lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