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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <fbd1ce27-8c77-46c8-9a27-633d910215eb@seco.com>
Date: Thu, 13 Nov 2025 14:53:08 -0500
From: Sean Anderson <sean.anderson@...o.com>
To: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
 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

On 11/5/25 04:51, Tomi Valkeinen wrote:
> 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.

You have to configure X to use 16-bit color. e.g. set DefaultDepth 16 in
your screen section. That will cause X to use RGB565, which is
supported.

--Sean

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