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

[Harry Wentland]

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.

Userspace needs full control of framebuffer pixel formats,
as well as control over DEGAMMA, GAMMA, CTM color operations.
It also needs to be able to select whether to drive the panel
as sRGB or BT.2020/PQ but it doesn't make sense for it to
control the pixel encoding on the wire (RGB vs YCbCr).

> I really don't want a repeat of the disaster of the
> 'Broadcast RGB' which has coupled together the infoframe 
> and automagic conversion stuff. And I think this one would
> be about 100x worse given this property has something
> to do with actual colorspaces as well.
>  

I'm unaware of this disaster. Could you elaborate?

Harry