116 Commits

Author	SHA1	Message	Date
enricobuehler	11045a0f70	chore: consolidate parallel-session WIP (HOLD — do not push) ... Local snapshot of intermingled in-flight work, committed to unblock the encode refactor (a clean ffmpeg_win.rs for the vbv-dedup follow-on). These hunks span the same files and can't be cleanly split here; the commit bundles three distinct workstreams that each belong in their own PR: - logging rework (~43 files: level re-tiering, structured fields, `?e`, hot-path flood latches) - conflicting-host detection (detect.rs + detect/{linux,windows}.rs + wiring in main.rs/mgmt.rs/Cargo.toml/docs/packaging) - standby-sink DWM-stall attribution (windows/display_events.rs + capture/ vdisplay wiring) NOT verified as a combination. NOT to be pushed until the refactor is done and these are re-verified and reorganized into their proper per-workstream PRs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-16 12:42:53 +02:00
enricobuehler	d381cdf7f4	fix(host): NVENC open-failure resilience — backoff, failed-open hygiene, self-diagnosis ... Field report (Linux direct NVENC): after a codec switch, every session open failed with NV_ENC_ERR_INVALID_VERSION until the host process was restarted — so the poisoned state is per-process, not a driver install issue. On-hardware investigation (RTX 5070 Ti, 610.43.03) could not reproduce it with clean codec cycles, dirty teardowns, or open/destroy storms, but established the failure class: the driver enforces a per-process concurrent-session cap (12 there, status INCOMPATIBLE_CLIENT_KEY; other branches report differently) whose exhaustion is exactly this signature — persistent open failures healed only by a process restart. Harden every path that can feed or mask that state: * Rebuild backoff: the in-place encoder-rebuild retries slept one frame interval, so all 5 attempts burned within ~40 ms at 120 Hz — no driver-side transient (deferred teardown of the previous session, engine reset) can clear that fast. Exponential backoff 100 ms → 1.6 s (~3 s total) so transients heal instead of killing the session. * Destroy-on-failed-open (Linux + Windows, all four open sites): the NVENC docs require NvEncDestroyEncoder even when OpenEncodeSessionEx FAILS — the driver may have allocated the session slot before erroring. Without it a retry burst against a transient leaks slots toward the cap, converting the transient into permanent exhaustion. * Teardown: a destroy_encoder failure (a session slot the driver may keep) is now logged with its status instead of silently discarded. * One-shot self-diagnosis on a failed session open (Linux): retry the raw open on a fresh dedicated CUDA context and log which of the three causes applies — shared-context poisoned (fresh works), driver-level skew/exhaustion/GPU loss (fresh fails the same way), or CUDA itself unhealthy (no fresh context) — so the next field report pinpoints the root cause with zero reporter effort. On-hardware regression tests (RTX box .21, all green): codec-switch reopen cycle (H265→AV1→H265→H264→H265), dirty teardown with in-flight encodes, and the full open-failure→diagnosis→in-place-recovery path via real session-cap exhaustion. Existing RFI/reconfigure/4:4:4 smokes still pass; clippy clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-16 01:57:36 +02:00
enricobuehler	f901bedf22	fix(host): actionable NVENC error logging — drop misleading "(no NVIDIA GPU?)" ... Every NVENC entry-point failure was annotated "(no NVIDIA GPU?)", which misled triage: the direct-NVENC path only loads on a machine that HAS an NVIDIA GPU. A Linux user hit NV_ENC_ERR_INVALID_VERSION at open_encode_session_ex (past the NvEncodeAPIGetMaxSupportedVersion pre-flight gate) — the signature of a userspace/kernel driver version skew that a host reboot fixes — and the log pointed at a missing GPU instead. A restart did fix it. Add encode/nvenc_status.rs: a shared NVENCSTATUS -> cause mapper that folds the real cause into the anyhow::Error at construction, so every downstream {e:#} log (the encode-recovery loop, session teardown) improves for free. INVALID_VERSION now reads "update the NVIDIA driver, or reboot if you just updated it (a host restart is the usual fix)"; NO_ENCODE_DEVICE / DEVICE_NOT_EXIST / INCOMPATIBLE_CLIENT_KEY (session-count limit) / OOM / UNSUPPORTED_PARAM get their own glosses. The required API version comes from the SDK consts so it stays correct across crate bumps. Wire it into all NVENC entry-point failures in both backends (encode/linux/nvenc_cuda.rs, encode/windows/nvenc.rs) — every open, init, preset/resource/bitstream call. Also: when the encode-recovery loop exhausts its in-place rebuilds it now logs a clear terminal line with the underlying cause instead of the session silently vanishing after the last identical "rebuilt in place" line. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 01:13:53 +02:00
enricobuehler	b8da32e8b6	fix(host): native sessions on the console + GPU-aware codecs + gamestream capability ... The web console Dashboard read AppState.{streaming,launch,stream}, which only the GameStream path writes, so a native punktfunk/1 session (the DEFAULT plane) showed "Idle / no session" while actively streaming — only the Stats page (shared recorder) reflected it. Add a plane-neutral per-session registry (session_status.rs) the native video loop publishes to; /status now merges both planes, reports active_sessions, and the Stop / Request-IDR buttons reach native sessions too (so surfacing them doesn't leave dead buttons). LocalSummary (tray) gets the same fix. Also on the management API: - /host codecs derive from Codec::host_wire_caps() instead of a hardcoded [H264,H265,AV1], so codecs the GPU can't encode no longer appear. - ApiCodec serializes HEVC as "hevc" (matching the wire/SDP/stats label) so the same codec reads identically across console pages. - HostInfo.gamestream reports whether the GameStream planes run (--gamestream), so the console can hide the Moonlight-only pairing UI on the native-only default host. - StatsStatus.elapsed_ms (host-monotonic) so the capture timer doesn't mix host/browser clocks. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-15 21:06:39 +02:00
enricobuehler	01266ff18d	feat(gamepad): SC2 Puck-dongle passthrough with the native 28DE:1304 topology ... Community-contributed round 5 of the Steam Controller 2 passthrough, reviewed + verified. A Puck-captured pad now presents the dongle's real seven-interface identity (CDC pair, four controller HID slots, management HID) instead of relabelling its reports as a wired 1302 — Steam's Puck feature dances (wireless_transport / esb/bond / 0xB4 slot status) get capture-shaped answers, and the wired identity's canned replies are corrected to the real captures (attribute count, string-attr framing, 0xF2 firmware info, bcdDevice nibble encoding). - new wire pref 10 = SteamController2Puck (Hello/Welcome byte; older peers degrade to Auto), selected by the Android capture link when the transport is a dongle, or by VID/PID in the degraded InputDevice path - TRITON_RDESC is now the captured numbered descriptor (mouse/keyboard lizard collections + per-id vendor reports); unnumbered framing made hidraw mangle feature report 2 and Steam eventually closed the device - interrupt-IN now queues sparse reports (battery/RSSI/wireless edges) instead of keeping latest-only, so a 250 Hz state packet can no longer erase them before the USB/IP poll observes them; EP0 SET_REPORT is split by wValue report type (OUTPUT parsed for rumble vs FEATURE) - vendored usbip-sim: config attributes/max-power, IAD prefix + BOS descriptor support, correct BCD minor.patch encoding (Deck's 0x0300/ 0x0200 values are nibble-zero, so its bytes are unchanged), and full-speed interrupt pacing in ms (was 8 kHz from the HS formula) - Triton feedback is serviced at 1 kHz while an SC2 backend exists so Steam's trackpad haptic writes reach the client unbatched Verified: clippy -D warnings + 319 host tests green on Linux, core wire tests green, Android kit/app compile + unit tests green. On-glass Puck retest owed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 20:47:52 +02:00
enricobuehler	a93f5a71ce	feat(host): script-facing stream-active runtime marker file ... Maintain $XDG_RUNTIME_DIR/punktfunk/stream while any client is streaming, holding the primary session's negotiated mode. A per-title launch wrapper can branch on it: present → session is already at the stream mode, run the game as-is; absent → run the local (e.g. multi-head gamescope) path. - New stream_marker module: RAII Guard registered per session, refcounted for concurrent clients, atomic (temp+rename) writes, injection-safe single-quoted client name. POSIX-sh-sourceable KEY=value, namespaced PF_STREAM_* keys, schema-versioned, additive-only. - Hooked into serve_session so every exit path (disconnect, error, panic-unwind) retracts the marker. File exists iff a stream is live. Unblocks the downstream triple-head gamescope launch-wrapper use case. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-15 18:40:05 +02:00
enricobuehler	e1d7fa2a30	fix(host): activate lid-closed pf-vdisplay targets — explicit CCD path-commit fallback ... A lid-closed laptop defeats both activation stages for a fresh IddCx target: the clamshell lid policy suppresses the new-monitor auto-activate, and the SDC_TOPOLOGY_EXTEND preset returns success without committing a path for the IDD — so every session retry burned ~10s in resolve_target_gdi and the stream died with "not yet an active display path" after 8 attempts (RDP/Parsec still work there: neither needs a NEW console display path). Field report: Windows laptop host, Intel iGPU, lid closed, v0.10.1. New activate_target_path() (win_display.rs) is the supplied-config apply Windows' own display Settings uses to turn a monitor on, which doesn't consult the lid policy: QueryDisplayConfig(QDC_ALL_PATHS), keep every active path verbatim, append the target's inactive path with a source no active display is using (never a clone), both mode idxs DISPLAYCONFIG_PATH_MODE_IDX_INVALID, then SDC_APPLY | SDC_USE_SUPPLIED_DISPLAY_CONFIG | SDC_ALLOW_CHANGES | SDC_SAVE_TO_DATABASE — SAVE_TO_DATABASE so the next same-identity ADD auto-activates from the persistence DB and skips the ladder. Wired as the THIRD stage of resolve_target_gdi; the on-glass-validated auto-activate → force-EXTEND order is unchanged. Also sweep stale "SudoVDA" out of logs/errors and current-behavior doc comments (the backend was removed; pf-vdisplay is the sole one): the capture error now names pf-vdisplay, the HDR toggle logs virtual-display, and the not-active warns list the exhausted fallbacks. Genuinely historical SudoVDA notes stay. cargo check + clippy green on the Windows box; on-glass lid-closed repro still owed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 16:44:41 +02:00
enricobuehler	9127c3465f	feat(client,host): PyroWave Apple Metal decoder + per-mode bitrate pin ... - clients/apple: native Metal wavelet decoder + compute shaders (Phase 5), decoding PyroWave without embedding MoltenVK. - pf-client-core: plumb user_flags/completeness through Decoder::decode_frame so the PyroWave backend parses chunk-aligned + partial AUs; gate the param's unused-warning to exactly the non-pyrowave builds (fixes -D warnings on the featureless Linux client build). - punktfunk-host: on a mid-stream mode switch, re-resolve the "Automatic" PyroWave bitrate for the new mode's ~1.6 bpp operating point (explicit rates and H.26x ABR stay put); reject sub-128px PyroWave modes before the encoder rebuild instead of after the ack. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-15 11:47:42 +02:00
enricobuehler	2621b6e6b1	feat(core,host,android): Steam Controller 2 as-is passthrough to Linux hosts ... The 2026 Steam Controller (Valve "Ibex" / SDL "Triton") captured on an Android client is passed through AS-IS: the host presents a virtual pad with the real wired identity (28DE:1302) and mirrors the physical pad's raw HID reports, so Steam on the host drives it over hidraw exactly like the real thing — trackpads, gyro, paddles, and its rumble/settings writes flow back onto the physical controller. Protocol ground truth: SDL's Valve-maintained SDL_hidapi_steam_triton.c + steam/controller_structs.h. Core: - GamepadPref::SteamController2 (wire byte 9; names steamcontroller2/ sc2/ibex) + PUNKTFUNK_GAMEPAD_STEAMCONTROLLER2 in the C ABI. - Raw HID planes: RichInput::HidReport (0xCC/0x04, client→host input reports verbatim, Copy fixed-64 body) and HidOutput::HidRaw (0xCD/0x05, host→client feature/output writes for replay). Best-effort is sound by the device protocol's own design (rumble re-sent every ~40 ms, settings every ~3 s — losses self-heal); HidRaw bypasses hidout dedup for exactly that reason. Host (Linux): - triton_proto.rs + steam_controller2.rs: Triton2Manager UHID backend — no kernel driver binds the PID (hidraw only; Steam Input is the consumer), raw mirroring with a typed-fallback 0x42 synthesizer until the first raw report, SET_REPORT ack + raw forward, canned GET_REPORT serial reply, rumble also parsed onto the universal 0xCA plane (phone mirror). Rides the uhid + 28DE-conflict degrades; UHID promotion by Steam is flagged in the creation log (usbip transport is the known follow-up if Steam ignores Interface:-1 devices for Triton too). Android: - Sc2UsbLink (wired/Puck: vendor-interface claim detaches the OS driver, interrupt read loop, lizard-off on the watchdog cadence, raw replay via interrupt-OUT / SET_REPORT with hidapi report-id framing) and Sc2BleLink (Valve vendor GATT service, notify subscribe machine, 0x45 re-framing, HIGH connection priority). - Sc2Capture orchestrator: raw plane + typed mirror (exit chord + host degrade paths keep working) on a GamepadRouter external slot; raw return path via GamepadFeedback.onHidRaw. - nativeSendPadHidReport JNI (direct ByteBuffer, no per-report copy), hidout raw decode, usb-host/BLUETOOTH_CONNECT manifest bits, opt-out settings toggle, StreamScreen engagement incl. the USB permission flow. Verified: core 149 + host 312 tests green on Linux (.21), on-box uhid smoke creates/mirrors/tears down the virtual 28DE:1302, C ABI harness round-trips, Android compileDebugKotlin green. On-glass with the real controller owed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 11:22:16 +02:00
enricobuehler	705a8baddf	feat(core,host,client): PyroWave datagram-aligned packets + partial-frame delivery (Phase 4, §4.4) ... PyroWave AUs now packetize on the negotiated shard payload, so a lost datagram costs a few wavelet blocks of localized blur rather than a whole frame — and the client can render an aged-out lossy frame instead of freezing until the next one. Host (opt-in, PyroWave only): - The encoder packetizes at the shard payload behind a 4-byte window prefix (used-len u16 + kind u16). Whole packets pack into WIN_PACKED windows; a packet too large for one shard (PyroWave 32x32 blocks are atomic and can exceed a shard) rides a WIN_FRAG_FIRST/CONT/LAST chain. `set_wire_chunking()` joins the Encoder trait (forwarded through TrackedEncoder — the silent-no-op trap); EncodedFrame.chunk_aligned marks the AU. - virtual_stream tags the AU with USER_FLAG_CHUNK_ALIGNED and re-applies chunking after every encoder (re)build, the adaptive-bitrate rebuild included. Core: - USER_FLAG_CHUNK_ALIGNED (0x40) wire bit. Reassembler opt-in (set_deliver_partial): a chunk-aligned frame that ages out with holes is handed over as Frame{complete:false} — received shards at their exact offsets, missing ranges zero-filled — instead of being dropped. Partials age out on a tight 30ms fuse (PARTIAL_WINDOW_NS) instead of the 120ms loss window: each frame is independently decodable, so an ancient partial has no value in a live stream. Newest-wins. A partial still counts as dropped for loss reporting. Client (PyroWave decode): - The session opts in when codec == PyroWave. The decoder walks the AU window-by-window, skipping zero (missing) windows and reassembling FRAG chains, then decodes whatever survived. A newest-decoded-index guard drops partials the pump has already moved past (no time-travel present). Also fixes a redundant-closure clippy nit in the PyroWave planar-present path. Validated on an RTX 5070 Ti under 2% netem loss with FEC pinned off: 60fps sustained entirely via partials, e2e 43ms p50 (146ms before the fuse) vs 23ms lossless, no keyframe-recovery chatter. Tests green: core 149, host 310 + the GPU-gated encoder smoke (framed-window walk + FRAG reassembly + upstream round-trip), client 26; clippy clean on the pyrowave feature combos. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 11:14:24 +02:00
enricobuehler	12148243bd	feat: PyroWave Phase 3 — pinned rate, all-intra silencing, opt-in UI, notices, docs ... plan §4.6 + Phase 3 productization: - Pinned bitrate: an Automatic client (bitrate 0) on a PyroWave session resolves to the codec's ~1.6 bpp operating point for the mode (≈200 Mbps at 1080p60) instead of the 20 Mbps H.26x default; explicit rates are honored. Mid-stream SetBitrate retargets are refused with the pinned rate acked (guards old/foreign clients), and the client-side AIMD controller + startup capacity probe stay off for the codec — no rate descent into wavelet mush, no climb probe whose VBV reasoning doesn't apply to hard per-frame CBR. Unit-tested. - All-intra silencing: the data plane drops drained keyframe/RFI requests on PyroWave sessions (the next frame IS the recovery), so the forced-IDR cooldown, RFI attempt, and storm coalescing never run. - Opt-in UI: 'PyroWave (wired LAN)' joins the console's Video-codec cycler; trust::Settings maps it to CODEC_PYROWAVE. Safe everywhere by the negotiation contract — an un-advertised preference falls back through the ladder. - FEC: decision recorded — adaptive FEC (10% start, loss-report driven) stays as-is for the MVP opaque-AU mode; the FEC≈0 policy belongs to the Phase-4 datagram-aligned mode. - THIRD-PARTY-NOTICES: the generator now lists third-party trees vendored inside first-party crates (pyrowave, Granite subset, volk, Vulkan-Headers) with their full license texts; file regenerated. - docs-site: 'PyroWave (wired-LAN codec)' page — what it is, the bandwidth table, how to enable it, current limits. Validated on .21: 309 host + 148 core + 26 client tests green, console-ui clean, both feature configs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 09:45:49 +02:00
enricobuehler	9d67dc18aa	perf(core): two-lane AES-GCM seal for large frames + send-thread stage split ... Phase 0.4 host half: PUNKTFUNK_PERF now splits the send thread per window into fec/seal/sock (SealPerf via Session::take_seal_perf; the paced video path folds its chunk-send time in through note_sock_ns), logged with per-packet ns in the send loop's perf line. Measured on .21 at 2.5 Gbps offered: fec ~100 ns/pkt (Phase 1.4 landed), seal ~1000 ns/pkt = 21.5% of a core, sock ~1400 ns/pkt — the Phase 1.5 gate (seal > ~15% of the thread at 2 Gbps) trips. Phase 1.5: seal_frame_inner is now write-then-seal — packetize writes every packet's plaintext at its final wire offset, then a frame of >= 256 wire packets (~300 KB) splits the AES-GCM pass across two lanes: a persistent punktfunk-seal2 worker (lazy-spawned, rendezvous channels, no per-frame spawn, zero steady-state allocs via a reused hand-off Vec) seals the back half under nonces seq_base+i while the send thread seals the front. Nonce order is deterministic per shard index, so the wire is byte-identical to the sequential pass — pinned by the wire-equivalence test, now including a 469-packet frame plus an assertion that the lane actually spawned. Small frames and the probe's ~17-packet AUs stay single-lane; PUNKTFUNK_SEAL_LANES=1 forces single-lane. Validated: 84 core tests + workspace suites + clippy -D warnings on .21. Halves the seal wall-clock on big frames — headroom for the 10G pair's ~4.8 Gbps ceiling (seal alone would be ~47% of a core there) and PyroWave 4K rates. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 23:47:33 +02:00
enricobuehler	5a384fe788	feat(host): pace-aware send chunking — high-rate frames pace honestly instead of blasting ... Phase 1.2: the native plane's pace chunks are rate-adaptive — 16 packets at today's rates, coarsening until the per-chunk interval clears the 500 µs sleep floor, capped at 64 (the GSO segment limit). Decouples the syscall batch from the pace step, so a ≥1 Gbps frame's overflow keeps real sleeps between chunks (and costs 4× fewer syscalls) instead of collapsing into an unpaced blast. Phase 1.3: the auto microburst cap scales with the frame — max(128 KB, the AU's wire bytes / 4) — so high-rate frames burst a bounded quarter and pace the rest; PUNKTFUNK_PACE_BURST_KB now pins an absolute override. GameStream plane untouched (its schedule stays pinned by the deterministic tests, now also asserting budget-independence). Linux GSO latch-off warns once (was silent; USO already warned). Linux GSO default stays OPT-IN: the post-1.2/1.3 A/B on the 2.5GbE-hop pair (.21 → M3 Ultra) reproduced the regression bit-for-bit — 2452 Mbps sendmmsg vs 1909 GSO peak, 0.4% loss at 1500 where sendmmsg is clean. The super-buffer trains lose on the constrained hop in the transport path itself (per-AU probe sends, no video pacer involved), so the block is fabric evidence, not pacing readiness. Control sweep on this build matched the sendmmsg baseline exactly (2452); loss-harness recovery curve identical; workspace clippy + tests green on .21. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 21:38:06 +02:00
enricobuehler	a1af916e38	feat(host): in-place encoder rate reconfigure — ABR steps no longer cost an IDR ... Every adaptive-bitrate step used to tear the encoder down and rebuild it, opening on a full IDR (a 20-40x frame-size spike, in-flight AU forfeit and an IDR-cooldown anchor) — exactly when the Automatic controller is climbing. Encoder::reconfigure_bitrate(bps) retargets the LIVE encoder instead (default false, so libavcodec/software paths keep the rebuild fallback, which also still owns the bitrate clamping): - Linux + Windows direct NVENC: nvEncReconfigureEncoder (added to the hand-rolled runtime EncodeApi tables) with resetEncoder=0 / forceIDR=0; the same init/config is re-authored via the new shared build_config/ build_init_params with only avg/max bitrate + VBV (PUNKTFUNK_VBV_FRAMES) moved. On-hardware test: 20→60→10 Mbps in place, zero IDRs (RTX 5070 Ti). - Native AMF: TargetBitrate/PeakBitrate/VBVBufferSize are dynamic properties — SetProperty on the live component, no Terminate/re-Init. - Vulkan Video (HEVC + AV1): stage the rate and emit an ENCODE_RATE_CONTROL control command on the next recorded frame (begin keeps declaring the session's current state, as the spec requires). The session glue tries the in-place retarget first and skips the rebuild/ inflight-clear/IDR-cooldown bookkeeping when it succeeds — the reference chain and the wire-index prediction survive, so RFI keeps working across rate steps. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 19:53:18 +02:00
enricobuehler	f3b6ccaa7f	fix(gamepad/windows): Steam-accepted Deck unit serial un-mangles the controller name ... Steam validates the Deck unit serial's format before accepting it. Our "PFDK..." serial was REJECTED ("Invalid or missing unit serial number"), so Steam substituted a hash identity and mangled the displayed name to "Steam Deck Controllerggg" on every host tested. An 'F'-leading serial passes, so switch to "FVPF..." — keeps the PunktFunk marker one slot in, still distinct from a real Deck's "FVZZ..." for the Linux self-detection in physical_steam_controller_present(). The name now shows a clean "Steam Deck Controller" with a serial-derived handle (verified on .173). Also fix the UMDF driver's 0xAE GET_STRING_ATTRIBUTE handler to echo the requested attribute id faithfully instead of collapsing board-serial (0x00) requests to unit-serial (0x01). Steam still logs a benign "Deck Controller PCB Serial# invalid" for the board serial — it validates that against a Valve-internal format for ANY value, including an empty one (verified) — but that line does not mangle the name, change the handle, or block promotion. Applied to both transports: host inject/proto/steam_proto.rs::deck_serial (Linux gadget/usbip) and the pf-dualsense UMDF driver (Windows), which mirror each other's serial format. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 16:31:07 +02:00
enricobuehler	d8e8529cd7	feat(gamepad): Windows Steam Deck backend — Steam-Input-promoted UMDF virtual Deck ... The N4 GO verdict, productized. GamepadPref::SteamDeck on a Windows host now builds a real virtual Deck instead of folding to DualSense: games get native Deck glyphs + both trackpads + gyro + all four back grips through Steam Input's own remapping. - steam_deck_windows.rs: DeckWinPad/DeckWinProto/SteamDeckWindowsManager over the sealed shm channel, sharing the whole Linux Deck codec (steam_proto now compiles on Windows too — it was already pure). The SwDevice identity carries usb_mi: Some(2): the &MI_02 hardware-id token hidclass mirrors into the HID child and Steam parses as the wired controller interface — the promotion gate. - Driver: DEVTYPE_STEAMDECK (3) graduates from the spike — SET_FEATURE 0xEB rumble / 0x8F haptic pulses are republished to the host through the output slot (report-id-0 prefixed, so parse_steam_output sees the Linux wire shape), and the 0xAE/GET_STRING serial + 0x83 unit id are per-pad (read from the section's pad_index; PFDK<unit-id> matches steam_proto::deck_serial). - Router: SteamDeck arms in the Windows Pads paths; pick_gamepad flips SteamDeck-if-windows -> SteamDeck (the DualSense fold retires); dualsense-windows-test grows --deck. ON-GLASS VALIDATED on .173 (rebuilt signed driver 9.9.0714.12xx installed, Steam live): the manager-created pad (index 1) enumerates with per-pad serial PFDK50460001, Steam logs Interface: 2 -> '!! Steam controller device opened' -> 'Steam Controller reserving XInput slot 0' -> PollState 2 (actively polling our cycling input frames) -> mapping activated; clean teardown on exit. Rumble round-trip through a real game remains an on-glass debt (nothing sent 0xEB during the idle hold). Known gap vs Linux: no physical-Steam-controller conflict degrade on Windows yet (degrade_steam_on_conflict is Linux-only — /sys scan); a Windows equivalent needs SetupDi enumeration and is deferred. Verified: .21 clippy -D warnings + 304/0 tests + fmt --all; .133 clippy -D warnings + the WDK driver-workspace check. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 12:36:26 +02:00
enricobuehler	4201851c7f	fix(fmt) + feat(gamepad): CI-matching rustfmt everywhere, enforced by repo git hooks; N4 spike flips to GO via MI_02 ... Three things that belong together: 1. rustfmt the gamepad-new-types host files ci.yml's `cargo fmt --all --check` gate flags (the .21/.133 verify recipes ran clippy+tests but never fmt — the same class of miss as 69f30f30). 2. Enforce it at the source: scripts/git-hooks/{pre-commit,pre-push} run the exact CI fmt gates (main workspace + the shipped-driver crates of the UMDF workspace); CONTRIBUTING documents the one-time `git config core.hooksPath scripts/git-hooks`. pre-push is the enforcement point (plumbing commits bypass pre-commit). 3. N4 follow-up — the spike verdict FLIPS TO GO: SwDeviceProfile grows `usb_mi`, synthesizing `&MI_02` into the Deck spike's USB hardware ids. hidclass mirrors the parent's USB tokens into the HID child's hardware ids, and hidapi/SDL/Steam parse `MI_` as bInterfaceNumber (defaulting to 0 when absent — the exact gate the first run hit: Steam wants the Deck controller on interface 2). Re-run live on .173: Steam logs `Interface: 2`, then `!! Steam controller device opened`, `Steam Controller reserving XInput slot 0`, and activates a mapping — full Steam Input promotion of the software-devnode Deck, no driver change needed. The PS identities pass `usb_mi: None` (real single-interface devices carry no MI_ token). A proper Windows-Deck backend phase is now justified; planned separately. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 12:20:33 +02:00
enricobuehler	8c854e0a19	feat(gamepad): classic Steam Controller backend — Linux UHID via hid-steam (N3) ... The reserved GamepadPref::SteamController = 5 slot goes live: the same hid-steam driver under the wired-SC identity (28DE:1102, ID_CONTROLLER_STATE), UHID-only in v1 (no captured SC USB interface layout, so no Steam-Input promotion — the pre-usbip Deck state; acceptable for discontinued hardware). Layout pinned against the kernel's ID_CONTROLLER_STATE table: 24-bit buttons at 8..11 (low bits shared with the Deck; grips at 9.7/10.0 = the Deck's L5/R5 positions; right-pad click 10.2; joystick click 10.6), u8 triggers at 11/12, the joystick/left-pad MULTIPLEX at 16..20 (a left-pad contact shadows the stick, like real hardware's lpad_touched flag), right pad at 20..24. Mapping: wire left stick -> SC stick; wire right stick -> right-pad coords + touched bit (the SC's camera surface — the second-stick loss is inherent); PADDLE1/2 -> the two grips (natively, masked out of the fold input); PADDLE3/4 + MISC1 -> the remap policy. The SC parser has NO gamepad_mode gate, so no mode-entry pulse. SteamDeckPad grew a SteamModel (open_model); ScProto/SteamCtrlManager; pick_gamepad flips SteamController -> itself on Linux (replacing the Xbox360 fold); SDL picker splits Valve PIDs (Deck 1205 stays SteamDeck, SC 1102/1142 now declare SteamController). Verified: .21 clippy -D warnings + 304/0 tests + on-box UHID smoke (hid-steam binds 1102, BTN_A + right-pad ABS_RX land on evdev, no mode pulse); .133 clippy -D warnings green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 11:15:54 +02:00
enricobuehler	70a74b0d7c	feat(gamepad): Switch Pro backend — Linux UHID via hid-nintendo (N2) ... A virtual Pro Controller (057E:2009, BUS_USB, verbatim 203-byte USB descriptor triple-cross-checked from real-device captures) bound by hid-nintendo (>= 5.16): Nintendo-family client pads get correct glyphs + POSITIONAL layout (wire south/east/west/north -> Switch B/A/Y/X, so the physical-position <-> glyph relationship survives), live gyro/accel, and HD-rumble feedback — instead of folding to Xbox360 (mirrored A/B + X/Y, no motion). - switch_proto: report-0x30/0x21/0x81 codec + the entire canned probe conversation, pinned line-by-line against hid-nintendo.c: 0x80-family USB acks, device info (type 0x03 + per-pad MAC), SPI-flash calibration blobs (user magics ABSENT -> factory path; sticks 2048 +/- 1400 with the left/right byte-order difference; IMU offsets 0 + the driver's own default scales so raw units pass 1:1), rumble amplitude decode through the driver's inverted joycon_rumble_amplitudes table, player lights -> 0xCD PlayerLeds. 11 new pin tests. - switch_pro: UHID backend answering the probe from the manager's service pass; SwitchProManager = UhidManager<SwitchProProto> (the 8 ms heartbeat doubles as the steady 0x30 stream the driver's post-probe rate limiter wants). switchpro-test CLI smoke. - Router/fold: SwitchPro arms; pick_gamepad SwitchPro -> itself on Linux; degrade_if_no_uhid covers it. SDL picker: NintendoSwitchPro + JoyconPair declare SwitchPro. Headless-validated on .21 (hid-nintendo 7.1): probe completes ('using factory cal' for sticks + IMU, player-1 LED round-trips to the 0xCD plane), gamepad + IMU input devices created, and an evdev capture pins the positional swap (wire A/B -> BTN_SOUTH/BTN_EAST) + full-range stick scaling. .21 clippy -D warnings + 303/0 tests; .133 clippy -D warnings. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 11:05:28 +02:00
enricobuehler	1830e095f8	feat(gamepad): DualSense Edge backend — Linux UHID + Windows UMDF (N1) ... The plain-DualSense transport + report codec under the Edge USB identity (054C:0DF2, verbatim 389-byte real-device descriptor cross-checked against the raw usbmon capture + hhd's production virtual Edge), so the wire back grips (BTN_PADDLE1..4: Deck L4/L5/R4/R5, Elite P1-P4) land on the Edge's NATIVE buttons[2] bits instead of the fold/drop policy: PADDLE1/2 -> the right/left back buttons, PADDLE3/4 -> the right/left Fn buttons (kernel BTN_TRIGGER_HAPPY1..4 on >= 7.2; SDL/Steam read hidraw on any kernel). - proto: Edge descriptor + btn2 bits + edge_paddle_bits(), pinned against hid-playstation DS_EDGE_BUTTONS_* and SDL_hidapi_ps5 (tests). - Linux: DsUhidIdentity parameterizes the UHID create; DsEdgeLinuxProto / DualSenseEdgeManager. Headless-validated on .21 (7.1): driver=playstation binds 0DF2, all 4 input devices created, probe lightbar/player-LED feedback round-trips; dualsense-test grew --edge (cycles all 4 paddles). - Windows: UMDF driver serves device_type=2 (Edge descriptor/attrs/strings, DS feature blobs); WinDsIdentity parameterizes the SwDevice profile + devtype stamp; DsEdgeWinProto / DualSenseEdgeWindowsManager; INF gains pf_dualsenseedge. Driver change => resign + reinstall before on-glass. - Router: DualSenseEdge arms in route_handle/apply_rich/pump/heartbeat; pick_gamepad folds Edge -> itself on linux||windows; degrade_if_no_uhid covers it. - Client (SDL): 054C:0DF2 declares DualSenseEdge (no distinct SDL type); Edge physical pads take the raw DS5 effects path; console-UI glyphs = Shapes. Apple/Android pickers follow separately. Verified: .21 clippy -D warnings + 292/0 host tests + on-box UHID bind smoke; .133 clippy pending in this push. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 10:49:31 +02:00
enricobuehler	45bde370e2	feat(gamepad): GamepadPref wire bytes for DualSense Edge (7) + Switch Pro (8) ... Phase 0 of gamepad-new-types: the two new kinds exist on the wire (enum, to_u8/from_u8/from_name/as_str, C-ABI constants + header), and pick_gamepad folds them to the closest EXISTING backend until their own backends land — DualSenseEdge -> DualSense (keeps the rich planes; only the paddles go through the fold policy), SwitchPro -> Xbox360. Wire round-trip pinned 0..=8 + unknown->Auto; fold table extended. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 10:20:24 +02:00
enricobuehler	17457cf4ba	refactor(gamestream/host): source gamepad BTN_* from punktfunk_core + pin the wire bits (G13/G15) ... `gamestream/gamepad.rs` hand-declared its own copy of the GameStream buttonFlags/buttonFlags2 layout, which had drifted from the single source of truth in `punktfunk_core::input::gamepad`: the click bits were named `BTN_LS_CLK`/`BTN_RS_CLK` (vs core's `…_CLICK`). The two layouts are bit-identical — GameStream/Limelight and the punktfunk/1 native wire are one contract — so define the gamestream names as `pub const` aliases of the core constants. Values now come solely from core (can't drift); kept as `pub const` (not a `pub use` re-export) because on Windows the only consumer — the Linux uinput button map — is cfg'd out, where an unused re-export lints as an error but an unused pub const does not. Rename the two injector call-sites (`inject/linux/gamepad.rs`) to the canonical `BTN_LS_CLICK`/`BTN_RS_CLICK`. G15 host half: replace the 3-bit gamestream-vs-core spot-check with an exhaustive golden-value test (`gamepad_wire_bits_are_pinned`) that freezes every button bit + axis id to its exact wire value, so renumbering a bit in core — which would silently break every shipped client — fails a test first. The host counterpart to the client-side C-ABI cross-checks. Verified on Linux .21: clippy -D warnings clean, pin test + gamepad suite green. (Windows verified together with the rest of Phase 3.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 14:08:00 +02:00
enricobuehler	76be4c3e12	feat(gamepad): multi-controller support on the native plane ... Host was already built for 16 pads; the blocker was every client hard-coding pad 0. This lands the host-side + reference-client contract: - input.rs: new wire kinds GamepadArrival=14 (declares a pad's type: code=GamepadPref byte, flags=pad) and GamepadRemove=13 (flags=seq<<24|pad, shares the snapshot seq space via encode/decode_gamepad_remove). - pf-client-core/gamepad.rs: reworked from a single `open` pad to a slots: Vec<Slot> model — every forwarded controller gets a stable lowest-free wire index held for its lifetime, per-slot held/axis/touch/ rumble state, GamepadArrival on open + GamepadRemove on close, and feedback routed back per wire index. Automatic forwards all real pads; a pin forces single-player. - punktfunk1.rs: replaced the single-session PadBackend enum with a Pads router — per-pad kinds[]/owner[] arrays, lazily-created per-kind managers, pure route_decision keeping a live device in its manager across a kind change (no ghost/dup). Input thread seq-gates GamepadRemove (clears the pad_mask bit, resets rumble) and applies GamepadArrival kinds. - inject linux/windows backends: add the two new no-op InputKind arms. Native/session + default-Windows clients (both spawn punktfunk-session) inherit this. 57 core + 33 client-core + 272 host tests green; clippy clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-12 21:53:07 +02:00
enricobuehler	fdda7144ed	fix(encode): harden loss-recovery correctness across host encoders (F1–F7) ... Phases 1–4 of design/encoder-recovery-hardening.md — make the shipped RFI/ freeze-until-reanchor recovery honest and rebuild-safe across every backend. F1 — frame-index domain desync: the encode loop now owns a session-lifetime `au_seq`; `Encoder::submit_indexed(au_seq + inflight)` pins NVENC inputTimeStamp and AMF LTR slots to the WIRE frame index, so `invalidate_ref_frames` compares client frame numbers in the same domain and survives adaptive-bitrate rebuilds (an internal counter desynced on the first rebuild → RFI silently dead / an AMF force-ref onto a never-decoded frame). `FrameMsg.frame_index` → `Session::seal_frame_at`; GameStream gets the same via `VideoPacketizer:: packetize(.., Some(idx))`. F2 — Windows NVENC left the client frozen ~1s per loss: NVENC RFI was transparent (no anchor tag) while the session glue armed the 750ms IDR cooldown, so the freeze only lifted on the ~1s keyframe re-ask. NVENC now mirrors AMF — `pending_anchor` tags the first post-invalidate AU (the clean re-anchor P-frame) `recovery_anchor`, incl. the covering-range dedupe re-arm; the client lifts at ~RTT. F3 — speed-test probe filler burned video frame indexes: moved to its own index space (`Packetizer::alloc_probe_index` + `Session::submit_probe_frame`) with a second client reassembly window routed on FLAG_PROBE, gated on the new VIDEO_CAP_PROBE_SEQ Hello bit (mid-session probes declined for older clients). F4 — RFI range sanity cap: forward gaps wider than `packet::RFI_MAX_RANGE` (256) resync via keyframe instead of an out-of-range RFI, host- and client-side (client huge-gap → keyframe in `RfiRecovery::observe` + the pf-client-core pump). F5 — reset() parity: Windows NVENC (teardown + lazy re-init), Linux VAAPI (drop-inner), Linux NVENC (reopen from stored OpenArgs) now give the stall watchdog a heal lever instead of ending the session. F6 — sw.rs `pending: VecDeque` (was `Option`), killing the silent AU drop at capturer pipeline depth > 1. F7 — doc sweep on the RFI/anchor comments. Verified: punktfunk-core lib tests (macOS + Linux), full punktfunk-host suite on Linux (RTX 5070 Ti), Windows compile. Owed: the on-glass client matrix (F2 freeze A/B, AMF LTR spike across a bitrate rebuild). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-12 11:17:19 +02:00
enricobuehler	f77fdee3e9	style(host): fix clippy doc_lazy_continuation in reconfig_allowed ... New clippy (rust-1.96) flags the summary line after the 'Gated OFF for' bullet list as a lazy list-continuation under -D warnings. Add a blank /// line so it reads as its own paragraph (clippy's suggested fix), matching intent. Comment only; no behavior change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-12 02:05:25 +02:00
enricobuehler	2271f67202	style: rustfmt the recovery + resize changes (Windows CI fmt check) ... The `cargo fmt --check` step on the x86_64-pc-windows-msvc job was failing: the mid-stream loss-recovery and resize-overlay commits landed with unformatted wraps across pf-presenter, pf-client-core, punktfunk-core, pf-console-ui, and a few host files. Applied `cargo fmt`, and hand-relocated two trailing comments in session.rs (a decoded-frame note and the wrap-counter note) to their own lines so rustfmt no longer column-aligns the following comment block to a deep indent. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 23:25:06 +02:00
enricobuehler	e55ff1bb28	feat(recovery): clean mid-stream loss recovery — freeze-until-reanchor + AMD LTR-RFI ... Removes the "gray frames with motion" artifact on Vulkan-Video clients and lets AMD/NVENC hosts re-anchor after loss WITHOUT a 20-40x IDR spike. Client (pf-client-core): after a reference loss the hardware decoder conceals the missing-reference deltas (on RADV, a gray plate with new motion painted over) and returns Ok. The pump now freezes on the last good picture until a clean re-anchor instead of showing the concealment — lifting on a real IDR, an intra-refresh recovery mark (2nd wave boundary), or an LTR-RFI recovery anchor (1st). The frame_index gap is the early, precise loss signal and drives an RFI request. Host recovery signals (inert unless the backend supports them): - USER_FLAG_RECOVERY_POINT — intra-refresh wave boundary (NVENC constrained GDR). - USER_FLAG_RECOVERY_ANCHOR — AMD LTR reference-frame-invalidation recovery frame. AMD LTR-RFI (encode/windows/amf.rs) — the AMD twin of NVENC RFI. AMF's AVC/HEVC API has no constrained-intra property (intra-refresh cannot heal; PSNR-proven), so the only clean-recovery lever is user LTR: mark frames as long-term references, and on loss force the next frame to re-reference the newest known-good one — a clean P-frame, not an IDR. Two rotating LTR slots, ~0.5s mark cadence, on by default for AVC/HEVC (PUNKTFUNK_NO_AMF_LTR disables). invalidate_ref_frames picks the newest LTR before the loss; a range older than the live slots falls back to a keyframe. Protocol (punktfunk-core): RfiRequest control message + NativeClient::request_rfi(). Host: RfiRequest dispatch -> invalidate_ref_frames (IDR fallback); an RFI success anchors the keyframe cooldown so the client's frames_dropped echo of the same loss is coalesced away rather than emitting a redundant IDR. Spike: synthetic NV12 GPU source for headless AMF encoder testing. Validated: core rfi_request_roundtrip; pf-client-core 31 unit tests (incl. an_rfi_anchor_lifts_immediately); punktfunk-host builds + 271 tests on Linux; punktfunk-host builds clean on Windows; real AMD iGPU spike (invalidate at frame 90 forced re-reference to LTR frame 60 — 180 frames, keyframes=1, no recovery IDR). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-11 17:31:17 +02:00
enricobuehler	d294b3923c	test(resize): extract + unit-test the live-reconfigure gate (H1 gamescope / H5 per-client-mode) ... The Linux §6 on-glass matrix can validate the gamescope must-REJECT behavior only on native-gamescope hardware (the NVIDIA dev box fails headless GBM allocation — a nested Hyprland/sway/gamescope output comes up 0×0), so pin the gate down deterministically instead: extract the inline `live_reconfig_ok` decision into a pure `reconfig_allowed(compositor, per_client_mode)` and test it — gamescope rejects in every identity mode, a per-client-mode policy rejects on every backend, and all other compositors (plus the synthetic protocol-test source) with the default identity accept. Also fmt-normalizes the re_add block from the prior commit (whitespace only). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 14:56:59 +02:00
enricobuehler	4c18bb80ca	feat(resize/win): mid-stream resize on-glass fixes — corrective-ack actual res + monitor re-arrival ... On-glass validation on the .173 Windows IDD-push host confirmed the Reconfigure protocol + host rebuild work end-to-end and genuinely change pixels for an advertised mode (1920x1080 -> 1280x720: two SPS/IDR sets, ffprobe both res). It also surfaced two gaps for out-of-EDID-list target modes, both fixed here. Fix 2 (corrective ack carries the ACTUAL resolution): the H2/H3 corrective ack recovered only the achieved REFRESH (interval_hz), taking width/height straight from the request — so when a backend delivered a different RESOLUTION (Windows pf-vdisplay falling back to its advertised mode) the client was told it got a size it never received, and by the D2 discipline never re-asked. New `delivered_mode(frame.{w,h}, interval)` derives the ack from the captured frame's real dims (what the encoder opened at / the client decodes) in both the success and rollback branches. Unit-tested. Fix 1 (reach arbitrary mid-stream modes via monitor RE-ARRIVAL): the pf-vdisplay driver freezes a monitor's advertised mode list at IOCTL_ADD, and IddCx exposes no live update-modes DDI, so an in-place ChangeDisplaySettingsExW to a mode not advertised at arrival returns DISP_CHANGE_BADMODE. The manager's mid-stream reconfigure now REMOVEs + re-ADDs the driver monitor at the exact new mode, reusing the slot's stable per-client id (EDID serial / ContainerId) so the OS keeps identity + saved DPI. The rebuilt Monitor PRESERVES gen (lease/refcount continuity) and the group restore snapshot; reisolate_after_swap re-isolates the new target without recapturing it. Host-only — no driver change. One monitor hotplug per switch (the design's accepted "re-arrival for everything"). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 14:34:22 +02:00
enricobuehler	d0d9bd5bfb	feat(resize): mid-stream resolution resize — host hardening (H1–H5) + session-binary Match window (C1) ... design/midstream-resolution-resize.md Phase 0 + Phase 1. Host (Phase 0): - H1/H5: per-backend Reconfigure acceptance gate — reject for gamescope (all sub-modes; a resize must never relaunch the title) and under the per-client-mode identity policy (a resize would resolve a different display slot). Synthetic stays reconfigurable on purpose (the protocol test source; the C-ABI roundtrip test rides it). Plus a 500 ms host-side min-interval backstop against Reconfigure spam. - H2: rollback/corrective ack — the data plane reports the mode actually live after a failed rebuild (or a refresh the backend capped) through a reconfig_result channel; the control task forwards it as a second accepted Reconfigured so the client's mode slot self-corrects. - H3: live stats mode — SendStats reads a packed AtomicU64 (w|h|hz) updated on every switch instead of latching the session-start mode. - H4: registry::retire(gen) — a mode-switch rebuild force-releases the superseded Linux display, so linger/forever keep-alive policies don't accumulate kept monitors at stale modes. VirtualOutput carries pool_gen (fresh AND reused) and the Pipeline tuple threads it to the switch arm. Client (Phase 1, default off): - Settings: match_window policy + persisted last window size; exposed as the Resolution tri-state (Native / Match window / explicit) in the Skia console, GTK and WinUI settings pages. - pf-presenter: window opens at the persisted size; Hello mode follows the window's pixel size; D2 trigger discipline (400 ms debounce to resize-end, ≥1 s spacing, even-floor + ≥320×200 clamp, each distinct size requested at most once — covers rejects and host rollbacks) as a pure, unit-tested decision; HUD line + title refresh on a switch. - Session binary wires both --connect and --browse paths; the WinUI shell is session-always, so this covers Windows too. Verified: workspace tests + clippy green; synthetic --remode end-to-end; live session-binary run (window at persisted 1000×600 → Hello 1000×600@60). On-glass per-backend matrix (Mutter/KWin/gamescope-reject, keep-alive accumulation) still pending before any default flip. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-11 12:53:47 +02:00
enricobuehler	73c911cae4	feat(rumble): host-authoritative self-terminating envelopes (0xCA v2) ... Rumble was level-triggered, unbounded state on a lossy channel: a non-zero level meant "buzz until further notice", healed only by the host re-sending state every 500 ms, and every client guessed when the host had died with its own magic timeout (SDL 1.5 s, Apple 1.6 s, Android up to 60 s). A lost stop, a reordered start, or a dead host could drone the motor for seconds. Make "stuck rumble" inexpressible on the wire. The 0xCA datagram grows a length-tolerant tail — [u8 seq][u16 ttl_ms] — so it self-terminates: the host authorizes a level for at most ttl_ms and renews it (~120 ms) while it holds, letting an abandoned one lapse client-side. seq is a per-pad wrapping reorder gate (reusing GamepadSnapshot::seq_newer) so a reordered stale start can't re-light a stopped motor. Decoders read the first 7 bytes as a plain level and ignore the tail, so no wire-version bump: an old client renders a new host's levels, and a new client falls back to its prior staleness heuristic against an old host (ttl = None). All four generation pairings render correctly. - core: encode_rumble_datagram_v2 / decode_rumble_envelope (datagram.rs); the client demux applies the seq gate then forwards (pad, low, high, Option<ttl>); next_rumble is unchanged (drops ttl), next_rumble_ttl keeps it; ABI adds punktfunk_connection_next_rumble2 + PUNKTFUNK_RUMBLE_NO_TTL, ABI_VERSION 4->5 (WIRE_VERSION unchanged — the tail is backward-compatible). - host (punktfunk1.rs): the flat 500 ms refresh becomes a renewal loop that bumps seq + stamps a fresh TTL on active pads and drains a short post-stop zero burst, then goes quiet. Hatches: PUNKTFUNK_RUMBLE_ENVELOPE=0 (legacy v1 + flat refresh, a bisect switch), PUNKTFUNK_RUMBLE_TTL_MS (clamped [150, 5000]). - renderers honor the TTL as their playback duration/deadline and keep their old heuristic only for a legacy (ttl=None) update: pf-client-core (the Deck haptic keep-alive is now deadline-bounded so it can't sustain a host-stopped rumble), clients/windows (SDL duration), android (JNI packs the lease out-of-band in bit 48 so any u16 ttl is unambiguous; Kotlin createOneShot(ttl)), apple (RumbleRenderer.envelopeDeadline + nextRumble2; sessionStaleSeconds demoted to the legacy fallback). - tests: codec round-trip + tail tolerance + seq-gate reorder (Rust); the probe asserts the v2 tail arrived under PUNKTFUNK_TEST_FEEDBACK; the Apple loopback asserts ttlMs round-trips end to end; RumbleTuning lease-decision cases. The host-side idle-timeout from the previous commit is defense in depth on the game side; this is the guarantee on the client side. Design: punktfunk-planning/design/rumble-envelope-plan.md. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-11 03:08:27 +02:00
enricobuehler	35d97ae6ac	feat(windows): parallel virtual displays — proto v3 ring binding, manager slot map, group topology (W0–W3) ... 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>	2026-07-11 01:06:44 +02:00
enricobuehler	3078528b28	feat(video): 4:4:4 defaults — the host allows it, the client chooses it ... Capability now lives on the host, choice on the client. PUNKTFUNK_444 flips to DEFAULT ON with an explicit-off grammar (0/false/off/no — the old presence-only flag() would have read =0 as on); every existing gate still applies (client advertisement, HEVC, full-chroma capture, encode probe, Windows HDR-display downgrade), so an unset host merely stops refusing. The Apple client's "Full chroma (4:4:4)" toggle flips to DEFAULT OFF: full chroma is a per-session trade — a clear win for desktop/text, but at a fixed bitrate game content spends those bits better at 4:2:0, and the encode/decode pixel rate rises. Persisted user choices survive both flips. Live-verified on the CachyOS VM: host with no env negotiates chroma_format_idc=3 for a 4:4:4-advertising client; PUNKTFUNK_444=0 resolves 4:2:0. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 18:09:28 +02:00
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