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? ~Maarten
