Re: [PATCH v3] drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE
From: Robert Mader
Date: Tue Jul 07 2026 - 09:27:10 EST
Hi,
On 07.07.26 15:01, Maarten Lankhorst wrote:
Hey,
On 7/7/26 10:03, Borah, Chaitanya Kumar wrote:
Would this be doable inside drm core? Implement the color pipeline properties, get the fixed pipeline for free?
On 7/3/2026 1:02 PM, Robert Mader wrote:
The client cap is currently advertised unconditionally, even for driverss/later/latter
that do not support plane color pipelines. If clients supporting the later,
like Wayland compositors or tools like drm_info, enable the client cap onThis change will but a driver can also choose to export colorops like programmable CTM_3x4 to achieve the same.
such drivers they will be left without both color pipeline and the legacy
properties COLOR_ENCODING and COLOR_RANGE, effectively breaking YUV->RGB
conversion support.
Prevent that by only marking the cap supported if there are actually planes
with color pipelines.
Note: while the color pipeline replacement for the legacy properties is
still under review (1), we can assume that it will work as a drop-in
replacement.
We should also perhaps document this somewhere that if a driver supports LEGACY properties, it is imperative to implement some version of it with the color pipeline line property.
But thanks for all feedback, as I was about to push this patch, I noticed it still uses -EOPNOTSUPP, can it be changed to -EINVAL?
For existing users it shouldn't make a difference. drm_info and Weston just check for "drmSetClientCap() == 0" - and old kernels without the cap will also return -EINVAL AFAICS.
I personally find -EOPNOTSUPP more appropriate and more in line with other return values in that function - but no strong opinion, thus feel free to change while applying (or I can resend the patch accordingly if you prefer).
Robert
~Maarten
--
Robert Mader
Consultant Software Developer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718