[PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Mike Looijmans]

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,
 	}, {
 		.drm_fmt	= DRM_FORMAT_RGBA8888,
 		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_ABGR8888,
-- 
2.43.0

base-commit: 67a993863163cb88b1b68974c31b0d84ece4293e
branch: linux-master-zynqmpdp-32bit

Met vriendelijke groet / kind regards,

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

Please consider the environment before printing this e-mail

Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Laurent Pinchart]

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.

>  	}, {
>  		.drm_fmt	= DRM_FORMAT_RGBA8888,
>  		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_ABGR8888,

-- 
Regards,

Laurent Pinchart

Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Mike Looijmans]

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

Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Laurent Pinchart]

On Mon, Jun 30, 2025 at 10:03:16AM +0200, Mike Looijmans wrote:
> On 27-06-2025 20:19, Laurent Pinchart wrote:
> > 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.

That won't work when using global alpha unfortunately :-(

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

Correct, *if* global alpha is set to full opaque, then you can disable
the blender. That could confuse userspace though, enabling the graphics
plane with XRGB would work, and then enabling the video plane with
global alpha would fail.

> Guess I'll need assistance from AMD/Xilinx to completely implement the 
> XRGB modes.

The blender can ignore the alpha channel of the graphics plane for
formats that have no alpha channel. It would be nice if there was a bit
to force that behaviour for 32-bit RGB too, but I couldn't find any :-(
It's worth asking though.

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

-- 
Regards,

Laurent Pinchart

Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2790 bytes --]

On Mon, Jun 30, 2025 at 10:03:16AM +0200, Mike Looijmans wrote:
> 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)

Given that we consider XRGB8888 mandatory, this patch is a good thing to
have anyway, even if suboptimal, or broken in some scenario we can
always fix later.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Laurent Pinchart]

On Mon, Jun 30, 2025 at 10:27:55AM +0200, Maxime Ripard wrote:
> On Mon, Jun 30, 2025 at 10:03:16AM +0200, Mike Looijmans wrote:
> > On 27-06-2025 20:19, Laurent Pinchart wrote:
> > > 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)
> 
> Given that we consider XRGB8888 mandatory,

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

> this patch is a good thing to
> have anyway, even if suboptimal, or broken in some scenario we can
> always fix later.

It needs to at least be updated to disallow XRGB8888 usage when the
video plan is enabled, or when global alpha is set to a non-opaque
value.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3358 bytes --]

On Mon, Jun 30, 2025 at 12:11:56PM +0300, Laurent Pinchart wrote:
> On Mon, Jun 30, 2025 at 10:27:55AM +0200, Maxime Ripard wrote:
> > On Mon, Jun 30, 2025 at 10:03:16AM +0200, Mike Looijmans wrote:
> > > On 27-06-2025 20:19, Laurent Pinchart wrote:
> > > > 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)
> > 
> > Given that we consider XRGB8888 mandatory,
> 
> How about platforms that can't support it at all ?

We emulate it.

> > this patch is a good thing to
> > have anyway, even if suboptimal, or broken in some scenario we can
> > always fix later.
> 
> It needs to at least be updated to disallow XRGB8888 usage when the
> video plan is enabled, or when global alpha is set to a non-opaque
> value.

Yeah, that's reasonable

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Laurent Pinchart]

On Mon, Jun 30, 2025 at 11:29:08AM +0200, Maxime Ripard wrote:
> On Mon, Jun 30, 2025 at 12:11:56PM +0300, Laurent Pinchart wrote:
> > On Mon, Jun 30, 2025 at 10:27:55AM +0200, Maxime Ripard wrote:
> > > On Mon, Jun 30, 2025 at 10:03:16AM +0200, Mike Looijmans wrote:
> > > > On 27-06-2025 20:19, Laurent Pinchart wrote:
> > > > > 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)
> > > 
> > > 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 ?

