Re: [PATCH v4 01/11] drm/colorop: Add DRM_COLOROP_FIXED_MATRIX

Hi Pekka,

On 7/30/2026 7:57 PM, Pekka Paalanen wrote:
> On Tue, 28 Jul 2026 21:30:14 +0530
> "Borah, Chaitanya Kumar" <[email protected]> wrote:
> 
>> Hello Rober,
>>
>> On 7/28/2026 8:32 PM, Robert Mader wrote:
>>> Hi,
>>>
>>> On 22.07.26 15:45, Harry Wentland wrote:
>>>> From: Chaitanya Kumar Borah <[email protected]>
>>>>
>>>> Introduce DRM_COLOROP_FIXED_MATRIX, a new colorop type representing a
>>>> hardware that performs a fixed matrix operation.
>>>>
>>>> Unlike CTM-based colorops, this block does not expose programmable
>>>> coefficients. Instead, userspace selects one of the predefined
>>>> hardware modes via a new FIXED_MATRIX_TYPE enum property. Supported modes
>>>> include common YCbCr->RGB and RGB709->RGB2020 conversions.
>>>>
>>>> v4:
>>>>    - Add limited-range YCbCr-RGB conversion matrix enums (Robert)
>>>>    - Document matrix values (Pekka)
>>>>    - Clarify RGB709 to RGB2020 is a full-range matrix (Pekka)
>>>>    - Fix confusing "CSC preset" doc (Pekka)
>>>>
>>>> v2:
>>>>    - Naming changes (Pekka)
>>>>
>>>> v3:
>>>>    - Fix NC matrix enum name and string (Melissa)
>>>>    - Rebase
>>>>
>>>> Co-developed-by: Harry Wentland <[email protected]>
>>>> Signed-off-by: Chaitanya Kumar Borah <[email protected]>
>>>> Signed-off-by: Harry Wentland <[email protected]>
>>>> Reviewed-by: Melissa Wen <[email protected]>
>>>> Reviewed-by: Harry Wentland <[email protected]>
>>>> Reviewed-by: Robert Mader <[email protected]>
>>>> ---
>>>>    drivers/gpu/drm/drm_atomic.c      |   4 +
>>>>    drivers/gpu/drm/drm_atomic_uapi.c |   7 ++
>>>>    drivers/gpu/drm/drm_colorop.c     | 109 ++++++++++++++++++++
>>>>    include/drm/drm_colorop.h         | 159 ++++++++++++++++++++++++++++++
>>>>    include/uapi/drm/drm_mode.h       |  12 +++
>>>>    5 files changed, 291 insertions(+)
>>>>
> 
>>>> diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/
>>>> drm_colorop.c
>>>> index 682fcc651525..e7ccf7d053b8 100644
>>>> --- a/drivers/gpu/drm/drm_colorop.c
>>>> +++ b/drivers/gpu/drm/drm_colorop.c
>>>> @@ -68,6 +68,7 @@ static const struct drm_prop_enum_list
>>>> drm_colorop_type_enum_list[] = {
>>>>        { DRM_COLOROP_CTM_3X4, "3x4 Matrix"},
>>>>        { DRM_COLOROP_MULTIPLIER, "Multiplier"},
>>>>        { DRM_COLOROP_3D_LUT, "3D LUT"},
>>>> +    { DRM_COLOROP_FIXED_MATRIX, "Fixed Matrix"},
>>>>    };
>>>>    static const char * const colorop_curve_1d_type_names[] = {
>>>> @@ -90,6 +91,17 @@ static const struct drm_prop_enum_list
>>>> drm_colorop_lut3d_interpolation_list[] =
>>>>        { DRM_COLOROP_LUT3D_INTERPOLATION_TETRAHEDRAL, "Tetrahedral" },
>>>>    };
>>>> +static const char * const colorop_fixed_matrix_type_names[] = {
>>>> +    [DRM_COLOROP_FM_YCBCR601_FULL_RGB] = "YCbCr 601 Full to RGB",
>>>> +    [DRM_COLOROP_FM_YCBCR601_LIMITED_RGB] = "YCbCr 601 Limited to RGB",
>>>> +    [DRM_COLOROP_FM_YCBCR709_FULL_RGB] = "YCbCr 709 Full to RGB",
>>>> +    [DRM_COLOROP_FM_YCBCR709_LIMITED_RGB] = "YCbCr 709 Limited to RGB",
>>>> +    [DRM_COLOROP_FM_YCBCR2020_NC_FULL_RGB] = "YCbCr 2020 NC Full to
>>>> RGB",
>>>> +    [DRM_COLOROP_FM_YCBCR2020_NC_LIMITED_RGB] = "YCbCr 2020 NC
>>>> Limited to RGB",
>>>> +    [DRM_COLOROP_FM_YCBCR_LIMITED_FULL] = "YCbCr limited to full",
>>>> +    [DRM_COLOROP_FM_RGB709_RGB2020] = "RGB709 to RGB2020",
>>>
>>> I'm still a bit unsure how useful the later two values are,
>>
>> You can see them being used in [1] and tested by [2]. We split out the
>> "YCbCr limited to full" block because some Intel planes have a 1DLUT
>> between it and the "YCbCr XXX Full to RGB" block. This keeps the color
>> pipeline consistent with the actual HW.
> 
> Hi Chaitanya,
> 
> it would be nice for VKMS to be able to have such a color
> pipeline only. Then userspace authors can test it.
> 

Sure! I will float something soon.

> That gives me the idea, that perhaps there should be a library of color
> pipelines for VKMS that replicates actual hardware pipelines. Maybe it
> would be in the kernel, or maybe it would be in some userspace project
> if VKMS pipelines can be crafted through configfs or something else.
> 

Sounds like a good idea. Worth exploring.

I'll give it some thought, but no promises ;)

>> Based on your experience implementing the colorop in weston, do you
>> foresee any challenges in supporting limited-range framebuffers using
>> the "YCbCr Limited-to-Full" fixed matrix block?
> 
> I cannot imagine a big problem, but it is yet another configuration
> that userspace must be explicitly prepared for.
> 

Thank you for clearing it up. We will check if we can extend Robert's 
implementation to support this.

==
Chaitanya

> 
> Thanks,
> pq
> 
> 
>> As for the "RGB709 to RGB2020" block, I can see it being useful for
>> converting SDR Rec.709 content into the Rec.2020 color space before
>> blending it with an HDR plane.
>>
>> ==
>> Chaitanya
>>
>>
>> [1]
>> https://lore.kernel.org/dri-devel/[email protected]/
>> [2]
>> https://lore.kernel.org/igt-dev/[email protected]/
>>
>> especially
>>> as they are not implemented in this series - IMO they should be left out
>>> and be part of the corresponding Intel series.
>>>
>>> Anyway, still R-B
>>>