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

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

On Wed, May 25, 2022 at 01:36:47PM +0300, Pekka Paalanen wrote:
> On Wed, 25 May 2022 09:23:51 +0000
> Simon Ser <contact@emersion.fr> wrote:
> 
> > On Wednesday, May 25th, 2022 at 10:35, Michel Dänzer <michel.daenzer@mailbox.org> wrote:
> > 
> > > > Mind that "max bpc" is always in auto. It's only an upper limit, with
> > > > the assumption that the driver can choose less.  
> > >
> > > It seems to me like the "max bpc" property is just kind of bad API,
> > > and trying to tweak it to cater to more use cases as we discover them
> > > will take us down a rabbit hole. It seems better to replace it with
> > > new properties which allow user space to determine the current
> > > effective bpc and to explicitly control it.  
> > 
> > +1, this sounds much more robust, and allows better control by user-space.
> > User-space needs to have fallback logic for other state as well anyways.
> > If the combinatorial explosion is too much, we should think about optimizing
> > the KMS implementation, or improve the uAPI.
> 
> +1 as well, with some recommendations added and the running off to the
> sunset:
> 
> Use two separate KMS properties for reporting current vs.
> programming desired. The KMS property reporting the current value
> must be read-only (immutable). This preserves the difference between
> what userspace wanted and what it got, making it possible to read
> back both without confusing them. It also allows preserving driver behaviour

I don't see much real point in a property to report the current bpc.
That can't be used to do anything atomically. So I suppose plymouth
would be the only user.

So IMO if someone really need explicit control over this then we 
should just expose properties to set things explicitly. So we'd
need at least props for the actual bpc and some kind of color 
encoding property (RGB/YCbCr 4:4:4/4:2:2:/4:2:0, etc.). And someone
would really need to figure out how DSC would interact with those.

For just the plymouth case I guess the easiest thing would be to
just clamp "max bpc" to the current value. The problem with that
is that we'd potentially break existing userspace. Eg. I don't think
the modesetting ddx or perhaps even most of the wayland compositors
set "max bpc" at all. So we'd need to roll out a bunch of userspace
updates first. And the "current bpc" prop idea would also have this
same problem since plymouth would just clamp "max bpc" based on the
current bpc before the real userspace starts.

-- 
Ville Syrjälä
Intel