[PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties

[Jyri Sarha]

On 04/21/17 14:17, Ville Syrjälä wrote:
>> +static char *ycbcr_to_rgb_mode_name[] = {
>> +	[DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT601_FULL] =
>> +		"YCbCr BT.601 limited range TO RGB BT.601 full range",
>> +	[DRM_PLANE_YCBCR_BT601_FULL_TO_RGB_BT601_FULL] =
>> +		"YCbCr BT.601 full range TO RGB BT.601 full range",
>> +	[DRM_PLANE_YCBCR_BT709_LIM_TO_RGB_BT709_FULL] =
>> +		"YCbCr BT.709 limited range TO RGB BT.709 full range",
>> +	[DRM_PLANE_YCBCR_BT2020_LIM_TO_RGB_BT2020_FULL] =
>> +		"YCbCr BT.2020 limited range TO RGB BT.2020 full range",
>> +	[DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT709_FULL] =
>> +		"YCbCr BT.601 limited range TO RGB BT.709 full range",
> We probably don't want to conflate the YCbCr->RGB part with the colorspace
> conversion because the YCbCr->RGB part should be performed on gamma encoded
> data and the colorspace conversion on linear data. So we need a degamma
> stage in between. At least that seemed to be the general concencus after
> the last round of mails on this topic.
> 

I do not really have the expertise to argue with that. I merely copied
the idea from the mail thread I referred to in the cover letter.
However, there are several display HWs out there that do not have all
bolts and knobs to make the color-space conversion in exactly the ideal
order, omap DSS being one of them.

> After staring at the v4l docs on this stuff I kinda like their
> "encoding" terminology to describe the YCbCr->RGB part, so I'm now a
> little partial to calling the prop something like YCBCR_ENCODING. OTOH

I guess this property should be called YCBCR_DECODING.

> if we want to expose the raw matrix as a blob then maybe calling it a
> CSC might be better. Not sure there's much point in exposing it though.

In my first version it was called just CSC, but then I wanted to make it
explicit what this CSC was used for to avoid mixing the YCbCr decoding
matrix with YCbCr encoding matrix. At least on OMAP DSS we have pieces
of HW that can do only one or the other, e.g. the offset calculations
are supported only to one direction.

> I don't think most people are in the habit if cooking up new ways to
> encode their pixel data.
> 

In the embedded side I can imagine there could be some custom appliances
where one may want to do some custom thing with the CSC and not needing
a custom kernel for that could make a life easier... but then again I am
not really an expert in this area.

Best regards,
Jyri