How you can help Linux VR thrive

VR on Linux has been known to be a bit of a pain… I’ve written about my experience with SteamVR/ALVR here before, and it was a lot of effort just to get SteamVR crashes that seemingly come back for no reason.

And that’s really the issue, SteamVR. It’s a buggy mess on Linux, it rarely gets fixes, and some issues remain after years of being known about and reported. It’s a proprietary runtime, so there’s not much the community can do about it.

All of this is why the Linux VR community has been moving away from SteamVR in favor of a FOSS OpenXR stack, that currently being Monado and WiVRn (for standalone headsets).

What is an OpenXR runtime?

OpenXR is the industry standard for XR applications, which allows your XR applications to communicate with the runtime, bind to inputs, display graphics, and a bunch of other things. It’s similar to how Wayland allows desktop applications to run on your desktop environment. SteamVR is an OpenXR runtime as well, but it is something more…

It’s an OpenVR runtime first and foremost. OpenVR is Valve’s standard developed as part of SteamVR. The issue with it is that it’s not widely supported by anything other than SteamVR, and poorly documented (the most complete documentation you’ll find is in the header files). This means a lot of games won’t run natively on OpenXR, including all major social VR platforms.

OpenVR compatibility layers

Fortunately we’re not doomed, there currently exist two compatibility layers that allow you to run OpenVR games on top of OpenXR. Of these OpenComposite is currently the more mature one capable of running more games, but its Rust rewrite, XRizer is advancing rapidly. OpenComposite is currently mostly receiving small bugfixes as many developers (including me) have shifted to working mainly on XRizer to get it up to speed.

One of the biggest improvements that comes with the rewrite is the ability to write comprehensive unit tests, which will help avoid game and hardware specific regressions in the future that have plagued its predecessor, the code quality is also massively improved. Help is certainly welcome, and if you feel up to the task go ahead and fire up your favorite games and see how far they go, and see if you can implement the missing functionality, there is currently a lot of low hanging fruit in terms of features and API coverage, so it’s the best time to get started!

If you’re not a developer, make sure to report any issues and post log files, so those who are know what they can work on next!

External tooling and modularity

This is one of the more exciting parts of the ecosystem! A big difference between SteamVR and FOSS XR is that Monado is a pretty bare-bones runtime on its own, it doesn’t come with a dash, or much else, it just does its job. Tools such as WlxOverlay-S and WayVR Dashboard can provide this experience, and programs such as Envision can be used to enable easy one-click installation. WayVR is really interesting here, because it is essentially a Wayland compositor embedded inside of WlxOverlay-S, which allows you to open app windows in VR, or directly on the dashboard, without having to fiddle with a desktop mirror. It’s great for having stuff like say a music player open (which is made even better by another Linux technology - PipeWire, with which you can easily stream said music into a social VR platform like Resonite).

There’s definitely a lot of work that can be done to improve the user experience here, especially on the runtime side. We’re still missing features such as input blocking (overlays can’t block input from the game), dynamic resolution, and more. This requires deeper work on the runtime and OpenXR standard side, so if you’ve worked on similar things before (like Wayland) you’d probably feel right at home with this.

Hardware and donations

Some of the difficulty of working with VR hardware comes from the lack of VR hardware… Donating to developers can help them afford what they need to properly test their software, WiVRn is one example of such a project.

If you can afford it, it could be worth it to put up bounties for bugs/features. If you’re a VR hardware company, there are certainly community members who would be more than happy to work with you to enable support for your hardware!

OpenXR games

This may be obvious, but make your games native OpenXR! No translation layer is the best translation layer!

Also don’t use Zucc’s soul-consuming Unity/Unreal plugin.

The future

What really has me hyped is that by working on this together we can not only make VR usable on Linux, we can make something much greater. We have the means to exceed what has already been done, and push the entire VR space forward, beyond what is possible on Windows or SteamVR, and make it damn reliable at that. I already see how surprised people are when they find out how easy and pleasent the setup process can be on Linux, if this can be extended to more and more parts of the user experience, and notorious bugs can be fixed, that’s a year of Linux VR right there, and it doesn’t even feel like something distant!

Lastly here are some more resources to check out:

• LVRA Wiki
• LVRA Discord (or [matrix])
• Monado
• OpenXR Spec

So TLDR: contribute, report bugs, donate, and spread the word!