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

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

[Mikko Rapeli]

Hi,

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(-)

-- 
2.34.1

[PATCH 1/2] drm: xlnx: zynqmp_kms: Init fbdev with 16 bit color

[Mikko Rapeli]

From: Anatoliy Klymenko <anatoliy.klymenko@amd.com>

Use RG16 buffer format for fbdev emulation. Fbdev backend is being used
by Mali 400 userspace driver which expects 16 bit RGB pixel color format.
This change should not affect console or other fbdev applications as we
still have plenty of colors left.

Cc: Bill Mills <bill.mills@linaro.org>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: stable@vger.kernel.org
Signed-off-by: Anatoliy Klymenko <anatoliy.klymenko@amd.com>
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 drivers/gpu/drm/xlnx/zynqmp_kms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c
index 2bee0a2275ede..ccc35cacd10cb 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
@@ -525,7 +525,7 @@ int zynqmp_dpsub_drm_init(struct zynqmp_dpsub *dpsub)
 		goto err_poll_fini;
 
 	/* Initialize fbdev generic emulation. */
-	drm_client_setup_with_fourcc(drm, DRM_FORMAT_RGB888);
+	drm_client_setup_with_fourcc(drm, DRM_FORMAT_RGB565);
 
 	return 0;
 
-- 
2.34.1

Re: [PATCH 1/2] drm: xlnx: zynqmp_kms: Init fbdev with 16 bit color

[Thomas Zimmermann]

Hi

Am 05.12.25 um 13:37 schrieb Mikko Rapeli:
> From: Anatoliy Klymenko <anatoliy.klymenko@amd.com>
>
> Use RG16 buffer format for fbdev emulation. Fbdev backend is being used
> by Mali 400 userspace driver which expects 16 bit RGB pixel color format.
> This change should not affect console or other fbdev applications as we
> still have plenty of colors left.
>
> Cc: Bill Mills <bill.mills@linaro.org>
> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> Cc: stable@vger.kernel.org
> Signed-off-by: Anatoliy Klymenko <anatoliy.klymenko@amd.com>
> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>

Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>

although with patch 2 applied, you can simply call 
'drm_client_setup(drm, NULL)' and it should do the right thing.

Best regards
Thomas

> ---
>   drivers/gpu/drm/xlnx/zynqmp_kms.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> index 2bee0a2275ede..ccc35cacd10cb 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> @@ -525,7 +525,7 @@ int zynqmp_dpsub_drm_init(struct zynqmp_dpsub *dpsub)
>   		goto err_poll_fini;
>   
>   	/* Initialize fbdev generic emulation. */
> -	drm_client_setup_with_fourcc(drm, DRM_FORMAT_RGB888);
> +	drm_client_setup_with_fourcc(drm, DRM_FORMAT_RGB565);
>   
>   	return 0;
>   

-- 
--
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)

[PATCH 2/2] drm: xlnx: zynqmp_kms: set preferred_depth to 16 bpp

[Mikko Rapeli]

Xorg fails to start with defaults on AMD KV260, /var/log/Xorg.0.log:

[    23.491] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[    23.491] (II) Module fbdev: vendor="X.Org Foundation"
[    23.491]    compiled for 1.21.1.18, module version = 0.5.1
[    23.491]    Module class: X.Org Video Driver
[    23.491]    ABI class: X.Org Video Driver, version 25.2
[    23.491] (II) modesetting: Driver for Modesetting Kernel Drivers:
kms
[    23.491] (II) FBDEV: driver for framebuffer: fbdev
[    23.510] (II) modeset(0): using drv /dev/dri/card1
[    23.511] (WW) Falling back to old probe method for fbdev
[    23.511] (II) Loading sub module "fbdevhw"
[    23.511] (II) LoadModule: "fbdevhw"
[    23.511] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[    23.511] (II) Module fbdevhw: vendor="X.Org Foundation"
[    23.511]    compiled for 1.21.1.18, module version = 0.0.2
[    23.511]    ABI class: X.Org Video Driver, version 25.2
[    23.512] (II) modeset(0): Creating default Display subsection in
Screen section
        "Default Screen Section" for depth/fbbpp 24/32
