Linux-arm64 release on experimental steam branch?

[Aureus]

I haven't seen anyone talk about it here on the forum. So I wanted to make this post.
On steam in the experimental branch a linux-arm64 build of Factorio is distributed with the linux x64 depot.

I have been playing that build for a couple days now. It is running really well on my Snapdragon X Elite laptop. And now I'm addicted to Factorio. Thanks!

08-30-2026, 01-49-34.png (16.41 KiB) Viewed 1478 times

08-30-2026, 01-50-58.png (26.38 KiB) Viewed 1478 times

08-30-2026, 01-51-30.png (56.28 KiB) Viewed 1478 times

[eugenekay]

Well i guess I have to try this on a Raspberry Pi next!

[h.q.droid]

How did you download it? From steam? I tried to download the Linux package from factorio.com and it doesn't have the AARCH64 executable.

EDIT: got the file from Steam. It didn't work:
- The window title says 2.1.15 despite being from a 2.1.17 install
- It hangs on startup

I'm on Asahi Linux. Output:

Code: Select all

   0.000 Initializing Steam API.
[S_API] SteamAPI_Init(): Loaded '/home/hqm/.local/share/Steam/linuxarm64/steamclient.so' OK.
Setting breakpad minidump AppID = 427520
SteamInternal_SetMinidumpSteamID:  Caching Steam ID:  76561198165610669 [API loaded no]
   0.000 2026-09-03 13:08:42; Factorio 2.1.15 (build 87324, linux-arm64, steam, space-age)
   0.000 Operating system: Linux
   0.000 Program arguments: "/home/hqm/.local/share/Steam/steamapps/common/Factorio/bin/x64/../arm64/factorio" 
   0.000 Config path: /home/hqm/.factorio/config/config.ini
   0.000 Read data path: /home/hqm/.local/share/Steam/steamapps/common/Factorio/data
   0.001 Write data path: /home/hqm/.factorio [24873/112951MB]
   0.005 Binaries path: /home/hqm/.local/share/Steam/steamapps/common/Factorio/bin
   0.020 System info: [CPU: arm64, 4 cores, RAM: 12178 MB]
   0.020 Environment: DISPLAY=:1 WAYLAND_DISPLAY=<unset> DESKTOP_SESSION=<unset> XDG_SESSION_DESKTOP=<unset> XDG_CURRENT_DESKTOP=<unset> SDL_VIDEO_DRIVER=<unset> SDL_ENABLE_STEAM_SCREEN_KEYBOARD=<unset> SteamDeck=<unset> __GL_FSAA_MODE=<unset> __GL_LOG_MAX_ANISO=<unset> __GL_SYNC_TO_VBLANK=<unset> __GL_SORT_FBCONFIGS=<unset> __GL_YIELD=<unset>
   0.044 Display options: [FullScreen: false] [VSync: false] [UIScale: manual-pixels (150.0%)] [Native DPI: true] [Screen: 4294967295] [Special: lmw] [Lang: en]
   0.098 Video driver: x11
   0.098 Available displays: 1
   0.099  [0]: eDP-1 13" - {1, [0,0], 2560x1600, SDL_PIXELFORMAT_XRGB8888, 59.99 Hz}
   0.327 Initialised OpenGL:[1] Apple M1 (G13G B1); driver: 4.6 (Core Profile) Mesa 26.0.6
   0.327   [Extensions] s3tc:yes; KHR_debug:yes; ARB_clear_texture:yes, ARB_copy_image:yes, ARB_pipeline_statistics_query:yes, ARB_gl_spirv:yes, ARB_ES2_compatibility:yes
   0.328   [Version] 4.6
   0.442 Graphics settings preset: integrated-gpuhigh
   0.442   Dedicated video memory size 7817 MB (detected from Apple M1 (G13G B1); VendorID: 0x10005)
   0.483 Graphics options: [Graphics quality: medium] [Video memory usage: all] [DXT: low-quality]
   0.483                   [Max threads (load/render): 32/4] [Max texture size: 4096] [Tex.Stream.: false] [Rotation quality: low] [Other: sTDCwtl] [B:0,C:0,S:100]

