possibly related to #this https://github.com/ValveSoftware/gamescope/issues/2171

Same thing here on a 5090, driver 610.43.03. I'm on publicbeta and the original
report is on stable, so it isn't branch-specific.

Steam 1.0.0.87 (build 1785347151) / Arch, kernel 7.1.5 / Plasma + KWin 6.7.3,
Wayland session, Steam on Xwayland 24.1.13 / RTX 5090, nvidia 610.43.03 / 2560x1440.

Not the software-fallback bug, webhelper_gpu.txt from this session:

gpu_compositing : enabled
rasterization   : enabled
opengl          : enabled_on
webgl / webgl2  : enabled
GL_RENDERER     : ANGLE (NVIDIA Corporation, NVIDIA GeForce RTX 5090/PCIe/SSE2, OpenGL 4.5.0 NVIDIA 610.43.03)
GL_VERSION      : OpenGL ES 2.0.0 (ANGLE 2.1.23105)

I grabbed the Steam window off the X server with import -window, which reads
what Steam drew before KWin composites it. The black is already there, so it's
coming from CEF rather than the compositor.

Drawer open at 2560x1440, it covers x=0..568. Same rows inside vs outside that range:

There's also a 22px black seam at x=547..568, exactly the drawer's right edge.
Header and footer draw correctly everywhere except where the drawer overlaps
them, and there it's precisely RGB(0,0,0). Two translucent layers on top of each
other come out opaque black.

Caught the animation windowed at 1280x800, 86 frames: 54 had a solid black column
or band, 7 of them with the whole 240px drawer region black, and every black run
ends at x=239, again the drawer's right edge. So during the slide the content
shifts right and the space it leaves paints black instead of the translucent
panel over the blurred background.

Also reproduces under gamescope --backend wayland -W 2560 -H 1440 -f -e -- steam -gamepadui (gamescope 3.16.25). Separate Xwayland, separate compositor, same
black, so nothing on the desktop side is involved.

Tried without success: every display and interface setting including UI scale and
reduce motion, windowed mode via both the in-UI toggle and -windowed, gamescope,
and -enable-desktop-gl-fallback (accepted, but GL_RENDERER stays ANGLE/GLES2
byte-identical, so that path looks gone in this CEF build).
STEAM_ENABLE_WAYLAND_IN_GAMEPADUI doesn't exist in 1.0.0.87 at all, zero
references in steam, steamui.so or steamwebhelper.

One dead end worth flagging so nobody else burns an afternoon on it:
tile_manager.cc: tile memory limits exceeded, some content may not draw fires
430 times in a fullscreen session and reads like an exact match for the symptom.
Windowed produces zero of them and the black is still there, so it tracks surface
size, not this bug.

This looks like the same defect as ValveSoftware/gamescope#2171 (alpha blending failure, black
rectangles behind Steam overlays on NVIDIA, not reproducible on AMD or Intel),
which fits the reports here that Deck and Intel iGPU render the drawer fine.

Adding a full root cause for this, building on @ExTV's finding that the black comes from CEF rather than the compositor.

Root cause: the popup BrowserView windows are created with a depth-24 (no-alpha) visual

Big Picture's affected surfaces — the two sidebars, notification toasts, and Steam Input radial/sector overlays — are separate CEF BrowserView popups drawn over the main page. Their page backgrounds are transparent (rgba(0,0,0,0), confirmed live via CEF remote debugging). On NVIDIA, CEF creates these popup windows with a depth-24 X visual, which has no alpha channel, while the main Big Picture window correctly gets a depth-32 ARGB visual:

0x2200049  depth 32   3840x2160   Steam Big Picture (main)   ✓ alpha
0x1800005  depth 32   3840x2160   main content child         ✓ alpha
0x1800012  depth 24   615x2161    left sidebar               ✗ no alpha
0x180001f  depth 24   820x205     notification toast         ✗ no alpha

With no alpha channel to store it, the transparent content flattens to opaque black. A depth-32 ARGB visual does exist on the X server (CEF uses it for the main window) — CEF's X11 backend simply doesn't select it for the popups. On Mesa the selection lands on depth-32, which is why this is NVIDIA-only, and why it's invisible on a normal desktop (the opaque window just sits on a background) but obvious in gamescope / when the popup is meant to composite over the page.

Verification chain (each step measured, not inferred)

1. CEF remote debugging (.cef-enable-remote-debugging, DevTools on localhost:8080): getComputedStyle on the popup pages reports backgroundColor: rgba(0, 0, 0, 0) — the pages intend transparency.
2. Live CSS injection of a 30%-opacity background into a popup renders fully opaque on screen — the surface has no working alpha to composite with:

1. xwininfo on the popup windows shows depth-24, while the main window is depth-32 (table above).
2. The buffer that reaches the compositor is ARGB8888 with the alpha already written opaque — consistent with CEF having had nowhere to store real alpha.

What was ruled out (in case it saves anyone the repeat)

Extensive testing on gamescope (RTX 5080, nvidia-open 610.57.04, CachyOS) eliminated everything downstream of CEF:

• Compositor GPU — reproduces with gamescope on an Intel iGPU while CEF renders on an NVIDIA dGPU (PRIME). The compositor's GPU is irrelevant; it tracks the client's producing driver.
• Buffer format / alpha mislabeling — the buffer arrives ARGB8888 (alpha-bearing), verified before any modification. Not an XRGB labeling issue.
• Compositor blend — premultiplied-over math is correct; forcing the base layer un-premultiplied, and compositing it over an opaque backdrop, both left the region black.
• Shader out-of-bounds "black border" sampling — visualized via the plane-border debug (turns such pixels magenta); the region stayed black, so it isn't border-sampled.
• Explicit / implicit sync — both surfaces negotiate wp_linux_drm_syncobj_v1; forcing a CPU wait on the acquire point changed nothing. (NVIDIA attaches dma_resv fences only via an explicit ioctl, so implicit-fence waits are moot on it anyway.)
• _NET_WM_OPAQUE_REGION — Steam does not set it.
• CEF child-window compositing — forcing XCompositeRedirectSubwindows(parent, Automatic) to fold the children into the parent pixmap: no change.
• GLX fbconfig ordering — NVIDIA's glXChooseFBConfig returns depth-24 alpha configs before depth-32 ones; an LD_PRELOAD shim reordering so a depth-32 config is first did not fix it, because the popups aren't created through that fbconfig path.
• Forcing depth-32 at XCreateWindow — didn't reach the popups: Chromium uses its own X11 protocol backend (ui/gfx/x/, builds CreateWindow requests internally over the xcb socket), so neither Xlib nor xcb window-creation calls can be interposed.
• CEF GL backend — --use-gl=angle --use-angle=vulkan shifted the symptom (black stopped lingering) but dropped the UI to ~10 fps; --use-gl=egl didn't help; -cef-disable-gpu (software) fixes it but pins a CPU core at 4K.

Where it lives / fix direction

The depth-24 visual selection is in Chromium's compiled X11 backend (ui/gfx/x/), so it can't be worked around by interposing a library. It appears to be a Chromium X11 transparent-visual selection issue for popup/child windows, exposed on NVIDIA and surfaced by Steam's transparent BrowserView popups. Candidate fixes: a newer CEF/Chromium (this class of bug may already be fixed upstream), a Chromium patch, or Steam requesting an ARGB (depth-32) visual for the popup views.

Happy to run any targeted test — the DevTools + xwininfo repro is deterministic and takes seconds.

FWIW, we're aware of this issue, but I'm not personally familiar with the details. I've asked my co-worker to comment here if he has anything further to share.