Steam Deck

Home · Install · Troubleshooting · Recovery

Steam Deck and SteamOS

The v0.3.0-preview.2 installer and runtime passed local SteamOS VM checks. Earlier real Microsoft sign-in, repeat menu/profile loading, and a short Free Play drive with normal exit passed with a scoped Venus presentation workaround. Preview 2 retesting found a race stall before completing a lap; Hakone benchmark loading also 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.2 --depth 1 https://github.com/volcmen/forza-motorsport-linux.git forza-readiness
cd forza-readiness
./setup platform-check

This tagged checkout includes the current diagnostic and installer corrections. Keep the installation checkout and recovery inputs described in Install. The 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.

Preview 2 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 older preview 1 predates these extra checks.

Current diagnostics default to the composed preview: native service libraries and the flatpak command are required; GTK, WebKit and SDL for the GUI come from the preview Flatpak. The diagnostic does not verify an installed app or runtime; composed Finish checks their exact commits and permissions. Missing native service libraries and ambiguous layouts still need resolution.

For an older native v0.2 setup, run ./setup platform-check --profile legacy from this diagnostic checkout. That profile retains native GUI checks and reports that fresh legacy acquisition is retired. Preview 1 predates profile selection and still uses the old native checks. A passing diagnostic establishes prerequisites, not gameplay. See the feedback review for the contributor reports and validation behind these corrections.

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. Preview 2 includes that correction and passed a fresh post-boot service launch. The older v0.3.0-preview.1 checkout predates it. 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.

Preview 2 maintenance qualification, October 17

The new qualification record uses the real-account VM, its existing Steam prefix and the unchanged verified runtime packages. Recovery after the game filesystem was remounted passed. Fresh tool/user Prepare and Finish passed after the corrected disk check caught 20 GiB free and the dedicated test disk was expanded. The OS remained read-only. The installed runtime passed 26 API tests and 18 storage checks.

The game loaded its saved profile and a one-lap Brands Hatch Indy event, then stalled with the lap timer at 00:46.858. This is a failed complete-race test, separate from the earlier short driving and normal-exit result. Do not read installer success or the earlier menu result as a race-stability guarantee. Disabling ntsync did not finish loading the comparison event within three minutes. The run with native threading DLL loading disabled exited before the title screen, although the standalone API test still passed. A native control with the same tracing also exited during shader loading, so the exit cause was not isolated. The licensed DLL requirement remains. These results apply to this pinned runtime and VM. Later native launches still exited early after a complete VM restart. Final composed status and the licensed-file integrity check passed. The original Steam options and local driving-assist selections were restored; the assist restoration could not be confirmed in the game UI.

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.