Steam zet Proton standaard aan op Linux bij games zonder native ondersteuning

Steam voor Linux schakelt Steam Play en de Proton-compatibiliteitslaag in recente bètaversies standaard in bij alle games die geen native Linux-ondersteuning hebben. Voorheen was Steam Play alleen ingeschakeld bij ondersteunde games.

Het bedrijf heeft de optie om Steam Play in te schakelen voor niet-ondersteunde titels verwijderd uit recente bètaversies, schrijft GamingOnLinux. In de stabiele versie van Steam moeten gebruikers Steam Play nog wel handmatig aanzetten voor alle games. Voor ondersteunde games staat de functie altijd aan.

Het is niet bekend in welke bètaversie Valve de verandering heeft doorgevoerd. Het bedrijf heeft de verandering niet genoemd in recente changelogs van Steam.

Reacties (62)

[--MeAngry--]

En wat is Steam Play in deze context? Waarom is dit interessant? Ik mis wat achtergrondinformatie. Ik dacht dat het daarbij ging om games een keer kopen en op alle platform spelen, maar ik mis in deze context hoe dat een verandering is van wat er al mogelijk was? Het hele doel was toch juist dat je Windows games op SteamOS kunt spelen met Proton?

Ik heb zelf een Steam Deck en ik snap niet eens wat er nou veranderd is uit dit nieuwsbericht.

[Reactie gewijzigd door --MeAngry-- op 18 juni 2025 15:47]

[Magic Power]

Steam Play is de mogelijkheid om Windows spellen te spelen op andere besturingssystemen. Meestal is dit Windows spellen spelen op een Linux besturingssysteem. Dit gebeurt met de Proton Compatibility layer, die 'layer' zorgt ervoor dat je een Windows spel op Linux kunt spelen.

Als je een Steam spel koopt, heb je toegang tot dit spel op elk OS dat je wilt. Dus als je bijvoorbeeld vroeger een spel op Windows hebt gekocht en gespeeld op Steam, kun je dit spel met jouw account automatisch ook spelen op een Linux systeem met jouw account. Je hoeft het spel niet opnieuw te kopen, het werkt op ongeacht welk OS je ook speelt. (dat ondersteund wordt door Valve).

Wat er hier aan de hand is is een beetje anders: Toen de 'Windows Compatibility Layer Proton' er in het begin was, werkte lang niet elk spel. Dus had Steam standaard een instelling dat alleen ondersteunde spellen werkte, om de ervaring voor de gewone gebruiker niet te moeilijk te maken. Wilde je meer spellen kunnen spelen, moest je deze instelling uitschakelen, en hopen dat het spel het alsnog deed. Dan kon je dus meer spellen spelen, maar het was mogelijk dat een aantal spellen het niet deden.

Op dit moment (2025) werken er al heel veel Windows spellen op Linux via dat 'Proton'. (behalve de Kernel Based Anti-Cheat spellen). Dus deze instelling in Steam is eigenlijk niet meer nodig, omdat je er redelijk vanuit kunt gaan dat je spel via 'Proton' gewoon werkt. (minus de Anti-Cheat spellen).

Daarom heeft Valve deze optie in de instellingen verwijderd, zodat je die optie niet meer eerst aan moet zetten voordat je Windows Steam spellen op Linux wilt spelen. Deze instelling zit vooralsnog alleen in de Beta versie van Steam, maar te verwachten is dat deze instelling over een tijdje ook naar de 'normale' Steam versie komt.

[Finraziel]

En als ik het goed begrijp is dit dus van belang voor mensen die 'gewoon' Linux draaien met Steam en niet zo zeer voor mensen met een Steam Deck. Daar heb ik zo'n setting in ieder geval nooit om hoeven zetten. Dat maakt het ook wat verwarrend denk ik want veel mensen zullen bij Steam en Linux aan de Steam Deck denken.

[SirLenncelot]

Proton staat ook aan op steamdeck.

[Finraziel]

