On 2022-05-25 09:28, Pekka Paalanen wrote: > 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. 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. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
