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

[Pekka Paalanen <ppaalanen@gmail.com>]

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

On Mon, 23 May 2022 13:54:50 +0200
Sebastian Wick <sebastian.wick@redhat.com> wrote:

> 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.

This is a very good point.

If one does an atomic commit (even with ALLOW_MODESET) but has changed
no KMS property at all, there should be no change in KMS hardware
state. That would be logical to me, but I also understand why KMS
doesn't work like that yet: the existing KMS properties are not enough.

Also KMS properties with "auto" value are probably favoring "the
best/highest possible" instead of "keep current state", which raises the
question of how such KMS properties should be initialized when the
firmware has chosen a different value from what "auto" in the driver
would. At the same time, this should not regress old userspace that
never sets a KMS property because the userspace was written before the
kernel exposed the property and the only thing happening was the driver
automatically choosing the value. Actually, the definition of "auto"
therefore is neither; it is "whatever the driver happened to be doing
before exposing this property".

Another question is how userspace can tell the kernel that it wants to
keep the current hardware state. That's the Plymouth problem.

Mind that "max bpc" is *always* in auto. It's only an upper limit, with
the assumption that the driver can choose less.


Thanks,
pq

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