Ja, natuurlijk... Maar mijn punt is dus juist dat je het op de steam deck nooit aan hebt hoeven zetten, ook niet voor niet ondersteunde games zoals dat hierboven beschreven wordt. Het enige waar je soms iets moest doen is bij games die een Linux versie hebben kon het handig zijn om juist handmatig de Windows versie met proton te selecteren omdat dat beter werkt, of soms een andere proton versie selecteren. Maar aanzetten dat proton überhaupt gebruikt moet worden is nooit nodig geweest op de steam deck. Dus voor een steam deck gebruiker zegt dit artikel helemaal niks.

[Sandor_Clegane]

Ook SteamDeck, zelfde met Bazzite. En ja, je moet het volgens mij ook hier op aanzetten dat elk spel in ieder geval geprobeerd wordt, ook al is er geen verificatie voor de SteamDeck.

Speel nu de laatste spellen gewoon op Bazzite, day one. Heerlijk, geen geneuzel meer met Windows.

Ik speel geen multiplayer meer en doe gewoon 1080p op een 4K OLED via een 7800XT. Goeie framerates en gamescope zonder geintjes met HDR.

[Finraziel]

Ik heb het echt nooit aan hoeven zetten hoor, en heb zeker wel spellen geprobeerd die op unsupported of nog niet getest stonden.

[Sandor_Clegane]

Volgens mij het is: "Enable steamplay for all other titles". En die staat onder compatability.

[xoniq]

ls je een Steam spel koopt, heb je toegang tot dit spel op elk OS dat je wilt.

Je hoeft het spel niet opnieuw te kopen, het werkt op ongeacht welk OS je ook speelt. (dat ondersteund wordt door Valve).

macOS probeert je te bellen.

[Chaseream]

Voor macOS kan je gebruik maken van Game Porting Toolkit. Ondanks dat deze gericht is voor game developers kan je via tools zoals Whisky (wrapper voor de toolkit) toch veel games spelen. Ik zelf heb er al meerdere keren met success gebruik van gemaakt.

[Reactie gewijzigd door Chaseream op 18 juni 2025 17:23]

[xoniq]

Ik zou Whiskey niet meer aanraden:

Maintenance Notice
Whisky is no longer actively maintained. Apps and games may break at any time.

Ze zijn gestopt. Enige optie is die andere tool waar je ook voor moet betalen.

[PrimusIP]

Ik heb met zowel ervaring daarmee als met dat Proton verhaal onder Linux. Maar Proton is wel een ander verhaal. Dat wat macOS heeft is een hit or miss. Sommige games werken prima, anderen niet, of matig. En na een update kan het zo weer stuk zijn.

Proton onder Linux daarentegen gaat fantastisch (ik heb nog een 10 jaar oude game pc met Fedora er op). Ik ben een enthousiast Mac(book) gebruiker, maar voor games heb ik dat platform opgegeven.

[emeralda]

Ik heb het weleens geprobeerd. Bleken trainers en cheat engine tables niet te werken onder Linux.

Dat is ook een beetje het probleem met dat SteamOS: je hoeft je nooit af te vragen of iets werkt met Windows.

[Jittikmieger]

Dit geldt ook voor MacOS. Ik gebruik b.v. Aseprite voor pixel art voor mijn homebrew games. Dat programma werkt op al mijn gebruikte besturingssystemen ondanks maar 1x aankopen: Windows, Linux, MacOS.

Ook veel (indie) games hetzelfde verhaal. Ik heb ze aangeschaft voor Windows, maar ze doen het naast mijn linux bak ook mijn Macbook. Denk aan: Dying Light, Divinity Original Sin Enhanced Edition, No Man's Sky, Cult of the Lamb, Terraria, Stardew Valley, Valheim, Bioshock Remastered, Borderlands 2, Company of Heroes 2, The Elder Scrolls Online, Warthunder, World of Tanks, Metro Exodus, ...

Ik kan nog wel even doorgaan...

[xoniq]

Ja maar dat zijn de native games.

Degene boven jou ging over dat onder Linux vrijwel elke game gedraaid kan worden, wat klopt, onder Linux. Onder macOS niet behalve als je externe dure tools gebruikt en dan is het nog geen garantie en zit je met een performance penalty tegenover WIndows of Linux.

Dus ik stak iets de draak met 'elk OS' aangezien het eigenlijk puur gaat om Windows en Linux en niets meer dan dat.

[SKBotNL]

