Steam Frame, a Linux machine, doesn't support Linux?

I expected some gambling, but not like this.
Reading time: 15 minutes

Nearly three months later, it is time to talk about Valve hardware again. Reviews for the Steam Frame, Valve’s newest VR headset, are finally out, and most Steam users can now sign up for the free lottery where they might be given the chance of buying one. I’ve previously discussed this lottery system, and Valve’s earlier hardware release: the Steam Machine. To close that earlier post, I signaled my disinterest in the Machine and my interest in eventually buying a Steam Frame. As someone who signed up for its lottery, I really wish things were as simple as just hoping I get selected. I’m almost hoping I’m not given the option to buy one just yet, as a forced waiting period could help my newfound anxiety around this product.

This post is a rant about what is hopefully a transient situation, and it is a timely rant, considering that I might need to make a decision about whether to gamble a thousand bucks very soon. I never had such strong hopes that a critique on this website becomes irrelevant in the days following its publication. It’s venting that can just quickly dissipate if Valve adds a few reassuring words to their marketing pages, or even if they just respond to some discussions in an official capacity.

After spending a couple of hours playing in my friend’s Valve Index, the Frame predecessor from 2019, I was sold on this VR thing. I wanted to buy the Frame for my first VR headset, even if the price was a bit sour. Of course, there would be an upper limit, but the price at which the Frame released is within the bounds of what I was mentally prepared to pay, even if we know that it isn’t the price Valve hoped and originally planned for - owing to the ongoing crazy demand for memory. Contrary to my expectations, my concern about the Frame is not its price… it isn’t even about the claims that, in the big 2026, there is still a limited selection of VR experiences that are really worth it; that VR is a novelty that can wear off quickly.

The most important context for this post is that I finished migrating away from Windows on all my computers a bit over a year ago. My “gaming desktop” was the last one to move. Perhaps more so than my long history of appreciation for the Linux desktop and command line, or my increased lack of patience for Windows and Microsoft shenanigans, what really enabled this migration was Proton, the Valve-sponsored project that ties together multiple other open source projects, including Wine and dxvk, to make it possible to run on Linux the vast majority of PC games built for Windows.

I had been running Windows on that desktop since I put it together in 2017, because of game compatibility concerns; once that was mostly out of the way, it would only be a matter of time until I said goodbye to Windows. I had experience with Proton from seeing it work just fine on the Steam Deck that I bought in late 2022, and the Linux desktop gaming experience continues to not disappoint me… at least for non-VR titles. The Linux experience in general is superior to Windows in ways that don’t get talked about enough. To update my system, I only need to reboot once, and it reboots quickly. Windows would sometimes take ages and reboot twice, and greet you with a new login interstitial, Edge or OneDrive marketing push upon login. I don’t know if I’ll ever have the patience to put up with that again.

Still, as much as I like Linux, and particularly Arch Linux, and as much as I appreciate what Valve has done for Linux gaming, I’m not the type to buy the Frame just to “signal support” for the platform, or just because it runs an exquisite arm64 variant of my preferred Linux distro. Maybe if it were cheaper, like the Deck was… but we’ve known, for a long time, that a low price wouldn’t be the Frame’s forte.

The reason I waited for the Frame instead of buying any other VR headset was that I believed that Valve would not only provide an alternative to Meta’s VR ecosystem, which I want absolutely nothing to do with, but also deliver a stellar user experience, particularly when it comes to hardware-software integration, even if the raw numbers in the hardware spec sheet didn’t stand out (as they do not). Even if the UI design isn’t always the most polished with Valve software, by hardware-software integration I mean that their things tend to work well together. For concrete examples: consider how you can just install Steam on most popular Linux distros, pick one Windows game off of your library, and it’ll probably launch without extra fiddling. Consider how well game standby works on the Deck. It’s this type of “it just works” experience that I was seeking when it comes to VR.

Additionally, the ergonomics of Valve hardware tend to be top notch, as we now know is the case with the Frame, too. Valve knows and respects that some people will want to “hold it wrong” and make changes at their own risk. They are relatively good at providing replacement parts, even out of warranty. Their pro-consumer approach to their hardware was good enough to make me, and many others, forget about the darker things Valve does, like the gambling mechanics they introduced in their free to play games and which still make them millions to this day.

Considering that the Deck, the Machine and the Frame all run SteamOS, with Valve having invested millions in the Linux gaming ecosystem by now, I expected the Frame to deliver the best VR experience possible for Linux gamers like myself, as similar as possible to that “it just works” experience that Proton provides. We knew that the Frame itself was going to be primarily oriented around streaming VR games from a more powerful machine (probably even the Machine), even if it would have some degree of standalone gaming capability - like the latest Meta Quests, but without being tied to Meta’s OS and ecosystem.

