[PATCH v4 0/2] drm/drm_blend: allow blend mode property without PREMULTI

[PATCH v4 0/2] drm/drm_blend: allow blend mode property without PREMULTI

[Leandro Ribeiro]

Some hardware only supports the COVERAGE blend mode and lacks PREMULTI
support entirely. DRM currently requires that PREMULTI is present when
creating a blend mode property, which prevents such drivers from being
properly upstreamed.

This series removes this restriction and allows drivers to create a blend
mode property without PREMULTI.

On Weston (userspace), we are working [1] towards adding support for
this kind of hardware.

[1] https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/2046

v4:
- Trigger warnings instead of errors when pixel format with alpha is
  exposed but blend mode is not setup.
- Require blend mode only when plane exposes pixel formats with alpha, not
  when it supports the alpha property.

v3:
- Changed where we enforce drivers to expose blend mode for planes that
  support the alpha property or pixel formats with alpha.
- Fixed missing check to forbid calling
  drm_plane_create_blend_mode_property() with a zero bitmask of
  supported modes.

v2:
- Force drivers to expose blend mode if plane supports alpha property
  or pixel format with alpha.

Leandro Ribeiro (2):
  drm/drm_blend: allow blend mode property without PREMULTI
  drm: ensure blend mode supported if pixel format with alpha exposed

 drivers/gpu/drm/drm_blend.c       | 20 ++++++++++++++------
 drivers/gpu/drm/drm_mode_config.c | 21 +++++++++++++++++++++
 2 files changed, 35 insertions(+), 6 deletions(-)

-- 
2.54.0

[PATCH v4 1/2] drm/drm_blend: allow blend mode property without PREMULTI

[Leandro Ribeiro]

Some hardware only supports the COVERAGE blend mode and lacks PREMULTI
support entirely. DRM currently requires that PREMULTI is present when
creating a blend mode property, which prevents such drivers from being
properly upstreamed.

Remove this restriction and allow drivers to create a blend mode
property without PREMULTI, enabling support for hardware that
implements only COVERAGE blend mode.

