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] [thread-next>] [day] [month] [year] [list]

Message-ID: <d16af3e8-3ca1-4676-9112-32f7e33bd6df@linux.dev>
Date: Thu, 13 Nov 2025 10:36:12 -0500
From: Sean Anderson <sean.anderson@...ux.dev>
To: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
 Mike Looijmans <mike.looijmans@...ic.nl>, dri-devel@...ts.freedesktop.org,
 Anatoliy Klymenko <anatoliy.klymenko@....com>
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/12/25 04:31, Tomi Valkeinen wrote:
> Hi,
> 
> On 11/11/2025 23:09, Sean Anderson wrote:
>> On 11/4/25 16:53, Sean Anderson wrote:
>>> On 6/27/25 10: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,
>>>
>>> Tested-by: Sean Anderson <sean.anderson@...ux.dev>
>>>
>>> I can confirm that this provides a nice performance boost :)
>> 
>> Actually, I think a better fix would be to make the "video" plane the
>> primary one. That plane supports XRGB8888 natively, and then the
>> graphics plane can be used as an overlay for e.g. windows or cursors.
> True, but I think usually the overlay plane is the video plane, which
> supports YUV formats. If we use the video plane as the root plane, then
> that one is reserved and there's no "real" video overlay plane.

But you can't use it as an overlay anyway unless you enable colorkey.
Otherwise it's always an "underlay". So you can't actually have e.g. the
video layer display a decoded video in a window because that would
require userspace to "carve out" the window in the graphics alpha layer.
But as discussed earlier in this thread, the alpha channel is always
disabled by this driver! So the video layer is completely unusable in
the current driver anyway.

> Did you check my recent reply to the thread? I didn't have too much time
> to debug all the combinations and what exactly the userspace does. I'm
> inclined to just merge this one which should improve the user experience
> quite a bit, even if there are still unclear parts to this. The related
> code can be improved later if we figure out the details.
> 
> Any objections?

I object to this because it solidifies the current state of affairs
where the alpha channel of the graphics layer can't be used. I will
submit a series later today to change the primary plane and enable the
alpha channel.

--Sean