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 08, 2023 at 11:18:42AM +0200, Pekka Paalanen wrote:
> On Fri, 3 Feb 2023 16:02:51 +0200
> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> 
> > 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@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@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.
> 
> But it's impossible to use a YCbCr framebuffer and have that *not*
> converted to RGB for the KMS color pipeline even if userspace wanted it
> to be strictly pass-through, only to be converted again to YCbCr for
> the cable, is it not?
> 
> Even more so with 4:2:0.
> 
> How could it be possible to stop the driver from doing those two
> YUV-to-RGB and RGB-to-YCbCr conversions at the beginning and at the end
> of the KMS color pipeline?

You can stop the conversion at the start of the pipeline by
using a "RGB" framebuffer. At the end of the pipe it's not
possible with the current props.

-- 
Ville Syrjälä
Intel