Hi,
On 07.07.26 15:01, Maarten Lankhorst wrote:
Hey,
On 7/7/26 10:03, Borah, Chaitanya Kumar wrote:
On 7/3/2026 1:02 PM, Robert Mader wrote:
The client cap is currently advertised unconditionally, even for drivers
that do not support plane color pipelines. If clients supporting the later,
s/later/latter
like Wayland compositors or tools like drm_info, enable the client cap on
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.
This change will but a driver can also choose to export colorops like
programmable CTM_3x4 to achieve the same.
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.
Would this be doable inside drm core? Implement the color pipeline properties,
get the fixed pipeline for free?
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
