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/[email protected]/
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: [email protected]
W: www.topic.nl
