Re: How should "max bpc" KMS property work?

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

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:
> >>
> >> On Fri, 20 May 2022 17:20:50 +0200
> >> Hans de Goede <hdegoede@redhat.com> 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