33 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Opus 5	6a9b3b0f28	fix(windows/cursor): a re-rendered pointer keeps its handle — re-probe the extent ... The GDI shape poller rasterises only when the HCURSOR VALUE changes. But Windows rebuilds the system cursors at a new size whenever the display scale under the pointer changes, and it does that behind a handle that never moves — the shared arrow is 0x10003 for the whole session. So the cache latched whatever size the pointer happened to have when the poller started and never let go. That window is not rare, it is the norm: a fresh virtual display is created at Windows' RECOMMENDED scale and only picks up the client's saved PerMonitorSettings override a beat later, while the poller starts within a second of the monitor appearing. Sample inside it and the session forwarded — and composited — a 96 px pointer over a 100 % desktop for its entire life, which reads on the client as a pointer 3x too large while every other thing on the streamed desktop is correctly sized. Scaling on the client cannot undo it: the bitmap is proportional to the video, it is just proportional to the WRONG scale. Re-read the bitmap's extent on a slow cadence whenever the handle is unchanged — dimensions only, no pixel copy, 4 Hz — and drop the cache when it moved, so the next tick re-rasterises and publishes a new serial. Observing the extent itself rather than a DPI proxy also covers the accessibility pointer-size slider and any other cause of a same-handle re-render. Windows-side clippy -D warnings green via scripts/wincheck.sh; on-glass owed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 13:22:53 +02:00
enricobuehlerandClaude Opus 5	14914bc72f	test(pf-capture): the suite the splits enable — 38 Linux + 19 Windows tests (Phase 6) ... The plan's priority order was "every producer- or OS-controlled parser, blend, geometry guard or negotiation decision", none of which had a test before this sweep (X3). Phase 5's splits are what made most of them reachable without a compositor or a driver. **6.1 `bitmap_extent`** — extracted from `update_cursor_meta`, which is the guard whose own SAFETY proof says a missing bound "SIGSEGVs inside the PipeWire `.process` callback (a segfault `catch_unwind` cannot catch)". Every input except the region size is producer-written. 5 tests: a bitmap that fits (with and without header/pixel offsets); the last-row rule (`stride·(bh−1) + row`, so a bitmap ending flush against the region is accepted rather than rejected by padding that is never read — and one byte short is rejected); anything past the region; degenerate geometry; and four distinct overflow vectors including the near-`i32::MAX` stride the SAFETY comment calls out. One assertion I first wrote was wrong, not the code — with a single row `stride·0 == 0`, so even a `usize::MAX`-wide row is arithmetically in range; the test now exercises the ≥2-row case that really overflows and says why the other is fine (the caller has already capped `bw` at 1024). **6.2 the composite blits** — 8 tests over `composite_cursor` / `composite_cursor_rgb10`: every packed `PixelFormat` arm lands the colour in its OWN channels (so a byte-order slip cannot pass); clipping off all four edges plus six fully-outside positions; zero-alpha, `visible: false` and no-bitmap-yet all drawing nothing; the integer alpha blend; NV12/Yuv444 declined rather than mis-blitted; and for the 10-bit path a bit-exact round trip of an untouched pixel (including the two alpha bits the repack must preserve), the R-at-bit-20 vs R-at-bit-0 distinction between `X2Rgb10` and `X2Bgr10`, and the same clipping. Plus `decode_bitmap_pixel`'s four byte orders. **6.4 the pod builders** — 4 tests. The `dataType` bitmask is pinned per Buffers pod, because each bit is load-bearing in a different direction: the mappable pod MUST include DmaBuf (or gamescope's modifier-bearing format pod wins and the buffer intersection is empty — a link silently stuck in "negotiating"), the SHM-only pod MUST exclude it (or Mutter hands dmabufs and the race-free download path is not), and the dmabuf pod MUST exclude the mappable types (or an HDR session can be handed a MemFd buffer, which Mutter paints 8-bit ARGB32 regardless of the negotiated 10-bit format). Also: every pod parses back through `Pod::from_bytes`; the HDR pods carry MANDATORY PQ + BT.2020 + LINEAR-modifier; and only the NV12 offer pins the colour matrix/range. The `dataType` reader parses the SPA property layout literally (`key, flags, size, type, value`) — a "find the first plausible-looking int" heuristic read the `size` word, which is also 4, and reported the wrong mask. **6.5 `FrameToken` generation masking (W14)** — 2 tests, with `IDD_GENERATION` parked two below the 24-bit boundary so the WRAP is what gets exercised: every minted generation is non-zero, fits the token's field, and survives the pack/unpack round trip `try_consume` performs; and the cleared- `latest` 0 sentinel never matches a live generation. **6.6 the cursor conversion (Windows)** — `convert`'s pixel logic extracted from its GDI plumbing into `mono_planes_to_rgba` / `apply_and_mask_alpha` / `alpha_is_empty`, which is what makes it testable at all (the caller needs a live `HCURSOR` and a screen DC). 6 tests: the four-state AND/XOR truth table in one row; transparency surviving without an invert neighbour; the invert outline covering all eight neighbours, overwriting only TRANSPARENT ones, and clipping at the edges; the alpha-less colour cursor taking alpha from the AND mask; and a short mask not panicking. **6.3 / 6.7** landed with the fixes they guard (`negotiation_plan` in 2.3, `f32_to_f16` in 3.5). 38 Linux tests, up from 6 at the start of the sweep — ci.yml already runs them. 19 `#[test]`s on the Windows side; Phase 0.1's `--all-targets` lint type-checks them all, but note it does not RUN them (the workflow lints only), so the Windows ones execute on a Windows box. clippy --all-targets clean on both targets. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 11:31:34 +02:00
enricobuehlerandClaude Opus 5	306f4a514d	refactor(pf-capture): structural splits + collapse the restated signal set (Phase 5) ... Refactors LAST, after every defect fix, so no behaviour change hides in a move diff — and so the newly-exposed review surface was already clean when it landed (the WP7 discipline). 28f8fc71's recorded trap (an inline `use super::X` inside a moved body silently changing meaning) was audited first: every `use super::` in the moved code is either at module level — where `super` still means `linux` — or inside a `mod tests` that moved with its parent. 5.1 `mod pipewire` → `linux/pipewire.rs`. It was 1,900 of that file's lines. `mod.rs` is a directory module, so a plain `mod pipewire;` resolves with no `#[path]`. 5.2 out of that, `linux/pw_pods.rs` (the 7 param-pod builders + `serialize_pod` + the PQ constant and its test) and `linux/pw_cursor.rs` (`CursorState`, `decode_bitmap_pixel`, `update_cursor_meta`, `dst_offsets`, both `composite_cursor*`). The pods are the crate's WIRE surface — a missing property is not a compile error but a link that stalls in `negotiating`; the cursor half is producer-driven and bounds-critical. Both are now pure enough to unit-test without a compositor, which is what Phase 6 needs. 5.3 `linux/portal.rs`: the ScreenCast/RemoteDesktop handshake, the cursor-mode choice and GNOME's BT.2100 probe — the async/tokio/zbus control plane, separated from the realtime half. Zero re-exports changed: `mod.rs` re-exports `gnome_hdr_monitor_active` at its old path. 5.4 `idd_push/open.rs` (the whole one-time construction path + `SharedObjectSa` + `AttachTexFail`) and `idd_push/compose_kick.rs`. Read `open.rs` when a session will not START and the parent when one stops flowing; the steady state stays with the parent by decision. Also moved the ~65-line stall REPORTING block out of `try_consume` (the hot loop) into `StallWatch::report`, taking its two correlation counters with it — they were capturer fields nothing else touched. 5.5 `windows/dxgi/selftest.rs`: `p010_reference`, both self-tests, `hdr_p010_convert_bars_on_luid`, `f32_to_f16` and the two test modules — the validation path, none of which runs in a session. The two `pub` entry points are re-exported, so `main.rs`'s subcommand and pf-encode's live e2e keep their paths. (An explicit `#[path]`, like `idd_push`'s children: this file is itself reached through a `#[path]`, so a bare `mod` would resolve to `windows/selftest.rs`.) 5.6 `CaptureSignals`. The seven shared flags/slots were created in `spawn_pipewire`, `_cb`-cloned one by one, passed as seven of `pipewire_thread`'s parameters, and then re-declared as fields on `PwHandles`, `PortalCapturer` AND `UserData` — the same list written four times, each with its own drifting copy of the doc comment. One `#[derive(Clone)]` struct instead (a refcount bump per field), which also makes it structurally obvious that producer and consumer share ONE set. And `CaptureOpts` for the four trailing `bool`s: four adjacent same-typed positional arguments are a silent-transposition footgun — swap `want_444` and `want_hdr` and it compiles, negotiates the wrong pod family, and surfaces as a black screen ten seconds later. 5.7 trait shape, targeted: `set_active(&self)` → `&mut self` (it took `&self` only because the flag happened to be an `Arc<AtomicBool>` — an implementation detail leaking into the contract); `capture_target_id` ⇒ `resize_output`'s pairing rule stated on both methods and in a cluster note; one-line cluster headers over the 13 methods. NOT done from 5.7: taking the gamescope targets as an `open_*` option instead of the trait method. It would put a Linux-only parameter on the cross-platform `open_virtual_output` and on the host's `capture_virtual_output` facade — a `#[cfg]`-shaped wart in two shared signatures to delete one already-`cfg`'d defaulted method whose lifecycle rule 2.5c had already made harmless. Wrong trade under 5.7's own "no churn for no defect fixed" principle. File sizes: `linux/mod.rs` 2,778 → 770 (target ≤900 ✓), `windows/dxgi.rs` 1,374 → 954, and `windows/idd_push.rs` 2,694 → 1,922. The last two miss the plan's ≤850/≤1,300 targets, which were computed against the ORIGINAL line counts — Phases 1–4 added several hundred lines of SAFETY proofs and defect rationale to exactly these files before the split. The moves themselves are the ones the plan specifies; closing the rest would mean inventing new splits it does not call for. Zero behaviour delta. pf-capture 20/20; workspace clippy --all-targets clean on Linux and on windows-msvc. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 11:25:39 +02:00
enricobuehlerandClaude Opus 5	530909a154	perf(pf-capture): take three per-frame costs off the Windows HDR hot path (Phase 4) ... **4.1 (W10) — the HDR convert allocated two views and mapped a constant buffer per frame, inside the ring slot's keyed-mutex hold.** So the driver's publisher sat blocked on that slot while the host created `CreateRenderTargetView`s and Mapped/Unmapped a 16-byte buffer whose contents never change. Both are lifetime-of-mode facts, not per-frame ones: - the two P010 plane RTVs now belong to the out-ring SLOT, built once in `ensure_out_ring` (`out_ring` becomes `Vec<OutSlot>`). A driver that rejects planar RTVs — the one hard requirement of this path — therefore fails at ring build, where such a failure belongs, instead of on the first frame. - `inv_src` becomes an IMMUTABLE constant buffer filled in `HdrP010Converter::new(device, w, h)`. The converter is already dropped by `recreate_ring` on every mode change, so it cannot go stale. This also deletes the `Map`'s silently-ignored failure: it could leave the chroma pass sampling at a garbage texel size with no error anywhere. **4.2 (W15) — `sdr_white_level_scale` ran inside the keyed-mutex hold too.** It is a CCD query that contends the display-config lock — precisely the contention `DescriptorPoller`'s doc says must stay off the frame path — and `prepare_blend_scratch` called it while holding the slot. Moved to `refresh_sdr_white_scale`, called at open and after each ring recreate (where the scratch is invalidated anyway). "Only on scratch rebuilds" is not the same as harmless when the thing being blocked is the producer. **4.3 (W11) — `VideoProcessorSetStreamAutoProcessingMode(vp, 0, false)`.** The comment claimed "no interpolation/auto-processing" while only setting the frame format; auto-processing's documented default is ENABLED, so vendor denoise/edge-enhancement was free to run inside every SDR `VideoProcessorBlt` — altering the pixels we encode and spending video-engine time on the desktop-capture hot path. Now actually disabled, with each call's purpose stated separately. **4.4 (the Linux CPU-path map cache) is deliberately NOT done.** The plan gates it on measurement ("measure first, and only if the CPU path still matters") and this box cannot measure a live capture session; it also needs a frame-buffer return path through `FramePayload::Cpu`, which is a larger change than the rest of this phase. Left for Phase 7's measured pass. Compile-verified for windows-msvc locally; pf-capture 20/20 on Linux; workspace clippy --all-targets clean on both targets. The GPU-capture check and the measured `cap_us` delta are owed to Phase 7.3. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 11:11:46 +02:00
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	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 Fable 5	326d6e17c8	fix(windows/capture): stand the IddCx hardware cursor down while the secure desktop is up ... 0.18.0 regression: UAC consent and Winlogon (lock/logon) stopped appearing in streams. The cursor channel's IddCx hardware-cursor declare — re-issued by the driver on every swap-chain assign — keeps the path out of the OS's software-cursor mode, which is the only mode the secure desktop renders through; DWM then never presents UAC/Winlogon into our swap-chain and the stream repeats the last normal-desktop frame for the whole interaction. The GDI cursor poller now classifies the input desktop on its reattach cadence (UOI_NAME != Default = secure, 250 ms cadence instead of 2 s), and the capturer edge-triggers the existing-but-unused proto-v6 IOCTL_SET_CURSOR_FORWARD flip: OFF at secure entry (the driver stops its per-assign re-declare; the host facade forces the same-mode re-commit that actualises the software-cursor default, under the vdisplay manager lock via the new force_recommit()), back ON at dismissal for channel sessions. Channel-session open resets the driver's persisted desired state to ON so a session that died mid-secure-desktop can't leave the next one adopting UNdeclared (the §8.6 cross-session composite trap); orderly teardown does the same. The flip closure is built for every Windows session — a channel-less session can reuse a driver monitor whose earlier-session cursor worker still re-declares, and NOT_FOUND from never-declared targets is ignored. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 14:13:15 +02:00
enricobuehlerandClaude Fable 5	7058647264	fix(vdisplay/capture): channel-less sessions composite the pointer on a sticky-declared target ... A declared IddCx hardware cursor is IRREVOCABLE for its OS target's life (§8.6), and the sticky exclusion survives monitor REMOVE→ADD because each client gets a STABLE target id — so once any desktop-mode session declared, every later pure-capture session on that target streamed a cursor-less desktop: DWM excluded the pointer, no channel forwarded it, no blend drew it (the exact no-regression gap §8.6's per-session cap gate cannot see). Driver: track every successful SetupHardwareCursor per target (DECLARED_TARGETS — scoped to the WUDFHost's life, exactly the sticky state's scope) and report it in a new AddReply::cursor_excluded tail field (dual-size discipline, both skews degrade cleanly; no proto bump). Host: the flag rides AddedMonitor → Monitor → WinCaptureTarget; a session WITHOUT the cursor channel on a flagged target forces composite mode in the IDD-push capturer — GDI poller + blend for the session's life, pinned on (set_cursor_forward cannot clear it: with no client drawing, un-compositing would erase the pointer entirely). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:47:53 +02:00
enricobuehlerandClaude Opus 4.8	c63ac48c9c	fix(windows/capture): actually QUERY the HDR SDR-white scale — the refresh block was silently dropped ... faad4b57 shipped the field, shader scale, and plumbing but the scripted edit inserting the sdr_white_level_scale() refresh in the scratch-rebuild arm matched nothing and silently no-op'd (no assert) — sdr_white_scale stayed at its 1.0 init, i.e. 80 nits, i.e. exactly the old dark cursor. Now queried on every scratch rebuild, with an info log of queried/applied so an HDR session shows what it uses. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	cecc059830	fix(windows/capture): 250 Hz cursor poll + HDR white-scale observability ... - The polled position is also the composite-blend position: at 16 ms a 240 fps session reused a stale position for ~4 consecutive frames and the composited pointer visibly stuttered against the video. 4 ms out-paces every session rate; a tick is one GetCursorInfo syscall. - Log the queried DISPLAYCONFIG_SDR_WHITE_LEVEL scale on each blend- scratch rebuild so an HDR session shows what is actually applied (the virtual display's own SDR-brightness setting is the suspect when the cursor still reads dark). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	d31d41b6b8	fix(windows/capture): match the HDR-composited cursor to the target's SDR white level ... sRGB→linear alone lands cursor-white at 80 nits (scRGB 1.0) while DWM composes the surrounding SDR desktop at the user's SDR-brightness setting (~200+ nits by default) — the cursor read visibly dark on HDR. Scale by DISPLAYCONFIG_SDR_WHITE_LEVEL (new win_display::sdr_white_level_scale, queried on blend-scratch rebuilds — the CCD query stays off the per-frame path). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	6e37da8b4e	fix(windows/capture): clippy unnecessary_lazy_evaluations in scratch build ... Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	0af280a793	feat(windows/capture): host-side cursor compositing for the capture model — the deterministic fix ... Root cause, proven on-glass across five driver builds: a declared IddCx hardware cursor is IRREVOCABLE. There is no un-declare DDI, the empty-caps re-setup is rejected INVALID_PARAMETER, and after a successful same-mode re-commit with the driver's re-declare provably suppressed (sticky per-target flag, zero re-setups logged) DWM still never composites the software cursor back into the monitor's frames. Every DWM-based composite flip is therefore unfixable. The composite (capture) model is now implemented in OUR pipeline: - the driver keeps its hardware cursor declared for the session's whole life (the state that works) — frames stay pointer-free always; - in composite mode try_consume routes the conversion through a blend scratch: slot copy + one alpha-blended quad of the GDI poller's shape at its polled position (CursorBlendPass — fullscreen-triangle VS with viewport placement, straight-alpha PS, sRGB→linear for FP16/HDR rings), covering all four convert paths (NV12, 4:4:4 copy, P010, PyroWave) GPU-side under the slot's keyed mutex; - pointer-only motion produces no driver publish (declared hw cursor), so try_consume REGENERATES from the last slot whenever the polled cursor state changes — the cursor moves on a static desktop at tick rate, without faking freshness for the stall/death watchdogs; - set_cursor_forward becomes purely host-internal state; the SET_CURSOR_FORWARD IOCTL machinery is no longer used by the host (driver keeps it, dormant) and its sender plumbing is removed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	b50e4767de	fix(windows/cursor-flip): flag + forced same-mode re-commit — the working un-declare ... The empty-caps un-declare is REJECTED by IddCx (STATUS_INVALID_PARAMETER, on-glass driver 9.9.0722.1407) — there is no un-declare DDI. The composite flip now works with the only lever the OS gives us: every mode COMMIT reverts the path to the software cursor, and the driver skips its per-commit re-declare while cursor_forward_on is off. So: - driver: disable stores the flag only (no DDI call); enable still declares immediately against the live worker's event. - host capturer: after a successful disable flip, force a same-mode re-commit (win_display::force_mode_reenumeration) — DWM composites the pointer from the very next commit; the swap-chain flap is the class the driver's preserved-publisher machinery already rides out. - state now survives re-arrivals end-to-end: the capturer caches the APPLIED state (cleared on every channel (re)delivery, which re-created driver entries need — their flag defaults to declared), and the stream loop re-applies every tick instead of edge-gating (steady-state cost: one Option compare). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	79d30fde64	fix(windows/capture): unsafe block for the extracted dup_into_public call ... Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	6a8df2ba97	fix(windows/cursor-flip): survive driver-side monitor re-arrival — flag-based flip + channel re-delivery ... On-glass (.173, match-window session): every window-size convergence re-creates the driver-side monitor (re-arrival resize / sibling-session slot churn), destroying the cursor worker the channel was delivered to — the flip then died NOT_FOUND (no entry with target_id ∧ worker) and the declared state was lost entirely. Driver: set_cursor_forward becomes STATE, not an edge on one monitor generation — find by target_id ∧ hw_cursor, store cursor_forward_on even without a live worker (it steers the next delivery/re-setup); declare/un-declare only when a worker exists. Channel delivery honors the flag: setup_and_spawn(declare=false) adopts + spawns WITHOUT declaring (composite mode), so a later enable-flip declares against the worker's event. Host: retain the SET_CURSOR_CHANNEL sender; extract deliver_cursor_channel and RE-deliver the surviving section on every ring recreate and — with one retry — when a flip IOCTL fails (the re-arrived entry gets a fresh worker, declared per its flag). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	92761813a9	feat(core+host+driver+client): mid-stream cursor-render flip — host composites in the capture model ... The cursor channel excluded the host pointer from the video for the whole session, but the client only draws it under the DESKTOP mouse model — flipping ⌃⌥⇧M to capture mid-stream left the session pointer-blind (user-found). The fix makes render ownership LIVE state: - wire: CursorRenderMode 0x51 (client→host, control stream) — client_draws: true = desktop model (host excludes + forwards), false = capture model / released (host composites, full fidelity — DWM on Windows incl. real XOR inversion, encoder blend on Linux). Sessions start client_draws=true (the pre-message behavior). - host: control task stores the flag; the encode loop edge-detects it — forwarding + frame.cursor strip while the client draws, quiet forwarder + overlay-into-blend while composited. SessionPlan now grants blend CAPABILITY wherever the capture has a pointer (dropping the !cursor_forward gate) so the composite side needs no encoder rebuild; per-tick frame.cursor decides what is drawn. - Windows: Capturer::set_cursor_forward → retained IOCTL_SET_CURSOR_FORWARD sender (proto v6) → driver (un)declares the IddCx hardware cursor on the LIVE monitor. Un-declare re-issues the setup with EMPTY caps (candidate mechanism — the DDI has no documented un-setup); resetup-on-commit is skipped while off, so a mode commit's software-cursor default is the fallback path. Failure against a pre-v6 driver logs and keeps declared-at-ADD behavior. - SDL client: one edge-detected reconciler at the cursor pump site — desktop-active = client draws; capture model or released = host composites. Covers the chord, the M3 auto-flip, and engage/release. - C ABI v12: punktfunk_connection_set_cursor_render (additive; wire version unchanged — pre-§8 hosts ignore the unknown message type). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	f2082f8b57	fix(windows/capture): drop redundant unsafe at the poller-spawn CCD call (inside open_on's unsafe region) ... Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	e59634a578	feat(windows/capture): GDI cursor-shape poller — masked/monochrome cursors for the cursor channel ... The M2c redesign (design/remote-desktop-sweep.md §8): the IddCx hardware- cursor query is alpha-only by design — IDDCX_CURSOR_SHAPE_TYPE has no monochrome value, the OS pre-converts monochrome to masked-color, and masked-color delivery is dead code on modern builds (proven on-glass at every ColorXorCursorSupport level). The driver keeps its hardware cursor declared (XOR FULL) purely so DWM excludes every cursor type from the IDD frame; the SHAPE now comes from a GDI poller in the capture host — which runs as SYSTEM inside the interactive session, so no helper process is needed. CursorPoller (idd_push/cursor_poll.rs, the RustDesk/WebRTC/OBS pattern): ~60 Hz GetCursorInfo on a dedicated thread; rasterise via CopyIcon→GetIconInfo→GetDIBits only when the HCURSOR value changes; monochrome via the WebRTC truth table with invert pixels as opaque black plus a white outline; AND-mask alpha for alpha-less color cursors; CURSOR_SUPPRESSED = hidden; per-output visibility via the target's desktop rect; per-monitor-V2 DPI awareness thread-scoped; input-desktop reattach on failure + 2 s cadence (GetCursorInfo on a stale desktop succeeds with stale data). Spawned iff the cursor channel was delivered; a live poller is the sole overlay source (no serial-namespace mixing) — the driver shm read remains as fallback if the poller dies. Not chosen: DXGI Desktop Duplication GetFramePointerShape — PointerPosition.Visible goes stale under injected-only input on current Win11 (Sunshine #5293, exactly our topology), it burns one of the session's four duplication slots, and IDD-output metadata has conflicting field reports. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Fable 5	3a34440a6b	feat(windows): IddCx hardware-cursor channel — remote-desktop sweep M2c ... Brings the cursor channel to Windows hosts. The pf-vdisplay driver declares an IddCx hardware cursor for sessions that negotiated cursor-forward — DWM then EXCLUDES the pointer from the IDD frame and delivers shape/position out-of-band, into the same CursorOverlay → forwarder → wire → client pipeline the Linux portal path uses. - pf-driver-proto v5 (additive, host floor stays 3): AddRequest's spare tail becomes hw_cursor (same size/offsets); IOCTL_SET_CURSOR_CHANNEL delivers a host-created CursorShm section (64-byte seqlock header + 256² shape buffer, layout pinned + tested). No event crosses the boundary — the host polls at encode-tick pace. - driver: wdk-iddcx grows the two cursor DDI wrappers; a per-monitor cursor worker (event wait → QueryHardwareCursor → seqlock publish) starts only when BOTH the ADD asked and the channel arrived, so a failed delivery leaves DWM compositing as today. Shape bytes ship raw (BGRA/masked + pitch); the host converts. - host: the section rides the existing sealed-channel broker (least- privilege dup, remote reap on failure); IddPushCapturer::cursor() seqlock-reads → CursorOverlay (BGRA→RGBA, masked-color approximation, desktop→frame origin shift, per-shape conversion cache). New Capturer::cursor() trait hook — the encode loop prefers it over the frame-attached overlay because hardware-cursor moves produce NO new frame on a static desktop. hw_cursor survives the re-arrival resize (carried on the manager's Monitor). - negotiation: cursor_forward grows the Windows arm (client cap ∧ driver proto ≥ 5, probed once via the control device); SessionPlan carries cursor_forward → OutputFormat.hw_cursor. - drive-by: wdk-probe's two pre-existing same-type casts (clippy) and pf-vdisplay's stale spike-test refs (crate::win_display moved to pf-win-display; tracing-subscriber was never a dep) repaired. Verified: proto tests on Mac AND MSVC (15/15 incl. the CursorShm layout pin); clippy -D warnings for proto/frame/capture/vdisplay/host on Linux (.21) and native Windows (.173); the DRIVER workspace clippy -D warnings green against the real WDK 10.0.26100 bindgen (DDI names, enum variants and IDARG layouts all bind). On-box driver deploy + on-glass validation follow. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Fable 5	428bd2519c	test(qsv): converter→ring-profile-P010→encoder live e2e (the RTV-written seam) ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-21 13:30:35 +02:00
enricobuehlerandClaude Fable 5	87d7eceabf	fix(encode/qsv): write the colour VUI unconditionally + Intel-lane colour diagnostics ... The native QSV encoder only attached mfxExtVideoSignalInfo on HDR sessions — an SDR stream carried no colour description at all (NVENC writes 709-limited unconditionally; qsv.rs now mirrors it). Diagnostics for the field-reported blue/magenta Intel-host colours: - hdr-p010-selftest takes an optional WxH + GPU vendor (intel|nvidia|amd) and prints which adapter it tested — 64x64 on the default GPU proved nothing on dual-GPU boxes, and the field heights (1080/1400) are not 16-aligned. - pf-capture: ignored live test running the converter at 1920x1080 pinned to the Intel adapter. - pf-encode: qsv_live_p010_1080_colorbars_dump — known P010 bars through the UNALIGNED-height ingest copy (1080 src -> align16 1088 pool, the seam no 640x480 test exercises) to Main10 HEVC, dumped for off-box decode checks. - dxgi.rs: drop the stale 'falls back to the R10 path' claim (no such path). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-21 13:30:35 +02:00
enricobuehler	dafab58943	Merge branch 'fix/round1-highs' into land/sweep-all	2026-07-20 00:42:38 +02:00
enricobuehlerandClaude Opus 4.8	fe4af1761e	fix(capture): stop stranding a PipeWire buffer on a caught panic; invalidate the PyroWave CSC on ring recreate ... Two medium findings from the round-1 sweep. - The `.process` callback dequeued a buffer INSIDE its `catch_unwind`, and every requeue site was inside too. `newest` is a raw pointer with no Drop, so any caught panic (update_cursor_meta / consume_frame) unwound past all three requeues and permanently stranded that buffer. Once the stream's fixed pool drained, `dequeue_raw_buffer` returned null every call and capture silently wedged while still reporting negotiated/active — defeating the very catch_unwind that was meant to keep a panic survivable. The drain loop now runs OUTSIDE the catch (dequeue/queue are non-panicking C FFI pointer ops) and `newest` is requeued exactly once after it, on every path: normal, corrupted-skip, or caught panic. - `recreate_ring` invalidated `video_conv` and `hdr_p010_conv` but not `pyro_conv`. That converter is mode-baked — BgraToYuvPlanes selects entirely different shaders and output formats for SDR (8-bit BT.709 → R8/R8G8) vs HDR (scRGB→PQ BT.2020 → R16/R16G16) — and `ensure_pyro_conv` only builds when None, so a display_hdr flip reused the stale SDR converter against a freshly HDR-formatted pyro ring, corrupting every frame. Reachable at the documented "Downgrade point D": a PyroWave session with client_10bit=true that opens on a box where HDR can't enable, then flips once the display comes up. Linux .21: pf-capture 1/0. Windows .173: `cargo check -p pf-capture` clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 23:16:25 +02:00
enricobuehlerandClaude Opus 4.8	b0fbb80fd5	fix(encode): key the PyroWave plane-import cache on the capturer's ring generation ... Completes the partial fix from the previous commit. The Windows PyroWave backend caches its imported plane images keyed on the D3D11 texture's COM address, and holds no reference on that texture — so once the capturer recreates its ring, those addresses can be handed straight back out by the allocator and a pointer-keyed cache hit returns an image bound to a texture that no longer exists. Adding the extent to the key ruled out same-address-different-size aliasing, but a recycle at identical dimensions still aliased. The capturer already tracks exactly the value needed: `generation`, bumped on every ring recreate. Plumbed it onto `PyroFrameShare` and the encoder now flushes every cached import when it changes, which makes cache identity independent of allocator behaviour rather than a bet against pointer reuse. Validated on the RTX box: `pyrowave_win_smoke` (forced with `--ignored`, the only test that actually exercises this path on real hardware) passes all ten configurations — 1024²/720p/1080p/1440p across SDR/HDR and 4:2:0/4:4:4 — with correct decoded chroma means, so the steady-state cache-hit path still works. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 21:45:14 +02:00
enricobuehlerandClaude Opus 4.8	3ae5f222d3	fix(hdr): honor SDR negotiation on the Windows host IDD-push path ... A Windows client with HDR off (video_caps=0) negotiates bit_depth=8, but the H.26x IDD-push capture composition FOLLOWED the virtual display's live "Use HDR" state rather than the negotiated depth. On a display whose advanced color was on — leftover from a prior 10-bit session on a reused monitor, the driver default, or the host's global toggle — the capturer emitted P010 and NVENC stamped HEVC Main10 + BT.2020 PQ from the pixel format alone (the in-band HDR upgrade). That 10-bit PQ stream reached a client that advertised SDR-only; on a client whose monitor is HDR-capable but has "Use HDR" off, the PQ landed on an SDR desktop and blew out. Make client_10bit authoritative for the composition depth on BOTH codecs, mirroring the PyroWave branch that already did this: * setup: force advanced color OFF for any !client_10bit session (was pyrowave-only), settling before the ring is sized; * display_hdr gates on client_10bit alone, so an SDR-negotiated session composes SDR even if a physical display forces HDR; * the descriptor poller re-asserts SDR against a mid-session "Use HDR" flip for any SDR-negotiated session (an HDR-negotiated H.26x session still follows flips both ways — its encoder re-inits on the depth change). Only Punktfunk's virtual display is touched, never the host's real desktop. Not yet on-glass; the client-side robustness fix (presenter should tone-map PQ on an SDR-mode display instead of taking an HDR10 swapchain) is a follow-up. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 10:01:17 +02:00
enricobuehlerandClaude Fable 5	188edde2b3	feat(pyrowave): Windows host HDR + 4:4:4, Rust client HDR present ... Phase 3 of design/pyrowave-444-hdr.md. A PyroWave session now negotiates HDR (10-bit) and 4:4:4 on a Windows host exactly like HEVC/AV1, and the Linux client presents it through the real HDR10 path. Host (Windows): BgraToYuvPlanes becomes mode-aware — SDR/BGRA and HDR/scRGB variants at half- or full-res chroma. The HDR passes reuse HdrP010Converter's exact colour math (scRGB -> PQ BT.2020 limited studio codes, verified by hdr_p010_selftest) but write P010-style MSB-packed codes into two separate shareable R16_UNORM/R16G16_UNORM textures; chroma keeps the pyrowave family's centre-sited 2x2 box. idd_push pins the composition to the NEGOTIATED depth (SDR sessions force advanced color off as before; 10-bit sessions enable it and ride the FP16 ring), and the descriptor poller re-asserts that state instead of following display flips the fixed-format encoder can't. The encoder imports 8/16-bit planes per session and stamps the sequence header's BT.2020/PQ/matrix bits on HDR (stamp_color_bits, extending 574e3e4e's range stamp); supports_10bit/can_encode_10bit/can_encode_444 gates open (HDR Windows-only — Linux capture has no HDR source). Client: the plane ring becomes R16_UNORM for 10-bit sessions (with a STORAGE_IMAGE format probe), the planar CSC pass joins the HDR10 swapchain rebuild (set_hdr_mode previously destroyed it without rebuilding — latent), st.hdr follows frame.color.is_pq(), and the planar push constants carry depth-10 MSB-packed rows + the PQ tonemap mode, identical to the NV12 arm. Verified: .173 (RTX 4090) deploy-config clippy + fmt + wire tests + the extended pyrowave_win_smoke (10-case {SDR,HDR}x{420,444} matrix incl. R16 imports and header stamps); .21 (RTX 5070 Ti) clippy across 4 crates, host 186 tests, client/presenter/encode tests, both Linux GPU smokes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-18 13:21:06 +02:00
enricobuehlerandClaude Opus 4.8	ebd9967547	feat(pyrowave): Windows host encoder — separate-plane zero-copy D3D11→Vulkan ... Wire PyroWave into the Windows host (design/pyrowave-windows-host-zerocopy.md). Before this a macOS client + Windows host that both selected PyroWave silently ran HEVC: the host never advertised CODEC_PYROWAVE and open_video_backend bailed. Approach (zero-copy, no GPU→CPU→GPU): pyrowave owns its own Vulkan device (create_device_by_compat, by render-GPU vendor/device-id — NOT LUID, invalid in Session 0). The capturer runs a BGRA→YUV BT.709-limited CSC (matching rgb2yuv.comp) into TWO SEPARATE shareable plane textures — full-res R8 Y + half-res R8G8 CbCr — which the encoder imports into pyrowave's device. Separate single/two-component textures import reliably on NVIDIA at any size; a single planar NV12 import does NOT (the vendored interop test: "only very specific resource sizes" — confirmed on-glass: 1024² fine, 720p/1080p/1440p garbage). A shared D3D11 fence, signalled after the CSC, is imported as a Vulkan timeline semaphore so the wavelet read is ordered after it. - pf-encode: enc/windows/pyrowave.rs (Encoder impl, two-plane import + Linux-style plane views); host_wire_caps advertises CODEC_PYROWAVE on Windows when the backend isn't Software; open_video_backend routes a negotiated PyroWave session first; pyrowave-sys on the Windows target; interop confirmed at open → clean HEVC fallback. - pf-encode: shared, unit-tested enc/pyrowave_wire.rs (single source of truth for the client-facing AU framing); Linux encoder uses it too. - pf-capture: dxgi.rs BgraToYuvPlanes CSC; idd_push.rs pyrowave mode — forces the virtual display SDR (the VideoProcessor can't ingest the FP16 HDR ring), a two-plane shareable out-ring, a shared fence passed every frame (so a rebuilt encoder re-imports it). Threaded via OutputFormat::pyrowave. - pf-frame: D3d11Frame::pyro carries the CbCr plane + fence; OutputFormat::pyrowave. Verified on .173 (RTX 4090): full-host build + clippy -D warnings (nvenc,amf-qsv) + fmt --all --check; pyrowave_wire unit tests; pyrowave_win_smoke GPU test round-trips distinct Y/Cb/Cr (100/180/60) exactly at 1024²/720p/1080p/1440p; Stage-0 interop validated in the real Session-0 service context on-glass. Deployed to the box. Owed: final on-glass picture/latency confirmation. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 11:39:44 +02:00
enricobuehlerandClaude Fable 5	bbe4380b41	perf(latency): T1.1 frame-driven encode trigger + T1.4 time-based flush thresholds ... design/latency-reduction-2026-07.md tier 1, remaining halves: - T1.1: the native encode loop wakes on the capture's ACTUAL arrival instead of sampling at a free-running tick — deletes the sample-and-hold (~half a frame interval on average, a full one worst-case: ~8ms avg @60fps). New Capturer::supports_arrival_wait/wait_arrival pair (IDD-push waits its frame-ready event against the shared-header token; the PipeWire portal blocks its channel with a pending stash); backends without an arrival signal — and PUNKTFUNK_FRAME_DRIVEN=0 — keep the legacy tick bit-identically. A 0.9x-interval rate floor caps encode at ~1.11x target when the compositor outruns the session; a +0.5x-interval keepalive keeps static desktops re-encoding at 1.5x-interval cadence. Pacing deadlines re-anchor to the actual submit so they can't drift against the arrival clock. GameStream plane untouched. - T1.4: the jump-to-live detectors run on WALL-CLOCK now (STANDING_TIME / FLUSH_AFTER = 250ms) instead of 30-frame counts whose meaning scaled with fps (500ms @60 but 125ms @240 — and stretching further under T1.1's slower static-scene repeats). The queue trip also requires depth still >= high, so a hysteresis-band hover can't fire on elapsed time alone. Validated: .21 Linux 185 core + 177 host + pf-capture tests, clippy -D warnings; .133 Windows cargo check of pf-capture + punktfunk-host green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 19:31:49 +02:00
enricobuehlerandClaude Opus 4.8	c8ee4b9902	fix(pf-vdisplay,pf-capture,pf-win-display): pre-split paths in the auto-merged v4 code ... The rename-followed perf hunks still said crate::win_display:: (the pre-W6 layout) — point them at pf_win_display::win_display:: and widen the four helpers they call cross-crate. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 16:13:15 +02:00
enricobuehlerandClaude Opus 4.8	09849906e9	Merge perf/first-frame-latency: driver proto v4 + first-frame/resize latency (P0-P2) ... Brings the first-frame-latency branch (P0.1 transition tracing, P1.1/P1.2 Welcome-time display prep, P2 in-place resize; pf-driver-proto v3 -> v4 with IOCTL_UPDATE_MODES) onto current main. The branch predates the W6.2/W7 splits, so git's rename detection carried most of it into the moved crates (pf-capture idd_push, pf-vdisplay manager/pf_vdisplay, pf-win-display, pf-driver-proto, the driver workspace) and the punktfunk1.rs remainder was re-homed by hand: - native/handshake.rs: welcome/start trace marks + the Welcome-time display prep spawn (the prep thread BECOMES the stream thread; hand-off via a SyncSender<SessionContext>). negotiate() gains bringup/quit/stop and returns the PrepHandle. - native.rs: bringup/resize_ms creation + the stop/quit flags hoisted BEFORE the handshake (the close watcher splits: flags pre-handshake, lifecycle events post-handshake where `hello` exists); punch_done stamp; the data plane adopts the prep thread's result or builds inline. - native/stream.rs: SessionContext/SendStats carry the trace; send_loop finishes it on the first video packet; the resize path gains the in-place fast path (try_inplace_resize) with the full rebuild as fallback, restructured so both share the post-rebuild bookkeeping; prepare_display/PreparedDisplay/ PrepHandle; build_pipeline(+retry) thread the stage marks. - session_status/mgmt: ttff_ms + last_resize_ms per session (union with the lifecycle-events fields main added to the same spots). - pf-capture: Capturer gains capture_target_id() + resize_output() defaults. - pf-vdisplay manager: perf's faster activation poll (60x50ms) + the settle floor before the PnP sweep, on main's knobs/no-trait shape. Also: packaging/windows/build-gamepad-drivers.ps1 is ASCII again (an em-dash from the pf-mouse work tripped windows-host.yml's locale-safety gate on main). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 16:08:16 +02:00
enricobuehlerandClaude Opus 4.8	94ca4041ca	refactor(host/W6.2): extract the frame-capture backends into the pf-capture crate ... capture/linux (PipeWire portal) + capture/windows (IDD direct-push: dxgi mechanics, idd_push + submodules, synthetic_nv12) + pwinit move into crates/pf-capture behind the Capturer trait + synthetic sources (plan §W6). The crate speaks pf-frame (CapturedFrame/PixelFormat + the DXGI identity), pf-zerocopy (CUDA import), and the pf-win-display leaves, and NEVER pf-encode — the capture->encode edge is one-way. This completes the deliberate capture/encode crate split (the invasive path the plan had merged into one pf-media): capture and encode are now separate subsystem crates sharing only pf-frame. Four seams keep the capturer off the orchestrator: - VirtualOutput is EXPLODED into primitives (remote_fd/node_id/preferred_mode/ keepalive) by the host facade, so pf-capture never depends on the vdisplay type; - FrameChannelSender: the sealed-channel delivery is a Send+Sync closure the host facade builds from the pf-vdisplay control device + send_frame_channel IOCTL and hands in; ChannelBroker holds the closure instead of the control HANDLE (the whole-desktop handle-duplication security boundary is byte-for-byte unchanged); - console_session_mismatch + desktop_bounds live in pf-win-display (leaf peers); - pwinit moves here (audio caller -> pf_capture::pwinit). The host keeps capture.rs as a thin BRIDGE: it re-exports the vocabulary + capturer types (every crate::capture::* path is unchanged) and keeps open_portal_monitor / capture_virtual_output, which resolve the ZeroCopyPolicy + FrameChannelSender and call into pf-capture. verify_is_wudfhost + install_gpu_pref_hook are re-exported (the gamepad-channel bootstrap + the main.rs subcommand consume them). Co-developed: the resident-HID-mouse compose-kick hook (HID_COMPOSE_KICK + the HID-first cursor kick + _display_wake) rides this commit into pf-capture; the host mouse_windows registration side lands separately on top. Verified: Linux clippy -D warnings (pf-capture + host nvenc,vulkan-encode,pyrowave --all-targets) + host tests 299/299; Windows clippy -D warnings (pf-capture --all-targets + host nvenc,amf-qsv --all-targets) Finished exit 0. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 11:28:56 +02:00