Running SteamVR and VRChat on Arch Linux (2023 Feb guide)

NOTE: This guide is for users competent with Linux. I mean, why else are you trying to VR on Linux if you are not a Linux enthusiast. And with a Valve Index. If you are not, some of the information in this guide may help. But additional debugging and troubleshooting will be required. Good luck hacking!

I'vm a heavy VRChat player. I've friends on there. I can talk about supporting CVR and the entire EAC debacle, but I'm not here to talk about that - I use Linux as my daily OS. It respects my privacy, I can do full customization, I just got VRChat and SteamVR to work at a usable state on my Arch installation. So I decide to write a guide for others who want to do the same. (and increase the VRChat Linux playerbase)

Here's my VR setup:

  • Valve Index HMD
  • Valve Index Controllers
  • 2.0 Base Stations
  • 3x Vive Tracker 3.0

And system specs:

  • Up to date Arch Linux with 6.1.12-zen1-1-zen kernel
  • Radeon RX 6700 XT GPU
  • Ryzen 7 3700X CPU
  • 32GB RAM
  • Steam installed from multilib repo (Arch official package)

SteamVR and Valve Index

First things first, I assume you already installed Steam and SteamVR. And already tried to do room setup and failed miserably. There's a few things that goes wrong.

  • SteamVR runs at a miserable 1FPS and a heck tone on corrupted frames
  • Index HMD not showing anything even though VR view shows it's working
  • SteamVR saying "Not using Direct Mode" and requires you to restart SteamVR. But restarting SteamVR doesn't fix it.

Let's get started.

If you see very corrupted images in the VR view (example in the image below), most likely you are running a Wayland session. SteamVR needs X and XWayland support is piss poor rignt now. Any X11 session will work. I've tested on both Gnome 42 and KDE 5. Both works. To check defintely, run echo $XDG_SESSION_TYPE in the terminal. If it says wayland, you are running a Wayland session. If it says x11, you are on X11.

Serious corruption in the VR view. On Gnome 42 Wayland session.
Image: Serious corruption in the VR view. On Gnome 42 Wayland session.

Switching to X11 will make the corruption go away and with much better FPS. Potentially looking like this. However, you may still see tghe "Not using Direct Mode" error. And if you try to put on the HMD, you will see nothing. Display won't turn on. At this point SteamVR will prompt you to setup your room. You can do that, more configuration is needed to make everything work. But the order isn't important.

Correctly working SteamVR on X11 sessio, no image corruption.
Image: Correctly working SteamVR on X11 sessio, no image corruption.

