Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2368 bytes --]

On Tue, 14 Feb 2023 22:10:35 +0200
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> On Tue, Feb 14, 2023 at 08:45:00PM +0100, Sebastian Wick wrote:

...

> > We also have to figure out how a user space which doesn't
> > know about the new property behaves when another client has set that
> > property. If any property which currently might change the pixel
> > values is used, we can't expose the entire color pipeline because the
> > kernel might have to use some element in it to achieve its magic
> > conversion. So essentially you already have this hard device between
> > "old" and "new" and you can't use the new stuff incrementally.  
> 
> That problem exists with any new property. Old userspace and new
> userspace may interact badly enought that nothing works right.
> In that sense I think these props might even be pretty mundane
> as the worst you might get from setting the infoframe wrong is
> perhaps wrong colors on your display.
> 
> To solve that particular problem there has been talk (for years)
> about some kind of "reset all" knob to make sure everything is
> at a safe default value. I have a feeling there was even some
> kind of semi-real proposal in recent times, but maybe I imgained
> it?

I've been talking about that too, but I think it all collapsed into
"let's just fix all KMS apps to always set all KMS properties" which
results in patches like
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/952

It does not seem to be a serious enough problem for anyone to put in
the work. And why would it be, when you can easily fix it in your own
project like that Weston example. The Weston example is not even
representative, because I did it before I saw any real problems.

Other musings have been in the direction that maybe logind (since it
opens DRM devices for you) should save the full KMS state on the very
first open after a reboot, and then KMS applications can ask logind
what the boot-up state was. This is a variation of "save all KMS state
from the moment you launch, and use that as the base if you ever let
something else touch KMS in between".

You also never see the problem to begin with, if you never let
something else touch KMS in between, so that already makes the problem
rare outside of the tiny set of compositor developers.


Thanks,
pq

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