Files
DroidDeck/docs/releases/0.1.1.md
T

10 KiB
Raw Blame History

SteamDeck 0.1.1

A patch release, and mostly about the two things 0.1 could not do: change a driver, and tell you what went wrong. Install it over 0.1 - same key, same runtime, nothing to re-download.

Everything here came out of one day of reports from three devices, which is why so much of it is about being able to see a fault rather than a new feature.


Graphics drivers - a new button on the main screen

Two lists, because a zip for one cannot serve the other:

  • Linux runtime driver - the glibc Turnip everything inside the runtime renders on: the Steam client's interface, every game it launches, and in desktop mode every program on the desktop. Import a -Linux Turnip zip; an Android or -Wayland zip is refused with the reason rather than becoming a black screen. The choice is per mode, so Steam and the desktop can run different builds. Nothing inside the runtime is modified - the session is pointed at the imported driver and the runtime's own Turnip is what a removed or unreadable import falls back to.
  • Display driver (Android) - the bionic Turnip the app's compositor puts the frame on the panel with. Auto keeps the GPU pick between the two bundled builds; an imported AdrenoTools zip can be chosen instead. It applies after the app is fully closed and reopened, because the compositor loads its driver once per process.

This is how a driver fix now reaches an installed runtime without a ~790 MB re-download.

Proven on device: an imported Mesa 26.3.0 (Vulkan 1.4.363) glibc Turnip drawing a whole Steam session - gamescope, the client, its UI helpers and Xwayland all on it - with an imported Android Turnip in the compositor in place of the bundled build.

Adreno 710 / 720 / 722

0.1 cannot start on these at all: Mesa has no entry for them and the session dies at device (chip_id = 7010000, gpu_id = 710) is unsupported. There is now a path - import Turnip-…-710-720-Test.zip as the Display driver and …-710-720-Test-Linux.zip as the Linux runtime driver, from Banners-Turnip's v26.3.0-20260921-r3 or newer. Those GPUs also want sysmem rendering, which the app sets on its own when it sees that driver chosen.

Unverified on real hardware. Nobody has run this runtime on a 710 yet. If you have one, the session folder is the thing to send.


Sound, and the microphone

DirectAudio for games replaces Wine's audio driver inside the games the client launches with one that talks straight to Android over a socket - no PulseAudio in between, and no resampling. The client itself keeps PulseAudio either way; it is a native Linux program with no other way to make a sound. It pairs only with a Wine 11 Proton (Valve's ARM64 builds, GE-Proton, proton-cachyos) and stays off on anything else rather than play silence, saying so in the log.

Microphone is its own switch: the relay helper opens Android's input stream under the app's own uid - which is what the recording permission is checked against - and PulseAudio exposes it to the client as DirectAudioMic, for voice chat. With it off, nothing in the session can record and Android's indicator stays off.

Both are under Audio on the main screen, both off by default, both applying at the next session start. A game's first launch after enabling DirectAudio still uses Proton's own audio - the driver is named in that game's prefix, which does not exist until then - and the second uses DirectAudio.

Built and wired; the microphone reached DirectAudioMic only after a fix to the bundled PulseAudio (0.1 shipped a 17.0 build of the module beside a 13.0 daemon, so it could never load). Treat voice as ready to test rather than proven.


Steam's overlay, and the app that takes your login

Two deviations from a normal Steam launch, both removed rather than worked around.

The overlay used to be stripped from every game, because it sat in front of the controller reader. That was an ordering problem - the interposer now goes first and the overlay loads as Valve intends. Every difference between the launch Valve ships and what runs here is a difference this runtime would otherwise have to account for.

And another Steam client on the same phone signs this one out seconds after every login. The app now asks Android to stop it when a session starts and says so. Where that app restarts itself through boot receivers, a background stop is a race it can win - if the client keeps signing out, uninstall the other one.


Performance and session fixes

Performance on the main screen, all off by default, all applying at the next session start:

Steam client cores Steam pins its own interface to a subset of cores it chooses - on one device five of eight, leaving out the fastest - which suits a running game and makes the menus sluggish when the client is all there is. Overriding it pins the client, its UI helper and gamescope to the cores you tick, re-applied every few seconds because the UI keeps spawning helpers that inherit Steam's choice
Game cores the cores a game may run on, applied by exec'ing it through taskset so every thread inherits the mask from its first instruction
Skip Steam's xalia helper xalia is an x86 Windows program Proton starts for gamepad navigation. On some devices its system calls are refused in a way it cannot cope with and the session dies seconds after Big Picture appears. Turn this on if a session will not stay up
Run proot without seccomp proot normally lets most system calls run untraced, which is most of its speed. Some kernels handle that badly and refuse calls that plainly exist. This traces everything instead: slower, but correct
Turnip: sysmem rendering for an Adreno 8xx that looks glitchy or slow, and required on a 710/720/722
Zink: lazy descriptors the client's menus are drawn through Zink; the first thing to try when the menus are slow while games are fast

