On Tue, Sep 15, 2026 at 3:51 AM Nakildias Professionnel <[email protected]> wrote: > > 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.
Please see this ticket for discussion and patches: https://gitlab.freedesktop.org/drm/amd/-/work_items/5339 Alex > > > 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, >