For this standalone capability, Valve is sponsoring FEX and working on their own Proton-like compatibility layers for running both x86 PC games on the Frame’s ARM SoC, as well as some Android games. It was known, for months now, that Valve was working on porting and validating a limited selection of the Arch Linux package repository on 64-bit ARM, so they could make an arm64 version of SteamOS. Everything looked rosy for the Linux ecosystem, and the community is already reaping the benefits: unofficially, people have already been getting PC games, and Steam itself, to run on some arm64 non-VR handhelds.

A few days ago, the incorrect Linus, the one with the Media Group and the alleged Tech Tips, broke the Frame review embargo date. I watched the leaked video and to my greatly negative surprise, it was claimed that streaming VR games from the Steam Machine wasn’t supported. That didn’t sound good, at all. My understanding, from all the marketing material and from the reviewer’s impressions, is that the golden path for the Steam Frame, the use case around which it is designed, is for wirelessly streaming VR games from a PC. And now you tell me that Valve didn’t manage to get that golden path to work with the PC of the same family of products? A family that was originally meant to release in “early 2026?!”

Surely, it was just a prerelease issue. Or maybe, the team at Linus Media Group was holding something wrong. Maybe they had dropped something prior to testing. Alas, as the embargo was properly lifted yesterday, more reviewers came out saying the same thing. The Steam Frame store page presently says, “Stream from your PC, laptop, Steam Deck or (coming soon!) Steam Machine.” That “coming soon” doesn’t inspire much confidence, considering the Valve Time track record, which has been proven again with “early 2026” turning into “September 2026” for the Frame.

From the videos I saw, the one from Gamers Nexus went into the most detail on this issue, briefly showing the error, or an example of the types of errors, that show up when attempting to stream a VR game from the Machine to the Frame. Unfortunately, none specify whether this is a Machine-specific issue, or whether it affects Linux desktops in general. I hope it’s the former and I’m writing all this rant for nothing; indeed, the Deck is not included in Valve’s “coming soon,” but that might be because streaming VR titles from the Deck, with its weaker CPU and GPU, is not an expected use case anyway. The more I think about this, the worse I suspect it is, and I really hope it’s just paranoia and pre-purchase anxiety.

The Machine is just an x86 PC with an AMD CPU and an AMD GPU, and it is running SteamOS which is just a not-so-rolling-release variant of Arch. To me, this raises flags: if the Machine had anything extra special about it, either hardware or software-wise, then there would be hope that this feature gap would be due to it. But with the Machine being just a Linux PC, doesn’t that mean that VR game streaming is generally broken in all similar Linux desktop setups, like mine? On my desktop, I use an Arch variant, running KDE Plasma with Wayland - just like the SteamOS desktop mode, and just like most people running CachyOS. If the claimed incompatibility were exclusive to the SteamOS game mode, wouldn’t Valve mention that the desktop mode can be used as a temporary workaround? I hope I’m wrong, but it feels like a more fundamental incompatibility that goes beyond the game mode. Because the desktop mode of SteamOS is not that different from my personal Arch setup, I’m afraid I’d be affected too.

It’d be funny if this were one of the good old nemeses of the Linux desktop rearing its head: lack of support for the wireless dongle that ships with the Frame. Some random people online suggested it could be this, but we know it’s not a complete lack of support, because streaming of non-VR games from the Machine works fine. Besides, generally speaking, Linux support for different wireless chipsets has greatly improved over the last decade or so, and it’s difficult to believe Valve wouldn’t pick an already supported chip or at least one that they could easily make work. Finally, my understanding is that the dongle is meant to be optional, a plug-and-play solution for those without sufficiently modern and beefy wireless access points at home.

That friend who owns a Valve Index, and who has more recently also switched from Windows to Arch Linux, has an Nvidia GPU, and uses Plasma with Wayland, does not have great feedback about Linux support for VR gaming. They claim they must power cycle the Index when they start SteamVR (possibly related bug report), the Steam overlay has some kind of broken background effect that can be nauseating, SteamVR Home reportedly doesn’t work at all. They say they can’t control the desktop through the overlay, which is a near deal-breaker for them, and to me sounds like typical “Wayland is more secure than X11” shenanigans1. However, the Valve Index is old news, Valve could have something cooking ready to release with the Frame, and/or they could have specific changes in SteamOS to better support at least the Frame <-> Machine situation, so I was cautiously optimistic.

I had other reasons to be optimistic about the software story: I believed that the delay in the launch of the three Valve hardware products of the year, originally announced to release in “early 2026,” had mostly to do with the RAMpocalypse, not their software development lifecycle. Therefore, in my mind, Valve had extra time to get the software side of things ready for prime time. However, at least when it comes to supporting streaming from Linux PCs and even from their own recently released one, this extra time appears to have been insufficient. This makes me fear that whatever the blocker is, it is one that is difficult to overcome.

It’s true that, with their limited stocks and associated lottery and waitlist systems, it’s unlikely that many people - even among the most ardent Valve fans - will have both a Machine and a Frame any time soon. But there will be some that do - the YouTube channels reviewing gadgets like these, if nobody else. For both devices to not play well together at launch, it gives an impression of a rushed launch, and reinforces my fear that the problems that need solving are not simple. After their track record with the Steam Deck, the Machine and the Controller, which all run Linux or work with Linux just fine, it feels atypical for Valve to not get the Linux-only golden path right with the Frame.

