[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <53e73b84-e2e1-42d7-afc9-f9bc04e5db37@ideasonboard.com>
Date: Thu, 22 Jan 2026 15:48:39 +0200
From: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To: Sean Anderson <sean.anderson@...ux.dev>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
dri-devel@...ts.freedesktop.org
Cc: Simona Vetter <simona@...ll.ch>, Thomas Zimmermann <tzimmermann@...e.de>,
linux-kernel@...r.kernel.org, Maxime Ripard <mripard@...nel.org>,
David Airlie <airlied@...il.com>, linux-arm-kernel@...ts.infradead.org,
Michal Simek <michal.simek@....com>,
Anatoliy Klymenko <anatoliy.klymenko@....com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Mike Looijmans <mike.looijmans@...ic.nl>
Subject: Re: [PATCH v2 0/4] drm: zynqmp: Make the video plane primary
Hi,
On 06/01/2026 18:42, Sean Anderson wrote:
> The graphics plane does not support XRGB8888, which is the default mode
> X uses for 24-bit color. Because of this, X must be set to use 16-bit
> color, which has a measurable performance penalty. Make the video plane
> the primary plane as it natively supports XRGB8888. An alternative
> approach to add XRGB8888 to the graphics plane is discussed in [1], as
> well as in patch 2.
>
> [1] https://lore.kernel.org/dri-devel/20250627145058.6880-1-mike.looijmans@topic.nl/
>
> Changes in v2:
> - Allow specifying blend mode default
> - Advertise coverage instead of premulti, since that's what the hardware
> supports.
> - Set default blend mode to none since that's what the default was
> before this series.
>
> Sean Anderson (4):
> drm/drm_blend: Allow specifying blend mode default
> drm: zynqmp: Check property creation status
> drm: zynqmp: Make the video plane primary
> drm: zynqmp: Add blend mode property to graphics plane
>
> drivers/gpu/drm/drm_blend.c | 22 ++++++-------
> drivers/gpu/drm/xlnx/zynqmp_kms.c | 53 +++++++++++++++++++++++++------
> include/drm/drm_blend.h | 26 +++++++++++++--
> 3 files changed, 78 insertions(+), 23 deletions(-)
>
I think the series looks fine, but there's still the main question of
whether making video plane primary is the best choice. I'll summarize my
understanding of our two options here:
1) Make video plane primary plane, and thus graphics plane an overlay
plane. The downside here is that, at least to me, the plane types feel
like they are the wrong way around, and any existing code that depends
on the plane type may start to fail. That said, the plane type is
supposed to be a legacy thing, and a modern userspace should just look
at the plane properties to decide how to use them (which raises the
question of why is X/Weston even failing).
2) Add XRGB format to the graphics plane. This should work fine too, as
long as we make sure using XRGB with per-pixel alpha will fail (i.e.
only global alpha supported with XRGB). Afaics that could be done with a
check in atomic_check.
Does anyone have strong arguments for either of these options?
Tomi
Powered by blists - more mailing lists