Valve published native ARM64 Steam in roughly April
2026.

 

The Steam Frame launched September 14th.

 

I built a client that installs the Steam Frame ARM64 Steam client on my RK3588 board.

 

• It launches Big Picture mode and firstboot makes you get past the VR Joystick screen.
• You can run it as desktop mode thereafter.
• The CLIENT and GAME run natively, naturally on ARM*. No box64 etc workarounds.
• Why not try to share if I can?

*panvk and vulkan are required.

This Contains:

1. Vulkan feature layer for Direct3D translation layer
2. Remote Play decode settings for GPU with no Vulkan Video,
3. Private Mesa GLX copy for multi threaded OpenGL,
4. Controller access rules for 243 pads
5. Memory map limit for Proton

 

Only tested on my H96 Max V58, RK3588 with Mali-G610 GPU. Armbian with an open grapics stack:

 

Tested device answers: `panthor` loaded, renderer `Mali-G610 MC4 (Panfrost)`, Vulkandriver `panvk`, `ubuntu`, `4096`. 

 

**Rock 5B, Orange Pi 5 and other RK3588 boards on Armbian.** Same Mali-G610 as tested device.

Pick Ubuntu based image.

 

`current` and `edge` kernel branches are mainline and carry Panthor<--Should be fine.

 

`vendor` branch:

check `lsmod`:  If `vulkaninfo` lists no `panvk` device, stock Mesa predates PanVK in use here :-( , `kisak-mesa` PPA is where  the test device sources from.

 

 

I may be under-educated but this might be able to run on a snapdragon chip or other ARM chip in a laptop or a mac. I have no idea. I do not own those things.

I reached out to the Armbian Forums first since that is how this came about in the first place 

 

I NEED FEEDBACK!!

Get it Here:

https://github.com/Scrumpper/Steam-ARM/releases

 

This project is not affiliated with, endorsed by or sponsored by Valve Corporation. Steam,
Proton, Steam Deck and Steam Frame are trademarks of Valve Corporation.

Thanks for releasing this. It's works fine on the Radxa Dragon Q6A Snapdragon QCS6490 SBC. I assume it won't work on ARM Mac, unless you added something like a micro VM, to enable running 4k page size apps in a 16k page size environment.

 

My PS4 controller works.

 

I skipped installing glx-lax and vk-spoof. I assume vk-spoof is for the RK3588 (and perhaps other SoCs that don't support everything needed for Vulkan).

 

Steam overlay doesn't seem to work, and running with Mangohud doesn't seem to work either. Mangohud did work when I tested a different setup of Steam ARM Linux.

 

Here is the result of the benchmark of Tomb Raider GOTY (1080p Normal quality).

 

Min FPS: 18.9

Max FPS: 31.9

Average FPS: 26.7

Did a test on the Radxa Rock 5B RK3588.

Armbian 26.8 has Mesa 26.0 and I had issues to get games working with Vulkan. Upgraded to 26.2.3 with the Persson PPA, and Tomb Raider GOTY is also working on the RK3588!

https://launchpad.net/~ernstp/+archive/ubuntu/mesarc

 

Half-Life needs OpenGL 3.2, so I started the Steam client like this: PAN_MESA_DEBUG=gl3 steam-arm

 

Mangohud wasn't working for me, but you can use Gallium HUD for OpenGL and Vulkan Overlay.

 

You can start games in Steam like this:

GALLIUM_HUD=simple,fps %COMMAND%

VK_INSTANCE_LAYERS=VK_LAYER_MESA_overlay %COMMAND%

 

Tomb Raider GOTY Benchmark

Min FPS: 15.6

Max FPS: 22.9

Average FPS: 19.7

 

You can see my video here: 

 

@LivingLinux WOW!
Snapdragon board! Did not expect that!
 Yes, vk-spoof reports device features DXVK requires which PanVK on Mali does not expose.

Turnip on Adreno exposes them. :-)

 glx-lax: not tied any SoC. It covers OpenGL titles that bind one context from several threads, which fail with a Mesa BadAccess error.
 Skip it unless a GL title fails that way.

Thank you SO MUCH for this feedback and benchmarking. it helps a lot.

I'm actually working through some of the stuff from your 1st and 2nd test.

 

Also, pagefile sizes are gonna (hopefully) be able to auto-detect in the next version of the installer. (i actually do not own anything ARM with 16k, 64k, etc, etc)

 

Got the overlay thing 80% nailed down. The different game engines make it kinda wonky.

Mangohud, too.

 

Good things soon :-)

