[PATCH v1] drm/atomic: Clear plane pipeline for legacy clients

[PATCH v1] drm/atomic: Clear plane pipeline for legacy clients

[Robert Mader]

Clients that do not enable DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE and try to
apply a new plane state currently have no way to unset/reset an existing
non-bypass color pipeline, resulting in unexpected behavior.

As we can be sure that such clients do not expect plane pipelines to be
set, let's reset the later for them, ensuring clean bypass-only pipeline
states.

This is a less comprehensive but more backward compatible approach compared
to a DRM_MODE_ATOMIC_RESET flag (link) that is currently being discussed.
Considering the simplicity and clearly defined behavior of this case,
this change could serve as an additional stop-gap solution to smoothen the
transition to the new APIs, resulting in less breakage on systems with
existing clients.

Link: https://lore.kernel.org/all/CAFZQkGzw2MZGivy=oyYgZE3_dmxu-z-NbDgzh9uyqSsj=MG=2w@mail.gmail.com/

Signed-off-by: Robert Mader <robert.mader@collabora.com>

---

If an approach like this was previously rejected or clearly goes against
API rules (or is unacceptable for other reason), please excuse me (and
just let me know).

The main motivation for the patch came up during testing the Weston
implementation (link) for the fixed-matrix color-ops. The test there checks
both the color pipeline and legacy property ways of offloading YCbCr
buffers and the current reset-less situation results in the legacy one
failing once the color pipeline test ran before.

Link: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/2133
---
 drivers/gpu/drm/drm_atomic.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 735ab7badc2e..581fde90dbd8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -656,6 +656,9 @@ drm_atomic_get_plane_state(struct drm_atomic_commit *state,
 	state->planes[index].new_state = plane_state;
 	plane_state->state = state;
 
+	if (!state->plane_color_pipeline)
+		plane_state->color_pipeline = NULL;
+
 	drm_dbg_atomic(plane->dev, "Added [PLANE:%d:%s] %p state to %p\n",
 		       plane->base.id, plane->name, plane_state, state);
 
-- 
2.55.0

Re: [PATCH v1] drm/atomic: Clear plane pipeline for legacy clients

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Implicitly clearing `color_pipeline` in `drm_atomic_get_plane_state` without adding the affected colorops causes hardware state desynchronization.
- [Medium] Piecemeal reset of color pipelines for legacy clients leads to visually inconsistent planes on the same CRTC.
--

--- Patch [1]: [PATCH v1] drm/atomic: Clear plane pipeline for legacy clients ---
commit 58ecff67ea2c28b7e6969be3a82eb9da9e435470
Author: Robert Mader <robert.mader@collabora.com>

drm/atomic: Clear plane pipeline for legacy clients

This commit clears the color_pipeline pointer in drm_atomic_get_plane_state()
for legacy clients that do not enable DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE.
This ensures non-bypass color pipelines are reset to clean bypass-only
states.

Link: https://lore.kernel.org/all/CAFZQkGzw2MZGivy=oyYgZE3_dmxu-z-NbDgzh9uyqSsj=MG=2w@mail.gmail.com/
Link: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/2133

> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 735ab7badc2ec..581fde90dbd8d 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -656,6 +656,9 @@ drm_atomic_get_plane_state(struct drm_atomic_commit *state,
>  	state->planes[index].new_state = plane_state;
>  	plane_state->state = state;
>  
> +	if (!state->plane_color_pipeline)
> +		plane_state->color_pipeline = NULL;

[Severity: High]
Does clearing the color_pipeline here prevent the old colorops from being
added to the atomic transaction?

If a legacy client takes over the display after a modern compositor configured
a color pipeline, setting plane_state->color_pipeline to NULL means callers
will skip adding the affected colorops.

This appears to orphan the old active colorops from the atomic commit,
meaning driver hardware programming will not see the transition to disable
them, leaving the hardware out of sync with software state.

[Severity: Medium]
Will this piecemeal reset lead to visually inconsistent planes on the same CRTC?

Because this reset is tied to plane state retrieval, a legacy client performing
a partial update (like DRM_IOCTL_MODE_CURSOR) will only add the specific target
plane to the transaction.

Other active planes on the same CRTC would not have drm_atomic_get_plane_state()
called for them, so their complex color pipelines would remain fully active while
the updated plane is forced to bypass.

> +
>  	drm_dbg_atomic(plane->dev, "Added [PLANE:%d:%s] %p state to %p\n",
>  		       plane->base.id, plane->name, plane_state, state);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709115855.53725-1-robert.mader@collabora.com?part=1