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

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

[Sean Anderson]

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

-- 
2.35.1.1320.gc452695387.dirty

[PATCH 1/3] drm: zynqmp: Check property creation status

[Sean Anderson]

Make sure to return an error in the event that we can't create our
properties.

Fixes: 650f12042b85 ("drm: xlnx: zynqmp_dpsub: Add global alpha support")
Fixes: 8c772f0b2b8e ("drm: xlnx: zynqmp_dpsub: Expose plane ordering to userspace")

Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
---

 drivers/gpu/drm/xlnx/zynqmp_kms.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c
index 2bee0a2275ed..c80a2d4034f3 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
@@ -174,9 +174,15 @@ static int zynqmp_dpsub_create_planes(struct zynqmp_dpsub *dpsub)
 
 		drm_plane_helper_add(plane, &zynqmp_dpsub_plane_helper_funcs);
 
-		drm_plane_create_zpos_immutable_property(plane, i);
-		if (i == ZYNQMP_DPSUB_LAYER_GFX)
-			drm_plane_create_alpha_property(plane);
+		ret = drm_plane_create_zpos_immutable_property(plane, i);
+		if (ret)
+			return ret;
+
+		if (i == ZYNQMP_DPSUB_LAYER_GFX) {
+			ret = drm_plane_create_alpha_property(plane);
+			if (ret)
+				return ret;
+		}
 	}
 
 	return 0;
-- 
2.35.1.1320.gc452695387.dirty

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

[Sean Anderson]

The zynqmp has two planes: "video" and "graphics". The video plane

- Is on the bottom (zpos=0) (except when chroma keying as the master plane)
- Supports "live" input (e.g. from an external source)
- Supports RGB, YUV, and YCbCr formats, including XRGB8888
- Does not support transparency, except via chroma keying (colorkey)
- Must cover the entire screen (translation/resizing not supported)

The graphics plane

- Is on the top (zpos=1)
- Supports "live" input (e.g. from an external source)
- Supports RGB and YUV444 formats, but not XRGB8888
- Supports transparency either via
  - Global alpha channel, which disables per-pixel alpha when enabled
  - Per-pixel alpha, which cannot be used with global alpha
  - Chroma keying (colorkey)
- Must cover the entire screen (translation/resizing not supported)

Currently the graphics plane is the primary plane. Make the video plane
the primary plane:

- The video plane supports XRGB8888, which is the default 24-bit
  colorspace for X. This results in improved performance when compared
  to RGB565.
- The graphics plane can be used as an overlay because it has a higher
  z-pos and supports a per-pixel alpha channel. Unfortunately, clients
  like weston cannot currently take advantage of this because they
  expect overlay planes to support translation/resizing.

One downside to this approach could be that the graphics plane has worse
support for YUV and YCBCr, so it may be more difficult to compose video
streams into the window of a media player. However, no existing software
could rely on this because there is no way to enable the per-pixel alpha
channel when the graphics plane is enabled. This makes it impossible to
"carve out" an area in the graphics plane where the video plane shows
through. This limitation is addressed in the next patch, but it means we
do not need to worry about compatibility in this area.

An alternate approach could be to pretend that the graphics plane
supports XRGB8888 by using the supported ARGB8888 mode instead and
enabling the global alpha channel. However, this would rule out ever
using the per-pixel alpha channel.

Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
---

 drivers/gpu/drm/xlnx/zynqmp_kms.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c
index c80a2d4034f3..456ada9ac003 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
@@ -161,8 +161,8 @@ static int zynqmp_dpsub_create_planes(struct zynqmp_dpsub *dpsub)
 		if (!formats)
 			return -ENOMEM;
 