Steam Play is eigenlijk het ding wat boven Proton zit, het draait games met Proton. Voorheen stond dit niet standaard aan. Dus als je een Windows-native game op Linux probeerde te spelen die niet Steam Play-geverifieerd door Valve was (dat de game goed werkt met Proton) probeerde Steam de game native te draaien, wat betekent dat de game simpelweg niet draait (en volgens mij krijg je er zelfs geen eens visuele feedback over, dus de game crasht eigenlijk zonder enige reden voor de gemiddelde gebruiker). Nu Steam Play standaard aan staat draaien alle games standaard via Proton.

[PaulHelper]

Sorry maar dit had je toch in een snelle Google kunnen vinden. Het is volgens mij inmiddels meer dan 6 jaar oud, dus aannemen dat een tweaker het kent is niet gek.
Waarschijnlijk had je sneller het antwoord door te googlen.

[tweaker29789]

Ik moet bekennen dat ik al een tijd niet meer op native ondersteuning voor linux let. Ik forceer al standaard Proton Experimental als ik een spel installeer.

[GertMenkel]

In mijn ervaring zijn er maar weinig games waar de native Linux-versie beter werkt. Ontwikkelaars lijken er met de pet naar te gooien als het op Linux aankomt, en Linux heeft natuurlijk door gebrek aan stabiele API's last van constante compatibiliteitsproblemen van zichzelf. Proton neemt al die onzin voor je weg. Het enige nadeel is dat anticheat + Proton nog wel eens mis gaat.

[johnbetonschaar]

Ontwikkelaars lijken er met de pet naar te gooien als het op Linux aankomt

Dat is 1 manier om er naar te kijken. Een andere manier om er naar te kijken is dat als ontwikkelaar praktisch geen enkel voordeel meer heeft om een native versie te ontwikkelen. Niet in ontwikkeltijd, niet of nauwelijks in performance, niet in compatibility, etc. Heel misschien in feature set omdat Proton soms enige tijd achter loopt op nieuwe features zoals raytracing of upscaling/framegen. Waarom zou je als ontwikkelaar weet ik veel hoeveel honderden dev uren in een Linux native port stoppen als a) het percentage mensen dat de game onder Linux gaat draaien al heel erg klein is, en b) het veel en veel eenvoudiger is om gewoon op Windows te ontwikkelen en dan hooguit achteraf even checken of Proton je game probleemloos draait en mogelijk wat kleine wijzigingen te maken als dat niet zo is.

9 van de 10 games draaien sowieso tegenwoordig bovenop een van de grote engines, en hebben weinig tot niks meer met de DirectX of Win32 laag eronder meer te maken. De vraag is wat het dan eigenlijk nog uitmaakt dat daar nog een laag middleware tussen zit die doet alsof het Windows is maar achter de schermen Vulkan en andere Linux API's gebruikt. Ik heb nooit mensen horen klagen dat een game die bovenop SDL2 draait niet 'native' is omdat de game voor alle graphics en input handling SDL2 API's gebruikt in plaats van rechstraaks naar een framebuffer schrijven en /dev/input uit te lezen (om maar een voorbeeld te noemen)

[Cilph]

Linux heeft natuurlijk door gebrek aan stabiele API's

Linux is echter zo stabiel dat Linus compleet neurotisch wordt als iemand er ook maar aan denkt om userland backwards compatibility te breken. Maar dat is de kernel zelf dan.

[Halfscherp]

Je zit er compleet naast. De kernel mag niet zomaar breaking changes richting userland maken maar in userland zelf zijn er constant breaking changes. Gnome breekt de compatibiliteit van extensies zo'n beetje met elke major version

[Hydranet]

Gnome breekt de compatibiliteit van extensies zo'n beetje met elke major version

Gnome zorgt er express voor dat extensies qua versie nummers bijgewerkt moeten worden zodat de ontwikkelaars van die extensies ook de de tijd nemen om hun extensies bij te werken voor het geval dat er veranderingen zijn binnen Gnome waar die extensies niet mee om kunnen gaan wat voor problemen zou kunnen zorgen binnen Gnome zelf

Dus bij nieuwe versie van Gnome waar de niet de juiste versie van Gnome in de extensie staan worden deze extensies uitgezet qua om te voorkomen dat een extensie een onstabiele Gnome shell zou veroorzaken, in vele gevallen is het gewoon een kwestie van een bestand bij werken van de extensie en daar de nieuwe Gnome versie aan toe voegen en soms moeten er nog meer dingen aangepast worden aan de extensie.

