The same roadblock has existed for ARM PCs as Linux PC - the mountain of legacy stuff that only runs on x86 Windows. Which is something Steam’s Proton has directly addressed.
Now that they’ve wrapped legacy software in an OS compatibility layer (Wine/Proton) and that is being wrapped in an instruction set compatibility layer (FEX) that mountain of software is ready to roll!
Best part is, valve’s contributions are virtually all being pushed upstream, meaning unrelated projects will all benefit from the work.
2026 - Year of the
LinuxReactOS desktop!ARM is so hot right now.
Seriously, consumer devices are all slowly moving in that direction. Valve sees where things are going.
Have you considered adding a heatsink? Maybe a fan??
i am a fan
Maybe the real fan was the ARMs we grew along the way 😻😸
ARMs Race
I’ve seen ARM64 in action firsthand in the new Macbooks. The energy efficiency especially is off the charts. Since battery life was the Steam Deck’s greatest flaw, chances are an ARM architecture version can squeeze a lot more juice out of the same battery size in the future.
Valve phone? I don’t really want an arm steam deck. It’s important to me I be able to run stuff outside of games on my deck. It’s not just a handheld, it’s a full fledged pc in a handheld body.
But if they want to make a valve phone with a Linux based os…
If they get this working well, next deck is gonna be ARM for sure.
I’m confused - isn’t the Steam Frame ARM based, and using FEX? The article talks about future devices but doesn’t mention the big new device that will be using FEX in 2026?
I think the article is working off the assumption that readers already know that the Steam Frame uses ARM. Basically, it’s gonna be a testing platform for things to come.
This problem is far more difficult to solve than x64 windows apps running on x64 linux.
While x64 and ARM are both turing complete and thus anything one can do, the other can also do, there can be subtle differences to the way they do them.
Like one I’m aware of is the atomicity of loading memory using a co-processor register, which is required for accessing thread local storage, and introduces a subtle race condition if someone uses user mode multithreading (which can be way faster than kernel mode multithreading) without handling the case where they get preempted between moving that register’s value and doing the load, and end up running on a different kernel thread when they get back (because you need one kernel thread per core). That thread would end up with the pointer for another thread’s thread local storage, which tends to break things pretty badly.
That’s just one that I’m aware of. There’s probably tons of other subtle differences that mean you can’t just have a map of “x in x64 means y in ARM” and use that to generate a compatible binary. It would probably run, but it would have bugs that the original doesn’t that are only seen in rare edge cases.
Not that I want to discourage this effort, but this is a problem an order of magnitude or two more difficult than the one proton solved, which was essentially just a bunch of wrappers that convert one API or OS behaviour to another equivalent one.
Arm Steamdeck? Sign me up! Arm on Linux ftw. I also have high hopes for the snapdragon x elite 2 to finally push me off macOS. Tangent on that I saw some reddit thread (yeah yeah reddit) and it mentioned that x elite 2 might support dgpus everyone said “but why though”? Well the answer is so that you can disable it and have killer battery life and then just enable it later for performance. Why wouldn’t everyone want that?
I’m guessing something about PSP sized because they have their Android Linux emulator project ongoing too
