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