> > > this patch is a good thing to
> > > have anyway, even if suboptimal, or broken in some scenario we can
> > > always fix later.
> > 
> > It needs to at least be updated to disallow XRGB8888 usage when the
> > video plan is enabled, or when global alpha is set to a non-opaque
> > value.
> 
> Yeah, that's reasonable

-- 
Regards,

Laurent Pinchart

Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3694 bytes --]

On Mon, Jun 30, 2025 at 12:33:35PM +0300, Laurent Pinchart wrote:
> On Mon, Jun 30, 2025 at 11:29:08AM +0200, Maxime Ripard wrote:
> > On Mon, Jun 30, 2025 at 12:11:56PM +0300, Laurent Pinchart wrote:
> > > On Mon, Jun 30, 2025 at 10:27:55AM +0200, Maxime Ripard wrote:
> > > > On Mon, Jun 30, 2025 at 10:03:16AM +0200, Mike Looijmans wrote:
> > > > > On 27-06-2025 20:19, Laurent Pinchart wrote:
> > > > > > 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)
> > > > 
> > > > 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.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Laurent Pinchart]

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:
> > On Mon, Jun 30, 2025 at 11:29:08AM +0200, Maxime Ripard wrote:
> > > On Mon, Jun 30, 2025 at 12:11:56PM +0300, Laurent Pinchart wrote:
> > > > On Mon, Jun 30, 2025 at 10:27:55AM +0200, Maxime Ripard wrote:
> > > > > On Mon, Jun 30, 2025 at 10:03:16AM +0200, Mike Looijmans wrote:
> > > > > > On 27-06-2025 20:19, Laurent Pinchart wrote:
> > > > > > > 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)
> > > > > 
> > > > > 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

Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 4244 bytes --]

On Mon, Jun 30, 2025 at 02:30:08PM +0300, Laurent Pinchart wrote:
> 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:
> > > On Mon, Jun 30, 2025 at 11:29:08AM +0200, Maxime Ripard wrote:
> > > > On Mon, Jun 30, 2025 at 12:11:56PM +0300, Laurent Pinchart wrote:
> > > > > On Mon, Jun 30, 2025 at 10:27:55AM +0200, Maxime Ripard wrote:
> > > > > > On Mon, Jun 30, 2025 at 10:03:16AM +0200, Mike Looijmans wrote:
> > > > > > > On 27-06-2025 20:19, Laurent Pinchart wrote:
> > > > > > > > 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)
> > > > > > 
> > > > > > 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 ?

No, it's for KMS.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Mike Looijmans]

On 30-06-2025 11:29, Maxime Ripard wrote:
> On Mon, Jun 30, 2025 at 12:11:56PM +0300, Laurent Pinchart wrote:
>> On Mon, Jun 30, 2025 at 10:27:55AM +0200, Maxime Ripard wrote:
>>> On Mon, Jun 30, 2025 at 10:03:16AM +0200, Mike Looijmans wrote:
>>>> On 27-06-2025 20:19, Laurent Pinchart wrote:
>>>>> 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)
>>> Given that we consider XRGB8888 mandatory,
>> How about platforms that can't support it at all ?
> We emulate it.
>
>>> this patch is a good thing to
>>> have anyway, even if suboptimal, or broken in some scenario we can
>>> always fix later.
>> It needs to at least be updated to disallow XRGB8888 usage when the
>> video plan is enabled, or when global alpha is set to a non-opaque
>> value.
> Yeah, that's reasonable

And feasible too I think. Basically only allow XRGB8888 when things are 
either totally transparent or totally opaque. I'm only concerned it 
might to lead to strange behavior, depending on which layer you enable 
first.


>
> Maxime


-- 
Mike Looijmans

Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Mike Looijmans]

