Linux gamers spent a decade asking for native ports, but Valve gave them something better

Published Aug 13, 2026, 8:00 PM EDT His love of PCs and their components was born out of trying to squeeze every ounce of performance out of the family computer. Tinkering with his own build at age 10 turned into building PCs for friends and family, fostering a passion that would ultimately take shape as a career path. Besides being the first call for tech support for those close to him, Ty is a computer science student, with his focus being cloud computing and networking. He also competed in semi-pro Counter-Strike for 8 years, making him intimately familiar with everything to do with peripherals. For most of the 2010s, the thing Linux gamers wanted above all else were native ports. It was the key marker of a developer that was taking the platform seriously, and there were always forum threads created after every popular release talking about whether Linux support would be possible or not. Besides a handful of games, support was quite thin, and those threads were mostly full of requests and wishes that were sent straight into the void. Fast-forward a few years, and now, Proton is the reason why the vast majority of your library can be played on Linux, not native support. Shipping a game with native Linux support is now harder to justify before Linux had a significant gaming user base. The porting process was never popular to begin with Native ports were never a mainstream practice Native Linux ports were never a development practice that had any steam behind it (no pun intended), and that's primarily because of the miniscule player base. They were largely done by contract houses like Feral Interactive, Aspyr, and Virtual Programming, and paid for by publishers who saw Linux as a marginal but non-zero line item. Proton is what removed the "non-zero" part entirely, and it made Linux more popular, but in turn, made ports a non-factor. Feral said as much when it canceled the Linux version of Total War Saga: Troy, explaining that demand for native titles had generally fallen since Valve launched Proton. A native port, like any main build of the game, is not a one-time expense. It is an open-ended commitment to patch parity, driver regressions, and QA across distros and display stacks, which, on Linux, are continuously changing. Proton collapses all of that work into the Windows build that's being worked on anyway, and Proton handles the rest. And, despite the rise in popularity, Linux is still sitting in the single digits in the Steam Hardware Survey, so it's not like there's suddenly a massive demand, it's just slowly gaining some traction. Linux ports of games often rot, while the Proton versions are well maintained Compatibility layers are not second fiddle Changing the Proton version for a Windows game through Steam. Most surviving native Linux builds were written against OpenGL, shipped once, and then left to rot, unfortunately. Proton doesn't have this issue, since it routes DirectX calls through DXVK and VKD3D-Proton onto Vulkan, a stack that Mesa, RADV, and Valve's own driver contractors have been steadily improving for the better part of a decade now. The translation layer is doing a lot of work here, and that's why it routinely beats the native route. Pure frame rate is the least of it. Native builds routinely fall behind their Windows counterparts on patches and content, and Linux and Windows builds of the same game often refuse to share cloud saves, which leaves anyone playing across both operating systems better off forcing Proton simply to keep one save file intact. There definitely are exceptions to this, the most recent of which is BeamNG.drive, which switched its Linux handling from Proton back to a native binary in January 2026, and the developers themselves say that using Proton can cost performance. A well-oiled native port will likely always beat a compatibility layer like Proton, but it takes constant maintenance. Compatibility is just a checkbox, and it's on the developers now Valve made this possible Valve's biggest achievement with gaming on Linux was changing what it asks of developers, and it's mostly just a checkbox now. Studios are just required not to break things, avoid launch wrappers (even those are mostly fine) and enable anti-cheat support. That last one is the true kicker. Proton translates API calls. It cannot satisfy an anti-cheat system that expects Windows kernel-level visibility into a machine, and it cannot manufacture a publisher's willingness to trust a Linux client. What makes this infuriating rather than merely disappointing is that the technical work is largely finished. Epic added Linux support to Easy Anti-Cheat specifically designed to work with Wine and Proton, and BattlEye followed. The integration demonstrably works, with ARK, DayZ, and Arma Reforger all running under Proton with BattlEye active, while a Battleye-enabled title like Escape From Tarkov keeps it disabled. A native port doesn't fix this by default, but if a multiplayer game developer bothers to create a native Linux port, they'd also presumably enable anti-cheat support, because it'd be useless otherwise. Linux users spent a long time waiting for something that'd never come, but we've ended up in a better place Linux gamers have been asking for native support for over a decade, but they've arguably received something better. A compatibility layer that grants them access to the same, well-maintained builds of their favorite games instead of native support that would be entirely abandoned because of low adoption. Obviously, there are some very real barriers yet to cross for Linux, but gaming on the platform is extremely well-supported considering how strong Windows market share still is.