-		/* Graphics layer is primary, and video layer is overlay. */
-		type = i == ZYNQMP_DPSUB_LAYER_VID
+		/* Graphics layer is overlay, and video layer is primary. */
+		type = i == ZYNQMP_DPSUB_LAYER_GFX
 		     ? DRM_PLANE_TYPE_OVERLAY : DRM_PLANE_TYPE_PRIMARY;
 		ret = drm_universal_plane_init(&dpsub->drm->dev, plane, 0,
 					       &zynqmp_dpsub_plane_funcs,
@@ -322,7 +322,7 @@ static const struct drm_crtc_funcs zynqmp_dpsub_crtc_funcs = {
 
 static int zynqmp_dpsub_create_crtc(struct zynqmp_dpsub *dpsub)
 {
-	struct drm_plane *plane = &dpsub->drm->planes[ZYNQMP_DPSUB_LAYER_GFX];
+	struct drm_plane *plane = &dpsub->drm->planes[ZYNQMP_DPSUB_LAYER_VID];
 	struct drm_crtc *crtc = &dpsub->drm->crtc;
 	int ret;
 
-- 
2.35.1.1320.gc452695387.dirty

[PATCH 3/3] drm: zynqmp: Add blend mode property to graphics plane

[Sean Anderson]

When global alpha is enabled, per-pixel alpha is ignored. Allow
userspace to explicitly specify whether to use per-pixel alpha by
exposing it through the blend mode property. I'm not sure whether the
per-pixel alpha is pre-multiplied or not [1], but apparently it *must* be
pre-multiplied so I guess we have to advertise it.

[1] All we get is "The alpha value available with the graphics stream
    will define the transparency of the graphics."

Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
---

 drivers/gpu/drm/xlnx/zynqmp_kms.c | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c
index 456ada9ac003..fa1cfc16db36 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
@@ -61,6 +61,13 @@ static int zynqmp_dpsub_plane_atomic_check(struct drm_plane *plane,
 	if (!new_plane_state->crtc)
 		return 0;
 
+	if (new_plane_state->pixel_blend_mode != DRM_MODE_BLEND_PIXEL_NONE &&
+	    new_plane_state->alpha >> 8 != 0xff) {
+		drm_dbg_kms(plane->dev,
+			    "Plane alpha must be 1.0 when using pixel alpha\n");
+		return -EINVAL;
+	}
+
 	crtc_state = drm_atomic_get_crtc_state(state, new_plane_state->crtc);
 	if (IS_ERR(crtc_state))
 		return PTR_ERR(crtc_state);
@@ -117,9 +124,13 @@ static void zynqmp_dpsub_plane_atomic_update(struct drm_plane *plane,
 
 	zynqmp_disp_layer_update(layer, new_state);
 
-	if (plane->index == ZYNQMP_DPSUB_LAYER_GFX)
-		zynqmp_disp_blend_set_global_alpha(dpsub->disp, true,
+	if (plane->index == ZYNQMP_DPSUB_LAYER_GFX) {
+		bool blend = plane->state->pixel_blend_mode ==
+			     DRM_MODE_BLEND_PIXEL_NONE;
+
+		zynqmp_disp_blend_set_global_alpha(dpsub->disp, blend,
 						   plane->state->alpha >> 8);
+	}
 
 	/*
 	 * Unconditionally enable the layer, as it may have been disabled
@@ -179,9 +190,18 @@ static int zynqmp_dpsub_create_planes(struct zynqmp_dpsub *dpsub)
 			return ret;
 
 		if (i == ZYNQMP_DPSUB_LAYER_GFX) {
+			unsigned int blend_modes =
+				BIT(DRM_MODE_BLEND_PIXEL_NONE) |
+				BIT(DRM_MODE_BLEND_PREMULTI);
+
 			ret = drm_plane_create_alpha_property(plane);
 			if (ret)
 				return ret;
+
+			ret = drm_plane_create_blend_mode_property(plane,
+								   blend_modes);
+			if (ret)
+				return ret;
 		}
 	}
 
-- 
2.35.1.1320.gc452695387.dirty

RE: [PATCH 2/3] drm: zynqmp: Make the video plane primary

[Klymenko, Anatoliy]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Sean,

Thanks a lot for the patch (and tackling the alpha issue in general)

> -----Original Message-----
> From: Sean Anderson <sean.anderson@linux.dev>
> Sent: Thursday, November 13, 2025 12:37 PM
> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org; Mike Looijmans <mike.looijmans@topic.nl>;
> David Airlie <airlied@gmail.com>; Thomas Zimmermann
> <tzimmermann@suse.de>; Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com>; Klymenko, Anatoliy
> <Anatoliy.Klymenko@amd.com>; Maxime Ripard <mripard@kernel.org>; linux-
> arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
> Michal <michal.simek@amd.com>; Sean Anderson
> <sean.anderson@linux.dev>
> Subject: [PATCH 2/3] drm: zynqmp: Make the video plane primary
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> The zynqmp has two planes: "video" and "graphics". The video plane
>
> - Is on the bottom (zpos=0) (except when chroma keying as the master plane)
> - Supports "live" input (e.g. from an external source)
> - Supports RGB, YUV, and YCbCr formats, including XRGB8888
> - Does not support transparency, except via chroma keying (colorkey)
> - Must cover the entire screen (translation/resizing not supported)
>
> The graphics plane
>
> - Is on the top (zpos=1)
> - Supports "live" input (e.g. from an external source)
> - Supports RGB and YUV444 formats, but not XRGB8888
> - Supports transparency either via
>   - Global alpha channel, which disables per-pixel alpha when enabled
>   - Per-pixel alpha, which cannot be used with global alpha
>   - Chroma keying (colorkey)
> - Must cover the entire screen (translation/resizing not supported)
>
> Currently the graphics plane is the primary plane. Make the video plane
> the primary plane:
>
> - The video plane supports XRGB8888, which is the default 24-bit
>   colorspace for X. This results in improved performance when compared
>   to RGB565.
> - The graphics plane can be used as an overlay because it has a higher
>   z-pos and supports a per-pixel alpha channel. Unfortunately, clients
>   like weston cannot currently take advantage of this because they
>   expect overlay planes to support translation/resizing.
>
> One downside to this approach could be that the graphics plane has worse
> support for YUV and YCBCr, so it may be more difficult to compose video

Not just more difficult but practically impossible:
1. GFX (in Xilinx terminology) plane doesn't support pixel upscaling, so
no support for NV12, YUY2 and other common video pixel formats.
2. Both planes are unscalable, this means we can only output native
display resolution video on the top plane, or display thick black frame
around the picture. We are losing GFX masking capabilities.
3. We won't be able to render subtitles on top of the video.
Probably the only practical video player option remains here is to render
video to a texture and embed it into graphics composition.

> streams into the window of a media player. However, no existing software
> could rely on this because there is no way to enable the per-pixel alpha
> channel when the graphics plane is enabled. This makes it impossible to

This situation is a driver bug not a fatum. Per pixel alpha blending works
just fine if we disable global alpha. We just need to avoid enabling it when
we have alpha capable GFX plane format.

> "carve out" an area in the graphics plane where the video plane shows
> through. This limitation is addressed in the next patch, but it means we
> do not need to worry about compatibility in this area.
>
> An alternate approach could be to pretend that the graphics plane
> supports XRGB8888 by using the supported ARGB8888 mode instead and
> enabling the global alpha channel. However, this would rule out ever
> using the per-pixel alpha channel.
>
> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> ---
>
>  drivers/gpu/drm/xlnx/zynqmp_kms.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> index c80a2d4034f3..456ada9ac003 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> @@ -161,8 +161,8 @@ static int zynqmp_dpsub_create_planes(struct
> zynqmp_dpsub *dpsub)
>                 if (!formats)
>                         return -ENOMEM;
>
> -               /* Graphics layer is primary, and video layer is overlay. */
> -               type = i == ZYNQMP_DPSUB_LAYER_VID
> +               /* Graphics layer is overlay, and video layer is primary. */
> +               type = i == ZYNQMP_DPSUB_LAYER_GFX
>                      ? DRM_PLANE_TYPE_OVERLAY :
> DRM_PLANE_TYPE_PRIMARY;
>                 ret = drm_universal_plane_init(&dpsub->drm->dev, plane, 0,
>                                                &zynqmp_dpsub_plane_funcs,
> @@ -322,7 +322,7 @@ static const struct drm_crtc_funcs
> zynqmp_dpsub_crtc_funcs = {
>
>  static int zynqmp_dpsub_create_crtc(struct zynqmp_dpsub *dpsub)
>  {
> -       struct drm_plane *plane = &dpsub->drm-
> >planes[ZYNQMP_DPSUB_LAYER_GFX];
> +       struct drm_plane *plane = &dpsub->drm-
> >planes[ZYNQMP_DPSUB_LAYER_VID];
>         struct drm_crtc *crtc = &dpsub->drm->crtc;
>         int ret;
>
> --
> 2.35.1.1320.gc452695387.dirty

Thank you,
Anatoliy

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

[Sean Anderson]

On 11/13/25 17:45, Klymenko, Anatoliy wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
> 
> Hi Sean,
> 
> Thanks a lot for the patch (and tackling the alpha issue in general)
> 
>> -----Original Message-----
>> From: Sean Anderson <sean.anderson@linux.dev>
>> Sent: Thursday, November 13, 2025 12:37 PM
>> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
>> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
>> Cc: linux-kernel@vger.kernel.org; Mike Looijmans <mike.looijmans@topic.nl>;
>> David Airlie <airlied@gmail.com>; Thomas Zimmermann
>> <tzimmermann@suse.de>; Maarten Lankhorst
>> <maarten.lankhorst@linux.intel.com>; Klymenko, Anatoliy
>> <Anatoliy.Klymenko@amd.com>; Maxime Ripard <mripard@kernel.org>; linux-
>> arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
>> Michal <michal.simek@amd.com>; Sean Anderson
>> <sean.anderson@linux.dev>
>> Subject: [PATCH 2/3] drm: zynqmp: Make the video plane primary
>>
>> Caution: This message originated from an External Source. Use proper caution
>> when opening attachments, clicking links, or responding.
>>
>>
>> The zynqmp has two planes: "video" and "graphics". The video plane
>>
>> - Is on the bottom (zpos=0) (except when chroma keying as the master plane)
>> - Supports "live" input (e.g. from an external source)
>> - Supports RGB, YUV, and YCbCr formats, including XRGB8888
>> - Does not support transparency, except via chroma keying (colorkey)
>> - Must cover the entire screen (translation/resizing not supported)
>>
>> The graphics plane
>>
>> - Is on the top (zpos=1)
>> - Supports "live" input (e.g. from an external source)
>> - Supports RGB and YUV444 formats, but not XRGB8888
>> - Supports transparency either via
>>   - Global alpha channel, which disables per-pixel alpha when enabled
>>   - Per-pixel alpha, which cannot be used with global alpha
>>   - Chroma keying (colorkey)
>> - Must cover the entire screen (translation/resizing not supported)
>>
>> Currently the graphics plane is the primary plane. Make the video plane
>> the primary plane:
>>
>> - The video plane supports XRGB8888, which is the default 24-bit
>>   colorspace for X. This results in improved performance when compared
>>   to RGB565.
>> - The graphics plane can be used as an overlay because it has a higher
>>   z-pos and supports a per-pixel alpha channel. Unfortunately, clients
>>   like weston cannot currently take advantage of this because they
>>   expect overlay planes to support translation/resizing.
>>
>> One downside to this approach could be that the graphics plane has worse
>> support for YUV and YCBCr, so it may be more difficult to compose video
> 
> Not just more difficult but practically impossible:
> 1. GFX (in Xilinx terminology) plane doesn't support pixel upscaling, so
> no support for NV12, YUY2 and other common video pixel formats.
> 2. Both planes are unscalable, this means we can only output native
> display resolution video on the top plane, or display thick black frame
> around the picture. We are losing GFX masking capabilities.

The graphics masking capabilities are the same as they always were.

> 3. We won't be able to render subtitles on top of the video.
> Probably the only practical video player option remains here is to render
> video to a texture and embed it into graphics composition.

OK, but none of this is currently possible either because of the global
alpha setting. So do you have a specific program in mind that plays
video and will do it with an "underlay" plane?

>> streams into the window of a media player. However, no existing software
>> could rely on this because there is no way to enable the per-pixel alpha
>> channel when the graphics plane is enabled. This makes it impossible to
> 
> This situation is a driver bug not a fatum.

And yet the driver bug provides ample evidence that no one is doing this,
so we don't need to worry about it.

--Sean

> Per pixel alpha blending works
> just fine if we disable global alpha. We just need to avoid enabling it when
> we have alpha capable GFX plane format.
> 
>> "carve out" an area in the graphics plane where the video plane shows
>> through. This limitation is addressed in the next patch, but it means we
>> do not need to worry about compatibility in this area.
>>
>> An alternate approach could be to pretend that the graphics plane
>> supports XRGB8888 by using the supported ARGB8888 mode instead and
>> enabling the global alpha channel. However, this would rule out ever
>> using the per-pixel alpha channel.
>>
>> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
>> ---
>>
>>  drivers/gpu/drm/xlnx/zynqmp_kms.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> b/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> index c80a2d4034f3..456ada9ac003 100644
>> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> @@ -161,8 +161,8 @@ static int zynqmp_dpsub_create_planes(struct
>> zynqmp_dpsub *dpsub)
>>                 if (!formats)
>>                         return -ENOMEM;
>>
>> -               /* Graphics layer is primary, and video layer is overlay. */
>> -               type = i == ZYNQMP_DPSUB_LAYER_VID
>> +               /* Graphics layer is overlay, and video layer is primary. */
>> +               type = i == ZYNQMP_DPSUB_LAYER_GFX
>>                      ? DRM_PLANE_TYPE_OVERLAY :
>> DRM_PLANE_TYPE_PRIMARY;
>>                 ret = drm_universal_plane_init(&dpsub->drm->dev, plane, 0,
>>                                                &zynqmp_dpsub_plane_funcs,
>> @@ -322,7 +322,7 @@ static const struct drm_crtc_funcs
>> zynqmp_dpsub_crtc_funcs = {
>>
>>  static int zynqmp_dpsub_create_crtc(struct zynqmp_dpsub *dpsub)
>>  {
>> -       struct drm_plane *plane = &dpsub->drm-
>> >planes[ZYNQMP_DPSUB_LAYER_GFX];
>> +       struct drm_plane *plane = &dpsub->drm-
>> >planes[ZYNQMP_DPSUB_LAYER_VID];
>>         struct drm_crtc *crtc = &dpsub->drm->crtc;
>>         int ret;
>>
>> --
>> 2.35.1.1320.gc452695387.dirty
> 
> Thank you,
> Anatoliy

RE: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics plane

[Klymenko, Anatoliy]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Sean,

Thank you for the patch.

> -----Original Message-----
> From: Sean Anderson <sean.anderson@linux.dev>
> Sent: Thursday, November 13, 2025 12:37 PM
> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org; Mike Looijmans <mike.looijmans@topic.nl>;
> David Airlie <airlied@gmail.com>; Thomas Zimmermann
> <tzimmermann@suse.de>; Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com>; Klymenko, Anatoliy
> <Anatoliy.Klymenko@amd.com>; Maxime Ripard <mripard@kernel.org>; linux-
> arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
> Michal <michal.simek@amd.com>; Sean Anderson
> <sean.anderson@linux.dev>
> Subject: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics plane
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> When global alpha is enabled, per-pixel alpha is ignored. Allow
> userspace to explicitly specify whether to use per-pixel alpha by
> exposing it through the blend mode property. I'm not sure whether the
> per-pixel alpha is pre-multiplied or not [1], but apparently it *must* be
> pre-multiplied so I guess we have to advertise it.
>
> [1] All we get is "The alpha value available with the graphics stream
>     will define the transparency of the graphics."
>
> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> ---
>
>  drivers/gpu/drm/xlnx/zynqmp_kms.c | 24 ++++++++++++++++++++++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> index 456ada9ac003..fa1cfc16db36 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> @@ -61,6 +61,13 @@ static int zynqmp_dpsub_plane_atomic_check(struct
> drm_plane *plane,
>         if (!new_plane_state->crtc)
>                 return 0;
>
> +       if (new_plane_state->pixel_blend_mode !=
> DRM_MODE_BLEND_PIXEL_NONE &&
> +           new_plane_state->alpha >> 8 != 0xff) {
> +               drm_dbg_kms(plane->dev,
> +                           "Plane alpha must be 1.0 when using pixel alpha\n");
> +               return -EINVAL;
> +       }
> +
>         crtc_state = drm_atomic_get_crtc_state(state, new_plane_state->crtc);
>         if (IS_ERR(crtc_state))
>                 return PTR_ERR(crtc_state);
> @@ -117,9 +124,13 @@ static void
> zynqmp_dpsub_plane_atomic_update(struct drm_plane *plane,
>
>         zynqmp_disp_layer_update(layer, new_state);
>
> -       if (plane->index == ZYNQMP_DPSUB_LAYER_GFX)
> -               zynqmp_disp_blend_set_global_alpha(dpsub->disp, true,
> +       if (plane->index == ZYNQMP_DPSUB_LAYER_GFX) {
> +               bool blend = plane->state->pixel_blend_mode ==
> +                            DRM_MODE_BLEND_PIXEL_NONE;
> +
> +               zynqmp_disp_blend_set_global_alpha(dpsub->disp, blend,
>                                                    plane->state->alpha >> 8);
> +       }
>
>         /*
>          * Unconditionally enable the layer, as it may have been disabled
> @@ -179,9 +190,18 @@ static int zynqmp_dpsub_create_planes(struct
> zynqmp_dpsub *dpsub)
>                         return ret;
>
>                 if (i == ZYNQMP_DPSUB_LAYER_GFX) {
> +                       unsigned int blend_modes =
> +                               BIT(DRM_MODE_BLEND_PIXEL_NONE) |
> +                               BIT(DRM_MODE_BLEND_PREMULTI);

| BIT(DRM_MODE_BLEND_COVERAGE) - this is what implemented in the hardware.

> +
>                         ret = drm_plane_create_alpha_property(plane);
>                         if (ret)
>                                 return ret;
> +
> +                       ret = drm_plane_create_blend_mode_property(plane,
> +                                                                  blend_modes);
> +                       if (ret)
> +                               return ret;
>                 }
>         }
>
> --
> 2.35.1.1320.gc452695387.dirty

Thank you,
Anatoliy

RE: [PATCH 1/3] drm: zynqmp: Check property creation status

[Klymenko, Anatoliy]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Sean,

> -----Original Message-----
> From: Sean Anderson <sean.anderson@linux.dev>
> Sent: Thursday, November 13, 2025 12:37 PM
> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org; Mike Looijmans <mike.looijmans@topic.nl>;
> David Airlie <airlied@gmail.com>; Thomas Zimmermann
> <tzimmermann@suse.de>; Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com>; Klymenko, Anatoliy
> <Anatoliy.Klymenko@amd.com>; Maxime Ripard <mripard@kernel.org>; linux-
> arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
> Michal <michal.simek@amd.com>; Sean Anderson
> <sean.anderson@linux.dev>
> Subject: [PATCH 1/3] drm: zynqmp: Check property creation status
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> Make sure to return an error in the event that we can't create our
> properties.
>
> Fixes: 650f12042b85 ("drm: xlnx: zynqmp_dpsub: Add global alpha support")
> Fixes: 8c772f0b2b8e ("drm: xlnx: zynqmp_dpsub: Expose plane ordering to
> userspace")
>
> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> ---
>
>  drivers/gpu/drm/xlnx/zynqmp_kms.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> index 2bee0a2275ed..c80a2d4034f3 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> @@ -174,9 +174,15 @@ static int zynqmp_dpsub_create_planes(struct
> zynqmp_dpsub *dpsub)
>
>                 drm_plane_helper_add(plane, &zynqmp_dpsub_plane_helper_funcs);
>
> -               drm_plane_create_zpos_immutable_property(plane, i);
> -               if (i == ZYNQMP_DPSUB_LAYER_GFX)
> -                       drm_plane_create_alpha_property(plane);
> +               ret = drm_plane_create_zpos_immutable_property(plane, i);
> +               if (ret)
> +                       return ret;
> +
> +               if (i == ZYNQMP_DPSUB_LAYER_GFX) {
> +                       ret = drm_plane_create_alpha_property(plane);
> +                       if (ret)
> +                               return ret;
> +               }
>         }
>
>         return 0;
> --
> 2.35.1.1320.gc452695387.dirty

Looks good to me.

Reviewed-by: Anatoliy Klymenko <anatoliy.klymenko@amd.com>

Thank you,
Anatoliy

Re: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics plane

[Sean Anderson]

On 11/13/25 18:03, Klymenko, Anatoliy wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
> 
> Hi Sean,
> 
> Thank you for the patch.
> 
>> -----Original Message-----
>> From: Sean Anderson <sean.anderson@linux.dev>
>> Sent: Thursday, November 13, 2025 12:37 PM
>> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
>> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
>> Cc: linux-kernel@vger.kernel.org; Mike Looijmans <mike.looijmans@topic.nl>;
>> David Airlie <airlied@gmail.com>; Thomas Zimmermann
>> <tzimmermann@suse.de>; Maarten Lankhorst
>> <maarten.lankhorst@linux.intel.com>; Klymenko, Anatoliy
>> <Anatoliy.Klymenko@amd.com>; Maxime Ripard <mripard@kernel.org>; linux-
>> arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
>> Michal <michal.simek@amd.com>; Sean Anderson
>> <sean.anderson@linux.dev>
>> Subject: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics plane
>>
>> Caution: This message originated from an External Source. Use proper caution
>> when opening attachments, clicking links, or responding.
>>
>>
>> When global alpha is enabled, per-pixel alpha is ignored. Allow
>> userspace to explicitly specify whether to use per-pixel alpha by
>> exposing it through the blend mode property. I'm not sure whether the
>> per-pixel alpha is pre-multiplied or not [1], but apparently it *must* be
>> pre-multiplied so I guess we have to advertise it.
>>
>> [1] All we get is "The alpha value available with the graphics stream
>>     will define the transparency of the graphics."
>>
>> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
>> ---
>>
>>  drivers/gpu/drm/xlnx/zynqmp_kms.c | 24 ++++++++++++++++++++++--
>>  1 file changed, 22 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> b/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> index 456ada9ac003..fa1cfc16db36 100644
>> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> @@ -61,6 +61,13 @@ static int zynqmp_dpsub_plane_atomic_check(struct
>> drm_plane *plane,
>>         if (!new_plane_state->crtc)
>>                 return 0;
>>
>> +       if (new_plane_state->pixel_blend_mode !=
>> DRM_MODE_BLEND_PIXEL_NONE &&
>> +           new_plane_state->alpha >> 8 != 0xff) {
>> +               drm_dbg_kms(plane->dev,
>> +                           "Plane alpha must be 1.0 when using pixel alpha\n");
>> +               return -EINVAL;
>> +       }
>> +
>>         crtc_state = drm_atomic_get_crtc_state(state, new_plane_state->crtc);
>>         if (IS_ERR(crtc_state))
>>                 return PTR_ERR(crtc_state);
>> @@ -117,9 +124,13 @@ static void
>> zynqmp_dpsub_plane_atomic_update(struct drm_plane *plane,
>>
>>         zynqmp_disp_layer_update(layer, new_state);
>>
>> -       if (plane->index == ZYNQMP_DPSUB_LAYER_GFX)
>> -               zynqmp_disp_blend_set_global_alpha(dpsub->disp, true,
>> +       if (plane->index == ZYNQMP_DPSUB_LAYER_GFX) {
>> +               bool blend = plane->state->pixel_blend_mode ==
>> +                            DRM_MODE_BLEND_PIXEL_NONE;
>> +
>> +               zynqmp_disp_blend_set_global_alpha(dpsub->disp, blend,
>>                                                    plane->state->alpha >> 8);
>> +       }
>>
>>         /*
>>          * Unconditionally enable the layer, as it may have been disabled
>> @@ -179,9 +190,18 @@ static int zynqmp_dpsub_create_planes(struct
>> zynqmp_dpsub *dpsub)
>>                         return ret;
>>
>>                 if (i == ZYNQMP_DPSUB_LAYER_GFX) {
>> +                       unsigned int blend_modes =
>> +                               BIT(DRM_MODE_BLEND_PIXEL_NONE) |
>> +                               BIT(DRM_MODE_BLEND_PREMULTI);
> 
> | BIT(DRM_MODE_BLEND_COVERAGE) - this is what implemented in the hardware.

Do you have a datasheet (or other) reference?

But in any case, DRM_MODE_BLEND_PREMULTI is mandatory even if we don't support
it. See drm_plane_create_blend_mode_property for details.

--Sean

RE: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics plane

[Klymenko, Anatoliy]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Klymenko, Anatoliy
> Sent: Thursday, November 13, 2025 3:04 PM
> To: 'Sean Anderson' <sean.anderson@linux.dev>; Laurent Pinchart
> <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org; Mike Looijmans <mike.looijmans@topic.nl>;
> David Airlie <airlied@gmail.com>; Thomas Zimmermann
> <tzimmermann@suse.de>; Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com>; Maxime Ripard <mripard@kernel.org>;
> linux-arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
> Michal <michal.simek@amd.com>
> Subject: RE: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics
> plane
>
> Hi Sean,
>
> Thank you for the patch.
>
> > -----Original Message-----
> > From: Sean Anderson <sean.anderson@linux.dev>
> > Sent: Thursday, November 13, 2025 12:37 PM
> > To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
> > <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
> > Cc: linux-kernel@vger.kernel.org; Mike Looijmans <mike.looijmans@topic.nl>;
> > David Airlie <airlied@gmail.com>; Thomas Zimmermann
> > <tzimmermann@suse.de>; Maarten Lankhorst
> > <maarten.lankhorst@linux.intel.com>; Klymenko, Anatoliy
> > <Anatoliy.Klymenko@amd.com>; Maxime Ripard <mripard@kernel.org>;
> linux-
> > arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
> > Michal <michal.simek@amd.com>; Sean Anderson
> > <sean.anderson@linux.dev>
> > Subject: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics
> plane
> >
> > Caution: This message originated from an External Source. Use proper
> caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > When global alpha is enabled, per-pixel alpha is ignored. Allow
> > userspace to explicitly specify whether to use per-pixel alpha by
> > exposing it through the blend mode property. I'm not sure whether the
> > per-pixel alpha is pre-multiplied or not [1], but apparently it *must* be
> > pre-multiplied so I guess we have to advertise it.
> >
> > [1] All we get is "The alpha value available with the graphics stream
> >     will define the transparency of the graphics."
> >
> > Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> > ---
> >
> >  drivers/gpu/drm/xlnx/zynqmp_kms.c | 24 ++++++++++++++++++++++--
> >  1 file changed, 22 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> > b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> > index 456ada9ac003..fa1cfc16db36 100644
> > --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> > +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> > @@ -61,6 +61,13 @@ static int zynqmp_dpsub_plane_atomic_check(struct
> > drm_plane *plane,
> >         if (!new_plane_state->crtc)
> >                 return 0;
> >
> > +       if (new_plane_state->pixel_blend_mode !=
> > DRM_MODE_BLEND_PIXEL_NONE &&
> > +           new_plane_state->alpha >> 8 != 0xff) {
> > +               drm_dbg_kms(plane->dev,
> > +                           "Plane alpha must be 1.0 when using pixel alpha\n");
> > +               return -EINVAL;
> > +       }
> > +
> >         crtc_state = drm_atomic_get_crtc_state(state, new_plane_state->crtc);
> >         if (IS_ERR(crtc_state))
> >                 return PTR_ERR(crtc_state);
> > @@ -117,9 +124,13 @@ static void
> > zynqmp_dpsub_plane_atomic_update(struct drm_plane *plane,
> >
> >         zynqmp_disp_layer_update(layer, new_state);
> >
> > -       if (plane->index == ZYNQMP_DPSUB_LAYER_GFX)
> > -               zynqmp_disp_blend_set_global_alpha(dpsub->disp, true,
> > +       if (plane->index == ZYNQMP_DPSUB_LAYER_GFX) {
> > +               bool blend = plane->state->pixel_blend_mode ==
> > +                            DRM_MODE_BLEND_PIXEL_NONE;

I would suggest adding
|| !plane->state->fb->format->has_alpha;
pixel_blend_mode doesn't make a lot of sense for non-alpha formats but may
have a negative effect on Mike's fix
https://lore.kernel.org/dri-devel/20250627145058.6880-1-mike.looijmans@topic.nl/
if user isn't careful enough around this property.

> > +
> > +               zynqmp_disp_blend_set_global_alpha(dpsub->disp, blend,
> >                                                    plane->state->alpha >> 8);
> > +       }
> >
> >         /*
> >          * Unconditionally enable the layer, as it may have been disabled
> > @@ -179,9 +190,18 @@ static int zynqmp_dpsub_create_planes(struct
> > zynqmp_dpsub *dpsub)
> >                         return ret;
> >
> >                 if (i == ZYNQMP_DPSUB_LAYER_GFX) {
> > +                       unsigned int blend_modes =
> > +                               BIT(DRM_MODE_BLEND_PIXEL_NONE) |
> > +                               BIT(DRM_MODE_BLEND_PREMULTI);
>
> | BIT(DRM_MODE_BLEND_COVERAGE) - this is what implemented in the
> hardware.
>
> > +
> >                         ret = drm_plane_create_alpha_property(plane);
> >                         if (ret)
> >                                 return ret;
> > +
> > +                       ret = drm_plane_create_blend_mode_property(plane,
> > +                                                                  blend_modes);
> > +                       if (ret)
> > +                               return ret;
> >                 }
> >         }
> >
> > --
> > 2.35.1.1320.gc452695387.dirty
>
> Thank you,
> Anatoliy

Thank you,
Anatoliy

Re: [PATCH 1/3] drm: zynqmp: Check property creation status

[Thomas Zimmermann]

Am 13.11.25 um 21:37 schrieb Sean Anderson:
> Make sure to return an error in the event that we can't create our
> properties.
>
> Fixes: 650f12042b85 ("drm: xlnx: zynqmp_dpsub: Add global alpha support")
> Fixes: 8c772f0b2b8e ("drm: xlnx: zynqmp_dpsub: Expose plane ordering to userspace")
>
> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>

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

> ---
>
>   drivers/gpu/drm/xlnx/zynqmp_kms.c | 12 +++++++++---
>   1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> index 2bee0a2275ed..c80a2d4034f3 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> @@ -174,9 +174,15 @@ static int zynqmp_dpsub_create_planes(struct zynqmp_dpsub *dpsub)
>   
>   		drm_plane_helper_add(plane, &zynqmp_dpsub_plane_helper_funcs);
>   
> -		drm_plane_create_zpos_immutable_property(plane, i);
> -		if (i == ZYNQMP_DPSUB_LAYER_GFX)
> -			drm_plane_create_alpha_property(plane);
> +		ret = drm_plane_create_zpos_immutable_property(plane, i);
> +		if (ret)
> +			return ret;
> +
> +		if (i == ZYNQMP_DPSUB_LAYER_GFX) {
> +			ret = drm_plane_create_alpha_property(plane);
> +			if (ret)
> +				return ret;
> +		}
>   	}
>   
>   	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)

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

[Thomas Zimmermann]

Hi

Am 13.11.25 um 21:37 schrieb Sean Anderson:
> 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.

Did you try to set drm_device.mode_config.preferred_depth = 16, like at 
[1]?  IIRC user space looks at this value to auto-detect the color format.

[1] 
https://elixir.bootlin.com/linux/v6.17.7/source/drivers/gpu/drm/tiny/cirrus-qemu.c#L542

Best regards
Thomas

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

-- 
--
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/3] drm: zynqmp: Make the video plane primary

[Sean Anderson]

Hi Thomas,

On 11/14/25 02:42, Thomas Zimmermann wrote:
> Hi
> 
> Am 13.11.25 um 21:37 schrieb Sean Anderson:
>> 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.
> 
> Did you try to set drm_device.mode_config.preferred_depth = 16, like at [1]?  IIRC user space looks at this value to auto-detect the color format.

I have not tried that. But I would rather use 24-bit color for the performance boost.

--Sean

Re: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics plane

[Sean Anderson]

On 11/13/25 18:59, Klymenko, Anatoliy wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
> 
>> -----Original Message-----
>> From: Klymenko, Anatoliy
>> Sent: Thursday, November 13, 2025 3:04 PM
>> To: 'Sean Anderson' <sean.anderson@linux.dev>; Laurent Pinchart
>> <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
>> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
>> Cc: linux-kernel@vger.kernel.org; Mike Looijmans <mike.looijmans@topic.nl>;
>> David Airlie <airlied@gmail.com>; Thomas Zimmermann
>> <tzimmermann@suse.de>; Maarten Lankhorst
>> <maarten.lankhorst@linux.intel.com>; Maxime Ripard <mripard@kernel.org>;
>> linux-arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
>> Michal <michal.simek@amd.com>
>> Subject: RE: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics
>> plane
>>
>> Hi Sean,
>>
>> Thank you for the patch.
>>
>> > -----Original Message-----
>> > From: Sean Anderson <sean.anderson@linux.dev>
>> > Sent: Thursday, November 13, 2025 12:37 PM
>> > To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
>> > <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
>> > Cc: linux-kernel@vger.kernel.org; Mike Looijmans <mike.looijmans@topic.nl>;
>> > David Airlie <airlied@gmail.com>; Thomas Zimmermann
>> > <tzimmermann@suse.de>; Maarten Lankhorst
>> > <maarten.lankhorst@linux.intel.com>; Klymenko, Anatoliy
>> > <Anatoliy.Klymenko@amd.com>; Maxime Ripard <mripard@kernel.org>;
>> linux-
>> > arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
>> > Michal <michal.simek@amd.com>; Sean Anderson
>> > <sean.anderson@linux.dev>
>> > Subject: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics
>> plane
>> >
>> > Caution: This message originated from an External Source. Use proper
>> caution
>> > when opening attachments, clicking links, or responding.
>> >
>> >
>> > When global alpha is enabled, per-pixel alpha is ignored. Allow
>> > userspace to explicitly specify whether to use per-pixel alpha by
>> > exposing it through the blend mode property. I'm not sure whether the
>> > per-pixel alpha is pre-multiplied or not [1], but apparently it *must* be
>> > pre-multiplied so I guess we have to advertise it.
>> >
>> > [1] All we get is "The alpha value available with the graphics stream
>> >     will define the transparency of the graphics."
>> >
>> > Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
>> > ---
>> >
>> >  drivers/gpu/drm/xlnx/zynqmp_kms.c | 24 ++++++++++++++++++++++--
>> >  1 file changed, 22 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> > b/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> > index 456ada9ac003..fa1cfc16db36 100644
>> > --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> > +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> > @@ -61,6 +61,13 @@ static int zynqmp_dpsub_plane_atomic_check(struct
>> > drm_plane *plane,
>> >         if (!new_plane_state->crtc)
>> >                 return 0;
>> >
>> > +       if (new_plane_state->pixel_blend_mode !=
>> > DRM_MODE_BLEND_PIXEL_NONE &&
>> > +           new_plane_state->alpha >> 8 != 0xff) {
>> > +               drm_dbg_kms(plane->dev,
>> > +                           "Plane alpha must be 1.0 when using pixel alpha\n");
>> > +               return -EINVAL;
>> > +       }
>> > +
>> >         crtc_state = drm_atomic_get_crtc_state(state, new_plane_state->crtc);
>> >         if (IS_ERR(crtc_state))
>> >                 return PTR_ERR(crtc_state);
>> > @@ -117,9 +124,13 @@ static void
>> > zynqmp_dpsub_plane_atomic_update(struct drm_plane *plane,
>> >
>> >         zynqmp_disp_layer_update(layer, new_state);
>> >
>> > -       if (plane->index == ZYNQMP_DPSUB_LAYER_GFX)
>> > -               zynqmp_disp_blend_set_global_alpha(dpsub->disp, true,
>> > +       if (plane->index == ZYNQMP_DPSUB_LAYER_GFX) {
>> > +               bool blend = plane->state->pixel_blend_mode ==
>> > +                            DRM_MODE_BLEND_PIXEL_NONE;
> 
> I would suggest adding
> || !plane->state->fb->format->has_alpha;
> pixel_blend_mode doesn't make a lot of sense for non-alpha formats but may
> have a negative effect on Mike's fix
> https://lore.kernel.org/dri-devel/20250627145058.6880-1-mike.looijmans@topic.nl/
> if user isn't careful enough around this property.

I don't believe that patch should be applied.

--Sean

>> > +
>> > +               zynqmp_disp_blend_set_global_alpha(dpsub->disp, blend,
>> >                                                    plane->state->alpha >> 8);
>> > +       }
>> >
>> >         /*
>> >          * Unconditionally enable the layer, as it may have been disabled
>> > @@ -179,9 +190,18 @@ static int zynqmp_dpsub_create_planes(struct
>> > zynqmp_dpsub *dpsub)
>> >                         return ret;
>> >
>> >                 if (i == ZYNQMP_DPSUB_LAYER_GFX) {
>> > +                       unsigned int blend_modes =
>> > +                               BIT(DRM_MODE_BLEND_PIXEL_NONE) |
>> > +                               BIT(DRM_MODE_BLEND_PREMULTI);
>>
>> | BIT(DRM_MODE_BLEND_COVERAGE) - this is what implemented in the
>> hardware.
>>
>> > +
>> >                         ret = drm_plane_create_alpha_property(plane);
>> >                         if (ret)
>> >                                 return ret;
>> > +
>> > +                       ret = drm_plane_create_blend_mode_property(plane,
>> > +                                                                  blend_modes);
>> > +                       if (ret)
>> > +                               return ret;
>> >                 }
>> >         }
>> >
>> > --
>> > 2.35.1.1320.gc452695387.dirty
>>
>> Thank you,
>> Anatoliy
> 
> Thank you,
> Anatoliy
> 

RE: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics plane

[Klymenko, Anatoliy]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Sean
> Anderson
> Sent: Thursday, November 13, 2025 3:07 PM
> To: Klymenko, Anatoliy <Anatoliy.Klymenko@amd.com>; Laurent Pinchart
> <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org; Mike Looijmans <mike.looijmans@topic.nl>;
> David Airlie <airlied@gmail.com>; Thomas Zimmermann
> <tzimmermann@suse.de>; Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com>; Maxime Ripard <mripard@kernel.org>;
> linux-arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
> Michal <michal.simek@amd.com>
> Subject: Re: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics
> plane
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 11/13/25 18:03, Klymenko, Anatoliy wrote:
> > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> > Hi Sean,
> >
> > Thank you for the patch.
> >
> >> -----Original Message-----
> >> From: Sean Anderson <sean.anderson@linux.dev>
> >> Sent: Thursday, November 13, 2025 12:37 PM
> >> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
> >> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
> >> Cc: linux-kernel@vger.kernel.org; Mike Looijmans
> <mike.looijmans@topic.nl>;
> >> David Airlie <airlied@gmail.com>; Thomas Zimmermann
> >> <tzimmermann@suse.de>; Maarten Lankhorst
> >> <maarten.lankhorst@linux.intel.com>; Klymenko, Anatoliy
> >> <Anatoliy.Klymenko@amd.com>; Maxime Ripard <mripard@kernel.org>;
> linux-
> >> arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
> >> Michal <michal.simek@amd.com>; Sean Anderson
> >> <sean.anderson@linux.dev>
> >> Subject: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics
> plane
> >>
> >> Caution: This message originated from an External Source. Use proper
> caution
> >> when opening attachments, clicking links, or responding.
> >>
> >>
> >> When global alpha is enabled, per-pixel alpha is ignored. Allow
> >> userspace to explicitly specify whether to use per-pixel alpha by
> >> exposing it through the blend mode property. I'm not sure whether the
> >> per-pixel alpha is pre-multiplied or not [1], but apparently it *must* be
> >> pre-multiplied so I guess we have to advertise it.
> >>
> >> [1] All we get is "The alpha value available with the graphics stream
> >>     will define the transparency of the graphics."
> >>
> >> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> >> ---
> >>
> >>  drivers/gpu/drm/xlnx/zynqmp_kms.c | 24 ++++++++++++++++++++++--
> >>  1 file changed, 22 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> >> b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> >> index 456ada9ac003..fa1cfc16db36 100644
> >> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> >> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> >> @@ -61,6 +61,13 @@ static int zynqmp_dpsub_plane_atomic_check(struct
> >> drm_plane *plane,
> >>         if (!new_plane_state->crtc)
> >>                 return 0;
> >>
> >> +       if (new_plane_state->pixel_blend_mode !=
> >> DRM_MODE_BLEND_PIXEL_NONE &&
> >> +           new_plane_state->alpha >> 8 != 0xff) {
> >> +               drm_dbg_kms(plane->dev,
> >> +                           "Plane alpha must be 1.0 when using pixel alpha\n");
> >> +               return -EINVAL;
> >> +       }
> >> +
> >>         crtc_state = drm_atomic_get_crtc_state(state, new_plane_state->crtc);
> >>         if (IS_ERR(crtc_state))
> >>                 return PTR_ERR(crtc_state);
> >> @@ -117,9 +124,13 @@ static void
> >> zynqmp_dpsub_plane_atomic_update(struct drm_plane *plane,
> >>
> >>         zynqmp_disp_layer_update(layer, new_state);
> >>
> >> -       if (plane->index == ZYNQMP_DPSUB_LAYER_GFX)
> >> -               zynqmp_disp_blend_set_global_alpha(dpsub->disp, true,
> >> +       if (plane->index == ZYNQMP_DPSUB_LAYER_GFX) {
> >> +               bool blend = plane->state->pixel_blend_mode ==
> >> +                            DRM_MODE_BLEND_PIXEL_NONE;
> >> +
> >> +               zynqmp_disp_blend_set_global_alpha(dpsub->disp, blend,
> >>                                                    plane->state->alpha >> 8);
> >> +       }
> >>
> >>         /*
> >>          * Unconditionally enable the layer, as it may have been disabled
> >> @@ -179,9 +190,18 @@ static int zynqmp_dpsub_create_planes(struct
> >> zynqmp_dpsub *dpsub)
> >>                         return ret;
> >>
> >>                 if (i == ZYNQMP_DPSUB_LAYER_GFX) {
> >> +                       unsigned int blend_modes =
> >> +                               BIT(DRM_MODE_BLEND_PIXEL_NONE) |
> >> +                               BIT(DRM_MODE_BLEND_PREMULTI);
> >
> > | BIT(DRM_MODE_BLEND_COVERAGE) - this is what implemented in the
> hardware.
>
> Do you have a datasheet (or other) reference?
>

Yes https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm


> But in any case, DRM_MODE_BLEND_PREMULTI is mandatory even if we
> don't support
> it. See drm_plane_create_blend_mode_property for details.
>

No doubts here

> --Sean

Thank you,
Anatoliy

RE: [PATCH 2/3] drm: zynqmp: Make the video plane primary

[Klymenko, Anatoliy]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Sean
> Anderson
> Sent: Thursday, November 13, 2025 2:52 PM
> To: Klymenko, Anatoliy <Anatoliy.Klymenko@amd.com>; Laurent Pinchart
> <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org; Mike Looijmans <mike.looijmans@topic.nl>;
> David Airlie <airlied@gmail.com>; Thomas Zimmermann
> <tzimmermann@suse.de>; Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com>; Maxime Ripard <mripard@kernel.org>;
> linux-arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
> Michal <michal.simek@amd.com>
> Subject: Re: [PATCH 2/3] drm: zynqmp: Make the video plane primary
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 11/13/25 17:45, Klymenko, Anatoliy wrote:
> > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> > Hi Sean,
> >
> > Thanks a lot for the patch (and tackling the alpha issue in general)
> >
> >> -----Original Message-----
> >> From: Sean Anderson <sean.anderson@linux.dev>
> >> Sent: Thursday, November 13, 2025 12:37 PM
> >> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
> >> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
> >> Cc: linux-kernel@vger.kernel.org; Mike Looijmans
> <mike.looijmans@topic.nl>;
> >> David Airlie <airlied@gmail.com>; Thomas Zimmermann
> >> <tzimmermann@suse.de>; Maarten Lankhorst
> >> <maarten.lankhorst@linux.intel.com>; Klymenko, Anatoliy
> >> <Anatoliy.Klymenko@amd.com>; Maxime Ripard <mripard@kernel.org>;
> linux-
> >> arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
> >> Michal <michal.simek@amd.com>; Sean Anderson
> >> <sean.anderson@linux.dev>
> >> Subject: [PATCH 2/3] drm: zynqmp: Make the video plane primary
> >>
> >> Caution: This message originated from an External Source. Use proper
> caution
> >> when opening attachments, clicking links, or responding.
> >>
> >>
> >> The zynqmp has two planes: "video" and "graphics". The video plane
> >>
> >> - Is on the bottom (zpos=0) (except when chroma keying as the master
> plane)
> >> - Supports "live" input (e.g. from an external source)
> >> - Supports RGB, YUV, and YCbCr formats, including XRGB8888
> >> - Does not support transparency, except via chroma keying (colorkey)
> >> - Must cover the entire screen (translation/resizing not supported)
> >>
> >> The graphics plane
> >>
> >> - Is on the top (zpos=1)
> >> - Supports "live" input (e.g. from an external source)
> >> - Supports RGB and YUV444 formats, but not XRGB8888
> >> - Supports transparency either via
> >>   - Global alpha channel, which disables per-pixel alpha when enabled
> >>   - Per-pixel alpha, which cannot be used with global alpha
> >>   - Chroma keying (colorkey)
> >> - Must cover the entire screen (translation/resizing not supported)
> >>
> >> Currently the graphics plane is the primary plane. Make the video plane
> >> the primary plane:
> >>
> >> - The video plane supports XRGB8888, which is the default 24-bit
> >>   colorspace for X. This results in improved performance when compared
> >>   to RGB565.
> >> - The graphics plane can be used as an overlay because it has a higher
> >>   z-pos and supports a per-pixel alpha channel. Unfortunately, clients
> >>   like weston cannot currently take advantage of this because they
> >>   expect overlay planes to support translation/resizing.
> >>
> >> One downside to this approach could be that the graphics plane has worse
> >> support for YUV and YCBCr, so it may be more difficult to compose video
> >
> > Not just more difficult but practically impossible:
> > 1. GFX (in Xilinx terminology) plane doesn't support pixel upscaling, so
> > no support for NV12, YUY2 and other common video pixel formats.
> > 2. Both planes are unscalable, this means we can only output native
> > display resolution video on the top plane, or display thick black frame
> > around the picture. We are losing GFX masking capabilities.
>
> The graphics masking capabilities are the same as they always were.
>
> > 3. We won't be able to render subtitles on top of the video.
> > Probably the only practical video player option remains here is to render
> > video to a texture and embed it into graphics composition.
>
> OK, but none of this is currently possible either because of the global
> alpha setting. So do you have a specific program in mind that plays
> video and will do it with an "underlay" plane?
>

webOS, Roku OS, just to name a few. But most importantly, AMD has quite
a few customers using "underlay" plane because of its YUV 420 capability.

> >> streams into the window of a media player. However, no existing software
> >> could rely on this because there is no way to enable the per-pixel alpha
> >> channel when the graphics plane is enabled. This makes it impossible to
> >
> > This situation is a driver bug not a fatum.
>
> And yet the driver bug provides ample evidence that no one is doing this,
> so we don't need to worry about it.
>
> --Sean
>
> > Per pixel alpha blending works
> > just fine if we disable global alpha. We just need to avoid enabling it when
> > we have alpha capable GFX plane format.
> >
> >> "carve out" an area in the graphics plane where the video plane shows
> >> through. This limitation is addressed in the next patch, but it means we
> >> do not need to worry about compatibility in this area.
> >>
> >> An alternate approach could be to pretend that the graphics plane
> >> supports XRGB8888 by using the supported ARGB8888 mode instead and
> >> enabling the global alpha channel. However, this would rule out ever
> >> using the per-pixel alpha channel.
> >>
> >> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> >> ---
> >>
> >>  drivers/gpu/drm/xlnx/zynqmp_kms.c | 6 +++---
> >>  1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> >> b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> >> index c80a2d4034f3..456ada9ac003 100644
> >> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> >> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> >> @@ -161,8 +161,8 @@ static int zynqmp_dpsub_create_planes(struct
> >> zynqmp_dpsub *dpsub)
> >>                 if (!formats)
> >>                         return -ENOMEM;
> >>
> >> -               /* Graphics layer is primary, and video layer is overlay. */
> >> -               type = i == ZYNQMP_DPSUB_LAYER_VID
> >> +               /* Graphics layer is overlay, and video layer is primary. */
> >> +               type = i == ZYNQMP_DPSUB_LAYER_GFX
> >>                      ? DRM_PLANE_TYPE_OVERLAY :
> >> DRM_PLANE_TYPE_PRIMARY;
> >>                 ret = drm_universal_plane_init(&dpsub->drm->dev, plane, 0,
> >>                                                &zynqmp_dpsub_plane_funcs,
> >> @@ -322,7 +322,7 @@ static const struct drm_crtc_funcs
> >> zynqmp_dpsub_crtc_funcs = {
> >>
> >>  static int zynqmp_dpsub_create_crtc(struct zynqmp_dpsub *dpsub)
> >>  {
> >> -       struct drm_plane *plane = &dpsub->drm-
> >> >planes[ZYNQMP_DPSUB_LAYER_GFX];
> >> +       struct drm_plane *plane = &dpsub->drm-
> >> >planes[ZYNQMP_DPSUB_LAYER_VID];
> >>         struct drm_crtc *crtc = &dpsub->drm->crtc;
> >>         int ret;
> >>
> >> --
> >> 2.35.1.1320.gc452695387.dirty
> >
> > Thank you,
> > Anatoliy

Thank you,
Anatoliy

Re: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics plane

[Sean Anderson]

On 11/14/25 19:12, Klymenko, Anatoliy wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
> 
>> -----Original Message-----
>> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Sean
>> Anderson
>> Sent: Thursday, November 13, 2025 3:07 PM
>> To: Klymenko, Anatoliy <Anatoliy.Klymenko@amd.com>; Laurent Pinchart
>> <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
>> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
>> Cc: linux-kernel@vger.kernel.org; Mike Looijmans <mike.looijmans@topic.nl>;
>> David Airlie <airlied@gmail.com>; Thomas Zimmermann
>> <tzimmermann@suse.de>; Maarten Lankhorst
>> <maarten.lankhorst@linux.intel.com>; Maxime Ripard <mripard@kernel.org>;
>> linux-arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
>> Michal <michal.simek@amd.com>
>> Subject: Re: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics
>> plane
>>
>> Caution: This message originated from an External Source. Use proper caution
>> when opening attachments, clicking links, or responding.
>>
>>
>> On 11/13/25 18:03, Klymenko, Anatoliy wrote:
>> > [AMD Official Use Only - AMD Internal Distribution Only]
>> >
>> > Hi Sean,
>> >
>> > Thank you for the patch.
>> >
>> >> -----Original Message-----
>> >> From: Sean Anderson <sean.anderson@linux.dev>
>> >> Sent: Thursday, November 13, 2025 12:37 PM
>> >> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
>> >> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
>> >> Cc: linux-kernel@vger.kernel.org; Mike Looijmans
>> <mike.looijmans@topic.nl>;
>> >> David Airlie <airlied@gmail.com>; Thomas Zimmermann
>> >> <tzimmermann@suse.de>; Maarten Lankhorst
>> >> <maarten.lankhorst@linux.intel.com>; Klymenko, Anatoliy
>> >> <Anatoliy.Klymenko@amd.com>; Maxime Ripard <mripard@kernel.org>;
>> linux-
>> >> arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
>> >> Michal <michal.simek@amd.com>; Sean Anderson
>> >> <sean.anderson@linux.dev>
>> >> Subject: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics
>> plane
>> >>
>> >> Caution: This message originated from an External Source. Use proper
>> caution
>> >> when opening attachments, clicking links, or responding.
>> >>
>> >>
>> >> When global alpha is enabled, per-pixel alpha is ignored. Allow
>> >> userspace to explicitly specify whether to use per-pixel alpha by
>> >> exposing it through the blend mode property. I'm not sure whether the
>> >> per-pixel alpha is pre-multiplied or not [1], but apparently it *must* be
>> >> pre-multiplied so I guess we have to advertise it.
>> >>
>> >> [1] All we get is "The alpha value available with the graphics stream
>> >>     will define the transparency of the graphics."
>> >>
>> >> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
>> >> ---
>> >>
>> >>  drivers/gpu/drm/xlnx/zynqmp_kms.c | 24 ++++++++++++++++++++++--
>> >>  1 file changed, 22 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> >> b/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> >> index 456ada9ac003..fa1cfc16db36 100644
>> >> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> >> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> >> @@ -61,6 +61,13 @@ static int zynqmp_dpsub_plane_atomic_check(struct
>> >> drm_plane *plane,
>> >>         if (!new_plane_state->crtc)
>> >>                 return 0;
>> >>
>> >> +       if (new_plane_state->pixel_blend_mode !=
>> >> DRM_MODE_BLEND_PIXEL_NONE &&
>> >> +           new_plane_state->alpha >> 8 != 0xff) {
>> >> +               drm_dbg_kms(plane->dev,
>> >> +                           "Plane alpha must be 1.0 when using pixel alpha\n");
>> >> +               return -EINVAL;
>> >> +       }
>> >> +
>> >>         crtc_state = drm_atomic_get_crtc_state(state, new_plane_state->crtc);
>> >>         if (IS_ERR(crtc_state))
>> >>                 return PTR_ERR(crtc_state);
>> >> @@ -117,9 +124,13 @@ static void
>> >> zynqmp_dpsub_plane_atomic_update(struct drm_plane *plane,
>> >>
>> >>         zynqmp_disp_layer_update(layer, new_state);
>> >>
>> >> -       if (plane->index == ZYNQMP_DPSUB_LAYER_GFX)
>> >> -               zynqmp_disp_blend_set_global_alpha(dpsub->disp, true,
>> >> +       if (plane->index == ZYNQMP_DPSUB_LAYER_GFX) {
>> >> +               bool blend = plane->state->pixel_blend_mode ==
>> >> +                            DRM_MODE_BLEND_PIXEL_NONE;
>> >> +
>> >> +               zynqmp_disp_blend_set_global_alpha(dpsub->disp, blend,
>> >>                                                    plane->state->alpha >> 8);
>> >> +       }
>> >>
>> >>         /*
>> >>          * Unconditionally enable the layer, as it may have been disabled
>> >> @@ -179,9 +190,18 @@ static int zynqmp_dpsub_create_planes(struct
>> >> zynqmp_dpsub *dpsub)
>> >>                         return ret;
>> >>
>> >>                 if (i == ZYNQMP_DPSUB_LAYER_GFX) {
>> >> +                       unsigned int blend_modes =
>> >> +                               BIT(DRM_MODE_BLEND_PIXEL_NONE) |
>> >> +                               BIT(DRM_MODE_BLEND_PREMULTI);
>> >
>> > | BIT(DRM_MODE_BLEND_COVERAGE) - this is what implemented in the
>> hardware.
>>
>> Do you have a datasheet (or other) reference?
>>
> 
> Yes https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm

There is no mention of this in the TRM.

| Video Blending is defined for two RGB video streams. One of these
| streams will be graphics that have an alpha value along with RGB
| stream. The alpha value available with the graphics stream will define
| the transparency of the graphics. Alpha value defined for blending
| function is always 8-bit. 1-bit alpha and 4-bit alpha are also
| supported, but these are scaled to 8-bits before they are used for
| alpha blending

Please quote a specific section where the alpha blending formula is
documented.

>> But in any case, DRM_MODE_BLEND_PREMULTI is mandatory even if we
>> don't support
>> it. See drm_plane_create_blend_mode_property for details.
>>
> 
> No doubts here

OK, so regardless of what the hardware does, we have to pretend to
support pre-multiplied alpha.

--Sean

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

[Sean Anderson]

On 11/14/25 19:57, Klymenko, Anatoliy wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
> 
>> -----Original Message-----
>> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Sean
>> Anderson
>> Sent: Thursday, November 13, 2025 2:52 PM
>> To: Klymenko, Anatoliy <Anatoliy.Klymenko@amd.com>; Laurent Pinchart
>> <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
>> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
>> Cc: linux-kernel@vger.kernel.org; Mike Looijmans <mike.looijmans@topic.nl>;
>> David Airlie <airlied@gmail.com>; Thomas Zimmermann
>> <tzimmermann@suse.de>; Maarten Lankhorst
>> <maarten.lankhorst@linux.intel.com>; Maxime Ripard <mripard@kernel.org>;
>> linux-arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
>> Michal <michal.simek@amd.com>
>> Subject: Re: [PATCH 2/3] drm: zynqmp: Make the video plane primary
>>
>> Caution: This message originated from an External Source. Use proper caution
>> when opening attachments, clicking links, or responding.
>>
>>
>> On 11/13/25 17:45, Klymenko, Anatoliy wrote:
>> > [AMD Official Use Only - AMD Internal Distribution Only]
>> >
>> > Hi Sean,
>> >
>> > Thanks a lot for the patch (and tackling the alpha issue in general)
>> >
>> >> -----Original Message-----
>> >> From: Sean Anderson <sean.anderson@linux.dev>
>> >> Sent: Thursday, November 13, 2025 12:37 PM
>> >> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
>> >> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
>> >> Cc: linux-kernel@vger.kernel.org; Mike Looijmans
>> <mike.looijmans@topic.nl>;
>> >> David Airlie <airlied@gmail.com>; Thomas Zimmermann
>> >> <tzimmermann@suse.de>; Maarten Lankhorst
>> >> <maarten.lankhorst@linux.intel.com>; Klymenko, Anatoliy
>> >> <Anatoliy.Klymenko@amd.com>; Maxime Ripard <mripard@kernel.org>;
>> linux-
>> >> arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
>> >> Michal <michal.simek@amd.com>; Sean Anderson
>> >> <sean.anderson@linux.dev>
>> >> Subject: [PATCH 2/3] drm: zynqmp: Make the video plane primary
>> >>
>> >> Caution: This message originated from an External Source. Use proper
>> caution
>> >> when opening attachments, clicking links, or responding.
>> >>
>> >>
>> >> The zynqmp has two planes: "video" and "graphics". The video plane
>> >>
>> >> - Is on the bottom (zpos=0) (except when chroma keying as the master
>> plane)
>> >> - Supports "live" input (e.g. from an external source)
>> >> - Supports RGB, YUV, and YCbCr formats, including XRGB8888
>> >> - Does not support transparency, except via chroma keying (colorkey)
>> >> - Must cover the entire screen (translation/resizing not supported)
>> >>
>> >> The graphics plane
>> >>
>> >> - Is on the top (zpos=1)
>> >> - Supports "live" input (e.g. from an external source)
>> >> - Supports RGB and YUV444 formats, but not XRGB8888
>> >> - Supports transparency either via
>> >>   - Global alpha channel, which disables per-pixel alpha when enabled
>> >>   - Per-pixel alpha, which cannot be used with global alpha
>> >>   - Chroma keying (colorkey)
>> >> - Must cover the entire screen (translation/resizing not supported)
>> >>
>> >> Currently the graphics plane is the primary plane. Make the video plane
>> >> the primary plane:
>> >>
>> >> - The video plane supports XRGB8888, which is the default 24-bit
>> >>   colorspace for X. This results in improved performance when compared
>> >>   to RGB565.
>> >> - The graphics plane can be used as an overlay because it has a higher
>> >>   z-pos and supports a per-pixel alpha channel. Unfortunately, clients
>> >>   like weston cannot currently take advantage of this because they
>> >>   expect overlay planes to support translation/resizing.
>> >>
>> >> One downside to this approach could be that the graphics plane has worse
>> >> support for YUV and YCBCr, so it may be more difficult to compose video
>> >
>> > Not just more difficult but practically impossible:
>> > 1. GFX (in Xilinx terminology) plane doesn't support pixel upscaling, so
>> > no support for NV12, YUY2 and other common video pixel formats.
>> > 2. Both planes are unscalable, this means we can only output native
>> > display resolution video on the top plane, or display thick black frame
>> > around the picture. We are losing GFX masking capabilities.
>>
>> The graphics masking capabilities are the same as they always were.
>>
>> > 3. We won't be able to render subtitles on top of the video.
>> > Probably the only practical video player option remains here is to render
>> > video to a texture and embed it into graphics composition.
>>
>> OK, but none of this is currently possible either because of the global
>> alpha setting. So do you have a specific program in mind that plays
>> video and will do it with an "underlay" plane?
>>
> 
> webOS, Roku OS, just to name a few. But most importantly, AMD has quite
> a few customers using "underlay" plane because of its YUV 420 capability.

Can you link to a specific example where the plane is selected based on
its primary/overlay status and not based on its format support?  I'm not
too familiar with these distros, but e.g. [1] selects the plane based on
the format, and doesn't care which one is primary.

--Sean

[1] https://github.com/webosose/omx-components/blob/27b33e17c25023f2c7ffbbfda10169fb500dacdc/src/omxdrm/videorenderer.cpp#L469

>> >> streams into the window of a media player. However, no existing software
>> >> could rely on this because there is no way to enable the per-pixel alpha
>> >> channel when the graphics plane is enabled. This makes it impossible to
>> >
>> > This situation is a driver bug not a fatum.
>>
>> And yet the driver bug provides ample evidence that no one is doing this,
>> so we don't need to worry about it.
>>
>> --Sean
>>
>> > Per pixel alpha blending works
>> > just fine if we disable global alpha. We just need to avoid enabling it when
>> > we have alpha capable GFX plane format.
>> >
>> >> "carve out" an area in the graphics plane where the video plane shows
>> >> through. This limitation is addressed in the next patch, but it means we
>> >> do not need to worry about compatibility in this area.
>> >>
>> >> An alternate approach could be to pretend that the graphics plane
>> >> supports XRGB8888 by using the supported ARGB8888 mode instead and
>> >> enabling the global alpha channel. However, this would rule out ever
>> >> using the per-pixel alpha channel.
>> >>
>> >> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
>> >> ---
>> >>
>> >>  drivers/gpu/drm/xlnx/zynqmp_kms.c | 6 +++---
>> >>  1 file changed, 3 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> >> b/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> >> index c80a2d4034f3..456ada9ac003 100644
>> >> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> >> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
>> >> @@ -161,8 +161,8 @@ static int zynqmp_dpsub_create_planes(struct
>> >> zynqmp_dpsub *dpsub)
>> >>                 if (!formats)
>> >>                         return -ENOMEM;
>> >>
>> >> -               /* Graphics layer is primary, and video layer is overlay. */
>> >> -               type = i == ZYNQMP_DPSUB_LAYER_VID
>> >> +               /* Graphics layer is overlay, and video layer is primary. */
>> >> +               type = i == ZYNQMP_DPSUB_LAYER_GFX
>> >>                      ? DRM_PLANE_TYPE_OVERLAY :
>> >> DRM_PLANE_TYPE_PRIMARY;
>> >>                 ret = drm_universal_plane_init(&dpsub->drm->dev, plane, 0,
>> >>                                                &zynqmp_dpsub_plane_funcs,
>> >> @@ -322,7 +322,7 @@ static const struct drm_crtc_funcs
>> >> zynqmp_dpsub_crtc_funcs = {
>> >>
>> >>  static int zynqmp_dpsub_create_crtc(struct zynqmp_dpsub *dpsub)
>> >>  {
>> >> -       struct drm_plane *plane = &dpsub->drm-
>> >> >planes[ZYNQMP_DPSUB_LAYER_GFX];
>> >> +       struct drm_plane *plane = &dpsub->drm-
>> >> >planes[ZYNQMP_DPSUB_LAYER_VID];
>> >>         struct drm_crtc *crtc = &dpsub->drm->crtc;
>> >>         int ret;
>> >>
>> >> --
>> >> 2.35.1.1320.gc452695387.dirty
>> >
>> > Thank you,
>> > Anatoliy
> 
> Thank you,
> Anatoliy

RE: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics plane

[Klymenko, Anatoliy]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Sean,

> -----Original Message-----
> From: Sean Anderson <sean.anderson@linux.dev>
> Sent: Monday, November 17, 2025 7:36 AM
> To: Klymenko, Anatoliy <Anatoliy.Klymenko@amd.com>; Laurent Pinchart
> <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org; Mike Looijmans <mike.looijmans@topic.nl>;
> David Airlie <airlied@gmail.com>; Thomas Zimmermann
> <tzimmermann@suse.de>; Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com>; Maxime Ripard <mripard@kernel.org>;
> linux-arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
> Michal <michal.simek@amd.com>
> Subject: Re: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics
> plane
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 11/14/25 19:12, Klymenko, Anatoliy wrote:
> > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> >> -----Original Message-----
> >> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
> Sean
> >> Anderson
> >> Sent: Thursday, November 13, 2025 3:07 PM
> >> To: Klymenko, Anatoliy <Anatoliy.Klymenko@amd.com>; Laurent Pinchart
> >> <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
> >> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
> >> Cc: linux-kernel@vger.kernel.org; Mike Looijmans
> <mike.looijmans@topic.nl>;
> >> David Airlie <airlied@gmail.com>; Thomas Zimmermann
> >> <tzimmermann@suse.de>; Maarten Lankhorst
> >> <maarten.lankhorst@linux.intel.com>; Maxime Ripard
> <mripard@kernel.org>;
> >> linux-arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>;
> Simek,
> >> Michal <michal.simek@amd.com>
> >> Subject: Re: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics
> >> plane
> >>
> >> Caution: This message originated from an External Source. Use proper
> caution
> >> when opening attachments, clicking links, or responding.
> >>
> >>
> >> On 11/13/25 18:03, Klymenko, Anatoliy wrote:
> >> > [AMD Official Use Only - AMD Internal Distribution Only]
> >> >
> >> > Hi Sean,
> >> >
> >> > Thank you for the patch.
> >> >
> >> >> -----Original Message-----
> >> >> From: Sean Anderson <sean.anderson@linux.dev>
> >> >> Sent: Thursday, November 13, 2025 12:37 PM
> >> >> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>; Tomi
> Valkeinen
> >> >> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
> >> >> Cc: linux-kernel@vger.kernel.org; Mike Looijmans
> >> <mike.looijmans@topic.nl>;
> >> >> David Airlie <airlied@gmail.com>; Thomas Zimmermann
> >> >> <tzimmermann@suse.de>; Maarten Lankhorst
> >> >> <maarten.lankhorst@linux.intel.com>; Klymenko, Anatoliy
> >> >> <Anatoliy.Klymenko@amd.com>; Maxime Ripard <mripard@kernel.org>;
> >> linux-
> >> >> arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>;
> Simek,
> >> >> Michal <michal.simek@amd.com>; Sean Anderson
> >> >> <sean.anderson@linux.dev>
> >> >> Subject: [PATCH 3/3] drm: zynqmp: Add blend mode property to graphics
> >> plane
> >> >>
> >> >> Caution: This message originated from an External Source. Use proper
> >> caution
> >> >> when opening attachments, clicking links, or responding.
> >> >>
> >> >>
> >> >> When global alpha is enabled, per-pixel alpha is ignored. Allow
> >> >> userspace to explicitly specify whether to use per-pixel alpha by
> >> >> exposing it through the blend mode property. I'm not sure whether the
> >> >> per-pixel alpha is pre-multiplied or not [1], but apparently it *must* be
> >> >> pre-multiplied so I guess we have to advertise it.
> >> >>
> >> >> [1] All we get is "The alpha value available with the graphics stream
> >> >>     will define the transparency of the graphics."
> >> >>
> >> >> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> >> >> ---
> >> >>
> >> >>  drivers/gpu/drm/xlnx/zynqmp_kms.c | 24 ++++++++++++++++++++++--
> >> >>  1 file changed, 22 insertions(+), 2 deletions(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> >> >> b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> >> >> index 456ada9ac003..fa1cfc16db36 100644
> >> >> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> >> >> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> >> >> @@ -61,6 +61,13 @@ static int
> zynqmp_dpsub_plane_atomic_check(struct
> >> >> drm_plane *plane,
> >> >>         if (!new_plane_state->crtc)
> >> >>                 return 0;
> >> >>
> >> >> +       if (new_plane_state->pixel_blend_mode !=
> >> >> DRM_MODE_BLEND_PIXEL_NONE &&
> >> >> +           new_plane_state->alpha >> 8 != 0xff) {
> >> >> +               drm_dbg_kms(plane->dev,
> >> >> +                           "Plane alpha must be 1.0 when using pixel alpha\n");
> >> >> +               return -EINVAL;
> >> >> +       }
> >> >> +
> >> >>         crtc_state = drm_atomic_get_crtc_state(state, new_plane_state-
> >crtc);
> >> >>         if (IS_ERR(crtc_state))
> >> >>                 return PTR_ERR(crtc_state);
> >> >> @@ -117,9 +124,13 @@ static void
> >> >> zynqmp_dpsub_plane_atomic_update(struct drm_plane *plane,
> >> >>
> >> >>         zynqmp_disp_layer_update(layer, new_state);
> >> >>
> >> >> -       if (plane->index == ZYNQMP_DPSUB_LAYER_GFX)
> >> >> -               zynqmp_disp_blend_set_global_alpha(dpsub->disp, true,
> >> >> +       if (plane->index == ZYNQMP_DPSUB_LAYER_GFX) {
> >> >> +               bool blend = plane->state->pixel_blend_mode ==
> >> >> +                            DRM_MODE_BLEND_PIXEL_NONE;
> >> >> +
> >> >> +               zynqmp_disp_blend_set_global_alpha(dpsub->disp, blend,
> >> >>                                                    plane->state->alpha >> 8);
> >> >> +       }
> >> >>
> >> >>         /*
> >> >>          * Unconditionally enable the layer, as it may have been disabled
> >> >> @@ -179,9 +190,18 @@ static int zynqmp_dpsub_create_planes(struct
> >> >> zynqmp_dpsub *dpsub)
> >> >>                         return ret;
> >> >>
> >> >>                 if (i == ZYNQMP_DPSUB_LAYER_GFX) {
> >> >> +                       unsigned int blend_modes =
> >> >> +                               BIT(DRM_MODE_BLEND_PIXEL_NONE) |
> >> >> +                               BIT(DRM_MODE_BLEND_PREMULTI);
> >> >
> >> > | BIT(DRM_MODE_BLEND_COVERAGE) - this is what implemented in the
> >> hardware.
> >>
> >> Do you have a datasheet (or other) reference?
> >>
> >
> > Yes https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm
>
> There is no mention of this in the TRM.
>
> | Video Blending is defined for two RGB video streams. One of these
> | streams will be graphics that have an alpha value along with RGB
> | stream. The alpha value available with the graphics stream will define
> | the transparency of the graphics. Alpha value defined for blending
> | function is always 8-bit. 1-bit alpha and 4-bit alpha are also
> | supported, but these are scaled to 8-bits before they are used for
> | alpha blending
>
> Please quote a specific section where the alpha blending formula is
> documented.
>

Yes, there is no explicit alpha blending formula in the TRM, although
absence of "premultiplied alpha" term anywhere in the doc suggests that
alpha is treated as a straight. Anyways, I cooked a quick test that proved
the straight alpha theory: https://github.com/onotole/zynqmp-dp-alpha

> >> But in any case, DRM_MODE_BLEND_PREMULTI is mandatory even if we
> >> don't support
> >> it. See drm_plane_create_blend_mode_property for details.
> >>
> >
> > No doubts here
>
> OK, so regardless of what the hardware does, we have to pretend to
> support pre-multiplied alpha.
>

Yes, we my pretend so, or we may work around backward compatibility check
in drm_plane_create_blend_mode_property by setting blend mode to
DRM_MODE_BLEND_COVERAGE immediately and later reject plane states
with DRM_MODE_BLEND_PREMULTI mode.

> --Sean

Thank you,
Anatoliy

RE: [PATCH 2/3] drm: zynqmp: Make the video plane primary

[Klymenko, Anatoliy]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Sean,

> -----Original Message-----
> From: Sean Anderson <sean.anderson@linux.dev>
> Sent: Monday, November 17, 2025 8:10 AM
> To: Klymenko, Anatoliy <Anatoliy.Klymenko@amd.com>; Laurent Pinchart
> <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org; Mike Looijmans <mike.looijmans@topic.nl>;
> David Airlie <airlied@gmail.com>; Thomas Zimmermann
> <tzimmermann@suse.de>; Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com>; Maxime Ripard <mripard@kernel.org>;
> linux-arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>; Simek,
> Michal <michal.simek@amd.com>
> Subject: Re: [PATCH 2/3] drm: zynqmp: Make the video plane primary
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 11/14/25 19:57, Klymenko, Anatoliy wrote:
> > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> >> -----Original Message-----
> >> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
> Sean
> >> Anderson
> >> Sent: Thursday, November 13, 2025 2:52 PM
> >> To: Klymenko, Anatoliy <Anatoliy.Klymenko@amd.com>; Laurent Pinchart
> >> <laurent.pinchart@ideasonboard.com>; Tomi Valkeinen
> >> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
> >> Cc: linux-kernel@vger.kernel.org; Mike Looijmans
> <mike.looijmans@topic.nl>;
> >> David Airlie <airlied@gmail.com>; Thomas Zimmermann
> >> <tzimmermann@suse.de>; Maarten Lankhorst
> >> <maarten.lankhorst@linux.intel.com>; Maxime Ripard
> <mripard@kernel.org>;
> >> linux-arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>;
> Simek,
> >> Michal <michal.simek@amd.com>
> >> Subject: Re: [PATCH 2/3] drm: zynqmp: Make the video plane primary
> >>
> >> Caution: This message originated from an External Source. Use proper
> caution
> >> when opening attachments, clicking links, or responding.
> >>
> >>
> >> On 11/13/25 17:45, Klymenko, Anatoliy wrote:
> >> > [AMD Official Use Only - AMD Internal Distribution Only]
> >> >
> >> > Hi Sean,
> >> >
> >> > Thanks a lot for the patch (and tackling the alpha issue in general)
> >> >
> >> >> -----Original Message-----
> >> >> From: Sean Anderson <sean.anderson@linux.dev>
> >> >> Sent: Thursday, November 13, 2025 12:37 PM
> >> >> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>; Tomi
> Valkeinen
> >> >> <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org
> >> >> Cc: linux-kernel@vger.kernel.org; Mike Looijmans
> >> <mike.looijmans@topic.nl>;
> >> >> David Airlie <airlied@gmail.com>; Thomas Zimmermann
> >> >> <tzimmermann@suse.de>; Maarten Lankhorst
> >> >> <maarten.lankhorst@linux.intel.com>; Klymenko, Anatoliy
> >> >> <Anatoliy.Klymenko@amd.com>; Maxime Ripard <mripard@kernel.org>;
> >> linux-
> >> >> arm-kernel@lists.infradead.org; Simona Vetter <simona@ffwll.ch>;
> Simek,
> >> >> Michal <michal.simek@amd.com>; Sean Anderson
> >> >> <sean.anderson@linux.dev>
> >> >> Subject: [PATCH 2/3] drm: zynqmp: Make the video plane primary
> >> >>
> >> >> Caution: This message originated from an External Source. Use proper
> >> caution
> >> >> when opening attachments, clicking links, or responding.
> >> >>
> >> >>
> >> >> The zynqmp has two planes: "video" and "graphics". The video plane
> >> >>
> >> >> - Is on the bottom (zpos=0) (except when chroma keying as the master
> >> plane)
> >> >> - Supports "live" input (e.g. from an external source)
> >> >> - Supports RGB, YUV, and YCbCr formats, including XRGB8888
> >> >> - Does not support transparency, except via chroma keying (colorkey)
> >> >> - Must cover the entire screen (translation/resizing not supported)
> >> >>
> >> >> The graphics plane
> >> >>
> >> >> - Is on the top (zpos=1)
> >> >> - Supports "live" input (e.g. from an external source)
> >> >> - Supports RGB and YUV444 formats, but not XRGB8888
> >> >> - Supports transparency either via
> >> >>   - Global alpha channel, which disables per-pixel alpha when enabled
> >> >>   - Per-pixel alpha, which cannot be used with global alpha
> >> >>   - Chroma keying (colorkey)
> >> >> - Must cover the entire screen (translation/resizing not supported)
> >> >>
> >> >> Currently the graphics plane is the primary plane. Make the video plane
> >> >> the primary plane:
> >> >>
> >> >> - The video plane supports XRGB8888, which is the default 24-bit
> >> >>   colorspace for X. This results in improved performance when compared
> >> >>   to RGB565.
> >> >> - The graphics plane can be used as an overlay because it has a higher
> >> >>   z-pos and supports a per-pixel alpha channel. Unfortunately, clients
> >> >>   like weston cannot currently take advantage of this because they
> >> >>   expect overlay planes to support translation/resizing.
> >> >>
> >> >> One downside to this approach could be that the graphics plane has
> worse
> >> >> support for YUV and YCBCr, so it may be more difficult to compose video
> >> >
> >> > Not just more difficult but practically impossible:
> >> > 1. GFX (in Xilinx terminology) plane doesn't support pixel upscaling, so
> >> > no support for NV12, YUY2 and other common video pixel formats.
> >> > 2. Both planes are unscalable, this means we can only output native
> >> > display resolution video on the top plane, or display thick black frame
> >> > around the picture. We are losing GFX masking capabilities.
> >>
> >> The graphics masking capabilities are the same as they always were.
> >>
> >> > 3. We won't be able to render subtitles on top of the video.
> >> > Probably the only practical video player option remains here is to render
> >> > video to a texture and embed it into graphics composition.
> >>
> >> OK, but none of this is currently possible either because of the global
> >> alpha setting. So do you have a specific program in mind that plays
> >> video and will do it with an "underlay" plane?
> >>
> >
> > webOS, Roku OS, just to name a few. But most importantly, AMD has quite
> > a few customers using "underlay" plane because of its YUV 420 capability.
>
> Can you link to a specific example where the plane is selected based on
> its primary/overlay status and not based on its format support?  I'm not
> too familiar with these distros, but e.g. [1] selects the plane based on
> the format, and doesn't care which one is primary.
>

The plane selection by the type may not be explicit. For instance, if a
graphics compositor uses legacy API with drmModeSetCrtc, it would allocate
the primary plane implicitly. Or some compositor may just rely on planes
z-order. For instance, here [2] you may see exact z-order WebOS compositor
expects from the HW planes (both VideoPlane and FullscreenPlane are used
for the video playback, the graphics lives on MainPlane). Anyways, the
probability of primary plane being reserved for a graphics compositor is
too high to ignore.
Back to example [1], in our case the renderer would fail this check:
if ((ovr->possible_crtcs & (1 << pipe)) && !ovr->crtc_id)
for the primary plane pre-occupied by the graphics, and this check:
if (!format_support(ovr, p->fourcc))
for the overlay plane lacking pixel upsampling support.

[2] https://github.com/webosose/luna-surfacemanager/blob/b2fef6f73232244f6f13102aa66d2d3f5942835e/modules/weboscompositor/webossurfaceitem.cpp#L1794

> --Sean
>
> [1] https://github.com/webosose/omx-
> components/blob/27b33e17c25023f2c7ffbbfda10169fb500dacdc/src/omxdrm/vid
> eorenderer.cpp#L469
>
> >> >> streams into the window of a media player. However, no existing software
> >> >> could rely on this because there is no way to enable the per-pixel alpha
> >> >> channel when the graphics plane is enabled. This makes it impossible to
> >> >
> >> > This situation is a driver bug not a fatum.
> >>
> >> And yet the driver bug provides ample evidence that no one is doing this,
> >> so we don't need to worry about it.
> >>
> >> --Sean
> >>
> >> > Per pixel alpha blending works
> >> > just fine if we disable global alpha. We just need to avoid enabling it when
> >> > we have alpha capable GFX plane format.
> >> >
> >> >> "carve out" an area in the graphics plane where the video plane shows
> >> >> through. This limitation is addressed in the next patch, but it means we
> >> >> do not need to worry about compatibility in this area.
> >> >>
> >> >> An alternate approach could be to pretend that the graphics plane
> >> >> supports XRGB8888 by using the supported ARGB8888 mode instead
> and
> >> >> enabling the global alpha channel. However, this would rule out ever
> >> >> using the per-pixel alpha channel.
> >> >>
> >> >> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> >> >> ---
> >> >>
> >> >>  drivers/gpu/drm/xlnx/zynqmp_kms.c | 6 +++---
> >> >>  1 file changed, 3 insertions(+), 3 deletions(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> >> >> b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> >> >> index c80a2d4034f3..456ada9ac003 100644
> >> >> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> >> >> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> >> >> @@ -161,8 +161,8 @@ static int zynqmp_dpsub_create_planes(struct
> >> >> zynqmp_dpsub *dpsub)
> >> >>                 if (!formats)
> >> >>                         return -ENOMEM;
> >> >>
> >> >> -               /* Graphics layer is primary, and video layer is overlay. */
> >> >> -               type = i == ZYNQMP_DPSUB_LAYER_VID
> >> >> +               /* Graphics layer is overlay, and video layer is primary. */
> >> >> +               type = i == ZYNQMP_DPSUB_LAYER_GFX
> >> >>                      ? DRM_PLANE_TYPE_OVERLAY :
> >> >> DRM_PLANE_TYPE_PRIMARY;
> >> >>                 ret = drm_universal_plane_init(&dpsub->drm->dev, plane, 0,
> >> >>                                                &zynqmp_dpsub_plane_funcs,
> >> >> @@ -322,7 +322,7 @@ static const struct drm_crtc_funcs
> >> >> zynqmp_dpsub_crtc_funcs = {
> >> >>
> >> >>  static int zynqmp_dpsub_create_crtc(struct zynqmp_dpsub *dpsub)
> >> >>  {
> >> >> -       struct drm_plane *plane = &dpsub->drm-
> >> >> >planes[ZYNQMP_DPSUB_LAYER_GFX];
> >> >> +       struct drm_plane *plane = &dpsub->drm-
> >> >> >planes[ZYNQMP_DPSUB_LAYER_VID];
> >> >>         struct drm_crtc *crtc = &dpsub->drm->crtc;
> >> >>         int ret;
> >> >>
> >> >> --
> >> >> 2.35.1.1320.gc452695387.dirty
> >> >
> >> > Thank you,
> >> > Anatoliy
> >
> > Thank you,
> > Anatoliy

Thank you,
Anatoliy

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

[Mikko Rapeli]

Hi,

On Fri, Nov 14, 2025 at 10:35:10AM -0500, Sean Anderson wrote:
> On 11/14/25 02:42, Thomas Zimmermann wrote:
> > Am 13.11.25 um 21:37 schrieb Sean Anderson:
> >> 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.
> > 
> > Did you try to set drm_device.mode_config.preferred_depth = 16, like at [1]?  IIRC user space looks at this value to auto-detect the color format.
> 
> I have not tried that. But I would rather use 24-bit color for the performance boost.

I have tested preferred_depth = 16 and it works. Proposed in
https://lists.freedesktop.org/archives/dri-devel/2025-December/540189.html
but I'm also fine with 24/32 bpp, or any default which draws pixels to HDMI
on AMD KV260 and X11 without manually changing the config.

This full series also works for me on AMD KV260 running Yocto genericarm64
machine config and core-image-sato image with Xorg.

Cheers,

-Mikko

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

[Mikko Rapeli]

Hi,

On Thu, Nov 13, 2025 at 03:37:11PM -0500, 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/

I've tested this series on AMD KV260 running Yocto genericarm64 machine config and
core-image-sato with Xorg. This series fixes HDMI output using X11, no need to
configure Xorg to 16bpp as workaround.

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

That said, I also tested
https://lore.kernel.org/dri-devel/20250627145058.6880-1-mike.looijmans@topic.nl/
and it works.

And I tested and submitted the patch for zynqmp framebuffer to prefer 16bpp
until different modes are actually support, which fixes Xorg startup and
the depth detection logic used there:

https://lore.kernel.org/dri-devel/20251205123751.2257694-3-mikko.rapeli@linaro.org/

This series and Mike's patches enable 24bpp mode to work, which I guess is the long
term path, but it is not clear to me what is still missing.

The patch from me fixes the current situtation where only 16bpp works but framebuffer
driver does not prefer that and thus userspace X11 uses the default 24bpp
which then fails. My patch could be merged right now until the XRGB8888 support
is finalized.

Cheers,

-Mikko

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

[Tomi Valkeinen]

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

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

[Mike Looijmans]

On 22-12-2025 10:48, Tomi Valkeinen wrote:
> 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.

I tried to get e.g. gstreamer to use the overlay as output (in YUV 
format), but never got that to work. Having read the comments on these 
series, it's probably the lack of positioning and scaling capabilities 
that made gstreamer discard it.

I expect no regression here - everyone who got the DP output to work 
must have been using some workaround already. The driver as it is now 
never worked with X11 (or wayland) anyway, unless you forced it into 
16-bit mode.

And given the capabilities, I seriously doubt that any user ever used 
the overlay plane.

For what it's worth, I'd say the best solution is to swap the planes and 
support XRGB8888 mode properly. Then at least, X11 and wayland work 
without further configuration or patches, the output quality is as it 
should be, and as an added bonus, the performance (with or without the 
MALI GPU) is much better too.


-- 
Mike Looijmans
System Expert

TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl