100 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
enricobuehlerandClaude Opus 5	bc45287dc6	fix(pf-capture): Windows IDD-push defects — HDR pin, cursor, recreate, handles, f16 (Phase 3) ... Compile-verified for x86_64-pc-windows-msvc locally (a scratch workspace symlinking the real sources against a stub punktfunk-core — the `quic` feature's ring/opus C builds are what blocks an in-tree cross-check). Behaviour is owed the on-glass validation in sweep Phase 7.3. **3.1 (W1/F3) — the HDR pin asserted a flip it never verified.** `poll_display_hdr` discarded `set_advanced_color`'s `bool` and then wrote `now.hdr = self.client_10bit` — the DESIRED state in place of the observed one. On a display that cannot be flipped (the state this file already logs as "Downgrade point D" at open) that broke in both directions: wanting HDR, the fabricated `true` differed from `current`, so two poller samples drove `recreate_ring(true, …)` and rebuilt the ring FP16 while the driver composed 8-bit BGRA — every publish dropped by the driver's format guard, `recovering_since` expiring, `try_consume` bailing: a permanent 3-second reconnect loop. Wanting SDR, the fabricated `false` MATCHED `current`, so no recreate ever fired and the ring stayed BGRA against an FP16 composition — the same dropped-publish outcome, silently. Now it re-reads `advanced_color_enabled` and follows what the display actually composes, with a one-shot error naming want/observed/returned. A not-yet-settled read costs one debounce cycle, never a wrong ring, which is why this does not block the frame path on a settle poll the way `open_on` does. Downgrade point D's error now carries the same pair, so `Some(false)` (display says no) and `None` (the CCD read failed) are distinguishable. **3.2 (W2, W3, W6) — cursor correctness.** - W2: the poller's desktop rect was captured once at open and used forever, for BOTH the desktop→frame offset and the `in_rect` visibility test — while both mid-session mode-change paths (`resize_output`, `poll_display_hdr` → `recreate_ring`) keep the same poller. After an in-place resize the pointer was clipped to the old rect and offset by a stale origin. It is now a SEED: the poll thread re-queries on its existing 250 ms reattach cadence, keeping the last good value on `None` (a transient CCD failure must not park the rect at zero and report every position invisible), which keeps the CCD call off the encode thread as `DescriptorPoller` demands. - W3: `composite_forced` tested `cursor_sender.is_none()`, but §8.6's rationale is "no cursor CHANNEL" — and the delivery just above it is explicitly allowed to fail non-fatally, which is precisely the state needing the rescue. It was the one state that skipped it: a negotiated channel that failed to create or deliver left a cursor-excluded target with NO pointer at all. Now `cursor_shared.is_none()`, evaluated after that binding. - W6: `cursor()` degraded poller→shm correctly, but the BLEND path — the only consumer that matters in the composite model, since the Windows encode loop never attaches `frame.cursor` — read the poller directly with no `alive()` check and no fallback, so the documented fallback and the spawn-failure warning were both untrue for exactly those sessions (a dead poller meant pointer-less frames, not a degraded pointer). One `live_cursor()` now serves all three consumers and LATCHES the source, because the two keep independent serial namespaces and interleaving them poisons the client's shape cache. **3.3 (W4, W5, W14) — recreate hardening.** - W4: `recreate_ring` committed `display_hdr`/`width`/`height` BEFORE the fallible `create_ring_slots` (VRAM pressure at a large new mode — exactly when resizes happen), leaving a failed recreate emitting frames stamped with the new geometry against the old ring, the old generation and an unchanged header. Slots are built first; nothing after the commit point fails. - W5: a recreate never cleared the driver's status words, and `wait_for_attach` — the only classifier of TEX_FAIL/BIND_FAIL and the only source of the LUID rebind — runs at open ONLY. A stale `OPENED` therefore made a failed re-attach look healthy while the recover-or-drop bail reported nothing. Now cleared before the Release generation store (plus `status_logged`), and the 3 s bail prints the live `(driver_status, detail, render_luid)` the way `next_frame`'s 20 s bail already did. The four-field read is one `driver_diag()` helper instead of four copies of the same unsafe block. - W14: `IDD_GENERATION` is a full `u32` but the publish token carries 24 bits and `unpack` masks what it reads, so past 2²⁴ recreates `tok.generation != self.generation` would be permanently true — every frame rejected. Masked at the single mint point, and 0 skipped (it is also the cleared-`latest` sentinel). **3.4 (W8, W9, W12) — handle hygiene.** `shared_object_sa`'s security descriptor is a `LocalAlloc` nobody freed: leaked twice per open and once per ring recreate. It is now an RAII `SharedObjectSa` whose `Drop` `LocalFree`s it and whose `as_ptr()` only lends a borrow — which also makes the "descriptor must outlive the attributes" rule structural instead of a comment. The PyroWave fence's shared NT handle, created per capturer and never closed, becomes an `OwnedHandle` (the encoder holds its own duplicate, so closing ours is safe). `cursor_blend`'s `cbuf_scale` is cached only on a successful `Map` — caching unconditionally wedged the HDR/SDR cursor scale for the session after one transient failure. **3.5 (W7) — `f32_to_f16` swallowed the rounding carry.** `sign | half_exp | (half_mant + round)` ORs a mantissa carry into bit 10, so for every ODD biased exponent (bit 10 already set) the carry vanished and the result came back ~2× low: `1.9998779 → 1.0`, `0.49996948 → 0.25`. Only values one ULP below a power of two are affected — precisely what a gradient test pattern is full of — so this made `hdr-p010-selftest` FAIL a correct shader. Composed additively, with 4 tests (18 asserted bit patterns, a round-trip property over the self-test's scRGB values, saturation) — all verified numerically against a standalone reference on this box, including a scan confirming old-vs-new diverges ONLY on the carry cases. Phase 0.1's `--all-targets` lint is what lets these compile in CI at all. pf-capture 20/20 on Linux; workspace clippy --all-targets clean on Linux and windows-msvc. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 11:06:26 +02:00
enricobuehlerandClaude Opus 5	9a7b3a46d0	fix(pf-capture): gamescope cursor — auth without setenv, frame-space coords, live targets (2.5) ... **2.5a (L4) — stop `set_var`ing `XAUTHORITY` from a live multithreaded host.** The old connect swapped the process-global var around each `RustConnection::connect` under a mutex. That lock serialises this source against itself and nothing else: `getenv` takes no lock, so every OTHER thread's read raced it — and the concurrency is by construction, since `attach_gamescope_cursor` runs while the PipeWire thread is starting up (libspa plugin load, EGL/CUDA init). The primary path now parses the MIT-MAGIC-COOKIE-1 entry out of the given file itself and hands it to `DefaultStream::connect` + `RustConnection::connect_to_stream_with_auth_info` — the same two steps `RustConnection::connect` performs internally, minus its env-derived auth lookup — so nothing in this process touches the environment. The env swap survives only as a fallback for a file we cannot parse, and a wrong cookie pick cannot do damage: the server rejects it and the fallback (which does libxcb's full family/address match) takes over. Sharing `pf_vdisplay`'s process-wide env lock was not the fix — wrong layer, and it would still not fix `getenv`. **2.5b (L6) — publish the pointer in FRAME coordinates.** `QueryPointer` answers in the nested root's space, but `CursorOverlay::x/y`'s contract is frame pixels, and gamescope's `-w/-h` (nested root) and `-W/-H` (output + PipeWire node) are independent knobs — at `-W 1280 -H 720 -w 640 -h 360` they differ by 2×, so the pointer drew at a fraction of its real position. The root size comes free off the setup reply we already parse; the negotiated frame size arrives from the PipeWire thread's `param_changed` through a new `Arc<AtomicU64>` (`0` = not negotiated ⇒ pass through, as before). Scaling is computed in `i64` — a 5K coordinate times a 5K width overflows `i32`. Position only: the bitmap stays at root scale, warned once so a mismatched session is visible. **2.5c (L7) — the targets are a PROVIDER, not a snapshot.** The list was discovered once, before the game launched. gamescope creates the game's Xwayland at launch and advertises only the FIRST in any child's environ (verified on this box: `--xwayland-count 2` makes `:2` and `:3`, only `:2` is advertised), so the game's display was invisible — and when the connected Big Picture display then reported "gamescope is not drawing the pointer here", the source blanked the cursor for the whole game session, which is the exact regression the module doc says it fixed. The worker now re-runs the provider every 2 s: it adopts new Xwaylands, reconnects dead ones, and `spawn` no longer returns `None` on an empty list — a stream that starts before the game converges instead of staying cursorless. The provider is a host-facade closure, same one-way-edge shape as `FrameChannelSender`. **2.5d (L8) — bound the teardown join.** `Drop` joined the worker unbounded while the worker blocks in `RustConnection` replies with NO read timeout, so a peer that stops answering but keeps its socket open hung capturer teardown — on the session path. Now: a completion channel, `recv_timeout(250 ms)`, then detach with a warning (the thread only touches its own X connections and an `Arc`'d slot). 7 new tests, all host-runnable: the cookie reader against a hostile `.Xauthority` (wrong protocol, wrong display, wildcard entry, truncation mid-length-prefix, an over-long length prefix, a missing file), display-string parsing, and the root→frame mapping incl. the 5K overflow. pf-capture 20/20; workspace clippy --all-targets clean on Linux and windows-msvc. Phase 7.2 owes the on-glass nested-gamescope validation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 10:56:05 +02:00
enricobuehlerandClaude Opus 5	759fdf767c	fix(pf-capture): buffer-geometry guards + a genuine drop-oldest hand-off (sweep 2.4, 2.6) ... **2.4 — buffer geometry correctness on the Linux CPU path.** L5: the self-mmap de-pad mapped the fd from offset 0 and then indexed by `chunk.offset()` ALONE, ignoring `spa_data.mapoffset` — where that spa_data's region actually begins inside the fd. For a pooled-memfd producer (every buffer a slice of one fd) it therefore read the WRONG buffer, and the `needed > avail` guard could not catch it: `avail` came from the whole-fd mapping, so it was ample for any single buffer's span. PipeWire's own MAP_BUFFERS slice (the fallback) was always correct because it already starts at `mapoffset` — only the hand-rolled "fix" path was wrong, so the two paths now compute their base separately (checked add; both halves are producer-controlled). L15: when `fstat` failed, the mmap length was invented as `offset + needed` — producer-controlled geometry. That defeats the entire point of the fstat (the "buffer smaller than the frame span" guard then compares against the number the producer just supplied) and can map, and read, past the end of the object — a SIGBUS, not an `Err`. Without a real length we now decline to self-map and let PipeWire's own slice serve, which is bounded by construction. L12: `bytes_per_pixel()`'s catch-all answers 4 for NV12, so a producer-native NV12 buffer computed `row = 4w` against a stride of ~w and ALWAYS tripped the stride guard — reporting "chunk stride < row", i.e. blaming the producer for a host limitation. NV12 cannot be de-padded on this path at all (plane 1 is not even in `datas[0]`'s span), so reject it with a message that says which side is at fault and under what condition the NV12 offer is valid. L14: `spa_meta_bitmap` was read field-by-field through an aligned `*const` at a PRODUCER-controlled offset, with a SAFETY comment asserting an alignment the code never established. One `read_unaligned` of the `Copy` POD instead. **2.6 — hand-off semantics (L9, L10).** The frame channel was `sync_channel(8)` + `try_send`, i.e. drop-NEWEST, while the trait documented drop-oldest. Neither remedy the plan offered works: a `SyncSender` cannot pop, so "drain one and retry" is not expressible, and shrinking the bound makes staleness WORSE, not better (with bound N the queue holds the first N frames of a stall and everything after is discarded, so a larger N actually yields a fresher frame — the defect is the discarding, not the depth). Replaced with a one-deep OVERWRITING mailbox plus a depth-1 wakeup channel: publishing overwrites, so a stalled consumer loses the intermediate frames and is always handed the freshest one. `next_frame` used to return the OLDEST of eight stale frames. Falls out of it: - `wait_arrival` now honours its documented "must NOT consume" contract by peeking the slot. The `pending` field existed only to stash a frame the un-peekable channel forced it to consume; it is gone. - a queued `CapturedFrame` can own a dup'd dmabuf fd or a CUDA buffer, so the old 8-deep backlog could pin eight compositor buffers. One-deep by construction now. - L10: `set_active(false)` flushes the mailbox, so a reused capturer no longer opens the next stream with the previous session's last frame (wrong content, and a `pts_ns` from the old clock). Two lines, where flushing a queue + a `pending` stash was fiddlier. - the producer-liveness signal moves to the wakeup channel's `Disconnected`, and a final frame left in the slot as the thread exits is still served before the error. pf-capture 13/13; workspace clippy --all-targets clean on Linux and windows-msvc. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 10:48:18 +02:00
enricobuehlerandClaude Opus 5	17eb8100a3	fix(pf-capture): portal teardown, observable death, one negotiation resolver (sweep 2.1–2.3) ... **2.1 (L1) — the portal thread leaked a live screencast session.** It parked on `future::pending()` and `Drop` stopped only the PipeWire thread, so every dropped portal capturer permanently leaked a thread + a 2-worker tokio runtime + a zbus connection — and because dropping that connection is what ends the compositor's cast (ashpd's `Session` has no `Drop`), the COMPOSITOR-side session leaked too. GameStream drops the pooled capturer on every HDR↔SDR reconnect flip and opens a fresh one, so the sessions accumulated: exactly the "second conflicting screencast" the pooling exists to prevent. Both portal threads now park on a `oneshot::Receiver` and `PortalSession::drop` fires it, then waits — BOUNDED (750 ms, then detach with a warning) — for a completion signal the thread sends after its runtime has been dropped. Bounded because teardown runs on the session path and the thread may be inside a D-Bus round-trip: an unbounded `join()` there would hang the host rather than leak. Every early-return path in `open` drops the session too, so a failed PipeWire spawn no longer strands a fresh cast. **2.2 (L2) — a dead capturer was pooled forever.** All three of the portal backend's terminal states are sticky and observable only by consuming a frame, and `Capturer` exposed no health predicate, so GameStream re-pooled unconditionally — after `result` was already an `Err`. One zerocopy-worker death or one compositor restart therefore wedged GameStream portal video at 10 s per reconnect attempt, permanently (that path has no rebuild closure). Adds `Capturer::is_alive()` (default `true`), implemented for `PortalCapturer` as `!broken && streaming && !thread.is_finished()` — the third term catches a dead PipeWire thread, which is otherwise indistinguishable from an idle desktop. A static desktop stays `Streaming`, so an idle-but-healthy capture is never reported dead. The host re-pools only on `result.is_ok() && capturer.is_alive()` and logs which of the two retired it. Both halves ship together: either alone leaves the wedge reachable. **2.3 (L3/F1) — a "VAAPI" downgrade latch was really a global zero-copy kill switch.** `spawn_pipewire` hand-mirrored the thread's `vaapi_passthrough` decision and the copy omitted `raw_dmabuf_import_disabled`, so once that latch fired the capturer still believed it had made the passthrough offer while the thread had already fallen back — and its timeout branch then latched a downgrade for an offer nobody made. That downgrade was `note_vaapi_dmabuf_failed`, which fed `pf_zerocopy::enabled()`, so ONE failed negotiation dropped every later session on the host — the NVENC EGL→CUDA path included — to CPU capture until restart. And since the raw-passthrough offer is also the PyroWave one on ANY vendor, a single PyroWave negotiation timeout was enough to do it on an NVIDIA box. Two fixes, both structural: - `negotiation_plan(NegotiationInputs) -> NegotiationPlan` is now the ONE resolver, consumed by the thread AND by `spawn_pipewire` — the mirror is deleted, not re-synced (WP7.6's shape), so the drift class is unrepresentable. It is pure (every env/latch read is an input), which is what makes it testable; the runtime-dependent half stays a method (`want_dmabuf` needs the modifier list the importer's construction actually yielded). The redundant `importer.is_none()` term goes: `build_importer` already excludes the passthrough, and that term is what made the decision look impure enough to "need" a mirror. `PUNKTFUNK_FORCE_SHM` was ALSO read in both places; now once. - the capture-side downgrade becomes `pf_zerocopy::note_raw_dmabuf_negotiation_failed`, which latches `RAW_DMABUF_DISABLED` — gating only the raw-passthrough decision. `enabled()` is now the env var alone, and `VAAPI_DMABUF_FAILED` is deleted. Also (L13, needed by 2.3's plan inputs): `PUNKTFUNK_PIPEWIRE_NV12` honoured only the exact string `"0"`, so `"0 "` or `"false"` read as force-ON — the bug class of ed525c4c. pf-host-config's explicit-off grammar is now exported as `env_on()` and the four in-crate copies (`PUNKTFUNK_ ZEROCOPY`/`_10BIT`/`_444`/`_CHACHA20`) plus this new caller share it. 7 new tests pin the four invariants that were prose-only comments, plus the latch property that made the mirror wrong. pf-capture 13/13; workspace clippy --all-targets clean on Linux and on x86_64-pc-windows-msvc. On-glass validation of 2.1/2.2/2.3 is owed (sweep Phase 7.1). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 10:41:53 +02:00
enricobuehlerandClaude Opus 5	54a37aeb46	docs(pf-capture): truth pass over comments, docs and log strings (sweep Phase 1) ... Every item here is prose that actively misdirects a maintainer or an operator. Landing it before the defect fixes means those diffs get reviewed against accurate comments. 1.1 (X5) — split two merged doc blocks that documented the item ABOVE them: `hdr_meta`'s whole contract was glued onto `fn cursor()` in lib.rs (leaving `hdr_meta` undocumented), and `hdr_p010_selftest_at`'s was glued onto `hdr_p010_convert_bars_on_luid` in dxgi.rs. rustdoc for the trait's central HDR contract was simply wrong. 1.2 (L9 doc half) — the `Capturer` trait doc advertised a "bounded drop-oldest channel". The Linux portal's `sync_channel(8)` + `try_send` is drop-NEWEST: under a consumer stall the arriving frame is discarded and the encoder gets the stalest queued one. Say so. (Phase 2.6 changes the behaviour; this commit only stops the doc from lying about today's code.) 1.3 — delete the DONT_FIXATE claim from the dmabuf offer comment. `build_dmabuf_format` emits a plain MANDATORY `ChoiceEnum::Enum` and `param_changed` re-emits nothing, so there is no two-step DMA-BUF handshake here; libspa 0.9's `ChoiceFlags` cannot even express DONT_FIXATE. Recorded as a real follow-up instead of an implemented thing. 1.4 — `mainloop.run()` no longer "blocks until process exit": the quit channel attached above it stops the loop from `PortalCapturer::drop`. 1.5 (L11) — the 6-arm negotiation log ladder told a fully zero-copy PyroWave session "VAAPI encode with the CPU capture path — zero-copy was disabled", one line after logging that it had advertised the PyroWave device's dmabuf modifiers: the passthrough arm was gated on `pyrowave_modifiers.is_empty()`, so the pyrowave case fell through to the CPU warning. Ungate it; the CPU-path arm is now reachable only when no dmabuf is advertised at all, which is what it claims. Its parenthetical also gains the third real cause (the session asked for CPU frames). Control-flow-neutral for every other combination. 1.6 (W13) — `kick_dwm_compose` claimed a "sub-millisecond" round trip while its cursor-on-a-sibling-display branch sleeps 35 ms on the CALLER's thread. State the cost on the function and at both call sites, including which one is on the live frame path. 1.7 (W16) — DDA-era residue, DDA having been removed: - retarget the win32u hook's rationale + all four log strings: its job is no longer "keep DDA on one adapter" but "keep the virtual display on the adapter SET_RENDER_ADAPTER pinned" (a DXGI reparent surfaces as the driver's TEX_FAIL render-adapter mismatch). The hook stays installed. - the per-monitor-v2 DPI awareness rationale likewise: not DuplicateOutput1's E_ACCESSDENIED any more, but keeping cursor/window coordinates in the PHYSICAL pixels the host's CCD geometry (`source_desktop_rect`, `desktop_bounds`) is already in. - `HYBRID_HOOK_HITS` was write-only. Surface it as `hybrid_hook_hits()` on the IDD-push open line, which is the first point where DXGI has actually been exercised — the patch-readback check proves the bytes landed, only this proves DXGI reaches the export. - delete `hdr_p010_selftest()`: an unreachable 64×64 wrapper (main.rs calls `hdr_p010_selftest_at`); its description moves onto the function that survives. - `VideoConverter`'s docs promised a P010/BT.2020 output and a live scRGB input path. It pins `YCBCR_STUDIO_G22_LEFT_P709` unconditionally and its only caller always passes `scrgb_input: false`. 1.8 (X7) — the native handshake's 4:4:4 gate comment stated the OPPOSITE of what `pf_capture::capturer_supports_444` returns on Windows ("delivers subsampled NV12/P010 today, so it returns false there" — it forwards `resolved_backend_ingests_rgb_444()` and the IDD ring passes BGRA through for an SDR 4:4:4 session). No `.rs` behaviour delta: comments, doc comments and log strings, plus 1.5's control-flow-neutral ladder and 1.7's counter accessor. Linux tests 6/6; clippy --all-targets clean on both targets. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 10:27:06 +02:00
enricobuehlerandClaude Opus 5	6a2a153c0b	chore(pf-capture): make the crate verifiable — Windows CI lint + two denies (sweep Phase 0) ... Gate for the rest of design/pf-capture-sweep.md: today half this crate is compiled by no CI job at all, so the Windows-side findings can't even be type-checked. 0.1 (X1) — windows-host.yml lints `-p pf-capture --all-targets`. The host lint above it builds pf-capture only as a DEPENDENCY, so its `#[cfg(test)]` modules were never compiled anywhere: the 5 StallWatch tests, the DXGI HDR self-tests and the cursor-conversion tables were dead code in CI. The workflow's own comment already diagnosed this blind spot and fixed it for pf-encode; pf-capture never got the same treatment. No features on this crate, so no feature juggling and no extra dep tree. 0.2 (X2) — `#![deny(unsafe_op_in_unsafe_fn)]` beside the existing `deny(clippy::undocumented_unsafe_blocks)`. The crate declares "every unsafe block carries a SAFETY proof; enforce it" in ten file headers, but in edition 2021 that lint has nothing to fire on inside an `unsafe fn` — so the hardest FFI in the crate was exempt from its own program: the ring/slot construction, the fence signal, the blend scratch, and every D3D converter ctor/convert. 119 operations across 16 functions now carry a proof. `shared_object_sa` loses its `unsafe` marker instead (it states no precondition — only its RESULT is a raw pointer, which is the caller's business). 0.3 (X4) — drop the crate-wide `#![allow(dead_code)]`. Verified: zero warnings on either target without it, so it was hiding nothing the lint can see (W16's dead items are `pub`/written-once, so they need Phase 1.7's deletion instead). No behaviour change: only lint attributes, `unsafe { }` scoping and comments. Linux `cargo test -p pf-capture` 6/6, clippy --all-targets clean on both targets (Windows verified by cross-checking x86_64-pc-windows-msvc locally). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 10:18:48 +02:00
enricobuehlerandClaude Opus 5	bf9386ecb2	test(pf-encode): pin the typed-EINVAL classifier's chain-survival contract (Phase 8) ... Rides on 25765c53 (the concurrent session landed the same typed-errno fix first — this branch's twin commit was dropped in the rebase; these are its surviving residuals): - Two tests pinning what the ladder's step-down rests on: the typed ffmpeg::Error survives with_context layers as a downcastable source (an eager format! anywhere between open_with and the ladder would silently break it), and the phrase WITHOUT the type no longer classifies. - The CudaHw::new eager-format guard note: those bail!s must NOT be converted to typed errors — a hwdevice/hwframes EINVAL is a config error no bitrate can fix, and enrolling it would burn ~10 doomed opens before surfacing the real failure. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 10:13:49 +02:00
enricobuehlerandClaude Opus 5	bf9fb3fb22	fix(pf-encode): enable VK_EXT_queue_family_foreign for the dmabuf acquires (Phase 8) ... Both Linux Vulkan encode backends named QUEUE_FAMILY_FOREIGN_EXT as the acquire barriers' src family without ever enabling the extension — spec-invalid on every device, tolerated by RADV. The audit filed vulkan_video's three sites; pyrowave's fresh-import acquire had the identical defect on its own device (critic catch). Enable when advertised (a fresh open-time enumerate — the rgb probe's is a probe-local and skipped entirely on native-NV12, so there was nothing to reuse; pf-presenter/dmabuf.rs is the in-repo precedent that already enables this extension). Not advertised → the core-1.1 QUEUE_FAMILY_EXTERNAL conservative substitute, chosen once at open and warn-logged (no fleet hardware takes that arm; such devices were never valid targets before). All four sites are acquire-only (src=FOREIGN, EXCLUSIVE images, oldLayout=UNDEFINED) — the swap is index-only. On-glass: 780M under validation layers — vulkan smokes + pyrowave smokes green, FOREIGN advertised and enabled, no fallback engaged. Shared ext_advertised helper in vk_util (cfg = the union of both consumers) with a unit test. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 10:08:44 +02:00
enricobuehlerandClaude Opus 5	1cefd37603	fix(pf-encode): arbitrate NVENC split-encode vs sub-frame readback (Phase 8) ... Verified against nvEncodeAPI.h's own splitEncodeMode doc (user-prompted — the audit's 'exclusive for HEVC' one-liner deserved checking): - H.264: split 'is not applicable' — hard-DISABLE the mode so the written config, CeilingKey, the split diagnostic log and the rejection-retry stay truthful (the retry used to re-open a byte-identical session after an H.264 'split rejection'). The libav path's operator arm gains the codec gate its auto arm always had. - HEVC: split 'not supported if … subframe mode' — when WE force split (TWO/THREE/AUTO_FORCED, the 4K120 throughput lever), sub-frame yields with a logged escape (PUNKTFUNK_SPLIT_ENCODE=0 chooses sub-frame). ⚠ Keyed on FORCED modes only, never != DISABLE: AUTO(0) is the resolver's fallthrough for every sub-950Mpix session, and the wider key would have disarmed the Phase-3 chunked-poll feature fleet-wide (critic catch). Under AUTO the driver arbitrates — the shipped state. - AV1: untouched — per-tile sub-frame + split are legal together. The arbitration is a pure nvenc_core fn called by each backend BEFORE the ladder, the ceiling key and the chunked-poll latch — all three see the post-arbitration truth. A drop inside build_init_params would have left poll_chunk busy-polling its whole budget every AU (numSlices stays 0 without reportSliceOffsets; both loop exits dead — critic catch). Linux latches subframe_forced beside subframe_on at query_caps (no env re-reads after open); Windows records the arbitrated state so reconfigure presents exactly the params the open had (also closes the pre-existing mid-session env-flip hazard there). Truth-table tests in nvenc_core; PUNKTFUNK_NVENC_SUBFRAME documented (it never was); PUNKTFUNK_SPLIT_ENCODE row updated. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 10:08:44 +02:00
enricobuehlerandClaude Fable 5	25765c53ec	fix(encode): classify libav-NVENC open failures by errno, not English strerror text ... The bitrate-probe ladder stepped down on format!("{e:#}").contains( "Invalid argument") — an English substring over the WHOLE context chain, which also fired on any other wrapped EINVAL (e.g. a CUDA-context errno) and gated a ~10-step ladder on strerror wording. The root ffmpeg::Error survives the anyhow chain; downcast and match Error::Other{errno:EINVAL} instead. Same fix for the intra-refresh ENOSYS probe in the open path. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-26 01:05:24 +02:00
enricobuehlerandClaude Fable 5	36589c39da	fix(gamestream): stall-recovery ladder — a wedged encoder no longer ends the stream ... The backends deliberately turn a wedged GPU into a bounded error so the caller can reset in place, but only the native plane ever did: on the GameStream path every submit/poll error propagated straight out of the video loop, costing Moonlight clients a full disconnect/reconnect. Port the native ladder (bounded resets + backoff + silent-wedge watchdog, same field-lesson backoff curve). Also keep the drop-recovery keyframe armed until it actually EMITS: it was consumed on read, so the coalesce gate could swallow it for good — leaving duplicate wire indices in the encoder's reference table for a later RFI to anchor on, exactly the stale-anchor case rfi.rs exists to prevent, and it opened only under congestion + loss, which is when RFI fires. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-26 01:05:23 +02:00
enricobuehlerandClaude Fable 5	e3354b6d5d	fix(encode/vulkan): guard the CSC source dimensions, and bound reset()'s wait ... The CSC path was the only backend arm that took frame.width/height on trust: the shader samples with clamped 1:1 texelFetch, so a mismatched frame silently streamed a cropped/edge-padded picture where every sibling errors into the encoder-rebuild path. The import cache now also carries the extent it imported at (a (st_dev, st_ino) hit alone doesn't prove the allocation still matches) and is dropped on reset(). reset() opened with an untimed device_wait_idle on the one thread whose every other wait is capped at ENCODE_FENCE_TIMEOUT_NS for exactly this reason — reset() runs BECAUSE the GPU looks wedged. Both vulkan-video and pyrowave now bound the wait and report "no in-place rebuild" on timeout instead of parking recovery on the suspect device; Drop keeps the unbounded wait (teardown must stay memory-safe against a wedged device). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-26 01:05:10 +02:00
enricobuehlerandClaude Opus 5	28f8fc71c4	refactor(pf-encode): split vulkan_video's construction tail into vk_build.rs (WP7.5) ... The ~820-line tail of free builders — make_frame/make_frame_csc/ make_frame_common, make_video_image, probe_rgb_direct, the H.265/AV1 parameter-set writers and the AV1 bit-writer — moves to a #[path] child module, the amf_sys.rs shape: the child sees the parent's private items (Frame and friends), so the split costs zero visibility churn. Six parent-called items went pub(super); five stay child-private (dead_code is per-item and each is used within the child). vulkan_video.rs drops 5,292 → 4,489 lines and the construction unsafe gets its own review surface; steady-state encode logic stays in the parent. ⚠ Trap recorded for future child-module splits: inline `use super::X` statements INSIDE moved fn bodies silently change meaning (super shifts one level) — vk_av1_encode/vk_valve_rgb imports needed crate:: paths. Proven on-glass, not just compiled: all 8 vulkan GPU smokes green under the validation layers on the 780M post-split (H.265 + AV1, RGB-direct, CSC, CPU paths — every moved constructor exercised). nvenc_cuda.rs and qsv.rs are DECLINED the same treatment, with evidence in the handoff doc: no equivalent self-contained seam — their candidate regions are ~150-line loader/accessor clusters interleaved with the encoders' own state types, and a thin-forwarder impl split is exactly the churn a no-defect phase penalizes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 00:08:03 +02:00
enricobuehlerandClaude Opus 5	bc5ec5105c	refactor(pf-encode): one Linux backend resolver, consumed by dispatch AND mirrors (WP7.6) ... The Linux backend decision existed as open_video_backend's string match plus five partial hand-copies (the zero-copy-plane gate, the pyro advertisement gate, the software advertisement pin, the vulkan pref ceiling, resolved_backend_is_gpu). Windows solved this long ago — windows_resolved_backend() is consumed by its dispatch AND its mirrors, with labels still stamped at the open sites. Linux now has the twin: resolve_linux_backend (pure, lazy auto probe) + linux_resolved_backend (config wrapper, unknown→auto exactly as every mirror's old `_` arm). ⚠ This deliberately DEVIATES from the audit's shadow-assertion prescription, on both critics' findings: the shadow had no execution venue (open_video had ZERO test call sites; shipped hosts are --release) — unfalsifiable ceremony — and the file's own Windows half proves dispatch-consumes-resolver is safe: the mgmt record is protected by the label-from-the-open-site convention, not by resolver avoidance. One consumed table beats two tables plus an inert cross-check. Preservation riders from the critique, all applied: - pref_ceiling KEEPS its cfg!(vulkan-encode) branch (the resolver is feature-blind; dropping it re-creates advertise-then-die-at-open). - linux_zero_copy_is_vaapi's Vulkan|Software arm preserves the old `_` fallthrough EXACTLY — the vulkan-on-NVIDIA capture-plane mismatch and the software twin are FILED in the design doc, not fixed here. - resolved_backend_is_gpu splits as linux + not(any(windows, linux)) — never a target list, so no exotic target loses the fn. - The auto probe is lazy (impl FnOnce) — explicit prefs stay zero-probe (/serverinfo polls through these mirrors), pinned by a panicking closure in the resolver test. New coverage: the full alias table pinned, and a GPU-free dispatch test through the real open_video_backend (software arm, vendored openh264) — its first test call site anywhere. Config-latch seam guarded loudly. Cross-crate mirrors recorded out of scope in the design doc: session_plan::resolve_encoder, gamestream/serverinfo.rs base_codec_mode_support, capture.rs's "pyrowave" string. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 00:08:03 +02:00
enricobuehlerandClaude Opus 5	cb69cd3b8c	refactor(pf-encode): move the AMF C-ABI mirror to its own file (WP7.4) ... The ~410-line hand-mirrored AMF vtable ABI was already isolated in an inline `mod sys` — the remaining value of the audit's 'best split in the crate' is the FILE boundary: amf.rs drops 3379 → 2965 lines and the pure unsafe-FFI surface (25 unsafe fns, zero policy) is reviewable in isolation, which is the crate's stated review goal. Pure move: `#[path = "amf_sys.rs"] mod sys;` keeps the module name and every `sys::` call site byte-identical; the module was self-contained (only `use std::ffi::c_void`, no super:: references). The banner became the file's module docs; contents de-indented one level — rustfmt-clean on the first check, which is what proves the move byte-exact. Gated on .173: all five clippy combos + the amf-qsv,qsv test leg (38 passed — the live AMF matrix on real VCN silicon among them). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 00:08:03 +02:00
enricobuehlerandClaude Opus 5	9491cc8759	refactor(pf-encode): extract the range-family RFI recovery policy (WP7.2) ... The two direct-NVENC backends carried hand-copied twins of the same loss-recovery decision: range validity, covering-range dedup, DPB window, clamp — ~30 duplicated lines each. The decision now lives once as nvenc_core::plan_range_recovery (the range half of WP7.2; the slot half is enc/rfi.rs), pure and unit-tested; each backend keeps its session gate, its unsafe per-timestamp driver loop, and its state stores. The step order is load-bearing and now pinned by tests: the covering dedup runs with the UNCLAMPED last and BEFORE the DPB window (a covered re-ask never touches the driver even when the range has since aged out of the DPB), the boundary at next_ts - RFI_DPB is inclusive, and the Invalidate carries the CLAMPED last — which is also what the caller records in last_rfi_range, exactly as the inline code stored it. A driver failure mid-loop still returns false with NO range recorded and no anchor armed. Decline deliberately clears nothing (neither twin touched pending_anchor on decline — same shape as Vulkan's non-clear, opposite of AMF/QSV; do not harmonize). The exact-cover → Covered test records EXISTING behavior including that a covered range survives a forced IDR with zero driver calls — a recorded fact, not an endorsement. RFI_DPB's import leaves both twins: its only per-backend use was the arithmetic that moved. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 00:08:03 +02:00
enricobuehlerandClaude Opus 5	9f1e648e4e	refactor(pf-encode): extract the slot-family RFI recovery policy (WP7.2) ... AMF (user-LTR bitfield), QSV (mfxExtRefListCtrl) and Vulkan Video (the app-owned DPB slot table) each hand-implemented the same loss-recovery decision: distrust every reference encoded at-or-after the loss start, anchor on the newest one strictly older. Three copies had already diverged once — the fecbec2d taint sweep reached AMF/QSV a commit before the Vulkan backend was carved out, and Vulkan shipped without it. The decision now lives once in enc/rfi.rs, pure and unit-tested (this path had zero coverage and is the loss-recovery path); every mechanism — how a force is applied, how distrust is persisted — stays in its backend. Behavior-preservation notes, each critic-verified against the shipped code: - Callers feed only currently-trusted references; taint (>= loss) and anchor (< loss) predicates are disjoint, so pre-sweep-view pick == post-sweep-table pick on every input. Tie-break preserved (first entry wins == the strict '>' all three used, ascending slot order). - plan_slot_recovery delegates its pick half to pick_anchor, which keeps both items live on every leg (pick_anchor's only external caller is Linux+vulkan-encode; dead_code is an item lint) and makes 'anchor chosen from the taint snapshot' structural. - The decline arms are deliberately NOT uniform and stay put: AMF/QSV clear an un-consumed pending_force; Vulkan leaves pending_loss armed (a stale arm re-resolves at frame-build into the healing IDR) — now pinned in comments on both sides. - Vulkan's frame-build site is a pick-only re-run by design (the arm carries the loss start, not the slot); pick_recovery_slot is deleted and its tests migrated 1:1 into the shared module. Test-count deltas are expected: the rfi tests now run on every Windows combo (amf.rs is featureless there) and on the Linux feature leg. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 00:08:03 +02:00
enricobuehlerandClaude Opus 5	d28fb1282b	test(pf-encode): guard TrackedEncoder's forwarding completeness (WP7.7, cheap half) ... A defaulted Encoder method that TrackedEncoder doesn't forward silently no-ops through the wrapper — the host loop only ever holds the wrapped box, so the feature dies for every session with nothing in the logs. The trap has bitten three times (set_wire_chunking's §4.4 chunking probe, set_pipelined's LN3 escalation, applied_bitrate_bps's ABR truth), and every Phase 7 consolidation that adds a trait method re-arms it. Source-text parse of the trait and the forwarding impl (both top-level rustfmt items: block ends at the first column-0 brace, method names sit on 'fn '-prefixed lines), then set equality — the reverse direction is already a compile error, so equality == completeness. Mutation-verified: removing set_wire_chunking's forward fails naming exactly that method. 16/16 today. Limit stated in the test doc: name-set equality only — a forward whose body delegates to the WRONG inner method still passes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 00:08:03 +02:00
enricobuehler	94b818da28	fix(client/pyrowave): declare the decode planes' real format — 10-bit sessions decoded through an R8 view of R16 planes ... The HDR/4:4:4 leg (188edde2, shipped 0.14.0) taught the client's plane ring to allocate R16_UNORM on a 10-bit session, but the pyrowave_image_view structs handed to decode_gpu_buffer kept the original SDR shape: image_format/view_format hardcoded R8_UNORM, chroma extents hardcoded half-res. pyrowave wraps our VkImage under the DECLARED format and vkCreateImageView's its storage view from it (pyrowave_c.cpp WrappedViewBuffers::wrap) — an R8 view over a non-MUTABLE R16 image is invalid Vulkan that release drivers execute anyway: the view's addressing covers half the surface, so the iDWT's 8-bit codes fuse pairwise into 16-bit texels (structured tile-scrambled garbage) and the never-written remainder samples as all-plane zeros (saturated green). Field report 2026-07-25: RX 9070 XT host → 780M client, total corruption on every 10-bit PyroWave session regardless of bitrate/refresh, wire counters spotless; milder shapes of the same UB on NVIDIA clients; Arc validation never saw it because it ran SDR (R8 ring — declaration consistent by accident). Declare what the ring really built: format from hdr16 (R16/R8), chroma extents from chroma444 (full-/half-res) — exactly what upstream's own pyrowave_image_get_image_view fills from the image itself. Host encoders audited clean: Windows keys plane formats off hdr16 already, Linux is 8-bit end to end.	2026-07-25 21:39:30 +02:00
enricobuehlerandClaude Opus 5	3e7828522d	fix(tray): drop the conflicting-host warning — the tray is the wrong place for it ... The tray led its tooltip with "⚠ conflicting host: Sunshine" and (on Linux) went NeedsAttention for a Sunshine that was merely *installed* — never started, never listening, harmless. An always-on warning over a dormant package is a false alarm on every poll, and the tray is the wrong surface for a one-shot install-time observation anyway. Removes the `conflicts` field from the tray's `Summary`, the tooltip prefix, `has_conflicts()`, and the ksni attention branch that fed on it. The host still detects and reports conflicts where that belongs — the startup `punktfunk::detect` warning, the `detect-conflicts` subcommand, and the `/api/v1/local/summary` field, which the tray must (and does, per the new test) keep tolerating on the wire. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 20:53:44 +02:00
enricobuehlerandClaude Fable 5	ffc7aec91a	feat(encode/pyrowave): log which GPU pyrowave picked — the selection stays put, by decision ... WP4.5's device-selection half, closed as the observability intermediate after TWO selection designs died in adversarial review: - Attempt #1 (d26bcf05, withdrawn): match pf_gpu::selected_gpu(). Its Linux auto arm answers "the NVIDIA GPU" whenever /dev/nvidiactl exists, moving the encoder off the iGPU that can import the compositor's dmabufs on an Intel-compositor + NVIDIA-present laptop — import failures feed the process-wide raw-dmabuf latch, which never un-latches. - Attempt #2 (this session, withdrawn before commit): anchor on the PUNKTFUNK_RENDER_NODE-else-renderD128 node via VK_EXT_physical_device_drm. Render minors are driver-BIND-ORDER artifacts, not display topology: on the common AMD-iGPU + NVIDIA-display desktop, in-tree amdgpu binds before out-of-tree nvidia, so the anchor deterministically picks the idle iGPU while the compositor allocates on NVIDIA — the same latch, opposite polarity, behind a success-looking log. The correct oracle is evidence of which device ALLOCATED the capture buffers — producer identity from the capture negotiation, threaded per session into this open. Until that plumbing exists, selection stays first-usable, both call sites still share one selector (pure over the device list, so capture_modifiers and open_inner cannot diverge — including across an in-place resize's re-open, which does not renegotiate capture), and the open logs ONE greppable line: picked vendor/device, the anchor node and its owner (DRM render major/minor, VK_EXT_pci_bus_info fallback), and the console's selected GPU. A wrong-device session on a multi-GPU host used to be completely invisible; a field report can now show it. No WARN arm on purpose: the wrong-pick direction inverts between the laptop and desktop topologies, so a mismatch is not evidence of a wrong pick, and a warning that fires forever on healthy hosts teaches people to ignore warnings. Decision recorded against the audit's framing: manual console GPU selection stays unhonored by pyrowave on Linux (the Windows twin honors it) — honoring console-mutable state without per-session threading is what made attempt #1 unsafe. Verified on the 780M: the line resolves all three identities (1002:15bf x3, DRM-props match live); full pyrowave on-glass suite green; selection behaviour byte-for-byte unchanged. WP4.5 (device half). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 19:22:28 +02:00
enricobuehlerandClaude Fable 5	46935bf0a5	fix(encode/vulkan): VBR instead of CBR — the driver was stuffing ~98% filler into every calm stream ... Second attempt at WP6.3; the first (ce543668) was withdrawn after its tight CBR window measured as a 36x bandwidth regression (97% filler NALs). The correction that unlocked this one: that measurement's BASELINE row was an 8-frame artifact. Under the shipped 1000ms/500ms CBR window a calm stream overflows the CPB once the initial fill drains (~30 frames at 10Mbps/60fps) and RADV then pads every frame to the exact rate share, forever. Measured on the 780M (1280x720@60, 10Mbps, calm content): 64 frames = 97.5% filler; 300 frames = 5.63MB at 98.5% filler where this commit ships 83KB at 0%. AV1: 99.6% -> 0%. The status quo was ~the full target bitrate of zeros on every idle AMD/Intel Vulkan-encode desktop and Steam Deck — and stuffing to exactly the target permanently satisfied the ABR calm brake (actual >= 3/4 * current), the ratchet WP6.3's withdrawal feared from the tight window, live in the shipped code all along. The fix reads VkVideoEncodeCapabilitiesKHR::rateControlModes (previously ignored — rateControlMode was hardcoded CBR with no capability check) and installs VBR with average == max plus the house ~1-frame window (vbv_window_ms, PUNKTFUNK_VBV_FRAMES-scaled) when the driver advertises VBR. VBR permits underspend, the exact missing degree of freedom: Vulkan exposes no filler-suppression control (AMF's filler_data=false / NVENC's default-off have no VK equivalent), so the MODE is the only lever. CBR-only drivers keep the loose window untouched — tightening it under CBR just starts the stuffing 30 frames earlier. Drivers advertising neither mode (ANV per current Mesa) keep the pre-existing CBR install, now WARN-logged. No pacing claim, deliberately: burst A/B on the 780M is byte-identical between 1000ms CBR and 17ms VBR (max AU 1.19MB in both) — this firmware ignores the window for QP decisions entirely. The payload is filler elimination. PUNKTFUNK_VULKAN_RC=cbr|vbr is the field escape hatch and the on-box A/B control (two withdrawn attempts bought that insurance). Also on the same caps struct: maxBitrate is now read and clamps open + retarget (RADV reports 1 Gbps — within 5% of the 4K120 ABR targets), and applied_bitrate_bps() reports the encoder-side truth (pending-first, so the session loop's read right after reconfigure_bitrate sees the clamp) — without it a binding clamp would feed the ABR a phantom base, the trap the trait doc names. And the one-frame VUID-vkCmdBeginVideoCodingKHR-pBeginInfo-08254 violation found in the withdrawal review: record_submit promoted a pending retarget into self.bitrate BEFORE recording whenever first_frame was set, so after a mid-stream reset() (which preserves the pending rate and rc_installed) the begin-coding declaration named a rate the session had not installed — and the two triggers, ABR retarget and the stall watchdog, correlate. Now the declaration always names the session's current rate and the RESET install carries the pending one via its own struct; promotion stays in post_submit_bookkeeping. The extended validation-layer test reproduces the retarget-then-reset coincidence: exactly one 08254 on the pre-fix build, zero on this one (RADV PHOENIX, on glass). Gates: docker amd64 legs green; Windows .173 seven legs (34 passed); .25 full-suite parity vs origin/main (identical CUDA-only failures) + all 9 vulkan on-glass tests + validation layers clean. WP6.3, plus WP7.1's ms-form half (vbv_window_ms). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 19:22:12 +02:00
enricobuehlerandClaude Opus 5	fdded5b8c3	fix(encode/pyrowave): refuse a frame that isn't the session's mode ... PyroWave never checked frame dimensions against the session, and it applies no alignment — `width`/`height` are the negotiated mode verbatim — so a mismatched frame was encoded edge-smeared or cropped, silently, forever. Every other Linux backend already refuses exactly this, with this shape, in `submit`: libav-NVENC (`linux/mod.rs`), VAAPI (`vaapi.rs`) and openh264 (`sw.rs`) all carry the same `ensure!`. PyroWave was the only one that didn't. That is the justification; an earlier draft cited `vulkan_video.rs` instead, which is the weaker precedent — it bails in its Dmabuf arms only, and its CSC path and CPU arm have no dimension guard at all. Mostly this is a wrong-picture bug and not a memory-safety one: `rgb2yuv.comp` clamps every fetch with `min(p, textureSize - 1)` and the CPU arm uploads `min(len, need)` into a session-sized image. But it also closes a narrow real hazard that was not in the filing: `import_cached` keys on `(st_dev, st_ino)` and returns the cached `VkImage` on a hit WITHOUT rechecking the extent, and unlike the capture side it is never cleared on a renegotiation — so a dmabuf inode recycled across a shrinking renegotiation would hand the encoder an image sized for the old, larger allocation. This check closes that route. ⚠ Recorded at the code because it changes the failure mode, not just the detection: a mismatch is NOT always transient. A compositor-initiated PipeWire renegotiation updates the capturer's size in place and signals nothing the encode loop reads, so it can be a permanent new steady state — and `reset()` reopens at the same dimensions by construction, so the host's five-reset budget cannot recover (~3.1 s of frozen stream, then the session ends) where before it would have streamed on with a wrong picture. For a real mode change that trade is clearly right; for a 16-row KWin mismatch it is not, and the proper fix is for the host to classify this error as a PIPELINE rebuild rather than an encoder reset. Filed, not done here. The device-selection half of WP4.5 was written, reviewed and WITHDRAWN — see the handoff doc. Matching the selected render GPU regresses the hybrid Intel-compositor + NVIDIA-present topology this project has a live field report for, because `selected_gpu()` answers NVIDIA whenever `/dev/nvidiactl` exists regardless of where capture actually runs. WP4.5 (dimension half). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 17:56:38 +02:00
enricobuehlerandClaude Opus 5	9fe9cbbf07	perf(encode/vulkan): build the padded RGB frame in the staging memory, not beside it ... The RGB-direct CPU-upload path allocated and zero-filled a whole padded frame on every submit, filled it row by row, then memcpy'd the whole thing into the mapped staging buffer. The zero-fill was entirely dead: the row loop writes every byte of every row, and rows past the source re-copy the last source row. So the frame paid for an allocation, a page-fault storm over fresh pages, a full zero-fill, and two full-frame copies where one would do. Map first, write the padded rows straight into the mapping. Nothing reads back from the destination — the row source is always the caller's buffer, never the staging memory — so writing into (write-combined) host memory costs nothing extra, and `make_host_buffer` allocates HOST_COHERENT, so the writes need no flush before the transfer reads them. Measured on real RDNA3 780M silicon, release build, `submit` alone, 400 frames x 3 rounds: - **1920x1080** (rows padded to 1088): p50 2315 -> **1725 us** (-25%), p99 2819 -> **1972 us** (-30%), and the spread (p99-min) tightens 739 -> 483 us. - **1366x768 -> 1408x768** (BOTH axes padded, so the column tail loop runs): p50 1013 -> **926 us** (-8%), p99 1303 -> **1110 us** (-15%). This is the one case where the new code could have been slower — 4-byte stores straight into write-combined memory — and it is not. - **CONTROL, 1280x720** (64x16-aligned, so the branch is never entered): p50 692 vs 692 us. No delta, which is what makes the two above attributable to this change rather than to anything else on the branch. The branch is reached by any RGB-direct session at a mode that is not 64x16 aligned, whenever capture delivers CPU frames (the default Linux capture path is dmabuf and never enters it). 1080p qualifies, since 1080 aligns to 1088. ⚠ An earlier draft of this message claimed "33 MB at 4K" — that is wrong: 3840 and 2160 are both already aligned, so 4K UHD never enters this branch at all. The large case is an ultrawide like 3440x1440 -> 3456x1440, ~20 MB. Three things this deliberately does NOT do: - The extent guards stay scoped to the `pad` branch. The CSC path deliberately supports a source SMALLER than the encode extent — its shader clamps at sample time — so a guard hoisted above the branch would break it. - Every fallible step stays above the map. An error raised between `map_memory` and `unmap_memory` would strand the mapping for the life of the slot's staging buffer, and the next frame's `map_memory` on it then violates VUID-vkMapMemory-memory-00678. (The filed "two exits above the map leak Vulkan objects" hazard is separately already gone: `47a23bec` moved that unwind into `make_host_buffer`.) - It adds guards rather than removing them: a zero source axis made `sh - 1` underflow, and "cannot fail after the map" has to be true by construction. Three corrections to an earlier draft, all found by review of that draft: - The `dw*dh*4 == need` precondition was a `debug_assert!` placed BELOW the map. That is wrong twice: it made the only check on the slice length vanish from the builds that ship, and a fired assert would have unwound past `unmap_memory` — the exact failure the bullet above says was designed out. It is now a real checked `?` above the map. - `need` was `(iw * ih * 4) as u64`: a u32 multiply widened after the fact, which agreed with the usize slice length only up to ~32768x32768. The old code's `min(need)` was a hard backstop against exactly that and the rewrite dropped it. Now widened before the multiply, matching `read_slot`'s existing discipline. - The extent guard now runs BEFORE the payload-length guard, so the usize `sw * sh * 4` cannot overflow on a garbage frame header. WP6.2(a). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 17:56:22 +02:00
enricobuehlerandClaude Opus 5	e680096c6a	perf(encode): stop re-reading the environment on every submit and poll ... `std::env::var` was on three per-frame paths. Measured on `.173` (Windows, 57 environment variables, 2M iterations): **121.9 ns** per call for the NVENC in-flight cap and **114.9 ns** per call for the ffmpeg poll spin, against **0.9 ns** once memoized. On Linux, 32 ns → 1.5 ns. ⚠ Those numbers deflate the filing, and that is worth recording: the audit ranked this as a hot-path defect, but ~120 ns/frame is ~0.003% of a frame budget. The fix is still right — it is free, and it takes a global environment lock off the encode thread — but nobody should schedule it ahead of anything on the strength of the "hot path" framing. The severity RANKING was also inverted, and the measurement confirms why. The site the audit called worst — `nvenc_cuda`'s backpressure loop condition — costs a default session nothing, because the condition short-circuits on `async_rt.is_some()` and the default session never engages the two-thread retrieve. The one that actually pays every frame is Windows `submit`, which consults `async_inflight_cap()` in BOTH arms of the ring-depth match, sync mode included, where the result is then thrown away. Windows `poll` is the second unconditional one, and the audit ranked it last. Memoized inside each helper rather than latched into a session field. Nothing in the workspace mutates these variables at runtime (enumerated: no `set_var` for either key anywhere in first-party code, and the Windows service's arbitrary-key `host.env` loader runs in the SCM supervisor, which re-execs the host as a child and never opens an encoder itself). A field would instead change WHEN the value is read — and the Windows `cap` composes the env with `input_ring_depth`, which `set_input_ring_depth` may change after open, so freezing that half would reintroduce the in-place-overwrite bug the ring term exists to prevent. Two deliberate behaviour changes ride along on `PUNKTFUNK_FFWIN_POLL_MS`, so "behaviour-preserving" describes the memoization only, not this whole commit: - **A 1000 ms ceiling.** The reachable hazard was never the overflow — that needed `ms >= 1.8e16` — it was a slipped digit: `=100000000` was a 27.7-hour spin of the encode thread. - **`.trim()`, now on all three parsers.** An earlier draft applied the house rule (WP7.8) to one of the three, which left `PUNKTFUNK_NVENC_ASYNC=" 1 "` working while `PUNKTFUNK_NVENC_ASYNC_DEPTH=" 6 "` silently fell back to 4 — and memoization would have frozen that silent fallback for the process lifetime. Reachable: the Windows `host.env` loader trims around `=` before stripping quotes, so `=" 2 "` yields a value with inner spaces. ⚠ Correction to an earlier draft of this message, which asserted that the audit's `saturating_mul` proposal would relocate an overflow panic into release builds. That is FALSE and the code comment now says so: `Duration::from_micros(u64::MAX)` is ~1.8e13 seconds, six orders of magnitude below `Duration`'s ceiling, so `Instant + Duration` neither overflows nor panics (measured, with and without debug assertions). `saturating_mul` is still wrong, for a different reason — it sets a deadline ~584,000 years out on a spin that provably never produces the owed AU, i.e. it wedges the encode thread permanently. A hang, not a panic. WP6.1. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 17:55:59 +02:00
enricobuehler	0044649b19	fix(encode/nvenc): codec-gate the HEVC 4:4:4 union write, and stop it eating the 10-bit arm ... `encodeCodecConfig` is a C union, so the `hevcConfig` writes in the 4:4:4 branch are only meaningful on an HEVC session — on H.264 or AV1 they reinterpret that codec's own config bytes. The branch was gated purely on `chroma_444 && full_chroma_input` with no codec test, and stayed non-UB only because `lib.rs` degrades 4:4:4 for non-HEVC codecs: a two-file invariant with nothing asserting it, on the path BOTH direct-NVENC backends take. The audit filed that much. What it did not note is that the same shape hides a second bug: this is an `if`/`else if`, so a non-HEVC session that arrived with `chroma_444` set took the HEVC branch and skipped the per-codec bit-depth arm entirely — ending up with neither HEVC 4:4:4 (wrong for it) nor its own 10-bit configuration (simply absent). AV1 would have lost `pixelBitDepthMinus8`/`inputPixelBitDepthMinus8` silently. Non-HEVC now falls through to the arm that knows what to do with it, and an unexpected request is logged rather than swallowed. Adds two tests that need no GPU — `apply_low_latency_config` is pure config authoring, so an AV1 session can assert it never receives the HEVC FREXT profile GUID (an INVALID_PARAM at open) and that its own depth still lands, with an HEVC case guarding the good path. ⚠ `NV_ENC_CONFIG` must NOT be `mem::zeroed` in those tests: `frameFieldMode`/`mvPrecision` are C enums whose discriminants start at 1, so all-zero is not a valid value and Rust's zero-init check ABORTS the process (SIGABRT, caught by the Linux gate). They seed it from `Default` the same way `build_config` does before overwriting from the driver preset. Worth knowing before writing any further test against these SDK types. Verified: Linux gate L1-L4 green (39 tests, the two new ones among them) and the full Windows gate on .173 — 7 legs. Note the Windows test leg runs `--features qsv`, so these tests only execute on the Linux leg; the Windows legs prove the change compiles in all five feature combinations.	2026-07-25 16:52:40 +02:00
enricobuehler	b3f8803ea3	fix(encode/qsv): stop advertising intra-refresh the driver silently dropped ... `ir_active` was `cfg.intra_refresh && set.co2.is_some()` — i.e. "we asked for it", not "we got it". Both `Query` and `Init` can return MFX_WRN_INCOMPATIBLE_VIDEO_PARAM, a WARNING the open path deliberately accepts, while dropping the intra-refresh wave on the floor. That lie is not cosmetic. `ir_active` feeds `EncoderCaps::intra_refresh`, so the session advertises gradual refresh to the client; the client then stops asking for the IDRs it would otherwise request on packet loss, and a lost frame gets concealed instead of repaired. The stream degrades exactly when recovery matters. Now confirmed against the driver: a best-effort `GetVideoParam` with a CodingOption2 buffer chained on, read back for `IntRefType`. Deliberately a SEPARATE query rather than a buffer attached to the existing `BufferSizeInKB` call (which is what the audit finding suggested) — that value backs every bitstream allocation, and a runtime that disliked the chained buffer would take it down with the readback. A failure here costs only the verdict and resolves conservatively (trust the request), so the worst case is the previous behaviour. Verified on Intel UHD 750 (.42), which is where the Intel on-glass run originally caught this: with PUNKTFUNK_INTRA_REFRESH=1, H.264 now logs "silently dropped intra-refresh (GetVideoParam reports IntRefType=0)" and advertises it OFF, while H.265 on the same GPU stays ON — it is genuinely active there. Per-codec, so it could never have been decided statically. 8 live QSV tests pass. Gated on .173: clippy -D warnings at nvenc,amf-qsv,qsv (host + pf-encode --all-targets), amf-qsv without qsv, qsv alone, no-features, cargo test --features qsv, rustfmt — all green. qsv.rs is Windows-only so the Linux legs do not compile it. Closes WP3.2(c), the last Phase 3 item that was hardware-blocked.	2026-07-25 16:52:40 +02:00
enricobuehlerandClaude Fable 5	47a23bec12	fix(encode/vulkan): unwind every open/import leak, and serve 24-bpp CPU instead of dying on it ... Phase 5's Linux half (audit WP5.1 + WP5.4), each item shaped by the review that rejected the obvious fix: Dmabuf import unwind (vk_util): every failure after create_image leaked the VkImage, and the dup'd dmabuf fd leaked as a raw i32. The sharp edge is that a SUCCESSFUL vkAllocateMemory transfers fd ownership to Vulkan (vkFreeMemory closes it), so the naive close-on-error is a double close that clobbers whatever unrelated descriptor recycled the number. The dup now lives in an OwnedFd released exactly in the allocate-success arm; every other path drops it once, and bind/view failures free image+memory. PyroWave open unwind: open_inner had ~20 fallible steps that each leaked everything before them (instance, device, pyrowave objects, the whole CSC pipeline). Rather than a parallel teardown guard — whose reviewed hazards were a null-unsafe pyrowave_encoder_destroy and a drifting duplicate of Drop — Self is now constructed right after create_device with every later resource null, and the existing Drop (wait-idle first, pw_enc null-guarded, delete-nullptr and VK_NULL_HANDLE destroys are no-ops) is the single unwind path for error and normal teardown alike. The ensure_cpu_rgb staging twins (create/allocate/bind, both backends) and the RGB-direct make_view pair get the same discipline via a shared make_host_buffer. Observed on hardware: 32 forced import failures, zero fd drift (the new import_failure_leaks_no_fds smoke on RADV). 24-bpp CPU service (WP5.4): pixel_to_vk had no mapping for the packed Rgb/Bgr the PipeWire portal negotiates, so a session committed to a path the backend could not serve and died at its first frame. The filed open-gate was rejected as a half-mirror — the dmabuf axis is keyed by fourcc at submit, unknowable at open — so instead the CPU axis is SERVED: a 3-to-4 expand at the staging upload (normalize_cpu_rgb, the CPU twin of WP1.4's swscale expand), order-preserving for the CSC samplers and BGRA-forced for the RGB-direct encode source, whose session pictureFormat is B8G8R8A8 — the on-glass run caught R-first sources violating VUID-vkCmdEncodeVideoKHR-pEncodeInfo-08207, a mismatch that predates this change for plain Rgbx CPU sources. The dmabuf axis feeds pf-zerocopy's raw-dmabuf degrade latch (3efbe416) from both Vulkan import caches — deterministic refusals flip capture to CPU delivery, which now serves every format capture produces; transient OOM and native-NV12 sessions are excluded. RECORDING-state hygiene: the fallible recording prefix (cursor prep, import, staging) now resets the command buffer on error instead of leaving it RECORDING for the next begin to trip VUID-vkBeginCommandBuffer-commandBuffer-00049; PyroWave's submit-level blanket reset is replaced by the same scoped shape, closing its fence-timeout hole where a reset hit a PENDING buffer (VUID-vkResetCommandBuffer-commandBuffer-00045). Verified: docker linux/amd64 4-leg gate green; RADV 780M on-glass under the validation layers at 1920x1080 — all 10 smokes pass (including the new 24-bpp CSC + RGB-direct legs and both channel orders), decoded colour truth checked with ffmpeg, and the only remaining validation messages are the two documented VALVE-extension layer gaps plus a pre-existing pyrowave shader/feature mismatch now filed in the planning doc. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 16:51:27 +02:00
enricobuehlerandClaude Fable 5	e0e845b7df	fix(encode/pyrowave): pin the NT-handle import contract to consume-on-success-only ... import_plane closed the shared NT handle on every pyrowave_image_create failure, believing pyrowave only consumes it on success. The vendored truth was messier: Granite's allocator closed by-reference handles UNCONDITIONALLY after the first vkAllocateMemory — success AND failure — while failures before the allocator (validation, vkCreateImage, no memory type) left the handle open, and both classes surface as the same error code. So the call site could not know whether to close, and an allocate-stage failure double-closed a possibly-recycled handle value (audit WP5.3). The filed fix (DuplicateHandle + close the original unconditionally) traded the double close for a guaranteed leak on every pre-allocate failure and left the ambiguity in place. Patch 0006 fixes the callee instead: the allocator never closes a caller's handle, and pyrowave_image_create consumes it exactly at its success return — which is what pyrowave.h ("take ownership and close the HANDLE on import") documents, and what Granite's semaphore import already did, so import_fence was correct as written and the two paths now share one contract. The close-on-failure in import_plane is thereby correct on EVERY path, including a vkBindImageMemory failure after a successful allocate. Bonus fix recorded in the patch: the allocator's block-recycling retry loop used to re-run vkAllocateMemory with import_info still pointing at the just-closed handle. Both-platform gates green; pyrowave_win_smoke (.173, 34/34) re-validates the live import path against the rebuilt vendored C++. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 16:51:00 +02:00
enricobuehlerandClaude Fable 5	d6d4408c8e	fix(encode/nvenc): teardown that tells wedged from routine, and a session budget that can heal ... Three Windows NVENC teardown/accounting defects (audit WP5.2, marked BLOCKING — the obvious fixes were reviewed and rejected before this): Event-handle leak: init_session pushed each completion event to self.events only AFTER nvEncRegisterAsyncEvent, so a failed registration leaked the Win32 handle. Push first — the init-failure path already runs teardown, which closes everything in the list (unregistering the one never-registered event is a harmless error return). Wedged drain: teardown drains the retrieve thread's backlog, and each queued job could burn its full 5 s completion wait — cap x 5 s on the encode thread, paid again on every rebuild of the stall-recovery ladder. The rejected fix (a shutdown flag) abandoned the backlog on EVERY teardown, turning the routine drain into destroy-while-encoding. Instead the wedge evidence stays where it lives: after one full-budget timeout in the retrieve loop, later jobs wait a 250 ms slice; a success resets the latch. Routine teardown is byte-identical to before — nothing is ever abandoned — and a first timeout is already encoder-fatal, so short slices behind an established wedge change only how long teardown blocks. Session-unit accounting: LIVE_SESSION_UNITS was refunded even when destroy_encoder FAILED, drifting the budget low and over-admitting parallel displays. The rejected fix (never refund on failure) let one transient wedge episode poison admission until a host restart. Now the refund follows PROOF: destroy succeeded, or its status says the driver holds no session (device gone/TDR). Ambiguous failures park the handle — units still charged, fail-closed, pinning the D3D11 device the driver session references — and init_session retries the destroy while zero sessions are live, under a gate that serializes every session open against the reap so a recycled handle address can never alias a live session. The charge lasts exactly as long as the driver keeps refusing the destroy, which is the definition of still-leaked. Admission stays a lock-free atomic load. Both-platform gates green (docker linux/amd64 4 legs; .173 all 7 legs). The retry-destroy-on-a-failed-handle assumption is documented at the reap: the SDK defines no retry semantics either way. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 16:50:46 +02:00
enricobuehler	3efbe4164e	fix(capture): capture CPU frames once the encoder proves it can't import dmabufs ... A dmabuf import the GPU driver refuses is refused identically on every retry, but the only recovery above it was the encode-stall ladder: five in-place encoder rebuilds, then the video session ends. So a host whose driver will not take what its compositor allocates lost every session on its first frame, and every reconnect repeated it — while the very same host streamed fine with `PUNKTFUNK_ZEROCOPY=0`. The software knew how to run that machine and never chose to. Latch it, exactly as the sibling CUDA-import path already does after repeated worker deaths: three consecutive import failures with no frame in between disable the raw-dmabuf passthrough for the host process, and capture negotiates CPU frames from the next session on. Three sits below the encoder's rebuild budget, so the latch is set before the session it doomed ends — one bad session, then a working (if slower) host, with a log line saying which and why instead of an operator having to find an environment variable. Only the two stages that ARE the import are counted — the buffersrc push of the DRM-PRIME descriptor and the buffersink pull where `hwmap` maps it into a VA surface. `avcodec_send_frame` is deliberately left out: that one is the encoder stalling, which the in-place rebuild exists to recover, and taking zero-copy away permanently over a transient fault would be a bad trade. The latch lives in pf-zerocopy because it is the leaf both sides can see — the capture→encode edge is one-way by design, so pf-capture cannot ask pf-encode anything.	2026-07-25 15:13:11 +02:00
enricobuehler	f32207a6ba	fix(encode/vaapi): tell libva the dmabuf's real size, not zero ... The zero-copy DRM-PRIME descriptor declared `objects[0].size = 0`, on the belief that ffmpeg would work the real size out. It does not: both of its import paths pass the value straight through to libva — `prime_desc.objects[i].size` on the PRIME_2 path, `buffer_desc.data_size` on the legacy fallback it tries next — so every VA driver we have ever handed a dmabuf to was told the backing object was empty and left to derive the size itself. The drivers this path has run on (radeonsi, modern Intel iHD) derive it correctly, which is why nobody noticed. A Gen9 Intel host does not get that far: `vaCreateSurfaces` answers VA_STATUS_ERROR_ALLOCATION_FAILED on the first frame and every frame after it, `av_buffersink_get_frame` returns EIO, and five in-place encoder rebuilds later the video session is over. That host cannot stream at all with zero-copy on. `lseek(SEEK_END)` is the standard dma-buf size query and the same one this tree's Vulkan bridge already performs on these very fds. A kernel that refuses it leaves the old 0 rather than costing a frame that might still have encoded. Whether this alone fixes that host is unconfirmed — the descriptor was wrong either way, and it is the first thing the driver reads.	2026-07-25 15:13:11 +02:00
enricobuehler	7c82a72ecd	fix(zerocopy): find the NVIDIA render node instead of assuming renderD128 ... The EGL importer — the head of the CUDA/NVENC zero-copy path — opened `/dev/dri/renderD128` and hoped. On a single-GPU host that is the NVIDIA node and it always worked. On a hybrid laptop the iGPU is bound first, so renderD128 is Intel: we built a GBM device on Mesa, asked it for a pbuffer-capable OpenGL config, got none (Mesa's GBM platform advertises only window-capable ones — gbm_surface is the point of that platform there), and reported zerocopy worker init failed: no EGL config for OpenGL on a machine whose NVIDIA EGL stack was demonstrably fine, naming neither the device nor the reason. `PUNKTFUNK_RENDER_NODE` was no escape either: this path never read it. Pick the node by what it is — the first `/dev/dri/renderD*` whose sysfs PCI vendor is 0x10de, the same identification the crate's Vulkan bridge already uses for its physical device. A local scan rather than a `pf_gpu` dependency, because this crate is a leaf whose worker is its own process, and `pf_gpu::linux_render_node` answers a different question anyway: it follows the operator's GPU *preference*, which may legitimately name the iGPU. What is needed here is not which GPU to use but where CUDA is. `PUNKTFUNK_ZEROCOPY_RENDER_NODE` overrides, and no NVIDIA node found keeps the historical guess — sysfs may just not be mounted, and the CUDA context is what properly fails on a host with no NVIDIA at all. Then stop the config query being able to fail this way: retry without the surface-type constraint, which is honest because we never create an EGLSurface — `eglMakeCurrent` runs surfaceless. And name the node in every error and in the ready line, so the next hybrid host diagnoses itself.	2026-07-25 15:13:11 +02:00
enricobuehler	6571a26aa9	fix(scripting): park the idle runner instead of pinning a core ... `punktfunk-scripting` with nothing to run pinned a full CPU core indefinitely — in exactly the state its own systemd unit documents as inert ("the runner does nothing until you add scripts or install plugins"). A field report on a 7.7 GB laptop had it at 99.9% CPU for two hours straight, `strace` showing a bare `clock_gettime` loop and no other syscall at all, which starved the compositor badly enough to blank the physical display. Nothing in the runner was looping. `Effect.runFork` registers nothing with the event loop — effect's keep-alive timer lives in `Runtime.makeRunMain`, which runner-cli deliberately doesn't use because its shutdown is the bespoke two-signal one — and a bun process whose only pending work is an unresolved promise busy-spins rather than blocking. With units running there is normally a socket or timer to park on; with none there is nothing at all, so the no-op state was the one state that span. Hold one idle handle for the runner's lifetime and drop it when the unit tree ends on its own. Measured on the packaged bun (1.3.14), three seconds idle with empty scripts/plugins dirs: 3098 ms of CPU before, 280 ms after (bun's startup, then nothing). The regression is a property of the process rather than of any function in it, so the test spawns the real CLI and reads the child's CPU time, asserting it also logged and stayed alive — a crashed runner burns no CPU either and must not pass.	2026-07-25 15:13:11 +02:00
enricobuehler	8578141d43	fix(encode/vulkan): AV1 at unaligned modes was violating two VUIDs on every frame ... Found by running the smokes at 1920x1080 under the validation layers while chasing the three items left over from WP4.2. AV1 forbids the encode source's `codedExtent` differing from the sequence header without `FRAME_SIZE_OVERRIDE` (VUID-vkCmdEncodeVideoKHR-flags-10324), or from the reference slots without `MOTION_VECTOR_SCALING` (`-10325`). RADV PHOENIX advertises NEITHER — and RGB-direct is the default on EFC hosts with true-extent the default at unaligned modes, so plain 1080p AV1 was tripping both on every frame: source 1920x1080 against an app-aligned 1920x1088 header and DPB. Measured 16 violations per 8-frame run; the CSC path had none. The fix is to make all three agree at the RENDER size rather than the aligned one — an unpadded coded size is valid on this hardware, so the coded frame simply IS the visible frame: - the AV1 sequence header follows the render size when true-extent is active (joining native NV12, which already authors true-size headers for the same reason); - the DPB setup and reference slots carry `src_extent` instead of the aligned `ext2d`. `src_extent` already collapses to `ext2d` whenever true-extent is off, so every other configuration is untouched; - `render_and_frame_size_different` now compares render against the DECLARED source extent instead of the aligned size, or true-extent would have claimed a mismatch that no longer exists. Fixing only the header is not enough and is actively misleading: it clears -10324 and immediately exposes -10325, because the mismatch has moved to the reference slots rather than gone. Both had to move together. This keeps the EFC fast path. Two alternatives were implemented, measured and rejected on the way here: falling back to the compute CSC costs the zero-copy the B2 work existed to deliver, and routing to the padded-copy staging trades these two VUIDs for VUID-VkImageCreateInfo-pNext-06811 — `pad_img`'s extra TRANSFER_SRC usage is not in the profile-advertised set, measured 8x per session on HEVC-padded too, so that is a pre-existing defect of the padded path and not somewhere to route a default session. HEVC is deliberately untouched: it has no equivalent constraint (its crop rides the conformance window), it measures zero violations, and its aligned-SPS path is the validated one. On RADV PHOENIX (780M, Mesa 26.0.4) the AV1 stream now decodes as coded 1920x1080 / render 1920x1080 — genuinely unpadded, where before the alignment rows were encoded and cropped back out. The CSC path still reports coded 1920x1088 / render 1920x1080, which is correct for it. All four `vulkan_smoke*` pass at 256x256 and 1920x1080. Two validation errors remain on the RGB-direct path and are NOT ours, now with evidence rather than assumption: `VUID-VkImageViewCreateInfo-image-08336` uses the PROFILE-BLIND format query, so it cannot see that RGB conversion legalises BGRA as an encode source — the profile-aware query used by -06811 accepts the very same image; and `VUID-VkQueryPoolCreateInfo-pNext-pNext` rejects `VkVideoEncodeProfileRgbConversionInfoVALVE`, which the VALVE extension REQUIRES for profile identity, and the layer diagnoses itself as "a struct from an extension added to a later version of the Vulkan header". Verified: canonical Linux gate (docker linux/amd64) L1-L4 green; on-glass on RADV PHOENIX under `VK_LOADER_LAYERS_ENABLE='*validation*'`, with the bitstreams read back through libdav1d/trace_headers.	2026-07-25 15:12:08 +02:00
enricobuehler	87863c12a9	fix(encode/windows): clear the Windows Phase 4 backlog — NVENC sticky state, QSV HDR + ABR ... Four items, gated on the RTX box (.173, all 7 Windows legs) and the Linux docker gate, with the QSV HDR one proven by an A/B on real Intel silicon (.42, UHD 750). WP4.1 — Windows NVENC sticky state. Both halves were the same mistake: a single field doing duty as both "what the session negotiated" and "what this session can actually do", so the first downgrade destroyed the negotiation. - `query_caps` clears `self.hdr` on a GPU without 10-bit encode, but `submit` re-derives the requested HDR state from every frame's pixel format and compared it against that cleared value. On such a GPU a P010 capturer therefore reported "HDR changed" on EVERY FRAME and tore down and rebuilt the whole encode session each time. The trigger now compares against `hdr_requested`, and the downgrade is latched in `hdr_unsupported` so it is remembered (and warned once) instead of rediscovered per init. - One subsampled-YUV frame cleared `chroma_444` permanently, so 4:4:4 never returned when the capturer went back to RGB. The negotiation now lives in `chroma_444_requested` and the effective value is recomputed at every init; the per-session downgrade still happens and is still reported honestly through `caps()`, it just is not destructive any more. WP4.3(a) — QSV HDR mastering luminance was divided by 10,000. The old comment justified it as "VPL wants whole cd/m²", which is true of the VIDEO-PROCESSING unit but not the encode path: the runtime passes the value straight into the ITU-T H.265 Annex D mastering-display SEI, whose unit is 0.0001 cd/m². Verified end to end on Intel UHD 750 by dumping the bitstream and reading SEI 137 with trace_headers, before and after: before: max_display_mastering_luminance = 1000 (0.1 nits) after: max_display_mastering_luminance = 10000000 (1000 nits) with `min` (500 = 0.05 nits) and both content-light-level fields unchanged. That asymmetry — a correct min beside a 10,000x-low max — was the original tell. WP4.3(b) — `reconfigure_bitrate` never re-read `BufferSizeInKB`, so an ABR step-up could hand the runtime an AU buffer sized for the old, lower bitrate. Fixed in both places it was broken: re-read the driver's answer via `GetVideoParam` after the `Reset` (mirroring `init_encode`), AND stop `take_bs` recycling pooled buffers without checking their capacity — the pool would otherwise keep serving short buffers even once `bs_bytes` was correct. WP7.8 — the `PUNKTFUNK_QSV_FFMPEG` half, finally landable now that a Windows gate exists (it sits behind `#[cfg(feature = "qsv")]`, so nothing in a Linux-only matrix compiles it — it was deliberately held back for exactly that reason). Trimmed like its siblings, and kept case-insensitive: the knob already accepted `TRUE`, and the bare house `matches!` would have silently dropped that spelling. Phase 4 of the audit is now complete, and WP7.8 with it. Verified: Windows gate on .173 — clippy -D warnings at nvenc,amf-qsv,qsv (host + pf-encode --all-targets), amf-qsv without qsv, qsv alone, no-features, `cargo test --features qsv` (34 passed), rustfmt. Linux docker gate L1-L4 green. On-glass: the QSV A/B above on .42. Owed: NVENC sticky-state on-glass on .173 (needs a live 10-bit-capable capture toggle).	2026-07-25 14:37:49 +02:00
enricobuehler	bab309017d	fix(encode/vulkan): five mode-specific correctness bugs, three caught on real silicon ... WP4.2 of the pf-encode audit, validated on RADV PHOENIX (780M, Mesa 26.0.4) under the Vulkan validation layers rather than by inspection alone. Three of the five reproduce with the driver naming the violation; one turned out milder than filed and is recorded as such. 1. `ensure_cpu_rgb` cached the staging image on FORMAT ONLY while sizing it to the SOURCE frame, and the copy uses the CURRENT frame's extent — so a same-format source-size increase copied past the allocation. Now keyed on (format, width, height). This is the memory-safety one: on hardware it was 8 x VUID-vkCmdCopyBufferToImage-imageSubresource-07971 ("extent.width (512) exceeds imageSubresource width extent (128)") and `submit` returned Ok every single time, so nothing upstream could notice. Zero after the fix. Note the trigger for anyone re-testing: the image is cached PER RING SLOT, so the ring must wrap before a slot sees a larger frame — two differently-sized submits in a row land on different slots and look fine. 2. The RGB-direct CPU padding loop only ever grows a source into the aligned extent; a source LARGER than the encode extent panicked on the row `copy_from_slice`. Now refused by name, matching what the DMA-BUF arms already do, so a bad frame takes the encoder-rebuild path instead of unwinding out of the encode thread with an index message. 3. AV1 wrote `render_width/height_minus_1` but never set `render_and_frame_size_different`, and AV1 ignores the render size unless that flag says it differs — so every mode needing 64x16 alignment presented the padding. libdav1d on the encoded stream now reports `size 1920x1088 ... render 1920x1080`; before, the flag being unset meant render defaulted to the coded 1088, i.e. 8 rows of duplicated edge pixels shipped to the client. 4. `read_slot` read the PERF timestamp pool whenever the pool merely EXISTED, but the padded-RGB path's CPU-upload arm records its own command buffer and writes no timestamps — reading an unreset query with WAIT is undefined. Now gated on a per-slot `ts_written`, because "a pool exists" was being used as proof of "the pool was written". SEVERITY CORRECTION vs the audit: this is not a hang in practice. It needs PUNKTFUNK_PERF *and* RGB-direct *and* the non-default PUNKTFUNK_VULKAN_RGB_TRUE_EXTENT=0 *and* an unaligned mode *and* CPU capture, and RADV then fails the read rather than blocking. Another driver may block, hence the fix. 5. `reset()` re-arms `first_frame`, which was also what decided whether begin-video-coding declares the rate-control state. But a reset does not rebuild the session, so the CBR installed earlier is still current when the next frame opens its coding scope: the declaration was omitted exactly when it was required. Split into `rc_installed`, which survives reset. On hardware this was VUID-vkCmdBeginVideoCodingKHR-pBeginInfo-08253 ("no VkVideoEncodeRateControlInfoKHR ... but the currently set mode is CBR"); zero after. Also fixes two pre-existing AV1 spec violations that were firing on EVERY frame of a shipped path and are not in the audit at all — found only because the validation layers were on, and confirmed untouched by this branch before being attributed as pre-existing: `constantQIndex` must be 0 unless rate control is DISABLED (VUID-...-10320; this session is always CBR, so the driver owns Q), and `pStdPictureInfo->pSegmentation` must be NULL (VUID-...-10350; it pointed at a zeroed struct, and leaving it unset means the same "segmentation disabled" while being spec-correct). Items 1 and 5 keep their reproductions as `#[ignore]`d hardware tests, documented as meaningful only under `VK_LOADER_LAYERS_ENABLE='*validation*'` since the violations are invisible to the API's return values. STILL OPEN, filed not fixed (three more pre-existing validation errors the cleanup exposed): VUID-VkQueryPoolCreateInfo-pNext-pNext on the AV1 and RGB paths, and 2 x VUID-VkImageViewCreateInfo-image-08336 (the RGB-direct encode-src view's format features lack VIDEO_ENCODE_INPUT) — the latter may be a validation-layer gap around the VALVE extension rather than our bug, and wants real analysis rather than a quick patch. Verified: canonical Linux gate (docker linux/amd64) fmt + clippy --all-targets at default and at nvenc,vulkan-encode,pyrowave + both test legs; and on RADV PHOENIX all four `vulkan_smoke*` tests pass at 256x256 and at 1920x1080 with zero validation errors on the paths touched here.	2026-07-25 14:37:49 +02:00
enricobuehlerandClaude Opus 5	e5e68f1d24	feat(presenter): DRM card selection + a usable kmsdrm swapchain error ... Both come straight out of the first compositor-less bring-up (P3), on a two-GPU box: PUNKTFUNK_DRM_CARD=<n> pins SDL's KMSDRM device index. SDL enumerates /dev/dri/card* and takes the first it can open, which is regularly the wrong one: it chose the card a live compositor already held DRM master on and died at swapchain creation, while the idle card with the connected display sat unused. Kept an explicit operator choice rather than auto-detection — deciding "is this card already mastered" needs the very ioctl that taking master IS, so any in-process guess would be fragile. The swapchain error now carries what to actually check. "vkCreateSwapchainKHR: Initialization of an object has failed" is useless to someone bringing up a kiosk; on the kmsdrm backend it now names the pinned card and lists the three real causes in order (no connected connector / another DRM master / NVIDIA). Empty on every other backend, where it would be noise. The NVIDIA note is measured, not guessed: on NVIDIA proprietary + kmsdrm, Vulkan enumerates the GPU AND the display (VK_KHR_display reports the connected HDMI connector) and still fails — as root, with nvidia_drm.modeset=Y, on a card no compositor was using. Not permissions, not DRM master; their direct-display path wants the display leased via vkAcquireDrmDisplayEXT and SDL's kmsdrm surface path does not do that. Plan: punktfunk-planning design/embedded-arm64-client.md §P3 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 14:32:45 +02:00
enricobuehlerandClaude Opus 5	aff169e131	build(flatpak): make the manifest architecture-generic ... Two things were x86-specific, both now expressed properly instead of hardcoded: * PKG_CONFIG_PATH carries the runtime's multiarch directory. flatpak-builder does NOT shell-expand `env` values, so ${FLATPAK_ARCH} would be taken literally — a build-options.arch override supplies the aarch64 string and inherits the rest. * The prebuilt Skia archive is per-target and pinned by sha256. Two `type: file` sources discriminated by only-arches now share one dest-filename, so SKIA_BINARIES_URL stays a single literal path. Upstream publishes the aarch64 archive under the same skia commit hash and the same resolved-feature key, so the two stay in lockstep on a skia-safe bump. build-flatpak.sh gains ARCH (default: this machine's), passes --arch to both flatpak-builder and build-bundle, and arch-suffixes the bundle name so an x86_64 and an aarch64 build can coexist in dist/ instead of the second silently overwriting the first. CI composes its own published filename, so nothing downstream changes. The aarch64 Skia sha256 was verified by downloading the published archive, not taken from the API. No aarch64 flatpak has been built — flatpak-builder builds in a sandbox for the target arch, which needs an arm64 machine. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 14:32:45 +02:00
enricobuehlerandClaude Opus 5	4dc078692d	build(arch): build the client for aarch64 (Arch Linux ARM) ... arch=('x86_64' 'aarch64'), and on aarch64 `pkgname` drops punktfunk-host so makepkg never enters the host's build or package path; build() takes a client-only cargo invocation without the NVENC/Vulkan-encode features. Dropping the host from pkgname rather than giving package_punktfunk-host a per-package arch is what makes the skip unambiguous, and it mirrors how PF_WITH_WEB already extends that array. The host stays x86-only because its encode stack (NVENC/QSV/AMF) is. Verified by sourcing the PKGBUILD under both CARCH values: x86_64 yields `punktfunk-host punktfunk-client`, aarch64 yields `punktfunk-client`. NOT verified by a real build — there is no official arm64 Arch container, and the README says so rather than implying it is tested. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 14:32:45 +02:00
enricobuehlerandClaude Opus 5	1c76b8c7b4	build(rpm): let the spec build a client-only aarch64 RPM ... The blocker was never ExclusiveArch — it was that %build builds host + tray + client together and %install lays down the host unconditionally, with no way to express "client only". `%bcond_without host` (default ON, so an x86_64 build is unchanged) now gates the host binary, the tray, the headless-session data, the firewalld services, the main %post and the bare %files section. Omitting %files for the MAIN package is the load-bearing part: it is what stops rpm emitting an empty `punktfunk` alongside punktfunk-client. build-rpm.sh exposes it as PF_WITHOUT_HOST=1 and skips the libcuda stub regeneration and the libcuda leak check, neither of which means anything without the host. Verified two ways. `rpmspec -P` shows the default expansion still carrying 3 host install lines, the tray build and one bare %files, while --without host carries none of those and one %files client. And a real rpmbuild in a native aarch64 Fedora 43 container produced punktfunk-client-*.aarch64.rpm with correct aarch64 sonames (libc.so.6(GLIBC_2.17), libSDL3.so.0, libavcodec.so.61) and no main package. Not a cross-compile: %build runs cargo for the build machine's arch, so this wants an arm64 builder. No CI leg yet — deliberate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 14:32:45 +02:00
enricobuehlerandClaude Opus 5	cac82d13df	ci: check the client for aarch64 on every push ... Adds a `rust-arm64` job: clippy -D warnings for the client crates at --target aarch64-unknown-linux-gnu, plus a --no-default-features session build so the minimal embedded configuration keeps compiling in its own right rather than only as a subset of the default one. Runs in the cross image on the ordinary amd64 runner; client crates are listed explicitly because --workspace would drag in the x86-only host encode stack. This is a regression guard, not an artifact leg (deb.yml ships those). c_char signedness cuts both ways and neither direction is visible from an x86-only CI: hardcoding i8 fails to COMPILE on ARM, while casting to u8 fails the LINT on ARM. Two such defects were already found this way. Also documents the arm64 client .deb recipe in packaging/debian/README.md. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 14:32:45 +02:00
enricobuehlerandClaude Opus 5	ab3884c763	fix(core/abi): cast identity PEM pointers with .cast(), not as *mut u8 ... `c_char` is i8 on x86_64 and u8 on aarch64, so `cert_pem_out as *mut u8` is a REQUIRED conversion on one target and a no-op on the other — where clippy::unnecessary_cast then denies it. `.cast::<u8>()` is correct and lint-clean on both. Caught by the new aarch64 clippy leg on its first run. A sweep of the remaining `as *mut u8` / `as *const u8` sites in the client crates found no other c_char-derived casts; the rest convert from c_void or u16. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 14:32:45 +02:00
enricobuehlerandClaude Opus 5	000f8b85b0	build(ci): cross-compile and publish an aarch64 Linux client ... Adds punktfunk-rust-ci-arm64cross (the rust-ci toolchain + an Ubuntu ports arm64 multiarch sysroot) and a deb.yml job that cross-builds the client package on the ordinary amd64 runner — no arm64 runner in the fleet and none needed. Client only: the Linux host encodes with NVENC/QSV/AMF, all x86. The apt registry keys pool entries by the .deb's own arch, so an arm64 box picks the package up with no client-side configuration. Three things this had to get right, each of which cost a failed build: * rustup target add must run against the toolchain rust-toolchain.toml PINS, not the image's default `stable` — otherwise the pinned toolchain has no aarch64 std and the build dies ~230 crates in on "can't find crate for core". Copying the pin file in also pre-downloads the toolchain every CI job currently re-fetches on first use. * ffmpeg-sys-next compiles a probe it intends to RUN, so it forces .target(HOST) while still passing the TARGET's include paths; the arm64 dir then shadows the host's own libc headers and the x86 compiler dies in bits/math-vector.h on NEON/SVE types. Prepending the host dir does NOT help — GCC drops a -I that duplicates a system directory, keeping its original later position — so ci/pf-host-cc strips target include dirs from host compiles instead. * the job hard-fails on a non-AArch64 session binary, rather than shipping an amd64 payload under an arm64 package name. skia needs no special handling: the aarch64-linux-gnu textlayout+vulkan prebuilt resolves, so arm64 ships the FULL client, OSD included — unlike Windows ARM64, which still builds --no-default-features. The cross image builds in its own docker.yml job (needs: build-push) since it is FROM punktfunk-rust-ci:latest and must not race the entry that publishes that base. rpm/Arch/Flatpak stay x86_64 for now — their builders have no arm64 sysroot, which is its own piece of work. Plan: punktfunk-planning design/embedded-arm64-client.md Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 14:32:45 +02:00
enricobuehlerandClaude Opus 5	915fc3ef9e	feat(session): headless --pair, so a box with only SSH can enrol ... `punktfunk-session --pair <PIN> --connect host[:port]` runs the SPAKE2 ceremony with no window and no toolkit, prints the same `paired <addr>:<port> fp=<hex>` line as `punktfunk-client --pair`, and exits. Until now the PIN ceremony lived only in the GTK shell or the Skia console, so enrolling an embedded/kiosk client meant installing a desktop on it — or copying the identity store by hand. Dispatches above every graphics call (the machine may have no display) and is in the `--no-default-features` build: enrolling must never be the reason a minimal image pulls in Skia. `--name` defaults to the hostname instead of the desktop path's hardcoded "Steam Deck". `forget_placeholder` and `device_name` move into pf_client_core::trust so the two binaries share one implementation rather than the session re-deriving them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 14:32:45 +02:00
enricobuehlerandClaude Opus 5	b7cea71bbd	fix(presenter): type the Vulkan extension pointers as c_char, not i8 ... `char` is signed on x86_64 but UNSIGNED on aarch64, so the hardcoded `Vec<*const i8>` compiles on every desktop target and then fails to match ash's `&[*const c_char]` when cross-compiling the client for ARM. Found by the aarch64 cross-build spike (punktfunk-planning: embedded-arm64-client.md) — the only portability defect in the client stack; nothing else in the client crates assumes an architecture. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 14:32:45 +02:00
enricobuehler	07f8e37c85	fix(encode/sw): refuse a mode openh264 cannot encode at open, not at every submit ... openh264 tops out at level 5.2 — 3840x2160 landscape or 2160x3840 portrait — and enforces that ceiling inside `reinit`, which the crate calls on the FIRST ENCODE rather than at encoder construction. So an oversized mode built a perfectly healthy-looking encoder and then failed every single submit: the session connects, negotiates, and never delivers a frame, with the real reason buried in a per-frame error rather than at the open. `validate_dimensions` does not cover this. It is keyed on the codec, and H.264 legitimately reaches 4096 on every hardware backend — this ceiling belongs to the software backend alone, which is exactly the path a GPU-less host falls back to. Rejects at open instead, mirroring the rule from the openh264 version we actually ship (0.9.3) rather than from its docs — including the orientation-aware shape, since a naive per-axis `w <= 3840 && h <= 2160` would wrongly refuse a legal 2160x3840 portrait session. Three tests: the accepted modes in both orientations, the modes `validate_dimensions` lets through but openh264 cannot serve, and that `open` itself refuses rather than deferring to submit. They cost nothing to run — the guard fires before openh264 is initialised at all. Verified with the canonical Linux gate (docker linux/amd64): fmt, clippy --all-targets at default and at nvenc,vulkan-encode,pyrowave, and the pf-encode test leg (37 passed).	2026-07-25 13:01:01 +02:00
enricobuehler	ed525c4c73	fix(encode/vulkan): PUNKTFUNK_VULKAN_RGB_DIRECT read "0 " as force-ON ... The knob tested `v == "0"` for the disable case and treated everything else that was set as a force-enable. So a trailing space — the kind a `.env` line or a shell script leaves behind — made `PUNKTFUNK_VULKAN_RGB_DIRECT=0 ` mean the exact opposite of what the operator wrote, forcing the RGB-direct encode source on. On a cursor-blend session that is not a subtle difference: the EFC front-end cannot blend, so the pointer disappears from the stream. An empty value and any typo did the same thing. Now parsed like every sibling knob in the crate — `matches!(v.trim(), "1"|"true"|"yes"|"on")` and the matching false spellings — so unrecognised input falls back to the default instead of being read as a force-on. `=0` and `=1` keep working exactly as documented. Splits the parse into a pure function so the accepted spellings are covered by tests. That matters more than it looks: the env-var read itself is untestable in a parallel test binary (the process environment is shared), which is precisely why this knob's behaviour had no coverage and the inverted case survived. Verified with the canonical Linux gate (docker linux/amd64): fmt, clippy --all-targets at default and at nvenc,vulkan-encode,pyrowave, and the pf-encode test leg (37 passed).	2026-07-25 13:00:50 +02:00
enricobuehler	3fac1a6da1	fix(encode/linux): stop the capability probes racing each other's libav log level ... Every capability probe drops libav's log level to AV_LOG_FATAL around an encoder open it expects to fail, then restores what was there before. That level is one process-global int and the probes genuinely overlap — they are reached both from `/serverinfo` and from session bring-up. Two overlapping save/restore pairs interleave as get(INFO) → get(FATAL) → set(INFO) → set(FATAL), and the process is then pinned at AV_LOG_FATAL permanently: every later libav diagnostic silently dropped, including the ones you want when a stream fails to open later on. Replaces the four hand-rolled save/restore pairs with one RAII guard over a single shared mutex. The audit filed two sites; there are four — the NVENC 4:4:4 and 10-bit probes in `linux/mod.rs` and both VAAPI probes, which is why the lock has to be shared across the two modules rather than kept local to either. Being RAII also closes a smaller hole the old shape had: the restore was a statement after the open, so any early return added to those functions later would have leaked the quiet level. Now it cannot. The guard is poison-tolerant — a probe that panicked mid-window has already restored the level through `Drop`, so refusing the lock forever afterwards would be strictly worse than proceeding. It is not re-entrant, which is safe here because no probe body reaches another probe (they only call encoder-open helpers); that invariant is written down at the type. Serialising the probes costs nothing measurable: they are process-once behind their caches and each already pays for a real encoder open. Verified with the canonical Linux gate (docker linux/amd64): fmt, clippy --all-targets at default and at nvenc,vulkan-encode,pyrowave, and the pf-encode test leg (37 passed).	2026-07-25 13:00:39 +02:00
enricobuehler	a17413327b	fix(encode/vulkan): give the vendored Vulkan ABI the layout guard it never had ... `vk_av1_encode.rs` and `vk_valve_rgb.rs` are hand-copied `#[repr(C)]` structs handed to the driver through raw `p_next` chains. Nothing in the type system relates them to the C definitions any more, so an edit that inserts, drops, widens or re-pads a field is not a compile error — it is the driver reading our bytes at the wrong offsets, silently. The sibling vendored ABI in `amf.rs` has carried assertions for exactly this reason; these two had none at all. Adds size, alignment and per-field offset assertions for all 19 vendored structs. They are `const` rather than `#[cfg(test)]` (the shape `amf.rs` uses) so they hold in every build including the shipped one, and on any target the modules compile for. Assertions cannot catch a swap of two same-typed fields — the offsets are unchanged — so the field order was diffed field-by-field against the authoritative headers while writing them: `vulkan_core.h` and `vk_video/vulkan_video_codec_av1std_encode.h` from Vulkan-Headers `main` as of 2026-07-25. That diff covered every struct, every `ST_*` structure-type value, every flag bit and both enum groups, and found no drift — the vendored copies are faithful. The one remaining hand-copied table the compiler still cannot see is the bitfield member order inside the three `*Flags` words, where a wrong index means the driver reads `use_superres` where we meant `render_and_frame_size_different`. Three tests pin those to the header by listing the members in C declaration order and asserting the Nth setter writes bit N, with the trailing `reserved` field checked too — a dropped member shifts `reserved` down and fails. Verified with the canonical Linux gate (docker linux/amd64): fmt, clippy `--all-targets` default and `nvenc,vulkan-encode,pyrowave`, and both test legs.	2026-07-25 12:46:24 +02:00
enricobuehler	6c2183ceec	fix(nvenc): stop telling operators to reboot when the driver version is fine ... `NV_ENC_ERR_INVALID_VERSION` is how the driver reports two opposite failures, and we only ever explained one of them. The message told the operator to update the NVIDIA driver or reboot — correct for a genuine header/kernel-module skew, and actively misleading for the field case behind it: a host that streams once per boot and then fails every later session at the caps probe, until the *process* restarts. A version skew is static; it cannot come and go inside one process, so that advice cost the reporter a reboot per stream. Split the two on the only fact that tells them apart: whether a session has already opened in this process. `nvenc_status` gains a `SESSION_OPENED` latch set right after every successful `open_encode_session_ex` — both backends' caps probe and real open, plus the Windows availability probe. No session yet, the version word really is in question and the existing skew advice stands. A session already opened, and the kernel module demonstrably accepted this build's version word, so the message now names per-process driver state and points at the cheap fix (restart the host service, no reboot) plus a request for the log. The load-time gate cannot serve as this discriminator: `NvEncodeAPIGetMaxSupportedVersion` is a pure userspace query, so the classic "updated the driver, didn't reboot" skew sails through it and only fails later at the open. Only a session that actually opened proves the kernel module agreed. The split lives in a pure `invalid_version(bool)` so both halves are unit-tested without touching the process-wide latch. This is a diagnosis change only — it does not fix the underlying field bug, whose root cause is still open. Verified on Linux (192.168.1.25): clippy `-p pf-encode --features nvenc` clean, `cargo test -p pf-encode --features nvenc --lib` 15 passed, rustfmt clean.	2026-07-25 12:40:51 +02:00
enricobuehlerandClaude Opus 5	ead37d066f	perf(encode/nvenc-linux): drop the bring-up probe left on the per-frame blend path ... `33121ece` added a block explicitly labelled "TEMP KWin composite probe (DROP BEFORE MERGE)" to prove the cursor blend was dispatching. It merged, and has been running on every blended frame since: an atomic fetch_add per frame plus a `tracing::info!` with seven computed fields every 512 frames, on the submit hot path of the default-on Linux direct-NVENC backend. The signal it existed for is already covered — the failure arm above it warns once with the dispatch error, and the `else` arm warns when an overlay arrives with no blend at all. What is deleted is only the success-path telemetry. Verified `-D warnings --all-targets` + tests on Linux (default; shipped nvenc,vulkan-encode,pyrowave), and `clippy --features vulkan-encode,pyrowave` on real AMD RDNA3 hardware. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 03:48:59 +02:00
enricobuehlerandClaude Opus 5	310b85f155	fix(encode): a forced-Vulkan pref must not advertise codecs that arm will refuse ... With `PUNKTFUNK_ENCODER=vulkan`, `open_video_backend`'s vulkan arm bails outright for anything that is not HEVC/AV1 ("the Vulkan Video encoder supports HEVC + AV1; the session negotiated {codec:?}"). But `host_wire_caps` for that same pref fell through to the VAAPI probe / static superset, which includes H.264 — so the host advertised H.264, a client could negotiate it, and the session died at encoder open. The pref now contributes a CEILING that is intersected with the device probe, never a replacement for it. That distinction is the whole fix: pinning a static HEVC|AV1 would have ADDED AV1 on the AMD/Intel hosts whose probe currently withholds it (pre-RDNA3, pre-Arc), re-creating this very bug for a different codec. Intersecting can only ever narrow. Without the `vulkan-encode` feature the pref cannot open anything at all — that arm bails with "requires a build with --features vulkan-encode" — so the ceiling is empty there rather than optimistic. Costs nothing on the handshake path: a `&str` match plus a const-folded `cfg!`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 03:17:45 +02:00
enricobuehlerandClaude Opus 5	087a3e358a	fix(encode/vaapi): key the entrypoint cache on the device, not just the codec ... `LP_MODE` cached the resolved VAAPI entrypoint (full-feature `EncSlice` vs low-power `EncSliceLP`/VDEnc) in a process-global array indexed by codec alone. That is not a staleness bug, it is a session-killer, because the cache is load-bearing: once a mode is latched the open tries exactly ONE mode and the `[false, true]` fallback is gone. Latch low-power on an Intel Arc (Gen12+ removed the full-feature entrypoints, so it is the only one that works there), then switch the web-console GPU preference to an AMD dGPU. `render_node()` follows that preference, so every VAAPI open now goes to radeonsi passing `low_power=1`, which it rejects — with no full-feature retry, for the process lifetime. `probe_can_encode` reports all-false (so the advertisement silently falls back to the static superset) AND the session's own encoder open fails. Now keyed on (render node, codec, bit depth): - The render node because the entrypoint is a property of the DEVICE libva opens, and it is literally what `render_node()` hands libva — so key and device cannot describe different GPUs. Deliberately not `pf_gpu::selection_key()`, which can name a different adapter than the node actually opened. - The bit depth because Main10 and 8-bit can resolve to different entrypoints on the same device; one shared slot let an 8-bit answer pin the 10-bit open, i.e. HDR under-advertisement. Verified `-D warnings --all-targets` + tests on Linux (default; shipped nvenc,vulkan-encode,pyrowave). The multi-GPU switch itself needs a box with two VAAPI-capable adapters — owed on-glass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 03:17:44 +02:00
enricobuehlerandClaude Opus 5	7536f7319a	fix(gamestream): a software-encode host must advertise H.264 only ... `base_codec_mode_support` fell through to the static superset (H.264|HEVC|AV1) on a GPU-less host, so Moonlight negotiated HEVC or AV1 and the session then died at encoder open with "the software encoder emits H.264 only" — openh264 encodes nothing else. The native plane's twin of this function, `pf_encode::Codec::host_wire_caps`, has gated on exactly this since it was written; this one never did. Deliberately a local gate rather than delegating wholesale to `host_wire_caps()`. Delegation is the drift-proof shape and was the first design, but on Windows it re-runs the DXGI adapter enumeration several times per `/serverinfo` GET — the probe helpers each sample it uncached — and this endpoint is polled by every client. The software case is a plain config read, so it costs nothing here. Recorded in a comment rather than fixed: the static `MaxLumaPixelsHEVC` in the serverinfo XML still advertises an HEVC limit even when the mask now drops HEVC. Harmless (Moonlight gates capability on the mask, not the limit) but it is a second, now-inconsistent advertisement. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 02:41:57 +02:00
enricobuehlerandClaude Opus 5	4d9f94e0a4	docs(encode): record why the production loops must not call Encoder::flush ... `flush` looked dead — the only caller in the host is the `spike` dev subcommand — so an audit sweep filed it as "wire it in or delete it". Both are wrong, and without this note the next sweep will re-file it. Wiring it in is refuted by control flow: both encode loops reach their exit only AFTER the transport is gone (client disconnected, or the session stopped), so the AUs a flush would recover have nowhere to go. And flush is the one call on this trait that can BLOCK on a wedged encoder, on exactly the teardown path a stopped session needs to finish promptly — the Linux direct-SDK NVENC retrieve-thread join is untimed, so flushing there could hang a session that is already ending. Deleting it is refuted by real consumers: `spike` encodes a FINITE clip and wants the tail, and the `#[ignore]`d hardware smoke tests across the backends assert the drain contract on real GPUs. Those are finite-stream users; a live session is not one. Doc only, no behaviour change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 02:41:57 +02:00
enricobuehlerandClaude Opus 5	ef239691df	feat(encode): make cursor blending a queryable capability, not an assumption ... `open_video`'s `cursor_blend` argument was a request with no answer: lib.rs did `let _ = cursor_blend;` and only three backends ever read `CapturedFrame::cursor`. So a session could ask for a composited pointer, get a backend that silently discards it, and stream with no mouse cursor and nothing in the logs. Two separately-confirmed audit findings — the VAAPI dmabuf path and the libav-NVENC CUDA path — are symptoms of that one hole. `EncoderCaps::blends_cursor` makes it a fact each backend states. The four exhaustive `EncoderCaps { .. }` constructors mean adding the field is a compile error until every backend answers, which is the enforcement mechanism for future backends rather than a side effect. Vulkan Video answers from its ACTUAL configured source rather than statically: only the CSC path composites (`prep_cursor` feeds the compute shader), while the RGB-direct/EFC front-end and the native-NV12 source have no compositing stage at all and merely warn once that the pointer is being dropped. `open_video` warns when a session asked for blending and the opened backend cannot deliver it. A warning is deliberately all it does: `open_video` cannot re-plan capture, so refusing would trade a missing pointer for a dead session. The host owns `plan.cursor_blend` and is the only layer that can fall back to capturer-side compositing — this gives it something to base that on. Enforcement is NOT included. The reviewed design proposed refusing the client's host-composite flip to keep the client drawing its own pointer, but `CursorRenderMode` is client->host only: there is no host->client counterpart, so refusing yields no pointer at all — the same failure it claimed to prevent. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 02:41:57 +02:00
enricobuehlerandClaude Opus 5	ab63e0dad3	fix(encode/nvenc-windows): fail safe when nobody sets the input ring depth ... `set_input_ring_depth` is a DEFAULTED trait method, so a caller that forgets it fails silently — and one did. The GameStream loop opens an encoder (gamestream/stream.rs:671 and the rebuild at :831) and never called it, while the Windows IDD-push capturer declares a ring of 2 and `async_inflight_cap()` defaults to 4. With PUNKTFUNK_NVENC_ASYNC=1 a Moonlight session therefore pipelined four encodes against a two-texture ring, letting the capturer rotate a texture out from under a live encode: torn or mixed frames, never an error — precisely the corruption the cap exists to prevent, and precisely what the trait doc warns "fails silently and intermittently". Guarded at the single point of CONSUMPTION rather than by plumbing the setter into every loop: `input_ring_depth` has exactly one reader in the workspace, so one fail-safe covers every caller including ones not yet written, whereas fixing N call sites only fixes the N someone remembered. An unconfigured ring is now treated as the shallowest any capturer here declares, so the unconfigured path degrades to less pipelining — a latency cost, not corruption. The two GameStream sites also pass the REAL depth, because the fail-safe is a floor, not a substitute: `idd_depth` is configurable and a deeper ring is free pipelining the fallback would forfeit. Default (sync) sessions are unaffected — the cap is only read while the async retrieve thread exists, and that is opt-in. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 02:41:57 +02:00
enricobuehlerandClaude Fable 5	78fe77b049	feat(host/encode): de-escalate the latency escalation once cadence holds clean ... Escalate-and-hold's missing half. The contention escalation (capture depth, then the NVENC pipelined retrieve) was permanent: one sustained overrun — even one CAUSED by the ABR overdrive's rebuild storms — cost the session its depth-1 latency and its sub-frame streaming forever, and `encode_us` reported queue depth instead of ASIC time for the rest of the session. - The leaky bucket now keeps scoring after escalation. A sustained every-frame-on-cadence run (~5 s at 120 fps) winds back one stage in reverse order: pipelined retrieve first (its rebuild restores the IO-stream binding and sub-frame chunked streaming), then capture depth back to 1. Attempts are paced by an exponential backoff (1 → 5 → 25 min, capped) — a workload that truly needs the escalation converges to keeping it, but never a permanent latch. - NVENC (Linux) implements `set_pipelined(false)`: a `want_sync` latch handled at the same drained safe point as the engage side (`maybe_disengage_async` mirrors `maybe_engage_async`); the lazy sync re-init re-arms everything and opens on an IDR. The stream loop polls until the switch lands, then re-runs the escalation warmup so the wind-back's own stall can't re-escalate it. `PUNKTFUNK_NVENC_ASYNC=1` (operator-pinned async) refuses the wind-back; the trait doc now specifies the two-way contract. - While escalated, `cadence_degraded` stays latched (bitrate climbs refused) even with the bucket drained: the headroom is spent, and climbs resuming mid-escalation would saw against it and starve the clean run. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 01:44:54 +02:00
enricobuehlerandClaude Fable 5	1b27706a9b	feat(host/native): truthful bitrate state — applied-rate adoption, ceiling pre-clamp, climb refusal ... Host half of the §ABR-overdrive fix. The stream loop now reads `Encoder::applied_bitrate_bps()` after every bitrate apply and stores THAT into `bitrate_kbps`/`live_bitrate` — the send pacer, web console, mgmt registry and control-task acks all track what the ASIC really targets instead of the requested rate (the pre-fix ack promised 1.01 Gbps while the encoder ran 794 Mbps, and the client controller climbed from the phantom base forever). - A short apply teaches `encoder_ceiling_kbps` (shared atomic): the stream loop pre-clamps incoming requests to it and SKIPS the apply when nothing would change — ending the reconfigure-reject → full-rebuild(~0.6 s + IDR) storm — and the control task resolves future SetBitrate acks against it, so the client learns the ceiling through the existing ack path (no wire change; old clients converge too). - `cadence_degraded` (shared flag, leaky-bucket level ≥ 10 or an escalated session): while set, the control task resolves climbs to the current applied rate — on a fat LAN no network signal ever stops a climb the encoder can't serve, and past the compute knee more bits only deepen the cadence miss. Descents always pass; they're the cure. - Escalation-warmup hygiene: an ABR rebuild stall (~70 missed deadlines at 120 fps, 3.5× the escalate threshold) and the backlog scored against a heavier rate no longer feed the latency escalation — rebuilds reset the leaky bucket and re-run the warmup; in-place down-steps clear the bucket. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 01:44:54 +02:00
enricobuehlerandClaude Fable 5	f3c3a9427b	feat(client/abr): learn the host's rate cap from short acks, and read host encode time as a signal ... Two client-side halves of the §ABR-overdrive fix (the 4K120 sessions that climbed to 1 Gbps against a 794 Mbps encoder and a 8.33 ms budget): - Short-ack cap learning: the host now resolves a climb it can't serve to what the encoder actually runs at (its codec-level ceiling, or the current rate while encode is behind cadence). Two consecutive identical short acks latch that value as a host cap the climb logic folds into its ceiling — one short ack stays a transient (a failed rebuild also acks short once). The cap is mode-scoped (cleared on an accepted mode switch, tracked via a mode generation counter the control task bumps) and re-probes one step after ~60 s parked clean, so a heavy-scene refusal can't quietly cap the whole session. - Host-encode-latency down-driver: the per-AU 0xCF `encode_us` the host already ships (and the overlay already draws) now feeds the controller through its own window accumulator — the overlay channel is lossy and embedder-drained, so the ABR gets a dedicated mirror of the decode-latency path. Baseline-relative like the decode signal (an escalated host reports encode_us inflated by ~a frame of queue depth; an absolute budget threshold would read permanently red), with the baseline rebased after our own decreases so one backoff doesn't train-fire into the floor. This is the only signal that can push an already-too-high rate back under the encoder's compute knee — host climb refusal stops the climb, but nothing else descends on a clean LAN. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 01:44:54 +02:00
enricobuehlerandClaude Fable 5	c1d54b835b	fix(encode/nvenc): cache the level ceiling, expose the applied bitrate, force 2-way split at 4K120 ... Three encode-time fixes from the 4K120 field analysis (sessions pinned ~107 of 120 fps, 14-15 ms reported encode): - Ceiling truth: the codec-level bitrate clamp (binary search at session open) now records its result in a process-lifetime advisory cache keyed by GPU/config, so an ABR overshoot opens — or in-place reconfigures — straight AT the ceiling instead of re-running the ~6-open search (and a full rebuild + IDR) on every overshoot. New `Encoder::applied_bitrate_bps()` exposes the post-clamp rate so the session loop can stop pacing/acking a phantom requested rate (consumed host-side in a follow-up). - Clamp-search hygiene: only NVENC parameter/caps rejections steer the search now (`NvCallError` keeps the raw status downcastable); a transient failure (busy engine, session limit, OOM, driver skew) propagates instead of shrinking into — and now caching — a bogus ceiling. The floor fallback also records the split mode it actually opened with, so a later reconfigure re-presents the real session params. - Split-frame selection: one shared `resolve_split_mode` replaces the two byte-identical direct-SDK copies; the force-2-way threshold moves to `SPLIT_FORCE_PIXEL_RATE` (950 Mpix/s, shared with the libav path) because 4K120 = 995,328,000 px/s missed the old `> 1e9` gate by 0.47% and stayed on AUTO — which never engages at 2160 px height, leaving the second NVENC engine idle in exactly the mode the threshold existed for. The Linux session-ready info! line now carries the final split mode (journals are INFO+; this was undiagnosable from user logs). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 01:44:54 +02:00
enricobuehlerandClaude Opus 5	42e5f5ad1e	fix(encode/windows): two dead items the new lint leg exposed in the shipped combo ... 09aa2db3 turned on `-p pf-encode --all-targets -D warnings` for Windows and removed the crate-wide `allow(dead_code)`; together those surfaced two genuinely-dead items in `nvenc,amf-qsv,qsv` — the combination the installer ships — and CI went red on my own step. - `WinVendor::Amf`: native AMF replaced the libavcodec AMF path in production, so the only remaining CONSTRUCTOR is the `#[cfg(feature = "amf-qsv")]` latency A/B in amf.rs — test code, so the lib target constructs it nowhere. The module header already says this machinery is kept deliberately for that measurement, so it gets a targeted `#[allow(dead_code)]` naming the reason rather than deletion. - `probe_can_encode`: `lib.rs`'s only caller is under `cfg(all(not(feature = "qsv"), feature = "amf-qsv"))`, because with the native VPL backend compiled in `qsv::probe_can_encode` answers instead. Gated `#[cfg(not(feature = "qsv"))]` to match its call site. Both are real findings the blanket allow had been hiding; neither is a behaviour change. WHY THIS ESCAPED MY PRE-PUSH CHECKS, since that is the useful part: the Windows runner I verify on has no FFmpeg dev tree, so `amf-qsv` could not build there and `ffmpeg_win.rs` was compiled by NOTHING in my matrix — the same class of blind spot this whole audit is about, reproduced by me. CI's own FFmpeg turns out to be cached on that box at C:\Users\Public\ffmpeg, so the verification recipe now sets FFMPEG_DIR and covers `nvenc,amf-qsv,qsv` (the CI command and my new step) plus `amf-qsv` without `qsv` — the combo that still uses `probe_can_encode`. All three clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 01:04:04 +02:00
enricobuehlerandClaude Opus 5	d49f1bba49	fix(tray): count native sessions as streaming, and stop hiding "Open web console" ... The tray sat at "Idle" through an entire stream, and its Windows context menu could come up without its main action. Two separate causes. `GET /api/v1/local/summary` reported `video_streaming`/`audio_streaming` straight from `AppState.streaming` — flags only the GameStream media pipeline raises. The native punktfunk/1 plane is the DEFAULT (GameStream is opt-in) and never touches them, so every native session read as idle: idle icon, and a tooltip that printed that session's own resolution next to the word "idle" (the `session` field was already native-aware). This is the blind spot `/status` was fixed for — see the `session_status` module doc — which the summary kept. Both flags now OR in a live native session, and the tray additionally treats a reported session as streaming, so a new tray reads an older host correctly too. The menu built "Open web console" (and the pairing entry) only while a live loopback probe of the console had just succeeded. A console still starting, or an SSR render slower than the 2 s probe timeout, therefore deleted the tray's most-wanted action outright — indistinguishable from a tray that never had one, with left-clicking the icon as the only, undiscoverable, way in. The entry is now always present and the default item; a failed probe changes its label to "(not responding)" instead of hiding it, and takes two consecutive misses to say so, since one timeout is not "down". While here: a "Release kept display…" entry when displays are held (the summary field's own doc promised a one-click release that did not exist), and entries deep-link to /pairing and /displays instead of all landing on the dashboard. The Linux SNI menu mirrors all of it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:46:30 +02:00
enricobuehlerandClaude Opus 5	09aa2db37c	fix(encode): probe Vulkan encode before committing capture to producer-native NV12 ... `linux_native_nv12_ok` is the verdict the host threads into capture negotiation (session_plan -> OutputFormat::nv12_native -> ZeroCopyPolicy::native_nv12_session -> pf-capture's prefer_native_nv12). Its doc claimed "the backend must be eligible to open", but it asked only three static questions — codec is H265/AV1, an env default, and a pref denylist — and never whether this GPU has an encode queue at all. It could not: vulkan_video.rs exposed no probe. That verdict is uniquely load-bearing. Once the producer has been asked for two-plane NV12 there is NO fallback: open_video deliberately makes a failed Vulkan open FATAL for an NV12 capture rather than degrading to libav VAAPI, because VAAPI would import that buffer as packed RGB and stream silent garbage. So on a gamescope host whose Mesa lacks Vulkan HEVC encode the session died at its first frame, while the same host with PUNKTFUNK_PIPEWIRE_NV12=0 streamed fine — and the comment promising such a device "degrades gracefully to the old backend rather than breaking the stream" was stale on every gamescope host. Two changes: 1. The gate. The third conjunct was a denylist of the EXPLICIT prefs that skip Vulkan Video ("nvenc"|"nvidia"|"cuda"|"pyrowave"), which silently missed the one that matters: the DEFAULT encoder_pref is "", and "" resolves to auto, which on an NVIDIA box opens NVENC. A stock NVIDIA host passed this gate. It now consults `linux_zero_copy_is_vaapi`, which layers the pref on top of the same auto decision open_video makes — what the note on `linux_auto_is_vaapi` says a capability probe must use, and what the downstream consumer of this very verdict already uses. This alone was worth fixing; a probe added behind the old gate would have opened a Vulkan instance on every NVIDIA handshake. 2. The probe. `vulkan_video::probe_encode_support` runs the FIRST check open_inner performs and hard-fails on — the physical-device + encode-queue-family scan for this codec's op — and nothing more, so it is provably no stricter than the open and can never talk a working host out of the fast path. The scan is now a shared `find_encode_device` used by BOTH, because a probe that mirrors a dispatch goes stale the first time the dispatch grows a case (the failure open_video's backend-label note already records). Cost: one instance plus physical-device queries — no logical device, no video session, no VRAM — cached per (selected GPU, codec) in the can_encode_10bit idiom, with the probe run outside the lock. Per codec, not once: codec_op_for selects a different queue-family bit for AV1, and HEVC-encode-without-AV1-encode is the common VCN/ANV configuration. Later stages (create_device, create_video_session, the capability query) can still fail for reasons the probe does not model. Those are harmless: the capture format is only committed once the probe says yes, and everything after keeps the ordinary packed-RGB negotiation. Verified `-D warnings --all-targets` + tests on Linux (default; shipped nvenc+vulkan-encode+pyrowave). The behaviour needs an on-glass check on the bazzite RADV box — including the negative case, which `RADV_DEBUG=novideo` reproduces. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Opus 5	4063ddc93d	perf(encode/nvenc-linux): swscale the packed 3-bpp expand instead of a per-pixel loop ... `submit_cpu`'s RGB24/BGR24 → rgb0/bgr0 expand ran `w*h` iterations per frame, each building two bounds-checked sub-slices for a 3-byte copy plus a pad-byte store — a shape LLVM will not vectorise into the byte shuffle it actually is. At 3840x2160 that is 8.3M iterations on the encode thread, per frame. It is not an edge case. The module header says the portal commonly negotiates packed 24-bit RGB, and pf-capture offers `VideoFormat::RGB` first because wlroots commonly fixates it — so this was the mainstream CPU path, running roughly an order of magnitude slower than the 4-bpp sibling branch (a plain row memcpy) purely because of how it was written. swscale's packed-RGB expanders are SIMD, the sibling VAAPI backend already routes RGB24/BGR24 through them, and this file already owned the `sws_getContext` / `sws_freeContext` lifecycle — so this is net subtractive rather than new machinery: the existing CSC condition widens to include `expand`, and the hand-written loop goes away. No new field, no second context, nothing added to `Drop`: `expand` is false whenever `want_444` (see the `nvenc_pixel`/`expand` binding), so the three users are mutually exclusive and one context serves whichever applies. The `expand` field itself is gone with its only reader. `sws_setColorspaceDetails` is now applied ONLY for the 4:4:4/HDR users. The expand is a pure byte shuffle — NVENC does the RGB→YUV itself downstream — and handing it a matrix and range would have silently range-converted every packed-RGB session, which is exactly what the module header promises does not happen. Verified `-D warnings --all-targets` + tests on Linux (default; shipped nvenc+vulkan-encode+pyrowave). The pixel path itself is unverifiable without an NVIDIA box: `nvenc_hdr10_smoke` and friends are #[ignore]d, so the channel order and the pad byte want an on-glass check on the CachyOS 5070 Ti. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Opus 5	c7081b2a82	fix(encode/nvenc-linux): stop leaking the SwsContext on open's early returns ... `sws_getContext` hands back a raw pointer whose only `sws_freeContext` lives in `Drop for NvencEncoder` — and `Drop` needs a CONSTRUCTED `Self`, which does not exist on either of `open`'s early returns: the intra-refresh-unsupported path (which recurses into `Self::open`) and the plain error return. Both sit between the context's creation and the `Ok(NvencEncoder { … })` that would give it an owner, so every failed open leaked one. That is not a once-per-process wart. `open_nvenc_probed` walks an EINVAL bitrate ladder — requested rate, then the codec-level cap, then ×3/4 down to 50 Mb/s — re-entering `open` at each step, so a GPU that refuses the requested bitrate leaks a context per step (up to ~10). The intra-refresh retry adds one more. Fixed structurally rather than with a guard: the block depends only on values known before the encoder open (`want_444`, `want_hdr10`, `cuda`, `format`, `nvenc_pixel`, the dimensions, `full_range_444`), so moving it BELOW `video.open_with(opts)` — to just above the struct construction, with nothing fallible in between — makes the leak unrepresentable instead of merely handled. No behaviour change: same context, same colourspace details, same field. Found while designing the WP1.4 swscale expand, which would have promoted this from a 4:4:4/HDR-only leak (the only sessions that build a context today) to one on every packed-RGB session. Fixing it first is the prerequisite for that change. Verified `-D warnings --all-targets` + tests on Linux (default; shipped nvenc+vulkan-encode+pyrowave). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Opus 5	6be174dc9c	fix(encode/windows): the encode bit depth must follow the pixels, not the negotiation ... All three Windows backends derived it the same wrong way — `bit_depth >= 10 || matches!(format, P010 | Rgb10a2)` at ffmpeg_win.rs:154, amf.rs:1275 and qsv.rs:777 — so the NEGOTIATED depth could force a 10-bit encoder over an 8-bit capture. That combination is not hypothetical. A client advertises 10-bit, the handshake negotiates bit_depth=10, and then enabling advanced colour on the IDD virtual display fails — at which point the capturer says exactly that and delivers 8-bit NV12 anyway ("10-bit HDR was negotiated but enabling advanced color on the virtual display FAILED — encoding 8-bit SDR"). Every vendor then lost the session, each in its own way: - native AMF and native QSV derived `expected = P010`, saw Nv12, and bail!'d at open; - the libavcodec path accepted the open, built a P010 encoder, and then failed EVERY submit forever, because its per-frame check recomputes the depth from the frame and never matches. reset() could not help: the rebuild re-derived the same wrong depth from the same stored bit_depth. The host burned MAX_ENCODER_RESETS and ended the session. The last one is the worst of the three because it IS the fallback: native QSV correctly refuses this input at open, and lib.rs then falls back to the ffmpeg path "for robustness" — which accepted it and died per frame instead. Since the duplication was the bug, the fix is one shared `ten_bit_input()` in codec.rs that all three call, and it follows the delivered pixels. That also keeps the stream HONEST rather than merely alive: the depth selects the colour signalling (BT.2020 PQ vs BT.709) and the staging surface format, so an 8-bit capture now produces an 8-bit stream that says it is SDR — which is what the capturer already reported it was sending. It warns when the negotiated depth is discarded. The negotiated depth stays an upper bound. The session LABEL may still claim HDR; that mismatch lives in the negotiation, not in the encoder, and is not addressed here. `is_10bit_format` keeps its (now format-only) definition and is used by submit_d3d11's per-frame check, so the predicate the encoder was built from and the one it re-checks per frame cannot drift. That check can now only fire on a genuine mid-stream depth change. Verified `--all-targets -D warnings` on Windows (no features / pyrowave / qsv / nvenc,qsv; 31 tests) and Linux (default; shipped nvenc+vulkan-encode+pyrowave). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Opus 5	6c97c00add	fix(encode/pyrowave): the RDO block-index cap must cover 4:2:0, not just 4:4:4 ... The vendored rate controller packs the 32x32 block index into the low 16 bits of `RDOperation::block_offset_saving` (pyrowave-sys patches/0002). Past u16::MAX the index collides with the `saving` field, the resolve over-credits, and the emitted payload can overshoot the buffer `pyrowave_encoder_packetize` writes into — whose only bounds check is an `assert` that the Release (NDEBUG) vendored build compiles out. There is no Rust-side guard behind it. All three callers of `pyrowave_mode_fits_rdo` hardcoded 4:4:4, leaving 4:2:0 unchecked — but 4:2:0 overflows too, just later: 8192x6144 is 73728 blocks and 8192x8192 is 98304, while `Codec::PyroWave.max_dimension()` permits 8192 per axis, so both are reachable from a client-requested `mode=WxHxFPS`. Worse, the host's only use of the helper (native/handshake.rs) is a 4:4:4 -> 4:2:0 downgrade, so an oversized mode was actively routed INTO the unguarded branch. The cap now lives in `validate_dimensions`, checked against 4:2:0 — the most permissive chroma, so a mode that cannot fit there fits no PyroWave session at any chroma. That is the single chokepoint both the negotiator (handshake.rs:180) and `open_video_backend` already run. Both encoder opens additionally check the chroma actually being opened: the 4:4:4 half, plus defence in depth for the `PUNKTFUNK_ENCODER=pyrowave` lab override. Not dormant: punktfunk-host has `default = ["pyrowave"]` and no build passes `--no-default-features`, so these backends ship in every host binary. Tests pin the arithmetic (8192x6144 = 73728, 8192x8192 = 98304, 7680x4320 still fits) and assert the cap does not leak to H.265/AV1, which have no such controller. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Opus 5	16fa43da40	ci(encode): lint and test the feature-gated encode backends ... pf-encode's GPU backends are off by default, so almost none of them were under `-D warnings`: - ci.yml lints/tests with default features, which do cover VAAPI, libav-NVENC and — via punktfunk-host's `default = ["pyrowave"]` — the PyroWave backends, but not `nvenc` or `vulkan-encode`. - deb.yml builds those two, but with `cargo build`, where warnings are not errors. That left enc/linux/nvenc_cuda.rs, enc/linux/vulkan_video.rs and the vendored vk_av1_encode / vk_valve_rgb bindings — ~8,150 lines carrying ~70 `unsafe` blocks — never linted anywhere, so the crate's own `#![deny(clippy::undocumented_unsafe_blocks)]`, its stated unsafe-proof gate, was never actually enforced on them. Linux gains a clippy+test leg at the SHIPPED feature set: deb.yml builds `punktfunk-host/nvenc,punktfunk-host/vulkan-encode` WITHOUT `--no-default-features`, so the .deb carries pyrowave too and that combination is what deserves the lint. GPU-free — the hardware tests are `#[ignore]`d and NVENC/CUDA dlopen their entry points, so the test binary links with no driver. Windows gains a separate `-p pf-encode --all-targets` lint. The existing lint is `-p punktfunk-host`, which never builds pf-encode's test targets — the blind spot that let the Linux twin's tests rot. It must be clippy rather than `cargo test`: on MSVC nvidia-video-codec-sdk link-imports NvEncodeAPICreateInstance / NvEncodeAPIGetMaxSupportedVersion, so a test binary cannot link without the driver's import lib. clippy type-checks without linking; ci.yml runs the tests. `--all-targets` is load-bearing, not decoration: without it the feature-gated `#[cfg(test)]` modules are never compiled at all. Also widens windows-host.yml's paths filter, which listed `crates/pf-encode/**` but none of the crates it compiles against (pf-frame, pf-gpu, pf-zerocopy, pf-host-config, pf-capture, ...), so a change reaching the Windows host through one of those triggered no Windows build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Opus 5	07348c0175	refactor(encode): drop the crate-wide allow(dead_code) ... Inherited from the pre-extraction host crate root as scaffolding for backend paths defined ahead of the build that used them. A census across every feature combination on both platforms (flip it to `warn`, rebuild) found it was hiding exactly two items — so it bought nothing while blinding the crate to future rot: - `vaapi::fourcc` — superseded by `pf_frame::drm_fourcc`; no call sites left. - `vulkan_video::open_opts` — test-only (the smoke tests use it to pass the RGB-direct request explicitly rather than through the env), now `#[cfg(test)]`. Removing it surfaced a real latent defect the Linux census could not see: `amf.rs`'s `percentile` / `drive_and_measure` helpers are used only by the `#[cfg(feature = "amf-qsv")]` latency A/B benchmark, so a `--features nvenc,qsv` build compiled the helpers with their caller gated out. They now carry the same gate as their caller. Verified `--all-targets -D warnings` on Linux (no features; shipped nvenc+vulkan-encode+pyrowave) and Windows (no features; pyrowave; qsv; nvenc,qsv). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Opus 5	e30551b1e2	fix(encode/nvenc-linux): unrot the direct-NVENC test module ... All ten `NvencCudaEncoder::open` call sites in the `#[cfg(test)]` module passed 9 arguments to a 10-parameter function: `cursor_blend` was added to `open` and the tests were never updated. The module has been uncompilable ever since — `cargo clippy -p pf-encode --features nvenc --all-targets` fails with 10x E0061. Nothing in CI noticed because no job compiles this crate's feature-gated test targets: ci.yml lints/tests with default features (which do not include `nvenc`), and windows-host.yml lints `-p punktfunk-host`, which builds pf-encode as a dependency and so never builds its test targets. The CI commit below closes that gap; this has to land first or that leg starts red. `false` is what these tests exercised before `cursor_blend` existed: every frame they build sets `cursor: None`, and there is no cursor-blend test. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Fable 5	8d5a9f66c9	fix(gamescope): ship a packaged privilege path for the DM-stop takeover ... Field report (Nobara, 0.19.2): entering Game Mode mid-stream left the monitor on and the stream mirroring at the desktop's resolution. Root cause: the DM-flavor takeover needs privilege to stop plasmalogin, the polkit rule is a docs-only manual step nobody installs, so every managed entry silently degraded to ATTACH — and with a physical display connected the attach path mirrors the box's own session at its own mode. Ship the privilege with the packages instead: a root helper (libexec/punktfunk/pf-dm-helper, verbs stop|restore) behind its own polkit action (io.unom.punktfunk.dm-helper, allow_any — the same mechanism Nobara's os-session-select uses, and the helper derives the DM unit from the display-manager.service symlink itself so callers never name a unit across the privilege boundary). The host tries the plain system-bus verbs first (root / operator rule still take precedence), then pkexec's the helper; the restore paths (idle restore + in-stream desktop-switch honor) use the same ladder so a takeover that needed the helper can always be undone by it. Packaged in rpm/deb/arch (Arch under /usr/lib/punktfunk with the policy's exec.path annotation rewritten; the host probes both layouts). Nix is left out deliberately: store paths can't match the probe, NixOS keeps the manual rule. Docs updated — the rule snippet stays as the scoped alternative. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 23:41:29 +02:00
enricobuehlerandClaude Opus 5	5c7a9407ff	fix(windows/web): start the console once its inputs exist, and verify it started ... A fresh install left PunktfunkWeb registered but not running: `web setup` waited only for the mgmt token before firing `schtasks /run`, while `web-run.cmd` also requires the host identity cert — and the host writes the token during argument parsing but `cert.pem` only after the pure-Rust RSA-2048 keygen inside `serve`. The launcher lost that race, exited 1, and since the task carried no trigger but boot (Task Scheduler does not reliably restart on a non-zero exit code) the console stayed down until the next reboot, with the installer still reporting "web console set up + started". - `web setup` gates on cert.pem (written last) as well as the token, 90 s budget. - After `schtasks /run`, poll for the :47992 listener and retry before giving up; warn honestly instead of claiming a start that did not happen. - `web-run.cmd` (installed + dev) waits in-process for the token + cert (~5 min) rather than exiting 1 and hoping restart-on-failure retries. - Register the task with a logon trigger alongside boot, falling back to the boot-only XML if a Task Scheduler build rejects it. - Linux had the same defect: punktfunk-web.service's Restart=on-failure gave up permanently after systemd's default 5-starts-in-10 s limit. StartLimitIntervalSec=0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-24 23:22:09 +02:00
enricobuehler	7781d09e26	feat(linux): log if unsupported / too low gamescope version discovered	2026-07-24 20:57:44 +02:00
enricobuehlerandClaude Opus 4.8	f4fe4d0792	chore(release): bump workspace version to 0.19.2 ... An all-fixes patch on top of 0.19.1, all host-side: - KDE Plasma display takeover moved off kscreen-doctor to in-process kde_output_management_v2 (86d5d666), with the >60 Hz custom-mode install ported too (64511af4) — a KWin host whose kscreen-doctor wedges now disables its physicals and hands over the streamed output in ~2.4 ms instead of hanging ~26 s and never taking over. - The gamescope managed takeover is display-manager-flavor-aware (e35dad52) so switching a non-SDDM Linux desktop (Nobara / plasmalogin) into Game Mode no longer start-limits the display manager into a permanent black screen, and in-stream 'Switch to Desktop' is honored under it (a3e21d92). - Windows display isolation anchors the kept sources at the desktop origin (9b241d9d) so an origin-less desktop no longer fails 0x57, with restore guaranteed never to leave the desktop all-dark. - Windows pen/touch/absolute-mouse map over the streamed output's rect rather than the whole virtual desktop (087e7d04), so absolute input lands correctly when a physical monitor is kept on beside the streamed display. Nothing moved on the wire (protocol 2) or at the C ABI (13), so no embedder rebuild and 0.18/0.19 peers keep mixing freely. The Windows virtual-display driver protocol is unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 17:56:08 +02:00
enricobuehlerandClaude Fable 5	087e7d0405	fix(inject/windows): map absolute input over the streamed output's rect, not the whole desktop ... Pen, touch, and absolute mouse arrive normalized to the STREAMED display's frame, but pointer_windows::to_screen and sendinput's MouseMoveAbs mapped them over the whole virtual desktop — correct only when the virtual display is the sole active display (Exclusive topology). In Extend — a physical monitor kept on beside the virtual output, or an Exclusive isolate degraded to the 0x57 keep-physicals fallback — the streamed output sits at a non-zero origin, so every sample landed shifted and mis-scaled. The pen exposed it first (field report 2026-07-24): a stylus is strictly absolute, with no closed-loop correction onto the target like a cursor. New pf-inject::stream_target (Windows): the host publishes the streamed output's CCD target id at capture bring-up (one central site — capture_virtual_output covers the native and GameStream planes); mapping sites resolve its current desktop rect through pf-win-display's source_desktop_rect — the same resolver the cursor-readback poller uses, so inject and readback always agree — TTL-cached (250 ms) because a group-layout re-arrange moves a live output's origin mid-session. No target set / never resolved falls back to the whole virtual desktop (the historical mapping, still right for Exclusive topology and devtest). One change in to_screen covers pen + touch; MouseMoveAbs converts the same desktop pixel into the 0..65535 MOUSEEVENTF_VIRTUALDESK coordinate, closing the identical latent absolute-mouse bug (apollo-comparison open item #14/#30). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 17:38:36 +02:00
enricobuehlerandClaude Opus 4.8	64511af4d3	fix(kwin): install >60Hz custom modes in-process too — KWin path is now kscreen-free ... Follow-up to the previous commit: the only KWin topology op still shelling out to kscreen-doctor was the >60 Hz custom-mode INSTALL (`set_custom_refresh`). Port it to `kde_output_management_v2` so the whole KWin path is kscreen-free on modern KWin. `kwin_output_mgmt::set_custom_mode` builds a one-entry `kde_mode_list_v2` (set_resolution / set_refresh_rate / set_reduced_blanking=full / add_mode), applies it via `kde_output_configuration_v2.set_custom_modes` (since 18), waits for KWin to generate the mode (its CVT generator may align the width down — matched with the same height-exact / width-within-8 / refresh-within-1Hz gate as before), then selects it — which changes the output size and drives the sacrificial-birth stream renegotiation. `kwin::create`'s want_high branch tries this first and only resolves a kscreen id + calls `set_custom_refresh` if it returns None (pre-6.6 KWin without set_custom_modes, or the compositor not answering) — so a >60 Hz session on a box where kscreen-doctor wedges no longer eats a 5 s resolve timeout either. Bonus: `set_custom_modes` REPLACES the custom list, so reconnects are idempotent — no more one-custom-mode-per-connect growth of the user's display list. Verified: cargo test -p pf-vdisplay (73 pass), clippy -D warnings clean, fmt clean. The set_custom_modes round-trip is proven live on KWin 6.6.4: apply=applied, and a 1648x928@75 request generates 1648x928@74.901 (CVT fractional refresh, caught by the 1 Hz tolerance). The mode SELECT + full >60 Hz stream is still owed on-glass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 12:47:34 +02:00
enricobuehlerandClaude Opus 4.8	86d5d66660	fix(kwin): drive display topology over kde_output_management_v2, not kscreen-doctor ... A KDE host on Nobara stopped disabling its physical screens and creating the virtual output the moment it updated: streaming still came up, but bring-up took ~26 s and the streamed output never became the desktop (`also_disabled=[]`). Root cause is not our topology logic — it's that every `kscreen-doctor` call on the reporter's session wedges. kscreen-doctor drives libkscreen, which (per setup) waits on the kscreen KDED module over D-Bus; when that layer is stuck it blocks in its own connect and never returns, so all five topology queries hit their 5 s budget and got killed (host log). Reproduced live on a Nobara / KWin 6.6.4 box: `kscreen-doctor -j` there times out at 8 s, every time. But the compositor's OWN Wayland is fully responsive on that same session — the host just created a virtual output over it via zkde_screencast. So drive the topology (resolve our output, take primary, disable the physical/bootstrap outputs, capture their modes, re-enable on teardown, position) directly over `kde_output_management_v2` + `kde_output_device_v2` instead of shelling out. On that same Nobara box the in-process path binds management (v19) and enumerates the outputs in 2.4 ms — ~3400x faster than the 8 s hang, and immune to whatever wedges the standalone tool. - vendor kde-output-management-v2 / kde-output-device-v2 (KWin advertises mgmt v19, device v20); generate client bindings inline (the interdependent-protocol module split from the wayland-protocols crate; needs the `bitflags` dep for the device protocol's bitfield enums). - new `kwin_output_mgmt`: bounded enumerate-then-apply over one Wayland connection; every wait is time-bounded so a genuinely wedged compositor degrades to `handled = false` and the old kscreen-doctor path still runs. - `kwin::create` topology + `apply_position` prefer the in-process path (address our output by its stable device UUID, supersede-robust) with kscreen-doctor as the fallback. The 60 Hz path now makes ZERO kscreen-doctor calls; only the >60 Hz custom-mode install still shells out (its in-process port is a follow-up). Verified on Linux: cargo test -p pf-vdisplay (73 pass), clippy --all-targets -D warnings clean, fmt clean, punktfunk-host checks clean. In-process enumeration proven live against KWin 6.6.4 (the reporter's env); the disable/apply path is not yet on-glass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 12:47:33 +02:00
enricobuehlerandClaude Fable 5	a3e21d9227	feat(vdisplay/gamescope): honor in-stream 'Switch to Desktop' under the managed DM takeover ... First on-glass test of the DM-flavor takeover confirmed the black-screen fix, but exposed that the managed model could not switch back: Steam's in-stream session-select is a silent no-op while the display manager is stopped (every config-write branch in os-session-select requires the DM to be running), so the capture loss it causes just relaunched game mode. The user pass of the switch script does leave one durable trace — the ~/.config/steamos-session-select sentinel, written before any DM check. The managed launch now baselines its mtime; a capture loss with the sentinel advanced reads as the switch request and is honored by replaying the switch with the DM up: restore the display manager, run the distro's own os-session-select (its internal pkexec is authorized allow_any by the distro policy, so it works from the host's sessionless context), then stop the autologin game-mode unit so Relogin lands in the newly selected desktop. The capture-loss re-detection then follows KWin as it comes up; a 120 s post-honor grace stops the rebuild loop from racing the booting desktop back into game mode (superseded early if the box's own game-mode unit reappears — the desktop→game leg stays fast). The baseline is re-recorded on crash-restore so a pre-existing sentinel never reads as a fresh request. Every verb in the sequence was live-validated on the Nobara repro VM. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 11:49:24 +02:00
enricobuehlerandClaude Fable 5	e35dad529b	fix(vdisplay/gamescope): DM-flavor-aware session takeover — stop masking Nobara's plasmalogin to death ... Field report (Nobara 43 HTPC): switching the host to Steam Game Mode mid-stream permanently black-screened the box. Live-proven root cause on a Nobara repro VM: our takeover masks the box's gamescope-session-plus unit, plasmalogin's Relogin=true then fails its session Exec repeatedly and trips systemd's start limit within ~1 s — the display manager dies, and our restore verb (unmask + user start) cannot bring a seatless gamescope back. Only 'reset-failed + restart' of the DM recovers. The takeover is now display-manager-flavor-aware: - SDDM (Bazzite/SteamOS) keeps the proven mask+SIGKILL path unchanged. - plasmalogin/unknown DMs never mask: with privilege (root or an operator polkit rule scoped to the DM unit — documented) the host stops the DM for the stream and restores it with reset-failed + restart (PUNKTFUNK_RECOVER_SESSION_CMD as fallback), recorded in the persisted takeover state so a host crash still restores; without privilege the managed takeover degrades to ATTACH and mirrors the box's live Game Mode instead of destabilizing the seat. Both legs of the privileged cycle live-verified on the repro VM (headless managed session works with zero login sessions; render nodes are 0666). A loaded-but-inactive leftover instance never triggers the DM stop. Companion fixes from the same triage: - ensure_box_gamescope_mode gains the attach-only rebuild-probe guard both managed paths already had (stale post-capture-loss detection restarted the box's unit), and no longer re-modes a box that drives a physical display — attach mirrors on-glass; re-mode is the headless-box model. - Capture-loss rebuilds targeting gamescope get a 100 s budget: the 40 s budget expired inside the first 45 s Steam-cold-start launch attempt, a guaranteed single-shot failure. - A PUNKTFUNK_COMPOSITOR pin now WARNs once per capture loss when the live session no longer matches it (the pin disables session-following — the reporter's original stream-death trigger). - A managed session that took nothing over (client gamescope pin beside a live desktop) is stopped on disconnect instead of being orphaned forever. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 11:49:24 +02:00
enricobuehlerandClaude Fable 5	9b241d9d7b	fix(pf-win-display): anchor the kept sources at the desktop origin when isolating ... Round 3 of the field-reported exclusive-topology 0x57, with the reporter's retest logs finally separating the variable: the SAME isolate call converged rc=0 whenever a kept member already sat at (0,0), and failed 0x57 on every shape — doomed-path-carried AND keep-only escalation — whenever the doomed physical held the origin. A committable config must still contain a primary (a source pinned exactly at (0,0)); deactivating the display that held it while the kept virtual stays at its EXTEND offset supplies an origin-less desktop, which Windows rejects wholesale. Translate the kept sources rigidly so the top-left-most lands on the origin; sets already covering (0,0) are untouched so plain re-commits stay byte-identical. Also from the same logs: - restore_displays_ccd now guarantees the desk is never left all-dark: the saved snapshot can be unappliable (0x64a — it pinned a virtual target incarnation removed before teardown) or apply cleanly yet re-light nothing (snapshotted while an earlier failed teardown had the physicals off). If no external physical is active after the apply while one is connected, fall back to the database EXTEND preset. Internal panels don't count — a closed lid must not be forced back on. - the final isolate failure now names the surviving targets instead of asserting 'a non-virtual display stayed active' — the logs showed a sibling VIRTUAL display as the survivor (linger-expiry shrink), and the wording sent triage the wrong way. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 10:21:47 +02:00
enricobuehlerandClaude Opus 4.8	ebddffa4c8	chore(release): bump workspace version to 0.19.1 ... An all-fixes patch on top of 0.19.0. The headline is session teardown — the native stop flag made enforceable and bounded (ac3dc432) and GameStream ending on the control peer's ENet disconnect (41fa25c4), so a session can no longer outlive the client that started it on either plane. Also: the Windows input-desktop pair (display writes b5fa878b + pen/touch injection 24a24734 both surviving a UAC prompt), the Apple display-sleep guard (bc5f6a38), the gamescope corner-parked cursor (4b2d2d1e), the KWin custom-mode selection (3a33a694), the tvOS glob warnings (cc8cccbe), and the Linux starter/env docs revamp (66172753). Nothing moved on the wire (protocol 2) or at the C ABI (13), so no embedder rebuild and 0.18/0.19 peers keep mixing freely. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 02:15:40 +02:00
enricobuehlerandClaude Fable 5	cc8cccbee6	fix(core/client): drop two redundant glob imports that warned on tvOS ... `punktfunk-core` emitted `unused import: super::super::*` for client/pump/handshake.rs and client/pump/input_task.rs — but only when built for a tvOS target, where the cfg set leaves the glob contributing nothing. Nobody saw them because CI never builds tvOS: that needs BUILD_TVOS=1 and the Tier-3 build-std nightly path, and the Apple workflow only runs swift build/test (macOS). Both files also `use super::*`, i.e. the parent `pump` module, which itself globs `super::*` (`client`) unconditionally — so every name stays reachable by that path and the inner glob was pure duplication. Their sibling datagram_task.rs already imports only `use super::*`, so this also makes the module consistent. control_task.rs and data.rs keep theirs: those genuinely resolve names through it and never warned. Verified warning-free AND compiling on every slice the xcframework ships — aarch64/x86_64-apple-darwin, aarch64-apple-ios, aarch64-apple-ios-sim, aarch64-apple-tvos, aarch64-apple-tvos-sim, x86_64-apple-tvos — plus Linux with and without the `quic` feature. A full xcframework rebuild now reports 0 warnings (was 6: two per tvOS slice), and swift build, swift test (170 tests), and xcodebuild for the macOS, iOS and tvOS schemes all pass. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 02:11:49 +02:00
enricobuehlerandClaude Fable 5	ac3dc4323f	fix(native/session): make the stop flag enforceable so a session can't outlive its client ... Native sessions could survive long after the client was gone, in two independent ways. HOST: `stop` was only advisory. The one thing that ends a session is the stream thread returning — every teardown (conn.close, the joins, and the RAII drops of the session permit, admission entry and stream marker) sits after that await, and nothing forced the issue. The encode loop checks `stop` between iterations, so any unbounded call INSIDE one never reaches the check, and one stuck syscall became a permanent zombie: it held its semaphore slot (four of those and the host stops accepting QUIC entirely), its admission entry (a later client gets "host busy" forever), and not even the console's Stop button could clear it — that button sets this same flag. * Bound the wait: once the session has been told to stop, the thread gets STREAM_STOP_GRACE (90 s, well past the 40 s capture-rebuild budget) to return, then teardown runs anyway. The thread is detached, not killed — Rust can't cancel a blocking thread — so it keeps its capturer/encoder until the stuck call returns, but the session's slot and admission entry come back and the host keeps serving. It logs at ERROR as the host wedge it is. * Bound the audio/input joins too — the last unbounded await in teardown. * Take the session permit AFTER the QUIC handshake instead of before `accept()`, so a host at its concurrency cap still accepts and the waiting client sees a live path instead of a silent dial timeout. * Bound the compositor helpers that caused the wedge in the first place: new pf-vdisplay `proc::{status_within, output_within}` kill a child that outlives its budget. `kscreen-doctor` is a Wayland client of the very compositor it configures, so against a wedged KWin it never returned; same for systemctl/dbus against a stuck session bus. CLIENTS: the connection was never closed, so the host was right to keep the session — it still had a live, keep-alive-answering peer. * Android: backgrounding did no teardown at all, and Android doesn't suspend the process, so the worker kept answering keep-alives until the OS reclaimed it (on a TV box, never). End the session on ON_STOP, via the existing onDispose path; a plain close, not a quit, so the host lingers the display for a fast return. * Apple: the .background arm was iOS-only AND gated on an opt-in that defaults off, so backgrounding did nothing — while the `audio` background mode kept the app (and its connection) alive indefinitely. Act unconditionally, and cover tvOS. * Core: `conn.close()` only queues the frame, and run_pump is the body of a block_on whose runtime is dropped the instant it returns, so the driver could never put it on the wire — a deliberate quit reached the host as silence (8 s idle timeout, no quit code, and the linger meant for an unwanted disconnect). Carry the endpoint out of the handshake and flush with wait_idle(), the same discipline the pairing and probe paths already use. Linux check/clippy/tests green: 262 host, 71 pf-vdisplay (incl. new bounded-process tests), 231 core. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 02:11:49 +02:00
enricobuehlerandClaude Fable 5	41fa25c440	fix(gamestream/session): end the session when the client disconnects or vanishes ... GameStream sessions outlived their client: the only complete teardowns were the explicit ones (RTSP TEARDOWN, nvhttp /cancel, mgmt DELETE /session), and the only automatic detector was a media-UDP send error — which needs an ICMP port-unreachable, so a true vanish (Wi-Fi drop, sleep, power off, crash) left video+audio encoding into the void forever, and even a plain Moonlight quit (which sends neither TEARDOWN nor /cancel) leaked the session. The stale state then cascaded: a lingering launch 503-blocked a different client under mode_conflict=reject, and streaming=true made a reconnect's PLAY take its "stream already running" branch — no new threads, old threads still aimed at the dead endpoint, the reconnect got no media. ENet already detects all of this — the control peer's reliable-ping timeout (or clean disconnect) fires Event::Disconnect within ~5-30 s — but the handler only reset input state. Wire the real teardown into it: * AppState::end_session — THE compat-plane session teardown: stops both media threads (their flags), clears launch + negotiated stream config; idempotent. /cancel and mgmt stop_session now share it. * control.rs Disconnect → end_session. Gated on the TRACKED session peer, and Connect only tracks a peer from the /launch owner's IP (the same source-IP bind the RTSP/media plane uses), so an unauthenticated LAN peer connect+disconnect can't end a live session, and a fast reconnect's stale-peer timeout can't kill its successor. * Client-unreachable UDP send errors now end the whole session via an OnSessionLost callback (built at PLAY) instead of stopping only the plane that noticed — audio no longer keeps streaming after video detects the dead client, and vice versa. Linux check/clippy/tests green (53 gamestream tests incl. the new end_session regression test). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 02:10:23 +02:00
enricobuehlerandClaude Opus 4.8	3a33a69401	fix(kwin): select the custom mode KWin actually built, not the one we asked for ... A KDE host streaming to a phone-shaped client fell back to 60 Hz even though the 120 Hz mode was sitting right there in KDE's display list, one manual click away. KWin generates every custom mode's timing with libxcvt, whose first step is `hdisplay_rnd = hdisplay - (hdisplay % 8)`. A 2868x1320@120 request (iPhone 16 Pro Max) therefore becomes 2864x1320@119.92 — 4 px narrower, fractional refresh. We then asked kscreen-doctor for `mode.2868x1320@120`; its `findMode` matches a mode's id or its own `WxH@qRound(Hz)` name, so that string matched nothing, the select silently no-op'd, the output stayed on its sacrificial birth mode, and `size_applied` came back false → "KWin rejected the custom mode" → 60 Hz. Widths like 1920/2560/3840 are all multiples of 8, which is why only clients with phone-shaped panels ever hit this. Resolve the mode out of the output's OWN list instead and address it by kscreen mode id: exact height, width at most one cell narrower than asked, refresh within 1 Hz (which excludes the native 60 Hz entry). `set_custom_refresh` now returns the whole achieved mode, and `create` reports that as the output's `preferred_mode` — so the capturer's renegotiation gate waits for the size KWin will actually deliver and the encoder opens against it, rather than starving on the requested one. Also skip `addCustomMode` when a usable mode is already installed: kscreen-doctor APPENDS to the list and KWin persists it per output name, so the old code grew the user's display list by one entry per connect. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 00:55:36 +02:00
enricobuehlerandClaude Opus 4.8	24a24734eb	fix(inject/windows): follow the input desktop for pen + touch injection ... Same field report as the display-write fix, other half of the symptom: with a UAC consent prompt up — one the user could SEE in the stream, because capture already renders the secure desktop (326d6e17) — pen and touch did nothing, while mouse and keyboard kept working. The split was exactly which paths knew the input desktop can move. sendinput.rs reattaches, so mouse/keyboard reached the prompt. pointer_windows.rs had no desktop handling at all, so every InjectSyntheticPointerInput came back ERROR_ACCESS_DENIED: 22:20:31 virtual pen created (PT_PEN) 22:20:31 pen inject failed error=Zugriff verweigert (0x80070005) 22:20:42 touch inject failed error=Zugriff verweigert (0x80070005) contacts=1 Measured on glass before fixing, to find out what it actually takes: device on Default, thread on Default -> 0x80070005 (the field failure) device on Default, thread on INPUT -> OK device on INPUT, thread on INPUT -> OK The middle row is load-bearing: the synthetic pointer device is NOT desktop-affine, so rebinding the thread suffices and the device is never destroyed and recreated across a desktop switch — which would have dropped in-flight contacts and the pen's in-range state mid-stroke. Injection now retries once bound to the input desktop. The binding is scoped, not persistent like sendinput's: inject_pen/inject_touch_frame run on TWO threads (the caller's apply_batch and the refresh threads), and the batch caller is a shared task thread that must not be left parked on a Winlogon desktop that disappears when the prompt is dismissed. The first-failure WARN now carries the rejected sample (flags, pen flags/mask, pressure, rotation, tilt, position). A 0x80070057 INVALID_PARAMETER was seen once BEFORE any prompt existed and is still unexplained; the ranges all look sound on inspection (coordinates clamped to the virtual screen, roll/azimuth u16 so the modulo cannot go negative, tilt bounded 0..=90), so catching the actual offending sample is the way to find it. Verified on glass: with a consent prompt up, pen and touch now reach it — zero inject failures where every prior session failed immediately. A UAC prompt can now be dismissed from an iPad with the Pencil. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 00:36:51 +02:00
enricobuehlerandClaude Opus 4.8	b5fa878bc6	fix(pf-win-display): follow the input desktop so a UAC prompt can't refuse display writes ... Field-reported 2026-07-23: a consent prompt left up on an unattended host made the box unreachable. Every connect black-screened and failed after ~60 s, and the host had to be reached over SSH to clear the prompt. Windows refuses ChangeDisplaySettingsEx/SetDisplayConfig issued from a thread that is not on the desktop currently receiving input. While UAC (or the lock / logon screen) is up that desktop is Winlogon, and the host — which the service launches explicitly onto WinSta0\Default — got DISP_CHANGE_FAILED / ERROR_ACCESS_DENIED for every write. A session starting in that window could never set its virtual display's mode, so the capturer sized its ring to a stale mode, every composed frame was dropped for a size mismatch, and bring-up burned 8 retries before giving up. Measured on glass (RTX box, SYSTEM host in console session 2, real consent prompt up, virtual display active): INPUT desktop = Winlogon UNBOUND CDS_TEST -> -1 (DISP_CHANGE_FAILED) UNBOUND SDC_VALIDATE -> 0x5 (ERROR_ACCESS_DENIED) BOUND CDS_TEST -> 0 (DISP_CHANGE_SUCCESSFUL) BOUND SDC_VALIDATE -> 0x0 (ERROR_SUCCESS) New input_desktop.rs mirrors pf-inject's sendinput.rs retry model: issue the write, and only when it fails the way a wrong-desktop write fails, rebind this thread to the current input desktop and retry once. A working write is never touched, so the normal path is unchanged. The retry predicate stays narrow (ERROR_ACCESS_DENIED only) so the unrelated 0x57 exclusive-mode topology bug is not re-issued and mis-attributed. Unlike sendinput's dedicated injector thread, the binding here is SCOPED — a shared display-write thread left on a Winlogon desktop that is later destroyed would fail every subsequent write, which is the wedge this removes. Applied to all eight SetDisplayConfig sites and both ChangeDisplaySettingsExW calls in set_active_mode. The isolate site now decides its supplied config once, outside the write, so a retry re-issues the identical config rather than logging its escalation twice. A save is logged, because a silent one is indistinguishable in a field log from a write that never needed saving — which made the first on-glass verification of this change inconclusive. Both ACCESS_DENIED diagnostics now ask which cause applies instead of naming only the disconnected-RDP one: that phrasing sent this investigation chasing a phantom RDP session on a host that was already service-launched in the console session, while a consent prompt was the actual cause. Verified on glass: connect with a consent prompt up now reaches first frame in 3.0 s (was a black screen then "Connection failed" after ~60 s), with six "retried bound to it and it applied desktop=Winlogon" lines and rc=0x0 throughout. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 00:36:51 +02:00
enricobuehler	4b2d2d1e14	fix(gamescope/cursor): follow gamescope's own cursor verdict — the corner-parked pointer ... gamescope hides its pointer by WARPING the X pointer to the root's bottom-right corner pixel; it does not swap in a transparent X cursor, so XFixesGetCursorImage keeps handing back the last opaque arrow. The XFixes source picked its display by "whichever pointer moved", and a parked pointer never moves again — so it froze on the parked Xwayland and composited that arrow at (w-1, h-1): a sliver of cursor welded to the corner of the stream for the rest of the session while the real pointer went undrawn. Reported on-glass in every game (a game grabs the pointer, so the hide is permanent): "part of cursor shows up on bottom right ... isn't where it really is". Follow GAMESCOPE_CURSOR_VISIBLE_FEEDBACK instead — gamescope publishes it on every nested Xwayland root: 1 on the server whose pointer it is drawing, 0 on the others and 0 on all of them once the pointer is hidden. It answers both questions correctly for a STATIC pointer, which motion cannot: which Xwayland owns it, and whether to draw it at all. Read at connect, re-read on its root PropertyNotify (event drain now discriminates CursorNotify vs PropertyNotify) with a 250 ms resync as the self-heal. A pointer gamescope draws nowhere is published visible:false, not dropped — the encode loop overwrites the frame's overlay from this slot and strips invisible ones, so a None would leave the last visible overlay standing on repeat frames. Honouring the atom also gives the stream gamescope's own idle auto-hide, which this source never had. The pointer-motion heuristic stays as the fallback for a gamescope that publishes no verdict (logged at session start via cursor_feedback=false), so nothing regresses to a cursorless stream. Measured on a live 1920x1080 Steam Gaming Mode session (RTX 5070 Ti, gamescope c31743d+, --xwayland-count 2 --hide-cursor-delay 3000): idle 3 s => pointer (1919,1079) + feedback 0; real evdev motion => pointer live + feedback 1. End-to-end against that session the source now publishes visible=false while parked and tracks the live pointer within one 250 ms sample of motion. cargo clippy -p pf-capture --lib -D warnings and the 5 new pick_active tests are green at cargo 1.96.1 (CI parity); cargo fmt --all --check clean.	2026-07-24 00:31:55 +02:00
enricobuehlerandClaude Opus 4.8	bc5f6a3881	fix(apple/session): keep the display awake for the length of a session ... A stream is not user activity to the OS, and controller input does not feed the HID idle timer on any Apple platform — so a gamepad-only session reliably idles the panel out from under the user mid-play. A keyboard/mouse capture session masks the bug because those events are real local HID. The Android client has held FLAG_KEEP_SCREEN_ON while streaming all along; the Apple clients held nothing. DisplaySleepGuard is acquired in beginStreaming and released at the top of disconnect, so it is scoped to the session — every teardown path (user quit, sessionEnded, the backgrounded keep-alive timeout) funnels through disconnect. iOS/iPadOS/tvOS: UIApplication.isIdleTimerDisabled. App-wide and ignored while backgrounded, which is what the audio-only keep-alive wants. macOS: ProcessInfo.beginActivity(.userInitiated, .idleDisplaySleepDisabled), the Foundation wrapper over IOKit power assertions. That defers display sleep but NOT the screen saver, which runs off the HID idle timer independently — so a 30 s IOPMAssertionDeclareUserActivity heartbeat runs alongside it. Intended side effect: an idle-lock that follows the screen saver is deferred for the session too. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 00:00:55 +02:00
enricobuehlerandClaude Fable 5	6617275387	docs(env): stop teaching the compositor pin + uid-1000 anchors in starters ... Field triage (Nobara, Discord): the kde.md starter host.env told desktop users to set PUNKTFUNK_COMPOSITOR=kwin, which PINS the backend — detect() short-circuits and the capture-loss rebuild never re-detects — so a mid-stream switch to Game Mode killed the stream instead of following it. A follow-up hardcoded XDG_RUNTIME_DIR=/run/user/1000 anchor broke PipeWire for any non-1000 uid (pw audio connect: Creation failed). Revamp across every starter/example/reference: - Desktop starters (kde/gnome/hyprland/sway) shrink to PUNKTFUNK_VIDEO_SOURCE=virtual + an explicit warning that pinning disables session-following; forcing a backend is CI/appliance-only. - host.env.example: rewritten around auto-detection; anchors demoted to a commented ssh/cron-only block with the uid trap spelled out; the gamescope ATTACH/MANAGED knobs documented (previously missing); case-sensitivity called out. - packaging/bazzite/host.env + README: drop the uid-1000 anchors (a systemctl --user service inherits/derives them); README's stale PUNKTFUNK_COMPOSITOR=gamescope-era template synced to the real one. - packaging/kde/host.env: loud APPLIANCE-ONLY header (it pins on purpose). - configuration.md: session-anchors section inverted to "leave unset", compositor row states the pin consequence, case-sensitivity note. - troubleshooting.md: new "session fails right after editing host.env" section (case, wrong-uid anchors, stale pin, restart-to-apply). - gamescope.md/bazzite.md: attach/managed descriptions match current behavior (managed is the infra-detected default; attach re-modes a box-owned session to the client's resolution). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 22:42:59 +02:00
enricobuehlerandClaude Opus 4.8	bda015b101	docs(release): rewrite v0.19.0 notes for end users + set end-user notes voice ... Release notes were written for the people who build Punktfunk, not the people who use it — dense with protocol/ABI/type names that confused even technical readers. Rewrite v0.19.0 in a benefit-first, plain-language voice (New/Improved/Fixed) with all internal terms removed from the body and every protocol/ABI/embedder detail moved to a single bottom "Under the hood" section. docs/releases/README.md now codifies this voice as the format spec for all future notes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 20:15:08 +02:00
enricobuehlerandClaude Opus 4.8	ec219763a6	fix(ci/release): make _release_notes_path POSIX-sh safe (deb/decky attach runs under dash) ... The v0.19.0 deb + decky release-attach steps source gitea-release.sh under `sh` (dash) and died with "Bad substitution" at _release_notes_path's `${BASH_SOURCE[0]:-$0}` — a bash array subscript dash rejects. So those legs never attached their assets to the release (the bash legs — apple, android, rpm — were fine, which is why the body still seeded and the DMG/.ipa attached). CI always sources this from the repo root, so resolve the notes as docs/releases/<tag>.md relative to CWD and drop $BASH_SOURCE entirely. Verified under dash. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 19:03:01 +02:00
enricobuehlerandClaude Opus 4.8	0dce1cd116	chore(release): bump workspace version to 0.19.0 ... Headline: the whole pen/tablet input stack (P0–P5) — a pressure-sensitive stylus plane across core wire, Linux, GameStream/Moonlight, Windows, iPad Pencil and Android. Plus touch-injection fixes, cursor-DPI scaling, three Windows-host display/cursor fixes, a gamepad same-PID conflict fix, and the Android mouse/keyboard (TV) regressions. Release notes authored in-repo at docs/releases/v0.19.0.md (first release on the new flow; CI seeds the release body from it). cargo update --workspace syncs the lock (versions only). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 18:26:49 +02:00
enricobuehlerandClaude Opus 4.8	c3c0115a82	fix(core/abi): bump ABI_VERSION to 13 for punktfunk_connection_send_pen ... The pen P0 work added a new embeddable C entry point (punktfunk_connection_send_pen) but left ABI_VERSION at 12 — the value 0.18.0 shipped. Per the project's convention (0.18.0 bumped to 12 for the additive cursor channel), additive C-surface growth bumps the ABI so embedders can gate on the new symbol. Regenerated include/punktfunk_core.h via cbindgen (cargo build -p punktfunk-core); WIRE_VERSION is unchanged (pen is capability-gated on HOST_CAP_PEN). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 18:23:38 +02:00
enricobuehlerandClaude Opus 4.8	00c8c12a0f	feat(ci/apple): export the iOS .ipa to the release + run artifacts ... The iOS leg archives with development signing and re-signs for App Store distribution at export time, but the existing export uses destination=upload (straight to TestFlight) and leaves no .ipa on disk. Add an export step that re-exports the SAME archive with destination=export to produce an App Store distribution-signed .ipa, then: * attach it as the `punktfunk-ios-ipa` run artifact on every build (upload-artifact@v3, since Gitea's backend rejects @v4), and * attach it to the unified Gitea release on vX.Y.Z tags (alongside the DMG), via the shared ensure_release/upsert_asset helpers. Same gate as the archive; warn+skip (never fails the best-effort iOS leg) if the archive is absent. Note: an App Store-signed .ipa installs only via TestFlight/App Store, not by direct sideload — it is a release/archival artifact. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 18:18:45 +02:00
enricobuehlerandClaude Fable 5	988b5742ec	fix(gamestream): tolerate NaN pressureOrDistance — VoidLink's finger touches were dropped whole ... The hex dumps from the on-glass session show textbook SS_TOUCH packets with pressureOrDistance = 0x7fc00000 (NaN): VoidLink encodes 'unknown finger pressure' as NaN (iPad fingers have no force sensor), and the anti-forgery finiteness gate rejected the entire packet — silently disabling the touch plane while pen (real Pencil force, always finite) worked. Coordinates keep the strict gate (they feed injector scaling); pressureOrDistance now sanitizes non-finite to 0.0, the spec's own 'unknown', which the pen path already maps to full-scale ink on contact. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 17:48:17 +02:00
enricobuehlerandClaude Fable 5	f938174d86	debug(gamestream): hex-dump the first few undecodable pointer packets ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 17:48:17 +02:00
enricobuehlerandClaude Fable 5	40611cd54d	debug(gamestream): surface the pointer plane's silent failure modes ... An on-glass 'touch does nothing' currently leaves NO trace: log the first SS_TOUCH per session at info (proves the client sends + we decode), and warn when a packet carrying a pointer magic fails the body parse (layout mismatch) instead of vanishing into the unknown-magic drop. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 17:48:17 +02:00