Re: [PATCH 01/10] drm/colorop: Add DRM_COLOROP_CSC_FF

[Pekka Paalanen <pekka.paalanen@collabora.com>]

[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]

On Tue, 17 Mar 2026 17:59:27 +0530
"Borah, Chaitanya Kumar" <chaitanya.kumar.borah@intel.com> wrote:

> AFAIU, the block I wanted to represent is Full Range YCbCr -> Full Range 
> RGB. We have the following configuration in our plane.
> 
> [YUV range correction Block] -> [Degamma LUT] -> [PRESET CSC] -> [Gamma LUT]
> 
> With the legacy "COLOR RANGE" property, selecting limited range enabled 
> the YUV range correction block.
> 
> I still need to figure out what use-case does the degamma LUT in between 
> the Range correction block and the Preset CSC serve since YCbCr to RGB 
> conversion will take place in non-linear domain. But it makes me wonder 

Hi Chaitanya,

yes, that is peculiar indeed. At least "Degamma LUT" is usable with RGB
framebuffers.

> if we can have "COLOR ENCODING" and "COLOR RANGE" property within the 
> same colorop like you have been implementing in [1] or should they be 
> represented by separate colorops.

If there is another operation in between (Degamma LUT) that you want to
expose, then range-conversion and fixed-matrix operations need to have
their own colorops. The chain of colorops cannot go backwards.

OTOH, if there is a single hardware operation that does both
range-conversion and fixed-matrix, then there is no problem for a
driver to translate the pair of colorops into hardware configuration.
So it sounds like they should be defined as separate colorops, and then
drivers usually expose them together. Unless the hardware cannot do all
combinations of their values.


Thanks,
pq

> Uma please weigh in if you have something to add or disagree with.
> 
> ==
> Chaitanya
> 
> [1] https://gitlab.freedesktop.org/hwentland/linux/-/commits/csc-colorop
> 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]