To enable direct mode (which somehow SteamVR doesn't do automatically), you need to configure the X server to prefer the default resolution of the Index HMD. Edit /etc/X11/xorg.conf and add the following lines:

Section "Monitor"
  Identifier "DisplayPort-1"
  Option "PreferredMode" "2880x1600"
EndSection

IMPORTANT!! The ID is not always DisplayPort-1. Especially if you have monitors connected also using DisplayPort. To find the correct ID. Run the following command:

❯ xrandr --query | awk '/2880x1600/{print h;} {h=$0}'
DP-2 disconnected (normal left inverted right x axis y axis)

For me, since I have a monitor connected to DP-1, the ID is DP-2. So I need to change the ID in the config to DisplayPort-2.

Now restart your computer (or restart X by restarting your display manager). And try to run SteamVR again. SteamVR will ask to enable direct mode. Click "restart" and it should work. And you shall see that popup not showing up anymore. And your HMD display should turn on. Now SteamVR is fully working.

Higher FPS OR fixing overlay jitter

This is one thing you need to decide and upstream is trying to solve. Currently the SteamVR overlay (including room guards) will jitters from time to time. This can feel disappointing and annoying. The root cause is async reprojecting not always reprojecting to the same frame. You can solve this by disabling async reprojection. But this will reduce your FPS and it forces SteamVR to wait around. This is not ideal. But it's a trade-off. You can try both and see which one you prefer. To disable. Add "enableLinuxVulkanAsync": false to ~/.steam/steam/config/steamvr.vrsettings:

// ~/.steam/steam/config/steamvr.vrsettings
{
   "steamvr" : {
      "enableLinuxVulkanAsync" : false
   }
}

The high frametime if async reprojection is disabled.
Image: The high frametime if async reprojection is disabled.

Known issues and stuff not supported

It's not 100% rose and sunshine. There are some issues that I've encountered. I did say "at a usable state" not "perfect". Here's a list of known issues:

  • (KDE) VR virtual desktop is not working. You can't use the virtual desktop to browse the web or do other stuff.
  • Automatic audio switching is not working on KDE. You need to manually switch audio output to the HMD.
  • Overlay jittering. See above.

Full Body Tracking

It works. Here's a short list of stuff I tried:

  • Vive Tracker 3.0
  • Self-made SlimeVR Tracker

VRChat

Getting VRChat to work is easy. With SteamVR working, you can just enable Steam Play (aka. Proton) and run VRChat. Then start the game either from the Steam GUI of the Steam Home VR menu. It just works.

Me playing VRChat on Linux, with Full Body Tracking.
Image: Me playing VRChat on Linux, with Full Body Tracking.

Finger tracking also works perfectly

Me playing VRChat on Linux, Finger Tracking using the Nuckles controllers.
Image: Me playing VRChat on Linux, Finger Tracking using the Nuckles controllers.

Audio tuning

If you want a better experience, you may want to do some tweaks. First although VRC comes with it's own noise compression. You might want to do it on a system level. Plese use PipeWire as your audio server (PulseAudio is getting less and less used anyway). And use the noise-suppression-for-voice plugin. And create the config file ~/.config/pipewire/pipewire.conf.d/99-input-denoising.conf. And add the following content. Change /usr/lib/ladspa/librnnoise_ladspa.so as fit. The path I provided is for Arch Linux. Other distros could differ.

context.modules = [
{   name = libpipewire-module-filter-chain
    args = {
        node.description =  "Noise Canceling source"
        media.name =  "Noise Canceling source"
        filter.graph = {
            nodes = [
                {
                    type = ladspa
                    name = rnnoise
                    plugin = /usr/lib/ladspa/librnnoise_ladspa.so
                    label = noise_suppressor_mono
                    control = {
                        "VAD Threshold (%)" = 50.0
                        "VAD Grace Period (ms)" = 200
                        "Retroactive VAD Grace (ms)" = 0
                    }
                }
            ]
        }
        capture.props = {
            node.name =  "capture.rnnoise_source"
            node.passive = true
            audio.rate = 48000
        }
        playback.props = {
            node.name =  "rnnoise_source"
            media.class = Audio/Source
            audio.rate = 48000
        }
    }
}
]

Now point VRChat to use the new "Noise Canceling source" as the input device.

In-Game Photo save location

Proton does not map the "Pictures" folder to the host (or the home folder for that matter). Usually VRChat saves photos to %USERPROFILE%/Picrures/VRChat. This would be have be mapped to $XDG_PICTURES_DIR or $HOME/Pictures on Linux. But since Proton doesn't do that it's stored in ~/.local/share/Steam/steamapps/compatdata/438100/pfx/drive_c/users/steamuser/Pictures/VRChat.

If you want to save the photos to your home folder (ex: easier setup for photo backup). You can create a symlink to the folder.

❯ mkdir -p ~/Pictures/VRChat
❯ ln -s ~/.local/share/Steam/steamapps/compatdata/438100/pfx/drive_c/users/steamuser/Pictures/VRChat ~/Pictures/VRChat

Gallery

Some images that I want to share.

If for some reason you doubt that I'm actually using Linux to play VRChat. Here's me also running archey3 and uname.

Proof that I'm actually using Linux!
Image: Proof that I'm actually using Linux!

This gave me some hope. Linux scheduler is doing a very good job at feeding the GPU with data. On Windows it's hard to get VRChat to use any CPU more then 50% (for me) and GPU is usually lower then 70%. Wasting my money.

VRChat actually using my GPU and CPU.
Image: VRChat actually using my GPU and CPU.

Some random in-game forest scene.

Some random in-game forest scene.
Image: Some random in-game forest scene.

Known issues

  • Seems to be locked at 60FPS even though frame time shows it can easily run at 120
  • Video playback is not working. Long time knwon WINE issue

Conclusion

"It works" would be the best way to describe it. SteamVR and VRChat works. But it's not as smooth as easy to set up on Windows. Never the less, I'm impress that it works. And that also means I can use Linux more. And I don't need to switch OS between my FOSS development and gaming. I can just use Linux for everything. And I'm happy about that.

Author's profile. Photo taken in VRChat by my friend Tast+
Martin Chang
Systems software, HPC, GPGPU and AI. I mostly write stupid C++ code. Sometimes does AI research. Chronic VRChat addict

I run TLGS, a major search engine on Gemini. Used by Buran by default.


  • marty1885 \at protonmail.com
  • Matrix: @clehaxze:matrix.clehaxze.tw
  • Jami: a72b62ac04a958ca57739247aa1ed4fe0d11d2df