[eugenekay]

The arm64/factorio binary is only available through Steam; it is not (yet?) included in the Linux tar.xz release on the Website. This would be amazing to have available without Steam.

I have not had success installing Steam on a Raspberry Pi, since that is a i386-only application. It is theoretically possible to cross-run the binaries, but the package situation on Debian is a mess so I gave up.

Copying the binary over from a i386/amd64 system also did not work: the Steam version of the binary requires the Steam Service to be running.

[h.q.droid]

The arm64/factorio binary is only available through Steam; it is not (yet?) included in the Linux tar.xz release on the Website. This would be amazing to have available without Steam.

I have not had success installing Steam on a Raspberry Pi, since that is a i386-only application. It is theoretically possible to cross-run the binaries, but the package situation on Debian is a mess so I gave up.

Copying the binary over from a i386/amd64 system also did not work: the Steam version of the binary requires the Steam Service to be running.

Well, steam has a native arm64 version too now. I'm already running that on Asahi! And my problem turns out to be a muvm problem that you most likely don't have to care on a Pi. The guide is here:

https://www.reddit.com/r/AsahiLinux/com ... ux_fedora/

[Aureus]

How did you download it? From steam? I tried to download the Linux package from factorio.com and it doesn't have the AARCH64 executable.

EDIT: got the file from Steam. It didn't work:
- The window title says 2.1.15 despite being from a 2.1.17 install
- It hangs on startup

When I made this post it was only on the steam experimental depot. I am running ubuntu on a snapdragon X elite laptop.
I am running the aarch64 version of steam with the steam runtime 3 beta. I have had no problems running the game with the setup I am using, but aarch64 is so wacky I could just be an exception.


To run the aarch64 version of steam you can use this script which downloads the aarch64 version of steam and the aarch64 steam runtime 3. Then launches steam which should update it:

Code: Select all

#!/usr/bin/env bash

# verbose
# export PS4='${LINENO}: '
# set -x

set -o pipefail
shopt -s failglob
set -u

log () {
	echo "steam-init.sh[$$]: $*" >&2 || :
}
# This version interprets backslash escapes like echo -e
log_e () {
	echo -e "steam-init.sh[$$]: $*" >&2 || :
}

STEAMROOT="$(cd "$(dirname "$0")" && echo $PWD)"
if [ -z "${STEAMROOT}" ]; then
	log $"Couldn't find Steam root directory from "$0", aborting!"
	exit 1
fi

RTARM64ROOT="$STEAMROOT/steamrtarm64"

if [ ! -x "$RTARM64ROOT" ]; then
	mkdir -p "$STEAMROOT/package"
	echo "publicbeta" > "$STEAMROOT/package/beta"
	wget -c -t 5 -O "$STEAMROOT/linuxarm64.zip" "https://client-update.steamstatic.com/bins_linuxarm64_linuxarm64.zip.f523fa87fc6b9b5435a5e7370cb0d664ef53b50b"
	unzip -d "$STEAMROOT" "$STEAMROOT/linuxarm64.zip" "steamrtarm64/steam"
	chmod +x "$RTARM64ROOT/steam"
fi

if [ ! -x "$RTARM64ROOT/steam-runtime-steamrt-arm64" ]; then
	log "Downloading steam-runtime"
	wget -c -t 5 -O "$RTARM64ROOT/steam-runtime-steamrt-arm64.tar.xz" "https://repo.steampowered.com/steamrt3c/images/latest-public-beta/steam-runtime-steamrt-arm64.tar.xz"
	tar -xvf "$RTARM64ROOT/steam-runtime-steamrt-arm64.tar.xz" --directory "$RTARM64ROOT"
fi

if [ -x "$RTARM64ROOT/steam-runtime-steamrt-arm64" ]; then
    log "Starting steam-runtime"
    "$RTARM64ROOT/steam-runtime-steamrt-arm64/run" "$STEAMROOT/steamrt-boot.sh" "$@"
