83 Commits

Author	SHA1	Message	Date
enricobuehler	1fcf9e11ec	fix(video): honor the signaled CSC matrix end-to-end + tvOS HDR presentation ... Clients derive Y'CbCr->RGB from the stream's SIGNALED matrix x range x depth via shared csc rows (Rust csc_rows + Swift CscRows) instead of hardcoded 709/2020 - a BT.601-signaled stream (a Linux host's RGB-input NVENC) no longer renders with a constant hue error. Host-side signaling made honest across NVENC/VAAPI/openh264/GameStream and the session plan's chroma/bit-depth. Decoded color-bar fixtures (601/709 x limited/full) pin the math in tests on both cores. Same presenter, tvOS HDR: tvOS has no Metal EDR API and a bare PQ colorspace tag composites UNTONE-MAPPED (the "overblown" Apple TV report), so HDR now splits on the display's live EDR headroom - PQ passthrough when the per-session AVDisplayManager mode switch landed (a real HDR10 output tone-maps itself), else an in-shader PQ->SDR tone-map (203-nit reference white, extended-Reinhard 1000-nit knee, 2020->709) into the proven SDR layer config. The 10-bit stream keeps its full decode depth either way. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 16:59:01 +02:00
enricobuehler	d1770c3476	refactor(host): shared send-pacing policy for the native and GameStream video planes ... Networking-audit deferred plan §5. Both planes spread a frame's wire packets across a time budget in chunked bursts; the schedule logic, PUNKTFUNK_VIDEO_DROP loss injection, and percentile helper were duplicated between punktfunk1::paced_submit and gamestream::stream::spawn_sender. Now one host-local send_pacing::pace_frame carries the policy; each plane keeps its exact historical parameterization and its own syscall layer (GSO Session vs sendmmsg over the RTP socket — policy shared, plumbing not): native burst_bytes = PUNKTFUNK_PACE_BURST_KB (microburst stage), fixed 16-packet chunks, budget = 0.9 × time-to-deadline gamestream no burst stage, bounded steps (≤ 12, chunk ≥ 16, the old pace_layout), fixed budget = 0.75 × frame interval Deterministic-schedule unit tests pin both parameterizations against verbatim transcriptions of the legacy math (burst split, chunk layout, step counts — including pace_layout's historical test anchors) and the sleep-target formula (GameStream's legacy per_step form agrees to ≤ steps/2 ns; the unified fraction form is used for both). Deliberate sub-observable normalizations, all on test-knob or ns-scale paths: PUNKTFUNK_VIDEO_DROP is now parsed once per process and clamped to 1..=90 on the GameStream plane too (was per-stream, unclamped), and the native sleep floor comparison is now >= (was >, differs only at exactly 500 µs). Validation: - 263 host tests green, incl. the end-to-end sender_delivers_batches (spawn_sender → pace_frame → sendmmsg, byte-identical delivery) - PUNKTFUNK_VIDEO_DROP FEC sweep at 5 % and 8 % injected wire loss: all 11 punktfunk1 integration tests (full host↔client roundtrips through send_loop → paced_submit) recover and pass - pending: one real Moonlight smoke session against this build (the legacy-plane timing gate) — recipe handed to the operator Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 16:26:41 +02:00
enricobuehler	dd73ae2469	fix(host): fresh random per-session nonce salt instead of the static "pkf1" ... Every session sealed with the literal salt b"pkf1", so GCM nonce uniqueness (nonce = salt || sequence) rested ENTIRELY on the per-session key being fresh — correct today, but a single key-reuse bug anywhere in the handshake path would have meant immediate catastrophic nonce reuse instead of merely a wrong key. Random salt per session keeps the documented second line of defense real. The salt is negotiated via Welcome, so every deployed client just follows — no wire or compat change. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 14:55:51 +02:00
enricobuehler	7ab97bb1a3	feat(host): capture-stall watch — DWM-level self-diagnosis for the Exclusive-topology stutter ... Field repro (Mounjay, still present on 0.9.0): the ~4 s double-jolt stutter appears ONLY while the virtual display is the sole active display (Exclusive topology) and stops the instant Windows switches to Extend — live, both ways. Cross-project research (Apollo #179/#358/#368/#563/#776, VDD #36, Tom's HW) points at the display/present path BELOW capture: an inactive-but-connected DisplayPort head being periodically serviced (standby HPD/AUX/link events), with a DWM software-vsync clock beat as the secondary (different-signature) class. Neither ends in anything our recovery-side detector can see unless the client actually loses data — so give the HOST a direct sensor at the ring: - StallWatch (idd_push.rs): a >150 ms hole in DWM frame delivery counts as a capture stall only when the 8 preceding frames arrived within 400 ms — sustained >=20 fps flow, so an idle desktop, a caret blink, or a paused video can never trip it. Per-stall debug line; when stalls settle into an evenly-spaced multi-second cycle, one rate-limited WARN names the class: 'capture stalls are METRONOMIC', with the topology=primary/extend and refresh-rate leads. Ring-recreate recovery gaps reset the watch (self- inflicted, already logged by the recreate path). - The evenly-spaced-cycle detector moves out of punktfunk1.rs into metronome.rs (RecoveryCadence -> Metronome, unchanged logic + tests) so the IDR-serve detector and the stall watch share one implementation; the recovery WARN now cross-references the capture-stall lines. Diagnosis map for an Exclusive-mode stutter log: 'slow display-descriptor poll' = something holds the win32k display lock; 'capture stalls are METRONOMIC' without it = DWM stopped composing (DP servicing / present clock, below us); recovery-IDR METRONOMIC alone = frames flowed but clients lost data. Verified: Linux tests+clippy+fmt clean; Windows (RTX box) 220/220 + clippy clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 11:05:21 +02:00
enricobuehler	7b25868a19	fix(input): rock-solid held gamepad state — Android device pinning + seq'd snapshots ... Two causes behind one field report (a held trigger jittering mid-game, Android client → Windows host): Android folded joystick ACTION_MOVEs from EVERY device into one axis state. A controller's joystick-classified sibling node (DualSense/DS4 motion sensors) or a second/drifting pad reports every pad axis as 0, so a held trigger flapped value→0→value on each event interleave. The mapper now qualifies the source DEVICE (its source classes must include GAMEPAD — a joystick event's own source is always plain JOYSTICK), pins to one deviceId until that device disconnects, and merges LTRIGGER/BRAKE (and RTRIGGER/GAS) with max, the same fold as the Controllers probe. Underneath, gamepad input rode per-transition events over unreliable, unordered QUIC datagrams — no sequence numbers, sharing the 4 KiB oldest-first-shed send buffer — so one dropped or reordered event corrupted held pad state until the NEXT change. Gamepad state now travels the way rumble already does: idempotent state, refreshed. InputKind::GamepadState packs the whole pad + a wrapping u8 seq into the existing 18-byte layout; the host advertises HOST_CAP_GAMEPAD_STATE (Welcome trailing byte, offset 67) and applies snapshots through a per-pad stale-seq gate, skipping frame emits for unchanged refreshes; the client folds embedder events into snapshots inside NativeClient's input task (send on change + 100 ms refresh of touched pads), so the SDL clients (Linux/Windows/session), Android, and Apple (C ABI) are all covered with zero capture-code changes. Either end older ⇒ the legacy per-transition path runs unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 01:11:38 +02:00
enricobuehler	47d22b6082	fix(host): admit exactly ONE parked knock per Approve — stop crashing gnome-shell, and self-heal dead sessions ... A retrying unpaired client parks one QUIC connection per knock, but the delegated-approval waiters were keyed on fingerprint alone — one console Approve resolved ALL of them. Observed live (2026-07-10): an iPad knocked 3x, one Approve admitted three full sessions, three Mutter virtual monitors were created within ~200us plus an ApplyMonitorsConfig, and gnome-shell SIGSEGV'd inside meta_monitor_manager_rebuild — dropping the box to the GDM greeter, unreachable until reboot (GDM auto-login runs once per boot) while the lingering host spammed "RemoteDesktop ... not activatable" libei errors. Four fixes, outermost symptom inward: - Knock generations (native_pairing): note_pending returns a per-knock generation; a re-knock bumps it and wakes the previous waiter, which resolves the new PairingDecision::Superseded (connection closes; the console list is unchanged). An approval records WHICH generation it admitted, so a stale waiter polling only after the pending entry is cleared still loses the tie — exactly one admission, no matter the interleaving. - TOPOLOGY_LOCK (vdisplay/mutter): every Mutter monitor mutation (pre-snapshot -> RecordVirtual -> ApplyMonitorsConfig, and the teardown Stop) is serialized process-wide. Concurrent rebuilds are what segfault the shell (second on-glass crash of this class — the teardown race is already documented in-file), and serialization also keeps wait_virtual_connector's snapshot diff from attributing a sibling's connector. Create timeout 20s -> 45s for lock queueing. - Session-env hygiene (vdisplay): when detection finds NOTHING live, clear the previous connect's XDG_CURRENT_DESKTOP/WAYLAND_DISPLAY retarget. A stale GNOME value kept mutter::is_available() true after the crash, routing explicit-backend connects into the dead session (create timeouts + libei error loops) instead of the crisp "no live graphical session" handshake error. - Opt-in recovery hook (config + punktfunk1): PUNKTFUNK_RECOVER_SESSION_CMD fires (detached via sh -c, debounced to one launch/min) when a client connects while no graphical session is live — e.g. `sudo -n systemctl restart gdm` re-runs auto-login and the client's retry lands in the recovered desktop. The handshake error tells the client to retry. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 01:10:26 +02:00
enricobuehler	a1285dfa13	fix(host): IDD capture immune to display-config stalls/flaps + metronomic-recovery self-diagnosis ... Field report (0.8.2→0.8.4): metronomic stutter every ~3.7-4 s, each event a double-jolt, on ALL clients — and the same box stuttered on Apollo (virtual display) but not Sunshine (physical). The disturbance class is host-side display-topology events / display-poller software (SteelSeries-GG class, Apollo #480/#358/#368) hitting the virtual-display path. Three changes make the IDD path resilient to it and self-diagnosing: - DescriptorPoller: the display-descriptor CCD queries (QueryDisplayConfig twice per sample) serialize on the session-global display-config lock, which topology churn and display-poller software can hold for tens-to- hundreds of ms. Polled inline, that stall landed ON the capture/encode thread 4x/s — a periodic frame hitch, invisible in any log. A dedicated thread now samples every 250 ms and publishes a snapshot; the capture loop pays one uncontended mutex read, and a sample slower than 50 ms logs a rate-limited warn — the stall is measured instead of streamed. - Flap immunity: advanced_color_enabled returns Option (None on a failed query or the target briefly missing from the active paths during a re-probe) and the poller keeps last-known-good per field — a transient no longer reads as "HDR off", which used to cost an HDR session TWO spurious ring recreates (false, then true again a poll later). On top, a two-strikes debounce: only two consecutive samples agreeing on the same new descriptor trigger the recreate; a real "Use HDR" flip or game mode-set still lands in ~1/2 s. - RecoveryCadence: served recovery IDRs within 1.5 s coalesce into one event (a double-jolt's paired IDRs count once); four consecutive events evenly spaced (±20%) warn "client keyframe recoveries are METRONOMIC — a periodic host/display disturbance, not random network loss" with the measured period (re-warn ≤ every 30 s) — so an affected host self-diagnoses in its own log / web console instead of reporting "nothing in the logs". Unit tests include the field report's exact double-jolt-pair schedule. Verified: host tests + clippy clean on Linux and on the RTX box (211/211, --features nvenc). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-09 20:42:58 +02:00
enricobuehler	5d9f1ccb6d	feat(host): --no-mdns/PUNKTFUNK_MDNS gate + punktfunk1-host --pairing-pin — docker-testing enablers ... mDNS advertisement (native _punktfunk._udp AND GameStream _nvstream) can now be disabled with --no-mdns on serve/punktfunk1-host or PUNKTFUNK_MDNS=0 (the PUNKTFUNK_ZEROCOPY off-grammar) — for multicast-dead environments (bridged Docker, CI netns) where the advert reaches nobody or fails outright and aborts the GameStream plane; clients dial a manually-added host instead (mDNS-blind host-add works since the 0.8.4 dial-first fix). Unit tests no longer advertise on the LAN (mdns: false). punktfunk1-host gains --pairing-pin <PIN> (the already-plumbed fixed-PIN test seam, now CLI-exposed; empty refused like --mgmt-token) so a CI harness runs a deterministic SPAKE2 ceremony instead of scraping the logged PIN. Verified live: --no-mdns + PUNKTFUNK_MDNS=0 skip the advert, --pairing-pin arms with the fixed PIN, and a punktfunk1-host --source synthetic + punktfunk-probe loopback run passes verification (60/60 frames, 0 mismatch). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-09 18:43:15 +02:00
enricobuehler	d0f68cbbcd	feat(core,host): per-family MTU shard sizing — the IPv6 gating item ... Phase 1 of the dual-stack plan (design/client-parity-and-network-resilience.md, plan 5): the host sizes each session's shard_payload from the QUIC remote's address family instead of assuming IPv4 — 1408 over v4 (unchanged), 1388 over v6 (40-byte header). Rides the existing Welcome::shard_payload negotiation, so there is zero wire change and old clients simply follow. This has to land before any v6 data path exists: the v4-maximal 1408 makes every sealed video datagram overshoot a 1500-MTU IPv6 hop, and v6 routers never fragment — that's a blackhole (every datagram dropped), not the graceful-ish degradation of the b5c30df v4 fragmentation saga. IPv4-mapped v6 remotes (::ffff:a.b.c.d, what a dual-stack [::] socket reports for a v4 client) correctly keep the v4 size — they ride IPv4 on the wire. New mtu1500_shard_payload_v6()/mtu1500_shard_payload_for() in core config with the same pinned never-fragments/maximality tests as the v4 constant, plus a family-selection test. Verified: 82 core lib tests + loopback/c_abi green and host check/clippy clean on Linux (home-worker-2); core tests green on macOS. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-09 11:35:28 +02:00
enricobuehler	8e6e8bb25c	feat(core,host): adaptive bitrate — mid-stream encoder re-targeting when set to Automatic ... New SetBitrate (0x05) / BitrateChanged (0x06) control messages: the host clamps like the Hello request, acks the resolved rate, and rebuilds the ENCODER ONLY in place (same mode, first new-rate frame is an IDR — the proven mode-switch resync, minus the pipeline churn). The client side is an AIMD controller (core abr.rs) in the data-plane pump, armed only when the user's bitrate is Automatic (Hello bitrate_kbps == 0): ×0.7 after two bad 750 ms windows (FEC-unrecoverable frames, ≥2% loss, one-way-delay rise above its rolling baseline — the pre-loss bufferbloat signal off the clock-skew handshake — or a jump-to-live flush), ~+6% after ~10 s clean, ceiling = the session's starting rate, 3 s cooldown, self-disables against a host that never acks (older build). Division of labour: adaptive FEC keeps answering fast random loss; bitrate now answers persistent congestion, closing the FEC death-spiral gap. The web-console sample reports the live rate. Also: join_host_port() brackets bare IPv6 literals before SocketAddr parsing (parse-side IPv6 groundwork, pairs with the next commit). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-09 10:57:41 +02:00
enricobuehler	2003d8a75c	style(host): rustfmt the bit_depth ternary in serve_session ... Collapse the manually-wrapped if/else to rustfmt's canonical form; fixes the cargo fmt --all --check CI failure at punktfunk1.rs:895. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-08 22:07:54 +02:00
enricobuehler	838a1239cf	feat(codec): make client codec selection real — GPU-aware native advertisement ... The clients' codec pickers sent a preference the host threw away: host_wire_caps() hardcoded HEVC for every GPU backend, so the native path never emitted H.264/AV1 regardless of what the user chose. Host: advertise what the backend actually encodes, mirroring the GameStream serverinfo logic — software openh264 emits H.264; probed backends (Linux VAAPI, Windows AMF/QSV) advertise their per-GPU CodecSupport via the new wire_mask(); NVENC keeps the Moonlight-validated H.264|HEVC|AV1 static superset; an empty probe falls back to the superset so auto clients still resolve HEVC. Gate 10-bit to HEVC (like the 4:4:4 gate) now that a client can steer the codec — Main10 is the only 10-bit encode path. Fix the web-console stats label hardcoded to "hevc" (new Codec::label(), shared with the GameStream register_session mapping). Android: replace the hardcoded H264|HEVC Hello advertisement with a videoCodecs param fed by VideoDecoders.decodableCodecBits() (AV1 bit only when a real hardware video/av01 decoder exists — the decode loop was already mime-driven); offer AV1 in the codec picker on capable devices. Decky: add the missing "Video codec" dropdown (auto/hevc/h264/av1) to the plugin settings, round-tripping the same codec key the flatpak client reads. Apple: unchanged by design (AnnexB.swift is NAL-only, AV1 is never advertised); refresh the stale "hosts don't emit AV1 on the native path yet" comments here and host-side. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-08 16:45:37 +02:00
enricobuehler	0b7e4a00ee	fix(host): crash visibility + Windows deliberate-quit teardown; pin outranks quit ... Two strands from the "Windows host went Offline after reconnect, zero errors in the logs" investigation. Crash visibility — the field reports kept arriving with nothing in the Logs tab because every way the host can die silently was unlogged: - A panic hook tees each panic (thread, location, backtrace) through `tracing` into the in-memory ring + host.log before the default hook runs — a panicking thread otherwise only hit stderr, absent from the web console and gone when stderr is detached. - A last-resort Windows SEH filter (windows/crash.rs) logs an unhandled native exception with its code, faulting address, and faulting MODULE — the smoking gun that separates our bug from a GPU runtime/driver DLL (amfrt64, the UMD, d3d11) crashing under us. - A 10 s watchdog around the vdisplay monitor teardown logs an ERROR when the driver REMOVE/CCD-restore looks wedged (it runs under the manager state lock, so a hang there silently blocks every future acquire). Deliberate-quit teardown (Windows pf-vdisplay) — the Windows manager never wired the linger skip the Linux registry has: on ⌘D (the QUIT close code) the monitor lingered 10 s, so a quick reconnect hit the Lingering-preempt's back-to-back REMOVE→ADD churn. A per-lease quit flag (VirtualDisplay:: set_quit_flag) now tears the monitor down immediately on a deliberate quit, so the reconnect finds the manager Idle and does a clean fresh ADD. Pin outranks quit (both platforms) — keep_alive=forever (the gaming-rig preset) promises "the screen stays alive", so a deliberate quit must skip only the linger WINDOW, never the pin. Windows release() checks keep_alive_forever() before the quit; the Linux registry had the inverse bug (force_immediate tore down even a pinned display) — fixed via effective_linger() with a unit test. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-08 14:17:01 +02:00
enricobuehler	a41f679516	perf(host): one input channel — motion applies on arrival, not after the 4 ms tick ... Rich input (gyro at the pad's report rate, trackpad contacts) rode a second mpsc channel that the input thread only drained after its main channel's 4 ms recv timeout — so during pure-gyro aiming (no button/pointer traffic, the common case) every motion sample ate up to 4 ms of added latency and quantization before reaching the virtual pad. At the Deck's 250 Hz sensor cadence that is a full sample period of jitter. Both planes now share one ClientInput channel: the thread wakes the moment either arrives and applies rich input immediately. The 4 ms timeout stays as the feedback-pump tick. Also adds a debug-level motion-cadence metric (inter-arrival p50/p95/max per 5 s window) so gyro delivery is measurable end-to-end instead of 'feels floaty'. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-08 10:51:04 +02:00
enricobuehler	e6d9454251	feat(host): fold Steam Deck to DualSense on Windows; split-pad touch + pad clicks ... A Deck client asking for 'steamdeck' on a Windows host resolved to Xbox360, whose apply_rich is a no-op — gyro and both trackpads silently discarded. Windows already ships a full DualSense backend (UMDF driver, touchpad + motion, wire units 1:1), so pick_gamepad now folds SteamDeck -> DualSense there. The three near-identical DualSense-family appliers (Linux UHID, Windows DualSense, Windows DS4) are hoisted into one shared dualsense_proto::DsState::apply_rich, with two mapping upgrades for Steam dual-pad clients everywhere: * the Deck's two pads SPLIT the single DualSense touchpad — left pad -> contact 0 on the left half, right pad -> contact 1 on the right half — mirroring the physical thumb layout and the split-pad zones games and Steam Input already use (the left pad was previously dropped outright) * TouchpadEx pad clicks now press the touchpad-click button (persisted in DsState::touch_click, OR-ed in by both serializers; previously dropped by every DualSense-family backend, Linux included) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-08 10:50:53 +02:00
enricobuehler	a5bb5ec4d5	fix(input): pointer lock + the missing per-iteration motion flush ... Two capture bugs compounding into 'sluggish and not captured': 1. flush_motion was never called from the run loop — the GTK client's frame-clock tick flushed pending motion every frame, and the port lost it. Pure mouse movement only reached the host when a click/key/ scroll happened to flush it; the host cursor simply didn't follow. Now one coalesced MouseMove per loop iteration. 2. Capture forwarded ABSOLUTE letterboxed coordinates with no pointer confinement (GTK parity, the plan's deferred 'stage-2' item): the visible local cursor outran the host cursor by the full e2e and escaped the window. Capture is now real pointer lock — SDL relative mouse mode (hidden, confined, raw deltas) with relative MouseMove on the wire, so the host cursor is the only cursor. Also: focus-gain re-engages after an auto-release (Alt-Tab undoes itself; the startup focus race can no longer strand the session uncaptured) while a chord release stays released until the user opts back in. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-07 23:14:08 +02:00
enricobuehler	a1b890ef42	fix(host): coalesce keyframe-request storms into one IDR per cooldown ... Clients request a keyframe on every FEC-unrecoverable frame and keep asking until the IDR actually arrives and decodes — a full round-trip on a link that is already behind. The host answered every request with a full IDR and only rate-limited under intra-refresh (opt-in, off by default), so on the default path a Wi-Fi loss burst produced a 20-40x bitrate spike storm that deepened the very loss it was recovering from — the second half of the periodic double-jolt. Coalesce a request storm into at most one forced IDR per cooldown ALWAYS: serve the first immediately (a genuinely wedged decoder still recovers at once), then suppress for the window (2 s under intra-refresh's healing wave, 750 ms for a full-IDR recovery — long enough to swallow one recovery event's round-trip echo, short enough to re-issue a lost IDR promptly). Seed the cooldown at session open and stamp it on both rebuild paths so the cold-open / post-rebuild storm coalesces into the IDR the fresh encoder already emits. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-07 16:18:30 +00:00
enricobuehler	636b9c1d1f	Merge remote-tracking branch 'origin/main'	2026-07-07 06:15:21 +00:00
enricobuehler	92f078adaf	fix(host): survive Bazzite's SDDM session supervisor in the gamescope takeover ... Diagnosed live on the .181 Bazzite F44 box (couldn't connect at all; field reports of streams dying after 30 s-5 min): Bazzite autologs into game mode via SDDM with Relogin=true, so the moment the managed takeover stops gamescope-session-plus@<client>, SDDM logs back in and restarts it within the same second. The resurrected autologin session then fights our transient session-plus over the Steam single instance and the GPU for the whole stream: its wrapper relaunches gamescope every ~7 s (each one missing the wrapper's hard 5 s readiness window on a slow NVIDIA init), the churn SIGSEGVs gamescopes, and eventually the streaming gamescope dies with it. Meanwhile a client that gave up left the pipeline-rebuild retry loop SIGKILLing and relaunching the box's Steam session for up to ~6 more minutes. - stop_autologin_sessions: runtime-mask each autologin unit before the SIGKILL stop, so no supervisor can restart it underneath the stream; match every loaded instance (the unit flaps through activating/failed mid-churn). Every restore path unmasks unconditionally (including the desktop-active early return), and --runtime keeps the mask in tmpfs so a reboot clears it. - launch_session: supervise the transient unit while polling for the node — the session-plus wrapper kill -9s a gamescope that missed its 5 s readiness handshake and exits 1, so relaunch it (after a short driver-settle cooldown) instead of waiting the rest of the 45 s on a corpse. - build_pipeline_with_retry: abort between attempts once the session's QUIC connection is closed — no more minutes of Steam churn for a departed client. Validated live on .181: cold-boot connect streams 2059 frames/45 s (p50 5.1 ms), zero SDDM resurrections while masked, TV session restored+unmasked on disconnect, warm same-mode reconnect reuses the session (866 frames/15 s). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-07 06:15:12 +00:00
enricobuehler	eea23c5647	fix(core,host): make the native data plane survive real Wi-Fi links ... Root-caused live on a phone at 100 Mbps (stream stuck seconds behind, then oscillating): a stack of transport defects, each amplifying the next. - MTU-safe shards: shard_payload 1452 overshot the IPv4/1500 budget (the old math forgot the 40 B header + 24 B crypto ride inside the UDP payload and counted IP+UDP as 8 B) — the kernel silently split EVERY video datagram into two IP fragments, doubling per-datagram loss on Wi-Fi. New config::mtu1500_shard_payload() = 1408 (1472 sealed = the exact ceiling), negotiated in the Welcome, pinned by a unit test. - Android batched I/O: recv/send batching was cfg(linux); Android is target_os="android" and silently fell back to a syscall per datagram. The libc crate binds neither recvmmsg/sendmmsg nor mmsghdr for Android, so a local bionic extern binding provides them (API 21+, floor is 28); cbindgen excludes them from the C header. The pump/runtime threads also get the Apple-QoS analogue on Android: nice −8 (below the decode thread's −10). - Latency-bounded receive: packets are consumed strictly in order at exactly the arrival rate, so a standing queue (Wi-Fi stall, power-save clumping) NEVER drains — observed as a stream permanently 6-7 s behind with both 32 MB socket buffers full. The pump now flushes the entire backlog (Session::flush_backlog: discard ring + kernel queue at memcpy speed, reset the reassembler) and requests a keyframe when frames keep completing > 400 ms behind the skew-corrected capture clock (30 consecutive, 2 s cooldown, logged). - Time-based loss window: the reassembler declared an incomplete frame lost a fixed 4 INDICES behind the newest — 33 ms at 120 fps, inside normal Wi-Fi retry/reorder timescales, so merely-late frames were pruned every few seconds, each costing a recovery-IDR burst + an inflated loss report. Now 120 ms of capture time (LOSS_WINDOW_NS), same fuse at every refresh rate, with a 64-index hard cap bounding memory against hostile pts. - Adaptive-FEC hysteresis: the controller was memoryless — one clean 750 ms report dropped FEC from 8 % straight back to the 1 % floor, so periodic burst loss (Wi-Fi scan / BT coexistence beats) always hit an unprotected stream and ping-ponged 1↔8 % with a frozen frame per cycle (observed in the host log as alternating loss_ppm=0/50000). Attack stays instant; decay is now one point per clean report. Verified: full core suite (incl. new flush + time-window tests) on macOS + Linux, host release build, arm64 cargo-ndk build, and a 30 s wired probe run at 2800x1260@120 — 3559/3559 frames, zero loss, capture→received p50 5.3 ms (host 5.1 + network 0.3). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-07 07:35:08 +02:00
enricobuehler	eaaf176adf	style: rustfmt drift from the AMF/watchdog commits ... `cargo fmt --all --check` (a CI gate) failed on main: config.rs (the new `zerocopy: val(...).map { !matches!(...) }` from 76bc7fe) and punktfunk1.rs (the `reset_stalled_encoder` conditions from 167d590) were left unwrapped by the pinned rustfmt. Pure reformat, no semantic change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-06 13:00:23 +00:00
enricobuehler	167d590349	fix(host): encode-stall watchdog — heal the silent AMF/QSV freeze in place ... Field reports: Windows AMD/Intel streams freeze after ~3-5 min regardless of desktop activity. Root cause: the libavcodec AMF/QSV poll is non-blocking (EAGAIN -> Ok(None)), and the encode loop's drain treated None as benign without popping `inflight` — a wedged driver (QueryOutput stops producing) meant frames kept being submitted, inflight grew unboundedly, no AU ever reached the send thread, and nothing logged: a silent permanent freeze. The input-side twin: once libavcodec's one-frame buffer fills, avcodec_send_frame EAGAINs and the submit `?` killed the whole session. Add `Encoder::reset()` (in-place encoder rebuild; implemented for AMF/QSV by dropping the wedged libavcodec encoder so the next submit re-opens it on the current device, forced IDR) and an encode-stall watchdog in the stream loop: trip on a poll error, on no AU within max(2 s, 8 frame intervals) while frames are owed, or on an owed backlog worth more than the window's frames (the slow-leak latency-runaway form). Recovery is a bounded (5 consecutive, cleared by any delivered AU) in-place rebuild + forced IDR — a logged ~one-second hiccup instead of a dead stream; exhaustion or a reset-less backend still fails the session with a clear error. Submit failures route through the same bounded recovery. The three existing pipeline-rebuild paths (session switch, mode switch, capture loss) now also clear the stale in-flight records that pointed at the dropped encoder. Backends whose poll blocks (direct NVENC sync, software) can't false-trip: they never return Ok(None) mid-stream and drain inflight below depth each tick. Validated: clippy -D warnings (nvenc,amf-qsv), 191 host tests, synthetic E2E 300/300 frames, and an on-glass AMD iGPU session (1080p120 HDR hevc_amf). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-06 14:36:29 +02:00
enricobuehler	622c8bf701	fix(host): silence write-only cur_node_id on non-Linux encoder builds ... cur_node_id (the capture 5-tuple's node id, added for the Linux dedicated- game-exit check) is read only under #[cfg(target_os = "linux")], so on the Windows nvenc/amf-qsv build it was assigned but never read — failing `clippy -D warnings`. Read it on non-Linux platforms (the `let _ = &launch` idiom already used in this file). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-06 10:49:45 +00:00
enricobuehler	1992eb1c52	feat(host): game-mode integration + dedicated game sessions ... Implements design/gamemode-and-dedicated-sessions.md (Parts A1-A5 + B0-B2): reconciles the merged display-management registry with session-mobile Bazzite/SteamOS hosts and adds a per-launch dedicated gamescope mode. - A1 DisplayOwnership {Owned,External,SessionManaged} + poolable_now(): the registry pools only what it owns, so gamescope managed/attach outputs are no longer double-owned by the registry AND the gamescope restore worker (fixes the game-mode-reconnect stale-node wedge). - A2 validated reuse: (backend,mode,launch,epoch) reuse key + kept_display_alive liveness probe + reused_gen/mark_failed on a reused-display first-frame failure. - A3 policy-driven managed restore (keep_alive replaces the hardcoded 5s debounce; forever = held = gaming-rig truthful) + crash-restore persist + SIGKILL teardown (kill_unit, applied to our transient unit AND the autologin stop -- validated live on .181 to avoid the F44 GPU-context leak). - A4 session epoch: observe_session_instance bumps the epoch + invalidate_backend on a desktop-compositor instance change; gamescope spawns are exempt. - A5 per-spawn log + PID-scoped gamescope node discovery. - B0 game_session {auto,dedicated} policy (top-level, preset-orthogonal) + pick_gamescope_mode dedicated_launch + steam -silent command shaping. - B1 free the autologin Steam before a dedicated Steam spawn (single-instance). - B2 game-exit -> APP_EXITED_CLOSE_CODE (0x52) clean session end. Adversarially reviewed (11 findings fixed). Validated on glass (.181 Bazzite F44, RTX 4090): dedicated spawn streams a real game smoothly; keep-alive reuse; the SIGKILL fix avoids the F44 vkCreateDevice leak. Workspace green (build / test --workspace / clippy -D warnings / fmt), OpenAPI + C header regenerated, web console tsc + vite build green. clients/probe: bump the no-video timeout 8s->45s for gamescope cold starts. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-06 10:33:43 +00:00
enricobuehler	07c8b868e6	style(host): cargo fmt --all (rustfmt 1.9.0 drift) ... The CI image's rustfmt reformats these files (multi-line assert!/tracing! macros, match-arm and struct-variant wrapping) — pre-existing drift that the Format job caught. Reformat to match. Pure formatting; no logic change. main.rs also gets a blank line before a standalone comment so rustfmt stops mis-indenting it as a trailing-comment continuation. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-05 19:29:28 +00:00
enricobuehler	7fb75e6922	test(punktfunk1): serialize in-process-host tests (shared admission table) ... The reconnect-preempt (e8531a9, preempt_same_identity) reads the process-global admission table and signals same-identity live sessions. The three in-process-host tests each bind a fixed loopback port and share that ONE table, so running them concurrently let one test's connection preempt + close another's live session — an intermittent `next_au: Closed` in c_abi_connection_roundtrip (surfaced under full-workspace load; a lucky pass hid it at e8531a9). Serialize them on a poison-tolerant lock. Test-isolation only — in production a host is one process with unique client certs, so same-identity preempt is correct. Full workspace `cargo test` now green (18 suites, 3× clean). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-05 18:09:59 +00:00
enricobuehler	e8531a9eac	feat(vdisplay): harden keep-alive reconnect — same-client preempt, quit-skips-linger, configurable idle ... On-glass testing (Test 2, KWin .116) surfaced that a reconnect within the QUIC idle-timeout window (~8s) lands on a fresh SECOND display instead of reusing the kept one: the old session was still Active (not yet Lingering), so the registry's keep-alive reuse (which only matches Lingering) skipped it and the old session kept streaming to nobody. Three fixes: #3 Same-client reconnect preempt (the real fix): admission::preempt_same_identity() lists a reconnecting client's OWN still-live session(s) (same cert fingerprint); serve_session signals their stop + waits the release grace BEFORE acquiring, so the zombie tears down → its display lingers → the reconnect REUSES it instead of making a second. Implements the "preempts downstream" the admission docs already promised. Independent of the mode_conflict policy; the pure core (same_identity_stops) is unit-tested. #2 Deliberate quit skips linger: a client that deliberately disconnects closes the QUIC connection with QUIT_CLOSE_CODE (0x51, shared in core::quic); the host reads the ApplicationClosed reason and tears the display down immediately (registry release() gained force_immediate → Linger::Immediate; multi-session-safe via the pure lifecycle machine), while a bare disconnect still lingers for reconnect. Threaded via a session quit flag → the DisplayLease. NativeClient::disconnect_quit() + punktfunk-probe --quit drive it; GameStream (Quit App / h_cancel) is a documented follow-up. #1 Configurable disconnect-detection latency: the QUIC control-connection idle timeout (stream_transport, 8s default) is host-tunable via --idle-timeout-ms / PUNKTFUNK_IDLE_TIMEOUT_MS, clamped >=1s with a keep-alive that scales to it so a live session never false-closes. Default unchanged (8s stays load-bearing for the Windows IDD-push reconnect flow). Workspace check + 63 core / 215 host / 47 vdisplay tests green; clippy clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-05 16:41:06 +00:00
enricobuehler	5c6ae43ed2	feat(punktfunk1): configurable data-plane UDP port (--data-port) ... The native data plane used a random ephemeral UDP port (hole-punched), which a strict firewall can't pre-open — so remote clients behind one couldn't connect. Add an optional fixed data port: - `Punktfunk1Options`/`NativeServe` gain `data_port`; `bind_data_socket` binds the fixed port (→ direct, no hole-punch) or falls back to a random port + hole-punch when unset or the fixed port is busy (a concurrent session already holds it). - `UdpTransport::from_socket`/`from_socket_punch` adopt an already-bound socket, so the host keeps the SAME data socket from handshake through streaming — no drop-then-rebind window in which a concurrent session could steal a fixed port. - `main.rs` wires the CLI flag through to `NativeServe`. - Firewall docs updated (troubleshooting.md + apt/pacman/bazzite READMEs): control plane is the fixed UDP 9777; the data plane is a separate random port that usually needs no rule, with the fixed-port option for strict firewalls. Unit-tested: default random+hole-punch, and fixed-port-then-fallback-when-busy. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-05 13:53:54 +00:00
enricobuehler	6ddce1049b	feat(vdisplay): finish Stage 4 — typed reject, Windows join-default, GameStream 503 ... Completes the mode-conflict admission surface deferred from the initial Stage 4: - REJECT now delivers the reason to the client: punktfunk/1 closes the QUIC connection with a distinct BUSY code (0x42) + the 'host busy: streaming WxH@Hz to <client>' string, which the client reads from ApplicationClosed (validated on loopback: the probe logs 'closed by peer: host busy … (code 66)'). - Windows default: separate (incl. the unconfigured default) resolves to JOIN — the Windows native host admits a second client at the live mode instead of the old silent last-wins reconfigure of the shared monitor (release-note behavior fix; the reconfigure is now opt-in as steal). separate stays multi-view on Linux. - GameStream 503: h_launch tracks the session owner fp (LaunchSession.owner_fp, kept [u8;32] for Copy) and applies the policy when a DIFFERENT paired client launches — reject → 503 (Moonlight 'host busy'), join → serve the live mode, steal/separate → take over. Same-client re-launch is never a conflict. Native reject-reason loopback-validated; Windows join-default pending .173 rebuild; GameStream 503 pending a Moonlight client (can't drive /launch autonomously). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-05 10:34:49 +00:00
enricobuehler	bc7cb04338	feat(vdisplay): mode-conflict admission — separate/join/steal/reject (Stage 4) ... The mode_conflict policy is now enforced at ADMISSION, before the punktfunk/1 Welcome, when a DIFFERENT client connects while another client's session is live: - separate (default, unconfigured → no change): each client its own display. - join: admit at the live display's mode (honest-downgrade — the Welcome carries it). - steal: signal the victim session(s)' stop flags, wait the release grace, serve. - reject: refuse the handshake with a busy reason (live mode + client label). New vdisplay/admission.rs: the pure decide() (unit-tested — same-client never conflicts, anonymous clients each distinct, join targets the oldest session) + a live-session registry (identity + mode + stop flag) sessions register in once up. Wired into punktfunk1 serve_session: admit() before validate_dimensions, register after the data plane binds. A same-client reconnect never conflicts. Validated on loopback (two probes, distinct identities, differing modes) across all four policies: separate→own mode, join→live mode, steal→victim interrupted, reject→handshake refused. Remaining Stage-4 surface (deferred): GameStream 503 path, Windows-specific defaults (separate→join map, silent-reconfigure→steal), reject reason delivered to the client as a typed message (currently host-side log + connection close). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-05 10:21:28 +00:00
enricobuehler	ed0881a9b9	feat(vdisplay): Linux keep-alive pool — registry-owned display lifecycle (Stage 1b) ... The ownership split (design/display-management.md §3): the registry owns the per-session virtual-display lifecycle on Linux, so a display can outlive its session (keep-alive) and be reused on reconnect. - registry.rs: a Linux pool driven by the pure lifecycle machine. acquire() reuses a kept (lingering/pinned) display of the same backend+mode, else creates one and keeps the backend's keepalive so the compositor output (and its PipeWire node_id) survives the session. The session's capturer holds a gen-stamped DisplayLease instead of the real keepalive; its drop drives linger/teardown. Enabling fact: KWin/Mutter/gamescope put their node on the DEFAULT PipeWire daemon (remote_fd=None) — reconnect re-attaches by node_id, no fd re-open. wlroots (remote_fd=Some, xdpw portal) passes through unchanged (teardown-on-drop) pending the fresh-portal-capture re-attach. - Default (unconfigured) linger = Immediate → today's teardown-on-disconnect, so no behavior change without a keep-alive policy; concurrent sessions still each create their own output (reuse only matches LINGERING entries). - Wired build_pipeline (punktfunk1) + gamestream through registry::acquire; capture_virtual_output signature unchanged. Windows delegates to vd.create (the manager already leases) — unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-04 23:37:21 +00:00
enricobuehler	c7f8ed2750	fix(core): split WIRE_VERSION from ABI_VERSION — new clients locked out of every deployed host ... ABI_VERSION was doing double duty: the embeddable C surface AND the punktfunk/1 Hello/Welcome version that hosts equality-check. The WoL feature's v3 bump added a client-local FFI function without changing a single wire byte — and every new client started refusing against every deployed host ("ABI mismatch: client 3 host 2", observed live Deck → Bazzite). The wire now carries its own WIRE_VERSION (still 2); ABI_VERSION stays 3 for the C header and the mgmt API's informational field. Bump WIRE_VERSION only when the handshake/planes actually change incompatibly. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-04 14:29:33 +00:00
enricobuehler	24d53b7584	fix(host): don't count punktfunk's own virtual Deck as a physical Steam controller ... The Steam-conflict gate scanned /sys/bus/hid/devices for non-virtual 28DE devices, but the usbip/gadget virtual Decks present a REAL USB device (vhci resolves through vhci_hcd, not /devices/virtual/) — so a just-ended session's pad still detaching, or a concurrent session's live one, read as "physical Steam controller attached" and degraded every back-to-back Deck session to DualSense (observed live on Bazzite). Exclude our pads by their PFDK… serial (HID_UNIQ), with the vhci_hcd path as belt and braces. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-04 11:14:24 +00:00
enricobuehler	99cb8dd888	feat(protocol): per-AU host-timing plane (0xCF) — split host+network latency (stats phase 2) ... The unified-stats equation's host+network stage was one opaque number because the wire carried nothing but pts_ns. Now the host reports its own share per frame: when the client's Hello sets VIDEO_CAP_HOST_TIMING (0x08), the send thread emits a 13-byte 0xCF datagram — [tag][pts_ns u64][host_us u32] — right after the AU's last packet leaves the socket, so host_us = capture→fully-sent (capture read/convert, encode, FEC+seal, paced send) against the same anchor the wire pts carries. Clients correlate by pts_ns and derive network = (received + clock_offset − pts) − host_us; the two terms tile per frame by construction. Back-compat is free in all four combinations: old clients ignore unknown datagram tags, old hosts ignore unknown cap bits (client keeps the combined stage). The hardened data-plane format is untouched — this rides the established QUIC side-plane pattern (0xC8…0xCE). NativeClient ORs the bit in unconditionally and exposes next_host_timing(); the C ABI gains PunktfunkHostTiming + punktfunk_connection_next_host_timing (additive). The synthetic host emits 0xCF too, so pure-loopback protocol tests cover the plane. The probe reports the split (host_p50/p95_us · net_p50/p95_us) and is our direct analogue of Sunshine's "host processing latency" — ours additionally includes the paced send. Validated on loopback (synthetic host + probe, debug build): 240/240 AUs matched, host_p50 6.5 ms + net_p50 6.4 ms ≈ capture→received p50 13.0 ms. Core suite + new 0xCF roundtrip/truncation test green; host+core+probe clippy clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-03 21:22:12 +00:00
enricobuehler	f87869db02	fix(host/audio): rebuild mic passthrough — eager, self-healing virtual mic on both hosts ... Mic passthrough silently died on real hosts. Root causes, all fixed: - No liveness anywhere: a PipeWire restart (Linux) or any WASAPI device error (Windows) killed the backend worker; push() fed the dead queue for the rest of the host's life. VirtualMic now has a liveness contract (push -> bool, alive(), discard()) and the new shared audio::MicPump reopens with backoff, probing on an idle heartbeat so the mic heals BETWEEN sessions too. Validated live: systemctl restart pipewire -> node back in ~0.5 s, tone flows through the reopened backend. - Lazy creation: the mic device didn't exist until the first 0xCB frame, but games bind their capture device at launch and never re-follow. The pump opens eagerly at host start (node exists with zero clients, elected default source). - Windows headless dead-end: with VB-CABLE as the ONLY render endpoint (exactly what the installer ships), the anti-echo guard rejected the cable as the default render endpoint -> mic permanently dead. The new wiring_plan (pure, unit-tested on every platform) assigns the mic its endpoint FIRST (cable reserved for the mic), points the loopback at a DIFFERENT endpoint, and the capture side now yields (explicit endpoint or honest error) instead of the mic dying. Plan recomputed per (re)open — endpoints churn at boot/logon/driver installs. - Stale bursts: buffered audio from a previous session played into a newly-attached recorder (observed live). Timestamped chunks + a consumer-gap check in the process callback age everything past 1 s. The Linux node mechanism stays the stream-based Audio/Source with RT_PROCESS + priority.session: the canonical null-audio-sink adapter recipe was tested on this box (PipeWire 1.6.2) and never gets a clock (QUANT 0 -> pure silence), and WirePlumber reroutes a feeder targeting it to the default sink (echo). Decision documented in the module docs. Live-validated on this box (synthetic host + probe --mic-test, pw-record): eager node, both attach orderings, PipeWire-restart self-heal, post-session silence. Windows side compile/CI + on-glass validation pending. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-03 20:41:19 +00:00
enricobuehler	5acd7f6686	feat(host,probe): controlled loss injection for the native path + probe keyframe-on-drop ... PUNKTFUNK_VIDEO_DROP now also covers the native data plane (N% of sealed wire packets discarded before send in paced_submit — the same FEC-test knob the GameStream path has; no netem/root needed), and the probe grows the real clients' recovery trigger: the data loop publishes the session's unrecoverable-frame count and the control task sends RequestKeyframe when it rises (100ms poll = natural coalescing). Together these make the IDR-vs-intra-refresh recovery A/B runnable against any host. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-02 16:33:56 +00:00
enricobuehler	6da3e2fe6d	feat(host): intra-refresh loss recovery + delivery-anchored latency instrumentation ... Intra-refresh (opt-in PUNKTFUNK_INTRA_REFRESH=1 until on-glass validated): NVENC runs a moving intra band + recovery-point SEI (gop_size becomes the wave period, ffmpeg forces the real GOP infinite; default fps/2, PUNKTFUNK_IR_PERIOD_FRAMES overrides; ENOSYS latches a fallback to IDR-only). Clients request a keyframe on every FEC-unrecoverable frame, so under intra-refresh the session glue serves the first request instantly and suppresses the rest for a 2s window — the wave heals loss without the 20-40x IDR spike cascade. VAAPI/software keep IDR recovery. Instrumentation: the wire pts now anchors at the PipeWire delivery stamp (client-measured latency covers delivery + queue age, not just submit->glass; repeats/synthetic stamps fall back to now), encode_us keeps its submit->AU meaning via a separate inflight stamp, and a new 'queue' stage (delivery->submit age of fresh frames) rides PUNKTFUNK_PERF and the web-console stats samples. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-02 16:33:56 +00:00
enricobuehler	03ad2406b6	fix(host/windows): layout-correct keyboard injection - semantic vs positional VKs ... First-party punktfunk clients send US-positional VKs (the physical key's US-layout VK), GameStream/Moonlight clients send layout-semantic VKs (Sunshine's model). The SendInput injector previously resolved everything through the SYSTEM service's layout - on a German host that is the y/z swap and u-umlaut-on-o-umlaut scramble. GameStream ingest now tags its key events KEY_FLAG_SEMANTIC_VK (stripped from punktfunk/1 wire events so a network client can't flip the convention); the injector maps semantic VKs under the foreground app's layout and positional VKs through a fixed scancode table. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-02 16:24:04 +02:00
enricobuehler	6e41356919	feat(protocol,clients): codec preference negotiation + Linux client decodes per Welcome (Phase 2a) ... Adds a client-selectable **preferred codec** and wires the core + ABI + probe + Linux client to negotiate and decode it. (Windows/Apple/Android follow in 2b.) **Core:** - `Hello.preferred_codec` (a single CODEC_* bit, 0 = auto) — a soft hint appended after `video_codecs`. `resolve_codec(client, host, preferred)` now honors the preference when the host can also emit it, else falls back to precedence (HEVC > AV1 > H.264). Roundtrip + preference tests. - `NativeClient::connect` takes `video_codecs` + `preferred_codec`; `NativeClient.codec` exposes the resolved `Welcome.codec`. - ABI: `punktfunk_connect_ex7` (adds the two codec params; `ex6` delegates to it advertising HEVC-only) + `punktfunk_connection_codec` getter + `PUNKTFUNK_CODEC_{H264,HEVC,AV1}` constants (drift-guarded against the wire values). Header regenerated. **Host:** passes `hello.preferred_codec` into `resolve_codec`. **probe:** `--codec h264|hevc|av1|auto` sets the preference (still advertises it can decode all three); the dump extension already follows the resolved codec. **Linux client:** advertises the codecs FFmpeg can actually decode (`decodable_codecs()`), threads the user's `codec` setting as the preference, and builds the decoder — both the software and VAAPI paths, plus the mid-session VAAPI→software demotion — from the negotiated `Welcome.codec` instead of hardcoding HEVC. New "Video codec" dropdown in Preferences (Automatic/HEVC/H.264/AV1). Live-validated on the dev box: probe `--codec hevc` against a software (H.264-only) host resolves to H.264 (graceful soft-preference fallback), no failure. clippy + core (57) + host (133) tests green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-02 00:13:26 +00:00
enricobuehler	28e04e5e62	feat(protocol,host): negotiate video codec + add a GPU-less software (openh264) encode path ... Phase 1 of codec negotiation, and the Linux software H.264 encode path it unblocks. **Codec negotiation (core `quic`):** - `Hello.video_codecs` (bitfield: CODEC_H264/HEVC/AV1) — the client advertises what it can decode; appended as a trailing byte (older client → 0 = HEVC-only, back-compat). - `Welcome.codec` — the single codec the host resolved and will emit; trailing byte (older host → HEVC). - `resolve_codec(client, host_capable)` picks the shared codec (precedence HEVC > AV1 > H.264) or `None` → the host refuses honestly rather than sending an undecodable stream. - Roundtrip + back-compat tests; cbindgen exports the CODEC_* constants. **Software encoder (host):** - The openh264 `OpenH264Encoder` (was Windows-only) is now built on Linux too — it's platform-agnostic (consumes CPU RGB `CapturedFrame`s, statically-bundled openh264). `openh264` moved to the shared linux+windows Cargo target. - `PUNKTFUNK_ENCODER=software` selects it: `open_video` gains a `software` branch (H.264 only), and `session_plan::resolve_encoder` / `capture::gpu_encode` resolve `EncoderBackend::Software` → `output_format().gpu = false`, so the portal capturer delivers CPU RGB. Explicit-only (auto never picks it — a box with a dead driver still has /dev/nvidiactl and would mis-resolve NVENC). **Host codec resolution (`punktfunk1`):** - The native path no longer hardcodes HEVC: it resolves the codec from the client's advertised set ∩ the host's capability (`Codec::host_wire_caps`: software→H.264, else HEVC), threads it through `SessionPlan.codec`, and opens the encoder + validates reconfigures at that codec. A software host + HEVC-only client is refused with a clear error. - 4:4:4 is gated on HEVC (it's HEVC-only). **Probe:** advertises H264|HEVC|AV1 and logs the resolved codec. Validated on the GPU-less dev box: negotiation is live end-to-end (probe advertises 0x07 → host resolves H.264 → Welcome reports it → plan = Software/H264), and the openh264 unit test (CPU RGB → AnnexB IDR) now runs on Linux. Full capture→encode still needs a GPU on this box — every compositor screencast path (KWin GL, gamescope VK_EXT_physical_device_drm, wlroots EGL) requires one; software render (llvmpipe/pixman) can't be captured — so this box exercises negotiation + encoder, not live capture. The software path unblocks GPU-less-*encode* boxes that still have a display GPU. Phase 2 (clients advertising real codecs + decoding per Welcome.codec) is a follow-up. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-01 23:13:39 +00:00
enricobuehler	138a6ed57d	fix(host): make client game launches work on every Linux compositor ... Client-initiated launches (Hello.launch / GameStream applist) were only wired to gamescope's bare-spawn path via the process-global PUNKTFUNK_GAMESCOPE_APP env — which leaked across sessions, was never read by kwin/mutter/wlroots (launch was a silent no-op there), and was unreachable on gamescope anyway because apply_input_env unconditionally defaulted to the managed session (which bails on non-Bazzite/SteamOS boxes and ignores the launch command in all its modes). - Thread the launch per-session: resolve the library id at handshake, carry it on SessionContext (Windows: id; else: resolved command), and hand it to the backend instance via set_launch_command — the global env write is gone (the env stays as an operator fallback in spawn). - Gamescope sub-mode ladder (pick_gamescope_mode, pure + unit-tested): managed only when session-plus/SteamOS infra exists, attach for an explicit request or a foreign (non-host-descendant) gamescope, else bare spawn — which nests the launch and is now reachable on plain distros instead of the guaranteed managed-mode bail. - launch_session_command: one launch entry point for both planes once capture is live — desktop compositors plain-spawn into the retargeted session (the virtual output is primary); managed/attached gamescope spawns with the live session's DISPLAY/GAMESCOPE_WAYLAND_DISPLAY discovered from /proc (steam:// URIs also forward over Steam's own pipe). launch_is_nested gates bare spawn against double-launching. - GameStream unified onto the same dispatch; also nests library-id picks into gamescope (previously only apps.json cmd was nested). Validated live on the dev box up to the missing-GPU wall: handshake resolution, Spawn sub-mode on plain Ubuntu, gamescope spawned with the command nested. On-glass validation (kwin spawn on the streamed output, Bazzite/Deck managed forward) pending GPU reattach. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-01 22:02:52 +00:00
enricobuehler	ae51276a03	feat(web): consolidate paired devices, self-contained sections, docs + lint ... Web console - Pairing/Library/Stats refactored into self-contained subsections that each own their own queries + mutations; a shared slot-based layout (view.tsx) is filled by the live page (containers) and Storybook (pure cards + fixtures) so the layout can't drift. - All paired devices in one list on Pairing with a protocol column (punktfunk/1 + Moonlight), routing each unpair to the right endpoint; the redundant Clients page is removed. - Library: overview grid split from the add/edit form into separate files. - Login screen links out to the docs. Docs - "Console login password" section on every host page (apt/RPM/Bazzite/SteamOS/Windows) plus a new "Forgot your Password?" troubleshooting page, linked from the login screen. - Console served as HTTP/1.1 over TLS (drop the unusable HTTP/3 advertising) across the Bun entry, launchers, systemd units, and packaging. Tooling - Biome now respects .gitignore (stops linting generated code), config migrated to 2.5.1; all lint issues fixed cleanly. Also includes this branch's in-progress host, Apple client, packaging, and CI changes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-30 19:05:22 +02:00
enricobuehler	bc8bdf7097	feat(windows-host): pf-vdisplay — fix the ADD/REMOVE wedge + per-client display-config persistence ... Two phases of pf-vdisplay (IddCx virtual display) lifecycle work, both validated on-glass on the RTX box. Phase 1 — fix the long-standing IOCTL_ADD 0x80070490 (ERROR_NOT_FOUND) wedge that ghost-monitor slot-budget exhaustion produced under ADD/REMOVE churn (the reset-script/reboot recurring failure). Validated: 43 reconnect-churn cycles, 0 wedges, monitor-node count flat at 1. * driver: on IddCxMonitorArrival failure, tear the created-but-not-arrived monitor down with WdfObjectDelete + reclaim its id — the asymmetric-with-the-create-failure-path leak that exhausted the 16-monitor MaxMonitorsSupported budget; recover MONITOR_MODES from lock poisoning instead of failing closed (defensive; the driver builds panic=abort). * host: collapse the build-retry churn — hold ONE monitor lease across all build attempts and preempt only on Lingering (not Active), so a cold start does 1 ADD not 8; reap not-present "punktfunk" monitor PDOs on startup (the reset-script step-2 logic, in-process) and self-heal a detected 0x80070490 by reaping + retrying ADD; force-preempt a stuck-Active prior monitor on the begin_idd_setup timeout (the safety net the Lingering-only preempt would otherwise drop). Phase 2 — give each client (keyed by its cert FINGERPRINT) a STABLE virtual-monitor id (1..=15) so Windows reapplies that client's saved per-monitor config (DPI SCALING) across reconnects, and two clients never share/bleed config. Validated: distinct clients -> distinct ids (1, 2); the driver honors the host's id (echoed resolved == preferred). * proto: rename AddRequest._reserved -> preferred_monitor_id (offset 20) and AddReply._reserved -> resolved_monitor_id (offset 12) — byte-compatible (offset asserts), NO PROTOCOL_VERSION bump, so a pre-Phase-2 driver degrades gracefully to auto-id (the host detects it via the resolved echo). * driver: create_monitor honors a host-supplied preferred id via resolve_id (range 1..=15, never collides with a live monitor) and seeds the EDID serial + IddCx ConnectorIndex + ContainerId from it. * host: a persisted LRU fingerprint->id map (%ProgramData%\punktfunk\pf-vdisplay-identity.json), threaded to add_monitor via a set_client_identity no-op trait method (Linux/GameStream unaffected). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-30 09:09:26 +02:00
enricobuehler	b9c8d5ab43	refactor(host/windows): collapse Windows capture to IDD-push only ... Remove DXGI Desktop Duplication (DuplCapturer), Windows.Graphics.Capture (WgcCapturer), the two-process SYSTEM+helper relay (virtual_stream_relay / HelperRelay / DesktopWatcher / composed_flip), and the five source files that implemented them. IDD direct-push is now the sole Windows capture path; the session topology is always SingleProcess. Deleted files: wgc.rs, wgc_relay.rs, desktop_watch.rs, composed_flip.rs, windows/wgc_helper.rs (+ wgc-helper subcommand in main.rs). dxgi.rs is kept but carved to shared GPU primitives only (make_device, HdrP010Converter, VideoConverter, install_gpu_pref_hook, WinCaptureTarget, pack_luid) — ~2237 lines of DDA-only code removed; imports cleaned. capture.rs: IDD-push open failure fails the session cleanly (no fallback). Adds capturer_supports_444() — returns false on Windows (IDD-push 4:4:4 is a follow-up), replacing the stale single_process gate in 4:4:4 negotiation. session_plan.rs: CaptureBackend{Dda,Wgc} and SessionTopology::TwoProcessRelay removed. config.rs: no_helper/force_helper/no_wgc/capture_backend/secure_dda removed. merged_env_block relocated from wgc_relay to windows/interactive.rs. Linux cargo check clean. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-06-30 06:46:52 +00:00
enricobuehler	40beb2c370	feat(host/steam): M6 — Steam-pad conflict gate (hardware-validated) ... Don't present a virtual Steam (28DE) pad on a host that already has a physical Steam controller — the host's own Steam Input would then manage two Decks and confuse player assignment. - physical_steam_controller_present(): scans /sys/bus/hid/devices for a 28DE HID device on a real (non-/virtual/) path. - degrade_steam_on_conflict() in resolve_gamepad: a resolved SteamDeck / SteamController with a physical Steam controller attached degrades to DualSense (then the M5 uhid ladder); PUNKTFUNK_STEAM_FORCE=1 overrides (e.g. a remote-only box with no competing Steam Input). Validated on real hardware (a SteamOS Steam Deck @ .253 + a Bazzite host @ .41, both running Steam): - Conflict confirmed: the Deck-as-host already has its physical 28DE:1205 AND Steam's 28DE:11FF XInput output pad live; a 2nd virtual 28DE = two Decks. - Bind robustness: the virtual Deck binds hid-steam on a SECOND kernel (Bazzite 6.17.7, vs the dev box 7.0) and the kernel accepted our serial (the M1 fix). - Criterion-4 (running-Steam recognition) PARTIAL: a userspace consumer (Steam/ SDL) engaged the virtual Deck (opened the hidraw, ran the lizard-disable + settings sequence the kernel's Deck path skips) but emitted NO 28DE:11FF XInput pad on the desktop — so Steam recognizes it enough to manage lizard mode but did not promote it to a managed XInput controller (likely needs a Big-Picture/game context, or a richer device; the 0x83/0xA1 attribute probes never fired, so it wasn't a probe-reject either). - The heuristic itself checks TRUE on the Deck, FALSE on Bazzite. Workspace clippy/fmt/test green. Not pushed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	71e0cace77	feat(host/steam): M5 — fallback remap, motion rescale, degrade ladder ... Keep the rich Steam inputs from silently dropping when the resolved backend isn't the virtual hid-steam device, and fix a cross-device motion-scale bug. - inject/proto/steam_remap.rs (new, pure + unit-tested): * motion_wire_to_deck — the wire carries DualSense-convention units (20 LSB/ deg.s gyro, 10000 LSB/g accel — what every client capture emits), but the Deck's hid-steam report wants 16 LSB/deg.s + 16384 LSB/g. The Deck backend now rescales (gyro x16/20, accel x16384/10000): a real Deck<->Deck gyro/ accel correctness fix (the DualSense/DS4 backends consume the wire 1:1). * fold_paddles + RemapConfig (PUNKTFUNK_STEAM_REMAP=paddles=drop|stickclicks| shoulders, default drop) — the DualSense + DS4 managers fold a client's back grips onto standard buttons rather than dropping them (those pads have no back-button HID slot; the uinput Xbox pad already exposes them as Elite paddles BTN_TRIGGER_HAPPY5-8). - resolve_gamepad: a runtime degrade ladder — a UHID backend (DualSense / DS4 / Steam Deck) on a host where /dev/uhid isn't writable now falls back to the uinput Xbox 360 pad instead of a dead controller (the device-create would just fail). Separate from pick_gamepad's compile-time platform check, so the existing pick_gamepad tests are untouched. - Delete the throwaway M0/M1 spike (src/bin/steam_uhid_spike.rs) — M2's #[ignore]d backend test subsumes its validation, and removing it frees steam_proto to reference steam_remap cleanly. On-box backend test still green; workspace clippy/fmt/test green (incl. the new steam_remap tests). Deferred as optional RemapConfig growth: gyro->mouse / trackpad->stick synthesis on an Xbox target (no slot — documented drop today). Not pushed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	baa20ef377	feat(host/steam): M2 — virtual Steam Deck as a wired PadBackend (Linux) ... Make the virtual hid-steam device a selectable per-session host gamepad, end-to-end on Linux: PUNKTFUNK_GAMEPAD=steamdeck now builds a SteamControllerManager that creates a /dev/uhid 28DE:1205 Deck, enters gamepad_mode, and feeds the byte-exact Deck report (M1). - inject/linux/steam_controller.rs: SteamControllerManager / SteamDeckPad, mirroring dualsense.rs (open/create2, GET/SET_REPORT pump, heartbeat, RAII destroy). Two Steam-specific quirks beyond the DualSense path: * gamepad_mode entry — best-effort `lizard_mode=0` via sysfs, plus a b9.6 creation pulse (MODE_ENTER) so steam_do_deck_input_event stops early-returning, plus an anti-toggle guard (MENU_HOLD_CAP) so a long in-game Start-hold can't flip gamepad_mode back off. * UHID_SET_REPORT answered err=0 (DualSense omits it; the kernel stalls ~5s/cmd otherwise); the 0xEB rumble report parsed onto the 0xCA plane. - core config.rs: GamepadPref::SteamDeck (wire byte 6) + SteamController (byte 5, reserved — folds to Xbox360 until its backend lands); from_u8 / from_name / as_str. Forward-compatible (unknown byte -> Auto); the C-ABI PUNKTFUNK_GAMEPAD_* constants stay M3, so no generated-header drift. - punktfunk1.rs: PadBackend::SteamDeck variant + select / handle / apply_rich / pump / heartbeat arms; pick_gamepad Linux arm. On-box: an #[ignore]d backend test (backend_binds_and_input_flows) drives the real SteamDeckPad — it binds hid-steam (gamepad + IMU evdevs), enters gamepad mode, BTN_A reaches the evdev, and the device tears down on drop. Workspace clippy/fmt/test green. Not pushed. Next: M3 (protocol/ABI wire) + M4 (client capture). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	a4d81641ea	fix(host/pairing): close native-pairing DoS findings #9 + #13 (red-team follow-up) ... The accepts for #9 (PIN-window burn) and #13 (knock-queue flood) rested on a circular premise — each cited the other as the safe fallback — and a re-review showed one LAN attacker could defeat BOTH, denying all onboarding. Close them: - #13 per-source-IP cap on the pending-knock queue (MAX_PENDING_PER_IP) so one host can't fill/evict the 32-slot queue (QUIC validates the source address); and eviction now NEVER drops a live *parked* knock (a held-open connection awaiting operator approval), so a cert-rotating flood can't evict the genuine device being onboarded. This makes the delegated-approval path genuinely flood-resistant — restoring the validity of #9's "use delegated approval on hostile LANs" fallback. - #9 fingerprint-bindable PIN window: `NativePairing::arm_for(ttl, Some(fp))` binds the window to one operator-selected device; `pin_for_attempt` returns `BoundToOther` for any other fingerprint, which the QUIC pair path rejects WITHOUT consuming the window — so an unpaired peer can neither pair nor BURN a window armed for a specific device (it can't forge the bound fingerprint). The mgmt `POST /native/pair/arm` gains an optional `fingerprint` (from a pending knock); unbound arming keeps the legacy any-device behavior (trusted-LAN). (Web-console "pair this pending device with a PIN" UX is a follow-up; the flood-resistant knock path above is the immediate hostile-LAN onboarding path.) + regression tests (armed_pin_is_fingerprint_bindable, pending_per_ip_cap_and_parked_protection); api/openapi.json regenerated. 110 host tests + clippy + fmt green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	624387ea82	feat(pairing): seamless no-PIN delegated approval (host parks the knock, clients add "Request access") ... Web-console "Approve" (delegated pairing, roadmap §8b-1) was unreachable: every client routed a fresh pair=required host straight to the SPAKE2 PIN ceremony, so no "knock" was ever recorded; and an unpaired connect was rejected+closed with no way to resume after approval. The backend + console were complete but had no client-side trigger and no post-approval admit path. Host (native_pairing.rs, punktfunk1.rs): an unpaired identified knock is now PARKED instead of rejected — it releases its NVENC session permit, awaits an operator decision (NativePairing::wait_for_decision, woken by a Notify on approve/deny), and on approval re-acquires a slot and admits the SAME connection with no reconnect. QUIC keep-alive (4s/8s) holds the parked connection warm. The pairing gate moves out of the HANDSHAKE_TIMEOUT-bounded handshake future; approve_pending is reordered read-then-add and wait_for_decision double-checks is_paired to close a "neither pending nor paired" race. New PENDING_APPROVAL_WAIT (180s). Tests: delegated_approval_admits_after_knock now approves mid-park (no reconnect) + new wait_for_decision_approve_deny_timeout unit test (108 host tests green). Clients (Linux/Apple/Windows/Android): a fresh pair=required host now offers "Request access" alongside the PIN ceremony — a plain identified connect with a ~185s handshake budget and a cancelable "waiting for approval" UI; on success the host is saved as paired, and cancel returns the UI immediately while a late- resolving connect is torn down silently via a per-attempt flag. Apple reuses the existing C-ABI timeout_ms (no ABI change); Windows adds SessionParams.connect_timeout + a RequestAccess screen; Android adds a timeoutMs arg to the nativeConnect JNI seam (both sides + both callers). Linux built + clippy + fmt clean; Apple/Windows/ Android pending their CI/on-device compiles. SPAKE2 ceremony reviewed end-to-end against the spake2 0.4 contract — correct, no changes needed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 06:41:09 +00:00
enricobuehler	46b82d4eee	fix(host/security): close audit findings S1,#1,#4,#10,#12,#7,#6,S2-S6 (Linux/cross-platform) ... Remediations from design/security-review-2026-06-28.md verified on Linux (cargo check/clippy/test green; Windows-gated paths verify in CI): - S1 [HIGH]: bump quinn-proto 0.11.14 -> 0.11.15 (RUSTSEC-2026-0185, pre-auth out-of-order STREAM reassembly memory exhaustion on the always-on default QUIC listener). - #1 [HIGH]: remove the unauthenticated nvhttp `GET /pin` endpoint; the GameStream PIN is delivered ONLY via the bearer-gated mgmt API, so a network client can no longer submit its own displayed PIN and self-pair. - #4 [HIGH->MED]: gate the unauthenticated RTSP/UDP media plane on a paired `/launch` and bind it to the launching client's source IP (threaded through the HTTPS handler), so an unpaired peer can neither start capture on an idle host nor ride a paired client's active launch. - #12: bound concurrent parked pairing waiters (MAX_PARKED_WAITERS) so a pre-auth peer can't pin unbounded 300s handshakes. +regression test. - #10: throttle the per-packet ENet control GCM-decrypt-failed warn (exponential backoff) so a junk flood can't spam the log. - #7 [MED->LOW]: serialize all process-global env mutation on the session-setup path under a new vdisplay::ENV_LOCK (apply_session_env / apply_input_env / the launch-cmd set_var / the gamescope env read), so concurrent native sessions can't race set_var/getenv (data-race UB -> host-wide DoS). Full per-session SessionContext threading remains a follow-up for cross-session value confusion. - #6 [MED]: move the gamescope EIS socket relay from world-writable /tmp to $XDG_RUNTIME_DIR (per-user 0700) and reject a symlinked relay file, so a local user can't intercept (keylog) or deny the remote session's input. - S2: a malformed client Opus mic frame now drops that frame instead of tearing down the shared host-lifetime virtual mic (cross-session DoS). - S3: track held buttons/keys in capped HashSets (was unbounded Vec with O(n) scans) so a paired client can't grow per-session input state. - S5: reject fps==0/absurd at the open_video chokepoint (covers Hello, ANNOUNCE, Reconfigure) so the encoder time_base/pts math can't div-by-0. - S6: bound the shared mic mpsc (drop-newest when full). - S4: cap Epic launcher-cache reads (catcache.bin/.item) so a planted giant can't OOM the host during library enumeration. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-28 22:06:24 +00:00