Hello Robert, On 7/7/26 15:15, Robert Mader wrote: > 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).
Yeah no worries, I looked at the code and it seems -EOPNOTSUPP is used a lot in getcap/setcap. In particular when driver support is missing for features, I'll leave it as is and push it now. Kind regards, ~Maarten
