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@xxxxxxxxxx> 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