[    23.512] (==) modeset(0): Depth 24, (==) framebuffer bpp 32
[    23.512] (==) modeset(0): RGB weight 888
[    23.512] (==) modeset(0): Default visual is TrueColor
...
[    23.911] (II) Loading sub module "fb"
[    23.911] (II) LoadModule: "fb"
[    23.911] (II) Module "fb" already built-in
[    23.911] (II) UnloadModule: "fbdev"
[    23.911] (II) Unloading fbdev
[    23.912] (II) UnloadSubModule: "fbdevhw"
[    23.912] (II) Unloading fbdevhw
[    24.238] (==) modeset(0): Backing store enabled
[    24.238] (==) modeset(0): Silken mouse enabled
[    24.249] (II) modeset(0): Initializing kms color map for depth 24, 8
bpc.
[    24.250] (==) modeset(0): DPMS enabled
[    24.250] (II) modeset(0): [DRI2] Setup complete
[    24.250] (II) modeset(0): [DRI2]   DRI driver: kms_swrast
[    24.250] (II) modeset(0): [DRI2]   VDPAU driver: kms_swrast
...
[    24.770] (II) modeset(0): Disabling kernel dirty updates, not
required.
[    24.770] (EE) modeset(0): failed to set mode: Invalid argument

xorg tries to use 24 and 32 bpp which pass on the fb API but which
don't actually work on AMD KV260 when Xorg starts. As a workaround
Xorg config can set color depth to 16 using /etc/X11/xorg.conf snippet:

Section "Screen"
        Identifier     "Default Screen"
        Monitor        "Configured Monitor"
        Device         "Configured Video Device"
        DefaultDepth   16
EndSection

But this is cumbersome on images meant for multiple different arm64
devices and boards. So instead set 16 bpp as preferred depth
in zynqmp_kms fb driver which is used by Xorg in the logic to find
out a working depth.

Now Xorg startup and bpp query using fb API works and HDMI display
shows graphics. /var/log/Xorg.0.log shows:

[    23.219] (II) LoadModule: "fbdev"
[    23.219] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[    23.219] (II) Module fbdev: vendor="X.Org Foundation"
[    23.219]    compiled for 1.21.1.18, module version = 0.5.1
[    23.219]    Module class: X.Org Video Driver
[    23.219]    ABI class: X.Org Video Driver, version 25.2
[    23.219] (II) modesetting: Driver for Modesetting Kernel Drivers:
kms
[    23.219] (II) FBDEV: driver for framebuffer: fbdev
[    23.238] (II) modeset(0): using drv /dev/dri/card1
[    23.238] (WW) Falling back to old probe method for fbdev
[    23.238] (II) Loading sub module "fbdevhw"
[    23.238] (II) LoadModule: "fbdevhw"
[    23.239] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[    23.239] (II) Module fbdevhw: vendor="X.Org Foundation"
[    23.239]    compiled for 1.21.1.18, module version = 0.0.2
[    23.239]    ABI class: X.Org Video Driver, version 25.2
[    23.240] (II) modeset(0): Creating default Display subsection in Screen section
        "Default Screen Section" for depth/fbbpp 16/16
[    23.240] (==) modeset(0): Depth 16, (==) framebuffer bpp 16
[    23.240] (==) modeset(0): RGB weight 565
[    23.240] (==) modeset(0): Default visual is TrueColor
...
[    24.015] (==) modeset(0): Backing store enabled
[    24.015] (==) modeset(0): Silken mouse enabled
[    24.027] (II) modeset(0): Initializing kms color map for depth 16, 6 bpc.
[    24.028] (==) modeset(0): DPMS enabled
[    24.028] (II) modeset(0): [DRI2] Setup complete
[    24.028] (II) modeset(0): [DRI2]   DRI driver: kms_swrast
[    24.028] (II) modeset(0): [DRI2]   VDPAU driver: kms_swrast

