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

Pekka Paalanen <[email protected]> Thu, 30 Jul 2026 17:27:58 +0300
Newsgroups	org.freedesktop.lists.amd-gfx,org.freedesktop.lists.dri-devel
Message-ID	<20260730172758.0c65485f@fluorite>
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.

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.

> 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.


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
> >
signature.asc (application/pgp-signature, 833 B)