Explainer · September 2026

Valve's Linux Steam client now runs on an Android phone. No root.

Not Wine pretending to be Steam. Not a streaming app. Valve's own Steam client for ARM Linux — the same build a Steam Deck-class ARM device would run — executing on your phone as ordinary ARM code, signing in, downloading from the store, and launching Windows games through Valve's own Proton.

“Max and I have been working hard on bringing everyone a true Linux Steam client running on Android without root requirements. His work with Gamescope and mine using Wayland has unlocked a powerful future for us all. No longer need to flash or dual-boot ArmadaOS or Rocknix — it comes straight to you via Bannerlator, WinNative, or a standalone app.”

The412Banner, announcing it in #gamescope-linux-steam-client

The first reply in that channel was, roughly: I still don't know what any of this means. Fair. This page is that answer, written for someone who has never used Linux and does not want to start now.

---

Start here: six words that do all the work

Skip this if you already know what Proton is.

Operating system

The software a device actually boots. Your phone runs Android. Your PC runs Windows. A Steam Deck runs Linux. Programs are built for one of them and normally will not run on another.

x86 and ARM

Two different machine languages. PC games are written in x86. Your phone's chip speaks ARM. Different words, not just a different accent — something has to translate.

Wine

Not an emulator. A re-implementation of Windows' own plumbing, so a Windows program's requests are answered by something that isn't Windows. It handles the operating system gap, not the chip gap.

Proton

Valve's packaged Wine, tuned for games, shipped through Steam. It is how a Steam Deck plays Windows games while running Linux.

Vulkan

The modern graphics language phones and PCs share. Games speak DirectX; something must convert it. Vulkan is the common ground that makes all of this possible at all.

Compositor

The thing that takes finished pictures from programs and puts them on the screen in the right order. Android has one. Linux needs one. We wrote one that lives inside the app.

Two roads to the same Windows game

This is the whole story in one picture. The rows are the same on both sides; what changes is who supplies each piece.

Bannerlator has always taken the left road: we build everything ourselves and run it as an Android app. The new work adds the right road: build a small Linux system instead, and let Valve's own software do its own job inside it.

Windows plumbing we build Valve's own software, unmodified Our Android-side pieces

Why the right road is worth the trouble

On the left road, every Windows-side fix is ours to make. When a game needs a newer Wine, we build one. When Valve improves Proton, we port it. The game also has no idea Steam exists: to install and update games, Bannerlator implements Steam's own download protocol itself.

On the right road, the Steam client is the real thing. Your library, cloud saves, the store, downloads, updates, friends, Big Picture, controller mapping — that is Valve's code doing its normal work. When Valve ships a better Proton for ARM, Steam downloads it by itself, like on a Deck.

A Linux system inside an app, with no root

This is the part people assume is impossible, and the part Max's work cracked.

Android is Linux underneath — but a locked-down one. You cannot become the administrator, you cannot mount a second filesystem, and an app lives inside a sandbox designed to stop exactly this. So rather than fight the phone, the runtime works entirely inside what an ordinary app is already allowed to do.

The walls, and what each one cost

Every one of these was a dead stop at some point, and the answers are the actual engineering in this project.

Wayland, and how a frame gets to your screen

"Wayland" is the word doing the most work in the announcement, so here is what it means.

On Linux, programs do not draw straight to the screen. They hand finished pictures to a display server, which decides where each window goes. The old one is X11, from the 1980s; the modern replacement is Wayland, which is simpler and much better suited to one program handing over one finished frame at a time — exactly our situation.

So the app contains a Wayland display server of its own. Linux programs connect to it as if it were a normal desktop. It takes their frames, and hands them to Android's compositor, which puts them on the panel. Nothing else on the phone is involved.

Who actually made the frame generation

We did not invent frame generation, and most of what runs here is not ours. It is worth being exact about this, because it is easy to read “frame generation in our compositor” as a bigger claim than it is.

• LSFG is Lossless Scaling's work. The shaders come out of your own copy of Lossless Scaling — the app you bought — read from the Steam library at runtime and never redistributed. The groundwork for running that chain on Vulkan outside Windows is lsfg-vk (PancakeTAS), with the Android port that followed it. Our part is the wiring: making it run inside the compositor on gamescope's output, finding your Lossless.dll in the Steam library for you, and the switches that turn it on mid-game.
• Win-FG is the one engine built here from scratch. Clean-room optical-flow frame synthesis — no proprietary shaders, no purchased DLL, no borrowed model weights — which is exactly why it can be built in and needs nothing from you.

So: one engine ours, one engine someone else's that we made work in a place it had never run, and the pacing and placement in between. Nothing else about frame generation on this page is a claim of authorship.

Why a driver can't cross the line

Programs need a small library to talk to the operating system, and Android and Linux use different ones — Android's is called bionic, desktop Linux uses glibc. Same language, different dialect: a driver built for one cannot load in the other, even on the same phone, for the same GPU. That is why Bannerlator's Contents screen has three separate driver slots, and why putting a file in the wrong one is refused rather than quietly broken:

Three ways to get it

Same runtime underneath. The difference is how much else comes with it.

Rough cost either way: about 790 MB for the Linux system, once, before any games. The desktop and emulator packages are roughly another 1.1 GB if you want them. You need an ARM64 Android 9+ device with an Adreno GPU — Mali, Xclipse and PowerVR are not supported by this path.

What actually works today

An honest ledger, not a feature list. Most of this has been proven on one or two devices.

What doesn't work, and why

• VAC-protected games report “insecure”. Team Fortress 2 runs and plays, but Valve's anti-cheat does not arm. Everything around it is correct — logged in, tracked by Steam, no errors — and the cause sits in the game's own start-up, before logging begins. The gap is the sandbox layer Android denies us, the same one that had to be removed to launch anything at all. This will be fixed by closing that gap or not at all: nothing here is, or will be, an attempt to hide from anti-cheat. Games not gated on VAC are online and fine, and BattlEye did not block GTA V.
• Games with only a Linux version don't run. Old Valve titles like the original Half-Life install a Linux build made for x86 PCs, and that needs the same missing sandbox. The workaround is to tell Steam to install the Windows version instead, which then takes the proven road.
• The Linux desktop composites on the CPU. Programs on it still use the GPU themselves; it is the desktop's own window-shuffling that runs in software, because the compositor it uses insists on a GPU device node Android doesn't hand out.
• Firefox's internal sandboxes are switched off in that desktop — they cannot be set up inside proot, and its tabs crash otherwise. Treat browsing there as less protected than on a real desktop.
• No Switch emulator, and there won't be one: the project's repository was taken down in February, so there is nothing to build from.

Questions people are already asking