Hey, On 7/9/26 08:44, Borah, Chaitanya Kumar wrote: > > > On 7/7/2026 6:31 PM, 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? > > Right now, the Bypass(default) pipeline is automatically created when we call > drm_plane_create_color_pipeline_property(), we could come up with a similar > helper that could also create a pipeline that replaces the legacy properties. > > But this can't replace the existing helper entirely because some HW (though > unlikely) might not support YUV buffers.
No need to do this for free, but a cheaper way for drivers to implement legacy properties by only implementing the pipeline would be nice, similar to how atomic also implements legacy modesetting and universal planes. Kind regards, ~Maarten Lankhorst