On 30-06-2025 10:21, Laurent Pinchart wrote:
> On Mon, Jun 30, 2025 at 10:03:16AM +0200, Mike Looijmans wrote:
>> On 27-06-2025 20:19, Laurent Pinchart wrote:
>>> 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.
> That won't work when using global alpha unfortunately :-(
>
>> 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.
> Correct, *if* global alpha is set to full opaque, then you can disable
> the blender. That could confuse userspace though, enabling the graphics
> plane with XRGB would work, and then enabling the video plane with
> global alpha would fail.
>
>> Guess I'll need assistance from AMD/Xilinx to completely implement the
>> XRGB modes.
> The blender can ignore the alpha channel of the graphics plane for
> formats that have no alpha channel. It would be nice if there was a bit
> to force that behaviour for 32-bit RGB too, but I couldn't find any :-(
> It's worth asking though.

Yes, my problem exactly.


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

RE: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Klymenko, Anatoliy]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Mike,

> -----Original Message-----
> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Mike
> Looijmans
> Sent: Monday, June 30, 2025 7:49 AM
> 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>; Simek, Michal <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
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 30-06-2025 10:21, Laurent Pinchart wrote:
> > On Mon, Jun 30, 2025 at 10:03:16AM +0200, Mike Looijmans wrote:
> >> On 27-06-2025 20:19, Laurent Pinchart wrote:
> >>> 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.
> > That won't work when using global alpha unfortunately :-(
> >
> >> 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.
> > Correct, *if* global alpha is set to full opaque, then you can disable
> > the blender. That could confuse userspace though, enabling the graphics
> > plane with XRGB would work, and then enabling the video plane with
> > global alpha would fail.
> >
> >> Guess I'll need assistance from AMD/Xilinx to completely implement the
> >> XRGB modes.
> > The blender can ignore the alpha channel of the graphics plane for
> > formats that have no alpha channel. It would be nice if there was a bit
> > to force that behaviour for 32-bit RGB too, but I couldn't find any :-(
> > It's worth asking though.
>

Unfortunately, there are no such explicit flag on the HW side. Although,
some blender modes may turn off per-pixel alpha as a side effect. Let me
check if I can find some trick to make it happen.

> Yes, my problem exactly.
>
>
> >
> >> (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
>
>
--
Thank you,
Anatoliy

RE: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Klymenko, Anatoliy]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi All,

> -----Original Message-----
> From: Klymenko, Anatoliy
> Sent: Monday, June 30, 2025 6:03 PM
> To: Mike Looijmans <mike.looijmans@topic.nl>; 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>; Simek, Michal <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
>
> Hi Mike,
>
> > -----Original Message-----
> > From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Mike
> > Looijmans
> > Sent: Monday, June 30, 2025 7:49 AM
> > 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>; Simek, Michal <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
> >
> > Caution: This message originated from an External Source. Use proper
> caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > On 30-06-2025 10:21, Laurent Pinchart wrote:
> > > On Mon, Jun 30, 2025 at 10:03:16AM +0200, Mike Looijmans wrote:
> > >> On 27-06-2025 20:19, Laurent Pinchart wrote:
> > >>> 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.
> > > That won't work when using global alpha unfortunately :-(
> > >
> > >> 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.
> > > Correct, *if* global alpha is set to full opaque, then you can disable
> > > the blender. That could confuse userspace though, enabling the graphics
> > > plane with XRGB would work, and then enabling the video plane with
> > > global alpha would fail.
> > >
> > >> Guess I'll need assistance from AMD/Xilinx to completely implement the
> > >> XRGB modes.
> > > The blender can ignore the alpha channel of the graphics plane for
> > > formats that have no alpha channel. It would be nice if there was a bit
> > > to force that behaviour for 32-bit RGB too, but I couldn't find any :-(
> > > It's worth asking though.
> >
>
> Unfortunately, there are no such explicit flag on the HW side. Although,
> some blender modes may turn off per-pixel alpha as a side effect. Let me
> check if I can find some trick to make it happen.
>

After some investigations I may confirm that this patch works, and it is
safe to accept it. 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.

