Re: New uAPI for color management proposal and feedback request

[Maxime Ripard <maxime@cerno.tech>]

Hi Pekka,

On Mon, Jun 07, 2021 at 11:06:32AM +0300, Pekka Paalanen wrote:
> 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 for bringing that up. I guess the work being done currently by
Werner and his active color format property addresses that concern :)

Maxime