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

[Sebastian Wick]

On Fri, Feb 3, 2023 at 2:35 PM Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
>
> 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 at 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).

Wrong in the sense of sending the YCC variant when the pixel encoding
is RGB for example.

Maybe I'm missing something here but my assumption is that the kernel
always has to know the pixel encoding anyway. The color pipeline also
assumes that the pixel values are RGB. User space might be able to
generate YCC content but for subsampling etc the pixel encoding still
has to be explicitly set.

So with the kernel always knowing exactly what pixel encoding is sent,
why do we need those variants? I just don't see why this is necessary.

>
> --
> Ville Syrjälä
> Intel
>