A managed takeover runtime-masks the box's `gamescope-session-plus@*` unit so its
session supervisor cannot restart it underneath our Steam. The only unmask ran in
`do_restore_tv_session`, on client disconnect — so for the whole stream the mask
stayed on, and it silently barred the door the user was most likely to walk
through next.

`mask_unit`'s own doc said the mask "blocks nothing" on images whose sddm helper
execs the session script directly. That is half right, and the half it gets wrong
is this bug: on f43 bazzite-deck the script's last act is

    systemctl --user --wait start gamescope-session-plus@${CLIENT}.service

(verified on the .41 VM). What the mask fails to stop is the RELOGIN LOOP — sddm
keeps trying regardless, which is why stopping the DM is the real defense. What it
very much does stop is the unit, and with it every entry into game mode, including
the user's own deliberate "Return to Gaming Mode" after a mid-stream switch to the
desktop. Steam then sits on its "Switch to Desktop…" modal forever. `--runtime`
lives in tmpfs, so a reboot cleared it — hence "it works right after a reboot" —
and a plain `unmask` does not (measured: still `masked-runtime`).

So the mask's sound lifetime is shorter than the takeover's: it ends the moment the
box stops being ours. The mid-stream session watcher already detects exactly that,
so it now lifts the mask on a confirmed switch to a desktop session — ahead of the
`compositor_for_kind` arm, because a switch we cannot follow still has to unbar the
return. `Gaming` and `None` deliberately do not lift: a takeover's own managed
session reads as `Gaming` and one momentarily down between relaunches reads as
`None`, and lifting on either would void the mask for the whole stream, in exactly
the SDDM-storm window it exists for.

Fixes a second, worse leak on the way: `honor_session_select_switch` consumed
`STOPPED_AUTOLOGIN` — the only record of what carries a mask — without unmasking,
so under a DM-stop takeover the disconnect restore found an empty list and lifted
nothing. That mask outlived not just the stream but the boot. It is also what let
that path's own step 1 work at all, since the DM's autologin heads back into game
mode through precisely this unit.

The lift is idempotent, keeps the restart list intact (the disconnect restore still
owes those units a `start`), and every hand-back path now routes through it.

Verified on Linux: `switch_ends_mask_window` decision table, plus an ignored
end-to-end test driving real `systemctl --user` (masked → survives Gaming/None →
lifted by a desktop switch → restart list intact → idempotent). Proven non-vacuous
by planting "Gaming also lifts", which fails it on the during-stream assert.

2026-08-10 17:16:29 +02:00

src

fix(gamescope): a takeover's mask no longer bars the box's own way back into Game Mode

2026-08-10 17:16:29 +02:00

vendor/usbip-sim

feat(gamepad): SC2 Puck-dongle passthrough with the native 28DE:1304 topology

2026-07-15 20:47:52 +02:00

build.rs

feat(host/windows): "Punktfunk Host" identity in Task Manager (icon + version info)

2026-07-03 13:52:55 +00:00

Cargo.toml

feat(pad-audio): DualSense audio haptics + speaker, host->client end to end

2026-08-01 12:07:06 +02:00

README.md

chore: consolidate all in-progress parallel-session WIP

2026-07-16 20:08:29 +02:00

README.md

punktfunk-host

The streaming host — the program you run on the machine whose desktop or games you want to stream. For each client that connects, it spins up a virtual display sized to that device, captures it on the GPU, encodes with hardware NVENC/VAAPI/AMF/QSV, and sends it out over a low-latency transport — no physical monitor, no letterboxing, no rearranging your real screens.

It speaks two protocols from one process:

GameStream — so any Moonlight / Artemis client works day one.
punktfunk/1 — punktfunk's own faster protocol (QUIC control plane, GF(2¹⁶) FEC + AES-GCM data plane) that the native clients use.

Runs on Linux (the primary, most battle-tested path) and Windows (x64). The shared protocol, FEC, and crypto live in punktfunk-core; this crate is everything platform-facing around it.

What it does

