You can run with us / We've got everything you need
Run with us / We are free
- Lisa Lougheed, Run With Us
Detailing our experiences after a few weeks trying to use VR on Linux rather than on Windows.
- table of contents
Introduction
Furality Umbra happened at the start of June, and it was the point where we realized that our bad Windows 10 gaming laptop has reached the end of its useful life in terms of VR, with a lot of video hitches and single digit framerates at multiple parts of the event, even with relatively restrictive performance settings. And so the thought turned to upgrading old desktop again, to try VR from there. That desktop has never run Windows outside of a virtual machine - and the goal is for it to never do so. So thoughts turned to trying to assess how desktop Linux VR performance was doing, particularly in case Valve suddenly decides to announce a standalone headset equivalent to the Steam Deck, as has been rumoured at this point for a long time.
Before we start
I can only really recommend this path if you're dedicated to both VR and making Linux work for it.
If you're dedicated to VR, but not Linux, everything here is simply easier on Windows. There mostly aren't the same weird gotchas, everything is significantly more likely to just work, and all it'll take is signing up for a Microsoft account, giving all your data to be ingested by Copilot, ads everywhere, and getting warnings that your computer may be at risk (because Edge isn't your default browser or Bing isn't your default search engine).
You might be able to tell that we no longer trust Microsoft at least as far as consumer versions of the OS go.
If you're dedicated to Linux, but not VR, you most likely can just play monitor based games without the hassle.
This will be a journey. We can advise the steps we took, but there is a decent chance that what worked for us may not work for others.
We went with Fedora as our distribution of choice for this experiment - but I do believe a lot of distributions can work, it just happens to be the one we chose. (See Appendix A if you're interested)
Our Linux experience
We've been using Linux in some form since roughly 2005, though it has never been our primary OS. [1] It's been a great companion with underpowered laptops, the server this site is hosted on, servers at work, our Raspberry Pi running Pi-Hole, and of course, the Steam Deck.
We do use the terminal a lot in general, but coming from a Windows administration background, we're significantly more used to PowerShell's syntax than bash's - so the basics are fine but we will reach for the GUI for more complicated tasks if they're possible that way. We can quit vim
, but do struggle with editing in it compared to nano
.
We are not experts, and you should take the things we say with a grain of salt.
Major Problem 1 - Drivers
I've put our hardware specs in Appendix B - but the important thing to know is that the GPU is an Nvidia RTX 3060.
I don't know if you know this, but Nvidia cards don't exactly have the best reputation on Linux for some reason. I had heard things are meant to be better recently - that Fedora's version of the open source mesa
drivers had incorporated something that might make them just work.
Attempt to start SteamVR up without doing anything, an initialization error, every time. Some searching later, and vulkaninfo | grep NVK
(and grep NVIDIA
) showed an error and the card using its internal name. If the default mesa
drivers are meant to work for this purpose, they weren't working on our system.
So then I had a choice, install the package in the package manager with the relevant repository, use the third party autoinstaller script we found somewhere (apologies, we forgot to save the source link) that handles the package management tasks, or install the drivers directly from Nvidia's website.
But the package manager packages all had x11
in the name, and is that still right for Wayland? I didn't know. Safest to go directly to the source, right? Install the drivers on Nvidia's site, reboot, and....
Well, I went into this expecting things to be Screwed at least once. One Fedora reinstall later, I ran through the autoinstaller script to grab the drivers that way, and oh look, SteamVR works now!
...
Sort of.
Major Problem 2 - Audio
Getting into SteamVR, there were a number of other problems (SteamVR overlays were inconsistent about if they wanted to work, desktop view would just display a test card, some initial problems with the Index being recognized that were solved by using a different port on the GPU and different USB ports, some textures seemingly being displayed at the wrong resolution), but the big major one was audio.
The stereotype of Linux is that audio is inconsistent at best, and I don't particularly think that's true in general these days; monitor audio has been rock solid throughout this process. However, it was so rock solid that it refused to switch away from it when launching SteamVR.
For people that do not own a Valve Index, the Index uses a set of free floating headphones that while not perfect, are very good at mimicking the feeling of positional audio. We have auditory processing issues, so are pretty reliant on this for dealing with crowded VRChat instances where many conversations can be going on at the same time.
Never mind that the mic didn't work, which is... kind of important when voice chatting.
I was kind of stumped by this. The Index's audio didn't even appear in the default KDE Plasma sound control window, so I couldn't think of how to fix it beyond the thought of plugging in an external headset (which would be doable, but I like the Index being integrated).
A friend who has been using VR on Linux for much longer than us pointed us towards PulseAudio Volume Control (aka pavucontrol
), which has the missing option to switch both audio input and output to "Pro Audio", which correctly switches to them when SteamVR is launched when the headset is connected.
Major Problem 3 - Video Players
This is primarily a VRChat specific issue, but VRChat is so much of our VR use that it matters a lot.
We loaded into an instance with friends watching the latest Defunctland. The video player made a few attempts to load... and then hard crashed not just VRChat, but SteamVR as a whole.
We tried different versions of Proton, but they didn't seem to do much - sometimes video would work, sometimes it would still crash. Some searches later, we found a video recommending KDE Plasma X11 over KDE Plasma Wayland for stability. This solved a number of other issues (e.g. some Steam overlays now worked that didn't before). It technically solved video players crashing, by just making them do nothing instead - but this also isn't ideal, because of just how important video players are - whether that's watching videos with friends or club lighting being dependent on audio from a video.
More searches, and eventually we were lead to the GloriousEggroll fork of Proton, which fixes at least playback under X11, which was good enough for the few chances we've had to hang out in VR since then. Still need to test under Wayland and figure out which is better for long term use.
Overall thoughts so far
When we were first getting into social VR in 2022, we delayed getting an Index because of the rumours of a standalone headset from Valve, the Deckard. It's got to be close. Just look at all these changes they're making to SteamVR on Linux! It took 6+ months for us to realize that we can't wait for rumours like this.
I have no idea when or if Deckard will happen, but VR on Linux still doesn't currently seem ready for it. A lot of these problems may not exist with a fixed hardware target running actually recommended hardware, but some feel like they'd still be blockers to that seamless Steam Deck like-experience. At the same time, without an announcement, there is limited incentive for Valve to improve any of this much despite how much parts of the company might want to philosophically.
It isn't all bad. There are issues we'd have frequently on the Windows laptop that we haven't experienced at all on Linux - some of them probably just down to being able to plug in the DisplayPort cable directly rather than having to use an adapter. I haven't had to unplug and replug in the computer side of the trident cable at all since finding the right spot, when that was an every other session thing on Windows. So far, the Index controllers always connect properly the first time. (It is also substantially quieter than the laptop, I think)
I'm determined to make this work for us, long term, to the extent it can. There are 15 months until Windows 10 end-of-life to fully make the switch over. But this is not an experience I could recommend to friends wanting to make their first jump to Linux as soon as Win10 dies. (Maybe everything Just Works™ on Linux Mint, but somehow, I doubt it) Even more so if this would also be on the computer they use to get work done - I have the privilege of doing this on a separate computer than our main machine, the computer we're typing this on; a separate computer where a reinstall can only ever cost a few hours rather than something important.
And every fix I've found is dependent on the kindness of strangers rather than Valve themselves. The official Steam support page for Linux is still relatively slim beyond not using the Snap or Flatpak versions of Steam, suggestions about desktop environment (GNOME Wayland has now implemented DRM leasing, I believe), and a little unclear advice about drivers. The error messages it gives are still ambiguous and unclear, a simple failed to initialize and a help link that goes to SteamVR for Windows documentation rather than the page above (which might have saved some but not all of the driver frustrations, at least)
It's usable - and I'm glad it's usable - but I would not call it user friendly.
Future plans
Now that GE-Proton is installed, I want to retest on Wayland, see what works now and what still doesn't.
Following that, our plans are to upgrade the CPU and PSU together, possibly upgrade the graphics card again.
And then, we have a very, very bad idea. It's an expensive one (if the thing in question isn't returned during the return window), but I have a burning question that as far as I can tell no one on the internet has answered as of the time of writing.
Asides and Appendices
Appendix A - Why Fedora?
We originally started with EndeavourOS (Arch based, with multiple user friendly tools to make it less intimidating). That worked in VR, for the few times we tried it before going back to Windows laptop. However, after a update run after a long time powered off, the machine was left unable to load the login screen. There presumably would have been some way to fix it via ssh
, but starting fresh felt cleaner when we knew there was nothing important on it anyway.
So we took the opportunity to reassess what was most important to us about this - and the answer we came up with was stability without getting stuck.
With being based in the UK and having a lot of US friends, there's a 5-8 hour timezone gap depending on where they're located. This usually means to talk in their evenings, we're logging on somewhere between 3am and 6am - which is a bad time to be troubleshooting anything. Which makes even the stable channel of a rolling release less than ideal.
However, we've had specific recommendations against the other extreme as well. OSes like Debian and Ubuntu can have weird issues from Steam and Proton expecting newer components than the OS provides; particularly with Valve recommending against the Snap or Flatpak versions of Steam if you're going to be running SteamVR.
And so, Fedora seemed like a nice balance, updated frequently, but not too frequently, with the added benefit of KDE Plasma being treated as first class - making the assumption that with it forming the basis of the Steam Deck's desktop OS, that Valve's SteamVR work would also be optimized for it.
And also, well, we'd never used Fedora or any other dnf
based distro (beyond a couple of CentOS servers at work prior to Red Hat doing a late stage capitalism), so new experiences are always welcome.
Appendix B - The hardware
The PC was originally built as a mid range light gaming and media PC in 2018, with the headroom to run VMs when we needed it to. It never really ended up being used for either gaming or media, due to getting a NAS the following year for media, and then an incorrect assumption that a laptop would be better for VR for being able to move around or take it places. (And then 2020 happened)
It has a couple of constraints, including the mini-ITX case and one we'll get to a little later.
- CPU: AMD Ryzen 2600
A solid pick for 2018, but somewhat less of one now.
- RAM: 16GB
Probably could have got away with 8GB, but for VM use it's nice having the overhead.
- GPU: Nvidia RTX 3060
This is the one upgrade the system had since 2018; the 650 Ti in there (a leftover from years gone by, mainly just in there so the system could output video) was simply not going to cut it to even make an attempt at VR. Choices here were constrained by the limited clearance in the ITX case, and...
- PSU: Corsair SF450
Yeah, this doesn't leave a lot of headroom and needs to be updated at this point so the rest of the system can be upgraded further.
- VR gear: Valve Index + Tundra Trackers
It has been quite a few years since the Index was released, and to me, it still represents one of the best overall deals as a package for someone that knows they enjoy VR and is prepared to make the changes to their space needed.
Coming from a Quest 1, the controllers were so much nicer to handle, the audio difference was noticeable, the tracking the base stations provide was a lot better for common scenarios - and the base stations provide an upgrade path for future SteamVR headsets, whether that's Deckard or a version of the Bigscreen Beyond that has the eyetracking support officially built in.
Footnotes
Conceptually, we love Linux. But conceptually, we also love Resonite but still spend most of our time in VRChat. And so, Windows is still what we have decades of experience with, and the Mac is where we tend to do all of our personal computing that isn't gaming. ↩︎