BTW the new version(s) installers are reproducible .sh scripts 

@Scrumpper I tried the new installer on a Raspberry Pi  5 running Ubuntu. The script gets busy installing a lot of things.

But when I start steam-arm, I get errors.

 

livinglinux@Pi5:~$ steam-arm
/usr/local/bin/steam-arm: 43: cannot create /home/livinglinux/.local/share/steam-arm/.local/share/Steam/steamrtarm64/steam-launch-wrapper: Directory nonexistent
chmod: cannot access '/home/livinglinux/.local/share/steam-arm/.local/share/Steam/steamrtarm64/steam-launch-wrapper': No such file or directory
/usr/local/bin/steam-arm: 59: cannot create /home/livinglinux/.local/share/steam-arm/.local/share/Steam/steamrtarm64/streaming_client: Directory nonexistent
chmod: cannot access '/home/livinglinux/.local/share/steam-arm/.local/share/Steam/steamrtarm64/streaming_client': No such file or directory
/usr/local/bin/steam-arm: 215: cd: can't cd to /home/livinglinux/.local/share/steam-arm/.local/share/Steam/steamrtarm64

 

thank you for your support and feedback!

 

Steam ARM 1.2 found no client folder in your home folder:

launcher looks in home folder of account that runs it; setup installs client for account `GAMEUSER` (default: first account, uid 1000).

 

Two likely causes:

 

1. Setup installed for another account.

 

Check:

   id -un; id -u
   grep GAMEUSER /etc/steam-arm/steam-arm.conf
   If GAMEUSER is not your account name, set it up for your account:

   sudo env GAMEUSER=livinglinux bash steam-arm-install.sh --keep

 

 

2. Setup stopped before client step.

 

On Pi 5 with 16K page kernel, setup switches config.txt to 4K kernel
rebooting and re-running setup reverts it.

 

Check:

   getconf PAGESIZE
   ls ~/.local/share/steam-arm/.local/share/Steam

   If page size is 4096 now and that folder has no steamrtarm64;

run setup again:

   sudo bash steam-arm-install.sh --keep

 

If neither helps, please post output of commands above plus last 30 lines of setup output.

 

More, (better) things soon

v2.0 is out.

Thanks for the quick response.

 

I was not the GAMEUSER, so I installed as you suggested: 

sudo env GAMEUSER=livinglinux bash steam-arm-install.sh --keep

 

My id number is 1002, perhaps that's causing issues?

 

Ubuntu uses the 4k page size kernel, so I haven't tested switching kernels.

 

Performance is underwhelming, especially compared to the RK3588. I guess we run into the limitations of the RPi5 hardware.

 

There was one weird thing when I started using my controller in the game Half-Life. I got a popup about allowing remote interaction. On the RK3588 I got a popup about allowing access to the controller, but this seems to be the wrong popup. You can see it at around 6:50 in the video.

I'm not really motivated to continue testing with the RPi5, unless we get some better performance.

 

 

Trying to install on my Phytium D2000 (8*A72 cores) with AMD Radeon RX550.

Hardware detection works fine, but I get an error that fex-emu-armv8.2 can't be installed, but fex-emu-armv8.0 is available.

 

Thanks for testing, on both boards.

 

 

2. GPU or CPU: renderer check
SteamWorld Dig on GPU ??? would confirm forwarding to Pi's V3D driver works.

To see what eachtitle gets:
Host: `glxinfo -B` should name V3D, not llvmpipe.
- Per title, 2.0: MangoHud on x86 Linux title, launch option
  `MANGOHUD_CONFIG=gpu_name,engine_version,fps,frametime,cpu_stats,core_load mangohud %command%`.
  llvmpipe in GPU name means CPU drawing.
- Next version adds log line per game start, `renderer: GPU (v3d renderD128) ...` or
  `renderer: warning: GPU forwarding not active: rendering on CPU (llvmpipe)` with reason,
  also in hardware report (`steam-arm-config report`).

3. Half-Life at about 30 fps
Linux build asks for OpenGL 2.1 (Steam store page); Pi 5's V3D offers OpenGL 3.1, so GL
version is not blocker and no GL override applies. Checks:
- Options, Video: renderer must be OpenGL. Software renderer draws on CPU by design.
- Lower resolution: frame rate unchanged means CPU limit. Half-Life is 32-bit x86 code
  running through emulation, and its old-style OpenGL calls each cross forwarding on
  their own, so processor is likely limit on Pi 5 (unmeasured).

