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
