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 Regards, Hans
