update, as of 2.17.5 "intermittent flashes of a stale/past frame in the left eye" part seems to be fixed, ive also identified headswim is due to steamvr defaulting to 90hz mode while bsb was configured to be in 75hz mode, making beyond be in 90hz mode is a likely workaround for headswim
the issue now appears on my Valve Index how however it appears in the menus and now VRChat crashes the dashboard when launching VRChat. I used a backup to restore a older version of the beta to fix the issue
1785799196 (current client log build)2.17.5, build ID 1784326967, SteamVR beta branch7.1.8-1-cachyos26.1.7-1steamvr-linux-fixes-layer-bin 0.1.4-1the version from my system info is working perfectly fine and if that was released to the stable branch or if updates were paused for that version it would be fine but something broke in recent updates
Nothing extracted yet.
Describe the bug
SteamVR's normal Linux launch path does not actually enable asynchronous reprojection on Bigscreen Beyond 2e. Async can be enabled through SteamVR's
vrstartup-helper.shentry point, but neither state is usable in low-frame-rate VRChat scenes (or other poorly optimized VR games):There is also persistent head-relative latency/head-swim in both states.
There appear to be two related problems:
To Reproduce
Use native Steam, SteamVR, RADV, and a wired Bigscreen Beyond 2e on Linux.
Opt into the SteamVR beta branch.
Set the following under the
steamvrobject in~/.local/share/Steam/config/steamvr.vrsettings:Launch SteamVR normally through Steam.
Launch VRChat and enter a scene that runs below the headset refresh rate (I had 38 FPS thanks vrchat).
Move your head.
Result with the normal Steam launch path
Async reprojection is not actually enabled. SteamVR logs:
The normal SteamVR launch starts the compositor with
NoNewPrivs=1and withoutCAP_SYS_NICE, even thoughvrcompositor-launcherhascap_sys_nice=eipon disk. The compositor cannot create its high-priority Vulkan queue and falls back to non-async behavior. At low frame rate this adds severe double images while turning the head; the separate head-swim/latency issue is also present.vrstartup-helper path to reproduce the async-on result
This is included only to demonstrate the launch-path defect and make the actual async behavior reproducible. It should not be necessary for a native SteamVR installation.
Install SteamVRLinuxFixes (on Arch:
steamvr-linux-fixes-layer-bin) and setenableLinuxVulkanAsync=trueas above.Grant the compositor launcher the documented high-priority capability:
Do not use Steam's normal SteamVR Play button. Keep Steam running, but launch SteamVR's own helper directly from the desktop session:
Re-run VRChat at the same low frame rate and turn your head.
There is no queue-permission error or fallback afterward. The severe double images are no longer the failure mode, but the left eye periodically flashes a stale/past frame. The persistent head-relative latency/head-swim remains.
Expected behavior
enableLinuxVulkanAsync=trueshould work when SteamVR is launched normally from the native Steam client, without a custom direct launcher or pressure-vessel bypass.System Information
1782866176(current client log build)2.17.3, build ID23899461, SteamVR beta branch7.0.10-2-cachyos26.1.1-1Bigscreen Beyond)steamvr-linux-fixes-layer-bin 0.1.4-1runtimediag.txt
steam-logs-2026-07-10.tar.gz
steam-minidumps-2026-07-10.tar.gz
Additional context
CAP_SYS_NICEthrough the SteamLinuxRuntime Sniper / pressure-vessel handoff for SteamVR's capability proxy, or provide a supported way to create the high-priority Vulkan queue.VK_KHR_present_wait/ SteamVRLinuxFixes. The layer is part of the workaround required to test async here, but it does not resolve the persistent head-swim or intermittent left-eye stale-frame artifact.