Cc: Bill Mills <bill.mills@linaro.org>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Anatoliy Klymenko <anatoliy.klymenko@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 drivers/gpu/drm/xlnx/zynqmp_kms.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c
index ccc35cacd10cb..a42192c827af0 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
@@ -506,6 +506,7 @@ int zynqmp_dpsub_drm_init(struct zynqmp_dpsub *dpsub)
 	drm->mode_config.min_height = 0;
 	drm->mode_config.max_width = ZYNQMP_DISP_MAX_WIDTH;
 	drm->mode_config.max_height = ZYNQMP_DISP_MAX_HEIGHT;
+	drm->mode_config.preferred_depth = 16;
 
 	ret = drm_vblank_init(drm, 1);
 	if (ret)
-- 
2.34.1

Re: [PATCH 2/2] drm: xlnx: zynqmp_kms: set preferred_depth to 16 bpp

[Thomas Zimmermann]

Hi

Am 05.12.25 um 13:37 schrieb Mikko Rapeli:
> Xorg fails to start with defaults on AMD KV260, /var/log/Xorg.0.log:
>
> [    23.491] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
> [    23.491] (II) Module fbdev: vendor="X.Org Foundation"
> [    23.491]    compiled for 1.21.1.18, module version = 0.5.1
> [    23.491]    Module class: X.Org Video Driver
> [    23.491]    ABI class: X.Org Video Driver, version 25.2
> [    23.491] (II) modesetting: Driver for Modesetting Kernel Drivers:
> kms
> [    23.491] (II) FBDEV: driver for framebuffer: fbdev
> [    23.510] (II) modeset(0): using drv /dev/dri/card1
> [    23.511] (WW) Falling back to old probe method for fbdev
> [    23.511] (II) Loading sub module "fbdevhw"
> [    23.511] (II) LoadModule: "fbdevhw"
> [    23.511] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
> [    23.511] (II) Module fbdevhw: vendor="X.Org Foundation"
> [    23.511]    compiled for 1.21.1.18, module version = 0.0.2
> [    23.511]    ABI class: X.Org Video Driver, version 25.2
> [    23.512] (II) modeset(0): Creating default Display subsection in
> Screen section
>          "Default Screen Section" for depth/fbbpp 24/32
> [    23.512] (==) modeset(0): Depth 24, (==) framebuffer bpp 32
> [    23.512] (==) modeset(0): RGB weight 888
> [    23.512] (==) modeset(0): Default visual is TrueColor
> ...
> [    23.911] (II) Loading sub module "fb"
> [    23.911] (II) LoadModule: "fb"
> [    23.911] (II) Module "fb" already built-in
> [    23.911] (II) UnloadModule: "fbdev"
> [    23.911] (II) Unloading fbdev
> [    23.912] (II) UnloadSubModule: "fbdevhw"
> [    23.912] (II) Unloading fbdevhw
> [    24.238] (==) modeset(0): Backing store enabled
> [    24.238] (==) modeset(0): Silken mouse enabled
> [    24.249] (II) modeset(0): Initializing kms color map for depth 24, 8
> bpc.
> [    24.250] (==) modeset(0): DPMS enabled
> [    24.250] (II) modeset(0): [DRI2] Setup complete
> [    24.250] (II) modeset(0): [DRI2]   DRI driver: kms_swrast
> [    24.250] (II) modeset(0): [DRI2]   VDPAU driver: kms_swrast
> ...
> [    24.770] (II) modeset(0): Disabling kernel dirty updates, not
> required.
> [    24.770] (EE) modeset(0): failed to set mode: Invalid argument
>
> xorg tries to use 24 and 32 bpp which pass on the fb API but which
> don't actually work on AMD KV260 when Xorg starts. As a workaround
> Xorg config can set color depth to 16 using /etc/X11/xorg.conf snippet:
>
> Section "Screen"
>          Identifier     "Default Screen"
>          Monitor        "Configured Monitor"
>          Device         "Configured Video Device"
>          DefaultDepth   16
> EndSection
>
> But this is cumbersome on images meant for multiple different arm64
> devices and boards. So instead set 16 bpp as preferred depth
> in zynqmp_kms fb driver which is used by Xorg in the logic to find
> out a working depth.
>
> Now Xorg startup and bpp query using fb API works and HDMI display
> shows graphics. /var/log/Xorg.0.log shows:
>
> [    23.219] (II) LoadModule: "fbdev"
> [    23.219] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
> [    23.219] (II) Module fbdev: vendor="X.Org Foundation"
> [    23.219]    compiled for 1.21.1.18, module version = 0.5.1
> [    23.219]    Module class: X.Org Video Driver
> [    23.219]    ABI class: X.Org Video Driver, version 25.2
> [    23.219] (II) modesetting: Driver for Modesetting Kernel Drivers:
> kms
> [    23.219] (II) FBDEV: driver for framebuffer: fbdev
> [    23.238] (II) modeset(0): using drv /dev/dri/card1
> [    23.238] (WW) Falling back to old probe method for fbdev
> [    23.238] (II) Loading sub module "fbdevhw"
> [    23.238] (II) LoadModule: "fbdevhw"
> [    23.239] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
> [    23.239] (II) Module fbdevhw: vendor="X.Org Foundation"
> [    23.239]    compiled for 1.21.1.18, module version = 0.0.2
> [    23.239]    ABI class: X.Org Video Driver, version 25.2
> [    23.240] (II) modeset(0): Creating default Display subsection in Screen section
>          "Default Screen Section" for depth/fbbpp 16/16
> [    23.240] (==) modeset(0): Depth 16, (==) framebuffer bpp 16
> [    23.240] (==) modeset(0): RGB weight 565
> [    23.240] (==) modeset(0): Default visual is TrueColor
> ...
> [    24.015] (==) modeset(0): Backing store enabled
> [    24.015] (==) modeset(0): Silken mouse enabled
> [    24.027] (II) modeset(0): Initializing kms color map for depth 16, 6 bpc.
> [    24.028] (==) modeset(0): DPMS enabled
> [    24.028] (II) modeset(0): [DRI2] Setup complete
> [    24.028] (II) modeset(0): [DRI2]   DRI driver: kms_swrast
> [    24.028] (II) modeset(0): [DRI2]   VDPAU driver: kms_swrast
>
> Cc: Bill Mills <bill.mills@linaro.org>
> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> Cc: Anatoliy Klymenko <anatoliy.klymenko@amd.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>

Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>

