Hi @kisak-valve - if I'm reading #855 (which points to #836) correctly, one recommended workaround is using Mesa 25.2.x… but I already am? Kubuntu 24.04 LTS has 25.2.8-0ubuntu0.24.04.1.

Otherwise, let me know if there's anything I can test to help with troubleshooting, and feel free to merge this issue with another one if it feels like a duplicate.

Quick note - as probably expected, this still happens with SteamVR beta 2.16.2.

I am also seeing the same, nearly identical issue with both 2.16.1 and 2.16.2 but using the latest stable NVIDIA driver (595.58.03) with Gentoo Linux. It seems vrcompositor crashes a few seconds after starting SteamVR. Rolling back to version 2.15.6 works fine.

steamvr_crash_dump.tar.gz

SteamVR-2026-04-10-PM_03_52_13.txt

Still relevant on 2.16.3.
Both the previous and public branch work fine.
Edit: Launching SteamVR kind of works, but actually waking the Steam Index headset causes a -203 error.

steam-logs.tar.gz
steam-minidumps.tar.gz
steam-runtime-diagnostic.txt

Also getting this crash. Starting SteamVR appears to work (no home + Steam menu open) but as soon as I try to run something, then SteamVR crashes with -203

Fedora 44
RTX 3090, Nvidia open driver 595.58.03
HTC Vive, SteamVR 2.16.3

Tried disabling the iGPU (desktop PC, wasn't using it but it still showed up in nvtop).
Tried "enableLinuxVulkanAsync" : false

SteamVR 2.15.6 (stable) works
SteamVR 2.12.? (previous) works

@kisak-valve ASSERT: "Unhandled sampler filter type!" is present in my 2.15.6 logs too so it might not be directly related to the crash, but I only have ASSERT: "IsDepthFormat(eVkFormat)" in 2.16.3 logs

vrcompositor_2.15.6.txt
vrcompositor_2.16.3.txt

I've at least gone and fixed the unhandled sampler type assert. I don't think it's the culprit here, but I'm tired of seeing it turn up in logs, and it was a legitimate bug. Hopefully that'll get into the next beta.

Hallelujah, I now have a consistent repro case for this. (The sampler is definitely not the cause.) Now just to find a fix for it. :)

@JohanAR - If you explicitly set "enableLinuxVulkanAsync" to true, do you still see this? Just to narrow something down.

I have the same issue as JohanAR except I'm using an AMD GPU. While on the current beta of SteamVR, setting enableLinuxVulkanAsync to true results in SteamVR starting and running fine, except that on my Index there is no visual output. The screens are slightly illuminated and I can hear sound. On the surface it looks similar to https://github.com/ValveSoftware/SteamVR-for-Linux/issues/855.

Imagine a suitable "victory dance" .gif in place of this comment.

Thanks for your attention to this.

