Related: #963 (Desktop tab segfaults the Steam client on the same setup) and ValveSoftware/steam-for-linux#13643 (host retries the Wireless Adapter link every 60 s while the headset is asleep). An anonymized log bundle covering all three is available on request.
Additional data point (2026-09-24 23:40, SteamVR 2.18.1 beta): the same happens with the title's OpenXR launch configuration (launch argument openxr, Unity OpenXR plugin). With no SteamVR running, Proton's OpenXR bridge reports the runtime as absent instead of starting it:
[XR] xrEnumerateInstanceExtensionProperties: XR_ERROR_RUNTIME_UNAVAILABLE (4x)
[XR] xrCreateInstance: XR_ERROR_RUNTIME_UNAVAILABLE
Failed to load XR. Trying again with Oculus...
The game then falls back to a flat window and Steam logs CRemoteClientJobStartStream timed out k_ERemoteClientWaitVRConnectionReady 24 s after launch. XR_RUNTIME_JSON in the game's environment points at SteamVR's steamxr_linux64.json, so the runtime is registered; it just is not running. So neither the OpenVR nor the OpenXR path lets a Proton title bring SteamVR up on a Linux host; the host has to start it for the headset.
The issue SteamVR needing to be run before launching a game is known and we are working on a fix.
We don't have an exact eta for when this will be released, but I have made a note and will try to respond here when it has been published. For now, you'll want to make sure SteamVR is launched before starting a game.
Confirming gap 2 on a different host, plus one log line that may help pin it down.
Host
rtw89_8852cu, firmware 0.27.125.0Gap 1 reproduces verbatim — this install ships only a linux64 build:
vrclient_steam.txt:
Unable to load driver vrlink. Primary driver shared library not found on filesystem
(for this architecture): .../SteamVR/drivers/vrlink/bin/linux32/driver_vrlink.so.
Unable to init watchdog mode for driver vrlink: VRInitError_Init_FileNotFound
No drivers were capable of being watchdogs. Failing init.
drivers/vrlink/bin/ contains only linux64/.
Gap 2, with Steam already started -pipewire -vrlinkforceenable and SteamVR started manually first
Launching Blade & Sorcery (appid 629730, Proton Experimental) from the headset: the game opens an OpenXR instance and tears it down within a millisecond, twice in a row.
21:06:39.449 vrclient type=VRApplication_OpenXRInstance
21:06:39.449 Skipping HMD presence checks.
21:06:39.451 Received success response from vrserver connect
21:06:39.452 App key after connect message:steam.app.629730
21:06:39.455 [SteamVR] XrViewConfigurationView recommendedImageRect: 2644 2644
21:06:39.456 xrCreateInstance: Application is requesting the following extensions:
21:06:39.456 XR_KHR_vulkan_enable, XR_KHR_vulkan_enable, XR_KHR_vulkan_enable
21:06:39.456 VR_Shutdown called
21:06:41.806 (identical sequence, second attempt)
21:06:41.813 VR_Shutdown called
The game never becomes the scene application. What is streamed to the headset for the next three minutes is the Steam UI — the user sees the Steam panels, not the game:
Destroying overlay F00000009 valve.steam.gamepadui.main
Destroying overlay 140000000E valve.steam.gamepadui.keyboard
Destroying overlay 1600000010 valve.steam.gamepadui.bar
... (at 21:09:52, "because that process disconnected")
The process list during that window contains vrdashboard, vrcompositor, vrserver, wineserver and xalia.exe, but no game process.
The line that may be new here
Input bindings are never loaded for the app, which is why the controller pointer stays dead while the Steam panels are visible:
21:06:39.337 SetApplicationPid appkey=steam.app.629730 pid=88175, external transition
21:06:39.337 [Input] LoadActionManifest failed. Could not find action manifest
for app '88175: wine-preloader' with key 'steam.app.629730'
21:06:39.451 SetApplicationPid appkey=steam.app.629730 pid=88954, external transition
21:06:39.451 [Input] LoadActionManifest failed. Could not find action manifest
for app '88954: wine64-preloader' with key 'steam.app.629730'
The app key resolves to the Proton preloader rather than the game, so the manifest lookup misses.
Isolating it to the Proton/OpenXR path
On the same host, same adapter, same SteamVR and the same -vrlinkforceenable startup, a native Linux title (Half-Life: Alyx, appid 546560) enters VR without any problem and plays normally. So on this host gap 2 is specific to the Proton/OpenXR route, not to the Frame session or the adapter link.
(The native session does show the periodic stream resets of #965, which appears to be independent of the title.)
On the multi-interface observation in the original report
This host binds vrlink to five interfaces (LAN, Tailscale, docker0, a docker bridge, the adapter) and does produce Received event indicating network change. But measuring it per-second across two sessions, only 1 of 61 and 1 of 21 reset bursts fall within 3 s of such an event, and the stream stayed on Found primary link FRAME_SUBNET.26 throughout with 0 Mbit/s on every other interface. On this host the multi-interface binding is not what drives the resets. Being able to pin vrlink to the adapter would still be useful.
Full anonymized logs and a per-second capture of both sessions available on request.
A fix for the original issue is currently being worked on, as a result I'll close this issue but will try to respond here when it is live in a steamvr release.
Retest on AMD. I replaced the display GPU in this host with an RX 9070 XT (Mesa 26.2.2 / RADV). The RTX 3090 stays in for CUDA only. Same Arch/KDE Wayland host, Steam beta, SteamVR 2.18.1 beta and 2.17.10 stable, Steam Frame over the Wireless Adapter.
-vrlinkforceenable. The manual workaround (start SteamVR first, then launch from the headset) still works.vkerror=-4 compositor crash hasn't reappeared. That part looks NVIDIA-driver-specific.allowMultipleLinks on, every netlink event on any interface triggers a vrlink link re-evaluation plus a reset burst. allowMultipleLinks: false alone isn't enough to pin the stream to the adapter, though. vrlink still binds every interface and commits to whichever link answers first. If SteamVR starts before the adapter link is up (for example, right after a headset update and reboot), it locks onto the LAN Wi-Fi for the whole session. What reliably pins it to the adapter here is a local firewall rule that drops vrlink's UDP port 10400 outside the adapter's 10.35.78.0/24 subnet. A setting to restrict vrlink to the adapter interface would make that unnecessary.Some extra info in case it proves useful: Two Linux-desktop details that belong with this issue, from CachyOS / Plasma Wayland / RX 9070 XT on 2.18.1 and 2.18.2 beta:
XR_ERROR_RUNTIME_UNAVAILABLE until Steam itself ran with PRESSURE_VESSEL_IMPORT_OPENXR_1_RUNTIMES=1 in its environment (not set by default for a desktop Steam). With it, the host OpenXR runtime is imported into the pressure-vessel container and the same titles start in VR.-vrlinkforceenable. SteamVR then restarts on top of it and Proton titles fail the scene handover (SetXrInputConfig failed): audio in the headset, no picture. Checking Steam's command line before blaming the game saves time.proton experimentalx1 2026-09proton hotfixx1 2026-09
Describe the bug
On a non-SteamOS Linux desktop host, launching a PC VR title from a Steam Frame never starts SteamVR. Steam launches the game, waits for the VR connection, and after ~40–60 s logs
CRemoteClientJobStartStream timed out k_ERemoteClientWaitVRConnectionReadyand kills the game. The headset stays on the "opening game" panel. 2D game streaming to the Frame over the same adapter link works.Two gaps combine to cause this:
Steam never calls StartSteamVR on this platform. The Steam client's 32-bit watchdog cannot load the vrlink driver because only a linux64 build ships:
Starting Steam with the undocumented
-vrlinkforceenableflag ("Force-enable VR Link capability for testing regardless of platform/encoder") lets the Frame attach to a running SteamVR and stream, but does not make Steam start SteamVR for a game launched from the headset (re-verified on 2.18.1 beta, see below).Proton titles cannot start SteamVR themselves. Proton's OpenVR bridge only connects to an already-running vrserver:
The game falls back to a flat window, which Steam streams as a 2D desktop stream until the timeout kills it.
Working sequence found: Steam started with
-pipewire -vrlinkforceenable, SteamVR started manually on the desktop first, then the game launched from the headset. The game then runs in VR on the Frame over the 6 GHz adapter link.Re-tested on SteamVR 2.18.1 beta (2026-09-24 22:52) — unchanged. Game process starts 22:52:29, no vrserver is started, timeout at 22:53:06, game removed at 22:53:04. Starting SteamVR manually (22:53:13) and relaunching from the headset (22:53:45) gives a working VR session until the game was quit at 23:04:39.
To Reproduce
remote_connections.txt.Expected behavior
Steam starts SteamVR for the Frame session (as on SteamOS/Windows), the Proton title initializes OpenVR against it, and the headset shows the game.
System Information
Additional context
allowMultipleLinkson, vrlink treats every netlink event on any host interface as a network change (SVLDataLinkUber: Received event indicating network change). On this host the LAN Wi-Fi's IPv6 SLAAC lifetime refreshes fire every 60–90 s; the 11 netlink events and the 11 vrlink network-change events in the 22:53–23:04 session match 1:1 by timestamp, and each lines up with aReset video streamburst from the headset (a visible micro-stutter), although the stream stayed on the adapter link (Found primary link FRAME_SUBNET.x) the whole time.Found primary link LAN_IP), which is far worse than the adapter link. A way to pin vrlink to the adapter interface, or to ignore address-lifetime refreshes on other interfaces, would help on hosts with several interfaces.steamwebhelperaborts (SIGABRT) and SteamVR logs "Destroying overlay ... valve.steam.gamepadui.* because that process disconnected"; the Steam dashboard panels stay missing until SteamVR is restarted (seen 2026-09-23 17:43:33 and 2026-09-24 22:45:45).Xid 32(invalid push buffer stream) against vrcompositor:Failed GetDeltas(Compositor): vkerror=-4,Submit: Failed to submit to queue,ASSERT: "Unexpected failure when checking for timeline signal" vksync.cpp:213, then SIGSEGV on RenderThread; the next start failed withVRInitError_Compositor_CreateDriverDirectModeResolveTextures, the third worked. Likely the same family as #944.