The graphics plane does not support XRGB8888, which is the default mode
X uses for 24-bit color. Because of this, X must be set to use 16-bit
color, which has a measurable performance penalty. Make the video plane
the primary plane as it natively supports XRGB8888. An alternative
approach to add XRGB8888 to the graphics plane is discussed in [1], as
well as in patch 2.

[1] https://lore.kernel.org/dri-devel/20250627145058.6880-1-mike.looijmans@topic.nl/


Sean Anderson (3):
  drm: zynqmp: Check property creation status
  drm: zynqmp: Make the video plane primary
  drm: zynqmp: Add blend mode property to graphics plane

 drivers/gpu/drm/xlnx/zynqmp_kms.c | 42 +++++++++++++++++++++++++------
 1 file changed, 34 insertions(+), 8 deletions(-)

-- 
2.35.1.1320.gc452695387.dirty

Hi,

On Thu, Nov 13, 2025 at 03:37:11PM -0500, Sean Anderson wrote:
> The graphics plane does not support XRGB8888, which is the default mode
> X uses for 24-bit color. Because of this, X must be set to use 16-bit
> color, which has a measurable performance penalty. Make the video plane
> the primary plane as it natively supports XRGB8888. An alternative
> approach to add XRGB8888 to the graphics plane is discussed in [1], as
> well as in patch 2.
> 
> [1] https://lore.kernel.org/dri-devel/20250627145058.6880-1-mike.looijmans@topic.nl/

I've tested this series on AMD KV260 running Yocto genericarm64 machine config and
core-image-sato with Xorg. This series fixes HDMI output using X11, no need to
configure Xorg to 16bpp as workaround.

Tested-by: Mikko Rapeli <mikko.rapeli@linaro.org>

That said, I also tested
https://lore.kernel.org/dri-devel/20250627145058.6880-1-mike.looijmans@topic.nl/
and it works.

And I tested and submitted the patch for zynqmp framebuffer to prefer 16bpp
until different modes are actually support, which fixes Xorg startup and
the depth detection logic used there:

https://lore.kernel.org/dri-devel/20251205123751.2257694-3-mikko.rapeli@linaro.org/

This series and Mike's patches enable 24bpp mode to work, which I guess is the long
term path, but it is not clear to me what is still missing.

The patch from me fixes the current situtation where only 16bpp works but framebuffer
driver does not prefer that and thus userspace X11 uses the default 24bpp
which then fails. My patch could be merged right now until the XRGB8888 support
is finalized.

Cheers,

-Mikko

Hi,

On 13/11/2025 22:37, Sean Anderson wrote:
> The graphics plane does not support XRGB8888, which is the default mode
> X uses for 24-bit color. Because of this, X must be set to use 16-bit
> color, which has a measurable performance penalty. Make the video plane
> the primary plane as it natively supports XRGB8888. An alternative
> approach to add XRGB8888 to the graphics plane is discussed in [1], as
> well as in patch 2.
> 
> [1] https://lore.kernel.org/dri-devel/20250627145058.6880-1-mike.looijmans@topic.nl/
> 
> 
> Sean Anderson (3):
>   drm: zynqmp: Check property creation status
>   drm: zynqmp: Make the video plane primary
>   drm: zynqmp: Add blend mode property to graphics plane
> 
>  drivers/gpu/drm/xlnx/zynqmp_kms.c | 42 +++++++++++++++++++++++++------
>  1 file changed, 34 insertions(+), 8 deletions(-)
> 

I made a test with pykms and tried this series with a few different
things. Afaics with this series the driver behaves as I would expect the
driver to behave. It makes sense to have the lower z-order plane as the
primary plane, especially as it supports the standard XRGB8888.

That said, I don't think there's anything that exactly would make the
current way of having GFX as primary wrong... So I still don't see a
single obvious solution to this whole issue.

A few thoughts:

If there is no regression here (i.e. this just has never worked well
with X/Weston), might the actual fix be in X/Weston? Is there an actual
bug in the xilinx driver?

On the other hand, I think it makes sense for drivers to (try to) expose
the HW in a common way. XRGB8888 is the standard format, so it makes
sense to expose XRGB8888 on primary plane. I think this is how the
driver should have behaved from the start. But if changing that now
would cause user space regressions, it's not good either.

 Tomi