4. Tomb Raider GOTY
Not fixable on Pi 5 with current drivers:
- Linux build: Feral port, tested on OpenGL 4 class drivers. V3D offers OpenGL 3.1.
  Zink (OpenGL on Vulkan), which runs it on some Mali boards, reaches OpenGL 4.0 only
  with tessellation shaders, which V3DV lacks.
- Windows build: Proton draws Direct3D through DXVK, and DXVK's baseline asks for Vulkan
  features V3DV does not report (BC texture compression, cull distance, null
  descriptors, robustBufferAccess2; Direct3D 11 also multiViewport and transform
  feedback). Sources: Mesa 26.1 `v3dv_device.c`, DXVK 3.1.1 `VP_DXVK_requirements.json`.
- Untested option: Windows build also has DirectX 9 renderer. With launch option
  `PROTON_USE_WINED3D=1 %command%` and DirectX 11 turned off in its launcher, Proton draws
  through OpenGL (WineD3D) in place of Vulkan, and Direct3D 9 level may fit in OpenGL 3.1.
  Expect low frame rate on top of emulation, if it starts at all.
Titles built for Linux against OpenGL 3.1 or older are best fit on Pi 5.

5. Proton 11 ARM64 "back to default", slow starts
Steam ARM does not write compatibility tool at game start: launch handler only reads
Steam's setting, and settings menu writes it only on request (Graphics, Linux or Windows
build). To keep Proton 11 ARM64:
- Properties, Compatibility: tick forcing option, pick Proton 11 ARM64 entry. Where list
  shows both ARM64 and plain "Proton 11.0", plain one is x86 build that runs Wine itself
  through emulation: far slower.
- Steam stores choice in `config.vdf` when client exits. Exit Steam from its own menu
  once after change; client that crashes or is stopped another way can lose last change.
- Next version logs `compat: warning` when saved choice names Proton but Linux build
  started.
Slow first start of Windows title: Proton prefix creation and redistributable installers
(Visual C++, DirectX) run under emulation once per title; PhysX installer is marked done
or stopped after 60 s. Every start translates x86 code again. Later starts skip prefix
and installer steps.

6. KDE Plasma "Remote control requested: input devices"
KDE on Wayland asks before X11 programs send emulated input;

Steam does that when controller drives desktop.

Next version adds optional part `kde-input-prompt` (off by default) that does same,
saves value it replaces, and puts it back when turned off or on uninstall.

Source: https://discuss.kde.org/t/kde-linux-steam-controller-request-remote-access-dialog/30731

 

 

- Raspberry Pi OS runs labwc (Wayland); x86 titles draw through XWayland. X11 session
  (raspi-config, Advanced Options, Wayland) is worth comparing on same title.

 

 

Phytium D2000 (8x Cortex-A72, RX550):

Cortex-A72 is ARMv8.0 and lacks atomics; ARMv8.2 FEX build cannot install there; FEX's PPA offers fex-emu-armv8.0 for it instead.

Steam ARM 2.0 asks for fex-emu-armv8.2 on every CPU, which is error in your screenshot.

 

