On Wed, 25 May 2022 09:23:51 +0000 Simon Ser <contact@xxxxxxxxxxx> wrote: > On Wednesday, May 25th, 2022 at 10:35, Michel Dänzer <michel.daenzer@xxxxxxxxxxx> 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:
pgpP979spYexO.pgp
Description: OpenPGP digital signature
