New uAPI for color management proposal and feedback request

Pekka Paalanen 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.
> 
> https://github.com/raspberrypi/linux/pull/4201
> 
> 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).

Hi Maxime,

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
switching back.

Please, consider whether this use-case will work before designing a
property where read-back may not necessarily return the written value.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20210607/70326cd1/attachment.sig>


More information about the amd-gfx mailing list