Hey,
On 7/1/26 15:32, Robert Mader wrote: > Hi Maarten, > > On 01.07.26 12:41, Maarten Lankhorst wrote: >> Hello, >> >> All you have to do is iterate over all planes at runtime until >> one is found that has the pipeline property attached, it's not >> a performance sensitive area and no locking is required for >> testing if plane->color_pipeline_property is NULL. > > that's correct - I checked that before and while the amount of code changes > necessary to support such a > "check-planes-with-cap-enabled-and-reinitialize-without-cap-otherwise" is not > big (AFAICS it should be possible with under 100 lines in Weston), it would > need to be replicated in various Wayland compositors and lots of apps with > native DRM backend (drm_info, Gstreamer KMS sink, MPV, Kodi etc.). The small > change proposed here seems like a more elegant solution to me. > > In a previous chat Pekka and Simon seemed to agree, quoting: "< emersion> pq, > you mean the cap is advertised regardless of driver support? that sounds like > a bug". You misunderstand my comment, I meant this from the kernel side. >> You can also make drm_plane_create_color_pipeline_property set >> the flag in drm_device::driver_features that the cap is supported. > Automatically enabling the driver feature sounds like a reasonable > improvement - I'll try that, thanks! >> >> But the cap setting code's not really performance sensitive, it will >> be called only a few times during boot at most. Perhaps check whether >> the first crtc->primary plane has the cap is also sufficient. >> >> If you want to continue with a special driver cap, then please set >> the flag for the xe driver too. > Indeed, will do in case the approach mentioned above doesn't work out for > some reason. >> Kind regards, >> ~Maarten Lankhorst > > Regards and thanks for the feedback!e >> >> On 6/30/26 10:42, Robert Mader wrote: >>> From the main commit: >>> >>> The client cap is currently advertised unconditionally, even for drivers >>> that do >>> not support plane color pipelines. If clients supporting the later, like >>> Wayland >>> compositors and drm_info, enable the client cap on sich drivers they will be >>> left without both color pipeline and the legacy properties COLOR_ENCODING >>> and >>> COLOR_RANGE, effectively breaking YUV->RGB conversion support. >>> >>> Add a new driver feature and guard the client cap behind it, allowing >>> plane color pipeline and legacy YUV->RGB support to co-exist. >>> >>> In case of VKMS make the client cap depend on the enable_plane_pipeline. >>> >>> The series can be easily tested with drm_info >= v2.10.0 and VKMS. Without >>> the >>> enable_plane_pipeline option - currently the default - the legacy flags >>> COLOR_ENCODING and COLOR_RANGE should be advertised, just like older >>> drm_info >>> versions. >>> >>> --- >>> >>> Related series actually implementing the color pipeline replacement for the >>> legacy flags: >>> https://lists.freedesktop.org/archives/dri-devel/2026-June/575655.html >>> >>> >>> Robert Mader (4): >>> drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE behind driver feature >>> drm/amdgpu: Add DRIVER_PLANE_COLOR_PIPELINE driver feature >>> drm/i915: Add DRIVER_PLANE_COLOR_PIPELINE driver feature >>> drm/vkms: Add DRIVER_PLANE_COLOR_PIPELINE driver feature >>> >>> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- >>> drivers/gpu/drm/drm_ioctl.c | 2 ++ >>> drivers/gpu/drm/i915/i915_driver.c | 2 +- >>> drivers/gpu/drm/vkms/vkms_drv.c | 6 +++++- >>> include/drm/drm_drv.h | 6 ++++++ >>> 5 files changed, 15 insertions(+), 3 deletions(-) >>>
