Re: [Intel-gfx] New uAPI for color management proposal and feedback request

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1157 bytes --]

On Mon, 7 Jun 2021 09:48:05 +0200
Maxime Ripard <maxime@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

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx