850 Commits

Author	SHA1	Message	Date
enricobuehler	810d918d36	fix(core/quic): make the control-stream read cancel-safe ... `io::read_msg` frames a message with two `quinn::RecvStream::read_exact` calls, and quinn documents `read_exact` as explicitly NOT cancel-safe: the bytes it has already taken out of the stream live only in the future's own buffer and nothing puts them back on drop. Both long-lived control loops drive that read from a `tokio::select!` arm — the client pump alongside `ctrl_rx.recv()` and the resync tick, the host alongside probe/reconfig/clip-offer channels — and neither uses `biased;`, so any sibling that becomes ready ends the iteration and drops a partially-progressed read. `clock_sync` has the same shape via `tokio::time::timeout`, which can fire mid-frame before the session even starts. A control frame only has to straddle two wakeups for this to bite: a ClipOffer carries up to 16 kinds x 128 bytes of MIME, ~2 KB, which exceeds one QUIC packet and is subject to the pacer; any frame whose second half is lost or reordered does it too. Losing the consumed length prefix misaligns the stream permanently — the next read takes two payload bytes as a length, so Reconfigured, ProbeResult, BitrateChanged, ClockEcho and ClipState all decode as garbage and are silently dropped, and a bogus length up to 64 KiB parks the read forever. Mode switches, adaptive bitrate, mid-stream clock resync and clipboard are dead for the rest of the session; only a reconnect recovers, and the log shows at most one `warn!`. Add `io::MsgReader`, which keeps the frame in progress in the reader rather than the future and reads via quinn's cancel-safe `read`, and switch the three cancelling sites to it (client control loop, host control loop, clock_sync). The sequential handshake/pairing callers keep the plain `read_msg`, whose doc comment now states the constraint. No wire bytes and no ABI change — only how the same length-prefixed frames are assembled. Tests: a frame split across two wakeups with the read cancelled in between must resume and leave the following frame correctly framed (confirmed to fail — it hangs on the desynced stream — against the old behavior), plus a zero-length frame round-trip. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-20 07:42:37 +02:00
enricobuehler	7b2cdf5a7a	fix(core/net): bind the data plane to the authenticated peer + stop adaptive FEC wedging large frames ... Four defects from the punktfunk-core quality sweep, all in the data plane. transport/udp: the hole-punch adopted the source address of ANY datagram whose first 8 bytes matched PUNCH_MAGIC — a fixed public constant with no key, nonce or session id — and the authenticated QUIC peer was passed only as the no-punch fallback, so it was never used to validate. Hole-punch is the default bring-up path (it is skipped only for a fixed --data-port), and the data socket is an OS ephemeral, so spraying the ephemeral range during the 2500 ms punch wait let anyone steal the video plane: the legitimate client is then filtered out by the connect() and gets nothing, while QUIC stays healthy so no reconnect fires. With a spoofed source the same 8 bytes aim a full-rate stream at a third party. Take the authenticated peer IP and require the punch to match it — only the PORT is in question (that is what a NAT remaps and what the punch exists to discover); the client dials the same host IP as its QUIC connection, so a NAT presents one source IP for both planes. Also budget each read from the REMAINING window, so off-peer datagrams cannot stretch the wait past punch_timeout. transport/udp: the punch keepalive treated every send error as fatal and broke out of its loop permanently and silently. It holds a clone of the connected, non-blocking data socket — exactly the socket whose transient conditions this module defines and documents in is_transient_io. One ENOBUFS from a full wlan tx queue or an ENETUNREACH during an AP roam killed the only thing holding the NAT mapping open; the path recovers, video keeps flowing, and the stream dies later when the idle timer expires the mapping during a static scene. Route it through is_transient_io like every other send site in the file. packet: adaptive FEC moved fec_percent live (host bands it 1..=50 while Welcome advertises 10) but the receiver's per-block acceptance ceiling was computed once from the negotiated percentage and never re-derived. Once FEC ramped, every packet of a maximal block failed `total > max_total_shards`, the block never accumulated a shard, the frame aged out, and the resulting loss drove FEC higher still — large frames wedged at 100% loss exactly when FEC was meant to rescue the link. Fixed on both sides, because hosts and clients update independently: the sender clamps per-block parity to the ceiling the peer negotiated, and the receiver sizes that ceiling from the whole clamp range rather than a stale snapshot of it. No wire bytes and no C ABI signature change; WIRE_VERSION and ABI_VERSION are unchanged. Regression tests cover all three (the punch tests were confirmed to fail without the fix). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-20 07:42:37 +02:00
enricobuehler	15d51bc0ff	Merge remote-tracking branch 'origin/main' into land/sweep-all	2026-07-20 00:46:41 +02:00
enricobuehler	e9a4c4a601	feat(security): add a user-writable plugin ingest inbox for cross-account data ... The LocalService runner can't traverse the interactive user's profile the way the old SYSTEM runner could — so a plugin can no longer read a file an app running as *you* produced (the acute case: the Playnite exporter's library JSON under %APPDATA%). Confirmed on-glass: as LocalService the glob finds nothing and the profile is un-traversable. Add the inverse of plugin-state: <config_dir>\ingest, granted BUILTIN\Users Modify by plugins enable (disable reverts to inherited Users:RX). An interactive-user app drops ingest\<plugin>\… and the de-privileged runner reads it there — the one Users-writable carve-out in the otherwise Users-read-only tree. SDK exports pluginIngestDir(name) to resolve it; on Linux the systemd --user runner owns the config dir so same-user producers write there with no grant. Accepted tradeoff: the inbox is writable by any local user (trusted-single- user model; it feeds only a LocalService runner). Consumers must treat ingest data as lower trust than their own state. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 00:45:27 +02:00
enricobuehler	fdbfa37e43	fix(cli): silence host capture/DPI/GPU startup noise on management subcommands ... A plain `punktfunk-host plugins add …` printed the host's startup banner and — on Windows — ran the win32u GPU-preference hook, whose DPI-awareness probe emits a scary `SetProcessDpiAwarenessContext … "access denied"` WARN. None of it is relevant to a package-manager command, and the WARN reads like a failure. Gate both behind is_management_cli(): plugins / openapi / library / detect-conflicts / driver / web / service-management verbs skip the banner and the DXGI hook. `service run` (the SCM-launched host) is explicitly NOT lightweight, so the hybrid-GPU ACCESS_LOST fix it depends on stays intact. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 00:45:27 +02:00
enricobuehler	73ec6ed9ef	feat(security): give the de-privileged runner a writable plugin-state dir ... The LocalService runner cannot write anywhere under %ProgramData%\punktfunk (the config dir is Users-read-only), so a state-writing plugin's saveCache / config-edit / first-run mkdir all fail EPERM — proven on-glass (rom-manager only looked fine because its state dir was pre-created by an admin run and a 0-title reconcile skipped the write). Add the one writable grant the model was missing, keeping the split crisp — code dirs RX+WA, secrets R, and now a dedicated state root RW: - plugins enable / build-scripting.ps1: create %ProgramData%\punktfunk plugin-state and grant LocalService (OI)(CI)(M); disable revokes. Users stay read-only, so another non-admin still can't tamper with a plugin's launch templates. - SDK: export pluginStateDir(name) -> <config_dir>/plugin-state/<name>. Same path on Linux (the systemd --user runner owns the config dir, writable with no grant), so plugins use one branch-free helper. Plugins must persist under pluginStateDir(), not straight under the config dir. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 00:45:27 +02:00
enricobuehler	84c47cd0a7	feat(security): run the Windows plugin runner as LocalService, not SYSTEM ... The PunktfunkScripting scheduled task ran operator-installed plugin code as SYSTEM with -RunLevel Highest — any plugin defect was a full compromise of the box. The principal is now NT AUTHORITY\LocalService (minimal privileges, no password to manage, exists at boot, loopback networking works), registered without RunLevel: - installer: New-ScheduledTaskPrincipal -UserId 'LocalService' - plugins enable: converges the principal idempotently (migrating tasks an older installer or a dev box registered as SYSTEM) BEFORE starting, then grants LocalService read — via icacls, full-System32-path — on exactly the two SYSTEM/Admins-DACL'd files the runner's connect() needs: the scoped plugin-token and the TLS-pin cert.pem. Never mgmt-token. plugins disable revokes the grants; plugins status now prints the task principal so the migration is verifiable. - build-scripting.ps1 mirrors the convergence + grants on dev deploys. The usage text also mentions the new --allow-public-registry gate that lands with the supply-chain commit. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 00:45:27 +02:00
enricobuehler	9b5ca0eff3	feat(security): scope the plugin runner to a capability-limited bearer token ... The scripting runner used to hold the console's full-admin mgmt-token — a plugin defect could rewrite hooks.json (arbitrary command execution) or administer pairing. The host now mints a second persisted secret, plugin-token (PUNKTFUNK_PLUGIN_TOKEN), and require_auth grows a third lane for it: loopback-confined like the admin token, but plugin_may_access carves out /hooks (read AND write), everything under /pair, /native/pair, /native/pending, client unpair DELETEs, and other plugins' ui-credential. Everything a plugin legitimately does (status/library/events/sessions, its own UI lease) is untouched. The SDK's zero-config connect() now prefers PUNKTFUNK_PLUGIN_TOKEN / plugin-token over mgmt-token, so plugins pick the scoped credential up automatically; a script that genuinely needs the admin surface sets PUNKTFUNK_MGMT_TOKEN explicitly. Old hosts without a plugin-token fall back to mgmt-token unchanged. No OpenAPI change: the lane is auth-layer only. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 00:45:27 +02:00
enricobuehler	1e8b267d93	Merge branch 'fix/vulkan-open-leak' into land/sweep-all	2026-07-20 00:43:19 +02:00
enricobuehler	dafab58943	Merge branch 'fix/round1-highs' into land/sweep-all	2026-07-20 00:42:38 +02:00
enricobuehler	1dcba4dffa	Merge branch 'fix/encode-medium-tier' into land/sweep-all	2026-07-20 00:42:32 +02:00
enricobuehler	a784682d4c	fix(client/net): split the receipt stamp from the pull + bleed standing latency ... The two-pair investigation (wired Mac clients stuck at a rock-steady ~18-19 ms "network" that survived the load ending and cleared only on reconnect) exposed two structural gaps, one of measurement and one of recovery: - Receipt was stamped at the hand-off PULL (Swift nextAU, pf-client-core, Android decode loops), not at reassembly completion — so any client-side standing state between the reassembler and the pull read as NETWORK latency, undiagnosable from the HUD. ABI v9: `PunktfunkFrame`/`Frame` grow `received_ns`, stamped by `Session::poll_frame` as the AU crosses the session boundary. Every embedder now uses the core stamp; the Apple client keeps the pull instant as `AccessUnit.pulledNs` and shows the receipt→pull wait as its own "client queue" term (detailed HUD tier from 2 ms + a `queue_p50` stats-log field). Decode stages keep their pull anchor on all platforms, so no historical stage shifts meaning. - The jump-to-live detectors deliberately ignore anything under 6 queued frames / 400 ms behind — so a small, constant, loss-free elevation (a sub-frame standing backlog, or a stale clock offset after a wall-clock step/slew) is carried for the rest of the session. New third detector (`StandingLatency`, unit-tested ladder): window-MIN one-way delay ≥ 10 ms above the session floor with zero loss for ~4.5 s escalates gently — a free clock re-sync first (an applied re-sync re-bases the floor), then at most 3 flush+keyframe bleeds sharing the jump-to-live cooldown, then a loud disarm naming what it means. Loss windows reset the run: congestion belongs to FEC/ABR, not this detector. Also: mid-stream re-sync apply/discard logs debug→info — they are the forensic trail for the stale-offset case and were invisible in the field. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 23:38:11 +02:00
enricobuehler	134874b3c8	fix(client/windows): repair the v0.15.0 MSIX build — ARM64 feature leak + illegal XML comment ... Both MSIX matrix jobs failed at the v0.15.0 tag, for two unrelated reasons, both introduced by this release. 0.13.0 and 0.14.0 shipped both packages; 0.15.0 shipped neither. ARM64 failed to BUILD. The PyroWave Windows un-gating (1ef0229b) moved `pyrowave-sys` in pf-client-core out of `cfg(target_os = "linux")` into a general optional dependency that pf-client-core's own `default = ["pyrowave"]` turns on. The ARM64 leg builds `--no-default-features` precisely to skip it, but that only disables defaults for the two packages named with `-p` — every internal edge kept inheriting them: clients/windows -> pf-client-core, clients/session -> pf-client-core, clients/session -> pf-presenter, and pf-presenter's own `default = ["pyrowave"]` -> pf-client-core. So the vendored Granite C++ compiled on ARM64 and stopped where it always does: muglm.cpp reaching for _MM_TRANSPOSE4_PS/_mm_storeu_ps, then `simd.hpp:103 #error "Implement me."`. Those three internal edges now pass `default-features = false`; the feature is enabled only through an explicit chain (clients/session's `pyrowave` -> pf-client-core/pyrowave + pf-presenter/pyrowave, and pf-presenter's `pyrowave` -> pf-client-core/pyrowave), so `--no-default-features` finally means what it says. Verified by feature resolution rather than assertion — `cargo tree -i pyrowave-sys`: aarch64-pc-windows-msvc, --no-default-features -> not in the graph (was: present) x86_64-pc-windows-msvc, default features -> present x86_64-unknown-linux-gnu, default features -> present PyroWave is NOT dropped from the Windows client. Decode has always run in the spawned punktfunk-session binary, whose own default keeps the feature on, and unification turns it back on for the shared pf-client-core wherever that binary is in the build (x64, Linux). The shell only ever offered "pyrowave" as a codec preference string — it holds no decoder and never called one, so linking the C++ into it was dead weight even on x64. x64 built fine and failed at PACKAGING: `makepri new` rejected the manifest with PRI191 "Appx manifest not found or is invalid" / malformed comment syntax. The console tile added in 2508b720 documented its flag inside an XML comment, and XML forbids `--` anywhere in a comment body, so the literal flag spelling made the whole manifest unparseable. Reworded, with a note to keep the next person from reintroducing it. Confirmed by parsing both revisions after template substitution: the tagged manifest fails at line 63 col 9, this one parses. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 23:20:29 +02:00
enricobuehler	134fba1424	fix(inject): heap the SwDeviceCreate callback context; stop latching a pad slot on a failed create ... Two medium findings from the round-1 sweep, each applied to both siblings. - create_swdevice stack-allocated the SwCreateCtx that the async PnP completion callback writes through (result + up to 127 u16 of instance id) and then SetEvents. The wait is bounded at 10s, so on a wedged-PnP timeout the callback can still be PENDING: the frame is popped, the input thread reuses that stack, and a late callback corrupts it and SetEvents an already-closed (possibly recycled) handle. The context is now heap-allocated and reclaimed only where the callback provably ran; on the timeout path the box is deliberately leaked and the event left open, so a late write always targets live memory. Costs a one-off ~264 B + one HANDLE on that rare path. Applied to the DualSense path and its XUSB sibling in gamepad_windows.rs. - Ds4WinPad::open swallowed a create_swdevice failure into a WARN and returned Ok with no devnode. PadSlots::ensure then stored Some(pad) AND called gate.on_success(), so the slot short-circuited on is_some() forever and the capped-backoff retry that exists precisely to self-heal a transient PnP failure never ran — the game saw no controller for the rest of the session unless the client unplugged the pad. Now propagates, matching the XUSB sibling. Same fix applied to steam_deck_windows.rs. Windows .173: pf-inject 53/0. Linux .21: pf-inject 74/0 (8 ignored). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 23:19:19 +02:00
enricobuehler	fe4af1761e	fix(capture): stop stranding a PipeWire buffer on a caught panic; invalidate the PyroWave CSC on ring recreate ... Two medium findings from the round-1 sweep. - The `.process` callback dequeued a buffer INSIDE its `catch_unwind`, and every requeue site was inside too. `newest` is a raw pointer with no Drop, so any caught panic (update_cursor_meta / consume_frame) unwound past all three requeues and permanently stranded that buffer. Once the stream's fixed pool drained, `dequeue_raw_buffer` returned null every call and capture silently wedged while still reporting negotiated/active — defeating the very catch_unwind that was meant to keep a panic survivable. The drain loop now runs OUTSIDE the catch (dequeue/queue are non-panicking C FFI pointer ops) and `newest` is requeued exactly once after it, on every path: normal, corrupted-skip, or caught panic. - `recreate_ring` invalidated `video_conv` and `hdr_p010_conv` but not `pyro_conv`. That converter is mode-baked — BgraToYuvPlanes selects entirely different shaders and output formats for SDR (8-bit BT.709 → R8/R8G8) vs HDR (scRGB→PQ BT.2020 → R16/R16G16) — and `ensure_pyro_conv` only builds when None, so a display_hdr flip reused the stale SDR converter against a freshly HDR-formatted pyro ring, corrupting every frame. Reachable at the documented "Downgrade point D": a PyroWave session with client_10bit=true that opens on a box where HDR can't enable, then flips once the display comes up. Linux .21: pf-capture 1/0. Windows .173: `cargo check -p pf-capture` clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 23:16:25 +02:00
enricobuehler	26ff005e70	fix(zerocopy): error-path leaks, exception-safe fence wait, odd-height NV12 overrun, worker reaper deadline ... Seven medium findings from the round-1 sweep, all in pf-zerocopy. Adjudicated against source; all zero-copy-preserving (no GPU→CPU→GPU roundtrip introduced). - import_src (vulkan.rs) leaked a VkBuffer + VkDeviceMemory + dup'd fd on every fallible step before the success-only src_cache.insert. A failed import is survived by the worker and RETRIED by the caller every frame, so this leaked per frame for the worker's whole lifetime. Now owns the dup fd via OwnedFd (closes on early return until Vulkan consumes it at allocate_memory) and destroys the buffer + frees memory on each error path. - ensure_dst destroyed the old exportable buffer and nulled self.dst BEFORE building the replacement, so a failed rebuild both dropped the working buffer and leaked every object the partial rebuild created (raw ash handles, no Drop; VkBridge::drop only frees the live self.dst). Now builds fully, unwinds each error locally, and swaps only on success. - The submit→wait→reset sequence in import_linear_nv12 / import_linear `?`-ed out of wait_for_fences BEFORE reset_fences on a TIMEOUT/DEVICE_LOST, leaving the shared self.cmd PENDING and self.fence IN-USE while the caller retries on the same bridge (and ensure_dst later destroys dst.buffer assuming nothing is in flight). Now drains the GPU (device_wait_idle) and resets the fence before propagating — fixing the reported ensure_dst UAF at its source. - copy_pitched_nv12_to_buffer writes height.div_ceil(2) chroma rows into a UV plane sized at height/2, so an odd height overruns by one uv_pitch row (OOB device write / CUDA_ERROR_ILLEGAL_ADDRESS). Added the even-dimension guard to import_linear_nv12, matching Nv12Blit/Yuv444Blit. - sweep_reaper only reaped already-exited workers, so a worker wedged inside a driver call lingered forever holding its CUcontext + BufferPool (hundreds of MB VRAM). Now force-kills a child parked past REAPER_KILL_DEADLINE (20s). Compile + tests green on Linux .21 (RTX 5070 Ti): pf-zerocopy 17/0. The error paths themselves are not fault-injected; the fixes are structural. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 23:10:06 +02:00
enricobuehler	986402f731	fix(inject,zerocopy,capture): teardown deadlock, GL→CUDA copy race, cursor-meta OOB read ... The three high-severity defects from the round-1 sweep of pf-inject / pf-zerocopy / pf-capture (adjudicated against source — all 7 reported criticals in these crates downgraded; these were the real highs). - pf-inject steam_gadget: `SteamDeckGadget::drop` set `running=false` then joined the control thread, which spends steady state parked in a blocking, no-timeout `EVENT_FETCH` ioctl that only tests `running` at its loop top. The flag never reaches it, closing the fd can't wake an in-flight ioctl (the syscall holds a file reference, and the fd is shared via Arc by the very threads being joined), so the join hung — and it runs on the session input thread via `PadSlots::sweep`, driven by the client's `active_mask`, so a remote peer clearing its pad bit could freeze all session input. Now wakes the parked threads with SIGUSR1 (no-op, non-SA_RESTART handler → the ioctl returns EINTR and the loop exits), retried until each reports done and bounded (~1s). - pf-zerocopy cuda: the GL→CUDA "sync point" was never established for the copy. `cuGraphicsMapResources`/`UnmapResources` were issued on the NULL stream, but the D2D copy runs on `copy_stream()`, a `CU_STREAM_NON_BLOCKING` stream exempt from implicit NULL-stream ordering — and the GL de-tile/CSC that produced the texture ends with only `glFlush` (no fence). So the copy could race ahead of the not-yet-retired GL draw: intermittent stale/torn frames under GPU load, on the default NVIDIA capture→encode path. Map, copy, and unmap now share `copy_stream()`, so map's device-side guarantee orders the GL work before the copy. Zero-copy preserved (no GPU→CPU→GPU roundtrip). - pf-capture cursor meta: `update_cursor_meta` trusted three producer-written fields (bitmap_offset, pixel offset, stride) with no bound against the metadata region, driving OOB pointer arithmetic and an oversized `from_raw_parts` — an OOB read that SIGSEGVs inside the PipeWire `.process` callback (uncatchable by the surrounding `catch_unwind`). Switched to `spa_buffer_find_meta` to obtain the region's real `size` and validate every offset with checked arithmetic before each deref/slice, mirroring the fd-length guard the main frame path already applies. Compile + existing tests green on Linux .21 (real RTX 5070 Ti): pf-inject 74/0, pf-zerocopy 17/0, pf-capture 1/0. The gadget deadlock path only executes on a SteamOS host with raw_gadget/dummy_hcd (not reproducible on the CachyOS box), so that fix is reasoned + compile-verified, not runtime-exercised. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 22:53:15 +02:00
enricobuehler	28491acf2a	fix(encode): unwind Vulkan Video open failure instead of leaking every prior object ... VulkanVideoEncoder::open_inner creates ~20 Vulkan objects across ~15 fallible steps, but all cleanup lived in the encoder's Drop — which only runs once the value exists at the final Ok(Self). Any earlier ?/bail! leaked everything built so far (a VkDevice + GPU memory per retried open, and this backend is the default encode path on AMD/Intel Linux hosts where open can fail transiently). Factor the entire teardown sequence — unchanged — into a VkTeardown guard whose Drop destroys any prefix of the build (vkDestroy*/vkFree* are defined no-ops on VK_NULL_HANDLE): open_inner mirrors each object into the guard as it is created and disarms it only at Ok(Self); the encoder's own Drop rebuilds one from its fields, so both paths share one sequence and cannot drift. make_frame now builds in place into a guard-parked null Frame so a mid-build failure unwinds its partial handles too, and make_video_image / vk_util::make_plain_image (also used by the PyroWave backend) / build_parameters_h265 no longer leak their own partially-created objects on failure. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 22:15:44 +02:00
enricobuehler	b0fbb80fd5	fix(encode): key the PyroWave plane-import cache on the capturer's ring generation ... Completes the partial fix from the previous commit. The Windows PyroWave backend caches its imported plane images keyed on the D3D11 texture's COM address, and holds no reference on that texture — so once the capturer recreates its ring, those addresses can be handed straight back out by the allocator and a pointer-keyed cache hit returns an image bound to a texture that no longer exists. Adding the extent to the key ruled out same-address-different-size aliasing, but a recycle at identical dimensions still aliased. The capturer already tracks exactly the value needed: `generation`, bumped on every ring recreate. Plumbed it onto `PyroFrameShare` and the encoder now flushes every cached import when it changes, which makes cache identity independent of allocator behaviour rather than a bet against pointer reuse. Validated on the RTX box: `pyrowave_win_smoke` (forced with `--ignored`, the only test that actually exercises this path on real hardware) passes all ten configurations — 1024²/720p/1080p/1440p across SDR/HDR and 4:2:0/4:4:4 — with correct decoded chroma means, so the steady-state cache-hit path still works. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 21:45:14 +02:00
enricobuehler	6f52397342	fix(encode): bound NVENC async pipelining by the capturer's texture ring ... The Windows direct-NVENC backend registers and encodes the capturer's textures IN PLACE (no CopyResource), so how deep it may pipeline is a property of the CAPTURER, not of the encoder. It was bounded only by `async_inflight_cap()` — `PUNKTFUNK_NVENC_ASYNC_DEPTH`, default 4, clamped to the output-bitstream pool — which consults nothing about the capturer, while the comment at the backpressure loop claimed it "keep[s] in-flight depth within the capturer's texture ring". It never did. The IDD-push capturer rotates `OUT_RING = 3` per delivered frame with no regard for encode completion (its own invariant note says OUT_RING(3) > max pipeline_depth(2)). With the default async depth of 4 the encoder can therefore still be reading a texture the capturer has already handed out again and overwritten: torn or mixed frames. It is visual corruption rather than UB, so it fails silently and intermittently — the worst shape to diagnose from a field report. Adds `Encoder::set_input_ring_depth`, reported from `Capturer::pipeline_depth`, and bounds the async backpressure loop by `min(async_inflight_cap(), depth)`. For IDD-push that yields 2, matching the capturer's stated contract; backends that copy their input, or are synchronous, ignore it. Wired at ALL THREE encoder-creation sites (initial open, stall/resize rebuild, ABR rebuild) and forwarded through `TrackedEncoder` — this crate has a documented trap where an unforwarded defaulted trait method silently no-ops through that wrapper, which has already bitten the direct-NVENC work once and the wire-chunking probe once. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 21:42:53 +02:00
enricobuehler	a38adad943	fix(encode): bound GPU waits, validate encode status, repair command-buffer and cache invariants ... Five of the nine medium findings from the pf-encode sweep. The remaining four need cross-crate plumbing or an unwind refactor and are deliberately left out. - vulkan_video `enqueue` waited on the backpressure fence with `u64::MAX`. That wait runs ON the host encode thread — the same thread the stall watchdog's `reset()` would run on — so a wedged GPU parked the one thread that could recover the session: no error, no reset, and teardown blocking on the join. This is the DEFAULT encode path for AMD/Intel Linux hosts (both shipped build recipes enable `vulkan-encode` and `vulkan_encode_enabled()` defaults true). Now bounded by ENCODE_FENCE_TIMEOUT_NS with expiry surfaced as an error. - vulkan_video `import_cached` evicted a cached dmabuf import and destroyed its image/view/memory with no fence wait, while up to `ring_depth - 1` submitted frames may still reference it — a GPU-side use-after-free. `Drop` and `reset` both idle first; this was the one unguarded destroy. Now idles before the eviction loop, guarded on the length test so the steady state pays nothing. - vulkan_video `read_slot` never asked for the encode's operation status, so a FAILED encode was indistinguishable from a successful one and its feedback was read as if it described real bitstream. Now requests WITH_STATUS_KHR and refuses anything that is not COMPLETE. - linux/pyrowave `encode_frame` opens its recording window early and has six fallible steps inside it; every one returned with `cmd` still RECORDING, and nothing repaired it (one `begin_command_buffer` in the file, and neither `reset()` nor `Drop` touches `cmd`), so the next frame called `begin` on a recording buffer — invalid usage. `submit` now resets the buffer on error; legal on all these paths since the pool carries RESET_COMMAND_BUFFER and the buffer is not pending. - windows/pyrowave `encode_frame` ignored `frame.width`/`height` and imported planes at the encoder's configured extent, so a ring recreate at a new mode (the IDD capturer does this autonomously on a confirmed descriptor change) read the planes under a stale VkImageCreateInfo. Added the size guard its QSV and AMF siblings already carry, and keyed the plane cache on (address, width, height) so a recycled COM address cannot resurrect an import of a different size. NOTE: a recycle at the SAME size is still theoretically possible; the complete fix keys on the capturer's ring generation and needs that plumbed onto `PyroFrameShare`. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 21:34:16 +02:00
enricobuehler	b22d0da75b	fix(encode): port the RFI taint sweep to Vulkan Video, close the QSV sweep hole, bounds-check encode feedback ... Three defects from the pf-encode sweep, each adjudicated against source. - Vulkan Video never received fecbec2d's taint sweep (it was carved out one commit later). `pick_recovery_slot` accepts any resident slot whose wire is below the CURRENT loss start, but "resident and older than this loss" is not "the client decoded it": after an earlier loss [a,b] recovered at wire r, everything in [a, r-1] is undecodable at the client — the lost frames plus every frame that predicted through the gap — and those wires stay eligible until the 8-slot ring rolls them out. A later loss could therefore anchor on one and ship it tagged `recovery_anchor`, which is the client's definitive re-anchor signal (punktfunk-core/src/reanchor.rs): the host lifts the client's post-loss freeze onto a picture built from a reference it never had. Swept before anchor selection, matching AMF/QSV. `slot_wire` is blanked and `slot_poc` deliberately is NOT: `slot_poc` feeds `build_h265_rps_s0`, which must keep naming every physically-resident DPB picture or a conforming decoder evicts them and the anchor then references a picture the client already dropped. - QSV's sweep was incomplete, and in its MODAL case. `ltr_slots` mirrors the hardware DPB, but nulling an entry issues no VPL call — the frame stays marked long-term until that LongTermIdx is re-marked or an IDR flushes it (amf.rs states this verbatim). The rejection loop iterates the post-sweep mirror and only rejects `Some` slots, so it silently skipped the single entry the sweep exists to distrust, leaving the recovery frame free to predict from it. With NUM_LTR_SLOTS=2 the "exactly one slot swept" case is the common one, and the two existing tests cover only the both-survive and both-swept cases. Taint is now recorded in `ltr_tainted` with the FrameOrder left in place, so anchor selection and the queued-force guard skip it while the rejection list still names it. - `read_slot` built a slice from the driver-reported (offset, bytes-written) encode feedback with no validation against `bs_size`, so a driver reporting a range outside the bitstream buffer produced an out-of-bounds read shipped straight onto the wire. Checked in u64 (so the add cannot wrap) before `map_memory`, so the error path has no unmap to unwind. Adds `taint_sweep_excludes_slots_from_an_earlier_loss` covering the two-loss case the existing single-loss test does not reach. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 21:18:17 +02:00
enricobuehler	f9668b16a1	fix(encode): NVENC partial-init session leak + three backend-parity gaps ... All four found in the pf-encode quality sweep and verified against source. - NVENC partial-init leak (BOTH platforms, high): `init_session` publishes `self.encoder` — and on Windows charges LIVE_SESSION_UNITS — *before* its remaining fallible steps (bitstream buffers; on Linux also the input-surface alloc and `register_resource`). A failure there left a live session with `inited == false`, and every guard on the re-init path keys off `inited`, so the next submit skipped teardown and overwrote `self.encoder`: the session leaked permanently toward the driver's per-process cap, and its budget units never returned, progressively starving parallel-display admission. `teardown` already keys off `encoder.is_null()` rather than `inited`, so it cleans up exactly this half-built state — it just was never called. Now invoked on the `init_session` error path on both platforms. - `can_encode_10bit` asked the wrong backend (medium): it resolved via `linux_auto_is_vaapi`, which ignores `encoder_pref`, while `can_encode_444` and `open_video` honour it. On a host that forces a backend (e.g. `encoder_pref = "vaapi"` on an NVIDIA box) the probe answered for NVENC while the session opened VAAPI, so the negotiated bit depth — and the HDR/SDR colour label derived from it — described a backend that never ran. Now uses the same `linux_zero_copy_is_vaapi` mirror, and `linux_auto_is_vaapi` carries a warning that it resolves the `auto` case only and is not a dispatch mirror. - Linux software arm ignored SW_BITRATE_CEIL (low): the Windows arm clamped openh264 to 100 Mbps, the Linux arm passed the full negotiated rate. The constant is now module-scope so both arms share one value. - QSV/AMF env-parity (low): `PUNKTFUNK_IR_PERIOD_FRAMES` was a no-op on QSV despite the comment claiming parity with AMF, and `PUNKTFUNK_NO_QSV_LTR` / `PUNKTFUNK_INTRA_REFRESH` had dropped AMF's `trim()` and `yes`/`on` spellings, so a value with stray whitespace silently did nothing on Intel while the same value worked on AMD. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 20:47:55 +02:00
enricobuehler	04e4394ee0	fix(encode): close the two teardown memory-safety holes in the reset paths ... Both surfaced in a post-refactor quality sweep of pf-encode and were then verified against the source (and, for pyrowave, against the C side). - PyroWave (BOTH platforms): `reset()` destroyed the encoder and, when the rebuild failed, returned `false` leaving `pw_enc` pointing at the freed object — `Drop` then destroyed it a second time. `pyrowave_encoder_destroy` is a plain `delete` (pyrowave_c.cpp:1184, which also reads `encoder->device` afterwards) with no null check, so this is a real double free. The failure branch is not vacuous: the rebuild fails when the device is lost/OOM, which is exactly the state that makes the stall watchdog call `reset()` in the first place, so the host corrupts its heap on the path that runs when things are already going wrong. Now nulls `pw_enc` before the fallible create, publishes only on success, and null-guards both `Drop` and `encode_frame` (the Windows `Drop` already guarded `sync` this way). - QSV: `reset()` dropped `pending` — each entry owning the `Box<BsBuf>` the runtime writes into asynchronously — BEFORE `MFXVideoENCODE_Close` aborted those operations, so the VPL runtime could write into freed heap. The preceding drain is best-effort and bails on the first `Err`, i.e. precisely the wedged-encoder case that triggers the reset. Fixed by ordering: Close, then clear. The full-teardown path was already correct (`Inner` declares `session` before `pending`, and fields drop in declaration order). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 20:07:57 +02:00
enricobuehler	c2bba13405	feat(host/web): per-scanner library toggles in the console ... Every installed-store scanner (Steam; Lutris+Heroic on Linux; Epic/GOG/ Xbox on Windows) was hardwired on. New library-scanners.json persists the operator's disabled set (default all on; absent/malformed = all on); all_games() gates each provider, so disabling one hides its titles from every surface (console grid, native clients, GameStream app list, launch resolve). GET /library/scanners lists this platform's scanners + state; PUT /library/scanners/{id} toggles and emits library.changed — admin lane only (the cert allowlist's exact-path /library match keeps both off the LAN surface). The console's Library page grows a "Game sources" card with one chip per scanner (platform-shaped by the API), EN+DE strings, story. The scanners are slated to become plugins; the stable per-scanner ids are the migration seam. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 19:58:05 +02:00
enricobuehler	940a260506	fix(host): retry the audio first-open instead of running the session silent ... Session start is peak endpoint churn on Windows — the virtual-display attach and the wiring plan's own IPolicyConfig default flips race the first WASAPI activate, which then fails transiently (IAudioClient 0x80070002, endpoint mid-re-registration) — and a first-open failure killed audio for the WHOLE session: wasapi_cap's capture thread sent the error through the ready handshake and exited, and the native plane's audio thread returned instead of entering its reopen loop (each layer's comment claimed the other retried; neither did). Two-layer fix: the WASAPI capture thread gives the first open three attempts a second apart before failing the handshake, and the native audio thread treats a failed first open like a mid-session capture death — it enters the existing reopen-with-backoff loop, so audio starts a few seconds late instead of never. The GameStream plane gets the WASAPI-level retry for free. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 19:37:03 +02:00
enricobuehler	40c2f68231	feat(client): device-pick plumbing — GPU enumeration + audio endpoint targeting ... The Settings GPU pick existed (adapter → PUNKTFUNK_VK_ADAPTER) but no Linux shell could enumerate anything to pick: the GTK shell deliberately links no Vulkan. pf_presenter::vk::list_adapters() reads the physical devices' marketing names (no surface, discrete first, deduped — the name is the whole match key in pick_device), surfaced as `punktfunk-session --list-adapters`. Audio gets the same treatment for the new speaker_device/mic_device settings (PipeWire node.name; empty = default): session main maps them onto PUNKTFUNK_AUDIO_SINK/SOURCE — a hand-set env still wins, like the adapter — and the playback/mic streams pass them as `target.object` (raw key: the keys::TARGET_OBJECT constant is feature-gated on a newer libpipewire than we require). pf_client_core::audio::devices() is the registry roundtrip the pickers read, exposed for debugging as `punktfunk-session --list-audio`. The WASAPI leg (Windows endpoint IDs) is still to come; the fields are ignored there. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 19:32:38 +02:00
enricobuehler	8fe90a8a4b	fix(client): clipboard poll cadence was never applied (and CI clippy) ... POLL was dead: the local clipboard was re-read once per inbound event wait (<=120 ms) instead of on its own 400 ms cadence, so the constant documenting the interval described something the code did not do. Give it a deadline of its own -- the event wait is short because it bounds teardown latency, which is no reason to hammer the Win32 clipboard eight times a second while the user is copying in another app. Build State in one expression while here, and note for next time: CI runs clippy as --workspace --all-targets -- -D warnings, so a scoped run without -D warnings (what I did) does not reproduce it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 19:22:24 +02:00
enricobuehler	aa45757a72	feat(client/windows): per-host clipboard toggle ... The bridge landed always-on whenever the host permitted it; sharing a clipboard is a trust decision about a specific host, so it needs to be opted into. Mirrors the Apple client's per-host model (StoredHost.clipboardSync, "Share clipboard with this host") rather than a global switch: KnownHost::clipboard_sync, toggled from the host card's overflow menu, default off. The session binary resolves the stored flag itself in session_params, so a direct connect and the console's own launches honor the same decision without every caller having to remember to pass it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 19:06:06 +02:00
enricobuehler	cab6350723	feat(client): shared clipboard on Windows ... The protocol half has been in punktfunk-core since the clipboard work landed -- the per-session fetch task, plus clip_control/clip_offer/ clip_fetch/clip_serve/next_clip on NativeClient -- but only the Apple client ever drove it, through the C ABI. The Windows and Linux clients link the core directly and simply never wired it, so copy-paste between host and client worked on a Mac and nowhere else. This adds the missing half: the OS-clipboard bridge, on its own session thread beside the audio one. Local -> remote stays lazy by construction, as the design asks: a GetClipboardSequenceNumber poll spots a local copy and we announce only the FORMAT LIST; bytes are read when (and only when) the host actually pastes and sends a FetchRequest. Remote -> local is EAGER in this first cut, which is a deliberate deviation worth naming. macOS gets laziness free from NSPasteboardItemDataProvider; the Windows equivalent is delayed rendering, which needs a clipboard-owning window running its own message pump. So we fetch on the offer and place real bytes under a 4 MB cap -- text always crosses, a large image is skipped rather than pulled for a paste that may never come. Delayed rendering lifts the cap later. Echo suppression is the design's Windows rule verbatim (capture the sequence number right after our own SetClipboardData); without it every copy ping-pongs between the machines forever. Content marked ExcludeClipboardContentFromMonitorProcessing -- what password managers set -- is never announced and never served. Text and PNG for now. Apps that publish only CF_DIB need the conversion the host already has. Linux keeps a stub: the bridge itself is platform-neutral and will drive a data-control seam unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 19:06:06 +02:00
enricobuehler	51f7ff1b3f	feat(client/windows): invert scroll direction ... The Apple client's toggle, wired through the shared session presenter: Settings::invert_scroll -> SessionOpts -> Capture, applied at the single seam where wheel deltas enter (before accumulation, so the fractional remainders stay consistent with what was actually sent). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 19:06:06 +02:00
enricobuehler	7a1809547b	fix(client/windows): left-align setting captions, drop the width cap, add auto-wake ... Three follow-ups to the parity sweep: - Captions read centred: a TextBlock defaults to Stretch alignment, so the MaxWidth cap left it floating in the middle of the leftover width instead of sitting under its control. Pin them (and the footers) Left. - The settings column kept the shared page() 640px cap, which -- next to the NavigationView pane spending the left third -- squeezed the cards into a narrow ribbon. Drop the cap here. - Auto-wake on connect (the Apple client's toggle) is now a setting rather than unconditional behavior. Default on, which is what it did before. Gating the flow's ENTRY, not its packet sends: with it off a failed dial just fails, instead of showing a "Waking..." wait that would never send a packet to end itself. The explicit "Wake" host-card menu action is deliberately NOT gated -- that is the user asking directly. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 19:06:06 +02:00
enricobuehler	1ef0229bd9	feat(client/windows): PyroWave decode + surface it in the GUI codec picker ... The decoder was gated to Linux because, when it landed, the Windows client still had its own in-process WinUI/D3D11 presenter and the PyroWave present path there was an open question. That client has since been retired: Windows now spawns the SAME Vulkan session presenter as Linux, and the decoder is plain Vulkan compute on the presenter's device (no fds, no dmabuf, no D3D11 interop), so the question that gated it answered itself. pyrowave-sys already builds on Windows too -- the Windows HOST encoder ships on it. So this is a port by un-gating: every cfg(all(target_os = "linux", feature = "pyrowave")) becomes any(linux, windows) -- decoder module, backend variant, Decoder::new_pyrowave, the CODEC_PYROWAVE advertisement, the session pump's opt-in/build/label arms, and the presenter's planar CSC pass. No new code. Then offer it in the Windows GUI, which is what prompted this. It stays preference-only (resolve_codec never auto-picks it) and a host or device that can't do PyroWave just falls back down the ladder to HEVC. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 19:06:06 +02:00
enricobuehler	fecbec2daf	fix(encode): make LTR-RFI loss recovery sound under sustained loss ... Field report (lid-closed Intel laptop, ~6-19% sustained loss): the stream never healed — permanent macroblock soup. Three stacked bugs: - QSV answered RFI with PreferredRefList only, a reorder HINT per the VPL spec — the recovery frame could keep predicting from tainted short-term refs. Now rejects every other DPB candidate (RejectedRefList) and caps L0 at one active entry (AVC/HEVC), matching AMF's hard ForceLTRReferenceBitfield / NVENC invalidation semantics. - Neither QSV nor AMF taint-swept LTR slots across losses: a slot marked inside the client's corrupt window became the "known-good" anchor of the NEXT loss, propagating corruption through every recovery. Both now drop slots at-or-after the loss start before picking an anchor, and guard a queued force whose slot the sweep emptied (no false recovery_anchor tag). - The native plane re-anchored the FULL IDR cooldown on every successful RFI, so under sustained loss the client's escalating keyframe requests were coalesced away indefinitely (field log: dozens swallowed, one IDR per ~8 s). RFI now anchors a 300 ms echo window with a 2-swallow budget per loss episode; a client still asking past that gets its IDR. Live-validated on Arc (qsv feature): 6/6 including the new qsv_live_ltr_rfi_taint_sweep_declines (a loss covering every live mark declines the RFI and falls back to IDR recovery). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 17:53:48 +02:00
enricobuehler	0b8e8312a5	fix(gamestream): announce the stream marker + lifecycle events on the compat plane ... Only the native punktfunk/1 loop announced the script-facing marker file, so a Moonlight session left it absent and wrapper scripts took their "not streaming" branch mid-stream. The GameStream plane now announces before run() (the marker must exist when the title's wrapper executes) and retracts before client.disconnected, keeping the native loop's event order; StreamRef call sites carry the plane/launch fields. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 16:34:43 +02:00
enricobuehler	f0c511c8fa	feat(plugins): punktfunk-host plugins CLI — add/remove/list/enable/disable/status ... One-liner plugin management replacing the manual scripting-dir + bunfig + bun-add ritual: package ops forward to the bun runner (new sdk plugins module + runner-cli subcommands, 11 tests green), enable/disable/status drive the systemd unit on Linux and the PunktfunkScripting scheduled task on Windows (installer support in the ISS). Docs page rewritten as .mdx with per-platform Tabs (registered in mdx.tsx). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 16:34:43 +02:00
enricobuehler	d2daeacc60	fix(pyrowave): per-session raw-dmabuf zero-copy capture on the Linux NVIDIA host ... A PyroWave session on an NVIDIA-auto host was forced onto CPU-RGB capture (session_plan flipped gpu=false): Mutter blits tiled->LINEAR, we mmap + de-pad ~30 MB, the encoder re-uploads it - three full-frame CPU touches per frame at 5120x1440 while an HEVC session on the same box rides the tiled EGL/CUDA zero-copy. The dmabuf passthrough + Vulkan tiled import were already validated (8dc5d672) but only reachable via the global PUNKTFUNK_ENCODER=pyrowave lab policy. ZeroCopyPolicy gains pyrowave_session (from OutputFormat.pyrowave, i.e. the negotiated codec): the capturer skips the NVENC-only EGL->CUDA importer, takes the raw-dmabuf passthrough, and advertises the wavelet encoder's Vulkan-importable modifiers so Mutter+NVIDIA negotiates tiled zero-copy. The forced-CPU flip in session_plan is gone. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 16:25:00 +02:00
enricobuehler	1d587a259e	fix(client/d3d11va): green bar at the bottom — clamp the blit to the frame ... The decode surface is DXVA-aligned (height rounded up to the profile's alignment, 128 for HEVC/AV1), so it is taller than the frame: a 2400-line stream decodes into a 2432-line texture. VideoProcessorBlt was called with no stream source rect, so it blitted the WHOLE surface — the uninitialized padding rows (NV12 Y=0,U=V=0, which converts to vivid green) landed at the bottom of the output and the picture was squashed to fit. Set the source rect to the real frame. Pre-existing on this backend, but 40030e90 made D3D11VA auto's first choice on Intel, so it went from a corner case to what every Intel user sees — a ~32 px green bar at 3840x2400, reported on glass within the hour. Also dedupe the Settings GPU picker by description: that string IS the identity downstream (persisted as Settings::adapter, matched by name as PUNKTFUNK_VK_ADAPTER), so repeated enumerations of one adapter offered the user the same choice twice — live on an Intel Arc laptop, whose Vulkan ICD also enumerates the single physical iGPU twice. Both paths now log their raw enumeration (decode texture dims; DXGI name/LUID/ids) for the next report. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 14:44:05 +02:00
enricobuehler	fb8deb31a5	feat(client): HDR pass-through on the D3D11VA path ... A PQ stream on the D3D11VA backend was always tone-mapped to sRGB by the VideoProcessor — with D3D11VA now auto's first choice on Intel (40030e90), Intel Windows users would have lost HDR entirely. When the presenter can import an RGB10A2 D3D11 texture AND offers an HDR10 swapchain (the new VulkanDecodeDevice::d3d11_hdr10 probe), the hand-off ring switches to RGB10A2 and the VideoProcessor does a pure colorspace conversion (YCbCr G2084 -> RGB G2084, no tone mapping); the emitted frame carries PQ/BT.2020 color, so the presenter flips its HDR10 swapchain and video image exactly as it does for Vulkan Video PQ frames, and the blit passes the PQ values through untouched. SDR-only paths keep the tonemap-to-sRGB BGRA8 ring; in-band PQ flips rebuild the ring like a resize (generation-bumped). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 14:19:35 +02:00
enricobuehler	40030e90c8	fix(client): vendor-aware Windows decode order — D3D11VA first on Intel ... Intel's Windows driver advertises Vulkan Video (Arc drivers since 2023), so the capability gate alone no longer keeps Intel off FFmpeg-Vulkan — and that combination is broken in the field (B580 report: strobing + 7.2 ms p50 decodes at 4K120) and on glass (Arc Pro iGPU: 29-33 ms p50 decodes at 4K60 where D3D11VA does 2.5 ms on the SAME GPU). Mirror the Linux vendor order on Windows: NVIDIA/AMD keep Vulkan Video first, Intel/unknown take D3D11VA first; vulkan stays reachable by explicit preference and as auto's fallback. Also: - Vulkan→D3D11VA mid-session demotion rung (the Windows analog of Linux's Vulkan→VAAPI rung) — a failing Vulkan backend lands on hardware, not on software, which cannot survive 4K120. - The demotion streak now needs 1 s of age as well as 3 consecutive errors: a startup loss burst produced 3 errors in 20 ms and stranded the session on software decode (one-way) before the IDR requested on the first error could possibly arrive — live-hit on the Intel iGPU leg. - Stale "Intel's Windows driver has no Vulkan Video" comments corrected, docs updated to the per-vendor order, vendor-order test extended with discrete/iGPU Arc cases. Verified on an Arc Pro iGPU + RTX 3500 Ada laptop against a CachyOS/NVENC host: auto now picks d3d11va on Intel (60 fps, 2.5-2.8 ms decode, e2e 26 ms vs 50 ms before) and still picks vulkan on NVIDIA. 27/27 pf-client-core tests, clippy clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 14:04:32 +02:00
enricobuehler	99a1d1bed6	fix(pf-capture): don't require a libspa that exports SPA_VIDEO_TRANSFER_SMPTE2084 ... The GNOME 50 HDR format offer took the PQ transfer id straight from pw::spa::sys, which only exists on libspa new enough to carry the BT2020_10/SMPTE2084/ARIB_STD_B67 block. Ubuntu 24.04 (noble) — the .deb host builder — ships older headers, so bindgen emitted no such constant and the host failed to compile there: error[E0425]: cannot find value `SPA_VIDEO_TRANSFER_SMPTE2084` in crate `pw::spa::sys` This never showed up locally or on the Linux CI: both run a current PipeWire, where the binding is present. It broke deb.yml's build-publish-host job, so v0.14.0 published its client .debs but no host .deb. Spell the id out (14) instead. It's wire ABI, not a private detail — SPA mirrors GStreamer's GstVideoTransferFunction and that block was added as a unit, so the value is the same on every libspa that has the symbol. On one that doesn't, PipeWire fails to intersect the offer and the session negotiates SDR, which is what an HDR-incapable host should do anyway (the path needs GNOME 50+ regardless). A test pins our value against pw::spa::sys wherever the symbol exists, so a renumbered enum fails loudly instead of silently mis-tagging the transfer function. It only builds where tests are compiled — the .deb/.rpm builders run plain `cargo build`, so it can't reintroduce the failure it guards. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 11:17:15 +02:00
enricobuehler	2123e4e580	fix(host/rtsp): scope the HDR mut allow so Windows clippy stays green ... `let mut hdr` tripped -D unused_mut on Windows: the only reassignment is the GNOME colour-mode probe below it, which is #[cfg(target_os = "linux")]. Dropping `mut` would break the Linux build, so allow unused_mut on non-Linux only — the lint still fires on Linux if that probe is ever removed. Second Windows-only breakage in this release that the Linux CI cannot see (see also the ffmpeg_win swscale match): `cargo clippy --workspace` on the Linux runner never compiles cfg(windows) code, and the Windows job builds only punktfunk-host + punktfunk-tray. Verified: cargo clippy --release -p punktfunk-host --features nvenc,amf-qsv,qsv -- -D warnings on 192.168.1.173. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 10:36:32 +02:00
enricobuehler	232b41e88b	fix(pf-encode/windows): cover the Linux HDR pixel formats in the win swscale match ... The GNOME 50 HDR work added PixelFormat::X2Rgb10 / X2Bgr10 but only taught the Linux encoders about them. `sws_src` in the Windows-gated ffmpeg_win.rs matches PixelFormat exhaustively, so the Windows host stopped compiling: error[E0004]: non-exhaustive patterns: `X2Rgb10` and `X2Bgr10` not covered --> crates\pf-encode\src\enc\windows\ffmpeg_win.rs:132:14 Linux CI never caught it — the file is cfg(windows), so `cargo clippy --workspace` on the Linux runner never compiles it. Both are Linux-only screencast formats (the Windows HDR path stays Rgb10a2/P010, per the PixelFormat docs), so they join the existing bail arm. Spelled out rather than folded into a `_` catch-all so the next PixelFormat addition breaks this match again on purpose. Verified: cargo check --workspace --all-targets --features nvenc,amf-qsv on the Windows box (192.168.1.173). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 10:30:33 +02:00
enricobuehler	59b766fb6c	chore(release): bump workspace version to 0.14.0 ... MINOR, not patch: 31 commits since v0.13.0 carry 10 features, including a new /api/v1/plugins surface with a regenerated OpenAPI spec + SDK client. Since sdk-publish pushes this version to consumers, a patch bump would understate a new API surface for anyone pinning ~0.13. Headline work: GNOME 50 HDR screencast capture + Linux Main10 encode, PyroWave 4:4:4 + HDR end to end (Linux/Windows/Apple), the console-hosted plugin UI surface, and the pyrowave perf work that lifted the 2.5 Gbps wall. Notable fixes: the RSA host-identity keygen that broke every fresh Windows install on 0.13.0, and SDR negotiation on the Windows IDD-push path. pf-clipboard / pf-inject / pf-vdisplay were still hardcoding 0.12.0 — the three the 22b352c1 sweep missed. Switched to version.workspace = true so the next bump stays one line. (fec-rs, pf-driver-proto and usbip-sim are deliberately versioned independently and stay put.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 10:25:27 +02:00
enricobuehler	00f759ec72	style(pf-encode): clear the clippy gate on the HDR/PyroWave additions ... `cargo clippy --workspace --all-targets --locked -- -D warnings` was red on main — three lints landed with the GNOME 50 HDR + PyroWave 4:4:4 work: * pyrowave_wire.rs: `aw / 2 >> level` tripped clippy::precedence. Rust already binds `/` tighter than `>>`, so this always parsed as `(aw / 2) >> level` (subband dim at half res, then one halving per DWT level) — the parens are purely explicit, no change in behaviour. * linux/mod.rs: `probe_can_encode_10bit` sat after `mod hdr_tests` (clippy::items_after_test_module) — moved above the test module, unchanged. Lint-only; no functional change. fmt/clippy/test all green afterwards. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 10:23:47 +02:00
enricobuehler	a83acf3ee1	style(fmt): rustfmt the GNOME 50 HDR files under the pinned toolchain ... `feat(hdr): GNOME 50 HDR screencast capture` (0e977817) landed with rustfmt drift — six files were not clean under the pinned 1.96.0 toolchain, so `cargo fmt --all --check` (ci.yml "Format") is red on main. Pure whitespace/ wrapping from `cargo fmt --all`; no semantic change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 10:09:34 +02:00
enricobuehler	3ae5f222d3	fix(hdr): honor SDR negotiation on the Windows host IDD-push path ... A Windows client with HDR off (video_caps=0) negotiates bit_depth=8, but the H.26x IDD-push capture composition FOLLOWED the virtual display's live "Use HDR" state rather than the negotiated depth. On a display whose advanced color was on — leftover from a prior 10-bit session on a reused monitor, the driver default, or the host's global toggle — the capturer emitted P010 and NVENC stamped HEVC Main10 + BT.2020 PQ from the pixel format alone (the in-band HDR upgrade). That 10-bit PQ stream reached a client that advertised SDR-only; on a client whose monitor is HDR-capable but has "Use HDR" off, the PQ landed on an SDR desktop and blew out. Make client_10bit authoritative for the composition depth on BOTH codecs, mirroring the PyroWave branch that already did this: * setup: force advanced color OFF for any !client_10bit session (was pyrowave-only), settling before the ring is sized; * display_hdr gates on client_10bit alone, so an SDR-negotiated session composes SDR even if a physical display forces HDR; * the descriptor poller re-asserts SDR against a mid-session "Use HDR" flip for any SDR-negotiated session (an HDR-negotiated H.26x session still follows flips both ways — its encoder re-inits on the depth change). Only Punktfunk's virtual display is touched, never the host's real desktop. Not yet on-glass; the client-side robustness fix (presenter should tone-map PQ on an SDR-mode display instead of taking an HDR10 swapchain) is a follow-up. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 10:01:17 +02:00
enricobuehler	0e977817f9	feat(hdr): GNOME 50 HDR screencast capture + Linux Main10 encode ... GNOME 50 (Mutter MR 4928, PipeWire >= 1.6) added HDR screen sharing for monitor streams: 10-bit PQ formats (xRGB_210LE/xBGR_210LE) with MANDATORY BT.2020 + SMPTE-2084 colorimetry props, advertised while the mirrored monitor is in BT.2100 colour mode. Wire the Linux host into it end-to-end on the GameStream desktop-mirror path (PUNKTFUNK_VIDEO_SOURCE=portal): * pf-frame: PixelFormat::X2Rgb10/X2Bgr10 (DRM XR30/XB30; X2Bgr10 is the Windows Rgb10a2 layout) + fourccs. * pf-capture: want_hdr portal offer — HDR-only LINEAR-dmabuf pods with MANDATORY PQ/BT.2020 props (SHM excluded: Mutter's SHM record path paints 8-bit ARGB32 regardless of format; tiled excluded: the EGL de-tile blit is 8-bit RGBA8), negotiated-colorimetry parse, generic HDR10 hdr_meta(), packed-10-bit CPU cursor blend, a process-wide SDR downgrade latch on negotiation timeout, and a DisplayConfig BT.2100 colour-mode probe (gnome_hdr_monitor_active). * pf-encode: libav NVENC X2RGB10->P010 swscale (BT.2020 limited) -> HEVC Main10 / 10-bit AV1 with PQ VUI; VAAPI 10-bit on both paths (CPU P010 upload + dmabuf XR30 scale_vaapi p010/bt2020); can_encode_10bit now probes for real on Linux; 10-bit sessions route around the 8-bit-only Vulkan-video/direct-NVENC backends. * GameStream: host_hdr_capable() Linux arm, live monitor-HDR check at RTSP honor time, capturer-pool reuse keyed on HDR-ness, gs_bit_depth covers the new formats. New `punktfunk-host hdr-probe` diagnostic and a PUNKTFUNK_SPIKE_HDR spike lever. * Native plane stays honestly 8-bit via capturer_supports_hdr(): Mutter RecordVirtual streams are SDR-only upstream (GNOME 50 and 51-dev), so virtual-display sources cannot deliver HDR yet. Validated on the RTX 5070 Ti (GNOME 50.3 / PipeWire 1.6.8): the Main10 probes pass and the ignored nvenc_hdr10_smoke GPU test emits an IDR that ffprobe reads as Main 10 / yuv420p10le / bt2020nc / smpte2084 / limited. Live HDR capture negotiation still needs an HDR monitor on glass; VAAPI 10-bit needs the AMD box. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 09:30:55 +02:00
enricobuehler	75474dcc90	fix(pyrowave): guard 4:4:4 modes that overflow the rate controller's block index ... The vendored rate controller packs its wavelet block index into 16 bits (RDOperation.block_offset_saving), so a mode whose 32x32-block count exceeds u16::MAX wraps inside the controller and corrupts the bitstream — ~8K-class 4:4:4 territory. Compute the exact count (`block_count_32x32`, the counting walk of upstream init_block_meta, pinned against the validated Apple WaveletLayout) and expose `pyrowave_mode_fits_rdo`; the negotiator downgrades such a session to 4:2:0 before the Welcome (the honest-downgrade channel), and both encoders refuse outright if one slips through rather than emit a wrapped stream. Vendor patches: 0002-rdo-saving-clamp (analyze_rate_control.comp clamps the saving accumulation to the target, same overrun class as 0001; slangmosh.hpp regenerated), 0003-devel-encode-16bit-read (devel tool y4m 16-bit plane reads; tool-only, kept so the vendored source stays honest). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 01:16:51 +02:00
enricobuehler	ac0e73321c	perf(pyrowave): elevated GPU scheduling + global-priority encode queue ... PyroWave's wavelet encode runs on the GPU's compute/shader cores, so a GPU-bound game starves it: submit spikes from ~2 ms to ~15 ms under a 95%+ game load and the stream fps collapses. NVENC is immune (separate encoder ASIC). Two levers to let the encode get scheduled ahead of the game's rendering: - Windows process GPU scheduling: D3DKMTSetProcessSchedulingPriorityClass, env PUNKTFUNK_GPU_PRIORITY = off|above-normal|high (default)|realtime. Best-effort, once per process, non-fatal on refusal (enc/windows/pyrowave.rs). - Global-priority Vulkan encode queue (Granite patch 0005): request a VK_KHR_global_priority queue (PYROWAVE_QUEUE_PRIORITY = off|high|realtime, default realtime), downgrading REALTIME→HIGH→none on NOT_PERMITTED so a refused class never regresses the encoder to HEVC. HONEST STATUS: on an RTX 4090 / Windows / WDDM neither moved the ~15 ms spikes — the graphics-vs-compute preemption granularity is the wall, not the priority level. Kept because both are correct, harmless (graceful fallback), and may help other GPUs/drivers. For a GPU-saturated game the working levers are reducing the encode's GPU cost (4:2:0/8-bit) or H.265; PyroWave holds full rate on the desktop and in games that leave the GPU headroom. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 01:02:01 +02:00