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

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Sebastian Wick <sebastian.wick@redhat.com>
Cc: amd-gfx@lists.freedesktop.org,
	Pekka Paalanen <ppaalanen@gmail.com>,
	Uma Shankar <uma.shankar@intel.com>,
	dri-devel@lists.freedesktop.org, Joshua Ashton <joshua@froggi.es>,
	Vitaly.Prosyak@amd.com
Subject: Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
Date: Fri, 3 Feb 2023 15:35:14 +0200	[thread overview]
Message-ID: <Y90NkvVabh+ue9hF@intel.com> (raw)
In-Reply-To: <CA+hFU4ymiOg06MQeKLcn5MSrR=BZnOLODdZCFvGUdWqt_ha61A@mail.gmail.com>

On Fri, Feb 03, 2023 at 01:59:07PM +0100, Sebastian Wick wrote:
> On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > On Fri, Feb 03, 2023 at 02:07:44AM +0000, Joshua Ashton wrote:
> > > Userspace has no way of controlling or knowing the pixel encoding
> > > currently, so there is no way for it to ever get the right values here.
> >
> > That applies to a lot of the other values as well (they are
> > explicitly RGB or YCC). The idea was that this property sets the
> > infoframe/MSA/SDP value exactly, and other properties should be
> > added to for use userspace to control the pixel encoding/colorspace
> > conversion(if desired, or userspace just makes sure to
> > directly feed in correct kind of data).
> 
> I'm all for getting userspace control over pixel encoding but even
> then the kernel always knows which pixel encoding is selected and
> which InfoFrame has to be sent. Is there a reason why userspace would
> want to control the variant explicitly to the wrong value?

What do you mean wrong value? Userspace sets it based on what
kind of data it has generated (or asked the display hardware
to generate if/when we get explicit control over that part).

-- 
Ville Syrjälä
Intel