Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Exposing DRM_MODE_BLEND_PIXEL_NONE exclusively for an ARGB8888 cursor plane breaks userspace expectations and contradicts hardware behavior. --
commit 4827dcdf2907d6dd03961937ab097337202514ed Author: Huacai Chen <[email protected]> Subject: drm/loongson: Create blend mode property for cursor plane This commit adds a blend mode property to the cursor planes in the loongson DRM driver to silence a kernel warning during boot. It configures the plane to exclusively expose DRM_MODE_BLEND_PIXEL_NONE since the hardware lacks a configurable blend mode register. > diff --git a/drivers/gpu/drm/loongson/lsdc_plane.c > b/drivers/gpu/drm/loongson/lsdc_plane.c > index bea42215796d4..efef25eaa6592 100644 > --- a/drivers/gpu/drm/loongson/lsdc_plane.c > +++ b/drivers/gpu/drm/loongson/lsdc_plane.c [ ... ] > @@ -747,8 +748,9 @@ int ls7a1000_cursor_plane_init(struct drm_device *ddev, > struct drm_plane *plane, > unsigned int index) > { > - struct lsdc_cursor *cursor = to_lsdc_cursor(plane); > int ret; > + unsigned int blend_caps = BIT(DRM_MODE_BLEND_PIXEL_NONE); [Severity: Medium] Will this break userspace compositors? Exposing DRM_MODE_BLEND_PIXEL_NONE exclusively for an ARGB8888 cursor plane contradicts hardware behavior and breaks userspace expectations. In DRM KMS semantics (as documented in drm_blend.c), DRM_MODE_BLEND_PIXEL_NONE explicitly means 'the alpha channel is ignored for blending'. However, the driver exposes DRM_FORMAT_ARGB8888 for the cursor plane (via lsdc_cursor_formats), and hardware cursors inherently perform fixed-function alpha blending (typically PREMULTI or COVERAGE) to render properly with transparent edges. When a display server queries the supported blend modes for the cursor plane in ls7a1000_cursor_plane_init(), it will receive only DRM_MODE_BLEND_PIXEL_NONE despite the format being DRM_FORMAT_ARGB8888. Userspace compositors (e.g., Wayland, Mutter, Weston) that strictly validate alpha blending capabilities will reject the hardware cursor plane because it claims to not support alpha blending, forcing a fallback to software cursor composition. By claiming the plane only supports PIXEL_NONE, the driver seems to be incorrectly documenting its hardcoded blend equation to silence a kernel warning. If the hardware truly ignored the alpha channel, it should expose DRM_FORMAT_XRGB8888 instead. > + struct lsdc_cursor *cursor = to_lsdc_cursor(plane); > > ret = drm_universal_plane_init(ddev, plane, 1 << index, [ ... ] > @@ -765,15 +767,16 @@ int ls7a1000_cursor_plane_init(struct drm_device *ddev, [ ... ] > int ls7a2000_cursor_plane_init(struct drm_device *ddev, > struct drm_plane *plane, > unsigned int index) > { > - struct lsdc_cursor *cursor = to_lsdc_cursor(plane); > int ret; > + unsigned int blend_caps = BIT(DRM_MODE_BLEND_PIXEL_NONE); [Severity: Medium] Does this face the same userspace rejection issue? As with ls7a1000_cursor_plane_init(), exposing DRM_MODE_BLEND_PIXEL_NONE exclusively for an ARGB8888 cursor plane will cause userspace compositors to reject the hardware cursor plane in ls7a2000_cursor_plane_init() as well. > + struct lsdc_cursor *cursor = to_lsdc_cursor(plane); > > ret = drm_universal_plane_init(ddev, plane, 1 << index, [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
