[PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888

[Tomi Valkeinen]

Hi,

On 11/11/2025 23:09, Sean Anderson wrote:
> On 11/4/25 16:53, Sean Anderson wrote:
>> On 6/27/25 10:50, Mike Looijmans wrote:
>>> XRGB8888 is the default mode that Xorg will want to use. Add support
>>> for this to the Zynqmp DisplayPort driver, so that applications can use
>>> 32-bit framebuffers. This solves that the X server would fail to start
>>> unless one provided an xorg.conf that sets DefaultDepth to 16.
>>>
>>> Signed-off-by: Mike Looijmans <mike.looijmans at topic.nl>
>>> ---
>>>
>>>  drivers/gpu/drm/xlnx/zynqmp_disp.c | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c
>>> index 80d1e499a18d..501428437000 100644
>>> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
>>> +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
>>> @@ -312,6 +312,11 @@ static const struct zynqmp_disp_format avbuf_gfx_fmts[] = {
>>>  		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_RGBA8888,
>>>  		.swap		= true,
>>>  		.sf		= scaling_factors_888,
>>> +	}, {
>>> +		.drm_fmt	= DRM_FORMAT_XRGB8888,
>>> +		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_RGBA8888,
>>> +		.swap		= true,
>>> +		.sf		= scaling_factors_888,
>>>  	}, {
>>>  		.drm_fmt	= DRM_FORMAT_RGBA8888,
>>>  		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_ABGR8888,
>>
>> Tested-by: Sean Anderson <sean.anderson at linux.dev>
>>
>> I can confirm that this provides a nice performance boost :)
> 
> Actually, I think a better fix would be to make the "video" plane the
> primary one. That plane supports XRGB8888 natively, and then the
> graphics plane can be used as an overlay for e.g. windows or cursors.
True, but I think usually the overlay plane is the video plane, which
supports YUV formats. If we use the video plane as the root plane, then
that one is reserved and there's no "real" video overlay plane.

Did you check my recent reply to the thread? I didn't have too much time
to debug all the combinations and what exactly the userspace does. I'm
inclined to just merge this one which should improve the user experience
quite a bit, even if there are still unclear parts to this. The related
code can be improved later if we figure out the details.

Any objections?

 Tomi