Hello Harry, Few thoughts on the series from Intel perspective.
On 3/17/2026 9:33 PM, Harry Wentland wrote:
When we merged the drm_plane color pipeline API the major gap that existed was the lack of a color-space conversion colorop. We deprecated any legacy drm_plane color properties, which means that the COLOR_RANGE and COLOR_ENCODING properties can't be used with the COLOR_PIPELINE property on a drm_plane. In practice this means that we can't use a COLOR_PIPELINE on YCbCr encoded framebuffers. This patchset adds a CSC colorop with the COLOR_RANGE and COLOR_ENCODING properties and implements support in VKMS and amdgpu.
AFAIU, while COLOR_RANGE and COLOR_ENCODING were plane properties, they were more representative of how the framebuffer provided to the plane should be interpreted, rather than selecting a transformation. So using them to define CSC behavior is bit of a semantic drift.
From, Intel's HW perspective we could re-use this CSC colorop but it would be preferable to introduce new enums like "YCbCr709 to RGB", "YCbCr601 to RGB" as discussed in [1]. That way we can still represent the "RGB709 to RGB2020" conversion that Intel's fixed matrix CSC supports (instead of inventing a new colorop). We might need to change the name of colorop to something like Fixed Matrix to be inclusive of both YCbCr to RGB conversion and Primary conversion.
Regarding the range property, we could re-use the COLOR_RANGE property as you have done. In the case of Intel, we would only expose DRM_COLOR_YCBCR_FULL_RANGE as supported for this CSC, and use a separate colorop to perform YUV range correction. This allows userspace to still pass limited-range framebuffers. I am assuming here that it matters for user-space if the conversion was done in limited or full range.
[1] https://lore.kernel.org/dri-devel/[email protected]/
== Chaitanya
An alternate way of possibly representing this has been proposed here: https://patchwork.freedesktop.org/patch/709860 This code has been tested with IGT and an experimental KWin branch. IGT branch: https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/tree/csc-colorop KWin branch: https://invent.kde.org/hwentlan/kwin/-/tree/csc-3dlut The kernel branch containing these changes, based on drm-misc-next can be found at: https://gitlab.freedesktop.org/hwentland/linux/-/tree/csc-colorop In order to successfully use this branch you might need a few bugfixes. The kernel tree containing those fixes plus these patches can be found at: https://gitlab.freedesktop.org/hwentland/linux/-/tree/csc-colorop-all Further background on this work can be found at: https://hwentland.github.io/2026/03/10/plane-color-pipeline-csc-3d-lut-kwin.html Cc: Alex Hung <[email protected]> Cc: Daniel Stone <[email protected]> Cc: Chaitanya Kumar Borah <[email protected]> Cc: Uma Shankar <[email protected]> Cc: Louis Chauvet <[email protected]> Cc: Melissa Wen <[email protected]> Cc: Simon Ser <[email protected]> Harry Wentland (10): drm/colorop: Add CSC colorop type drm/colorop: Add CSC colorop initialization helper drm/atomic: Add CSC colorop state handling drm/vkms: Add CSC colorop support drm/vkms: Add atomic check and matrix handling for CSC colorop drm/amd/display: Implement CSC colorop support drm/amd/display: Use GAMCOR for first TF if CSC is used drm/amd/display: Check CSC colorop bypass before programming drm/amd/display: Check actual state during commit_tail drm/amd/display: Set color_space to plane_infos .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 ++- .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 115 +++++++++++++++++- .../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 25 +++- drivers/gpu/drm/drm_atomic.c | 6 + drivers/gpu/drm/drm_atomic_uapi.c | 8 ++ drivers/gpu/drm/drm_colorop.c | 91 ++++++++++++++ drivers/gpu/drm/vkms/vkms_colorop.c | 64 +++++++--- drivers/gpu/drm/vkms/vkms_composer.c | 5 + drivers/gpu/drm/vkms/vkms_plane.c | 50 +++++++- include/drm/drm_colorop.h | 39 ++++++ include/uapi/drm/drm_mode.h | 1 + 11 files changed, 388 insertions(+), 30 deletions(-) -- 2.53.0