https://gjs.guide/extensi...updates-and-breakage.html
YouTube: How Gnome Extensions get updated | no they don't break |

[Mortov Molotov]

Is de reden waarom ik naar kde ben overgestapt

[GertMenkel]

Kernel naar userland wel (en dat is natuurlijk ook technisch gezien wat Linux is), maar userland-applicaties zoals het grootste deel van de graphics-stack, bibliotheken voor het parsen van JSON/XML, voor het doen van web-verzoeken, enzovoorts, die wijzigen allemaal continu.

Op Windows heb je API's voor alles van het lezen van XML tot het opzetten van telefoongesprekken, en die API's zijn over het algemeen jarenlang stabiel. Bij Linux moet je met honderden verschillende versies werken. De beste oplossing nog is om alle systeembibliotheken gewoon nog een keer mee te leveren, op een versie die je zelf beheert, maar dan moet je nog steeds dingen als glibc in de gaten houden, en ben je nog afhankelijk van hoe de GPU-driver zich die dag voelt.

Al dat gedoe heeft ervoor gezorgd dat talen als Go en Rust over het algemeen de voorkeur geven aan alles statisch compileren en inbakken in binaries. Je kunt daar ook wel .so's gebruiken, maar over het algemeen wordt de meeste code meegecompileerd tenzij het in een andere taal geschreven is. Dat doen die talen op Windows vaak ook, alhoewel je daar een stuk kleinere programma's uit kunt halen als je voor je Windows-build de native API's direct aanspreekt in plaats van dependencies binnen te halen.

[MaartenBW]

Factorio.

Hier vind je een goed blog post hoeveel (extra) moeite het kost om een goede native Linux te ondersteunen.
https://factorio.com/blog/post/fff-408

Dus buiten factorio, is Proton meestal the way to go.

[Hydranet]

Dat is mij ook opgevallen met een paar spellen die Linux natives hebben, een daarvan die ik mijn kan herinneren is Borlderlands 2, de Linux versie daarvan loopt vele malen versie achter de Windows versie of die heeft al lang geen update meer gehad.

Fijn dat Steam dat nu standaard zo instelt, scheelt weer dat ik zelf voor die paar spellen dat met de hand moet aanpassen.

[Reactie gewijzigd door Hydranet op 18 juni 2025 16:55]

[Wouterie]

Same! Native Linux werkt vaak niet of onvoldoende.

[Soldaatje]

En van Experimental kan je nog een Bleeding Edge installeren, die had ik in het begin nodig voor Indiana Jones.
Waar ik wel eens tegenaan gelopen ben is als ik te veel wissel van verschillende proton-versies de game dit als een nieuwe installatie ziet, dus toen kreeg ik een tijdelijke ban om te spelen, dat was AC Odyssey van Ubisoft.

[Olympus user]

Misschien voor veel mensen verwarrend dat de ene Proton de andere niet is.

[GertMenkel]

Welke Proton's bedoel je? Steam/Valve heeft toch maar één Proton.

