steam deck

[B-Nerd]

would it be possible to have a proper steam deck build where it can work without a external linux pc
because of steamos even with distrobox it is a mess to build

[jackpoison-prog]

Partly, and the next release moves it a good way closer.

Two things are needed to turn your disc into something playable: the recompiler, which converts the disc's executable into C, and a C compiler to build that C. The next release ships the recompiler inside the Deck package (tools/dolrecomp, statically linked, so it runs on SteamOS as-is). That half no longer needs another machine.

The compiler is the awkward half, because SteamOS ships none and mounts /usr read-only. It can be done — the whole toolchain has been built and run on a Deck — and the README now documents it. The trap that probably made it a mess:

sudo steamos-readonly disable
sudo pacman-key --init && sudo pacman-key --populate archlinux
sudo pacman -S base-devel glibc linux-api-headers cmake ninja

Do not add --needed. SteamOS ships an image with /usr/include stripped but leaves the packages registered as installed — pacman's database claims glibc owns 504 files under /usr/include when 14 are on disk. With --needed it decides everything is present, installs nothing, and you end up with compilers and no headers, which fails much later and looks like an entirely different problem. Without it you are restoring files rather than upgrading, since SteamOS pins snapshot repos. Never use -Sy or -Syu — that is what actually breaks Decks.

A SteamOS update wipes that toolchain, but keep the module you built: it is just a file, and it keeps working.

One more thing worth knowing: if your disc image is .rvz or .gcz, the recompiler cannot read it but the runtime can —

./bin/moderngekko-run --extract yourdisc.rvz ./game

I did look at bundling a compiler so none of this would be needed. Zig is the obvious candidate and it very nearly works — it compiles this project to byte-identical output — but its linker crashes on the module, so it is not ready yet. I will revisit when that is fixed.

[B-Nerd]

unlocking the file system is no the best way to do thing on steamos

[jackpoison-prog]

You're right, and I'm not going to argue for unlocking the filesystem as a good
answer. It gets wiped by every SteamOS update, which makes it a chore rather
than a fix.

1.4 is out and it does the half that was in my control: the Deck package now
carries the recompiler itself (tools/dolrecomp, statically linked, runs on
SteamOS as-is), plus a BUILD-ON-THE-DECK.md walking through the whole thing.

The other half I can't remove. Your module is compiled from your disc on your
machine — that's what keeps this legal — so a C compiler has to exist somewhere
in the process, and SteamOS ships none.

Three ways, honestly ranked:

Container (distrobox/toolbox) — survives SteamOS updates, no unlocking,
and it's what setup.sh points you at when it can't find a compiler. You said
this was a mess; if you tell me where it went wrong I'll fix the instructions,
because this is the route I'd rather have people on.

Unlock — works, and I tested it end to end on SteamOS 3.8.25 rather than
just writing it down: 34 minutes from unzip to a running module, no bundled
libraries needed. Updates wipe it, so the guide includes the reset steps too.

Build once on any Linux PC and copy two files over. One-time, and the
module keeps working across Deck updates because it's just a file.

Not the answer you wanted, but that's the actual shape of it.

[jackpoison-prog]

Coming back to this, because my answer from August is now out of date and you
asked for exactly the thing that has since happened.

Yes. The whole build runs on the Deck, with no second machine. In August I
could only tell you the recompiler half was solved and the compiler half was
awkward. Since then it has been done end to end on a Deck and written up:
BUILD-ON-THE-DECK.md,
which ships inside the Deck package as well. Tested on a Steam Deck LCD, SteamOS
3.8.25, build 20260807.2 — not theory, a real device doing the whole thing.

Current release is 1.5.2, and there are two zips:
https://github.com/jackpoison-prog/RingOut/releases/tag/v1.5.2

Download both of them onto the Deck

This is the part that isn't obvious, so it's worth being explicit:

zip	what it's for
RingOut-1.5.2-linux-x86_64.zip	this is what builds. It carries module-src/. You don't play with it on the Deck — it bundles 66 libraries that fight the Deck's own Mesa driver
RingOut-1.5.2-steamdeck-x86_64.zip	this is what you play. No bundled libraries, no game data — you copy in what you built

Then, on the Deck:

cd ~/RingOut-1.5.2-linux
./setup.sh --deck /path/to/your/disc.rvz

About 15 minutes. --deck is not optional: without it the module is tuned for
whatever built it, and with it you get -march=x86-64-v3, which is what the
Deck's Zen 2 actually executes. It checks the result and tells you if something
came out wrong. When it can see exactly one Deck package next to it, it installs
game/ and the module for you and says so; otherwise it prints the two cp
commands to run.

For Game Mode: Desktop Mode → Steam → Add a Non-Steam Game → point it at
~/RingOut-1.5.2-deck/RingOut. It plays in both modes.

The honest caveat: the toolchain is still the manual part

SteamOS ships no compiler and mounts /usr read-only, and I can't package
around that. So this is still one manual step, and it's the same one from my
August reply:

sudo steamos-readonly disable
sudo pacman-key --init && sudo pacman-key --populate archlinux
sudo pacman -S base-devel clang glibc linux-api-headers cmake ninja

Do not add --needed, and never -Sy or -Syu. Both traps are in the
doc with the reasoning; the --needed one is the vicious one, because SteamOS
leaves packages registered as installed with their headers stripped, so pacman
concludes everything is present, installs nothing, and you get compilers with no
headers — which fails much later and looks like a completely different problem.

A SteamOS update wipes all of that. The module you built survives — it's just
a file, and it keeps working.

Two things that will otherwise cost you

Your disc format. If it's .rvz, .gcz or .wia, the recompiler can't read
it but the runtime can:

./bin/moderngekko-run --extract /path/to/your/disc.rvz ./game

A message that looks like a failure and isn't. On a stock Deck you'll see:

module: this clang cannot read the shipped PGO profile

That's expected and it's my limitation, not yours. The shipped profiles are
written by LLVM 22 and SteamOS 3.8 ships clang 20, which can't read a profile
from a newer LLVM. You get a correct module, about 13% slower. You can have that
back by training a profile with your own clang:

sudo pacman -S llvm            # llvm-profdata lives here, NOT in clang
./setup.sh --deck --pgo /path/to/your/disc.rvz

Measured on the test Deck, that's worth 14% less CPU time (233.99 → 201.07
Gcyc over 6000 fixed frames, 8 runs each arm, ranges not overlapping) and costs
about 26 minutes on top of the normal build. It changes speed only — 18 runs,
profiled and not, all produced one identical state hash.

One prerequisite people trip on: play the game once first. The training run
needs your save data to get past the memory-card screen, and without it the run
sits on that screen and trains on nothing. Setup detects this and keeps your
existing module rather than building a worse one.

None of the profile part is required. The plain module is correct and plays fine.

---

So: still not a single-click install, and I'd rather say that than oversell it.
But "works without an external Linux PC" is now genuinely true, which it wasn't
when you asked. I'll leave this open — if you run through it on your own Deck and
something in that doc doesn't match what your SteamOS does, that's worth knowing,
since SteamOS moves and section 6 is entirely about its packaging behaviour.