> ---
>   drivers/gpu/drm/xlnx/zynqmp_kms.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> index ccc35cacd10cb..a42192c827af0 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> @@ -506,6 +506,7 @@ int zynqmp_dpsub_drm_init(struct zynqmp_dpsub *dpsub)
>   	drm->mode_config.min_height = 0;
>   	drm->mode_config.max_width = ZYNQMP_DISP_MAX_WIDTH;
>   	drm->mode_config.max_height = ZYNQMP_DISP_MAX_HEIGHT;
> +	drm->mode_config.preferred_depth = 16;

There is another discussion on-going about rearranging planes. But to 
make user space work correctly, preferred_depth should be set no matter 
what.

Best regards
Thomas

>   
>   	ret = drm_vblank_init(drm, 1);
>   	if (ret)

-- 
--
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)

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

[Tomi Valkeinen]

Hi Mikko,

On 05/12/2025 14:37, Mikko Rapeli wrote:
> Hi,
> 
> 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

Or is there something else on KV260 that messes up the 24 bit color?

 Tomi

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

[Mikko Rapeli]

Hi,

On Fri, Dec 19, 2025 at 01:59:14PM +0200, Tomi Valkeinen wrote:
> Hi Mikko,
> 
> On 05/12/2025 14:37, Mikko Rapeli wrote:
> > Hi,
> > 
> > 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.

Cheers,

-Mikko

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

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

Tested-by: Mikko Rapeli <mikko.rapeli@linaro.org>

Cheers,
-Mikko

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

[Thomas Zimmermann]

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.

Best regards
Thomas

>
> Tested-by: Mikko Rapeli <mikko.rapeli@linaro.org>
>
> Cheers,
> -Mikko

-- 
--
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)

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

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

 Tomi

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

