Thanks for explaining the issue... somehow...

Anyway, I cannot seem to downgrade, no matter what I try the terminal of my choosing says that "Nothing provides mesa-filesystem needed by [insert a mesa component here]"

Replying to https://github.com/ValveSoftware/SteamVR-for-Linux/issues/836#issuecomment-3571940156

Hi, The fix for this MR was merged for mesa 25.3 which is what the User is using with Nobara 43. So this fix is not quite correct. I have confirmed downgrading to 25.2.6 does fix the issue.

drm logs show a series of successfull calls related to initialization, then vrcompositor closing its drm fd. So, the thing we still need is some debugging inside of Mesa of where an error is occurring -- enabling wsi_display_debug as before, then adding additional logging in swapchain init's error paths to find what's going wrong.

I tried doing some reverts to see if I could at least figure out if there's a way to make 25.3 work, I had to do a few minor adjustments but reverted these MRs in order and steamVR is working again:

37880
70e3af188d61375f7d8440a149136710c81d94c9
b777384e993de71341ed96d962f531f1d73a36c6
c4e0f4d917615db1be61aa3b3fd918977362c324

36325
a7b866617a8f9810dc2d68310c57a3f4884832c1
bd57e48249acca3bb216e3e42416c55b6c7fb7b1

37026
8abfd26534c6cfcacc2dd3080181a6e7b901095b

36607
ba92104b564514117a0bcc4120dff6089965eabc

35461
94619a0f4ba733d0141793e46417aa0ecec3298d
d977951d64cdc9fc477f4f2193880a4ae4e4299b
13137393f67b3da41d97a18b7a1961a40ef469f1
2c870bbe20ccaed9d8c85bb3144075025d3c9a01
1ed78dd7ec4add7c62e26e6200910d0d3b3e300f
b4176393a0aa5af547aa3f0ddfd03817e99a2588
b465d144ca329315fb640e4b765d8a4090e09e51

36341
a8e9af2ce98e69ab44c47b1859be89e4d2891639
0c0d9c05e08aa5ad0a57f7f425a223c4f5735f19
fe7652eae91f51e42b3e4238b5aab7cabb777bf1
b16a6a56d87bf748e06fda0e115926a43cbb9db6

6173
055d5759a7e6bb80c652f20f4fa96480547ca1a1
3c302d29a486f471d78f241ce9252a95a97537fe
513ffea1d366c82e50975fd430d012ff8e652a79
baa9b4225b198fb9567da8c6d7a5a072fc69df58
09058ccbdb5138432af4fee9aa5263e4a4943157

I'm going to try re-applying 6173 and its fix 36325 next to see if it works. if so then we know its one of the other changes in this list. if not then we know its 6173 still.

6173 is still the problem. Reverting to only 6173 applied then adding 36325 on top of it does not resolve the issue. I've opened a bug in mesa: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14382

Downgrading to mesa 25.2.7 or 25.2.6 does not fix the issue on Arch Linux.

Just want to add some info here, which may be useful.
SteamVR works for me with the following:

HMD: Index
GPU: 6900XT
OS: Cachy

Installed:
lib32-mesa 1:25.3.1-3
lib32-vulkan-mesa-device-select 1:25.2.7-2
lib32-vulkan-radeon 1:25.2.6-2
linux-firmware-amdgpu 1:20251125-2
linux-firmware-radeon 1:20251125-2
mesa 1:25.3.1-3
mesa-utils 9.0.0-7.1
vulkan-mesa-device-select 1:25.2.7-2
vulkan-radeon 1:25.2.6-2

Skipping updates for:
lib32-vulkan-radeon 1:25.2.6-2 -> 1:25.3.1-3
vulkan-radeon 1:25.2.6-2 -> 1:25.3.1-3

If i try to upgrade vulkan-radeon, it forces the replacement of "vulkan-mesa-device-select" with "vulkan-mesa-implicit-layers" which I assume is breaking SteamVR.

Downgrading to mesa 25.2.7 or 25.2.6 does not fix the issue on Arch Linux.

