On 2022-05-25 09:28, Pekka Paalanen wrote:
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.
The problem then becomes how to change the effective bpc to the maximum value?
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.
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.