This does not introduce a regression, as no existing upstream drivers
expose only COVERAGE. However, userspace that wants to support such kind
of hardware in the future will have to check the supported blend modes
instead of assuming PREMULTI is always supported.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
---
 drivers/gpu/drm/drm_blend.c | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 2f0d1ba285be..d17ae964fb21 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -563,10 +563,10 @@ EXPORT_SYMBOL(drm_atomic_normalize_zpos);
 /**
  * drm_plane_create_blend_mode_property - create a new blend mode property
  * @plane: drm plane
- * @supported_modes: bitmask of supported modes, must include
- *		     BIT(DRM_MODE_BLEND_PREMULTI). Current DRM assumption is
- *		     that alpha is premultiplied, and old userspace can break if
- *		     the property defaults to anything else.
+ * @supported_modes: bitmask of supported modes. When
+ *		     BIT(DRM_MODE_BLEND_PREMULTI) is included, it will be used
+ *		     as the default. Otherwise, the default will fallback to one
+ *		     of the supported modes.
  *
  * This creates a new property describing the blend mode.
  *
@@ -599,13 +599,14 @@ int drm_plane_create_blend_mode_property(struct drm_plane *plane,
 		{ DRM_MODE_BLEND_PREMULTI, "Pre-multiplied" },
 		{ DRM_MODE_BLEND_COVERAGE, "Coverage" },
 	};
+	unsigned int default_mode;
 	unsigned int valid_mode_mask = BIT(DRM_MODE_BLEND_PIXEL_NONE) |
 				       BIT(DRM_MODE_BLEND_PREMULTI)   |
 				       BIT(DRM_MODE_BLEND_COVERAGE);
 	int i;
 
 	if (WARN_ON((supported_modes & ~valid_mode_mask) ||
-		    ((supported_modes & BIT(DRM_MODE_BLEND_PREMULTI)) == 0)))
+		    (supported_modes == 0)))
 		return -EINVAL;
 
 	prop = drm_property_create(dev, DRM_MODE_PROP_ENUM,
@@ -630,7 +631,14 @@ int drm_plane_create_blend_mode_property(struct drm_plane *plane,
 		}
 	}
 
-	drm_object_attach_property(&plane->base, prop, DRM_MODE_BLEND_PREMULTI);
+	if (supported_modes & BIT(DRM_MODE_BLEND_PREMULTI))
+		default_mode = DRM_MODE_BLEND_PREMULTI;
+	else if (supported_modes & BIT(DRM_MODE_BLEND_COVERAGE))
+		default_mode = DRM_MODE_BLEND_COVERAGE;
+	else
+		default_mode = DRM_MODE_BLEND_PIXEL_NONE;
+
+	drm_object_attach_property(&plane->base, prop, default_mode);
 	plane->blend_mode_property = prop;
 
 	return 0;
-- 
2.54.0

[PATCH v4 2/2] drm: ensure blend mode supported if pixel format with alpha exposed

[Leandro Ribeiro]

Before "drm/drm_blend: allow blend mode property without PREMULTI",
userspace would have to assume that only PREMULTI was supported by
drivers that didn't expose the blend mode property. But now userspace
shouldn't rely on that, as they can't count with drivers always
supporting PREMULTI.

Warn if a driver exposes pixel formats with alpha but doesn't expose the
blend mode property. This way userspace doesn't have to guess. Drivers
triggering this warning must be fixed.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
---
 drivers/gpu/drm/drm_mode_config.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
index 66f7dc37b597..8cca1dea3b3d 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -674,6 +674,25 @@ static void validate_encoder_possible_crtcs(struct drm_encoder *encoder)
 	     encoder->possible_crtcs, crtc_mask);
 }
 
+static void validate_blend_mode_for_alpha_formats(struct drm_plane *plane)
+{
+	const struct drm_format_info *fmt;
+	u32 i;
+
+	/* blend mode property supported, no need to check anything */
+	if (plane->blend_mode_property)
+		return;
+
+	for (i = 0; i < plane->format_count; i++) {
+		fmt = drm_format_info(plane->format_types[i]);
+		if (fmt->has_alpha) {
+			WARN(1, "[PLANE:%d:%s] pixel format with alpha exposed but "
+			     "blend mode not setup", plane->base.id, plane->name);
+			break;
+		}
+	}
+}
+
 void drm_mode_config_validate(struct drm_device *dev)
 {
 	struct drm_encoder *encoder;
@@ -732,6 +751,8 @@ void drm_mode_config_validate(struct drm_device *dev)
 	drm_for_each_plane(plane, dev) {
 		if (plane->type == DRM_PLANE_TYPE_PRIMARY)
 			num_primary++;
+
+		validate_blend_mode_for_alpha_formats(plane);
 	}
 
 	WARN(num_primary != dev->mode_config.num_crtc,
-- 
2.54.0

Claude review: drm/drm_blend: allow blend mode property without PREMULTI

[Claude Code Review Bot]

Overall Series Review

Subject: drm/drm_blend: allow blend mode property without PREMULTI
Author: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Patches: 3
Reviewed: 2026-05-27T14:22:59.780246

---

This is a clean, well-motivated 2-patch series that relaxes the DRM blend mode property creation to no longer require PREMULTI support, enabling hardware that only supports COVERAGE. The approach is sound: patch 1 removes the restriction while maintaining backwards compatibility (PREMULTI remains the default when available), and patch 2 adds a validation warning to catch future drivers that expose alpha formats without setting up a blend mode property.

The series is at v4 and has clearly benefited from prior review iterations. The scope is minimal and well-contained. I have one correctness concern in patch 2.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/drm_blend: allow blend mode property without PREMULTI

[Claude Code Review Bot]

Patch Review

**Looks good.** The change is straightforward and correct.

The WARN_ON condition change from requiring `BIT(DRM_MODE_BLEND_PREMULTI)` to just rejecting `supported_modes == 0` is the right relaxation — it still catches invalid bits via the `supported_modes & ~valid_mode_mask` check while removing only the PREMULTI mandate.

The default mode fallback logic is well-ordered:

```c
if (supported_modes & BIT(DRM_MODE_BLEND_PREMULTI))
    default_mode = DRM_MODE_BLEND_PREMULTI;
else if (supported_modes & BIT(DRM_MODE_BLEND_COVERAGE))
    default_mode = DRM_MODE_BLEND_COVERAGE;
else
    default_mode = DRM_MODE_BLEND_PIXEL_NONE;
```

PREMULTI first preserves compatibility with existing userspace that assumes premultiplied alpha. COVERAGE second matches the target hardware use case. PIXEL_NONE as the final fallback is the only remaining valid option given the earlier validation.

The doc update accurately describes the new behavior. No issues.

---
Generated by Claude Code Patch Reviewer

Claude review: drm: ensure blend mode supported if pixel format with alpha exposed

[Claude Code Review Bot]

Patch Review

**Potential NULL pointer dereference.** In `validate_blend_mode_for_alpha_formats()`:

```c
for (i = 0; i < plane->format_count; i++) {
    fmt = drm_format_info(plane->format_types[i]);
    if (fmt->has_alpha) {
```

`drm_format_info()` can return NULL for unknown formats (it only does a `WARN_ON(!info)` internally, then returns NULL). If a buggy driver registers an unknown fourcc, this validation function — which exists precisely to catch driver bugs — would hit a NULL dereference on `fmt->has_alpha`.

This should have a NULL check:

```c
fmt = drm_format_info(plane->format_types[i]);
if (fmt && fmt->has_alpha) {
```

In practice this is unlikely to trigger since any driver with an unknown format would already be very broken, but a validation function should be defensive.

**Otherwise the logic is correct.** The early return when `blend_mode_property` is set avoids unnecessary iteration. The `break` after the first warning avoids spamming the log. The placement in `drm_mode_config_validate()` in the existing `drm_for_each_plane` loop is efficient.

**Minor style nit:** The WARN format string is split across lines:

```c
WARN(1, "[PLANE:%d:%s] pixel format with alpha exposed but "
     "blend mode not setup", plane->base.id, plane->name);
```

"not setup" should be "not set up" (two words — "setup" is a noun, "set up" is the verb/participle form). Very minor.

---
Generated by Claude Code Patch Reviewer