Home · Install · Troubleshooting · Recovery

Steam Deck and SteamOS

The v0.3.0-preview.1 installer and runtime passed controlled SteamOS VM tests. Real Microsoft sign-in, repeat menu/profile loading, and a short Free Play drive with normal exit subsequently passed with a scoped Venus presentation workaround. Hakone benchmark loading remains unresolved. Physical Steam Deck gameplay is not yet validated. The preview supplies a complete custom Proton tool, a separate user bundle, and a Flatpak login/overlay app. SteamOS stays read-only. Use Install for the exact preview steps and Recovery to undo them. Preserve an existing working setup; use a fresh test environment.

Check your system first

In Desktop Mode, open Konsole and run as your normal user:

git clone --branch v0.3.0-preview.1 --depth 1 https://github.com/volcmen/forza-motorsport-linux.git forza-readiness
cd forza-readiness
./setup platform-check

This read-only command needs Python 3.11 or newer, without uv, sudo, or system package changes. Start native Steam first so its library metadata exists. It reports dependencies, user services, Secret Service, game/prefix candidates, space, and DLL names that collide by case. It recognizes an additional library, including mounted microSD metadata, without proving physical storage behavior. It never creates a prefix, copies/deletes DLLs, selects an ambiguous installation, or uploads results. ./setup platform-check --json omits private library paths.

The current main checkout also checks read/write/search access to the actual game directory and reports free space on its filesystem. This catches a game folder mounted separately from the library root. It performs no write probe and does not change permissions. The tagged preview predates these extra checks.

Native GUI dependency warnings on SteamOS are expected before installing the preview Flatpak. Missing native service libraries and ambiguous layouts still need resolution. A passing diagnostic establishes prerequisites, not gameplay.

Earlier controlled qualification

The disposable guest used Valve's installed SteamOS 3.8.14 image, KDE Plasma X11, an ordinary user session, and software graphics. The game metadata and private threading DLL were synthetic; the prefix was created with the actual packaged Proton launcher. There was no authenticated Steam game launch or Microsoft account.

Check	Observed result
Prepare → Finish → status	Complete tool verified and published; user-only integration reached READY_TO_ATTEMPT; full tool remained unchanged.
Doctor	Installation and prerequisite checks passed; disk space warned below 100 GiB.
Actual installed runtime	26 Wine API checks passed with one optional invite-relay skip; 18 storage checks passed through the installed launcher and native service.
Login app	Microsoft sign-in page rendered from the new Flatpak. Account/token persistence was not exercised.
Overlay	Rendered the waiting/empty state with the native service. No invitations or physical controller were tested.
Recovery	Rollback removed recorded user files and the public tool, retained prefix/recovery copies and Flatpak, and left SteamOS read-only.

The dated validation record and build/source record identify exact inputs, revisions, checks, and limits.

Later real-account and game test

The October 15 real-account follow-up used the licensed Steam game, actual threading DLL, an authenticated Steam client, and Venus graphics in an isolated SteamOS VM. Microsoft password/MFA sign-in completed; its wallet records survived a full VM reboot. The real game created its prefix, reached the installed launcher and native service, and then remained at a white window before the menu. Steam's official file verification completed successfully after correcting ownership of the isolated ext4 disk's root directory. A further game launch with verified files, writable storage and normal synchronization settings still did not reach the menu. Lower logging and a controlled fsync comparison also did not resolve the blocker; diagnostic overrides were removed afterward. Basic Direct3D 12 readback and presentation worked in a separate scratch test, but swap-chain cleanup still timed out. The dated report records the observed callbacks, wait samples, controls and limits.

Venus presentation follow-up, October 16

The new test record isolated the scratch probe's cleanup hang to a present-wait path. Disabling both v1 and v2 present-id/wait extensions let the probe complete rendering, readback, every cleanup step, and normal process exit. Disabling only v2 still timed out; the earlier v1-only comparison had left v2 enabled.