Je hebt natuurlijk ook nog Proton (mail/VPN), Proton (het autoproject van Maleisië, PROTON (Midden Nederland B.V.), Proton (de Belgische variant van de Chipknip), Proton (de Russische raket), en natuurlijk het subatomische deeltje, maar geen van allen lijkt me voor Steam relevant

[DeTeraarist]

Nouja, die laatste is wel een beetje essentieel

[Fragger123]

Je hebt naast Proton van Valve bijvoorbeeld ook nog Proton van Glorious Eggroll die dan weer extra support toevoegd voor bepaalde games > https://github.com/GloriousEggroll/proton-ge-custom

[MacPoedel]

Dat is Proton-GE, die builds zijn niet officieel en moet je zelf installeren (behalve met protonup-qt), dus als die op je systeem staan, heb je ze toch zelf geïnstalleerd. Als je Steam op Linux installeert, heb je alleen Proton, Proton Hotfix en Proton Experimental.

Protondb.com kan wel wat verwarrend zijn als men in compatibiliteitsrapporten het over onofficiële Proton versies heeft die je mogelijk niet geïnstalleerd hebt.

[cyclone]

Euh ja, ik dacht al wordt hier misschien ProtonVPN mee bedoeld oid ?

[watercoolertje]

Ik snap de verwarring wel maar waarom zou er dan niet gewoon ProtonVPN staan?

Of misschien de hele suite van Proton dan, want anders hebben alle producten/diensten gewoon een naam en dat is niet Proton (dat is het bedrijf). Maar ProtonMetEenToevoeging.

[Reactie gewijzigd door watercoolertje op 18 juni 2025 16:17]

[daily.data.inj]

Je ziet het al gebeuren als je op de tag Proton klikt onderaan het artikel.

[Master Chieftec]

Ik moest gelijk denken aan Proton Cake Mix uit Afrika. Nee, ik snap de verwarring.

[uiltje]

Proton Cake Mix. Gegarandeerd met 50% protons.

[Zwarte_os]

Ik ben onlangs voor mijn nieuwe systeem overgestapt van Windows naar Fedora en ik moet eerlijk bekennen dat ik dit ook verwarrend vond in Steam. Ik wilde bv Cyberpunk installeren en kwam toen op een disabled install button uit. Blijkt dat je dan eerst in je compatibility moet kijken naar proton terwijl mijn verwachting was dat Steam automatisch Proton zou gebruiken voor ondersteunde games.

Al snel een optie gevonden dat steam play gewoon altijd aanstaat waar mogelijk maar ik vond het enigzins verassend waarom het niet standaard aan zou staan bij games die geen officiele Linux installer hebben.

[Reactie gewijzigd door Zwarte_os op 18 juni 2025 15:54]

[HollowGamer]

Tip, check: https://www.protondb.com/explore

Deze site helpt je ook in het algemeen als je op Linux een game wilt spelen, vaak ook zonder meteen Steam, maar bijvoorbeeld via een andere launcher.

[Zwarte_os]

Super, dankjewel!

[Terr-E]

Het is een stukje verwachtingsmanagement vanuit Valve;
Zeker in het begin van SteamPlay / Proton werkte lang niet alle Windows games met Proton, dus dan kun je het beste SteamPlay default uit hebben staan en dat avontuurlijke gebruikers het zelf aan kunnen zetten en "positief verrast" kunnen worden als een niet-ondersteunde of niet-geteste game stiekem wel werkt met Proton. Als het default aanstaat moet je als Valve zijnde genoeg vertrouwen hebben dat het op de grote meerderheid van de games werkt. Want anders zadel je een hoop gebruikers die voor het eerst Linux / een SteamDeck proberen op met fouten en niet startende games en dat kan tot meer reputatieschade leiden dan wanneer SteamPlay standaard uit staat.
Dat ze dus nu eindelijk na bijna 7 jaar het default aan zetten geeft wel wat vertrouwen.

[Muntan]

Ik had hetzelfde probleem recent!

[jumbos7]

In het verleden lette ik op of een game native was of via proton werkte en moest ik op onderzoek uit om te bekijken of ik het aan de praat kon krijgen onder Linux maar tegenwoordig kom ik eigenlijk geen game tegen die niet out of the box werkt onder Linux dus bij mij staat Steamplay voor Windows-only games standaard aan.

Het enige waar het nog problemen geeft is denk ik bepaalde online multiplayer games die vertrouwen op (root-level) anti-cheat, maar dat speel ik uit principe niet en het gaat sowieso zelden om games die ik interessant vind.

[Reactie gewijzigd door jumbos7 op 19 juni 2025 06:27]

[Insomnia1988]

Oh dat gaan we straks proberen, kijken of Bonesaw nu wel werkt

[Mark_88]

Nice, grote stap voor de toegankelijkheid van Linux gaming! Als we iets vinden op die paar anticheatgames dan hebben we het goed.

[Rumblebumble]

Ik zou graag overstappen op Linux maar Battlefield houdt het tegen😥

[Mark_88]

PUBG voor mij. Vriendengroep speelt het. Vervelende is dat het een kip-eiverhaal is tenzij er een of andere tiebreaker komt.

[vDorst]

Kan zijn dat linux beveiliging SELinux tegenhoud dat Wine(Proton) kan werken.
Dit merkt je dat je geen niet-linux games gestart krijgt.

Ik liep hier tegen aan met OpenSUSE MicroOS.
Zie https://security.opensuse.org/2025/06/06/selinux-gaming.html, punt

3) The problem with emulating Windows games