Per-client virtual displays at the exact WxH@Hz. Linux uses per-compositor backends — KWin, gamescope, Mutter, and Sway/wlroots; Windows uses its own all-Rust IddCx virtual display, even on the secure desktop (UAC / lock screen).
GPU zero-copy capture → encode. dmabuf → CUDA/Vulkan → NVENC on Linux; on Windows the host pushes frames straight into its own IDD (sealed IDD-push, no screen-scraping) → GPU encode. Encoders auto-select by GPU vendor: NVENC (NVIDIA), VAAPI (Linux AMD/Intel), AMF/QSV (Windows AMD/Intel), or software H.264 as a floor. HDR/10-bit and HEVC 4:4:4 supported.
Input injection. Mouse/keyboard (libei / gamescope EIS / wlr / Windows SendInput) and virtual gamepads — Xbox 360/One, DualSense, DualShock 4 — with rumble and HID feedback back-channels.
Audio both ways. Opus audio host→client, plus a virtual microphone the client can talk into.
Trust & discovery. A persistent host identity, SPAKE2 PIN pairing (default) or TOFU, and mDNS auto-advertisement so clients find the host without typing an IP.
Management API + web console. A REST API (mgmt.rs, OpenAPI at api/openapi.json) drives status, paired devices, and on-demand pairing; the browser UI is in web/.

Run it

punktfunk-host serve runs inside your desktop session. Bare serve is the secure native-only default (punktfunk/1 + the management API); add --gamestream on a trusted LAN to also accept stock Moonlight clients.

# Linux, from the repo root (see the repo README "Running on this box" for the headless recipe):
cargo run -rp punktfunk-host -- serve                 # native-only (secure default)
cargo run -rp punktfunk-host -- serve --gamestream    # + Moonlight compatibility

Then pair from the web console (https://<host-ip>:47992) or the client app.

Most people should install a package rather than run from source — see packaging/ (apt · rpm/COPR/bootc · Arch/sysext · Windows installer) and the per-platform guides at docs.punktfunk.unom.io/docs/install.

Subcommands

Command	Purpose
`serve`	The host (native `punktfunk/1` + mgmt API; `--gamestream` adds Moonlight).
`punktfunk1-host`	Standalone native-protocol listener for testing/measurement (`--source virtual`, `--max-sessions`).
`openapi`	Print the management-API OpenAPI spec (regenerates `api/openapi.json`).
`library`	Inspect the multi-store game library.
`service` · `driver` · `web`	Windows: SCM service, driver install, bundled web console.
`-test` / `-selftest` / `*-probe`	Diagnostics (input, zero-copy, HDR, compositor, gamepads).

--help lists them all.

Layout

src/
  main.rs            CLI + subcommand dispatch
  config.rs · session_plan.rs · session_tuning.rs · pipeline.rs   session setup + the frame pipeline
  vdisplay/          per-compositor virtual outputs (kwin · gamescope · mutter · wlroots)
  capture/ · capture.rs    screen/dmabuf capture (+ Windows IDD-push)
  encode/ · encode.rs      per-GPU encoders (nvenc · vaapi · ffmpeg_win (AMF/QSV) · sw)
  linux/zerocopy/    dmabuf → CUDA → NVENC bridges (EGL/GL tiled, Vulkan LINEAR)
  inject/ · inject.rs      input backends (libei · wlr · uinput gamepads · UHID DualSense/DS4)
  audio/ · audio.rs        Opus out + virtual mic (PipeWire / WASAPI)
  gamestream/        Moonlight compat: nvhttp · pairing · rtsp · control · stream · gamepad · apps
  native.rs      the native punktfunk/1 host (QUIC control + native-thread UDP data plane)
  mgmt.rs · native_pairing.rs · stats_recorder.rs   management API, pairing, perf capture
  hdr.rs · library.rs      HDR metadata; multi-store game library
  linux/ · windows/  platform-confined backends

punktfunk-core — the shared protocol · FEC · crypto core
Clients — the apps that connect (Apple · Linux · Windows · Android · probe)
Packaging & docs — install & operate
punktfunk-planning (internal planning repo) — architecture rationale and deep-dive plans

README.md

punktfunk-host

What it does

Run it

Subcommands

Layout

Related