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

[Ville Syrjälä]

On Fri, Feb 03, 2023 at 02:52:50PM +0100, Sebastian Wick wrote:
> 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.

The kernel doesn't really know much atm. In theory you can just
configure the thing to do a straight passthough and put anything you
want into your pixels.

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

-- 
Ville Syrjälä
Intel