Hi,
amdgpu lists DRM_FORMAT_RGBA8888 (RA24) as a supported format on every
primary and overlay plane, both in the plane's format list and in its
IN_FORMATS blob. Any atomic commit that puts an RA24 framebuffer on one
of those planes, TEST_ONLY included, fails with -EINVAL:
amdgpu 0000:03:00.0: [drm] *ERROR* Unsupported screen format RA24
little-endian (0x34324152)
[drm:amdgpu_dm_atomic_check [amdgpu]] dm_update_plane_state() failed
[drm:amdgpu_dm_atomic_check [amdgpu]] Atomic check failed with err: -22
[drm:drm_atomic_check_only] atomic driver check for 00000000e90a6d65
failed: -22
A compositor that trusts the advertised list and picks RA24 can't light
the display. KWin 6.7 does this on most starts: it ranks RA24 equal to
AR24 and AB24, and the order among the three is random. It then fails
every output configuration, retries for one to two seconds, and stops
presenting for several seconds, which shows up as a freeze at every
login. I'm reporting the KWin side to KDE separately, but fixing the
driver removes the trap for every compositor.
Where in the source
-------------------
Checked against mainline at v7.3-rc3:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
DRM_FORMAT_RGBA8888 is in rgb_formats[] and overlay_formats[], the
lists passed to drm_universal_plane_init(), so userspace sees it. It is
also in alpha_formats[] in the blending setup.
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
fill_dc_plane_info_and_addr() switches on fb->format->format to choose a
SURFACE_PIXEL_FORMAT_*. It has cases for C8, RGB565, XRGB/ARGB8888,
XBGR/ABGR8888, the 2101010 and 16161616 formats, NV12/NV21/P010 and the
half-float formats. There is no case for DRM_FORMAT_RGBA8888, so it falls
through to default:, logs "Unsupported screen format %p4cc" and returns
-EINVAL.
So either RGBA8888 should come out of rgb_formats[] and overlay_formats[]
(and alpha_formats[]), or fill_dc_plane_info_and_addr() needs a mapping
for it. I haven't checked whether DC has a surface pixel format that
fits, so I don't know which of the two is right.
Reproduction
------------
1. On an affected card, read any primary plane's formats with drm_info,
drmModeGetPlane() or the IN_FORMATS blob. RA24 is listed. Here every
primary and overlay plane lists 20 formats, RA24 among them, and 17 of
the 340 IN_FORMATS format/modifier pairs are RA24. The cursor planes
list only AR24.
2. As DRM master, create an RA24 framebuffer and do an atomic commit, or a
TEST_ONLY one, with it on a primary plane of an active CRTC.
3. The commit fails with -EINVAL, and the kernel log shows the lines
above.
In practice the easiest way to hit it is Plasma Wayland with KWin 6.7:
log in a few times and grep the kernel log for "Unsupported screen format
RA24". Most starts produce hundreds of lines. When RA24 is hidden from
KWin (an LD_PRELOAD wrapper that removes it from drmModeGetPlane() and
drmModeFormatModifierBlobIterNext()), the same configuration succeeds
first time on every start, and the primary planes run AB30.
System
------
GPU: AMD Radeon RX 9070 XT, Navi 48 [1002:7550] rev c0
Display Core: v3.2.384 on DCN 4.0.1
Kernel: 7.2.4-arch1-2 (Arch Linux)
linux-firmware: 20260910
Mesa: 26.2.2
libdrm: 2.4.134
Compositor: KWin 6.7.5, Plasma Wayland
Displays: 3x AOC Q27G41ZE, 2560x1440 @ 240 Hz, DisplayPort
(DP-1, DP-2, DP-3)
Command line: root=UUID=... rw loglevel=3 quiet video=2560x1440-32
Not bisected. Going by the source, mainline still has the mismatch, and
since rgb_formats[] is shared by every GPU that DC drives, other AMD
cards are presumably affected as well. I've only tested this one.
Log
---
Kernel with drm.debug=0x16, one failing check during KWin's first modeset
for DP-2 (CRTC 437, primary plane 152). 10 bpc is pruned for link
bandwidth and 8 bpc validates, so the stream itself is fine. The plane
state is what fails:
[drm:drm_atomic_set_fb_for_plane] Set [FB:495] for [PLANE:152:plane-2]
state 000000001159dc5f
[drm:drm_atomic_set_mode_prop_for_crtc] Set [MODE:2560x1440] for
[CRTC:437:crtc-1] state 0000000007556867
[drm:drm_atomic_check_only] checking 00000000e90a6d65
[drm:drm_atomic_helper_check_modeset] [CRTC:437:crtc-1] mode changed
[drm:drm_atomic_helper_check_modeset] [CONNECTOR:459:DP-2] keeps
[ENCODER:458:TMDS-458], now on [CRTC:437:crtc-1]
[drm:amdgpu_dm_atomic_check [amdgpu]] Disabling DRM plane: 152 on DRM
crtc 437
[drm:dm_update_crtc_state [amdgpu]] Disabling DRM crtc: 437
[drm:create_validate_stream_for_sink [amdgpu]] Trying with 10 bpc
[drm:create_validate_stream_for_sink [amdgpu]] Pruned mode 2560 x 1440
(clk 992260) RGB 10-bpc -- No DP link bandwidth
[drm:create_validate_stream_for_sink [amdgpu]] Trying with 8 bpc
[drm:dm_update_crtc_state [amdgpu]] Enabling DRM crtc: 437
[drm:amdgpu_dm_atomic_check [amdgpu]] Enabling DRM plane: 152 on DRM crtc
437
[drm] *ERROR* Unsupported screen format RA24 little-endian (0x34324152)
[drm:amdgpu_dm_atomic_check [amdgpu]] dm_update_plane_state() failed
[drm:amdgpu_dm_atomic_check [amdgpu]] Atomic check failed with err: -22
[drm:drm_atomic_check_only] atomic driver check for 00000000e90a6d65
failed: -22
In one 4-second capture of KWin starting, all 602 failed atomic checks
were this same RA24 rejection, on planes 206 and 152.
Formats per plane, as read from userspace:
plane 44: XR24 AR24 RA24 XR30 XB30 AR30 AB30 XR48 XB48 AR48 AB48 XB24
AB24 RG16 NV12 P010 XR4H AR4H XB4H AB4H
plane 98: same
plane 152: same
plane 206: same
plane 260: same
plane 316: same
plane 372: same
plane 428: AR24 (cursor)
plane 433: AR24
plane 438: AR24
plane 443: AR24
I can capture a longer drm.debug log or test a patch if that helps.
Thanks,
