ValveSoftware
SteamVR error 497 - Swapchain failed to be created: fffffffc
Describe the bug SteamVR can't connect to window manager after switching to Fedora 43 in the recent Nobara Linux update
To Reproduce Steps to reproduce the behavior:
- Launch SteamVR
Expected behavior SteamVR to launch
System Information (please complete the following information): Please use the latest Steam beta client and SteamVR beta for your bug reports!
- Steam client version (build number or date): 1763795278
- SteamVR version: 2.14.3
- Distribution (e.g. Ubuntu): Nobara Linux 43
- Steam runtime diagnostics: [generate via Help -> Steam Runtime Diagnostics in the Steam client]
runtime_diag_nobara_nov_24.tar.gz
- Steam and SteamVR logs: [generate by running this command in a terminal
tar -zcvf ~/Desktop/steam-logs.tar.gz ~/.steam/steam/logs]
- Minidumps: [run the following command:
tar -zcvf ~/Desktop/steam-minidumps.tar.gz /tmp/dumps]
Screenshots If applicable, add screenshots to help explain your problem.
Additional context Add any other context about the problem here.
Hello @Markosha2004, from your vrcompositor.txt:
Mon Nov 24 2025 17:11:30.135775 [Info] - HMD swapchain mode:2 count:3
Mon Nov 24 2025 17:11:30.135797 [Info] - Swapchain failed to be created: fffffffc
Mon Nov 24 2025 17:11:30.135813 [Error] - CHmdWindowSDL::CreateSwapChainBufferResources - Invalid swapchain
Mon Nov 24 2025 17:11:30.164121 [Info] - HMD swapchain mode:1 count:4
Mon Nov 24 2025 17:11:30.165885 [Info] - Direct mode: disabled
Mon Nov 24 2025 17:11:30.166270 [Info] - Mirror swapchain mode:0 count:4
Mon Nov 24 2025 17:11:30.168322 [Error] - CHmdWindowSDL: VR requires direct mode.
Mon Nov 24 2025 17:11:30.168348 [Error] - CHmdWindowSDL: Failed to inititalize X presentation support
Mon Nov 24 2025 17:11:30.168432 [Error] - Error making window!
There is a mesa regression starting with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6173 that needs to be evaluated by a mesa dev. Until something is figured out, the workaround would be to use the mesa 25.2 series or older.
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.
I intentionally omitted https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36325 from my routine driver testing for brevity. This merge request changes SteamVR's failure symptom from SteamVR error 496 - Cannot DRM Lease Display to the above. While bisecting the driver regression, I attempted to apply !36325 directly to !6173 when it was merged on July 21, but changes in between prevented a trivial, sane build of mesa. This leaves some months of other changes to src/vulkan/wsi_common_display.c between !6173 and !36325 that are in limbo and someone would need to spend some effort detangling. It's not clear where in that timeframe the swapchain issue was introduced, from !6173 or after.
The above paragraph is functionally noise until there's a better understanding as to what's going on, !36325 was targeting a different near-match use case.
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.
The mesa-provided Vulkan layers are unrelated to the already bisected regression in (mesa)/src/vulkan/wsi_common_display.c.
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 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_CAPsomewhere?
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_AcquireXlibDisplayEXTlooks 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