With the same override, the licensed game passed its white window, optimized shaders, displayed the title screen and Welcome Center, and loaded the existing player profile and settings. A second launch repeated the menu/profile result without another account login. The first benchmark attempt stalled while loading Hakone. A restart with Low quality and ray tracing Off also stalled; a further nodxr comparison reached a black screen without a benchmark result, so that extra flag was removed.

A later Free Play session, with Low/Off and the presentation workaround retained, loaded Brands Hatch Indy Circuit in the owned 2017 Acura NSX. Keyboard throttle, steering, and brake/reverse changed the car's speed, direction, and position. Quit Race returned through the menus, and Exit to Desktop returned normally to Steam with no game or owned Xodus service process remaining. The selected lap was not completed. This limited driving result does not resolve the separate Hakone benchmark failure; long-session stability and measured performance remain unverified.

For the tested Venus VM only, prepend this assignment to the existing Forza Steam launch options, keeping the required launcher and other options intact:

VKD3D_DISABLE_EXTENSIONS=VK_KHR_present_id,VK_KHR_present_wait,VK_KHR_present_id2,VK_KHR_present_wait2

Remove that assignment to undo the change. Do not replace managed Proton or launcher files. This is an experimental diagnostic workaround for the recorded virtual graphics stack; it is not a recommended default on physical Deck/AMD hardware. See the dated record for exact builds, controlled comparisons, and remaining limits.

Wallet activation after reboot

The reboot exposed a native-launcher failure when KDE's existing Secret Service had not started. PR #17 adds activation of the existing desktop provider before a new Xodus session. The tagged v0.3.0-preview.1 checkout predates that correction. On the tested SteamOS KDE image, an existing installation can use this session-scoped workaround before launching the game:

busctl --user --timeout=5 call org.freedesktop.DBus /org/freedesktop/DBus \
  org.freedesktop.DBus StartServiceByName su org.kde.secretservicecompat 0

This uses the installed KDE provider. Preserve the accepted installation files; replacing its managed launcher manually invalidates integrity checks. The fix addresses service startup; it does not establish successful game-menu or gameplay behavior.

What virtualization establishes

Containers were useful for pinned, isolated compilation and dependency tests. QEMU was useful for installed-OS dependencies, desktop applications, user services, paths, and recovery. Neither reproduces a Deck's GPU, controller, power management, or game performance. Valve also distinguishes VM-based development from device validation.

Preview limitations

• Use native Steam. Flatpak Steam is unsupported. Additional libraries must resolve to one unambiguous game and prefix; do not unplug storage during a transaction.
• The app and GNOME 50 runtime commits are pinned. A runtime update requires requalification; do not downgrade another app's runtime or change trust hashes.
• The GUI uses the existing Secret Service/KDE Wallet. Do not add a competing credential daemon or disable SteamOS read-only mode.
• The overlay needs input-device permission for its current SDL listener. That permission covers more than a gamepad; the Xodus socket also permits protocol requests despite its read-only mount.
• Start the overlay while the game/service is running. Close and reopen it after each service restart: the old Flatpak retains the earlier socket inode.
• READY_TO_ATTEMPT is an installer result. Incoming invite notifications remain unsupported; explicit Invite/Join needs a real account/game test.

What a physical Deck still needs to establish

1. Real Steam prefix creation and game handoff with the selected preview tool.
2. Microsoft sign-in, wallet unlock/cancellation, saved credentials and refresh.
3. Two successful launches, online content, and clean exit in Gaming Mode.
4. Controller navigation/driving, Steam Input behavior, and the overlay controls.
5. Internal storage and actual microSD installation/removal behavior.
6. Suspend/resume, graphics stability, measured performance, and explicit Invite/Join.

Use the first-session checklist and record the SteamOS version, Deck model, storage location, exact release, and steps actually attempted. Do not attach licensed DLLs, credentials, account identifiers, or unredacted authentication logs. A startup screenshot alone does not establish gameplay.