Re: [PATCH 0/3] drm: zynqmp: Make the video plane primary

[Mike Looijmans <mike.looijmans@topic.nl>]

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