I understand that we’re talking about the intersection between two niche market segments: VR gaming (and at enthusiast prices, at that), and Linux gaming. From purely a business numbers standpoint, and outside of this context, it’d make little sense to care about such a small potential user base. But Valve hasn’t traditionally behaved like the typical public megacorporation that mainly wants to appease the stock market and play a short-term numbers game. Valve has already poured millions into the Linux gaming ecosystem and the Steam Frame is not releasing alone, it has always been marketed as part of the same family of devices as the Steam Machine. We know they want Linux gaming to work, at least on their devices, and the reason has been obvious ever since Windows 8 came out with its app store. Their strategy is to turn the Linux gaming niche into less of one.

I also understand that it is my own choice to use Linux on my computers. As much as Valve seems to encourage Linux gaming, they haven’t forced me to switch to Linux, and the overwhelming majority of PC gaming still happens on Windows - I say, begrudgingly. One of the main rules of most free and open source software is that it is provided without a guarantee of fitness for particular purposes; especially considering the wide variety of hardware and software configurations that can make up a “Linux desktop,” I certainly don’t expect Gabe Newell to personally come and fix compatibility issues on my Arch install. If the Steam Machine streamed perfectly to the Frame but my PC didn’t, then it’d be on me and the rest of the community to figure out how to replicate what Valve did. But when it doesn’t presently work right among their first-party hardware and software configuration…

If this incompatibility is prompted by, say, a Wayland thing, or a Mesa bug or limitation, then I’d expect Valve to be doing things like using “hastily made” forks of the relevant software components on their Machine and/or Frame, in order to allow the two to work together until a more mainline-compatible solution is eventually developed. That such “hack” wasn’t ready, for a product that’s releasing at least six months past the planned launch date, is slightly surprising, considering that Valve and their subcontractors working on Linux-related initiatives have historically shown great competence. I’d absolutely love to know the technical details behind this hurdle. To be fair, I’m just not looking hard enough - someone who lives and breathes through the relevant mailing lists probably knows. But from an end user perspective, the messaging from Valve is not reassuring, with that “(coming soon!),” and no one has a conclusive answer in the few discussions I found online.

I’ve signed up for the Steam Frame list anyway, and I’ll have a difficult decision to make, as soon as I’m offered the limited time option to buy the Frame, which could be as soon as September 18.

  • If I buy it, it’ll be a bit of a gamble, with hopes that the apparent Linux compatibility issues will be sorted out actually “soon.” It’s a decision I’d make with the awareness that until the issues are sorted out, I would have a subpar and incomplete experience. For VR titles, I’d be limited to standalone ones running on the Frame itself, with the limited fidelity and short battery life that implies. Even after the main blocker is addressed, who knows what kind of quality issues (e.g. increased latency) this product will have when streaming from Linux? It’s not like any reviewer was able to test this configuration, yet. That’s a subpar experience for which I will have unjustifiably paid a premium. I am certainly not setting up a Windows machine again just for VR gaming, and my negative feelings would go towards the Valve product and towards regretting my purchase, not towards my decision to ditch Windows.
  • If I don’t seize an eventual opportunity to buy the Frame, I’ll see other people take my place in line, and if I ever change my mind (e.g. once the Linux compatibility situation improves), I’ll be at the back of the queue, waiting months/years to buy something whose price and specs may look even less impressive by then. Or not, with the way consumer hardware only seems to get more expensive lately.

If money weren’t a concern, the first option would definitely be the preferable one. However, as everyone has rightly pointed out, the Steam Frame is not cheap. If I were to actually buy one and regret it, I’m sure I could always sell it in the used market. However this can be bothersome, there are some risks to it, and I don’t want to feel like a scalper; I actually want this specific product to work for me, because I realize that other similar products in the market will probably not have a better Linux compatibility story.

I had some doubts and fears around the Steam Frame: that it could be too expensive, that I could end up regretting the purchase due to the novelty of VR wearing off, that my desktop’s hardware specs couldn’t be up to the task of high-fidelity VR experiences, or that the compatibility with existing titles in standalone mode would be subpar (and the jury’s still out on that one…). Having “will this work with my Linux desktop?” be my primary concern, is definitely not what I expected from a 2026 Valve hardware release. Valve, please fix (your marketing page).


  1. Note that this use case is different from operating the desktop mode in the Steam Frame: in that case, the Frame is running KDE with the sole rendering surface for the latter being the VR environment; in my friend’s case, they have started a Plasma Wayland session “within which” they have a program rendering a VR environment, and they want to control the “outer” session from within that environment. The Frame renders “KDE in VR” while the more typical desktop VR experience has “VR in KDE” trying to re-render and control the “outer” desktop environment. ↩︎