On 2022-05-25 00:03, Alex Deucher wrote:
On Tue, May 24, 2022 at 11:43 AM Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Tue, May 24, 2022 at 11:36:22AM +0200, Hans de Goede wrote:
Hi, On 5/23/22 13:54, Sebastian Wick wrote:
On Mon, May 23, 2022 at 10:23 AM Pekka Paalanen ppaalanen@gmail.com wrote:
Nice to see there would be other uses for knowing which might be higher priority to the larger community.
Would it be proper to initialize 'max bpc' to the link depth used by boot-up firmware? I guess it could make things more reliable and solve the Plymouth blanking issue, but not the professional color management use cases.
I was always under the impression that if you do an atomic commit without changing any properties that it won't result in a mode set which would clearly make the current behavior a bug.
I agree, IMHO the i915 driver currently setting max-bpc to 12 by default, causing an unrequested link re-negotation on the first modeset is a bug in the i195 driver and is also the root cause of this plymouth bug-report:
https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/102
Why would anyone want to run at 8bpc when they have a panel with higher color depth? So I think someone is going to be doing that modeset eventually anyway.
We used to do something similar, but then got piles of bug reports about the displays running at 30Hz rather than 60 so we changed it to 8. It's hard to say what a user will prefer.
Ville's suggestion elsewhere to filter modes based on minimum bpc (and lower effective bpc as needed for the selected mode, while there's only the "max bpc" property) should take care of that particular issue?