Valve is running TWO very different ARM policies at ONCE. On its OWN HARDWARE, the Steam Frame, the company is ACTIVELY tuning the translation layer that lets Windows games run on a Snapdragon chip. On everyone else’s ARM Linux machines, its PUBLIC BUG TRACKER now says the Steam client is simply NOT SUPPORTED.
A Narrow Bug Report, Closed on Scope
On October 4 at 18:48 UTC, a user filed issue #13689 on Valve’s steam-for-linux tracker. The report concerned Remote Play on the NATIVE ARM64 Linux Steam client, build 1790904859 from the steam_client_steamdeck_publicbeta_linuxarm64 package, running on an AYN Odin 3 handheld with a Qualcomm SM8750 chip, the Fedora 44-based Armada distribution and Linux kernel 7.2.6.
The complaint was NARROW and WELL DOCUMENTED. The handheld’s V4L2 HARDWARE DECODER lists FOUR compressed formats in order: H.264, HEVC, VP9 and AV1. An strace log attached to the report shows the Steam client STOPS probing once it finds H.264 or HEVC and NEVER REACHES the AV1 entry, so the Remote Play host is NEVER TOLD that AV1 is available. The reporter noted that steamclient.so ALREADY contains AV1 streaming references and asked Valve to add the MISSING PROBE.
About three hours later, at 21:55 UTC, the kisak-valve account CLOSED THE ISSUE with ONE line: “Steam for Linux is not currently supported on ARM based hardware (#4061).” The reply did not say whether the probing behavior is a BUG, or whether AV1 will EVER BE OFFERED to ARM64 clients.
The issue it points to, #4061, is titled “can’t run on ARM architecture systems” and was opened on October 12, 2015. As MIXED reported, it carries the Feature Request label and more than 100 comments, and it remains OPEN almost ELEVEN years later with NO PUBLISHED ROADMAP or timetable.
Meanwhile, on the Frame
The contrast is the Steam Frame itself. Valve’s Steam Frame page describes the headset as a PC running SteamOS on a Snapdragon 8 Series processor, and MIXED notes that its specifications list a 4nm Snapdragon 8 Gen 3 with an ARM64 ARCHITECTURE. According to Digital Citizen, Valve’s developer documentation tells studios that shipping to the headset “probably means running Windows x86 via Proton and FEX.”
That is the path Valve just CHANGED. Valve developer Pierre-Loup Griffais said on September 27 that the FEX CODE CACHE “is now enabled on Proton Experimental (ARM), and should exhibit improved 1%-low frame times, especially over subsequent runs,” per the same report. FEX TRANSLATES x86 code into ARM64 instructions at RUNTIME. Caching that translated code TO DISK is meant to cut the HITCHES that appear when a game reaches code it has not seen before, which is why the promise is about 1% lows rather than AVERAGE frame rate.
Two CAVEATS apply. Proton Experimental is OPT-IN and has to be SELECTED PER GAME, and Griffais gave NO benchmark, no game list and no before-and-after numbers. Digital Citizen also notes that the FEX project describes its cache as having no SIZE LIMIT and no way to remove STALE ENTRIES.
Where Valve Draws the Line
None of this is a CONTRADICTION on paper. The ARM64 Steam client inside the Frame ships as part of STEAMOS, on hardware Valve BUILDS AND CONTROLS. What #13689 shows is where the line sits: ARM is a FIRST-CLASS target when it is Valve’s own headset, and an UNSUPPORTED platform when it is a THIRD-PARTY HANDHELD running a COMMUNITY DISTRIBUTION.
That line will GET TESTED more often as Snapdragon HANDHELDS pick up Valve’s ARM64 client builds and file reports like this one. For now, the OFFICIAL ANSWER is a pointer to an issue from 2015.
Valve has not PUBLICLY SAID whether the Frame’s own client offers AV1 for Remote Play, and nothing in the closed report involves a Steam Frame. The AV1 probing question itself remains UNANSWERED.