{"id":420388,"date":"2025-12-02T21:56:15","date_gmt":"2025-12-02T21:56:15","guid":{"rendered":"https:\/\/www.europesays.com\/us\/420388\/"},"modified":"2025-12-02T21:56:15","modified_gmt":"2025-12-02T21:56:15","slug":"steam-machine-today-steam-phones-tomorrow","status":"publish","type":"post","link":"https:\/\/www.europesays.com\/us\/420388\/","title":{"rendered":"Steam Machine today, Steam Phones tomorrow"},"content":{"rendered":"

It\u2019s a big deal that Valve is making a game console<\/a>. But I\u2019m beginning to think the Steam Machine may end up a footnote in gaming history. What if Valve could bring PC games not just to its own living room consoles, but also to the Arm chips that billions of people have in their phones? What if you no longer had to wait for game developers to do the hard work of porting PC games to your phone, Mac, or other Arm hardware, because games built for desktop PCs could just work?<\/p>\n

If you wrote off the Steam Frame<\/a> as yet another VR headset few will want to wear, I guarantee you\u2019re not alone. But the Steam Frame isn\u2019t just a headset; it\u2019s a Trojan horse that contains the tech gamers need to play Steam games on the next Samsung Galaxy, the next Google Pixel, perhaps Arm gaming notebooks<\/a> to come.<\/p>\n

I know, because I\u2019m already using that tech on my Samsung Galaxy. There is no official Android version of Hollow Knight: Silksong, one of the best games of 2025, but that doesn\u2019t have to stop you anymore<\/a>. Thanks to a stack of open-source technologies, including a compatibility layer called Proton and an emulator called Fex, games that were developed for x86-based Windows PCs can now run on Linux-based phones with the Arm processor architecture. With Proton, the Steam Deck could already do the Windows-to-Linux part; now, Fex is bridging x86 and Arm, too.<\/p>\n

This stack is what powers the Steam Frame\u2019s own ability to play Windows games, of course, and it was widely reported that Valve is using the open-source Fex emulator<\/a> to make it happen.<\/p>\n

What wasn\u2019t widely reported: Valve is behind Fex itself.<\/p>\n

In an interview, Valve\u2019s Pierre-Loup Griffais, one of the architects behind SteamOS and the Steam Deck, tells The Verge that Valve has been quietly funding almost all the open-source technologies required to play Windows games on Arm. And because they\u2019re open-source, Valve is effectively shepherding a future where Arm phones, laptops, and desktops could freely do the same. He says the company believes game developers shouldn\u2019t be wasting time porting games if there\u2019s a better way.<\/p>\n

Remember when the Steam Deck handheld showed that a decade of investment in Linux could make Windows gaming portable? Valve paid open-source developers to follow their passions<\/a> to help achieve that result. Valve has been guiding the effort to bring games to Arm in much the same way: In 2016 and 2017, Griffais tells me, the company began recruiting and funding open-source developers to bring Windows games to Arm chips.<\/p>\n

Fex lead developer Ryan Houdek tells The Verge he chatted with Griffais himself at conferences those years and whipped up the first prototype in 2018. He tells me Valve pays enough that Fex is his full-time job. \u201cI want to thank the people from Valve for being here from the start and allowing me to kickstart this project,\u201d he recently wrote<\/a>.<\/p>\n

I didn\u2019t realize it at the time, but when I showed off Silksong on my Samsung Galaxy S25<\/a> using the GameHub app, I was running it on Fex, and Proton, and other Valve-backed open-source tech. Even if Valve never makes a Steam Phone, developers can take the tech and run.<\/p>\n

So: Why Arm, how does any of this work, and might Valve make that Steam Phone? I asked Griffais, and here\u2019s what he said \u2014 edited for brevity and clarity.<\/p>\n

Pierre-Loup Griffais:<\/strong> In 2016, 2017, there was always an idea we would end up wanting to do that, and that\u2019s when the Fex compatibility layer was started, because we knew there was close to a decade of work needed before it would be robust enough people could rely on it for their libraries. There\u2019s a lot of work that went into that.<\/p>\n

It all started with the same assumption that you\u2019re going to get the same experience on Arm, you\u2019re going to have the same set of games, and you\u2019re going to be able to run them without having to worry about what architecture your computer is using. That was really our goal, to try to reduce barriers for users not having to worry about what games run and for developers to get a starting point for those new devices.<\/p>\n

Because there\u2019s a lot of price points and power consumption points where Arm-based chipsets are doing a better job of serving the market. When you get into lower power, anything lower than Steam Deck, I think you\u2019ll find that there\u2019s an Arm chip that maybe is competitive with x86 offerings in that segment.<\/p>\n

We\u2019re pretty excited to be able to expand PC gaming to include all those options instead of being arbitrarily restricted to a subset of the market.<\/p>\n

When you say \u201cinclude all those options,\u201d you\u2019re thinking there\u2019ll be other Arm SteamOS devices, too? <\/strong><\/p>\n

Yeah, and I\u2019m excited about that. I think that it paves the way for a bunch of different, maybe ultraportables, maybe more powerful laptops being Arm-based and using different offerings in that segment. Handhelds, there\u2019s a lot of potential for Arm, of course, and one might see desktop chips as well at some point in the Arm world.<\/p>\n

Desktops are not completely out of the question: Designs like, say, the Framework Desktop<\/a> use essentially a big SOC, right? And those big SOCs have existed in the Arm world for a while. Apple\u2019s making very good-quality examples of that<\/a>, so it\u2019s not too crazy to imagine something like that in the PC space at some point.<\/p>\n

When and how are you attracting companies to build those other kinds of devices?<\/strong><\/p>\n

I don\u2019t think there\u2019s a specific plan there. I think the first step is for us to ship what we have, and it will maybe show the way. Then it\u2019s all based on the conversations we have after that.<\/p>\n

If there are good opportunities, they will be made easier and easier over time because we\u2019ll keep building the hardware support, we\u2019ll keep greasing the wheels, so to speak, so that SteamOS can work on a wider variety of Arm devices, but also so that the catalog becomes more reliable there in terms of compatibility and performance.<\/p>\n

We might have people reaching out, or we might reach out based on what we\u2019re seeing OEMs build. Maybe they\u2019ll build something with a different OS that we think would be a good fit with SteamOS or vice versa. In the handheld space, some collaborations were us reaching out, some were OEMs reaching out to us.<\/p>\n

We\u2019re seeing the same thing right now in the living room, where we\u2019ve already had some good conversations with folks in the living room space that think SteamOS could be a good fit. As we work on SteamOS for Steam Machine, that\u2019s closer to becoming a reality. We\u2019re excited to partner with folks after that. I think the same will happen for SteamOS for Arm.<\/p>\n

Is the Arm version of SteamOS a separate operating system?<\/strong><\/p>\n

It\u2019s the same exact OS components, the same exact Arch Linux base, all the same updater, all the same technologies. Depending on form factors, you might have different pieces of software that you want to be running or not running \u2014 some of them make more sense on a handheld, some more sense on a headset, some in desktop form factor, but all of those options are always available and part of the core OS.<\/p>\n

So when you\u2019re looking at SteamOS on Arm, you\u2019re really looking at the same thing. Instead of downloading the normal Proton that\u2019s built for x86 and targets x86 games, it will also be able to download a Proton that\u2019s Arm-aware, that has a bulk of its code compiled for Arm and can also include the Fex emulator.<\/p>\n

Can you break down those layers for us? When I\u2019m playing a Windows game on my Steam Deck, how does that work? <\/strong><\/p>\n

If you\u2019re playing that game on your Steam Deck, you\u2019re going to be playing it through Proton, which is essentially a distribution of Wine<\/a>, bundled with everything you would need to run any sort of game made for Windows.<\/p>\n

The game itself is a Windows executable, right? At a core level, the Linux operating system does not even know how to load the program, and so, instead of invoking it through the OS, you invoke it through Proton, which is going to do the first step of setting up the address space, loading the segments of code into memory. The code coming from the app is all x86, and so Proton is a facilitator. It puts the existing code of the app in a format and a layout that the Linux OS can understand and then starts executing that code.<\/p>\n

Whenever that game code makes an API call for something it was built against in its original development environment, either just a core C runtime library or higher-level APIs like DirectX or DirectSound, or USB enumeration or input \u2014 whenever the game calls those functions, those functions exist in Proton\u2019s code, and it\u2019s going to be Proton implementing that and giving you results. Or giving the game a result based on the Linux OS, as opposed to the other environment that the game was designed for. So it\u2019s just an alternate implementation for all those APIs.<\/p>\n

At the end of the day, the code of the game is not changed, right? It\u2019s the same code that\u2019s loaded into memory and executed natively by the CPU.<\/p>\n

How is Wine different from Proton?<\/strong><\/p>\n

It\u2019s really the same thing. Proton includes Wine, and the bulk of development that\u2019s happening Wine is actually driven by Proton; it\u2019s all the same set of developers. But there\u2019s a branch of Wine that is Wine plus a bunch of experimental gaming-focused stuff. That is what we\u2019re currently working on at the moment, and when it gets tested enough, it\u2019s no longer experimental and goes into Wine proper and then everyone has it.<\/p>\n

Proton is just a preview of the latest and greatest Wine. Its goal is to provide the best game compatibility, so all the APIs the game might run are well supported and offered with good performance and has all the gaming stuff configured for you. It includes those extra layers like DXVK, which is a D3D11 driver that\u2019s translating to Vulkan, and VKD3D, which is a D3D12 layer that translates to Vulkan as well. There\u2019s also built-in support in Wine that targets OpenGL.<\/p>\n

Proton is targeted towards the Steam runtime, so it\u2019s using all the libraries that are provided by Steam, so you don\u2019t need to install any extra components in your OS, and it\u2019s also integrated with Steam and games in general to manage save data and so Steam can find games for cloud save purposes.<\/p>\n

How does all of this change when we\u2019re running Windows games on Arm?<\/strong><\/p>\n

First there\u2019s an intermediate step. Anytime you\u2019re setting up code segments, Wine is now going to try and see if it\u2019s x86 or Arm code, because some Windows apps are targeted towards Arm or might include mixed segments, or a DLL might bundle both Arm and x86 code. If there\u2019s x86 code, it will put it in the right spot with enough functionality to jump in and out of the Fex emulator.<\/p>\n

The Fex emulator\u2019s sole purpose is to provide compatibility with x86. So it takes the x86 code, and uses a just-in-time translator to emit Arm code that does the exact same thing. Proton built for Arm support will make sure that whenever it\u2019s setting up code segments, any code segment that\u2019s x86 will properly jump into Fex so it can be run through Fex instead of the native CPU.<\/p>\n

All the game code is translated by Fex, so it has a bit of work to do. But when the game jumps into an API call, like, say, issuing a draw call to the graphics driver through the Vulkan or D3D12 API, it will immediately jump into Arm-native code. Because you\u2019re running Arm-native code built as part of Proton, the area you have to emulate is only the code that\u2019s owned by the game itself. So the performance hit of any emulation stops as soon as you cross that API boundary between Windows and Linux.<\/p>\n

How does this compare to other Windows-on-Arm emulation, like<\/strong> Prism for Windows on Arm<\/strong><\/a>?<\/p>\n

I don\u2019t really know how the Windows one works and what its priorities are, so I\u2019m not the best person to talk about that. I think what I would say about Fex is, it was designed for being able to attain the best performance possible for gaming stuff in a way that also guarantees the best correctness.<\/p>\n

Some games do tricky things with a CPU when they\u2019re trying to do anti-tamper and things like that, and so by making sure that we implement the emulation with 100 percent correctness, I think we have good support for that.<\/p>\n

You\u2019ve told me Valve is really funding a lot of this Proton development, this Wine development, and I\u2019ve heard that the same thing is happening with Fex. How long has Valve supported Fex and to what degree? <\/strong><\/p>\n

That\u2019s right, all the core developers have been funded by us since the beginning. We definitely started that project with the idea that it would be something that\u2019s useful for the ecosystem at large, but also something that would be really useful for SteamOS and other applications in the future.<\/p>\n

We identified that Arm compatibility was going to be really important so that folks can enjoy those new options in the market without having a whole bootstrapping problem of \u201cwhere are the games going to come from.\u201d The last thing that we want, and that\u2019s been our philosophy since forever, is we don\u2019t want game developers to have to spend a bunch of time porting things to different architecture if they can avoid it.<\/p>\n

We would way rather have those game developers invest their time and energy into making their games better, or working on their next game. We think that porting work is essentially wasted work when it comes to the value of the library.<\/p>\n

Proton is also something where you could say we started it, but because it\u2019s a derivative of Wine, it\u2019s less clear-cut. Whereas Fex, we were talking with a few developers that we knew were the right fit for an undertaking like that, a long-term thing that needed a very specific set of experts. We worked hard on trying to convince these guys to start the project, and have been funding them ever since.<\/p>\n

The Steam Frame<\/strong> runs Android apps<\/strong><\/a>, but it\u2019s not Android running on the headset. How?<\/strong><\/p>\n

It\u2019s a similar compatibility layer as Proton, just targeted at Android. There\u2019s not a whole Android API and implementation there, just a subset mostly targeted towards games, providing the right libraries on our side, so that things typically contained in an Android executable can run. They\u2019re already targeting Arm, so you don\u2019t need to do emulation on the code that\u2019s contained there. You just need to set up the libraries and executable in such a way that it can run in the first place.<\/p>\n

Will there be SteamOS phones? Will you bring non-gaming apps into the store in a big way?<\/strong><\/p>\n

We have done things around phones with the Steam Link app<\/a>. I don\u2019t know if that\u2019s going to be a big focus for us to develop local content or try to develop SteamOS for devices like that. I mean, I\u2019m not discounting any possibility, but I think with just living room, handheld, and desktop, trying to have a good outcome for gaming applications and everything else you\u2019d want to do in a desktop, we have a ton of work to do.<\/p>\n

Is Arm the future of handheld gaming, or is it just something for headsets?<\/strong><\/p>\n

I don\u2019t know. I think Arm devices are definitely a good fit for lower performance, like anything lower than Steam Deck. But it\u2019s possible it\u2019ll be a good option for something on the order of the Steam Deck performance envelope. We don\u2019t really try to steer the market one direction or another; we just want to make sure that good options are always supported.<\/p>\n

Follow topics and authors<\/strong> from this story to see more like this in your personalized homepage feed and to receive email updates.<\/p>\n