On Tue, May 24, 2022 at 11:43 AM Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> 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@xxxxxxxxx> wrote: > > >> > > >> On Fri, 20 May 2022 17:20:50 +0200 > > >> Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > >> > > >>> I got pointed to this thread by Jonas Ådahl while asking some questions > > >>> the "max bpc" property related to: > > >>> > > >>> https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/102#note_1382328 > > >>> > > >>> The current i915 behavior which you describe here, which if I understand > > >>> things correctly is for "max bpc" to default to as high as possible is > > >>> causing problems with flickerfree boot in plymouth. Plymouth does a modeset > > >>> on the monitor's native resolution in case the BIOS/GOP setup the monitor > > >>> in a non native mode. Plymouth does not touch the "max bpc" property when > > >>> doing this modeset. Normally this works fine and when the BIOS/GOP has > > >>> already configured the monitor at the native resolution the i915 driver > > >>> will do a fastset and all is well. > > >>> > > >>> Still the modeset is causing the screen to go black for multiple seconds, > > >>> despite the resolution being unchanged. What is happening according to > > >>> the on screen mode info from the monitor is that on plymouth's modeset > > >>> the link is being configured changes from 8 bpc to 10 bpc. > > >>> > > >>> Is there anyway to avoid this without hardcoding "max bpc" to 8 in > > >>> plymouth (which would cause the same problem in the other direction > > >>> if the firmware sets up the link for 10bpc I believe) ? > > >> > > >> Hi Hans, > > >> > > >> there was an attempt to get much of the current link state information > > >> delivered to userspace, but I've forgot most about it. > > >> I did find https://lkml.org/lkml/2021/6/18/294 linked from > > >> https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_963469 . > > >> I said the same in the Plymouth Gitlab issue you linked to. > > >> > > >> Personally, I would need to know all current link details for > > >> (professional) color management: am I still driving the monitor with > > >> the same signal as I did when I measured the monitor one reboot ago? > > >> If not, I cannot trust the color output and need to measure again. > > > > > > I would go further and say that not being in control of all the link > > > details is an issue for user space. > > > > > > Max bpc doesn't give us a minimum guarantee. > > > Bpc doesn't really make sense for YUV. > > > We don't know if the link is using RGB or YUV. > > > The Colorspace property requires user space to know if the link is RGB > > > or YUV (or does the link change depending on the Colorspace property? > > > What about the default Colorspace?). > > > Link compression can mess up colors. > > > > > > There simply is no way to write a proper user space with the current KMS API. > > > > > >> > > >> 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. Alex
