If you’ve been following Valve’s software updates over the last year, you might have noticed something: most of the improvements aren’t about raw power or new features. Instead, they’re all about increasing compatibility and improving the responsiveness of the hardware. The latest SteamOS updates squeeze more life out of the original Steam Deck’s AMD APU, and both Wine and Proton can now use the mainline NTSYNC kernel driver to better map Windows synchronization primitives onto Linux, reducing overhead in some threaded workloads. And, the big one: Valve added FEX-2604 for Arm64EC builds in Proton 11.0 Beta, opening the door to running x86 Windows games on Arm Linux through Steam itself.
If you look at any one of these updates in isolation, it just seems like Valve is making Linux gaming incrementally better. But taking a step back and looking over all of them reveals something bigger: Valve has made “not Windows” invisible often enough that the remaining problems are no longer Direct3D or Win32 compatibility in general, but edge cases involving kernel-level anti-cheat, DRM, platform services, and titles whose assumptions simply don’t survive outside Windows. The next frontier is the “not x86” problem, and FEX is the bet Valve is making to get there.
Valve isn’t walking away from x86 or anything like that; the Steam Machine is still x86, and today, x86 is still the safest path for PC gaming. On top of that, Windows is still the primary operating system used by the vast, vast majority of gamers. Yet the company has been slowly reducing its dependency on both.
SteamOS is moving beyond the Deck
From a handheld-only OS to something bigger
For a long time, SteamOS was basically “the Steam Deck’s operating system.” It shipped on the Deck, it was optimized for the Deck, and installing it somewhere else meant dealing with driver issues and missing features. The bigger public third-party handheld milestone was SteamOS 3.7.8, which added official Legion Go S support and published installation guidance for other AMD-powered handhelds with NVMe SSDs, alongside an expanded SteamOS Compatibility label system that goes wider than the original Deck Verified program. Lenovo’s Legion Go S is the cleanest official example, and other AMD handhelds are more of an expanded install path than a guaranteed Deck-like experience.
SteamOS 3.8 is the follow-through on 3.7.8, and the preview adds initial Steam Machine support, updates the Arch base, kernel, and graphics stack, and continues to iterate on desktop and game-mode functionality. Together, they make SteamOS feel less Deck-bound than ever before.
Valve is also preparing SteamOS to run on its own upcoming hardware. The Steam Machine ships on x86; the Steam Frame VR headset uses Qualcomm’s Snapdragon 8 Gen 3, an Arm64 mobile SoC, which means SteamOS and its surrounding compatibility stack span both x86 and Arm. The Steam Machine store page is live with full specs, but still hasn’t been officially announced. Reports have suggested that Valve’s final pricing and release-detail announcements have been complicated by the massive increase in memory and storage costs.
Arm is on the table because major parts of the industry have already made the move, and both Qualcomm and MediaTek are pushing hard into Windows laptops. As a result, Microsoft has thrown serious weight behind its Windows-on-Arm Prism translation layer, and Apple’s M-series transition is several years deep and effectively complete thanks to Rosetta 2 easing the transition. By making the move to Arm, Valve isn’t betting against the industry here; arguably, they’re moving with it. At the same time that they’re also making a big bet on Linux.
FEX fills the x86-to-Arm gap
Running Windows x86 games on Arm
FEX-Emu is, on paper, a straightforward piece of engineering. It’s a usermode x86 and x86-64 emulator/JIT for Arm64 Linux. It translates raw x86 instructions into Arm64 instructions at runtime using just-in-time (JIT) compilation, similar to what Apple did with Rosetta 2 for M-series Macs. In the Proton stack, FEX handles the CPU instruction translation; the Windows API and graphics compatibility layers (Wine, DXVK, VKD3D-Proton) still do the heavy lifting on the API side. FEX solves the instruction-set problem; Proton still has to solve the Windows problem.
That two-layer split is what makes this harder than Rosetta 2. Apple only had to translate macOS-on-x86 to macOS-on-Arm, but the operating system stayed the same on both sides. Valve has to translate Windows-on-x86 to Linux-on-Arm, which means CPU instruction translation through FEX and a full Windows-to-Linux translation through Wine, DXVK, and VKD3D-Proton, stacked on top of each other. Each layer is its own engineering problem, and any one of them can be the thing that breaks a given game.
FEX was originally an independent project maintained by a small team of enthusiasts who wanted to run x86 Linux applications on Arm64 devices. Valve has supported and sponsored its development for several years now, and the project has been accelerating since. Recent FEX work has included JIT improvements, call-return stack work, hardware TSO (total store ordering) support where the SoC allows, and x87-related optimizations that can improve performance in games that rely on older x87 floating-point behavior.
The real milestone came with FEX-2604, which Valve bundled directly into Proton 11.0 Beta alongside a new Arm64EC configuration. Arm64EC is the bridge target here, as it’s Microsoft’s Windows ABI for mixing Arm64-native and x64-compatible code, and Proton 11’s Arm64EC builds now include FEX-2604 for the x86-64 translation piece. This gives Valve a cleaner way to combine native Arm pieces with translated x86-64 code instead of treating the whole stack as one giant emulation blob. Even so, it’s the first time the integration has lived inside Valve’s official Proton beta stack rather than as a side experiment. Steam games can even run on a modded Nintendo Switch thanks to the latest Proton and FEX updates.
The performance isn’t native, as you’d expect, but it’s still surprisingly good. Translation layers always carry overhead, but the gap is narrowing over time, and the strategic payoff is thousands of Windows x86 games running on Arm hardware without developers needing to actually ship native Arm versions. Developers can keep shipping Windows x86-64 binaries the way they always have, and those binaries reach SteamOS, Arm-based handhelds, and the Steam Frame without any additional work. Valve isn’t asking the industry to do something new, as all it’s doing is removing the native-port pressure that killed the original Steam Machines.
However, the overhead of FEX isn’t the only Arm problem, as plenty of Windows games carry x86-specific assumptions baked into their builds. For example, both SSE and AVX in shader compilers and physics code, x86-specific timing assumptions for frame pacing or networking, hand-rolled assembly in older engines, and DRM wrappers that sniff the host CPU and bail out when it isn’t what they expected. FEX can paper over a lot of that, but each one is a separate edge case rather than a single problem that gets fixed once.
I’ve tested out FEX and Proton myself, and the experience is pretty impressive given the two translation layers in play. On the Lenovo ThinkStation PGX, an Nvidia GB10 Grace Blackwell mini PC running Ubuntu 24.04 for aarch64, both Cyberpunk: 2077 and Doom: Eternal were a genuinely pleasant experience to play. At 1440p on max settings, Counter-Strike 2 averaged 117 FPS, Cyberpunk 2077 sat around 50 FPS, and DOOM Eternal ran between 140 and 170 FPS. It was an incredibly seamless experience once I had FEX up and running.
The thing that makes those numbers possible is “thunking.” FEX’s thunking layer lets OpenGL and Vulkan calls from the translated x86 environment route into native aarch64 graphics libraries and drivers instead of emulating the entire graphics stack. For Direct3D games, DXVK or VKD3D-Proton still converts those calls to Vulkan first. When that’s wired up correctly, the GPU runs near-native and the only translation cost is on the CPU side. When it isn’t, you get what happened on my first attempt in that same test: a manual setup that fell back to software rendering, where Cyberpunk took several minutes just to draw a loading screen because every shader instruction was being emulated on CPU cores.
Proton has become the real product
Wine is the foundation, but Proton is the experience
There are really two transitions happening here: Proton reduces Valve’s dependence on Windows, and FEX reduces its dependence on x86, and SteamOS is the layer that lets Valve pursue both at once. We’ve talked a lot about FEX, but Proton is Valve’s complete Wine stack, built on Wine while adding DXVK for Direct3D-to-Vulkan translation, VKD3D-Proton for Direct3D 12, Steam-specific fixes, controller integration, fullscreen handling, and automatic per-game configuration. You install a game, and then you play the game, with Proton chugging away invisibly in the background.
The most underrated part of how Proton scaled to be the PC gaming powerhouse it is today is that the Steam Deck did most of the heavy lifting on the developer side. Before the Deck, “works on Linux” wasn’t something most developers cared for. After all, why would they? But after the Deck launched, “Steam Deck Verified” became something publishers could chase, and many actually did. Deck owners are real customers buying real games, and bad Proton compatibility shows up as refunds and poor reviews. Hardware sales forced developers to pay attention, and developer attention meant that Valve got more data on what games worked, what games didn’t work, and in the latter case, why they didn’t work. This, in turn, makes the Steam Deck an even more desirable product, and this feedback loop is the thing the original Steam Machines never had.
Proton 11 is still in beta, but its direction is what matters here. NTSYNC is now in the mainline Linux kernel, giving SteamOS a cleaner path to expose Windows-style synchronization improvements through Proton. Wine 11.5 added syscall user dispatch support, helping with direct-syscall edge cases that previously broke games like Detroit: Become Human and Red Dead Redemption 2. And with Arm64EC configuration options in Proton 11, Valve is starting to extend the compatibility layer beyond x86.
Compatibility, in 2026, is no longer a build problem as far as developers are concerned. In fact, the largest hurdles typically come in the form of kernel-level anti-cheat, DRM, and platform services rather than Direct3D calls or missing Win32 functions. That’s a different kind of problem that Valve can’t solve on its own.
Proton also doesn’t sit in a vacuum. As we’ve mentioned, Microsoft is doing its own x86-to-Arm translation with Prism in Windows 11, and over the last few years, Apple finished its x86-to-Arm transition with Rosetta 2 as the stepping stone to aid the developer transition. Valve is the one Linux-side player executing on the same architectural shift the rest of the industry has already committed to, and arguably the one player whose business model depends most directly on a Windows-based application running succesfully. No matter the platform.
Microsoft has a lot to think about as well, here. Microsoft’s grip on PC gaming has been built on a bundle of assumptions: Windows is the default platform and DirectX is the default graphics target, meaning that if you wanted to ship a PC game, you targeted Windows. The OS acted almost as a cyclical type of vendor lock-in, though SteamOS alongside Proton and FEX inverts that. The Windows binary still works as a build target, but Windows itself is no longer a required runtime. Even on x86 hardware where Windows would ordinarily be the obvious choice, like the Steam Machine, Valve is offering a credible alternative platform that runs the same library. It’s not a death blow to Microsoft now, but for games, we’re honestly at the strange point now where compiling for Windows may be the most practical way to reach multiple platforms with one binary.
The hardware strategy behind the software
Waiting for the right chip, not just a faster one
While the software has been maturing, Valve has been equally patient with hardware. The company hasn’t released a Steam Deck successor since the original launched in 2022, despite the fact that most of its competitors release new handhelds every year or two. Valve has said it wants a true generational Deck 2 jump, not the typical spec bump that could risk sacrificing battery life. The original LCD Steam Deck shipped with a custom 7nm AMD APU based on Zen 2 and RDNA 2, and the OLED refresh moved to a revised 6nm version of the same broad Zen 2/RDNA 2 APU architecture. With a low TDP on the Steam Deck, the games that run well under those conditions can feasibly see eight hours of play time.
The Steam Frame matters a lot here, but with a caveat: it’s streaming-first, with a lot of heavy rendering offloaded to a host PC, so its Arm workload profile isn’t a true proxy for a standalone Deck 2. The Frame is a proof of capability product, not proof of the Steam Deck 2’s architecture. Valve’s handheld history is firmly AMD x86, and there’s no public indication that’s changing, but the path exists if they want it, and it gives them access to SoCs designed around mobile power envelopes with significantly longer battery life as a result.
Valve’s current SteamOS-era hardware strategy now has three distinct pillars: the Steam Machine is the living-room PC, the Steam Frame is the Arm-based proof of concept, and the Steam Deck remains the battery-constrained handheld. All three sit on top of SteamOS and point at the same Steam library, even if the practical compatibility profile differs by device. Proton and FEX aim to unify the compatibility, and Valve’s long term goal seems to involve them putting their eggs in every basket to reduce their reliance on any given platform or operating system.
The bigger picture is this: your game library is still mostly a Windows library, but the experience no longer has to be on Windows. With SteamOS, Proton, and FEX maturing in parallel, Valve has spent years making the host operating system disappear from the player’s point of view. It’s not about replacing Windows today, tomorrow, or even in the next year. Nor does Valve seem to care about forcing a transition away from x86 anytime soon. Afterall, translation layers carry overhead, and anti-cheat, DRM, platform services, and x86-specific assumptions can still break games. But for a considerable number of mainstream Steam games, Proton is already invisible to most users.
When you have a truly fantastic compatibility layer, to the end user, it’s arguably not even there. You don’t have to think about it, and you can just play your games. It’s worked so far on the software side, and when the hardware beneath it shifts from x86 to Arm without anyone noticing, you’ll only realize it happened by looking back at what Valve built.