[Thomas Zimmermann]

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)

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

[Mikko Rapeli]

Hi,

On Tue, Jan 06, 2026 at 10:29:37AM +0200, Tomi Valkeinen wrote:
> 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.

I did testing of all three different patch series'es on AMD KV260 and
did not find any performance difference between them. The Xorg
rendering is still very slow to an external HDMI display.

I don't have an opinion on the graphics formats but just want something
out to a display by default. I think there is a lot more to fix to get
the performance into usable state.

Cheers,

-Mikko

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

[Thomas Zimmermann]

Hi

Am 07.01.26 um 09:00 schrieb Mikko Rapeli:
> Hi,
>
> On Tue, Jan 06, 2026 at 10:29:37AM +0200, Tomi Valkeinen wrote:
>> 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.
> I did testing of all three different patch series'es on AMD KV260 and
> did not find any performance difference between them. The Xorg
> rendering is still very slow to an external HDMI display.
>
> I don't have an opinion on the graphics formats but just want something
> out to a display by default. I think there is a lot more to fix to get
> the performance into usable state.

I briefly looked through the xlnx driver and found several things to try.

* The update code in [1] appears to always update the whole buffer. 
Setting drm_plane_enable_fb_damage_clips() for the planes will enable 
damage handling. Then flushing only the damaged areas might improve 
performance.

* The driver could set drm_device.mode_config.prefer_shadow to make Xorg 
use a shadow buffer in user space. This often works for devices with 
discrete VRAM.  IDK if non-X compositors also benefit from this.

* If the hardware supports it, setting non-coherent DMA mappings could 
enable caching on the memory buffers. The driver would then have to 
enable damage clips and flush caches by itself where necessary.

Best regards
Thomas

[1] 
https://elixir.bootlin.com/linux/v6.18.3/source/drivers/gpu/drm/xlnx/zynqmp_disp.c#L1109

>
> Cheers,
>
> -Mikko

-- 
--
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)

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

[Mikko Rapeli]

Hi,

On Wed, Jan 07, 2026 at 09:32:28AM +0100, Thomas Zimmermann wrote:
> Am 07.01.26 um 09:00 schrieb Mikko Rapeli:
> > On Tue, Jan 06, 2026 at 10:29:37AM +0200, Tomi Valkeinen wrote:
> > > On 06/01/2026 09:41, Thomas Zimmermann wrote:
> > > > Am 22.12.25 um 09:58 schrieb Mikko Rapeli:
> > > > > 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.
> > I did testing of all three different patch series'es on AMD KV260 and
> > did not find any performance difference between them. The Xorg
> > rendering is still very slow to an external HDMI display.
> > 
> > I don't have an opinion on the graphics formats but just want something
> > out to a display by default. I think there is a lot more to fix to get
> > the performance into usable state.
> 
> I briefly looked through the xlnx driver and found several things to try.
> 
> * The update code in [1] appears to always update the whole buffer. Setting
> drm_plane_enable_fb_damage_clips() for the planes will enable damage
> handling. Then flushing only the damaged areas might improve performance.
> 
> * The driver could set drm_device.mode_config.prefer_shadow to make Xorg use
> a shadow buffer in user space. This often works for devices with discrete
> VRAM.  IDK if non-X compositors also benefit from this.
> 
> * If the hardware supports it, setting non-coherent DMA mappings could
> enable caching on the memory buffers. The driver would then have to enable
> damage clips and flush caches by itself where necessary.
> 
> Best regards
> Thomas
> 
> [1] https://elixir.bootlin.com/linux/v6.18.3/source/drivers/gpu/drm/xlnx/zynqmp_disp.c#L1109

There is also the official AMD/Xilinx kernel tree with a lot more patches
which have not been upstreamed yet:

https://github.com/Xilinx/linux-xlnx/commits/master/drivers/gpu/drm/xlnx

I wasn't sure which of these changes fix the X11 startup issues but came up
with the 16bit patches since they are so simple and avoid doing the same
in Xorg config file.

Would be nice to get these AMD patches upstreamed, for example one subsystem
at a time.

Cheers,

-Mikko