← TRIGLER Lab
Proof of Concept — Reference Hardware
SteamOS POC
Validating the Kestrel launcher, suspend/resume, and controller UX on real, shipping SteamOS hardware — before committing to custom ARM silicon that doesn't exist yet.
Document KST-POC-001
Revision A
Issued 2026-09-01
Status Proof of concept — planning
1×
Translation layer (Proton)
2×
Translation layers if ARM (Proton + FEX)
01
Why swap the POC off Kestrel Silicon
The Kestrel Silicon KX2 in the architecture doc is a concept part — it has no fab, no dev kit, and no driver stack. Standing up a custom KestrelOS image for it would mean writing and validating a whole platform (bootloader, kernel bring-up, GPU driver, input stack, launcher) against silicon that doesn't exist. That's not a POC, that's the whole product.
SteamOS already runs on real, purchasable, driver-complete hardware, and its gamepad-first "Big Picture"-style UX is close enough to what Kestrel's software section describes (suspend-anywhere, quick resume, controller-native launcher) that it's a legitimate stand-in for proving the software and UX concept out. The open question this doc answers is which chip family to run that POC on.
Scope: this POC validates launcher UX, suspend/resume behavior, and controller ergonomics. It does not validate the KX2's performance, power, or BOM figures in the spec sheet — those stay concept numbers until real silicon is chosen. See §04.
02
Candidate Reference Hardware
All four run SteamOS or a SteamOS-derived image (HoloISO / Bazzite) today, with mature vendor driver support — no bring-up work required.
| Device | Chipset | Arch | CPU | GPU | SteamOS status |
|---|
| Steam Deck LCD | AMD Van Gogh | x86-64 | Zen 2, 4c/8t | RDNA2, 8 CU | Native |
| Steam Deck OLED | AMD Van Gogh (refined) | x86-64 | Zen 2, 4c/8t | RDNA2, 8 CU | Native |
| ASUS ROG Ally | AMD Z1 Extreme | x86-64 | Zen 4, 8c/16t | RDNA3, 12 CU | Community image |
| Lenovo Legion Go | AMD Z1 Extreme | x86-64 | Zen 4, 8c/16t | RDNA3, 12 CU | Community image |
Recommendation: Steam Deck (LCD or OLED) — it's the reference device SteamOS is built for, so it removes driver/firmware variance from the POC entirely and keeps the exercise focused on launcher and UX behavior rather than hardware bring-up.
03
ARM vs x86-64 — Game Compatibility
Kestrel's long-term concept silicon is ARM (mobile-class, low-power). SteamOS's actual install base and Proton's compatibility work are built around x86-64. Running the POC on ARM would mean stacking a second translation layer — FEX-Emu (x86-64→ARM) underneath Proton (Windows→Linux) — instead of Proton alone. That compounding is the crux of the comparison below.
x86-64 (Steam Deck-class)
Proton (Wine + DXVK/VKD3D)
Windows API → Linux/Vulkan
SteamOS / Linux, native x86-64
ARM (Kestrel-class)
Proton (Wine + DXVK/VKD3D)
Windows API → Linux/Vulkan
| Factor | x86-64 (Van Gogh / Z1) | ARM (Kestrel-class) |
|---|
| Translation layers to run a Windows title | 1 — Proton only | 2 — Proton + FEX |
| Kernel-level anti-cheat (EAC, BattlEye) | Partial — title allowlist | Effectively none |
| GPU driver maturity (Vulkan) | Mature — Mesa RADV | Varies by SoC vendor |
| Native Linux/SteamOS titles | Run as-is | Need ARM64 rebuild |
| "Steam Deck Verified" program coverage | Directly applicable | Not applicable |
| CPU perf-per-watt (silicon only) | Good | Better |
| Perf-per-watt after translation overhead | Retained | Largely erased by FEX overhead |
| Tooling / debugging maturity | Years of Deck-driven investment | Early, improving (Asahi, FEX) |
Anti-cheat is the hard blocker either way: most kernel-level anti-cheat vendors simply refuse to run under Wine/Proton regardless of CPU architecture, so it isn't an ARM-specific gap — but ARM's added FEX layer makes an already-narrow allowlist narrower still, since a title needs the anti-cheat vendor's Proton opt-in and FEX to handle it correctly.
04
Recommendation
POC chipset
x86-64 — AMD Van Gogh (Steam Deck) as the reference platform
Rationale
Single translation layer (Proton only), mature Mesa/RADV drivers, and direct access to the ProtonDB / Deck Verified compatibility data — the POC can focus entirely on launcher and UX validation instead of fighting a second, less mature translation layer
Kestrel ARM concept
Stays the long-term silicon direction in
the spec sheet — not abandoned, just decoupled from this POC's timeline
Revisit trigger
FEX-Emu / Asahi-class ARM Linux driver maturity closing the gap, or Kestrel committing to native ARM64 builds instead of relying on x86-64 game compatibility at all
This is a sequencing decision, not a reversal: prove the software concept fast on hardware that already exists (x86-64 / SteamOS), then decide whether Kestrel's production silicon stays ARM (better perf-per-watt, but a compatibility lift) or follows the POC onto x86-64 (matches the concept spec's game-compatibility goals out of the box, at the cost of the mobile-class power envelope in the original spec).
05
What the POC Does and Doesn't Prove
Validates
Gamepad-first launcher flow
System-wide suspend / resume
Quick-resume cache concept
Controller ergonomics and mapping
Does not validate
KX2 CPU/GPU performance figures
Power-consumption breakdown (§03 of architecture doc)
BOM / cost reference (§05 of architecture doc)
245g weight / 175×78×19mm form factor