linux-kernel - Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT

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: <80ca3ab4-da77-4fb5-94f4-0d1d9acc7fa1@ideasonboard.com>
Date: Wed, 5 Nov 2025 11:51:14 +0200
From: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To: Mike Looijmans <mike.looijmans@...ic.nl>, dri-devel@...ts.freedesktop.org
Cc: David Airlie <airlied@...il.com>,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Michal Simek <michal.simek@....com>,
 Simona Vetter <simona@...ll.ch>, Thomas Zimmermann <tzimmermann@...e.de>,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

Hi,

On 27/06/2025 17:50, Mike Looijmans wrote:
> XRGB8888 is the default mode that Xorg will want to use. Add support
> for this to the Zynqmp DisplayPort driver, so that applications can use
> 32-bit framebuffers. This solves that the X server would fail to start
> unless one provided an xorg.conf that sets DefaultDepth to 16.
> 
> Signed-off-by: Mike Looijmans <mike.looijmans@...ic.nl>
> ---
> 
>  drivers/gpu/drm/xlnx/zynqmp_disp.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> index 80d1e499a18d..501428437000 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> @@ -312,6 +312,11 @@ static const struct zynqmp_disp_format avbuf_gfx_fmts[] = {
>  		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_RGBA8888,
>  		.swap		= true,
>  		.sf		= scaling_factors_888,
> +	}, {
> +		.drm_fmt	= DRM_FORMAT_XRGB8888,
> +		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_RGBA8888,
> +		.swap		= true,
> +		.sf		= scaling_factors_888,
>  	}, {
>  		.drm_fmt	= DRM_FORMAT_RGBA8888,
>  		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_ABGR8888,

I did some testing with this.

With current upstream, I can't start either weston or X. Weston says
XRGB8888 not supported, X says modeset failed.

But we do have XRGB8888, on the VID plane. VID plane is even set as the
first plane (perhaps intentionally, to have XRGB8888 on the first
plane?). However, for VID plane, we set DRM_PLANE_TYPE_OVERLAY and for
GFX plane we set DRM_PLANE_TYPE_PRIMARY. According to docs, these plane
type flags are legacy, and are ignored by userspace that supports
universal planes. So, both Weston and X should work, but don't.

Out of interest, I tested switching the plane types the other way
around. This made weston start, but X still doesn't. So apparently
weston does use those flags, and they're mandatory. I'm a bit surprised
that X doesn't start. So having the first plane as PRIMARY with XRGB8888
still wasn't enough for some reason.

With this patch, both weston and X start.

According to Anatoliy: "The ZynqMP DP blender ignores per pixel alpha if
top plane alpha is enabled (which is always the case in the driver). So,
AR24 is effectively treated as XR24 by the hardware". So should we then
remove the alpha formats from the driver, as they are effectively not
supported?

 Tomi