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

[Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>]

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