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. -- Ville Syrjälä Intel