If that is the case for you, you probably didn't downgrade all packages involved. This worked for me on an AMD GPU system:

cd /var/cache/pacman/pkg
pacman -U ./mesa-1\:25.2.7-1-x86_64.pkg.tar.zst ./lib32-mesa-1\:25.2.7-1-x86_64.pkg.tar.zst ./lib32-vulkan-mesa-device-select-1\:25.2.7-1-x86_64.pkg.tar.zst ./lib32-vulkan-radeon-1\:25.2.7-1-x86_64.pkg.tar.zst ./vulkan-mesa-device-select-1\:25.2.7-1-x86_64.pkg.tar.zst ./vulkan-radeon-1\:25.2.7-1-x86_64.pkg.tar.zst

You probably have to confirm removal of vulkan-mesa-implicit-layers and lib32-vulkan-mesa-implicit-layers as those packages are causing a conflict with the vulkan-mesa-device-select packages.

After a reboot SteamVR was working again. I've pinned those packages for now.

I downgraded all mesa related packages to 25.2.7 and it still doesn't seem to work.
Generally since the last update where VR stopped working, my SDDM has a very small and wrong resolution, feeling like KDE might need a downgrade too or some other packages too.

Current Versions of downgraded Packages:
vulkan-radeon 1:25.2.7-1
vulkan-mesa-device-select 1:25.2.7-1
vulkan-intel 1:25.2.7-1
lib32-vulkan-radeon 1:25.2.7-1
lib32-vulkan-intel 1:25.2.7-1
lib32-vulkan-mesa-device-select 1:25.2.7-1
linux-firmware-amdgpu 20251125-1
linux-firmware-radeon 20251125-1

@Gladox114 Try downgrading mesa & lib32-mesa as well, if not already.

@JasperDeLaat94 Thanks a lot, it did fix VR. Unsure how I failed to downgrade these two packages while trying to copy SteffenWi's command but with "downgrade" in Arch Linux

Hello,

I have the same underlying problem here on Nobara 43, although I'm not able to downgrade the mesa-drivers.
A little bit of backstory: I used to have a NVIDIA GPU, which worked fine. Now I just got a AMD RX 9070 XT and switched all drivers, and also tried installing Nobara on a different SSD without all nvidia packages, but to the same result.

If I try to downgrade from mesa-25.3.1 to mesa-25.2.7 as mentioned in the posts above, my system also wants to uninstall Steam. Also the other way around, if I try to reinstall Steam with the downgraded mesa, it wants to update to mesa-25.3.x, as if it were a hard dependency.
I also tested all combinations of SteamVR beta and previous branch, in addition to all Steam Runtime 3.0 (sniper), beta and previous branch.
NonVR Steam games work just fine. Can someone help, please?

Steam Client version: 1763795278
SteamVR version: 2.14.4 (release branch)

Distribution:
Nobara Linux 43
KDE Plasma 6.5.3
Display Server: Wayland

CPU: AMD Ryzen 7 5800X
GPU: AMD Radeon RX 9070 XT
Memory: 32 GiB
Filesystem: btrfs
Headset: Valve Index

Steam runtime diagnostics.txt
steam-logs.tar.gz
steam-minidumps.tar.gz

This is a thread for adding information about the bug itself, not for figuring out how to properly downgrade your video drivers.
Please go to a generic help channel of some sort, like the nobara discord, so that this thread can remain about the bug.

I'm just looking at this in gdb:

(gdb) p/x available_surface_formats
$12 = {{surface_format = {format = 0x32, colorSpace = 0x0}, drm_format = 0x34325258}, {surface_format = {format = 0x2c, colorSpace = 0x0}, drm_format = 0x34325258}, {surface_format = {format = 0x40,
      colorSpace = 0x0}, drm_format = 0x30334258}, {surface_format = {format = 0x40, colorSpace = 0x3b9c6048}, drm_format = 0x30334258}, {surface_format = {format = 0x3a, colorSpace = 0x0},
    drm_format = 0x30335258}, {surface_format = {format = 0x3a, colorSpace = 0x3b9c6048}, drm_format = 0x30335258}, {surface_format = {format = 0x5b, colorSpace = 0x0}, drm_format = 0x38344258}, {
    surface_format = {format = 0x5b, colorSpace = 0x3b9c6048}, drm_format = 0x38344258}, {surface_format = {format = 0x61, colorSpace = 0x0}, drm_format = 0x48344258}, {surface_format = {format = 0x61,
      colorSpace = 0x3b9c6048}, drm_format = 0x48344258}}