Version 2.1(upcoming) picks FEX build matching CPU (same rule as FEX's own installer).

 

Until 2.1 is out, in Steam ARM 2.0 folder run:

   sed -i 's/fex-emu-armv8.2/fex-emu-armv8.0/g' steam-arm-install.sh

then start setup again.

RX550 is detected as amd-radv: games use forwarding to system Mesa (radeonsi, RADV).

 

Raspberry Pi errors from 1.2? or 2.0?
Those errors mean Steam ARM 1.2 finds no client folder in your home: launcher looks in home of account that runs it, setup installs client for account `GAMEUSER` (default: first account, uid 1000).

 

Two likely causes:

 

1. Setup installed for another account.

 

Check:
   id -un; id -u
   grep GAMEUSER /etc/steam-arm/steam-arm.conf
   If GAMEUSER is not livinglinux, set it up for your account:
   sudo env GAMEUSER=livinglinux bash steam-arm-install.sh --keep

 

2. Setup stopped before client step.

On Pi 5 with 16K page kernel, setup switches config.txt to 4K kernel and stops with "reboot, then run setup again".

 

Check:
   getconf PAGESIZE
   ls ~/.local/share/steam-arm/.local/share/Steam
   If page size is 4096 now and that folder has no steamrtarm64, run setup again:
   sudo bash steam-arm-install.sh --keep

 

Steam ARM 2.0 handles Pi 5 page-size switch and second run on its own, so updating to 2.0 avoids case 2. 

 

 

Thank you for this insightful info! it helps TONS!
 

Edited October 3Oct 3 by Scrumpper

On 10/3/2026 at 2:45 AM, Scrumpper said:

Phytium D2000 (8x Cortex-A72, RX550):

Cortex-A72 is ARMv8.0 and lacks atomics; ARMv8.2 FEX build cannot install there; FEX's PPA offers fex-emu-armv8.0 for it instead.

Steam ARM 2.0 asks for fex-emu-armv8.2 on every CPU, which is error in your screenshot.

 

Version 2.1(upcoming) picks FEX build matching CPU (same rule as FEX's own installer).

 

Until 2.1 is out, in Steam ARM 2.0 folder run:

   sed -i 's/fex-emu-armv8.2/fex-emu-armv8.0/g' steam-arm-install.sh

Installation works when installing fex-emu-armv8.0, but starting steam-arm gives the error illegal instruction. I guess the Steam ARM Linux Client doesn't work with A72 cores.

On 10/3/2026 at 2:45 AM, Scrumpper said:

On Pi 5 with 16K page kernel, setup switches config.txt to 4K kernel and stops with "reboot, then run setup again".

Yes, this works with the latest version. But there is another problem. Raspberry Pi OS is based on Debian, and installing from a PPA works different.

You have to add the PPA to the sources.

https://en.ubunlog.com/how-to-add-ppa-repositories-to-debian-and-distributions-based-on-it/

You are correct.

Steam client builds newer than 15 April 2026 need Armv8.1 with LSE atomics, so Cortex-A53, A57 and A72 cannot run them.

FEX itself installs fine; client stops.

Steam ARM 2.1 (now released) checks for this and stops setup and checks for this.

The x86 Steam client under FEX Armv8.0 (should) avoid the native client's requirement.

I do not have an A72 to test against. Could be slow, could be fine. idk.

 

 

Raspberry Pi OS and PPA:

known issue, thank you for the PPA advice

i'll try to get something together quick on this. so, v2.2

 

 

Again, I GREATLY appreciate your feedback!

 

 

Edited Tuesday at 01:25 AM5 days by Scrumpper

8 hours ago, Scrumpper said:

I do not have an A72 to test against. Could be slow, could be fine. idk.

I tested a Snap that installs Fex and x86 Steam. As long as a you have a capable GPU and thunking working, 8 A72 cores is fine.

 

Thanks for the quick updates.

 

 

 Steam ARM 2.2 is out: Debian 13 and Raspberry Pi OS now get FEX source as apt source file with pinned key (your earlier report)

setup checks host packages before changing anything.

 

looks like a nice snap

 

A72 boards still stop at Armv8.1 check, because Valve's native ARM64 client crashes there (steam-for-linux #13288) 

I tried 2.2 on RPi OS. Installation goes fine, but starting steam-arm doesn't work.

I also tried like this: steam-arm -no-cef-sandbox

I also tried the restart options. 

 

Output of terminal attached.

Anything else you need for analysis? The dmp file doesn't look human readable, but I can add it.

 

Steam.txt

By your log:

Install works; client starts, then steamwebhelper (Steam's built-in browser, draws whole Steam window) keeps crashing: window stays empty. 

 

 Please send:

1. `~/.local/share/steam-arm/.local/share/Steam/logs/webhelper-linux.txt` and `cef_log.txt` (if present). These show why steamwebhelper fails.
2. Hardware report: `steam-arm-config`, Maintenance > Hardware report (writes `steam-arm-report.txt`, personal details removed).
3. Output of `echo $XDG_SESSION_TYPE` and `getconf PAGESIZE`.

 

One test that would narrow it down: switch desktop to X11 (`sudo raspi-config`, Advanced Options > Wayland > X11, reboot), then start Steam ARM again. If Steam opens on X11, cause is Wayland.

 

No need for dmp file; crash IDs in log were uploaded to Valve already.

Edited Thursday at 09:41 PM2 days by Scrumpper