While VR works with Debain 13 as a fallback (it uses older Mesa drivers), it didn't work for me at all with the newest mesa drivers on Arch Linux. But after using a different refresh rate other than 144hz, it finally stops crashing on my Arch Linux.

Maybe you could test Debain Trixie.

Also KDE shows me a crash log in the notifications: vrcompositor.kde_crash.log

Other infos if relevant:
OS: ArchLinux, 7.0.3-zen1-1-zen
Mesa: mesa 1:26.0.6-1
SteamVR: 2.16.4
KDE: Plasma(6.6.4), Frameworks(6.25.0), Qt(6.11.0), Wayland
GPU: AMD RX 6750 XT

Hrm. I'm not managing to reproduce the crash here when putting the Index into 144Hz mode, but I haven't completely duplicated either reported setup down to individual package versions.

Before I dig in too deeply -- can you elaborate on your monitor setup, @Gladox114? Zoarial94 mentions having two monitors, and I wonder if that might be a factor here (since the test rig I'm trying to use here only has one).

Before I dig in too deeply -- can you elaborate on your monitor setup, @Gladox114? Zoarial94 mentions having two monitors, and I wonder if that might be a factor here (since the test rig I'm trying to use here only has one).

I do indeed have two monitors. (Using a WQHD[75hz] Monitor and a 4k Ultrawide[144hz] Monitor over DisplayPort if it matters. Before this setup, I had a WQHD[75hz] and just a FullHD[60hz] Monitor).

I didn't test a single Monitor yet, which I could try soon and report again if it changes anything.

@Packetdancer Seems like pluging all Display Cables out of the GPU except VR and ultrawide monitor, didn't solve the issue. Even reducing the hz of the monitor to 60hz didn't fix anything.

With the 1.16.5 SteamVR Beta version, I do get a different error now, which was previously -303

Failed to connect to window manager
SteamVR failed to connect to the window
manager. You may need to restart your
Session or SteamVR
Restart SteamVR (497)

It instantly works again, after setting 120hz in the steamvr.settings text file and restarting SteamVR

Okay, thanks for the update. I'll poke a bit more.

So, I still can't reproduce this in a scenario where the Index works at less than 144Hz but dies at 144Hz. But I have found a similar bad scenario, and I now have a theory what may be going on.

So, @Gladox114 -- can you throw me your vrserver.txt and vrcompositor.txt from an affected run? To elaborate, what I am seeing in Zoarial's logs is:

• The HMD display is not showing up enumerated right in vrserver.txt, though vrcompositor manages to still find it
• vrcompositor seemingly manages to lease the display and get a direct mode surface.
• Upon the first attempt to use that surface, Vulkan returns a VK_ERROR_SURFACE_LOST -- vrcompositor is (understandably) not expecting this at this particular point and just crashes out hard shortly thereafter.

As I mentioned, I have a theory about this, and if your logs look similar to Zoarial's, I may want to make a temporary test build of SteamVR to have one or both of you get me some more details.

Finally found the time.

First working run: Starting with 120 Hz -> crash with error -201 -> restart steamvr -> working perfectly fine (weird first crash, irrelevant).

144hz run: Switch to 144hz -> restart -> see error code 497 and a reduced settings overlay

Log files:
vrserver.txt
vrcompositor.txt
Other maybe relevant files?:
vrcompositor-linux.txt
vrmonitor.txt

EDIT:
Maybe vrsettings might also help/create an impact on the setup.

steamvr.vrsettings

Uuuugh. I still can't reproduce this specifically, but it looks awfully like a different Mesa DRM lease issue I've been looking at. Specifically, this:

Thu Jun 11 2026 14:25:58.153012 [Info] - Swapchain failed to be created: fffffffd

...looks unpleasantly familiar. I may want to make a special build of SteamVR with some extra debugging to have you try to gather some additional information.

I tested again today and I am unable to duplicate the crash, but I still get an error. Here are some updated logs!

Working 120hz

vrserver.txt

vrcompositor.txt

Broken 144hz (But not crashing anymore)

vrserver.txt

vrcompositor.txt

Whoops, I actually mean I still get the crash but Steam handles it a little more gracefully now.

So, your issue actually appears to be different (though probably related), Zoarial.

Gladox seems to be seeing a problem I've actually seen more generally with mesa and display leasing, which I'm looking at; the display is found, is successfully leased, but then the Vulkan queries return invalid data and as a result the swapchain cannot be created (which doesn't always get handled particularly well at that point).

You, however, when you're in 144Hz, the query to Wayland to find the display to even try to lease it in the first place is returning that there's no display present that matches what it was asked to find. Out of curiosity, if it isn't a huge hassle for you to switch from Wayland to XOrg briefly, I'd be curious if you see the same issue there. (If it's an immense hassle to switch just to run one test, don't worry about it; I know most of my test machines are set up to easily switch between the two, but I know not everyone has things set up that way.)

I think I'm still on a version of plasma with Xorg. I have some time tonight to mess around with it, so I'll let you know if I find anything interesting!

No luck with Xorg and 144hz. 120hz works fine.

With async reprojection
vrcompositor.txt

vrserver.txt

Without async reprojection
vrcompositor.txt

Okay, NOW your issue shows the same as Gladox's in those logs. Which makes me wonder if the "can't find the display" on Wayland and the "found the display, but the lease silently failed in the background and now Vulkan calls return garbage data" are the same underlying cause in the AMD driver, just presenting in different ways.

Thanks, though; that's useful.

Appreciate this thread is a little old now, but if you're still running into this on the latest SteamVR beta we'd be interested in taking another look.

Specifically, if you're able to upload any dumps from ~/.steam/steam/dumps that would be very helpful.

@danwillm I cannot find any folder or file mentioning "dumps" inside when triggering the error after setting 144hz.

Latest release is 2.17.7 (Beta)

❯ pwd
/home/yuki/.steam/steam
❯ find . -name "*dumps*"
./steamapps/common/projectM/presets/Geometric/Wire Cube Trace/suksma - life partners marry dumpsters.milk
./steamapps/common/projectM/presets/Fractal/Loops/suksma - phat_RippleNebula_update - mash0000 - the colors of autumn invoke dumpster dives.milk

@Gladox114 my mistake, the dumps on Linux are uploaded to /tmp/dumps. If you run into this issue again check and you should see a new file starting with crash_***.dmp