> > Yes, my problem exactly.
> >
> >
> > >
> > >> (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
> >
> >
> --
> Thank you,
> Anatoliy
>

Thank you,
Anatoliy

RE: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Klymenko, Anatoliy]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Klymenko, Anatoliy
> Sent: Tuesday, October 14, 2025 1:57 PM
> To: Mike Looijmans <mike.looijmans@topic.nl>; 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>; Simek, Michal <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
>
> Hi All,
>
> > -----Original Message-----
> > From: Klymenko, Anatoliy
> > Sent: Monday, June 30, 2025 6:03 PM
> > To: Mike Looijmans <mike.looijmans@topic.nl>; 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>; Simek, Michal <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
> >
> > Hi Mike,
> >
> > > -----Original Message-----
> > > From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
> Mike
> > > Looijmans
> > > Sent: Monday, June 30, 2025 7:49 AM
> > > 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>; Simek, Michal <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
> > >
> > > Caution: This message originated from an External Source. Use proper
> > caution
> > > when opening attachments, clicking links, or responding.
> > >
> > >
> > > On 30-06-2025 10:21, Laurent Pinchart wrote:
> > > > On Mon, Jun 30, 2025 at 10:03:16AM +0200, Mike Looijmans wrote:
> > > >> On 27-06-2025 20:19, Laurent Pinchart wrote:
> > > >>> 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.
> > > > That won't work when using global alpha unfortunately :-(
> > > >
> > > >> 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.
> > > > Correct, *if* global alpha is set to full opaque, then you can disable
> > > > the blender. That could confuse userspace though, enabling the graphics
> > > > plane with XRGB would work, and then enabling the video plane with
> > > > global alpha would fail.
> > > >
> > > >> Guess I'll need assistance from AMD/Xilinx to completely implement the
> > > >> XRGB modes.
> > > > The blender can ignore the alpha channel of the graphics plane for
> > > > formats that have no alpha channel. It would be nice if there was a bit
> > > > to force that behaviour for 32-bit RGB too, but I couldn't find any :-(
> > > > It's worth asking though.
> > >
> >
> > Unfortunately, there are no such explicit flag on the HW side. Although,
> > some blender modes may turn off per-pixel alpha as a side effect. Let me
> > check if I can find some trick to make it happen.
> >
>
> After some investigations I may confirm that this patch works, and it is
> safe to accept it. 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.
>
> > > Yes, my problem exactly.
> > >
> > >
> > > >
> > > >> (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
> > >
> > >
> > --
> > Thank you,
> > Anatoliy
> >
>
> Thank you,
> Anatoliy

Almost forgot,

Tested-by: Anatoliy Klymenko <anatoliy.klymenko@amd.com>

- Anatoliy

Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Sean Anderson]

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@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,
>  	}, {
>  		.drm_fmt	= DRM_FORMAT_RGBA8888,
>  		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_ABGR8888,

Tested-by: Sean Anderson <sean.anderson@linux.dev>

I can confirm that this provides a nice performance boost :)

Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Tomi Valkeinen]

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@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,
>  	}, {
>  		.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

Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Sean Anderson]

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@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,
>>  	}, {
>>  		.drm_fmt	= DRM_FORMAT_RGBA8888,
>>  		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_ABGR8888,
> 
> Tested-by: Sean Anderson <sean.anderson@linux.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.

--Sean

Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Tomi Valkeinen]

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@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,
>>>  	}, {
>>>  		.drm_fmt	= DRM_FORMAT_RGBA8888,
>>>  		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_ABGR8888,
>>
>> Tested-by: Sean Anderson <sean.anderson@linux.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.

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?

 Tomi

Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Sean Anderson]

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@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,
>>>>  	}, {
>>>>  		.drm_fmt	= DRM_FORMAT_RGBA8888,
>>>>  		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_ABGR8888,
>>>
>>> Tested-by: Sean Anderson <sean.anderson@linux.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

Re: [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Sean Anderson]

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@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,
>>  	}, {
>>  		.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
> 
> 
>