Support us on Patreon
PayPalValve have been cooking! A new Steam Client Beta is available with something quite special for Linux gamers, as Valve work to continue improving Linux gaming.
This is some pretty impressive sounding stuff that Valve have done here, and should eventually (when stable) ensure we get a great Steam experience across many different Linux distributions - and finally with 64bit too that people have been asking for a long time. It's called the "Linux SteamRT3 Beta" and Valve explained it in the patch notes as:
The Steam for Linux client can now be run inside a Steam Runtime container. This will help the Steam client provide a more consistent experience across multiple distributions. This is the same technology we use for Steam games.
The SteamRT3 beta client is distributed alongside the regular beta client. You can opt-in to the beta client via the 'Use experimental SteamRT3 Steam Client' toggle in Settings->Interface.
The SteamRT3 beta client has been updated to 64 bits.
Please report issues specific to the SteamRT3 beta in the Beta Forums or the steam-for-linux issue tracker.
Plus some other useful changes came along for the ride:
Big Picture Mode
Moved Steam chat into the quick access menu, making it easier to access while in-game.
Introduced new quick chat feature for Steam Deck and Big Picture Mode
When in a chat, press and hold the view button to bring up quick chat options.
Move thumbstick and release view button to send a quick chat.
Quick chats can be edited in Settings > Keyboard
Remote Play
Enabled streaming while Remote Desktop is active on Windows
Added more flexible options to the Advanced Host Options for selecting primary display, resolution, refresh rate, etc. while streaming from a Windows computer. This will also allow setting whether HDR is enabled while streaming.
Added support for the SudoVDA virtual display driver on Windows. If you have the SudoVDA driver installed and select this as your primary display in the Advanced Host Options, Steam will automatically create a virtual display to match the client display settings.
Source: Valve
Article taken from GamingOnLinux.com.
See more from me
You can also find comments for this article on social media: 
fenglengshun 11 hours ago
Hopefully we can lay down the multilib requirement soon.
Liam Dawe 11 hours ago
Quoting: scaineThis sounds absolutely incredible. If they've genuinely created intra-distro consistency, that's a HUGE win for Linux as a gaming platform. Now, Valve, what are you going to do about that shitty kernel-level-anticheat problem?Thinking on this somewhat. Perhaps this could be a way towards it. Have everyone run Steam inside a container, Valve can verify nothing in the container has changed. Perhaps this could help towards ensuring a secure environment?
Quoting: tgurrYou probably still need to install 32bit graphics driver on your host for as long as you want to play 32bit native games. Maybe they could add an option like "Always run the windows version of the game (through Proton) for games which only have a 32bit native version" to be able to really get rid of the need to have to have 32bit libs installed. As (old) 32bit native games won't magically go away any time soon - if ever.Well, it sounds like it's time for a new API compatibility layer, then ;)
Couldn't a shim work? A 32-bit library that calls into a 64-bit driver. Or would it require additional IPC mechanisms & overhead?
Quoting: Liam DaweInteresting thought. As it is, it's not enough, as external programs can still poke at he memory and code. But add to that encrypted memory and secure attestation (SGX enclave verifying the hash of the code, memory decryption keys only available inside the enclave), and it could be pretty bullet proof, no need for a kernel driver, "just" a recent CPU with recent microcode (and hopefully you will not be locked out of your game just because a security bug has been found for your CPU model).Quoting: scaineThis sounds absolutely incredible. If they've genuinely created intra-distro consistency, that's a HUGE win for Linux as a gaming platform. Now, Valve, what are you going to do about that shitty kernel-level-anticheat problem?Thinking on this somewhat. Perhaps this could be a way towards it. Have everyone run Steam inside a container, Valve can verify nothing in the container has changed. Perhaps this could help towards ensuring a secure environment?
I don't like this idea in general (imagine your bank wanting you to use an approved web browser on an approved OS), but I could see it working for anti-cheat in games. I wonder what the perf impact would be. And of course, it would require cooperation from anti-cheat providers.
bwrap: execvp /usr/lib/pressure-vessel/from-host/libexec/steam-runtime-tools-0/pv-adverb: Too many levels of symbolic linksits the application tray that is broken.
Last edited by Naib on 20 Mar 2026 at 2:18 pm UTC
Arehandoro 5 hours ago
I don't think I'll move away from Flatpak because it deals with litter inside the home dir (forcing everything under a ~/.var/app/com.valvesoftware.Steam prefix; some games otherwise write saves and config files in random places), and Steam presumably won't try to prevent that when existing saves have to remain visible.
If it at least makes Steam easier to contain (with the embedded chromium properly sandboxed), it's good for security.
How to setup OpenMW for modern Morrowind on Linux / SteamOS and Steam Deck
How to install Hollow Knight: Silksong mods on Linux, SteamOS and Steam Deck