Can confirm, 2.16.3 no longer crashes on application launch with enableLinuxVulkanAsync enabled, but it gets pretty bad tearing and the default SteamVR environment (what's it called when home is disabled?) gets doublevision when I move the head. I assume that's already known and a separate issue.

I do still experience the same error even with enableLinuxVulkanAsync enabled or explicitly disabled on 2.16.3.

Sat Apr 18 2026 16:38:37.064304 [Error] - ASSERT: "IsDepthFormat(eVkFormat)" at /data/src/common/vrcommon/vrrenderer/vulkanrenderer.cpp:762.
Sat Apr 18 2026 16:38:43.479140 [Info] - Failed Watchdog timeout in thread Render in WaitForPresent after 6.231145 seconds. Aborting.

I'm on Arch Linux with Mesa 26.0.4. That may explain why my system reacts differently?

I'm on Arch Linux with Mesa 26.0.4. That may explain why my system reacts differently?

26.0.5 recently fixed #836, can you try it with that version?

@JohanAR - Yeah, I've seen that behavior -- I mostly just wanted to narrow down that what you were seeing was the same thing I found. The fact that it worked (for certain definitions) with enableLinuxVulkanAsync set to true was enough to confirm that.

I suspect others are seeing the same issue, but I'll definitely want to hear back when we get that fix out to see if it does address the issue for them, or if there's something else concealed under similar behavior.

I'm on Arch Linux with Mesa 26.0.4. That may explain why my system reacts differently?

26.0.5 recently fixed [#836](https://github.com/ValveSoftware/SteamVR-for-Linux/issues/836), can you try it with that version?

Tried, first attempt resulted in the error described here. Every subsequent attempt results in what I wrote before: Only dim lights, nothing else.

What does error 203 actually mean btw? Is it some kind of catch-all for render thread stalls or semaphore misuse etc?

I'm also getting this error code in my own application after I tried adding Pipewire ScreenCast support. I assume I'm doing something wrong and probably not related to this bug, but I noticed a similar pattern. The ScreenCast in my app breaks after it has been running with all version, but only in some cases it causes the SteamVR to crash.

SteamVR 2.12.14 - Does not crash
SteamVR 2.15.6 - Only crashes when enableLinuxVulkanAsync = false, survives when true.
SteamVR 2.16.3 - Crashes when enableLinuxVulkanAsync = false (did not try true)

It would of course be nice if SteamVR always survived if an app is misbehaving. Unfortunately I couldn't find anything that looked related in the logs.

Edit: The bug in my code seems like it was that a dma-buf VkImage being destroyed while the extension device still had in-flight commands reading it.

SteamVR 2.16.3 worked with enableLinuxVulkanAsync set to true! And.. this might be my imagination, but my CPU-bound system felt kind of smoother despite only hitting 23-28 FPS in VRChat.

--- /home/user/.local/share/Steam/config/steamvr.vrsettings
+++ /home/user/.local/share/Steam/config/steamvr.vrsettings.new
@@ -6,6 +6,7 @@
    },
    "steamvr" : {
       "analogGain" : 1,
+      "enableLinuxVulkanAsync" : true,
       "installID" : "77XXXXXXXXXXXXXXXXX",
       "lastVersionNotice" : "2.16.3",
       "lastVersionNoticeDate" : "1776117938",

If this is the way Valve intends to go, I'm happy to leave that flag turned on.

But if it'd be more helpful to keep testing without that enabled, I can turn it off after the fix for non-Vulkan-Async setups is shipped in a beta release.

Yep the smoothness comes from the asynchronous reprojection. Basically, SteamVR makes in-between frames by just moving the last frame around to match how your head has moved (rather than waiting for the next fully truly rendered frame, which takes longer to make than a reprojection frame).

If your head's still, it doesn't really help but with low frame rates it helps make sure your brain sees the motion it expects with less delay when you move your head, making things seem smoother and reducing nausea.

@JohanAR

What does error 203 actually mean btw? Is it some kind of catch-all for render thread stalls or semaphore misuse etc?

So, the error code in vrmonitor can come from several places. The main thing to note is that if it's a positive error code it came from a specific component (e.g. VRInitError_<system>_<error> stuff in the OpenVR headers), while a negative error code is internal to vrmonitor.

In this particular case, -203 is the vrmonitor error "no compositor available." Which is entirely accurate, because the compositor has locked up and been killed by the watchdog process (and then failed to restart).

For positive error codes, you can look them up in the OpenVR headers -- positive 203 would be VRInitError_Driver_NotLoaded for instance.

@digitalcircuit

If this is the way Valve intends to go, I'm happy to leave that flag turned on.

I mean, generally I'm going to recommend the async flag if it makes your system feel better! It exists for a reason! And I'm satisfied that the issue's fixed in main (and hopefully makes it over into release in time for the next beta), so for my part I don't really need more data on this. Feel free to leave the flag on! :)

It is worth noting that changing the flag doesn't actually fix the bug, it just makes the bug way less likely to happen. So it still can happen with any HMD using the baseline Vulkan renderer. (Which is... basically everything you'll encounter on Linux right now except for VRLink.) And any driver that uses direct mode or any Nvidia driver that has a specific queue priority bug will cause async mode to be disabled, which may be why we've seen a couple of folks report that changing the value doesn't do anything for them.

But for purposes of "validating that you are seeing the same thing I tracked down and fixed," turning on async to see if the error no longer immediately happened was enough for me to feel confident that we were looking at the same issue.

FWIW, this has made it into 2.16.4. I'll leave the ticket open until 2.16.4 is in the actual beta branch, though.

I've updated to SteamVR 2.16.4 this evening and removed enableLinuxVulkanAsync from the settings file, and it works! I then re-added enableLinuxVulkanAsync and it still works!

@Packetdancer I think this issue can be closed..? Thank you very much! And if anyone else is still having issues, you'll probably want to file a new bug report.

Glad the fix works! :)