Electron/Chromium native Wayland GPU context loss under Steam Linux Runtime 4 on NVIDIA; XWayland and --disable- gpu avoid failure

[mgeldi]

Your system information

• Steam Runtime Version: Steam Linux Runtime 4.0 4.0.20260507.232683, pressure-vessel 0.20260505.0
• Distribution (e.g. Ubuntu 18.04): CachyOS, rolling, Arch-like
• Link to your full system information (Help -> Steam Runtime Diagnostics) in a Gist: The Gist containing relevant Runtime Diagnostics
• Have you checked for system updates?: Yes
• What compatibility tool are you using?: Steam Linux Runtime 4.0, native Linux app, not Proton
• What versions are listed in steamapps/common/SteamLinuxRuntime/VERSIONS.txt?

#Name           Version             Runtime Runtime_Version Comment
depot           1.0.20260430.230225
LD_LIBRARY_PATH 1.0.20260430.230225 scout   1.0.20260430.230225 # steam-runtime/
scripts         0.20260430.0

• What versions are listed in steamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt?

#Name                 Version             Runtime Runtime_Version Comment
depot                 2.0.20260507.232681
pressure-vessel       0.20260505.0
pressure-vessel-arm64 0.20260505.0
scripts               0.20260505.0
soldier               2.0.20260507.232681 soldier 2.0.20260507.232681 # soldier_platform_2.0.20260507.232681/

• What versions are listed in steamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt?

#Name                 Version             Runtime Runtime_Version Comment
depot                 3.0.20260507.232682
pressure-vessel       0.20260505.0
pressure-vessel-arm64 0.20260505.0
scripts               0.20260505.0
sniper                3.0.20260507.232682 sniper  3.0.20260507.232682 # sniper_platform_3.0.20260507.232682/

• What versions are listed in steamapps/common/SteamLinuxRuntime_4/VERSIONS.txt?

#Name                 Version             Runtime  Runtime_Version Comment
depot                 4.0.20260507.232683
pressure-vessel       0.20260505.0
pressure-vessel-arm64 0.20260505.0
scripts               0.20260505.0
steamrt4              4.0.20260507.232683 steamrt4 4.0.20260507.232683 # steamrt4_platform_4.0.20260507.232683/

Additional system details:

Kernel: Linux 6.18.34-1-cachyos-lts x86_64
GPU: NVIDIA GB202 [GeForce RTX 5090]
NVIDIA driver: NVIDIA UNIX Open Kernel Module 610.43.02
App: ThiccThocc, native Linux Steam app, app ID 4548640
Frontend runtime: Electron 42.3.3

Please describe your issue in as much detail as possible:

A native Linux Steam app using Electron 42.3.3 crashes or becomes unusable when launched through Steam Linux Runtime 4.0 with Chromium/Electron native Wayland enabled on an NVIDIA system.

The failure appears to happen in Chromium's GPU/Skia/ANGLE path. The app works when forced to X11/XWayland. It also works when forced to native Wayland with GPU disabled. Disabling VAAPI does not fix it.

Expected result:

The Electron app should render normally under native Wayland inside Steam Linux Runtime 4.0.

Actual result:

Native Wayland fails in the Chromium GPU compositor path, then the detached Electron GUI exits with SIGTRAP.

Relevant log excerpt from slr-app4548640-t20260608T192616.log:

2026-06-08T17:26:17.428Z INFO [runtime] PRESSURE_VESSEL_RUNTIME=steamrt4_platform_4.0.20260507.232683
2026-06-08T17:26:18.258Z INFO [electron] skipping --ozone-platform=x11 force (THICCTHOCC_OZONE_PLATFORM_HINT set; Electron main owns ozone selection)
2026-06-08T17:26:18.346Z INFO [electron]: [thiccthocc-frontend] ozone-platform=wayland (THICCTHOCC_OZONE_PLATFORM_HINT)
2026-06-08T17:26:19.185Z INFO [electron]: [electron] main reveal (did-finish-load-fallback): show()
2026-06-08T17:26:19.188Z WARN [electron]: [307425:0608/192619.188440:ERROR:media/gpu/vaapi/vaapi_wrapper.cc:1658] vaInitialize failed: unknown libva error
2026-06-08T17:26:19.340Z WARN [electron]: [307425:0608/192619.340149:WARNING:ui/gl/angle_platform_impl.cc:52] FramebufferGL.cpp:1327 (checkStatus): GL framebuffer returned incomplete: 0x00008CD6
2026-06-08T17:26:19.340Z WARN [electron]: [307425:0608/192619.340163:ERROR:gpu/command_buffer/service/shared_image/shared_image_representation.cc:408] Unable to initialize SkSurface
2026-06-08T17:26:19.340Z WARN [electron]: [307425:0608/192619.340311:ERROR:gpu/command_buffer/service/raster_decoder.cc:1115]   RasterDecoderImpl: Context lost during MakeCurrent.
2026-06-08T17:26:19.340Z WARN [electron]: [307425:0608/192619.340390:ERROR:gpu/ipc/service/shared_image_stub.cc:579] SharedImageStub: context already lost
2026-06-08T17:26:44.770Z WARN [electron] detached GUI exited with signal: 5 (SIGTRAP) (core dumped)

The app also has a native Wayland canary. On this system, the canary detects the failure and falls back to X11/XWayland:

[electron-canary]: [thiccthocc-frontend] ozone-platform=wayland
[electron-canary]: [thiccthocc-frontend] display-canary failed reason=UnknownVizError
[electron] native Wayland probe failed reason=exit_status:exit status: 70; falling back to X11/XWayland
[electron]: [thiccthocc-frontend] ozone-platform=x11

Comparison:

Works:
- Steam Runtime 4 + X11/XWayland
- Steam Runtime 4 + native Wayland + GPU disabled

Fails:
- Steam Runtime 4 + native Wayland + GPU enabled
- Steam Runtime 4 + native Wayland + VAAPI disabled

This does not look like only a VAAPI/video-decoding issue. It looks more like Chromium GPU compositing / Skia / ANGLE / GL context loss on native Wayland, possibly involving pressure-vessel host-driver integration, NVIDIA, or Electron/Chromium.

Timeline note: during earlier SteamRT4 testing there was a short period where native Wayland appeared to work, or at least appeared usable enough that I did not notice this failure. The available Steam console logs show native Wayland / auto-Wayland testing on SteamRT4 by 2026-05-31 with steamrt4_platform_4.0.20260415.225012; those runs already contain Unable to initialize SkSurface / Context lost during MakeCurrent messages, although the window sometimes reached main reveal before failing. By 2026-06-08 on steamrt4_platform_4.0.20260507.232683, the failure is reliably caught by the native Wayland canary as UnknownVizError, or crashes with SIGTRAP when Wayland is forced. I am not sure whether the relevant change was a Steam Runtime update, NVIDIA driver update, app/Electron changes, or intermittent driver/runtime state. I do not want to assign blame here; I am mentioning it in case it helps correlate with runtime or driver changes. I'm mentioning this point, because the issue was already present with the Steam Linux Runtime 3 (sniper). When the SteamRT4 came out, I switched to it - and it was working during this brief period.

Additional observation: during one reproduction run started via STEAM_LINUX_RUNTIME_LOG=1 steam, VRAM usage unexpectedly filled almost completely and appeared to be attributed to the app after opening Steam Runtime Diagnostics. I could not reproduce this on a later restart, so this may be intermittent driver/runtime state rather than a deterministic app leak.

I can provide the full STEAM_LINUX_RUNTIME_LOG=1 logs and a minimal Electron repro if useful.

Attached/provided in Gist:

steamlinuxruntime_diagnostics
slr-app4548640-t20260608T192616.log
slr-app0-t20260608T192043.log
steam-runtime-system-info-1780939394.txt

Steps for reproducing this issue:

1. Start Steam from a Wayland desktop session on an NVIDIA system with Steam Runtime logging enabled:

STEAM_LINUX_RUNTIME_LOG=1 steam

