Taming the Steam arm64 client (on pmOS) - Drakulix' Blog
If you have seen my previous endeavour trying to compile Proton for arm64, you are probably not very surprised, that I was excited, when suddenly a Steam Client for arm64 started to show up on the internet. People were quick to get it running on various systems, thanks to some community scripts to download and setup the executables.<br>And all of this was expected to happen at some point after Valve officially announced the Steam Frame - a Snapdragon 8 Gen 3 device running SteamOS. However trying the client I quickly noticed, that this isn't the Steam Frame client version and that it behaved weirdly...<br>Valve is open-sourcing a lot of code, that isn't specifically the steam client itself. This includes most notable Proton and the SteamLinuxRuntime. Both contained references to arm64 for quite some time, enough to puzzle together how it is supposed to work.<br>For one Valve now builds the SteamLinuxRuntime 4.0 for arm64, as well as Proton for arm64. However this client will by default not attempt to download either of them. If you download the Proton runtime, you might also notice, that it is missing the toolmanifest.vdf, that would make it show up in the Steam client.<br>The steam runtime also contains new references to a emulator.json manifest, which the public FEX source repository also contains. This tells us, that Steam is likely going to pick an emulator suitable for running runtimes compiled for foreign architectures (x86_64 on arm64) automatically and inject it into it's pressure-vessel container. The pressure-vessel/proton scripts also suggest, that Steam will allow users to set some FEX config parameters.<br>Additionally we find references to a `graphics-provider.json`, which is providing the graphics drivers compiled for a different architecture, as running amd64 binaries on arm64 likely need mesa compiled for amd64 as well, which no arm64 distribution will ship by default.<br>The somewhat unofficial or at least unannounced Steam Client for arm64 seems to handle none of this. It seems to be totally oblivious to being compiled for arm64 and will just attempt to launch a x86_64 runtime by default. Even if you have setup a global binfmt-emulator for x86_64 binaries chances are high, that the container steam spawns will break that setup.<br>And there is more that suggest that this is simply an automated build of steam for another architecture without any of the changes that will make the Steam Frame actually work. The script on the internet will download Steam from the publicbeta channel as there doesn't seem to be a stable client yet. But you can totally download the arm-build for the steamdeck_stable branch and you'll get an arm64-client that has all the subtle changes you would get running Steam on a Steam Deck.<br>what the heck ?<br>Oh, behave...<br>The tweet, uhm toot(?), no bluesky isn't fedi, well.. "post" you saw previously running on the Nintendo Switch has the additional challenge, that you cannot run FEX on that hardware at this point in time. So is it all useless? Well no, the Steam Client finally contains the steamclient.so compiled for arm64, we were previously missing trying to run Proton on arm64. So people quickly either compiled Proton for ARM themselves - Valve has public build instructions, which makes this very easy - or simply downloaded the depot from Steam and wrote their own toolmanifest.vdf file.<br>And that works, but wouldn't it be nice, if we could simply run any Proton version including x86_64 ones (like will presumably be possible on the Steam Frame) with our arm64 client? Or - heck - if the game has a native linux version, wouldn't we want to simply run that through FEX?<br>At this point I need to talk a bit about how exactly we are running the Steam Client in the first place. People who payed attention to Valves Steam updates might have seen the news about SteamRT3C. The public x86_64 beta client, that runs inside a steam-runtime container itself. (Yes Steam has so far still been a 32-bit binary on Linux.) Since the arm64 client is very particular about the libraries it expects on the host system, people were quickly adopting the same approach the beta client takes and used the SteamRT4 runtime for arm64 to run the client.<br>This means Steam runs in a container runtime we can mess with and the entry point to every steam runtime invocation is a little shell script called _v2-entry-point. So... what if we simply move /bin/sh in the container to /bin/sh.real and add a little script like this?
#!/bin/sh.real
if [[ "$1" == */_v2-entry-point ]]; then<br>folder=$(dirname $1)<br>header=$(readelf -h $folder/pressure-vessel/bin/pressure-vessel-wrap | grep Machine)
if [[ $header == *"X86-64"* ]]; then<br>export PRESSURE_VESSEL_BWRAP=/usr/bin/fexwrap<br>exec "$HOME/.local/share/Steam/steamrtarm64/pv-runtime/steam-runtime-steamrt/pressure-vessel/bin/steam-runtime-launch-client" \<br>--pass-env-matching=STEAM* \<br>--pass-env-matching=Steam* \<br>--pass-env-matching=SDL*...