[HollowGamer]

Ik moet je helaas zeggen dat ik geen positieve ervaringen heb met OpenSUSE. Het is niet SELinux (of whatever), zij hebben zelf van alles op slot gezet en geven je niet de juiste tools (en docs) om het op te lossen. Dit heel artikel somt echt OpenSUSE voor mij op.. een random artikel, met een oplossing dat over een aantal maanden niet meer werkt.

Als je iets als MicroOS wilt gebruiken, dan raad ik Fedora Silverblue aan. Je gamed dan via Flatpaks en launchers. Anders gewoon Fedora, Cachy of Debian Unstable (voor laatste kernel + mesa).

[Caelorum]

Bazzite als je puur wilt gamen.

[HollowGamer]

Bazzite is erg bloated, en ik vind niet beter vergeleken bij andere. Ik heb ook gemerkt dat er veel bugs in zitten, die nogal genegeerd worden op hun GitHub.

[vDorst]

Opzicht ben ik wel tevreden.
Ik wilde "atomic" achtig OS proberen.
Tevens heeft OpenSUSE heeft goede secure boot super dat ook blijft werken na een update.
Zo ver hebben geen echte problemen gehad.
Ook met MicroOS wordt alles via Flatpak geïnstalleerd en andere dingen installeer in via de package manager zodat ze beschikbaar zijn bij de volgende reboot.

[HollowGamer]

Mijn Linux hart klopt! Ik ben alleen bang voor aankomende MS handhelds (of wie die ook maakt).

[xoniq]

De eerstvolgende is gewoon een iets aangepaste ROG Ally. En zelfs toekomstige Windows handhelds van Microsoft zullen vast gewoon Linux kunnen draaien.

Maar als Microsoft Windows echt dusdanig weer te fixen dat het gewoon 'game only' kan draaien met de minimale nodige processen is dat al een win. Ik zal Windows nodig blijven hebben voor VR.

[HollowGamer]

Dat is ook mijn probleem ermee. De geruchten zijn dat MS bezig is met een OS dat speciaal gemaakt is voor handhelds (al ping pongen de geruchten wat op en neer).

Stel dat MS nu komt met een OS dat prima werkt, dan is Proton veel minder interessant. Mijn reden voor Proton is niet perse gaming, maar juist dat mensen loskomen van Microsoft die al jarenlang alles domineert met hun APIs en Windows model. Voor mij hoeft MS niet weg (liever wel, maar blijf realistisch), ik heb liever een gezonde concurrentie van Linux/Apple.

[SilentDecode]

Tip voor de mensen op Linux met Proton geïnstalleerd en het werkt nog steeds niet helemaal lekker:
ProtonGE. Dit is een zelfbouwproject van iemand anders, maar met wat meer resources erin van Windows.

Voorbeeldje:
Space Engineers (1) draait 'meh' met Proton (meerdere versies) en crashed best wel vaak. Sindsdat ik ProtonGE heb geïnstalleerd, heb ik geen enkele crash gehad en draait de game ook een héél stuk beter en sneller (ik ben geen FPS jager, dus op mijn redelijk normale hardware, draait het alsnog wel goed).

Linkie naar Github:
https://github.com/GloriousEggroll/proton-ge-custom

[Reactie gewijzigd door SilentDecode op 18 juni 2025 21:56]

[HollowGamer]

Het grappige is dat soms GE beter werkt, maar bij oudere games weer een vorige/stable Proton versie.

GE heeft zeker nice features, maar check even goed of het correct werkt met de game die je wilt spelen. Ik raad dus aan deze naast de huidige te zetten, en het goed te testen. Dacht namelijk ook dat GE bepaalde patches heeft, die online multiplayer games niet altijd leuk vinden.

[SilentDecode]

Oh, good to know.

Heel eerlijk speel ik maar 2 of 3 games, waarvan 2 native op Linux draaien zonder tussenkomst van Proton. Dus eigenlijk gebruik ik het alleen voor Space Engineers (1).