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

[Pekka Paalanen]

On Fri, 3 Feb 2023 16:02:51 +0200
Ville Syrjälä <ville.syrjala at 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 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.

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?

From uAPI point of view:

"Colorspace" currently defines (or does it? see my patch 2 review) the
colorimetry and the color model encoding. If a driver chooses the cable
encoding independently, the "Colorspace" color model encoding is often
wrong. If we have another KMS property to choose the cable encoding,
then it is possible to still set "Colorspace" to disagree with the
actual cable encoding. What's the use of that possibility to configure
things wrong?


Thanks,
pq

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20230208/9203dd34/attachment.sig>