(gdb) p/x *create_info
$13 = {sType = 0x3b9acde8, pNext = 0x0, flags = 0x0, surface = 0x55cf9c620480, minImageCount = 0x3, imageFormat = 0x7062eebc, imageColorSpace = 0x55cf, imageExtent = {width = 0x870, height = 0x4b0},
  imageArrayLayers = 0x1, imageUsage = 0xa, imageSharingMode = 0x0, queueFamilyIndexCount = 0x0, pQueueFamilyIndices = 0x0, preTransform = 0x1, compositeAlpha = 0x1, presentMode = 0x2, clipped = 0x1,
  oldSwapchain = 0x0}
(gdb) bt
#0  wsi_display_surface_create_swapchain (icd_surface=0x55cf9c620480, device=0x55cf9c700790, wsi_device=0x55cf9c6c5d58, create_info=0x7fff87186be0, allocator=0x55cf9c7007d0, swapchain_out=0x7fff87186c50)
    at ../src/vulkan/wsi/wsi_common_display.c:2984
#1  0x00007f5f6007dcfb in wsi_CreateSwapchainKHR (_device=0x55cf9c700790, pCreateInfo=0x7fff87186cc0, pAllocator=0x0, pSwapchain=0x7fff87186dc8) at ../src/vulkan/wsi/wsi_common.c:1066
#2  0x00007f5f61962b62 in terminator_CreateSwapchainKHR () from target:/lib/libvulkan.so.1
#3  0x000055cf702d8c19 in vr::CHmdWindowSDL::InitVulkanSwapChain(VkSurfaceKHR_T*, vr::CHmdWindowSDL::SwapChainData_t*, bool, vr::CHmdWindowSDL::SwapChainData_t*) ()
#4  0x000055cf702d92f4 in vr::CHmdWindowSDL::CreateDirectModeWindow(unsigned int, unsigned int, VkDisplayKHR_T*, VkSurfaceKHR_T*) ()
#5  0x000055cf702d962b in vr::CHmdWindowSDL::CreateHMDWindow(unsigned int, unsigned int, VkDisplayKHR_T*, VkSurfaceKHR_T*) ()
#6  0x000055cf702dcf26 in vr::CHmdWindowSDL::CHmdWindowSDL(vr::CHmdDistort*, int, int, unsigned int, unsigned int, float) ()
#7  0x000055cf702873f4 in vr::CHmdDistort::Initialize(TVRSharedState<VRCompositorState_t, false>*, vr::IVRIPCResourceManagerClient*, bool) ()
#8  0x000055cf70357e6c in CVRCompositor::Init() ()
#9  0x000055cf703589fe in RealMain(unsigned int, ParsedArguments_t&) ()
[#10](/issue/ValveSoftware/SteamVR-for-Linux/10) 0x000055cf7027b878 in main ()

imageFormat = 0x7062eebc, imageColorSpace = 0x55cf These look bad to me.

Edit, I think this is a result of vkGetPhysicalDeviceSurfaceFormatsKHR returning 0 formats. I'll keep digging and follow up either here or on the mesa issue.

wrote a repro for this. using this instead of steamvr should speed up debugging. to build, you need wayland libraries, vulkan loader and header. you also need to use wayland-scanner to generate marshaling code for the drm lease extension, protocol file is here

I noticed the result of drmModeObjectGetProperties is missing all the atomic properties, compared to the output of drm_info. checking the kernel source code does show that atomic properties are skipped if the drm fd is not atomic.

so i guess the cause is that mesa is missing a DRM_IOCTL_SET_CLIENT_CAP somewhere?

so i guess the cause is that mesa is missing a DRM_IOCTL_SET_CLIENT_CAP somewhere?

Indeed, I applied this patch I posted at https://gitlab.freedesktop.org/mesa/mesa/-/issues/14382#note_3241522, and I have VR working on the main branch of mesa.

Nice work on the investigation/repro

I can confirm that testing with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38987 resolves the issue.

If I can ask. How can/could I try https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38987 ? My Question is Related to #854
OS: Bazzite
Or should I mayby just wait till this is resolved ?

@pietru2004 I think you should not compile mesa by yourself and use it. Yes, normally it should be pretty straight forward. BUT IF something went wrong, you kill your graphics drivers and end up without a working desktop. Including to the fact that you ask "How" I would say just do not do it. If you have a testing machine where it does not matter if you kill your graphics stack, here: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/README.rst

But if you do not have a separate system, just do not do it and wait for the official update

Ok I gona wait then since I have no testing machine. Also if I can ask (if somebody knows), is there any chance for official update to be before Christmas ? If nobody knows or there is no chance I can always just boot into windows for vr - I have dual boot.

(Not sure should I, but should I mark this comment as offtopic?)

Ok I gona wait then since I have no testing machine. Also if I can ask (if somebody knows), is there any chance for official update to be before Christmas ? If nobody knows or there is no chance I can always just boot into windows for vr - I have dual boot.

(Not sure should I, but should I mark this comment as offtopic?)

This is distro dependent, Nobara for example, just backported the patch already and released 25.3.2 last night.

i heard from @kisak-valve that this only fixes wayland but doesn't fix X11. i think there are still a couple more places that's missing drmSetClientCap.

for example, wsi_AcquireXlibDisplayEXT looks like it needs one too.

i heard from @kisak-valve that this only fixes wayland but doesn't fix X11. i think there are still a couple more places that's missing drmSetClientCap.

for example, wsi_AcquireXlibDisplayEXT looks like it needs one too.

Good to know but this issue is not the right place for this note because thats an error of Mesa and not Steam VR. Please comment it under an Mesa issue like this one https://gitlab.freedesktop.org/mesa/mesa/-/issues/14382#note_3241522

Fix for the X11 case: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39166

Fix for the X11 case: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39166

Finally got merged a little bit ago, should be in the next release

Am 10. April 2026 23:33:07 MESZ schrieb six @.***>:

authorisation left a comment (ValveSoftware/SteamVR-for-Linux#836)

Fix for the X11 case: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39166

Finally got merged a little bit ago, should be in the next release

--
Reply to this email directly or view it on GitHub:
https://github.com/ValveSoftware/SteamVR-for-Linux/issues/836#issuecomment-4226912829
You are receiving this because you are subscribed to this thread.

Message ID: @.***>
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

This doesn't occur with me anymore, only if I launched 3rd party software called Helvum prior to launching steamvr

Still happening to me; SteamVR 2.16.6, Linux Mint 22.3

i'm not sure if it's related but

Thu Jul 30 2026 22:28:30.570782 [Info] - Swapchain failed to be created: fffffffd
Thu Jul 30 2026 22:28:30.570806 [Error] - CHmdWindowSDL::CreateSwapChainBufferResources - Invalid swapchain

is (still) happening to me, archlinux mesa 26.1.5

For anyone running into this error on the current SteamOS 3.8.18.
It's because SteamOS still uses the Mesa 25.3 driver.

Switching to the preview channel which will update to SteamOS 3.8.25 inludes the Mesa 26.2 drivers.
And fixes the issue.

I think this is happening to me on mesa 26.2.1-1? it's really weird because it did work last night and then a few hours later it doesn't anymore.

Sun Aug 23 2026 21:13:38.942477 [Info] - ERROR: Swapchain failed to be created: VkResult = -1000000000
Sun Aug 23 2026 21:13:38.942499 [Error] - CHmdWindowSDL::CreateSwapChainBufferResources - Invalid swapchain