New uAPI for color management proposal and feedback request
ppaalanen at gmail.com
Mon Jun 7 08:06:32 UTC 2021
On Mon, 7 Jun 2021 09:48:05 +0200
Maxime Ripard <maxime at cerno.tech> wrote:
> I've started to implement this for the raspberrypi some time ago.
> It's basically two properties: a bitmask of the available output pixel
> encoding to report both what the display and the controller supports,
> and one to actually set what the userspace wants to get enforced (and
> that would return the active one when read).
I would like to point out that I think it is a bad design to create a
read/write property that returns not what was written to it. It can
cause headaches to userspace that wants to save and restore property
values it does not understand. Userspace would want to do that to
mitigate damage from switching to another KMS client and then back. The
other KMS client could change properties the first KMS client does not
understand, causing the first KMS client to show incorrectly after
Please, consider whether this use-case will work before designing a
property where read-back may not necessarily return the written value.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the amd-gfx