On Mon, 23 May 2022 13:54:50 +0200 Sebastian Wick <sebastian.wick@xxxxxxxxxx> 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:
pgpztMJgu694T.pgp
Description: OpenPGP digital signature
