Taming the Steam arm64 client (on pmOS)

The appearance of an arm64 Steam client signals Valve’s long-term intent to support ARM devices, but the current build is a raw port without the tooling needed for seamless operation. Engineers attempting to use it will find that the client defaults to x86_64 runtimes, ignoring ARM-native Proton or SteamLinuxRuntime unless manually configured. This creates a mismatch between the client’s architecture and the games it tries to run, requiring emulation layers like FEX to bridge the gap. The lack of an official release means no guarantees on compatibility or performance, leaving adopters to debug runtime containers and environment variables themselves.

Valve’s existing ARM-related work, like SteamLinuxRuntime 4.0 and Proton for arm64, hints at a future where the client automatically selects emulation or native runtimes. However, the current build lacks the `toolmanifest.vdf` and `emulator.json` files that would enable this. Engineers can manually add these files or compile Proton for ARM, but this is a stopgap. The client also expects specific host libraries, pushing users toward containerized solutions like SteamRT4. These workarounds add complexity, as the client’s containerization can break global emulation setups like binfmt, forcing engineers to patch entry-point scripts or environment variables to keep things running.

The practical consequence is that ARM-based Linux devices can now technically run Steam, but only with significant manual intervention. The client’s behavior suggests it was built automatically without ARM-specific optimizations, making it behave like an x86_64 client in an ARM environment. For engineers, this means extra effort to validate game compatibility, runtime stability, and performance. The reliance on community scripts and undocumented container tweaks also means that updates from Valve could break existing setups. Until Valve officially supports ARM, this remains a proof-of-concept with limited real-world utility for production use.