Scrumpper

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.

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)

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!

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!

v2.0 is out.

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

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

@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 :-)

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: Vulkan feature layer for Direct3D translation layer Remote Play decode settings for GPU with no Vulkan Video, Private Mesa GLX copy for multi threaded OpenGL, Controller access rules for 243 pads 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.

V4.2.1 GET IT NOW Hardware H.264/HEVC/MJPEG encode; 1080p faster than 180 fps (h96-encode) Works headless and for every desktop user, not only root mpv pre-tuned for the VPU; yt-dlp bundled and auto-updating 6 TOPS NPU; exposed and benchmarked RKNPU three-core neural engine, driver v0.9.8, up to 1000 MHz Single-core and 3-core INT8 benchmark, about 1.5 TOPS measured (h96-npu bench all) On-demand RKNN runtime installer, no proprietary library bundled (h96-npu-setup)

V3.2 IS LIVE https://github.com/Scrumpper/H96_MAX_V58_Unofficial-Armbian/releases

Thanks for the review :-) I couldn't get the same numbers as you but I imagine all silicon is a little different.

@Dravens Wayland compositing was broken on this Panthor/Mali-G610 stack. KWin-Wayland crashed when I tried it, and I never really looked into it any further. X11 is the session I ran with, and what the desktop hooks use. Nested Wayland works ok. I ship `cage`/`gamescope` running as a client inside the X11 desktop. This app gets a Wayland socket and PanVK Vulkan, no conflict with X11 alongside it (that's what my gaming/kiosk modes use). TLDR: Full Wayland has a known unfixed crash on this GPU stack. Checked the image, and the ophub kernel this build ships (6.1.141-rk3588-ophub) already has it compiled in (`binder.ko` in modules.builtin, so `CONFIG_ANDROID_BINDER_IPC=y`). So nothing needs rebuilding on my side. ashmem isn't needed either, Waydroid uses memfd since 1.2.1. Which means you can just try it: install `weston` + waydroid, run `weston --xwayland`, set `WAYLAND_DISPLAY`, and launch waydroid into it. Ready-made scripts: [waydroid-x11](https://github.com/mid-kid/waydroid-x11), [waywes](https://github.com/KSMaan45/waywes). Note it's Weston, not the cage/gamescope I ship. Warning on the GPU though: [waydroid#760](https://github.com/waydroid/waydroid/issues/760) is a Rock-5b (same RK3588/Mali-G610) that only boots with GPU disabled, [#776](https://github.com/waydroid/waydroid/issues/776) is "rockchip-rk3588 GPU unsupported", and [#2087](https://github.com/waydroid/waydroid/issues/2087) reports Panfrost/Panthor perf way below host. That's upstream Waydroid's passthrough, not something I can fix here. Expect software rendering... which could make other things run kinda rough.

@Hqnicolas Thank you for bringing this to my attention :-) I've updated the repo. Lmk if I should do anything else. This was kinda my first fore into making stuff for Armbian.

It seemed like EVERYONE was talking about "looking into" getting Armbian going on this box. I did my best. Built from the Rock5b images. WiFi: Broadcom BCM43752 / AP6275P 802.11ax "WiFi 6" Panthor + Mesa GPU stack Open PanVK Vulkan + Panfrost GL GPU driver Gpu no longer pinned to 800MHz. Power toggles cycle it 600MHz, 800MHz, and 1000MHz. (the CPU also scales) Desktop compositing on the GPU A command is needed to set monitor resolution. Default is 1080p. Other Findings: CPU frequency was scanned under load: LITTLE cores (Cortex-A55): 1800 MHz BIG cores (Cortex-A76): 2208 MHz Those were the scaling_cur_freq readings. The vendor DTB caps the A76 at 2208 MHz: the physical max is 2.4 GHz but that OPP entry isn't in the table. Github repo: DOWNLOAD RELEASE FILES READ THE README.md! REFLASH STOCK IMAGE: UNPACKED FLASHING FILES FOR STOCK ANDROID README.md