On Mon, Jun 30, 2025 at 12:52:48PM +0200, Maxime Ripard wrote:

On Mon, Jun 30, 2025 at 12:33:35PM +0300, Laurent Pinchart wrote:

quoted

On Mon, Jun 30, 2025 at 11:29:08AM +0200, Maxime Ripard wrote:

quoted

On Mon, Jun 30, 2025 at 12:11:56PM +0300, Laurent Pinchart wrote:

quoted

On Mon, Jun 30, 2025 at 10:27:55AM +0200, Maxime Ripard wrote:

quoted

On Mon, Jun 30, 2025 at 10:03:16AM +0200, Mike Looijmans wrote:

quoted

On 27-06-2025 20:19, Laurent Pinchart wrote:

quoted

On Fri, Jun 27, 2025 at 04:50:46PM +0200, Mike Looijmans wrote:

quoted

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

  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)

Given that we consider XRGB8888 mandatory,

How about platforms that can't support it at all ?

We emulate it.

Does that imply a full memcpy of the frame buffer in the kernel driver,
or is it emulated in userspace ?

Neither :)

The kernel deals with it through drm_fb_xrgb8888_to_* helpers, but only
on the parts of the framebuffer that were modified through the damage
API.

Aahhh OK, it's for the fbdev emulation. So that means that drivers are
not required to support XRGB8888 ?


-- 
Regards,

Laurent Pinchart