design/windows-parallel-virtual-displays.md (display-management Stage 7 / §6.6): N simultaneously-live pf-vdisplay monitors, one sealed ring each, every idd-push-security invariant preserved per-ring. - proto v3: SharedHeader._pad → target_id — the ring NAMES its monitor, host-stamped before the magic; the driver publisher refuses a cross-bound ring via the shared, unit-tested frame::check_attach (new DRV_STATUS_BIND_FAIL — the gamepad pad_index validation applied to frames, invariant #10); the host's wait_for_attach surfaces the refusal loudly and self-checks its own stamp. - manager: the one-monitor MgrState becomes a slot map keyed by the client's identity slot (0 = anonymous/GameStream); per-slot reconnect + dead-WUDFHost preempts, slot-scoped begin_idd_setup (a different identity is an admission question, never a preempt), ONE device-level watchdog pinger, per-slot /display/state + /display/release. - group topology: isolate_displays_ccd takes the managed target SET (a sibling slot is never deactivated); SavedConfig + the DDC/PnP axes move to the group record (first-in captures, last-out restores); desktop layout via CCD source origins from the pure layout::arrange (auto-row default, manual pins win), re-applied on create + reconfigure. - admission: the Windows separate→reject override now sits behind the PUNKTFUNK_WIN_SEPARATE=1 validation hatch (the wedge it guarded is structurally gone — a second identity gets its own monitor + ring; default flips in W5 after soak); max_displays and NVENC session-unit budgets decline an unaffordable display AT admission; kick_dwm_compose is process-globally throttled and per-display — cursor jump + 35 ms dwell (a sub-tick jump composes nothing; DWM reads dirties from current state at the next vsync tick). On-glass on the RTX box: V1/V2/V4/V5/V6/V9 green — two paired clients on two monitors streaming ~60 fps each with zero mismatches and zero bind failures, churn-hammer clean (no 0x80070490), per-ring mode-change recreate leaves the sibling untouched, typed budget rejection, fault-injected cross-bind refused loudly with the sibling undisturbed. V7: WUDFHost-kill shared fate is clean; in-process device recovery is a known follow-up (the retired-never-closed control handles block the adapter cycle — reset-pf-vdisplay.ps1 recovers). DWM composes two IDD monitors concurrently at 60 fps — the plan's load-bearing unknown, answered yes. Also carries the client-HDR EDID forwarding that shared this working tree (Hello::display_hdr → AddRequest luminance tail → the monitor's CTA-861.3 HDR block, PUNKTFUNK_CLIENT_PEAK_NITS hatch) and the Deck client fixes (40 ms rumble keep-alive with 1-LSB jitter, HDR self-diagnosing presenter warn, flatpak HDR env). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
punktfunk client — Flatpak (Steam Deck / SteamOS, and any flatpak distro)
The native Linux client — the shell (crate punktfunk-client-linux, binary
punktfunk-client) plus the Vulkan session binary it execs for streaming (crate
punktfunk-client-session, binary punktfunk-session) — is
published two ways by CI (.gitea/workflows/flatpak.yml), on every push to main (a rolling
<next-minor>-ciN.g<sha> build, base derived from the latest stable tag by
scripts/ci/pf-version.sh) and on v* tags (a clean X.Y.Z):
- Hosted OSTree repo at
https://flatpak.unom.io(recommended) — a GPG-signed Flatpak remote served by a static Caddy container on unom-1, so users install once and thenflatpak update. Shared unom-wide repo (remote nameunom), reusable by other unom apps under the same signing key. See "Install (recommended)" below. - Single-file
.flatpakbundle in Gitea's generic package registry (unomorg) — the no-remote fallback the Decky plugin consumes (stablelatest/punktfunk-client.flatpakURL) and the offline/manual path. On tags it's also attached to the Gitea release.
The host is NOT a flatpak (it needs unsandboxed
/dev/uinput+ zero-copy NVENC — see../README.md"Why not Flatpak"). Only the client is sandbox-friendly.
Why flatpak for the Steam Deck
SteamOS /usr is read-only and image-based, and the system is missing libadwaita and
libSDL3 — so a bare punktfunk-client binary dropped into ~/.local/bin won't run. Flatpak
is the Deck's native, update-survivable app path (the user already runs Moonlight and chiaki-ng
as flatpaks), and the bundle carries libadwaita (from org.gnome.Platform//50) + a bundled SDL3,
with HEVC-capable FFmpeg supplied automatically by the runtime's codecs-extra extension.
App id: io.unom.Punktfunk (matches the Apple bundle id family and the Decky plugin's
flatpak fallback).
Install (recommended): the hosted repo
One command adds the signed unom remote and installs the client; it auto-adds Flathub for the
GNOME runtime, and flatpak update tracks new builds from then on:
flatpak install --user https://flatpak.unom.io/io.unom.Punktfunk.flatpakref
flatpak run io.unom.Punktfunk
Equivalent two-step (add the whole remote, then install by app id):
flatpak remote-add --user --if-not-exists unom https://flatpak.unom.io/unom.flatpakrepo
flatpak install --user unom io.unom.Punktfunk
Updates — the whole point of the hosted repo:
flatpak update # or: flatpak update io.unom.Punktfunk
Install on the Deck via the bundle (no-remote fallback)
The generic registry is a plain HTTP file store, so just download the bundle and install it per-user (no root, survives SteamOS updates). This is what the Decky plugin uses; the hosted repo above is the better path for a human on the Deck:
# Pick a version: a tag like 1.2.3, or the newest main build's <next-minor>-ciN.gSHA.
VER=1.2.3
URL="https://git.unom.io/api/packages/unom/generic/punktfunk-client-flatpak/$VER/punktfunk-client-$VER.flatpak"
# Flathub must be enabled (it is on the Deck) so the GNOME runtime + codecs-extra extension pull in:
flatpak remote-add --user --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
curl -fL -o /tmp/punktfunk-client.flatpak "$URL"
flatpak install --user --bundle /tmp/punktfunk-client.flatpak
Run it:
flatpak run io.unom.Punktfunk # GUI host list (mDNS)
flatpak run io.unom.Punktfunk --connect HOST:PORT
The Decky plugin launches exactly this (flatpak run io.unom.Punktfunk --connect …) once
installed — see ../../clients/decky/README.md.
Updating the bundle install
If you installed from the bundle (not the hosted repo), it has no remote to track, so updates are "download the newer bundle and reinstall":
flatpak install --user --bundle /tmp/punktfunk-client.flatpak # same command, newer file
Installs from https://flatpak.unom.io instead just take flatpak update (see "Install
(recommended)" above).
Build locally / the CI fallback
CI builds this in a --privileged Fedora container, because flatpak-builder runs
bubblewrap, which needs user namespaces the default Docker executor denies. If the Gitea
runner can't grant --privileged (the job fails at flatpak-builder with
"Creating new namespace failed: Operation not permitted"), build it out-of-band and upload
by hand. The easiest place is on the Deck itself (it can run org.flatpak.Builder
user-scope, no root):
# On the Deck (or any flatpak box), one-time:
flatpak install --user -y flathub org.flatpak.Builder
# build-flatpak.sh auto-detects org.flatpak.Builder, generates cargo-sources.json (or reuses an
# existing one — see below), builds, and exports dist/punktfunk-client-<version>.flatpak:
bash packaging/flatpak/build-flatpak.sh
# Upload to the generic registry (PAT with write:package):
curl -fsS --user "enricobuehler:$REGISTRY_TOKEN" \
--upload-file dist/punktfunk-client-*.flatpak \
"https://git.unom.io/api/packages/unom/generic/punktfunk-client-flatpak/0.0.1-manual/punktfunk-client.flatpak"
cargo-sources.jsongeneration needspython3+aiohttp+tomlkit, which the Deck lacks. Generate it on a dev box (build-flatpak.shdoes it, or run the upstreamflatpak-cargo-generator.py Cargo.lock -o packaging/flatpak/cargo-sources.json), rsync it next to the manifest, andbuild-flatpak.shreuses it (it only regenerates when the file is absent orFORCE_GEN=1).
The Mac build host cannot build a Linux flatpak (no flatpak-builder for macOS), and home-worker-2 has no flatpak and no passwordless sudo to install it — so the Deck or the privileged CI container are the only two viable build sites.
Manifest
io.unom.Punktfunk.yml. Runtime org.gnome.Platform//50
(GTK 4.20 + libadwaita 1.8 ≥ the crate floors of v4_16 / v1_5), built on freedesktop-sdk 25.08,
with two build-time SDK extensions: org.freedesktop.Sdk.Extension.rust-stable (→ //25.08,
rustc 1.96 — the GTK4 dep chain, e.g. pango-sys 0.22, needs ≥ 1.92, which the EOL GNOME-48 /
24.08 rust-stable at 1.89 could not provide) and org.freedesktop.Sdk.Extension.llvm20 (libclang,
needed by bindgen in ffmpeg-sys-next / sdl3-sys). HEVC-capable libavcodec (soname 61, accepted by
ffmpeg-next 8.x) is supplied automatically at runtime by the freedesktop codecs-extra
extension point (auto-downloaded with the runtime; no app-side codec declaration). A bundled
SDL3 3.4.10 module (pinned to match sdl3-sys 0.6.6+SDL-3.4.10), and finish-args for Wayland +
--device=all (GPU/VAAPI render node + evdev + the hidraw char-devices SDL3 needs for DualSense)
--socket=pulseaudio(PipeWire-pulse: playback + mic) +--share=network. Alongside it:io.unom.Punktfunk.desktop,io.unom.Punktfunk.metainfo.xml,io.unom.Punktfunk.svg(all installed by the manifest). Avulkan-headersmodule supplies what the session binary's ash/Vulkan build needs.cargo-sources.json(the offline crate cache) is a pure function ofCargo.lock; CI regenerates it each build and it is gitignored — generate it on any box with network +python3/aiohttp/tomlkit(build-flatpak.shdoes this automatically) and, for a build host that lacks those (the Deck), rsync the generated file in alongside the manifest.
Offline Skia: the session binary's Skia console UI (pf-console-ui → skia-safe) normally
downloads prebuilt libskia binaries at build time, which is dead in the offline sandbox — so the
manifest pins a skia-binaries-….tar.gz source and points the build at it with
SKIA_BINARIES_URL: file://…. When bumping the skia-safe/skia-bindings crate version, update
that pinned tarball (URL + sha256) to the matching skia-binaries release or the build breaks
offline.
Hosting the repo (unom-1) + one-time setup
The OSTree repo flatpak-builder produces is GPG-signed in CI and rsynced to unom-1, where a tiny
static Caddy container (server/compose.production.yml + server/Caddyfile, port 3230)
serves the ./site tree (repo/ + unom.flatpakrepo + io.unom.Punktfunk.flatpakref +
index.html). The edge Caddy on home-reverse-proxy-1 fronts it at https://flatpak.unom.io.
The CI deploy step no-ops until the secret + infra exist, so it won't redden builds mid-setup.
Signing key: dedicated RSA-4096 key unom Flatpak Repo <flatpak@unom.io>. Public key committed
at unom-flatpak.gpg (its base64 goes into the .flatpakrepo/.flatpakref
GPGKey=); private key (ASCII-armored, then base64) lives only in the CI secret.
One-time setup (mirrors any new unom DMZ service — see the deploy-infra notes):
- Secret
FLATPAK_GPG_PRIVATE_KEYon this repo = base64 of the armored private key (gpg --armor --export-secret-keys <fpr> | base64 -w0).DEPLOY_*+REGISTRY_TOKENalready exist. - Edge Caddy on home-reverse-proxy-1 (
/home/caddy/caddy/Caddyfile, apply by hand +./reload.sh):flatpak.unom.io { reverse_proxy 192.168.50.50:3230 } - Port allowlist: add
3230tocaddy_target_portsinunom/infra(proxmox/unom-1) + terraform apply. - DNS: ensure
flatpak.unom.ioresolves to the edge proxy.
Re-signing/rotation: regenerate the key, replace unom-flatpak.gpg + the secret; every client must
re-add the remote (the GPGKey changed), so rotate rarely.
Alternatives considered
- Hosted OSTree repo (chosen): the only option that gives
flatpak update. We self-host the static tree on unom-1 behind Caddy (Gitea has no flatpak/ostree registry); the build already produces the repo, so the marginal cost is GPG signing + an rsync + a 10-line static container. - Generic registry bundle (kept as fallback): one curl to publish, one
flatpak install --bundleto consume; mirrors the deb/rpm curl-upload pattern. No auto-update — this is what the Decky plugin pulls (stablelatest/punktfunk-client.flatpak), plus the offline/manual path. - Release attachment: also done on tags, good for a human-facing download page.
- Flathub (deferred): best discoverability + zero hosting, but a separate submission/review process and less control; revisit once the client is past scaffold quality.