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

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Feb 15, 2023 at 12:01:25PM +0200, Pekka Paalanen wrote:
> 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

That requires some knowledge about the property in question to
pick the value. I think for some prop types (enums at least)
we could guarantee that the first value is always the safe default,
but for eg. range properties there is no way to know. So doing
that fully blind is not possible atm.

I guess one option might be to include a "reset value" in the
props somehow, and just have everyclient set all unknown props
to that. But there are of course other options too (reset
flag to atomic ioctl, etc.).

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

Yeah, it's a pretty rare problem so not much interest I guess.

-- 
Ville Syrjälä
Intel