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

[Pekka Paalanen]

On Fri, 3 Feb 2023 18:00:44 +0200
Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:

> On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
> > 
> > 
> > On 2/3/23 10:19, Ville Syrjälä wrote:  
> > > On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote:  
> > >>
> > >>
> > >> On 2/3/23 07:59, 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?
> > >>>  
> > >>
> > >> I've asked this before but haven't seen an answer: Is there an existing
> > >> upstream userspace project that makes use of this property (other than
> > >> what Joshua is working on in gamescope right now)? That would help us
> > >> understand the intent better.  
> > > 
> > > The intent was to control the infoframe colorimetry bits,
> > > nothing more. No idea what real userspace there was, if any.
> > >   
> > >>
> > >> I don't think giving userspace explicit control over the exact infoframe
> > >> values is the right thing to do.  
> > > 
> > > Only userspace knows what kind of data it's stuffing into
> > > the pixels (and/or how it configures the csc units/etc.) to
> > > generate them.
> > >   
> > 
> > Yes, but userspace doesn't control or know whether we drive
> > RGB or YCbCr on the wire. In fact, in some cases our driver
> > needs to fallback to YCbCr420 for bandwidth reasons. There
> > is currently no way for userspace to know that and I don't
> > think it makes sense.  
> 
> People want that control as well for whatever reason. We've
> been asked to allow YCbCr 4:4:4 output many times.
> 
> The automagic 4:2:0 fallback I think is rather fundementally
> incompatible with fancy color management. How would we even
> know whether to use eg. BT.2020 vs. BT.709 matrix? In i915
> that stuff is just always BT.709 limited range, no questions
> asked.

The difference between 4:4:4 and 4:2:0 is purely the sub-sampling. It
has absolutely no implication to colorimetry nor MatrixCoefficients at
all.


Thanks,
pq
-------------- 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/dri-devel/attachments/20230208/b700e3b6/attachment.sig>