linux-kernel - Re: [PATCH 0/2] drm: xlnx: zynqmp_kms: 16 bpp fixes for Xorg startup on AMD KV260

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <93d715b1-cee0-4067-a8ff-1dce562bd083@suse.de>
Date: Tue, 6 Jan 2026 09:42:40 +0100
From: Thomas Zimmermann <tzimmermann@...e.de>
To: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
 Mikko Rapeli <mikko.rapeli@...aro.org>
Cc: dri-devel@...ts.freedesktop.org, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>, Michal Simek <michal.simek@....com>,
 Bill Mills <bill.mills@...aro.org>,
 Ilias Apalodimas <ilias.apalodimas@...aro.org>
Subject: Re: [PATCH 0/2] drm: xlnx: zynqmp_kms: 16 bpp fixes for Xorg startup
 on AMD KV260

Hi

Am 06.01.26 um 09:29 schrieb Tomi Valkeinen:
> Hi,
>
> On 06/01/2026 09:41, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 22.12.25 um 09:58 schrieb Mikko Rapeli:
>>> Hi,
>>>
>>> On Fri, Dec 19, 2025 at 02:30:11PM +0200, Mikko Rapeli wrote:
>>>> On Fri, Dec 19, 2025 at 01:59:14PM +0200, Tomi Valkeinen wrote:
>>>>> On 05/12/2025 14:37, Mikko Rapeli wrote:
>>>>>> Currently on default yocto images Xorg fails to start on AMD KV260
>>>>>> because 24/32 color depth gets detected but does not actually work.
>>>>>>
>>>>>> These two patches fix the issue and now 16 bpp gets detected
>>>>>> and Xorg starts and draws on external HDMI display using
>>>>>> kernel.org based linux-yocto kernel.
>>>>>>
>>>>>> Anatoliy Klymenko (1):
>>>>>>     drm: xlnx: zynqmp_kms: Init fbdev with 16 bit color
>>>>>>
>>>>>> Mikko Rapeli (1):
>>>>>>     drm: xlnx: zynqmp_kms: set preferred_depth to 16 bpp
>>>>>>
>>>>>>    drivers/gpu/drm/xlnx/zynqmp_kms.c | 3 ++-
>>>>>>    1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>
>>>>> Did you notice the few already sent serieses on the list where the
>>>>> topic
>>>>> has been discussed?
>>>>> [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888
>>>>> [PATCH 0/3] drm: zynqmp: Make the video plane primary
>>>> Oh I wasn't aware of these.
>>>>
>>>>> Or is there something else on KV260 that messes up the 24 bit color?
>>>> These look very similar and likely fix the X11 startup. I will give them
>>>> a try.
>>> Right, now I've tested:
>>>
>>>    * these patches from Anatoliy and me to help X11 use 16bpp mode by
>>> default
>>>      and removes the need to manually setup Xorg for 16bpp
>>>    * "drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888" which enables
>>> the X11 default
>>>      24bpp to work, no need to set Xorg config to 16bpp
>>>    * "drm: zynqmp: Make the video plane primary" which also fixes the
>>> X11 default
>>>      24bpp to work, no need to set Xorg config to 16bpp
>>>
>>> All of these fix HDMI graphics output on AMD KV260 board with yocto
>>> genericarm64 machine
>>> and core-image-sato image which includes Xorg. The graphics rendering
>>> is still
>>> very slow but I think that is a different problem.
>>>
>>> I guess the last series from Sean Anderson is moving forward so I'll
>>> reply to that thread separately.
>> Just want to say that the series here improves xlnx and makes it a
>> 'better' driver. IMHO the changes should be merged independently from
>> what happens with the other series.
> I might be missing something, but I don't think I fully agree. Yes, the
> userspace doesn't seem to be able to cope with the current upstream
> driver behavior (even if it's not wrong as such, afaics), so in that
> sense this series is better. But I don't think (almost) anyone really
> wants to use RGB565 if XRGB8888 is an option? And that's what the other
> series is trying to achieve, and that series conflicts with this one.
>
> So I'd rather try to get a conclusion on Sean's series (or the other one
> from Mike). If that effort fails, we could go with this series as a backup.

My point wasn't really about the color format. I meant that the 
preferred_depth field should always be set. If you see my comment on 
patch 1, passing NULL to drm_client_setup() and letting it auto-pick the 
format from preferred_depth would also make sense.

Best regards
Thomas

>
>   Tomi
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)