NVIDIA: 通过 linux-dmabuf 传递的客户缓冲区合成时会丢失 alpha 值 - 透明窗口渲染为不透明的黑色

Xwayland -> satellite

create_immed(new id wl_buffer#25, 1897, 2130, 875713089, 0) create_immed(new id wl_buffer#26, 1897, 2130, 875713089, 0)

satellite -> niri

-> [email protected]_immed(wl_buffer@42, 1897, 2130, 875713089, 0) -> [email protected]_immed(wl_buffer@43, 1897, 2130, 875713089, 0) 875713089 = 0x34325241 = AR24 = DRM_FORMAT_ARGB8888. Both hops use the same format; the wl_shm path is not used at all in this run (wl_shm_pool occurrences: 0, zwp_linux_buffer_params_v1: 22). The surface is clean — attach/damage_buffer/frame/commit only. Nothing calls wl_surface.set_opaque_region (0 occurrences in the trace, and the satellite source contains no such call). 2. A/B: only the buffer path changes the result. Test window: a root X window with a 32-bit TrueColor visual, content = fully transparent black plus one opaque coloured square. In both runs the window ends up tiled at 1265x1420 logical and focused; grim captures are compared before/after the window appears. "New black" = pixels that were not near-black before and are near-black after.

Xwayland rendering path	buffer format	new black on screen
glamor (default) → linux-dmabuf	AR24	46.0 % (≈ the entire window area, 48.7 %)
-glamor none → wl_shm	AR24	9.9 %

The 9.9 % in the shm run is not window content: it matches niri's own window shadow (layout { shadow { size … } }), i.e. the transparent content composited correctly and only niri's shadow was added. With dmabuf, the window content itself was black.