Dear Valve: It is Time to Open Source SteamVR

I wish there were a better way to express a sigh other than just writing the word because that’s what I really need to start this piece: a big ol’ sigh.

Steam Frame in a box (maybe that asterisk should be for more than parler en français).

I wanted this first article about the new Steam Frame to be my initial impressions, from when I first opened it about a month ago. I wanted to tell you about the comfort, the clarity of the pancake lenses, the great tracking and image stability, the joy of wireless, and yes, even the smooth initial software experience on Linux.

But that initial surprise at it just working, well, that should tell you everything with the word “surprise”. It did not last. A couple of weeks later, as I started writing up my thoughts, the new wireless dongle, the key to a good streaming experience, stopped working. It was there, the network it uses to communicate with the Frame was set up, paired, no change in anything on my side, and yet it was always “Waiting…” or “Inactive” or even “Not Detected” by Steam.

Not that this meant that I couldn’t stream from my desktop. 2d games were fine, and VR could work too, as I have my desktop wired directly into a (mesh) access point literally next to the computer. So the packet loss was often non-existent, and the pings were easily in the low teens or single digits (ms). But that isn’t always reliable, and the multi-link streaming the Frame does really can make a world of difference for a reliable experience.

I wanted to use the full potential of the new device, test it, and also just expect to be able to use the hardware I paid so much for. Not only was I lucky to even have the Frame so early (my order email was in one of the first waves), but my home setup meant I could do pretty well without the dongle.

So why the long sigh? What do I really have cause to go on about?

Well, it brings me to something I’ve thought for a long time, since I first got the Valve Index back at the end of 2020: Valve should open source SteamVR. And when it comes to the Frame, that means the rest of the related software stack, from the client with Remote Play to handling connecting to the Frame wirelessly. Or at least more, because right now the whole thing is pretty closed. And yes, there are alternative open source software stacks you can set up, but that doesn’t mean Valve shouldn’t lead, especially with their new VR headset being a Linux machine.

Screenshot from the prolific Issue #965 with people trying to debug and fix SteamVR on Linux issues.

Now, there are many (probably valid!) arguments you could give why they have reason not to, or should carry on as they have and upstream drivers and such, to which I have one response: but it doesn’t work with their own hardware!

Not for everyone, and not consistently enough, and most importantly: not in a way the user has almost any real control over. This has been a problem for as long as I have used SteamVR and it hasn’t gotten better, at least not consistently. Look no further than the comments on each new release, or the endless and long-lived issue reports on GitHub.

Every time I would fire up the Index, I would hold my breath waiting to see if it would work. A free bit of time in the afternoon to get in a little Beat Saber as a winter workout would end up in a frustrated half hour of eventually giving up. No blocks were sliced and I felt my time was wasted.

With the long rumors of “Deckard” and more updates specifically targeting Linux in SteamVR, it did seem things were (at times) improving. My break from VR for most of this year (home renovations and general upheaval in my space and time) sort of healed or scabbed over these poor experiences.

So I was cautiously hoping for the best, expecting things not to work, or at least require tinkering and digging up what I could with very little Linux appearing in early reviews or user reports. I kept an eye on Reddit and YouTube for any useful information, while hoping to get that ready to order email from Steam. Then there was the Linux wireless troubleshooting script Valve created when the Frame came out, leading me to contributing some updates to GNU Guix (still my distro of choice) to help ensure everything was hopefully ready to go. I was flying blind, having never used wireless on my desktop or in Guix.

And then it worked! It was really good! Maybe the nightmare that is SteamVR on Linux is gone, with the challenging terrain of wireless on Linux to boot?

But no, and here I am, after a Steam desktop client update broke the dongle for me, to be fixed in the next beta, to sort of reappear and then not on further updates… letting out one big sigh as I write the piece dormant for the last 6(!!) years rather than telling you all the good and bad of the actual cool new thing, the Steam Frame.

From the Frame, the Streaming Status will show what is connected, or maybe a dreaded “Not Detected” even when everything is plugged in and set up.

In earlier versions of Steam there were settings on both host and client for the wireless dongle, but not on the current (beta) versions. The adapter has to be paired between the Frame and host (where it is plugged in), as well as giving privileges to Steam so it can manage the connection through NetworkManager.

(Since about 2 weeks ago, things seem to work consistently on the Frame stable release and desktop beta client, at least for now. All I had to do was file a report, somehow conjuring the new 64-bit beta to fix my issue. But I don’t want to let this thought linger until I again feel that palpable frustration. One glance online tells me that problems continue for others, though it is always hard to tell how widespread. I hope the situation has improved for others, and it does seem to be looking better.)

As I wrote earlier, I’m dismissing any counterarguments with the glaring, practical simplicity that the current approach just doesn’t work. And SteamVR on Linux would work better, or at least have a chance!, if Valve would just open source the damn thing.

It comes down to leaving the real resource of the niche of a niche community that is VR on Linux on the table: us hard-working Linux gaming nerds desperate to freely give our time to make something we care about better. You can see it all over the Linux VR Adventures Matrix/Discord, on Reddit, Valve’s GitHub (for instance, this bug report with lots of user tips or attempts at fixes), and many other code repos (or making tools from Valve more accessible), including straight up binary patching. People jump through crazy hoops to try and figure out what is going wrong, write plausible or probably bad idea scripts to run, and do everything they can to make things work better. On top of that, there is also the whole community trying to do cool and useful things on the Frame.

But how much can be done when the system is ultimately closed? I don’t need to repeat here the well-worn and many reasons we all have to be on Linux in the first place. One of the primary reasons, for me and many others, is the freedom to do what we want with our systems. That stops when you hit SteamVR (and yes, generally games themselves), and stings all the more because you know there is some code just out of reach that you could have some chance to understand, debug, and help make better.

When things are working, this is what SteamVR shows from the host machine, with both the wireless adapter and Wi-Fi connected (multi-link streaming).

And on the Frame side (stats shown can fluctuate a bit and often average lower).

If Valve really cares at all about VR on Linux, which it certainly seems to, what with the Linux computer that is the Steam Frame, then please open source the software stack. It doesn’t have to be any secret sauce on foveated streaming or anything special, but the basic pieces of just getting VR to run.

And if Valve doesn’t really care, then all the more reason to let it run free and see what the community is capable of.

Valve has done amazing things for gaming on Linux by building off of, and contributing back to, the Free Software ecosystem. It is time to do that with SteamVR.