2. Launch ThiccThocc Keyboard Studio through Steam Linux Runtime 4.0. (Note: it isn't public yet, I'll submit the app soon for Valve review. Hopefully, this can still help)

3. Force Electron native Wayland with launch options equivalent to:

THICCTHOCC_OZONE_PLATFORM_HINT=wayland %command%

4. Observe Chromium/Electron GPU errors and GUI crash:

FramebufferGL.cpp ... GL framebuffer returned incomplete: 0x00008CD6
Unable to initialize SkSurface
RasterDecoderImpl: Context lost during MakeCurrent.
detached GUI exited with signal: 5 (SIGTRAP) (core dumped)

5. Compare with X11/XWayland:

THICCTHOCC_OZONE_PLATFORM_HINT=x11 %command%

This works.

6. Compare with native Wayland plus GPU disabled:

THICCTHOCC_OZONE_PLATFORM_HINT=wayland THICCTHOCC_ELECTRON_DISABLE_GPU=1 %command%

This also works.

7. Compare with native Wayland plus VAAPI disabled:

THICCTHOCC_OZONE_PLATFORM_HINT=wayland THICCTHOCC_ELECTRON_DISABLE_VAAPI=1 %command%

This still fails.

[smcv]

native Wayland

Native Wayland is not recommended for Steam games, because the Steam Overlay LD_PRELOAD module (and therefore Steam features that rely on it, like Steam Input) has the limitation that it assumes and requires X11 + GLX or X11 + Vulkan. It doesn't currently understand EGL, either X11 + EGL or Wayland + EGL. (See also ValveSoftware/steam-for-linux#8020)

If you force the LD_PRELOAD module to be completely disabled, does that make any difference? Disabling it in the Steam UI is not enough, you'd have to use something like Launch Options = LD_PRELOAD=/nonexistent %command% (that should produce error messages about being unable to load /nonexistent, which you can use as confirmation that it has taken effect).

Steam Linux Runtime 4.0

Or, does opting in to the public beta branch for this compatibility tool make any difference?

The available Steam console logs show native Wayland / auto-Wayland testing on SteamRT4 by 2026-05-31 with steamrt4_platform_4.0.20260415.225012; those runs already contain Unable to initialize SkSurface / Context lost during MakeCurrent messages, although the window sometimes reached main reveal before failing.

Are you saying that with steamrt4_platform_4.0.20260415.225012, the issue you're reporting didn't happen, so it's a regression (either in SLR, or in some other component that changed) between then and now? Or was 4.0.20260415 already not working, but with less-bad symptoms?

By 2026-06-08 on steamrt4_platform_4.0.20260507.232683, the failure is reliably caught by the native Wayland canary as UnknownVizError, or crashes with SIGTRAP when Wayland is forced

The changes between 4.0.20260415 and 4.0.20260507 are in the release notes. Nothing in there jumps out at me as a likely cause, unless your Electron/Chromium build uses SDL?

As you said, this might be some other factor, like an OS or driver upgrade, or a change to your codebase.

You could confirm whether this is a SLR regression by moving steamapps/common/SteamLinuxRuntime_4 out of the way, and replacing it with the result of unpacking an older SteamLinuxRuntime_4.tar.xz from https://repo.steampowered.com/steamrt4/images/. The older version you used for your successful (?) test should be https://repo.steampowered.com/steamrt4/images/4.0.20260415.225012/SteamLinuxRuntime_4.tar.xz for example.

[smcv]

This does not look like only a VAAPI/video-decoding issue

As a side note, we don't expect VA-API to work on the Nvidia proprietary driver: on that driver, video acceleration is either VDPAU (legacy, only for X11 I think), CUDA, or maybe something Vulkan-related. The Nvidia proprietary driver doesn't contain a VA-API driver module.

There's a third-party VA-API module that is sometimes used by users of the Nvidia proprietary driver, but we can't use that in the Steam Linux Runtime (we intentionally exclude it) because its dependencies are too complicated, and pulling them in would defeat the purpose of providing a stable runtime environment.