454 Commits

Author	SHA1	Message	Date
enricobuehler	94802795e7	Merge branch 'gamepad-apple-cleanup': cross-client + host gamepad review cleanup (G1–G25) ... 48-finding cross-client + host gamepad audit (2026-07-13). Apple/Android/SDL-core capture + feedback and the Linux/Windows host injectors: held-guide release, the permanent broken-latch cliff (PadGate), Steam Deck trackpad clicks, DualSense mute, Windows DS/DS4 paddle fold, uinput button re-sync, gamestream BTN_* dedup, the dead Windows shell fork, legacy-Deck rumble ceiling, XUSB arrival, ARM64 fences, the truncate-everywhere value convention, and more. See punktfunk-planning/design/gamepad-review-cleanup.md.	2026-07-13 22:29:41 +02:00
enricobuehler	1af11cc64d	fix(inject/host/windows): order the pad change-detect fields with Release/Acquire (G21) ... The XUSB `packet` publish and the XUSB `rumble_seq` / DualSense `out_seq` reads used plain unaligned accesses with no fence, so a driver could observe a bumped change-detect field over a torn body on a weakly-ordered core (ARM64). Publish `packet` via a Release AtomicU32 store behind a Release fence, and Acquire-load the seq fields, mirroring the gamepad_raii PadChannel seq-fence precedent. The DualSense input report embeds its seq mid-report with no driver-gated change-detect field, so it gets a Release fence after the copy and a documented residual (a per-frame input generation is deferred). No-op on x86-TSO. Verified: Windows .173 `cargo clippy -p punktfunk-host --all-targets -- -D warnings` (green). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 22:05:13 +02:00
enricobuehler	2f214532d9	fix(inject/host/windows): eager-create the XUSB pad on Arrival + refresh last_active (G10) ... The XUSB manager's `handle` dropped `GamepadEvent::Arrival` via a `let else`, so the GameStream path never created the pad until the first `State` and missed the first XInput poll. Match on the event and `ensure` eagerly on Arrival, mirroring the DualSense backend. Also refresh `last_active` on create and unplug so a freshly-created pad's residual-rumble idle clock starts fresh rather than inheriting a stale Instant (which could force off a legitimate rumble at once). Verified: Windows .173 `cargo clippy -p punktfunk-host --all-targets -- -D warnings` (green). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 22:05:13 +02:00
enricobuehler	31bc863084	fix(inject/host/windows): free the per-section security descriptor (G19) ... `sddl_sa` leaked the `LocalAlloc`'d PSECURITY_DESCRIPTOR that ConvertStringSecurityDescriptorToSecurityDescriptorW returns, once per DATA section and once per bootstrap mailbox create (amplifiable under pad-flap via create_named's squat-retry loop). Wrap it in a `SecAttr` RAII owner that `LocalFree`s on drop; it outlives every CreateFileMappingW (the section copies the security info at create time), and create_named builds one and reuses it across retries instead of re-allocating. Verified: Windows .173 `cargo clippy -p punktfunk-host --all-targets -- -D warnings` (green) -- confirms the LocalFree/HLOCAL signature at the pinned windows-rs rev. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 22:05:13 +02:00
enricobuehler	e5166c6e6e	fix(host/steam): load vhci_hcd at boot on sysext hosts so the Deck pad is Steam-Input-promotable ... The virtual Steam Deck pad only appears in the host's Game Mode (and is navigable) when it arrives as a real USB device via the usbip/vhci_hcd transport — Steam Input won't promote the UHID hid-steam fallback (Interface: -1). The host runs as an unprivileged --user service, so it cannot modprobe vhci_hcd itself; the module must be loaded at boot and the vhci attach/detach sysfs files chgrp'd to the `input` group by the udev rule. Packaging ships modules-load.d/punktfunk.conf + 60-punktfunk.rules under the sysext's /usr/lib, but a systemd-sysext image MERGES after systemd-modules-load and early udev have already run, so on a plain reboot of a sysext host (e.g. Bazzite) those files are read too late: vhci_hcd is never loaded, usbip fails, and the pad silently degrades to non-promoted UHID — the controller vanishes from Game Mode. (deb/arch/rpm are unaffected: real /usr is present at early boot.) Fix: sysext post_merge now mirrors BOTH files into real /etc (read at the normal early-boot time, shadowing the /usr copies by filename; refreshed every merge since neither is user config), then reloads udev, modprobes vhci-hcd, and re-triggers the vhci platform device for the live session. Also raise the UHID-fallback log INFO->WARN with an actionable hint. Verified on the .41 sysext host: after the /etc mirror, unloading vhci_hcd and restarting systemd-modules-load (the real reader of /etc/modules-load.d) reloads the module; a udev coldplug trigger makes attach/detach root:input 0660; the unprivileged host user can then write attach — the exact working precondition for the usbip transport, now durable across reboot. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 17:41:51 +02:00
enricobuehler	59fc820226	perf(inject/host): dedup the DualSense HID-output feedback plane (G17) ... A game's DualSense output report bundles rumble + lightbar + player-LEDs + adaptive-triggers into one report, so a pad that is merely rumbling re-sends its unchanged lightbar / LED / trigger state on every output report. The managers already dedup rumble, but forwarded every rich `HidOutput` event verbatim — flooding the 0xCD feedback plane to the client during continuous rumble. Add a shared `HidoutDedup` (dualsense_proto, used by both the Linux UHID and Windows UMDF managers) that forwards Led/PlayerLeds/Trigger only on a value change (per side for the two triggers) and always forwards one-shot TrackpadHaptic pulses — mirroring the rumble dedup two lines above and the DS4 backend's lightbar dedup. Reset per pad on create/unplug. Verified on Linux .21 (clippy -D warnings clean, new HidoutDedup unit test + full suite green); Windows .173 with the rest of Phase 3. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 14:14:28 +02:00
enricobuehler	d611645ffc	refactor(inject/host/windows): hoist the shared SwCreateCtx into gamepad_raii (G14) ... The `SwDeviceCreate` completion-callback context (`SwCreateCtx`, the `sw_create_cb` extern callback, and the `instance_id()` accessor) was copy-pasted byte-for-byte in the XUSB (`gamepad_windows.rs`) and DualSense/DS4 (`dualsense_windows.rs`) backends. Hoist the one copy into `gamepad_raii.rs` as `pub(super)`; both `create_swdevice` bodies now build the shared type and pass the shared callback. Prunes the now-orphaned HRESULT/SetEvent/HANDLE imports from the two siblings. Pure move + dedup, no behavior change. Windows-verified with the rest of Phase 3 (clippy --all-targets -D warnings). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 14:08:00 +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	6263108e15	fix(inject/host/windows): fold Steam back grips on the Windows DS/DS4 backends (G7) ... The Windows DualSense and DualShock 4 managers passed the raw wire buttons straight into `DsState::from_gamepad`, so a client's Steam back grips (BTN_PADDLE1..4) were silently dropped and `PUNKTFUNK_STEAM_REMAP` was ignored — the Linux DS/DS4 backends already fold them via `steam_remap::fold_paddles`. Bring the Windows backends to parity: add a `remap: steam_remap::RemapConfig` field (`::from_env()` in `new()`) to both managers and fold the paddles before `from_gamepad`, exactly as `linux/dualsense.rs` / `linux/dualshock4.rs`. Default policy stays Drop (don't fire buttons the user didn't ask for); set the env to map the grips onto stick-clicks or shoulders. `steam_remap` was gated `target_os = "linux"`; widened to `any(linux, windows)`. It's pure (only punktfunk_core + std::env); its Linux-only Deck motion rescale is `pub` so it compiles clean on Windows with no dead-code warning. Verified: Linux .21 (clippy -D warnings clean, inject tests 32 pass / 0 fail — the gate widening is a no-op there); Windows .173 (clean-recheck of punktfunk-host, cargo clippy --all-targets -D warnings EXITCODE 0, steam_remap + both managers compiling on Windows for the first time). On-glass with a real DualSense/DS4 + PUNKTFUNK_STEAM_REMAP still owed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 13:36:13 +02:00
enricobuehler	0c427cb3f1	fix(inject/host/linux): re-assert absolute gamepad button state each frame (G8) ... The uinput gamepad backend emitted only XOR-changed button edges while advancing `prev_buttons` unconditionally. Because `emit()` is best-effort (a full kernel queue silently drops the write), a dropped EV_KEY edge was never re-synced — the button stayed stuck (pressed-not-released, or vice versa) until it next toggled. The axes never had this problem: they re-emit their absolute value every frame. Re-assert every mapped button's absolute state each frame, exactly like the axes, and drop the now-unused `prev_buttons` field. Restating an unchanged key is free downstream: the kernel input core discards an EV_KEY whose value already matches the device's current state (no duplicate event reaches consumers, and BTN_* keys don't autorepeat). The `emit()` "next frame re-syncs state" comment is now honest for buttons too. Verified on the Linux host build (.21): cargo clippy -D warnings clean (no dead-field warning), full punktfunk-host suite 277 passed / 0 failed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 13:14:02 +02:00
enricobuehler	5109a4c80a	refactor(inject/host): extract the shared PadGate create-retry policy + fix the permanent broken latch (G3/G12) ... All seven virtual-pad managers (Linux uinput/uhid: gamepad, dualsense, dualshock4, steam_controller; Windows XUSB/UMDF: gamepad, dualsense, dualshock4) carried an identical copy-pasted `broken: bool` latch that was set on the FIRST pad-creation error and never cleared — so a single transient failure (a startup race on /dev/uinput, a momentary EBUSY, the Windows companion driver not yet ready) permanently disabled EVERY controller for the rest of the session, even after the cause cleared. Extract that latch into one shared, unit-tested `PadGate` (inject/pad_gate.rs) with the fix baked in: capped exponential backoff (1s doubling to 30s) instead of a permanent kill. After a failure, creation is blocked only until the backoff elapses — so the manager no longer re-attempts (and re-logs) on every one of the 60–240 input frames/sec — then a single retry is allowed; a success resets the backoff. A genuinely broken setup therefore self-heals within one backoff window of the fix (udev reload / driver install / next client connect) with no host restart. The gate is manager-wide, matching the old flag's semantics (these failures are systemic, not per-slot). This folds G3 (broken latch) into G12 (dedup the manager skeleton): the latch now lives in one place across all seven backends. Verified on the Linux host build (.21): cargo clippy -D warnings clean, full punktfunk-host suite 277 passed / 0 failed, 4 new PadGate tests green. Windows managers verified separately on the x64 box. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 12:33:49 +02:00
enricobuehler	43e52437c0	fix(gamepad/host): map BTN_MISC1 to the DualSense mute button (G6) ... DsState::from_gamepad mapped GUIDE→PS and TOUCHPAD→TOUCHPAD into buttons[2] but never handled BTN_MISC1, so the mic-mute / capture button clients send was inert on every PlayStation-family virtual pad (DualSense/DualShock4), and btn2::MUTE was dead code. Map BTN_MISC1 → btn2::MUTE (rebuilt from the wire bit each frame like PS/TOUCHPAD, so no persistence gap) and drop the #[allow(dead_code)]. Test extended (from_gamepad_maps_touchpad_click); green on Linux (.21). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 12:04:59 +02:00
enricobuehler	2642ba6ad0	fix(gamepad/host): keep Steam Deck trackpad clicks across a button frame (G2) ... SteamControllerManager::handle rebuilds `SteamState.buttons` from the gamepad frame every tick via from_gamepad, preserving only the rich-plane TOUCH bits — so a held trackpad CLICK (set on the rich plane by apply_rich, stored in `buttons`) was wiped on the very next button/stick frame and only flickered back on the next rich event. This is the exact trap the DualSense backend already dodges by keeping click in a separate `touch_click` field. Mirror that: add persisted `lpad_click`/`rpad_click` bools to SteamState set by apply_rich (instead of pressing LPAD_CLICK/RPAD_CLICK into `buttons`), OR them into the report's click bits in serialize_deck_state, and preserve them across the rebuild in handle() like touch/coords/motion. RPAD_CLICK's other owner — the DualSense touchpad-click wire button via from_gamepad — stays in `buttons` and is OR'd at serialize, so the two sources release independently (a released BTN_TOUCHPAD can't strand a rich click, and vice-versa). Adds a regression test (rich_click_survives_a_buttons_rebuild). All 17 inject::{steam,dualsense,dualshock4}_proto tests pass on Linux (.21). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 12:04:59 +02:00
enricobuehler	644c035a34	feat(encode/amf): accept AMF runtime >=1.4.34 (graceful degrade) + log loaded amfrt64.dll identity ... The Windows AMF encoder hard-rejected any runtime <1.4.36 — a Jan-2025 (Adrenalin 25.1.1) driver floor. Every AMD host on an older driver failed the session with "update the AMD driver" after 8 retries, notably Boot Camp Macs whose bundled amfrt64.dll lags far behind. Split the single pin: - AMF_MIN_VERSION (1.4.34): the ABI floor accepted at load. Every vtable slot the FFI mirrors is a base-interface slot stable since well before 1.4.34; the 1.4.35/1.4.36-only features are string-keyed encoder properties already applied via set_prop(required=false), which log-and-continue — so an older driver degrades those features individually instead of failing. - AMF_HEADER_VERSION (1.4.36): the header the mirror targets, now passed to AMFInit capped at min(header, runtime) so claiming a version newer than the runtime can't make AMFInit reject an otherwise-usable older driver. No functionality removed: a >=1.4.36 runtime behaves exactly as before. Also logs, once per process, the AMF runtime version AND the loaded amfrt64.dll's full path + file-version resource (via GetModuleFileNameW + VerQueryValueW). This surfaces the Boot Camp failure mode where the display driver reads 25.x but the System32 amfrt64.dll is a stale build reporting an old AMF version; the too-old decline now names the DLL path/build and points at reboot + DDU reinstall. Not compile-verified: amf.rs is Windows-only and this Linux box can't cross-build it (a dependency's C build fails for the msvc target). Needs cargo check/clippy on the Windows build box / CI. rustfmt-clean; the windows-crate FFI signatures were verified against the on-disk 0.62.2 bindings. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 01:32:51 +02:00
enricobuehler	05868ef634	fix(encode): Vulkan-HEVC full-RPS reference retention + AV1 feature gate (RFI review) ... 2026-07-12 review of the host encoders / client decoders / RFI plane. NVENC (both), AMF-LTR, the session glue, and the client RfiTracker came out clean; every fix lands in the Vulkan Video backend + dispatch: 1. HEVC: author each P-frame's short-term RPS to retain ALL resident DPB pictures (minus the setup slot), not just its one reference. HEVC 8.3.2 evicts unlisted pictures, and clients keep FEEDING the decoder while frozen — so with the old single-pic RPS, a conforming parser (FFmpeg = the Linux VAAPI/Vulkan and Windows D3D11VA clients) had already discarded the picture an RFI recovery anchor references whenever a fed post-loss frame preceded it: generate_missing_ref, and the "clean" anchor plus everything chained after it decodes as garbage. Pure builder (`build_h265_rps_s0`) + unit tests; AV1 needs nothing (slot-based retention). The smoke test now encodes a fed post-loss frame between loss@4 and anchor@6 so an ffmpeg decode of the dropped dump exercises exactly this (expect ONE POC-4 complaint, never POC 3) — revalidate on the AMD box; this NVIDIA dev box fails the backend earlier at HEVC header retrieval (pre-existing). 2. AV1: chain PhysicalDeviceVideoEncodeAV1FeaturesKHR (videoEncodeAV1 = TRUE, stype 1000513004) into device creation — spec-required for the ENCODE_AV1 codec op; RADV tolerated the omission, validation layers and stricter drivers do not. 3. RFI decline no longer self-arms force_kf — that bypassed the session glue's 750 ms IDR cooldown, turning a storm of hopeless RFI requests into one full IDR each. Decline like NVENC/AMF and let the caller's coalesced keyframe path own the fallback; add the missing first>last guard for parity. 4. open_video_backend now returns the label of the branch that ACTUALLY opened, so the mgmt API / web console reports "vulkan" instead of "vaapi" for the default-on Vulkan sessions (the old dispatch-mirror resolved_backend_label went stale when the backend gained its VAAPI fallback; deleted). Structure: the ~230-line inline HEVC coding block moves to record_coding_h265 (symmetric with record_coding_av1) and the duplicated pre-encode barriers dedupe into begin_encode_cmd. Follow-up plan (separate, punktfunk-planning): bring the post-loss freeze + RECOVERY_ANCHOR/POINT lift to the Android/Windows/Apple clients via a shared ReanchorGate (design/client-reanchor-freeze-parity.md). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-12 23:12:12 +02:00
enricobuehler	2d37835545	feat(encode): AV1 on the Linux Vulkan Video encoder (real RFI) ... Extend the raw Vulkan Video backend to AV1 (`VK_KHR_video_encode_av1`) alongside HEVC, so AMD/Intel Linux hosts get the same clean-P-frame loss recovery for AV1 that HEVC already has — no full IDR on packet loss. ash 0.38.0+1.3.281 predates the AV1-encode extension (finalized in Vulkan 1.3.290) and bumping ash breaks the SDL/Vulkan client (it drops the lifetime on AllocationCallbacks, which sdl3-sys still generates). So the AV1-encode structs/flags/enums are vendored host-only in `encode/linux/vk_av1_encode.rs`, copied verbatim from ash-master's generated code and chained into ash's generic video-encode calls via raw p_next — the common StdVideoAV1* types (from AV1 decode) are reused from ash 1.3.281. `vulkan_video.rs` gains a parallel AV1 path: AV1 Main profile/caps/session (+ max-level session-create), a bit-packed sequence-header OBU + per-frame temporal-delimiter framing (Vulkan AV1 encode, unlike H26x, emits only the frame OBU), and per-frame StdVideoEncodeAV1PictureInfo with the RFI reference model — a normal P inherits CDF context from its reference for compression, while an IDR or recovery anchor sets primary_ref_frame=NONE + error_resilient_mode so it decodes independent of the (possibly lost) frames since its reference. HEVC recording is unchanged; the shared CSC / ring / DPB-barrier pipeline is reused as-is. Codec routing in `open_video_backend` extends the HEVC arm to HEVC|AV1. The seq header enables only order-hint (+128px superblocks per caps), matching FFmpeg's proven Vulkan AV1 config — enabling CDEF/restoration made VCN emit frame-header sections our seq header didn't match, desyncing every inter frame. Headless-validated on real RADV (780M): open + 6-frame encode (I P P P P P) decodes 0-error on both dav1d and ffmpeg/cbs; the RFI recovery anchor at frame 4 is a clean P (not IDR), and dropping the "lost" frame 3 still decodes clean (re-anchored to frame 2). HEVC smoke unchanged (no regression). `cargo clippy --features vulkan-encode -- -D warnings` and the no-feature build both green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-12 22:06:24 +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	84329205eb	feat(encode): default-on the Linux Vulkan Video HEVC backend ... On-glass validated 2026-07-12 on an AMD RADV 780M with a real Deck-class client: the pipelined raw-Vulkan HEVC encoder ran a rock-solid 1080p@240 session and healed loss with clean P-frame recovery anchors (real RFI the libav VAAPI path can't express). Ship it on by default, mirroring the NVENC default-on. - vulkan_encode_enabled() defaults ON; PUNKTFUNK_VULKAN_ENCODE=0 is the libav VAAPI escape hatch. A failed open still falls back to VAAPI, so a device without h265 Vulkan encode (or an untested Intel/ANV that misbehaves at open) degrades gracefully instead of breaking the stream. - Ring depth defaults to 2 (one frame of overlap, lowest added latency — the on-glass-validated real-time setting); PUNKTFUNK_VULKAN_INFLIGHT still tunes it. - Compile --features punktfunk-host/vulkan-encode into the arch/deb/rpm host builds (pure-Rust ash, no new lib / no link-time dep), alongside nvenc. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-12 20:20:31 +02:00
enricobuehler	e9d8f2bc04	perf(encode): pipeline the Vulkan Video encoder (frames in flight) ... The Linux raw-Vulkan HEVC backend blocked on two GPU fences per frame, so CPU readback and the next capture could not overlap the GPU encode. Refactor into a small ring of per-in-flight-frame resources (own command buffers, CSC descriptor set + Y/UV/NV12 scratch, bitstream buffer, feedback query and sync objects) so submit() records into a free slot and returns without waiting, and poll() reads back the oldest slot once its fence signals. The pump's non-blocking poll then overlaps a frame's CSC+encode with the next capture — the throughput win — with no capturer/pump change (VAAPI untouched). - New `Frame` struct + `make_frame`; encoder holds `frames`/`ring`/`in_flight`. - `record_submit` (non-blocking) + `read_slot` (fence-gated readback) replace the synchronous `encode_frame`; `enqueue` applies backpressure by draining the oldest slot when the ring is full. - DPB self-barrier between consecutive encodes: orders frame N's reconstruct write before N+1's reference read now that they can be in flight together. - flush() drains all in-flight slots in order; reset() waits idle + discards. - Ring depth defaults to 3, overridable via PUNKTFUNK_VULKAN_INFLIGHT (2..=6). - Smoke test drains via poll-loop + flush (async breaks one-AU-per-submit). Headless-validated on real RADV 780M: cargo check (feature on/off) + clippy -D warnings + rustfmt clean; smoke test at ring depth 2/3/6 all ffmpeg-decode clean (I P P P P P) and drop-heal (I P P P P) with 0 errors. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-12 19:51:21 +02:00
enricobuehler	bbbb7f5723	fix+perf(encode): clamp Vulkan CSC to source edge + cache dmabuf imports ... Two refinements after the initial on-glass validation on RADV (780M): - Green padding bar at non-16-aligned heights (e.g. 1080 → coded 1088): the CSC compute shader read past the edge of the shorter source dmabuf for the 8 alignment-padding rows, producing undefined/green garbage that showed on a client rendering the coded frame. Clamp every source fetch to `textureSize-1` so padding rows duplicate the last real row (invisible, and the SPS conformance window still crops it for a compliant decoder). BT.709 conversion is byte-identical for in-bounds pixels. 5120x1440 (exactly aligned) was never affected. - Per-frame dmabuf import churn: the backend created + imported + destroyed a VkImage every frame (allocation jitter → stutter). PipeWire cycles a small fixed pool, so import each underlying buffer ONCE (keyed by st_dev/st_ino — each frame's fd is a fresh dup of the same buffer) and reuse it, matching the CUDA-path VkBridge. First import acquires from the foreign producer; cached re-reads keep queue ownership and use a plain visibility barrier. On-glass: ~3-6 imports per session then silent (was ~one per frame at 240 Hz), stutter gone at resolutions with headroom. Also adds a PF_SMOKE_W/H override to the headless smoke test to exercise the conformance-window crop path (ffprobe confirms coded 1088 → displayed 1080). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-12 19:24:12 +02:00
enricobuehler	5ab6daa694	feat(encode): raw Vulkan Video HEVC backend on Linux (AMD/Intel) with real RFI ... Add `VulkanVideoEncoder` (`VK_KHR_video_encode_h265` via ash) — the open-stack twin of the direct-NVENC RFI path, giving AMD/Intel Linux hosts real reference-frame invalidation loss recovery: a clean P-frame recovery anchor that re-references a known-good older frame instead of a full IDR. The app owns the DPB, so recovery = pointing the P-frame's single L0 reference at a resident slot strictly older than the loss (never a concealed frame). The backend owns its own ash instance/device with encode + compute queues, authors VPS/SPS/PPS (Main, conformance-window crop for non-16-aligned heights like 1080->1088), runs a DPB-ring reference-slot state machine with monotonic POC and CBR rate control, and does an on-GPU RGB->NV12 BT.709 compute CSC (embedded rgb2yuv.spv) since capture delivers packed-RGB dmabufs — importing each frame's dmabuf (explicit DRM modifier) or uploading a CPU-RGB fallback, CSC on the compute queue, then encode on the encode queue, ordered by a semaphore. Wired into `open_video_backend`: an AMD/Intel HEVC session opens this instead of libav VAAPI when `PUNKTFUNK_VULKAN_ENCODE=1` (VAAPI fallback on any open error, so it can only improve recovery, never break a stream); `PUNKTFUNK_ ENCODER=vulkan` forces it. Gated behind the new `vulkan-encode` Cargo feature, which pulls no new dependency (reuses the `ash` bindings already carried for the dmabuf zero-copy bridge). Opt-in until on-glass validated, mirroring how the direct-NVENC path shipped. Headless-validated on real RADV (RDNA3 780M, Mesa 26): open + multi-frame encode + `invalidate_ref_frames` all run through the real struct and ffmpeg decodes the output `I P P P P P` with 0 errors; the recovery frame is a clean P-frame (not an IDR); and dropping the "lost" AU still decodes cleanly because the recovery re-anchored to an older frame — the RFI heal, proven on real hardware. `cargo check`/`clippy -D warnings` green with the feature on and off. Design: design/linux-vulkan-video-encode.md. Harness: design/vkenc-probe-harness/. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-12 17:08:15 +02:00
enricobuehler	76594f27c1	feat(nvenc): default-on the Linux direct-SDK NVENC path ... On-glass validated 2026-07-12 on an RTX 5070 Ti host with a real Steam Deck client (NV12 4:2:0, 1280x800@90): real nvEncInvalidateRefFrames landed 73/73 as clean P-frame recovery anchors (never IDR), losses consistently ~2 frames deep — well inside the 5-frame DPB. That is the loss recovery the libav hevc_nvenc path cannot express, so make the direct path the default on NVIDIA. PUNKTFUNK_NVENC_DIRECT=0 (also false/no/off) is now the libav escape hatch. Still gated on a CUDA capture payload — the `cuda` check in open_nvenc_probed keeps AMD/Intel on VAAPI regardless, and the NVENC/CUDA entry points stay dlopen'd at runtime (no new DT_NEEDED), so non-NVIDIA hosts are unaffected. Packaging comments updated to match. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-12 13:34:53 +02:00
enricobuehler	ad532b08a0	style(encode): rustfmt the direct-SDK NVENC Linux backend ... `cargo fmt` was not run on the Phase 5.2 additions (nvenc_cuda.rs + the encode.rs dispatcher fork), failing the ci.yml rust fmt job. Whitespace/wrapping only — no behavior change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-12 11:35:07 +02:00
enricobuehler	93093f3cf9	feat(encode): direct-SDK NVENC on Linux (CUDA input) with real RFI ... Phase 5.2 of design/encoder-recovery-hardening.md (design/linux-direct-nvenc.md). The Linux NVIDIA host encodes through libavcodec `hevc_nvenc`, which structurally cannot express `nvEncInvalidateRefFrames` — so every FEC-unrecoverable loss is a full IDR and, since the client freezes-until-reanchor, a per-loss freeze for RTT+IDR-encode. This ports the Windows raw-NVENC backend to NV_ENC_DEVICE_TYPE_CUDA over the shared CUcontext so Linux NVIDIA gets the same real RFI + F2 recovery-anchor + reset() stall lever + HDR-SEI/Main10 plumbing. New `encode/linux/nvenc_cuda.rs` (`NvencCudaEncoder`): - runtime-loaded entry table via `dlopen libnvidia-encode.so.1` (never link-time, mirroring the zerocopy::cuda libcuda loader) — one binary still starts on AMD/Intel Linux boxes and falls through to VAAPI/software; - session on the shared CUcontext (zerocopy::cuda::context()); - an encoder-owned ring of registered CUDADEVICEPTR input surfaces (zerocopy::cuda::InputSurface + a contiguous-NV12 allocator), each captured DeviceBuffer device→device copied in via the existing copy_* helpers — mirrors the libav recycled-hwframe-pool copy, so zero regression vs today; - config/RFI/anchor/reset ported from the Windows backend; sync-only (NVENC async is Windows-only, so that whole subsystem is dropped); - Main10/HDR-SEI wired but inert until a Linux P010 capture path (Phase 5.1). Wired behind PUNKTFUNK_NVENC_DIRECT (default OFF) in open_nvenc_probed; the Windows path is untouched (no shared extraction in v1). Two on-hardware `#[ignore]` smokes added. Validated on .21 (RTX 5070 Ti, driver 610.43.03): builds on Linux under ci-check, clippy-clean, full host suite 272/0, NV12 smoke (8 AUs, real invalidate_ref_frames + recovery_anchor on a P-frame) and YUV444 FREXT smoke (6 AUs, chroma_444) green; Windows compile unaffected. Owed: the client-in-the-loop matrix (RFI-survives-ABR, reset() heal, A/B vs libav) and the default flip. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-12 11:18:21 +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	a85be8e467	feat(displays): clearer virtual-display preset names + descriptions ... "Gaming rig" actually meant a dedicated/headless box you only ever stream from, which confused users — rename it to "Headless box" and rewrite all five preset summaries to be scenario-first and shorter (the console cards already show the mechanics as badges). Updated across the host API summaries (mgmt.rs), the web console labels (en/de), and the docs table + prose. The internal preset id `gaming-rig` is unchanged (stable API / stored-policy / test contract). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-12 01:29:18 +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	19e9828e8d	fix(host/windows): force off a stale rumble residual the game abandoned ... XInput vibration is level-triggered — it persists until the game sets it to zero — so a game that latches a rumble and then stops calling XInputSetState (a residual left at a menu/loading screen, or a plain forgotten stop) drones to the client forever (measured: a stuck (0,512) resent every 500 ms for 5.5 minutes). A real controller stops when the app stops driving it; mirror that. Keyed on game ACTIVITY (any SET_STATE, even an unchanged one), so a rumble the game keeps asserting is never cut — only an abandoned residual is; kept above SDL's ~2 s resend so an SDL-driven host game refreshes the activity clock before it fires. This is the game-facing half of the rumble-stop story; the wire-facing half is the self-terminating envelope model in the following commit. They compose: this bounds a game-abandoned rumble at the host, envelopes bound a host-abandoned rumble at the client. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-11 03:07:58 +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	0dacb37088	feat(linux): zero-copy 4:4:4 — the EGL worker converts to planar YUV444 on the GPU ... A 4:4:4 session no longer falls to the CPU path (SHM capture + swscale RGB→YUV444P + re-upload — the fps-ceiling triple tax). The zero-copy worker grows a Yuv444Blit: three full-res R8 GL passes (the proven BT.709 coefficients; studio or full range per PUNKTFUNK_444_FULLRANGE, read by both processes so pixels and VUI flip together) into ONE stacked 3-plane pitched CUDA allocation — which keeps the worker↔host wire and IPC single-plane. The encoder copies the planes into ffmpeg's yuv444p CUDA surface and hevc_nvenc emits Range-Extensions 4:4:4 natively. ImportKind::Tiled444 is APPENDED to the worker protocol (a worker outliving a replaced host binary must keep the old tags stable; an old worker just errors the import, which the fail machinery already handles). A 4:4:4 session on a LINEAR/gamescope capture — no convert wired there — fails with a clear message instead of letting hevc_nvenc silently subsample. caps().chroma_444 now keys off the session (it missed the GPU path when keyed off the swscale's existence). Live-verified on the CachyOS VM (RTX 5070 Ti): per-frame "imported to CUDA yuv444=true", stream Rext/yuv444p/bt709 in both tv and pc range, no CPU-path warning. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 18:09:28 +02:00
enricobuehler	d55cde61d3	style: cargo fmt — settle the CSC/tvOS changes' layout (CI Format gate) ... Formatting only, no code change: the signaled-CSC and tvOS commits (1fcf9e11, 3ba19f28) left six files unformatted and the rust job's Format step rejects main. cargo fmt --all --check is clean after this. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 17:11:27 +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	a011aebef5	feat(host,web): experimental PnP monitor-devnode disable for Exclusive sessions ... Second experiment against the connected-but-dark-head stutter (field-proven on the reporter's box: unplugging his standby HDMI TV removes a metronomic ~4 s double-jolt; DDC/CI is a dead end for TVs — measured on the lab LG, VCP 0xD6 gets no I2C ACK). An Exclusive isolate only removes physical monitors from the CCD topology; their PnP devnodes stay live, so every standby wake (auto input scan, Instant-On HPD cycling) still triggers the full Windows reaction: PnP arrival/removal, CCD re-evaluation, DWM invalidation — the suspected hiccup mechanism (Apollo #368's Device-Manager-refresh signature). - New `pnp_disable_monitors` display-policy axis (default off): orthogonal to presets like game_session/ddc_power_off, surfaced in GET/PUT /display/settings + the enforced list, carried through the layout transform. - windows/monitor_devnode.rs: after the isolate takes, disable exactly the deactivated monitors' devnodes — CCD target → monitor device path (DISPLAYCONFIG_TARGET_DEVICE_NAME) → PnP instance id → CM_Disable_DevNode with CM_DISABLE_PERSIST, so a hot-plug RE-ARRIVAL stays disabled (that persistence is the whole point). Teardown re-enables BEFORE the CCD restore (+300 ms re-arrival settle) so restored paths have their monitors back. Precise selection — co-installed third-party virtual displays are never touched. - Crash safety: instance ids journal to <config>/pnp-disabled-monitors.json before disabling; serve startup re-enables leftovers from a crashed host. Worst case is documented in the console help (Device Manager re-enable). - Web console: second Experimental-badged toggle (the DDC block refactored into a shared ExperimentalToggle), EN/DE strings, preset-switch carry. Verified: Linux 263 tests + clippy + fmt clean; Windows (RTX box) 220/220 + clippy clean; web tsc + production build clean; openapi.json regenerated. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 16:47:40 +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	baa04d2d24	style: cargo fmt over the networking-audit changes ... rustfmt pass over the files the deferred-plan items touched (pinned toolchain 1.96.0); no semantic change. cargo fmt --all --check now clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 16:10:20 +02:00
enricobuehler	9afcbcd307	feat(transport): Windows DSCP via qWAVE flows — PUNKTFUNK_DSCP now real on the wire there ... Networking-audit deferred plan §4 (the qos.rs follow-up). On Windows set_tos_v4 succeeds but the stack strips the mark without a qWAVE flow, so PUNKTFUNK_DSCP=1 was a silent wire no-op there. Now (Apollo/Sunshine's approach): QOSCreateHandle once per process; QOSAddSocketToFlow per connected media socket — video → QOSTrafficTypeAudioVideo, audio → QOSTrafficTypeVoice (QOS_NON_ADAPTIVE_FLOW) — then best-effort QOSSetFlow(QOSSetOutgoingDSCPValue, 40/48) to pin the exact CS5/CS6 the other platforms mark. The pin lands for elevated processes (the host runs as the SYSTEM service — exactly where the video egress is) or under the "allow non-admin DSCP" policy; otherwise the traffic-type default marking stands (still WMM-useful). Gating + contract unchanged: opt-in via dscp_enabled(), every step debug-logs and continues. set_media_qos now returns an RAII QosFlow guard (QOSRemoveSocketFromFlow on drop) that must outlive the socket's traffic: stored in UdpTransport (declared before the socket, so drop order removes the flow first) and held for the stream's scope by the GameStream video/audio senders — whose tagging moved after connect(), since qWAVE derives the flow's 5-tuple from the connected socket (behavior-neutral on Linux). Off-Windows the guard is inert and never constructed. Validated: cargo check -p punktfunk-core --target x86_64-pc-windows-msvc green (the full host can't cross-check from Linux — aws-lc-sys needs MSVC tooling; it builds on-box via deploy-host.ps1). Remaining on the next Windows pass per plan: deploy to the RTX box and pktmon/Wireshark the client side — DSCP ≠ 0 on video egress with PUNKTFUNK_DSCP=1, 0 without. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 15:59:23 +02:00
enricobuehler	cdbdc078d6	perf(core): ref-based FEC encode — packetize shards reference the frame in place ... Stage A of the zero-copy host packetize path (networking-audit deferred plan §1): ErasureCoder::encode now takes &[&[u8]], so Packetizer::packetize builds each block's data shards as slices straight into the frame buffer instead of allocating + copying a Vec per data shard. Only the frame's final (possibly partial) shard is staged in a reusable zero-padded scratch; blocks are consecutive shard ranges, so every other shard is a full payload-sized slice. - gf8: encode_sep() over the same Cauchy codec — parity byte-identical to nanors/Moonlight (nanors_exact_parity_vectors unchanged and green) - gf16: reed_solomon_simd::encode is already generic over AsRef<[u8]> - loss-harness sweep: recovery rates identical before/after - bench pipeline (end-to-end, host+client): gf8/64K -3.0%, gf16/64K -2.2%, gf16/1M -3.4%, gf8/1M -0.7% Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 15:16:07 +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	cca5008805	feat(host,web): experimental DDC/CI monitor power-off for Exclusive sessions ... The sole-virtual-display stutter investigation's active experiment: when the Exclusive isolate deactivates a physical monitor, the dark-but-connected head keeps getting serviced (monitor standby auto-input-scan / DP link churn) at a seconds-scale cadence — the leading suspect for the periodic double-jolt. A panel commanded off over DDC/CI (the VESA monitor-control channel in the video cable) believes it has an owner and, on cooperating firmware, stops probing. - New `ddc_power_off` display-policy axis (default off): orthogonal to presets like game_session, stored in display-settings.json, surfaced in GET/PUT /display/settings + the enforced list, carried through the layout transform. - windows/ddc.rs: VCP 0xD6 power-mode control via the dxva2 Physical Monitor API. Deliberately DPMS-off (0x04, DDC stays responsive, signal return wakes) and never power-button-off (0x05, bricks-until-button on many monitors). Probe-before-write; every failure is skip-and-log — monitors without DDC/CI, OSD-disabled, or behind docks/KVMs degrade to a logged no-op. - Manager wiring: panels commanded off immediately BEFORE the Exclusive CCD isolate (an HMONITOR — and with it the DDC channel — only exists while the display is active); teardown wakes them right after the CCD restore, where returning signal alone already wakes most firmware. - Web console: an Experimental-badged on/off control on the display card, applied immediately like the game-session axis and preserved across preset switches; EN/DE strings incl. the wake-failure escape hatch (press the monitor's power button once, turn the option off). Diagnostic value on top of the fix: if this kills a reporter's stutter, the churn is monitor-firmware-initiated; if only topology=primary/extend does, the driver services dark heads regardless — the two remaining root-cause classes. Verified: Linux 258 tests + clippy + fmt clean; Windows (RTX box) 220/220 + clippy clean; web tsc + production build clean; openapi.json regenerated. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 12:32:36 +02:00
enricobuehler	f68f6bc590	fix(linux): zerocopy worker survives the host binary being replaced on disk ... A pacman canary upgrade under a running host (0.5284→0.5338, 09:24 today) unlinked /usr/bin/punktfunk-host; current_exe() then readlinked to "<path> (deleted)", every worker spawn failed ENOENT, and each session silently fell back to the CPU linear-copy capture — observed as the box "regressing" to ~90 fps at 5-7 MP until a service restart. - RemoteImporter::spawn now pins a read fd to /proc/self/exe (once, kept for the process lifetime) and execs the worker via /proc/self/fd/<n>. The magic link names the running image's inode, not its path, so the spawn survives replacement/deletion — and the worker is always byte-for-byte the host's own build, so a mid-upgrade spawn can't hit a worker-protocol skew either. If the fd draws number 3 (the worker's socket slot — the pre-exec dup2 would clobber it) it is re-numbered; if /proc is unavailable the old path-based spawn remains as fallback. - argv[0] is set to "punktfunk-host" and the worker prctl-renames its comm to "pf-zerocopy" — exec-by-fd-path would otherwise show a bare fd number in ps and top. - zerocopy-probe now also spawns the worker (handshake + modifier query), so the probe catches spawn-level breakage, not just FFI/GPU bring-up. Verified end-to-end on the dev box: probe with the binary unlinked mid-run (/proc/self/exe → "(deleted)") still spawns the worker and reports all 13 modifiers. New unit tests cover the pinned spawn and the deleted-file exec; the latter retries ETXTBSY (fs::copy's write fd leaks into other tests' forked children until their execs clear it — a copy-then-exec harness artifact, not a production concern). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 11:34:13 +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	ef39050dbc	docs: repo-wide housekeeping — sync README & docs with the code as shipped ... Six parallel audits swept the root docs, docs-site, every per-directory README, and the packaging docs; every claim below was verified against the source before editing. - README: Layout gains the six missing crates (pf-client-core, pf-presenter, pf-console-ui, pf-ffvk, pf-driver-proto, punktfunk-tray), clients/session, api/ and ci/; Linux/Windows client rows reflect the shell + Vulkan-session split and the Vulkan Video -> VAAPI/D3D11VA -> software decode chains; the "every client over a C ABI" claim is corrected (Rust clients link the core directly); tiered stats overlay + console shell noted; Apple row mentions AV1. - CONTRIBUTING: drop the dead CLAUDE.md link (deliberately untracked); point at the README's build/invariants sections. SECURITY: 0.9.0. - host-cli/pairing: --allow-pairing/--require-pairing are no-op legacy names — pairing is required by default, --allow-tofu is the real flag; document --data-port and --idle-timeout-ms. - configuration: document PUNKTFUNK_RECOVER_SESSION_CMD (session-crash recovery hook), PUNKTFUNK_MDNS, PUNKTFUNK_DATA_PORT. - virtual-displays/gnome: GNOME per-client scaling shipped (host- persisted) — flip the ❌ to ✅ and describe how it works. - stats: new "Detail levels" section (Off/Compact/Normal/Detailed + per-platform cycle gestures); retire the GTK hand-off note. - clients/install-client/status/roadmap: decode chains, Windows client validation narrowed to HDR-only pending, adaptive bitrate, console shell, Apple AV1, Windows host vendor list. - Sub-READMEs: clients/linux rewritten for the re-architecture; session Windows decode rung + d3d11va knob; Windows tiered overlay; Android minSdk 28; decky file table; host zerocopy/ path; scripts port 47992 and steamos-host.md; pf-dualsense source path. - packaging: canary version bases are tag-derived (<next-minor> via pf-version.sh/.ps1), codecs-extra not ffmpeg-full, document the pinned offline-Skia tarball + SKIA_BINARIES_URL and vulkan-headers. - Convert 15 dangling design/*.md links to the punktfunk-planning prose convention (those docs live in the private planning repo). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 09:13:42 +02:00
enricobuehler	b7cb75a48a	fix(host): dual identical GPUs stream again — self-heal the IDD-push ring onto the driver's real render adapter ... A box with two identical GPUs (twin RTX 4090s in the field report) died out of pipeline retries with driver_status=2 (DRV_STATUS_TEX_FAIL, detail 0x80070057): SET_RENDER_ADAPTER pinned the driver to one twin at monitor ADD, but the ring open re-ran the GPU picker, whose max-VRAM tie is settled by DXGI enumeration order — which follows the primary display that the vdisplay flow itself moves mid-session. Ring on one twin, swap-chain on the other → the driver can't open the shared textures, and every retry repeats the same wrong pick. - wait_for_attach: TEX_FAIL becomes a typed AttachTexFail carrying the render LUID the driver reports in the shared frame header (written before the texture opens, so valid on failure) — the error now names both adapters instead of guessing "mismatch?". - open_inner: on AttachTexFail with a different, non-zero driver LUID, rebind the ring there and reopen ONCE. Both candidates are real GPU adapters, so NVENC keeps getting a device it accepts. - gpu::enumerate (Windows): sort the inventory by LUID so the max-VRAM tie, the env-substring first match, and twin occurrence numbering are stable for the boot instead of tracking the primary display. - manager: record the ADD-time render pin on Monitor and warn on reuse when the current pick has moved away from it (the pick only takes effect on the next monitor create; /display/release forces one). - pf_vdisplay: drop the "ADD render adapter DIFFERS from pinned" warn — the ADD reply carries IDARG_OUT_MONITORARRIVAL.OsAdapterLuid (the IddCx DISPLAY adapter, verified on-glass), not the render GPU, so the check compared unrelated LUIDs and fired on every ADD. Verified on the RTX 4090 box: single-GPU streaming is unchanged (IddPush + NVENC AV1 session, no new warnings). The rebind path needs a twin-GPU box — until validated there, /display/release remains the manual recovery. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 02:19:07 +02:00