else
    log "steam-runtime nor pressure-vessel are installed"
fi

Then you can make a copy of the steam.desktop and modify the Exec= to something like this:

Code: Select all

Exec=env STEAMOS=1 STEAM_RUNTIME=1 /home/<YOUR USER>/.steam/steam/steamrtarm64/steam %U

> I always have to run it twice, it always opens silent for some reason for me.


Now you should just be able to run the aarch64 steam client by launching steam from your app launcher. Test in a terminal to see the output's though.

You can confirm if its the aarch64 version of steam by checking the proccess. Get the pid of steam and check the exe to see if its an aarch64 executable:

Code: Select all

file -L /proc/<steam_pid>/exe

But you could just wait. Steam will probably soon actually release all of this when the steam frame comes out.

[zkrallex]

Ngl, I'm more interested in this part:

09-13-2026, 01-24-24.png (16.63 KiB) Viewed 630 times

As most Android are arm64s, makes sense to split the job into porting to architecture first and then shipping to Android.

[eugenekay]

FFF-446 has announced this officially; including a Non-Steam Linux ARM64-specific Download. Officially it does not work on Raspberry Pi:

Of course we are going to support the Raspberry Pi, especially considering that I used mine to obtain the initial sysroots used in development! Unfortunately, the Pi's OpenGL support is rather limited, so while you can easily host servers from a Pi, you cannot play the game with graphics.

You can override the OpenGL driver auto-detection (to fake Pi's compatibility with 4.3, while also forcing the Pi to use specific profile):

$ MESA_GL_VERSION_OVERRIDE=4.3 MESA_GLSL_VERSION_OVERRIDE=430 ./bin/arm64/factorio

After waiting a LONG TIME at the loading screen:

20260918_10h07m27s_grim.png (1.78 MiB) Viewed 301 times

315.127 Error generateTextureObject:112: [OpenGL]: Error INVALID_OPERATION (1282).
360.266 Error GraphicsInterfaceOpenGL.cpp:260: [OpenGL]: Error INVALID_OPERATION encountered in frame 3046.

GraphicsInterfaceOpenGL.cpp is not happy; but the game works!

20260918_10h07m45s_grim.png (1.57 MiB) Viewed 301 times

There are some definite issues rendering transparent sprites (ie, most of them) so the game is not playable like this; but it works! I will do some more experimenting on a Raspberry Pi 5; it is probably going to be a bit faster than the Model 400 I used here.

Very cool!

[XT-248]

Cool that you were able to kind of get it to work on a Raspberry Pi 5.

I would like to see more updates if you have any.

[eugenekay]

So far I have only tried the Base Game (not Space Age), to give the Pi the best shot with the Graphics. Raspberry Pi 400 (Keyboard) using a MicroSD card took over 5 minutes to load the data files, crop bitmaps, etc.... not a great experience. Switching to a Model 5 with NVMe disk was 77 seconds - totally reasonable for a first-start!

LIBGL_ALWAYS_SOFTWARE=1 gives a better graphical appearance (transparent sprites are rendered correctly), but it is SLOW to render - less than 5FPS. Not a good choice.

Zink supposedly lets you run OpenGL applications through Vulkan API calls instead, but I have not been able to puzzle this together yet.

[sparr]

$ MESA_GL_VERSION_OVERRIDE=4.3 MESA_GLSL_VERSION_OVERRIDE=430 ./bin/arm64/factorio
After waiting a LONG TIME at the loading screen

You can use an external GPU with a raspberry pi, if you want to run the game at a somewhat normal speed.

[eugenekay]

I don’t have a PCI Express enclosure or spare GPU handy… but GPU performance does not immediately seem to be an issue; the Pi 5 manages 60fps at 1280x720 resolution while playing the Main Menu background simulations. This is the same as the Switch, which has a (on paper) slower & older chipset. Rendering suffers at 1920x1080; not a surprise.