On 22-12-2025 10:48, Tomi Valkeinen wrote:
> Hi,
>
> On 13/11/2025 22:37, Sean Anderson wrote:
>> The graphics plane does not support XRGB8888, which is the default mode
>> X uses for 24-bit color. Because of this, X must be set to use 16-bit
>> color, which has a measurable performance penalty. Make the video plane
>> the primary plane as it natively supports XRGB8888. An alternative
>> approach to add XRGB8888 to the graphics plane is discussed in [1], as
>> well as in patch 2.
>>
>> [1] https://lore.kernel.org/dri-devel/20250627145058.6880-1-mike.looijmans@topic.nl/
>>
>>
>> Sean Anderson (3):
>>    drm: zynqmp: Check property creation status
>>    drm: zynqmp: Make the video plane primary
>>    drm: zynqmp: Add blend mode property to graphics plane
>>
>>   drivers/gpu/drm/xlnx/zynqmp_kms.c | 42 +++++++++++++++++++++++++------
>>   1 file changed, 34 insertions(+), 8 deletions(-)
>>
> I made a test with pykms and tried this series with a few different
> things. Afaics with this series the driver behaves as I would expect the
> driver to behave. It makes sense to have the lower z-order plane as the
> primary plane, especially as it supports the standard XRGB8888.
>
> That said, I don't think there's anything that exactly would make the
> current way of having GFX as primary wrong... So I still don't see a
> single obvious solution to this whole issue.
>
> A few thoughts:
>
> If there is no regression here (i.e. this just has never worked well
> with X/Weston), might the actual fix be in X/Weston? Is there an actual
> bug in the xilinx driver?
>
> On the other hand, I think it makes sense for drivers to (try to) expose
> the HW in a common way. XRGB8888 is the standard format, so it makes
> sense to expose XRGB8888 on primary plane. I think this is how the
> driver should have behaved from the start. But if changing that now
> would cause user space regressions, it's not good either.

I tried to get e.g. gstreamer to use the overlay as output (in YUV 
format), but never got that to work. Having read the comments on these 
series, it's probably the lack of positioning and scaling capabilities 
that made gstreamer discard it.

I expect no regression here - everyone who got the DP output to work 
must have been using some workaround already. The driver as it is now 
never worked with X11 (or wayland) anyway, unless you forced it into 
16-bit mode.

And given the capabilities, I seriously doubt that any user ever used 
the overlay plane.

For what it's worth, I'd say the best solution is to swap the planes and 
support XRGB8888 mode properly. Then at least, X11 and wayland work 
without further configuration or patches, the output quality is as it 
should be, and as an added bonus, the performance (with or without the 
MALI GPU) is much better too.


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

Hi

Am 13.11.25 um 21:37 schrieb Sean Anderson:
> The graphics plane does not support XRGB8888, which is the default mode
> X uses for 24-bit color. Because of this, X must be set to use 16-bit
> color, which has a measurable performance penalty. Make the video plane
> the primary plane as it natively supports XRGB8888. An alternative
> approach to add XRGB8888 to the graphics plane is discussed in [1], as
> well as in patch 2.

Did you try to set drm_device.mode_config.preferred_depth = 16, like at 
[1]?  IIRC user space looks at this value to auto-detect the color format.

[1] 
https://elixir.bootlin.com/linux/v6.17.7/source/drivers/gpu/drm/tiny/cirrus-qemu.c#L542

Best regards
Thomas

>
> [1] https://lore.kernel.org/dri-devel/20250627145058.6880-1-mike.looijmans@topic.nl/
>
>
> Sean Anderson (3):
>    drm: zynqmp: Check property creation status
>    drm: zynqmp: Make the video plane primary
>    drm: zynqmp: Add blend mode property to graphics plane
>
>   drivers/gpu/drm/xlnx/zynqmp_kms.c | 42 +++++++++++++++++++++++++------
>   1 file changed, 34 insertions(+), 8 deletions(-)
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)

Hi Thomas,

On 11/14/25 02:42, Thomas Zimmermann wrote:
> Hi
> 
> Am 13.11.25 um 21:37 schrieb Sean Anderson:
>> The graphics plane does not support XRGB8888, which is the default mode
>> X uses for 24-bit color. Because of this, X must be set to use 16-bit
>> color, which has a measurable performance penalty. Make the video plane
>> the primary plane as it natively supports XRGB8888. An alternative
>> approach to add XRGB8888 to the graphics plane is discussed in [1], as
>> well as in patch 2.
> 
> Did you try to set drm_device.mode_config.preferred_depth = 16, like at [1]?  IIRC user space looks at this value to auto-detect the color format.

I have not tried that. But I would rather use 24-bit color for the performance boost.

--Sean

Hi,

On Fri, Nov 14, 2025 at 10:35:10AM -0500, Sean Anderson wrote:
> On 11/14/25 02:42, Thomas Zimmermann wrote:
> > Am 13.11.25 um 21:37 schrieb Sean Anderson:
> >> The graphics plane does not support XRGB8888, which is the default mode
> >> X uses for 24-bit color. Because of this, X must be set to use 16-bit
> >> color, which has a measurable performance penalty. Make the video plane
> >> the primary plane as it natively supports XRGB8888. An alternative
> >> approach to add XRGB8888 to the graphics plane is discussed in [1], as
> >> well as in patch 2.
> > 
> > Did you try to set drm_device.mode_config.preferred_depth = 16, like at [1]?  IIRC user space looks at this value to auto-detect the color format.
> 
> I have not tried that. But I would rather use 24-bit color for the performance boost.

I have tested preferred_depth = 16 and it works. Proposed in
https://lists.freedesktop.org/archives/dri-devel/2025-December/540189.html
but I'm also fine with 24/32 bpp, or any default which draws pixels to HDMI
on AMD KV260 and X11 without manually changing the config.

This full series also works for me on AMD KV260 running Yocto genericarm64
machine config and core-image-sato image with Xorg.

Cheers,

-Mikko