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

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2936 bytes --]

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

It allows the desired value to include "auto" meaning the driver should
pick best/highest value that works. That helps with the combinatorial
explosion as userspace can leave details for the driver to choose when
it doesn't care. Then userspace can read back from "current" property
to see what actually happened.

Plymouth could read the "current" property first and explicitly set
that to keep the current setting instead of hitting "auto" or making
assumptions about firmware set state.

There could also be another special value "driver default", different
from "auto". While "auto" gets the best/highest possible, "driver
default" would be the default value and mean whatever the driver did
before it exposed this property. This should avoid regressions in
behaviour.

All this won't fix the "empty commit should not change anything"
problem, because userspace needs to explicitly set the properties it
does *not* want to change. That's backwards, but fixing that would mean
changing what existing userspace experiences - which might be ok or
not, I don't know.

Thinking even further, about the problem of TEST_ONLY commits not
telling you what "auto" settings would actually give you; there could
be a new/extended KMS ioctl that would be the same as commit now, but
allow the kernel to return another set of KMS state back with
TEST_ONLY. Like reading back all KMS state after commit was done for
real. The "current" KMS properties would be part of that set, and tell
userspace what would happen in a real commit.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]