Plus Download/steamdeck-env, a file of KEY=VALUE lines added to the session's environment, for an experiment that would otherwise need a build per attempt.


Logs worth sending

This is the change that will save the most time. Each session now gets its own folder:

Download/SteamDeck/session-20260921-161256/
    device.txt     what this device is, and every setting the session ran with
    network.txt    the link, the DNS the runtime was given, and what it means
    app.log        what the app itself decided and reported
    crash.log      Android's crash buffer, as it stood when the session ended
    audio.log      the PulseAudio daemon and the DirectAudio relay helper
    session.log    the guest session: proot, gamescope, the client's own output
    wayland.log    the compositor - what it presented, and how fast
    steam.log + steam/   the client's own logs                  (Steam mode)
    desktop.log    labwc, the panel and the programs on it      (desktop mode)

device.txt is written before the session starts, so a session that dies in its first second still says what it ran on: model, SoC, Android and kernel, cores and their ceilings, RAM, the GPU as KGSL names it, the panel, which driver each half of the session chose, and every switch in effect. crash.log is where a session the system killed leaves its only trace.

Credentials are scrubbed and nothing identifying is collected. Steam's logs are filtered line by line on the way in - session tokens, machine-auth GUIDs, WebAPI keys, Guard codes and e-mail addresses are replaced, and a SteamID is masked to its last four digits so lines still correlate. loginusers.vdf, config.vdf and the ssfn files are never copied. No serial number, no device or advertising id, no account name, no network name. A session folder is meant to be attached to a report exactly as it is.


If Steam dies with nothing in the log

That is usually not Steam. Android 12 and later kill the extra processes an app starts for itself once there are more than a few, and a session is made of dozens - proot, gamescope, Xwayland, the client and its helpers, Wine, FEX. Where that is left on, the OS ends the session and no log of ours says why, because nothing in the session did it.

Some phones expose it in Developer options as a "restrict child processes" switch - turn it off. Otherwise, once per device:

adb shell settings put global settings_enable_monitor_phantom_procs false

device.txt records what your phone reports, and the Performance dialog says so when it is not disabled.


Still true from 0.1

VAC-protected games report insecure. Games that ship only a Linux build will not start - install the Windows version instead. The desktop composites in software, and Firefox's child-process sandboxes are off there. No Switch emulator. The emulator packages install but none has been run with a game.

If a game launches and dies instantly, check Properties → Compatibility in the client: a game pointed at the ARM64 Proton needs that depot to have finished downloading, and the session log says so plainly when it has not.


Credits

  • maxjivi05 (Max) - the gamescope runtime this is built on: the proot session, the session shim, the input interposer and the controller work, from WinNative. The PROOT_NO_SECCOMP fallback and the phantom-process finding above are his too.
  • The412Banner - the app, the Wayland compositor, the runtime plumbing and the Steam session.
  • Winlator (brunodev85) - the PulseAudio-on-AAudio audio stack, the gamepad state model and the shape of a session's host-side components.
  • Vauzi (Vauzi-17/710) - the Adreno 710/720/722 device entries the experimental driver carries.

Frame generation: Win-FG is built in; LSFG uses the shader chain from your own copy of Lossless Scaling, read on device and never redistributed, on groundwork from lsfg-vk (PancakeTAS).

GPL-3.0. gamescope, Mesa, Turnip, Xwayland, labwc, LXQt, PulseAudio, proot and Arch Linux ARM are their own authors'. Not affiliated with Valve - Steam, Proton and Steam Deck are Valve's, and no Valve software is redistributed here: the client is fetched from Valve's own manifest on your device.


APK SteamDeck-0.1.1.apk - 15927028 bytes sha256 db4b0604ca53c4441bb66d0764ca7ff98b2a9f7bdfc48e3d52c6024b3a4bf78c versionCode 2, built from 2570562 by run 35634795441. Signed with the AOSP test key (v1 + v2 + v3), so it installs over 0.1 and the r24–r34 test builds in place.