From: Mike Looijmans <mike.looijmans@topic.nl>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org, David Airlie <airlied@gmail.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Michal Simek <michal.simek@amd.com>,
Simona Vetter <simona@ffwll.ch>,
Thomas Zimmermann <tzimmermann@suse.de>,
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888
Date: Mon, 30 Jun 2025 10:03:16 +0200 [thread overview]
Message-ID: <42af6260-c8af-42e1-a9bb-adfaaabf0190@topic.nl> (raw)
In-Reply-To: <20250627181911.GF24912@pendragon.ideasonboard.com>
On 27-06-2025 20:19, Laurent Pinchart wrote:
> Hi Mike,
>
> Thank you for the patch.
>
> On Fri, Jun 27, 2025 at 04:50:46PM +0200, 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@topic.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,
> I'm afraid that's not enough. There's a crucial difference between
> DRM_FORMAT_ARGB8888 (already supported by this driver) and
> DRM_FORMAT_XRGB8888: for the latter, the 'X' component must be ignored.
> The graphics layer is blended on top of the video layer, and the blender
> uses both a global alpha parameter and the alpha channel of the graphics
> layer for 32-bit RGB formats. This will lead to incorrect operation when
> the 'X' component is not set to full opacity.
I spent a few hours digging in the source code and what I could find in
the TRM and register maps, but there's not enough information in there
to explain how the blender works. The obvious "XRGB" implementation
would be to just disable the blender.
What I got from experimenting so far is that the alpha component is
ignored anyway while the video path isn't active. So as long as one
isn't using the video blending path, the ARGB and XRGB modes are identical.
Guess I'll need assistance from AMD/Xilinx to completely implement the
XRGB modes.
(For our application, this patch is sufficient as it solves the issues
like X11 not starting up, OpenGL not working and horrendously slow
scaling performance)
>
>> }, {
>> .drm_fmt = DRM_FORMAT_RGBA8888,
>> .buf_fmt = ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_ABGR8888,
--
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl
next prev parent reply other threads:[~2025-06-30 8:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.fb98a918-329e-4536-a0a5-a99b22ba0120@emailsignatures365.codetwo.com>
2025-06-27 14:50 ` Mike Looijmans
2025-06-27 18:19 ` Laurent Pinchart
2025-06-30 8:03 ` Mike Looijmans [this message]
2025-06-30 8:21 ` Laurent Pinchart
2025-06-30 14:49 ` Mike Looijmans
2025-07-01 1:03 ` Klymenko, Anatoliy
2025-10-14 20:56 ` Klymenko, Anatoliy
2025-10-14 21:02 ` Klymenko, Anatoliy
2025-06-30 8:27 ` Maxime Ripard
2025-06-30 9:11 ` Laurent Pinchart
2025-06-30 9:29 ` Maxime Ripard
2025-06-30 9:33 ` Laurent Pinchart
2025-06-30 10:52 ` Maxime Ripard
2025-06-30 11:30 ` Laurent Pinchart
2025-06-30 11:48 ` Maxime Ripard
2025-06-30 14:47 ` Mike Looijmans
2025-11-04 21:53 ` Sean Anderson
2025-11-11 21:09 ` Sean Anderson
2025-11-12 9:31 ` Tomi Valkeinen
2025-11-13 15:36 ` Sean Anderson
2025-11-05 9:51 ` Tomi Valkeinen
2025-11-13 19:53 ` Sean Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42af6260-c8af-42e1-a9bb-adfaaabf0190@topic.nl \
--to=mike.looijmans@topic.nl \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=michal.simek@amd.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--cc=tomi.valkeinen@ideasonboard.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®