All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Paalanen <pekka.paalanen@collabora.com>
To: Robert Mader <robert.mader@collabora.com>
Cc: dri-devel@lists.freedesktop.org,
	"Maxime Ripard" <mripard@kernel.org>,
	"Daniel Stone" <daniels@collabora.com>,
	"Harry Wentland" <harry.wentland@amd.com>,
	"Jonas Ådahl" <jadahl@redhat.com>,
	"Michel Dänzer" <mdaenzer@redhat.com>,
	"Sebastian Wick" <sebastian.wick@redhat.com>,
	"Simon Ser" <contact@emersion.fr>,
	"Victoria Brekenfeld" <victoria@system76.com>,
	"Xaver Hugl" <xaver.hugl@kde.org>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] drm/atomic: Clear plane pipeline for legacy clients
Date: Thu, 30 Jul 2026 17:41:00 +0300	[thread overview]
Message-ID: <20260730174100.017a1b5a@fluorite> (raw)
In-Reply-To: <20260709115855.53725-1-robert.mader@collabora.com>

[-- Attachment #1: Type: text/plain, Size: 2473 bytes --]

On Thu,  9 Jul 2026 13:58:55 +0200
Robert Mader <robert.mader@collabora.com> wrote:

> 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(+)

Hi Robert,

this sounds reasonable indeed.

Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>

Thanks,
pq

> 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);
>  


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      parent reply	other threads:[~2026-07-30 14:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09 11:58 [PATCH v1] drm/atomic: Clear plane pipeline for legacy clients Robert Mader
2026-07-09 12:26 ` sashiko-bot
2026-07-10  7:59 ` Michel Dänzer
2026-07-30 14:41 ` Pekka Paalanen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260730174100.017a1b5a@fluorite \
    --to=pekka.paalanen@collabora.com \
    --cc=airlied@gmail.com \
    --cc=contact@emersion.fr \
    --cc=daniels@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=harry.wentland@amd.com \
    --cc=jadahl@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mdaenzer@redhat.com \
    --cc=mripard@kernel.org \
    --cc=robert.mader@collabora.com \
    --cc=sebastian.wick@redhat.com \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    --cc=victoria@system76.com \
    --cc=xaver.hugl@kde.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.