1559 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
enricobuehler	589d48a975	fix(plugin-kit): SSE keepalive must outpace Bun's idle timeout (0.1.4) ... servePluginUi's Bun.serve leaves idleTimeout at Bun's 10s default, so the old 15s keepalive could never arrive — an idle status feed was closed before its first ping, which is exactly what a live host showed. Default is now 5s. Also adds the regression suite that should have caught it: the original test only covered a finite, self-driving stream. The new one exercises the production shape (PubSub-backed, published after the response opens) plus the keepalive — with a reader that does not re-enter read(), which is what made the first version of this test lie. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 19:59:04 +02:00
enricobuehler	424bab1c3a	fix(plugin-kit): soften @unom/ui's card ring for the brand palette (0.1.3) ... @unom/ui rings cards ring-2 ring-accent, sized for its own subtle accent; in this palette --accent is the brand violet, so every card shouted. The console already softens the same ring in its Card wrapper — plugin UIs now inherit that instead of each wrapping AnimatedCard themselves. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 19:47:51 +02:00
enricobuehler	5a27c02738	feat(encode/nvenc): LN1 phase-0 — slice-count + sub-frame-readback knobs and the slice-timing probe ... PUNKTFUNK_NVENC_SLICES=N (2..=32, default off) splits H.264/HEVC frames into N slices (sliceMode 3); PUNKTFUNK_NVENC_SUBFRAME=1 (default off) arms enableSubFrameWrite + reportSliceOffsets on sync sessions only. Both experimental groundwork for sub-frame slice output (plan §7 LN1). nvenc_cuda_subframe_slice_probe (on-hardware, ignored) answers the LN1 go/no-go: spins lock_bitstream(doNotWait) against an in-flight frame and prints the (t_us, status, numSlices, bytes) timeline — incremental slice availability and its spacing, or all-at-completion. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 19:44:54 +02:00
enricobuehler	d5a0f5012b	fix(encode): RGB-direct probe — accept cosited-even chroma siting (what VCN EFC actually offers) ... On-glass B0 result from the 780M (RADV PHOENIX, host Mesa 26.0.4): the probe returned no-709-narrow-midpoint because RADV advertises xChromaOffsets = COSITED_EVEN only — the VCN EFC does canonical H.26x left-cosited x-chroma, while the requirement was written to bit-match our 2x2-average (midpoint) shader. The delta is a half-pel chroma-x phase, imperceptible and unsignalled in our bitstream; EFC's siting is arguably the more correct one. Accept either siting bit per axis (model + range stay exact: 709 narrow); B1 will pass the preferred available bit. With this the 780M probes rgb_direct=available; both GPU smoke tests (H265 + AV1) pass on that box against host Mesa 26.0.4 — the first real-RADV validation of the poll fix, the quality-level control, and B0. (Container mesa alone can't run the H265 smoke: Fedora ships RADV with H264/H265 encode compiled out — AV1 only. Use the host ICD via VK_ICD_FILENAMES on Atomic boxes.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 19:44:33 +02:00
enricobuehler	d833cff470	fix(plugin-kit): resolve the --secondary text/surface collision in theme.css (0.1.2) ... @unom/ui reads --secondary as muted TEXT; this palette (like the console's) uses it as a dark SURFACE, so EmptyState captions, badge text and table headers rendered dark-on-dark. Tailwind derives both utilities from one token, so the text lane is re-pointed at --muted-foreground here — once, for every plugin, instead of in each plugin's stylesheet. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 19:44:01 +02:00
enricobuehler	34ec57cb52	test(encode/nvenc-linux): on-hardware assertion that stream-ordered submit arms ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 19:38:22 +02:00
enricobuehler	cd36c46388	perf(encode/nvenc-linux): LN2 v1 — stream-ordered submit via NvEncSetIOCudaStreams ... Bind the session's IO streams to the encode thread's high-priority copy stream: in sync-retrieve depth-1 use the per-frame input copy and cursor blend now enqueue with NO cuStreamSynchronize and encode_picture orders after them on the stream. Same stream both directions, so the encode's completion is inserted into the stream and later work (the next frame's copy into a reused ring slot) waits for it. Soundness gate: the fast path engages only when pending is empty (true depth-1 usage) — every prior encode was drained by a blocking poll, and the caller holds the frame payload across the matching poll (contract now documented on Encoder::submit; both host loops already comply). Pipelined callers and PUNKTFUNK_NVENC_ASYNC mode keep the blocking copies. True zero-copy input registration (registering the worker-owned IPC buffer directly) stays the LN2 v2 follow-up — it needs a contiguous worker-pool NV12 layout and a registration<->IPC-mapping lifetime tie. PUNKTFUNK_NVENC_STREAM_ORDERED=0 restores the old blocking behavior. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 19:38:22 +02:00
enricobuehler	59b6d3796b	perf(encode/nvenc-linux): LN0 — sampled submit/retrieve-lock split, sub-frame caps, zeroReorderDelay ... Latency plan §7 LN0 (Linux/NVIDIA encode follow-on): - sampled PUNKTFUNK_PERF submit split (copy/blend/map/pic) in nvenc_cuda — the host loop's submit_us folds all four together; the D2D input copy is the LN2 zero-copy target and now measurable on its own - sampled blocking lock_bitstream timing on pf-nvenc-out — in two-thread mode the host loop's wait_us wraps a non-blocking poll, so the real encode wait was measured by no timer - caps probe + log SUPPORT_SUBFRAME_READBACK / SUPPORT_DYNAMIC_SLICE_MODE (LN1 sub-frame slice-output prerequisites, fleet visibility) - explicit zeroReorderDelay=1 in the shared low-latency config (P-only + no lookahead has no reordering anyway; pins the bit against preset or driver drift; shared with the Windows backend) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 19:38:22 +02:00
enricobuehler	78dba293a8	feat(encode): Vulkan Video B0 — vendored VK_VALVE_video_encode_rgb_conversion + RGB-direct probe telemetry ... First phase of design/vulkan-rgb-direct-encode.md (punktfunk-planning): make the captured BGRx dmabuf the direct encode source with the VCN EFC front-end doing the 709-narrow CSC — deleting the per-frame compute CSC, both plane copies, the semaphore hop and one queue submit. B0 changes nothing about the encode path. It vendors the extension surface (vk_valve_rgb.rs — ash 0.38 predates it; same rationale and style as the vk_av1_encode module) and probes at open whether this host qualifies: extension present (Mesa >= 26.0 + EFC hardware) → feature bit → conversion caps cover the compute shader's exact math (709 / narrow / midpoint both axes) → encode-src format set offers B8G8R8A8 with DRM-modifier tiling. The verdict is one INFO line (rgb_direct=available | first missing requirement) — the field telemetry that decides where B1 can default on. Verified: cargo check + clippy clean + unit tests green (Linux box); the probe short-circuits to no-ext on non-RADV drivers. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 19:29:22 +02:00
enricobuehler	cfdec2729d	perf(encode): Vulkan Video — explicit VCN preset, persistent bitstream map, CSC split timing ... Field follow-up to 6dc195f9 (the AMD host whose H265 encode sits at ~5 ms): the remaining time is the VCN ASIC preset, and we never chose one. 1. Explicit encode quality level. RADV only emits a VCN preset op when the app issues ENCODE_QUALITY_LEVEL — we never did, so every session ran the firmware's default preset. Install the resolved level on the first frame's RESET control (chained ahead of the CBR state, which satisfies the spec's quality-change-carries-rate-control rule) and bake the same level into the session-parameters object (the spec requires the match). Default 0 = the fastest tier the driver exposes (RADV: SPEED, except H265 on pre-RDNA4 which the driver pins to BALANCE); clamped to the profile's maxQualityLevels. PUNKTFUNK_VULKAN_QUALITY=0..3 overrides for quality-biased setups. Logged at open so field logs show the tier. 2. Persistent bitstream mapping. read_slot vkMapMemory/vkUnmapMemory'd the host-visible bitstream buffer every frame; map each ring slot once at build instead (coherent memory; vkFreeMemory implicitly unmaps). 3. PUNKTFUNK_PERF CSC split. GPU timestamps bracket the compute batch (import barriers + cursor prep + CSC dispatch + plane copies) and a sampled csc_us line logs every ~2 s — separating shader/copy time from the ASIC encode inside the pump's wait_us, the VAAPI submit-split analog for this backend. Off (and unrecorded) unless PUNKTFUNK_PERF. Verified: cargo check + clippy + DPB/RPS unit tests green (Linux box). The GPU smoke tests still need a RADV host (NVIDIA driver fails session open on the build box, pre-existing). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 19:17:34 +02:00
enricobuehler	6dc195f982	fix(encode): Vulkan Video poll() must block per the depth-1 pump contract ... The session pump's depth-1 loop (capture → submit → poll) treats a poll() None as "the backend holds the frame internally, re-poll next tick" — true only of the libav AMF/QSV wrappers, whose codecs genuinely hold ~2 frames. The Vulkan Video backend probed its slot fence with get_fence_status instead, so the AU of every frame — finished on the ASIC in ~5 ms — sat unharvested until the tick AFTER the next frame was submitted: encode_us read as one full frame period (~17 ms at 60 Hz vs VAAPI's ~5.3 ms on the same VCN, the AMD field report) and every frame shipped a frame period late — one frame of avoidable glass-to-glass latency on the path that exists to beat libav VAAPI. Wait the oldest in-flight slot's fence in poll() instead, matching the sync NVENC backend's blocking lock_bitstream and the documented Capturer::pipeline_depth contract ("capture → submit → poll-blocks"). Bounded by ENCODE_FENCE_TIMEOUT_NS like enqueue()'s backpressure wait, for the same reason: poll runs on the thread the stall recovery runs on, so a wedged GPU must surface as an error, not park it. None now only means "nothing submitted". Covers H265 and AV1 (shared poll). Verified: cargo check + DPB/RPS unit tests green (home-worker-5); the GPU smoke tests fail at session open on that box's NVIDIA driver identically on unmodified origin/main — pre-existing, needs the RADV box for on-glass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 18:53:21 +02:00
enricobuehler	da259d5b79	feat(plugin-kit): browser-safe ./wire subpath for provider schemas (0.1.1) ... Plugin contracts share ProviderEntry/Artwork/LaunchSpec/PrepStep with their UIs; the kit root stays node-only (reconcile keeps the HostClient transport). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 18:49:13 +02:00
enricobuehler	4094f6208d	fix(web): load the inlang plugin from node_modules, not a CDN ... `web/project.inlang/settings.json` pointed `modules` at https://cdn.jsdelivr.net/npm/@inlang/plugin-message-format@4/dist/index.js — inlang's stock `paraglide-js init` scaffolding, which nobody had a reason to keep. It made `bun run codegen` need the network at build time, so in a sandbox that has none (the Nix build; any air-gapped CI) the plugin import failed and paraglide compiled ZERO messages. That failure is silent by design: the inlang SDK logs a PluginImportError as a WARNING, paraglide still prints "Successfully compiled" and exits 0, vite bundles the empty message set, and the console only dies at request time inside renderToReadableStream because every `m.foo()` is undefined. Reported from a NixOS host running punktfunk-web-server. The plugin is a normal npm package, so depend on it like one: add @inlang/plugin-message-format as a devDependency and reference it by relative path. `loadProjectFromDirectory` (which both `paraglide-js compile` and the vite plugin use) imports non-`http` modules straight off disk, and the shipped dist/index.js is a self-contained bundle with no imports of its own, so it loads from the data: URL exactly as the CDN copy did. Compiles 268 messages offline, with no project.inlang/cache round-trip. Add tools/check-i18n.mjs, run at the end of `codegen`, so this can never ship silently again: it fails the build on a remote `modules` entry, a module that does not resolve, or a compiled message count below what messages/en.json defines. Verified it catches all three (remote URL, missing plugin, corrupt plugin that compiles to 0 messages) and passes a healthy build. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 18:43:39 +02:00
enricobuehler	0ed8ca90f2	fix(plugin-kit): regenerate bun.lock (duplicate package path after react devDep add) ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 18:41:34 +02:00
enricobuehler	8d72e1d27e	feat(plugin-kit): @punktfunk/plugin-kit 0.1.0 — the Effect plugin framework ... The ~80% of every plugin that was copy-pasted (rom-manager ↔ playnite), extracted as one Effect-v4 package: - runtime: definePluginKit — async-main boundary hiding a ManagedRuntime (two-effect-instances discipline), signal-driven interruption with a bounded shutdown grace - config: Schema-driven raw round-trip (defaults only in the Schema via withDecodingDefaultKey + encodingStrategy omit; file stays authored-shape), atomic writes, world-writable refusal, changes stream - cache-store: disposable derived state, corrupt→empty, write-through - reconcile: kit-owned provider wire schemas + typed client over the skew-safe untyped pf.request seam - sync-engine: generic poll/watch/debounce/single-flight-coalesce/ fingerprint-skip engine with a status PubSub (the SSE feed) - ui-server + sse: effect/unstable/httpapi behind servePluginUi with core-only env layers (validated by the phase-0 spikes); raw SSE route (httpapi has no event-stream media type) - cli: minimal command dispatcher reusing the plugin layer graph (deliberately not effect/unstable/cli — it needs platform packages) - react subpath: plugin router (path→hash→fallback deep-link restore + pf-ui:navigate bridge), ResultGate, sseAtom, resolvePluginBase - theme.css: the console's violet identity packaged for plugin UIs 18 bun tests incl. the two phase-0 spikes; publish workflow mirrors sdk-publish (tag plugin-kit-v*; 0.1.0 published manually). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 18:41:11 +02:00
enricobuehler	c15c80718a	chore(sdk): bump @punktfunk/host to 0.1.2 ... Manual publish (no sdk-v tag — the version was published directly so the plugin-kit and rewritten rom-manager can consume pluginStateDir/pluginIngestDir from the registry; the previously published 0.1.1 predates the security-tiers merge and lacks those exports). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 18:41:11 +02:00
enricobuehler	bb58fde369	feat(plugin-kit): scaffold @punktfunk/plugin-kit + phase-0 spikes ... Two spikes validating the riskiest seams of the plugin-kit design before implementation: - HttpApi (effect/unstable/httpapi) served on Bun behind the SDK's servePluginUi using ONLY effect-core layers (Etag.layerWeak, Path.layer, HttpPlatform.layer + FileSystem.layerNoop) — no platform package. Auth, schema validation, and static fallthrough all verified end-to-end. - Browser client prefix strategy for the console proxy: both transformClient+prependUrl AND baseUrl preserve the /plugin-ui/<id> path prefix. Nested Schema.withDecodingDefaultKey defaults confirmed (Effect-valued defaults; encodingStrategy "omit" restores raw shape on encode). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 18:41:11 +02:00
enricobuehler	de7b54d4e0	fix(core): remaining 15 sweep lows — client, clipboard, C ABI (v10), FEC, GSO, GTK ... Second and final batch from the 2026-07-20 core-sweep lows: client: - connect() timeout now sets `quit` before shutdown, so a handshake that completes after the deadline closes with QUIT_CLOSE_CODE instead of leaving the host lingering (virtual display up) for a reconnect that never comes. - probe_result: saturating_add on the wire-supplied wire_packets + send_dropped counters (debug-build overflow panic / release wrap). - the standing-latency bleed no longer sets flush_in_window: that flag is the ABR's SEVERE (×0.7) verdict, and the bleed fires only on provably loss-free windows the controller itself scores as fine. clipboard: - fetch_cancels pruned on every new fetch (was: one dead oneshot per paste for the session). - serve chunks gated on a parked waiter + capped at CLIP_FETCH_CAP with an Error event (was: unbounded silent accumulation under any req_id). - serve_inbound park bounded by FETCH_STALL_SECS + send.stopped() (was: an unanswered FetchRequest parked the task, waiter, and bi-stream forever; ~100 of them exhaust the connection's bidi budget). C ABI (ABI_VERSION 9 → 10, header regenerated, additive only): - new punktfunk_connection_clock_offset_now_ns — the LIVE re-synced offset (Swift/Kotlin latency math read the frozen connect-time value ~40ms wrong after a wall-clock step). - to_config: checked u64→usize narrowing of max_frame_bytes (32-bit armeabi truncated >4GiB to a plausible residue). - host_poll_input: no &mut held across the embedder callback (re-entry aliased it — UB under noalias); mid-drain callback clears now stick. - next_audio_pcm: DTX (empty) payloads skipped — decode synthesized 120ms of concealment per 5ms slot and grew the playout ring forever. - next_clipboard releases the parked payload on an empty poll (a one-off 50MiB paste stayed resident all session). - frames_dropped / wants_decode_latency write their documented 0/false defaults before the NULL-handle check. - gamepad constant docs match pick_gamepad() reality (DualSenseEdge/ SwitchPro landed; DualSense/DS4 honored on Windows UMDF too). FEC: - gf8 reconstruct/reconstruct_into reuse the (k,m) codec cache like encode_into (was: fresh 230×200 generator + decode inversion per lossy block on the pump thread). - vendored fec-rs: the 8 safe wrap_mul_slice shims assert equal lengths (x86 SIMD callees bound stores on input.len() — safe-code OOB write); ReconstructShard's safety contract gains the len()==get().len() clause and reconstruct_internal sizes raw slices from the slice. transport/GTK: - Linux GSO super-buffer capped at the real UDP payload ceiling (65487) not 65535 — seg sizes ≥1024 could EMSGSIZE and latch GSO off process-wide, blamed on the network. - GTK settings dialog no longer rewrites an unlisted-but-valid stored gamepad preference to "auto" on close. Already fixed on main (verified stale, skipped): the reassembler FEC ceiling, wants_decode_latency's third term, request_probe rollback + the generalized probe watchdog. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 18:26:43 +02:00
enricobuehler	76ac3cf867	fix(core): five sweep lows — seal-lane fallback, flush partial, codec echo, idle clamp, pair-name UTF-8 ... From the 2026-07-20 punktfunk-core quality sweep's adjudicated lows (~/punktfunk-sweeps/punktfunk-core-2026-07-20.json), each with a regression test: - session: the two-lane seal's dead-worker fallback dropped the frame's back half and returned Ok with half an access unit; the corpse lane was also never respawned. The send-failure arm now reclaims the tail (single-lane seals the WHOLE frame) and both failure arms drop the lane so the next large frame respawns it. A recv-side death now surfaces as an error instead of silent truncation. - reassemble: Reassembler::reset() left pending_partial parked, so a pre-flush stale partial survived Session::flush_backlog and was delivered as the first "frame" after a jump-to-live. - caps: resolve_codec echoed a non-conformant multi-bit preferred byte verbatim (downstream from_wire folds it to HEVC — possibly outside the shared set). It now isolates one bit of the intersection. - endpoint: stream_transport_idle only floored the value; an absurd operator-supplied idle timeout blew past QUIC's VarInt ms ceiling and panicked host startup through the expect. Clamped to 1s..1h. - pairing: PairRequest::encode cut the device name at a raw byte-64 boundary, splitting multi-byte UTF-8 (host showed U+FFFD forever); it now shares Hello's char-boundary truncate_to. The frozen-FEC-ceiling finding (reassemble.rs:109) was already fixed on main by the sweep's high-severity commit — skipped as stale. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 18:16:02 +02:00
enricobuehler	f4ec18d528	chore(core): fix build.rs + crate-doc drift left by the W7/W8 splits ... - build.rs: drop the stale `rerun-if-changed=src/client.rs` (the file became client/ in W7; the path never fires). - lib.rs: the crate doc's module list named 6 of ~19 modules — add the missing ones (config/error/stats/input/reject/reanchor/render_scale/ audio/wol + the quic-gated control-plane group), without intra-doc links to feature-gated modules. - quic/mod.rs: the module doc still described the deleted `msgs` module; list the actual post-split module set. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 18:08:39 +02:00
enricobuehler	ce51a2ba74	refactor(core): decompose the client run_pump monolith into pump/ submodules ... client/pump.rs was a single 1192-line async fn stacking six concerns. It is now a 190-line orchestrator (same spawn order, same channel wiring) over five focused modules: - pump/handshake.rs — connect + Hello/Welcome/Start + skew handshake + hole punch + Session construction (HandshakeOut) - pump/input_task.rs — the gamepad snapshot/removal/arrival re-send state machine + passthrough input forwarding - pump/control_task.rs— the control-stream select loop (renegotiation, probes, bitrate acks, clock re-sync, clip metadata), bundled as ControlTask - pump/datagram_task.rs — the datagram tag demux + rumble reorder gate - pump/data.rs — the blocking data-plane pump (loss reports, ABR + capacity probe, jump-to-live detectors, standing-latency bleed), bundled as DataPump Every body moved verbatim (dedent + arg-struct destructures aliasing the original binding names); no per-frame indirection added — the pump loop, its locals, and the hot-path shape are byte-equivalent. The Ctrl/DataPump arg structs exist only to stay under too_many_arguments. 196 lib tests pass; clippy clean on --features quic AND --no-default-features (--all-targets); include/punktfunk_core.h byte-identical; fmt clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 18:07:14 +02:00
enricobuehler	eacaaa5cd8	refactor(core): peel session.rs anti-replay, perf telemetry, and seal lane into submodules ... session.rs (1203) sharpens down to the two hot-path state machines + lifecycle (887): ReplayWindow + seq_of + their tests -> session/replay.rs; the PUNKTFUNK_PERF trio PumpPerf/SealPerf/TimedCoder -> session/perf.rs; the Phase-1.5 lane machinery SealLane/SealJob/seal_wire_slice/ TWO_LANE_MIN_PACKETS -> session/seal.rs. Facade pattern (session.rs stays the parent file); pub use keeps session::{PumpPerf,SealPerf} stable and lib.rs re-exports are untouched. Pure code motion + pub(super) bumps — seal_frame_inner/poll_frame/poll_input bodies unchanged; the wire-equivalence tests stay co-located with the seal path they pin. 196 lib tests pass, clippy --features quic --all-targets clean, fmt clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 17:56:26 +02:00
enricobuehler	e0a1edb9d4	refactor(core): co-locate the quic wire tests with their modules ... quic/tests.rs (1813 lines, 43 tests) was the W7 split's leftover: the source moved into handshake/caps/control/clock/pairing/pake/datagram/ endpoint/clipstream/io but every test stayed in one monolithic file. Each test now lives in a #[cfg(test)] mod tests at the foot of the module it exercises, verbatim. The two CompositorPref/GamepadPref wire/name tests moved to config.rs (where those enums live), so they now also run under --no-default-features. The clip_loopback and ctrl_framing integration mods share connect_pair via a cfg(test)-only quic/test_util.rs. Test-only motion: 196 lib tests pass unchanged on macOS, clippy --features quic --all-targets clean, include/punktfunk_core.h byte-identical. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 17:53:36 +02:00
enricobuehler	a53369bf21	fix(ci): green main again — clock_sync callers, two clippy denials, an unused import ... `ci.yml`'s clippy gate has been failing on main since the pre-0.16.0 sweep landed, and because clippy stops at the first crate it can't compile, the visible error was only ever the first of four. `ci.yml` is not tag-triggered, so v0.16.0 cut and shipped over a red main; none of this reaches the release artifacts (the two E0308s are in a test binary and a dev tool, and the rest are lints) but the gate has been blind since. Fixed, in the order clippy surfaced them: - clients/probe failed to COMPILE (E0308, x2). `810d918d` moved `clock_sync` onto the resumable `io::MsgReader` but only updated the client pump, leaving the probe passing a bare `&mut RecvStream`. The probe now wraps the control stream in a `MsgReader` at `open_bi` and threads that everywhere — Welcome, the --remode and --bitrate watchers, and the speed-test result read — which is also what the refactor was for: those reads sit behind timeouts and `select!`, exactly where a straddling frame would desync the stream for the rest of the run. - pf-capture: `SPA_META_Cursor as u32` is a `u32 -> u32` no-op (`clippy::unnecessary_cast`). Line 1274 already passes the same constant uncast, so the type is not in question. - pf-inject: `noop as usize` on the SIGUSR1 wake handler added in `986402f7` trips `clippy::function_casts_as_integer`; goes via `*const ()` as the lint asks. Same value in the `usize`-typed `sa_sigaction` slot. - punktfunk-core: the `ctrl_framing` test module's `use super::*` is unused, which `-D warnings` promotes to an error. Verified with CI's own commands on a Linux box (this is all Linux-gated code, so a Mac cannot check it): `cargo clippy --workspace --all-targets --locked -- -D warnings` finishes clean, `cargo build --workspace --locked` succeeds, and `cargo test --workspace --locked` exits 0 with no failures — including punktfunk-core's 196-test suite, which covers the control-stream framing the probe change touches. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-20 11:49:49 +02:00
enricobuehler	3213c1b61c	ci(flatpak): resolve over TCP so the flathub bootstrap stops failing on tag pushes ... The flathub remote-add has now burned its entire retry budget and failed the job on three consecutive tag builds — v0.15.0, the v0.15.0 re-point, and v0.16.0 — each one needing a manual re-run to land the bundle. The cause was already root-caused here on 2026-07-11 (see the Tooling step's comment): home-runner-1's Docker embedded resolver at 127.0.0.11 drops UDP lookups while the shared multi-org fleet is saturated. Nothing retransmits a dropped datagram, so the lookup simply times out. The fix then was to widen retry.sh to 10 attempts (~9 min), which comfortably outlasts a main push's ~8-workflow fan-out — but a TAG push starts 13 workflows at once, and that burst now outlives the whole budget. Retrying harder is chasing the symptom; the transport is the problem. `options use-vc` moves resolution to TCP, where the kernel retransmits and a query cannot be silently lost under load. Same resolver and search path — only the transport changes — so internal names still resolve exactly as before. Deliberately no additional nameservers: a public resolver in the list could answer an internal name (git.unom.io) with NXDOMAIN. retry.sh stays as the backstop for real upstream blips. Applied non-fatally, because Docker bind-mounts /etc/resolv.conf and may present it read-only: a DNS tuning that cannot be applied must not be the thing that fails a release build. If the write is refused we warn and stay on UDP, i.e. exactly today's behaviour. Scoped to the flatpak workflow, where the failure is actually evidenced, rather than applied fleet-wide on suspicion. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-20 08:33:34 +02:00
enricobuehler	b3adfb3a56	ci(release): pin Xcode DerivedData so it stops filling the mac runner's disk ... v0.16.0's Apple leg failed at the xcframework build with "No space left on device (os error 28)": the runner's boot volume was at 100% with 152 MB free. None of the four `xcodebuild archive` calls passed -derivedDataPath, so each one used the default ~/Library/Developer/Xcode/DerivedData/<name>-<hash> — and that hash is derived from the PROJECT'S ABSOLUTE PATH. act_runner rotates its workspace (~/.cache/act/<hash>/hostexecutor), so every rotation looked like a new project to Xcode and minted a fresh ~760 MB tree. Nothing ever collects those: they live outside the workspace, so act's own cleanup never sees them. 31 had accumulated in three days (17 -> 20 July), which with the 12 GB shared ModuleCache came to 32 GB — on a 228 GB volume already 95% full. Pin all four archives to one path. The tree is now REUSED rather than multiplied, which also keeps the module cache warm instead of rebuilding it per run. The new step additionally prunes anything week-stale left in the default root, covering both the legacy per-path trees and any other job that lands there. Cleared by hand on home-mac-mini-1 to unblock the release (152 MB -> 31 GB free); this is the change that stops it coming back. Note the same class of problem bit the Windows runner the same night from the other direction — its disk-cleanup task purges C:\t and deleted files out from under ISCC mid-pack — which is worth its own look and is NOT addressed here. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-20 08:17:33 +02:00
enricobuehler	191c9a4e18	chore(release): bump workspace version to 0.16.0 ... MINOR, not the 0.15.1 originally planned: the 24 commits since v0.15.0 carry 7 features, and they are not incidental — they change the plugin runner's privilege model. It stops holding the console's full-admin token (scoped plugin-token lane), the Windows runner drops from SYSTEM to LocalService, public-registry plugin installs are gated behind an explicit flag, and the systemd user unit is sandboxed. Operators have workflow-visible changes to absorb (a plugin genuinely needing the admin surface must now set PUNKTFUNK_MGMT_TOKEN; installing outside the @punktfunk scope needs --allow-public-registry). A patch label would understate all of that, and sdk-publish pushes this version straight to consumers. The other 12 fixes are largely the pf-encode/zerocopy/capture/inject quality sweep landing: teardown deadlocks, error-path leaks, a GL->CUDA copy race, an odd-height NV12 overrun, a cursor-meta OOB read, plus the two loss-recovery gaps 0.15.0 left open (Vulkan Video never got the LTR taint sweep; QSV's sweep skipped its modal single-swept-slot case). `WIRE_VERSION` stays 2 and the driver protocol stays v4 — pairings, clients and installed drivers keep working. The C ABI moves 8 -> 9 (PunktfunkFrame grows `received_ns`, so receipt is stamped at the session boundary rather than at the embedder's pull); the gitignored Apple xcframework needs a rebuild for that to reach the Apple clients. No OpenAPI path changes (45 before and after) — the new plugin-token lane is auth-layer only — so api/openapi.json moves info.version only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> v0.16.0	2026-07-20 07:47:10 +02:00
enricobuehler	dd558be55b	fix(core/client): fix the four ways a speed-test probe corrupts ABR and the report tick ... There is one `ProbeState` per session and no correlation id, and two independent requesters share it: the pump's startup link-capacity probe and the embedder's `NativeClient::request_probe` (the shipped "Test connection" in the Windows GUI and the Linux GTK app). The startup path had a busy check, a watchdog and a window rebase; the embedder path had none of them, and the two collide by default — both shipped speed tests call `request_probe` on the statement right after `connect()`, and the pump's probe fires 2 s later, inside that burst. Four defects, one cluster: - The pump overwrote the shared slot unconditionally. Mid-burst it drops `base_packets`/`base_bytes`, the pump re-snapshots them against the host's full-burst denominator, and the user's speed test reports roughly an order of magnitude low; if the result lands first instead, the reset wipes `done` and the embedder's poll loop never sees its own measurement. Now it defers and retries rather than stealing the slot. - An unanswered embedder probe never timed out. `probe_active` gates the entire report tick — LossReport, the ABR window feed, the standing-latency ladder and a pending ClockResync all live inside it. A host that ignores ProbeRequest is an anticipated configuration (the startup path was given a 6 s timeout for exactly that) so the embedder path could latch `active` forever and silently switch off every adaptation mechanism for the rest of the session. Now a watchdog covers a probe of either origin. - `request_probe` latched `active` before `try_send`, so a full or closed ctrl channel returned `Closed` to the caller while leaving the session wedged in the state above. It now rolls back, mirroring the startup path. - Only the startup path rebased the ABR window past the burst. Probe filler is counted into `bytes_received` for every accepted datagram but never reaches the decoder, and the tick is suppressed for the whole burst, so the first post-burst window read the burst rate as `actual_kbps`. That poisons `proven_kbps`, a monotone high-water mark that is never decayed, which disables the x1.5 evidence-gated climb guard for the session and authorizes a climb into a rate the decoder has never carried. The rebase now happens on the falling edge of any probe, and covers the loss/packet anchors too so the first post-burst LossReport isn't divided by a filler-inflated packet count. Also: `wants_decode_latency` advertised on two of the three terms the pump actually requires to arm ABR, omitting `resolved_bitrate_kbps > 0`, so against an old host that reports no rate an embedder fed decode latency to a controller that never runs. No wire or ABI change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-20 07:42:37 +02:00
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	5cd6e8f572	docs: reflect the plugin-runner security tiers ... - plugins: the Windows runner task runs as LocalService now, and public-registry names need --allow-public-registry - automation + SDK README: connect()'s zero-config credential is the scoped plugin token; pairing administration and hook registration need an explicit PUNKTFUNK_MGMT_TOKEN opt-in Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 00:45:27 +02:00
enricobuehler	7b7231fdbe	feat(security): gate public-registry plugin installs + sandbox the runner unit ... Supply chain: resolvePackage() used to pass any punktfunk-plugin-* or foreign-scope name straight to bun add — a typo or a squatted look-alike on npmjs.org would install operator-privileged code. Only the @punktfunk scope (pinned to the Gitea registry by the bunfig scope map) resolves by default now; anything else throws with an explanation unless --allow-public-registry is passed, and even then installs print a loud warning. Removal never gates — uninstalling stays safe regardless of origin. systemd (user unit): free hardening for well-behaved plugins — NoNewPrivileges, PrivateTmp, ProtectSystem=strict with ReadWritePaths=%h (plugin state and download dirs under $HOME keep working), and RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6. Plugins writing outside $HOME, and distros that restrict unprivileged user namespaces for user units, are handled via a documented systemctl --user edit drop-in. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 00:45:27 +02:00
enricobuehler	7fe07d0fa5	feat(security): enforce the unit-file trust rule on Windows too ... fileIsSafe() returned true unconditionally on win32 ('ACL check is a follow-up'), leaving the best-effort directory DACL as the only guard on what the runner imports and executes. The follow-up: before importing a unit, read its SDDL (Get-Acl via the full-System32-path powershell) and refuse loudly — exactly like the Unix mode-bits path — unless the owner is SYSTEM/Administrators/TrustedInstaller (or the account the runner itself runs as, mirroring Unix's 'your own file is fine') and no other principal holds a write-capable allow ACE (write/append data, EA/attrs, DELETE, WRITE_DAC, WRITE_OWNER, generic write/all). The SDDL verdict is a pure exported function with platform-independent tests; unknown ACE shapes and unreadable ACLs fail closed. Inherit-only ACEs (templates for children) and deny ACEs don't trip it. 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	ecec7cc062	feat(deploy/windows): always deploy the plugin/script runner ... `punktfunk-host plugins add/remove/list` forward to the bun runner, which on Windows is resolved relative to the running exe (<exe-dir>\bun\bun.exe + <exe-dir>\scripting\runner-cli.js). Only the installer ever laid that payload down, so on a deploy-host.ps1 dev box — where the service runs out of target\release — both paths are absent and the CLI bails with "the plugin runner isn't installed". deploy-all.ps1 was host + web console only. Add build-scripting.ps1: it mirrors CI (bun install --frozen-lockfile --ignore-scripts + bun build src/runner-cli.ts --target=bun, gated on the same `attempt=` sentinel that proves the dynamic plugin import stayed a runtime import), then lays the bundle + scripting-run.cmd + the shared bun next to every host exe it finds — the built one and whatever the PunktfunkHost service runs — so it is correct on a dev checkout or an installed {app}. It stops a running PunktfunkScripting first (a live runner holds bun.exe open) and does not silently enable the opt-in task (-EnableTask to do so). deploy-all.ps1 is now host -> web console -> runner, always, so the host binary and the runner bundle never drift apart. Co-Authored-By: Claude Opus 4.8 <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