1585 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	e8a4f54c07	fix(pf-vdisplay): the capability-hint test asserted the environment, not the code ... `silent_without_capabilities` called the real `capability_denial_hint()` and asserted it returns "", on the strength of a doc comment that read "The test process has no capabilities." That is true on a dev box and false in CI, where the runner container is root with a full permitted set. main went red on 0f79587d with: left: " — NOTE: this process carries capabilities (CapPrm=0x000001ffffffffff) …" right: "" Nothing was wrong: the hint fired correctly, on a process that really did hold every capability. The test was reading the ambient environment and calling it a property of the code. `permitted_caps_from_status` had already been split out for exactly this reason — "so that shape is testable without a capability-carrying process to point at" — but only the PARSE half. The message half still went to /proc/self/status. This finishes the split: `capability_denial_hint_for(Option<u64>)` holds the formatting and takes the mask, `capability_denial_hint()` reads /proc and delegates. Both keep their callers, so neither is dead code. Also adds `names_the_mask_and_the_repair_when_capped`. Without it the silent case passes just as well against a function that returns "" unconditionally — which is the failure mode this repo has been bitten by before, and the reason every decode fix carries a counterfactual. No behaviour change: the three error paths call the same function and get the same string. ⚠ Verification is CI. `kwin.rs` is `#[cfg(target_os = "linux")]`, so it does not compile on the macOS host this was written from; `cargo fmt --all --check` is clean and a Linux container check was attempted but the stock rust image has no cmake for audiopus_sys, so it never reached the test. ci.yml going green on main is the proof — and unlike the case it replaces, this test now fails or passes for reasons that have nothing to do with the machine running it. Does not touch the v0.26.0 tag: ci.yml runs on `push: branches: [main]` and `pull_request` only, and no tag leg runs cargo test.	2026-08-09 10:39:41 +02:00
enricobuehler	42ee6c5628	fix(packaging): the host's CAP_SYS_NICE made it invisible to KWin, killing every KDE session ... 0.26.0-1 setcap'd `cap_sys_nice=ep` on /usr/bin/punktfunk-host so the encoder could open an elevated global-priority Vulkan queue. On every KDE box that ended desktop streaming outright: KWin virtual output failed: KWin does not expose zkde_screencast_unstable_v1 to this client reported from CachyOS on NVIDIA and on AMD, surviving a clean reinstall of host and client, and worked around only by KWIN_WAYLAND_NO_PERMISSION_CHECKS=1. The two cannot coexist. KWin hands out its restricted protocols — zkde_screencast_unstable_v1, which mints our virtual output, and org_kde_kwin_fake_input, which injects input — only to a client it can IDENTIFY, by resolving that client's /proc/<pid>/exe and matching it against an installed .desktop's Exec=. The kernel refuses that readlink to any reader whose effective set is not a superset of the target's PERMITTED set (cap_ptrace_access_check), and KWin holds no capabilities. So the instant the binary carries one, KWin's executablePath() is empty, nothing matches, and the global is never advertised — presenting exactly as a missing or mis-installed .desktop file. Measured on CachyOS (kernel 7.1.6), same-uid reader, cap_sys_nice=ep on the target: no capability .............................. readlink /proc/<pid>/exe OK capability ................................. EPERM capability + prctl(PR_SET_DUMPABLE, 1) ..... EPERM <- dumpable is NOT the gate capability dropped + PR_SET_DUMPABLE(1) .... OK <- only an uncapped process works The third row also rules out the reflex fix of moving the grant to systemd AmbientCapabilities=, which lands CAP_SYS_NICE in the very same permitted set. Nothing short of not holding the capability restores identification, so the host does not get one. The cost is pacing only. pf-zerocopy's device create already walks REALTIME -> HIGH -> default when a priority class is refused, and pf-frame's thread nice is a documented best-effort no-op without the capability — so this is 0.25.0's behaviour exactly, which is the behaviour that worked. * packaging/arch/punktfunk-host.install: grant -> revoke. post_upgrade strips the capability from boxes that already ran 0.26.0-1's scriptlet. A pacman upgrade writes a new inode and file capabilities do not survive that, so this is belt-and-braces for reinstall/downgrade paths. * pf-vdisplay kwin.rs: all three "KWin does not expose zkde_screencast" errors now read /proc/self/status and, if this process holds ANY capability, name it with its CapPrm mask and the `setcap -r` that repairs it. The failure stays impossible to diagnose from the Wayland side otherwise, and it is not unique to our own packaging — a hand-rolled setcap does it too. Verified on 192.168.1.21 (CachyOS): the capability/dumpable matrix above; cargo check and cargo clippy --all-targets -- -D warnings clean for pf-vdisplay; both new unit tests pass; and the hint itself exercised end-to-end, silent uncapped and firing with CapPrm=0x0000000000800000 under cap_sys_nice=ep. The shipped punktfunk-host-0.26.0-1-x86_64.pkg.tar.zst was unpacked to confirm its .INSTALL carries the setcap on both post_install and post_upgrade. Ships as 0.26.0-2 — packaging plus one crate, no version bump.	2026-08-09 09:37:30 +02:00
enricobuehler	2079411f4f	fix(pf-encode): the Windows host could not compile — a Linux-only reader tripped dead_code ... The v0.26.0 tag went red on windows-host at the clippy step, after a clean build: error: function `wire_sequence` is never used --> crates\pf-encode\src\enc\pyrowave_wire.rs:68:15 = note: `-D dead-code` implied by `-D warnings` `pyrowave_wire` is cfg'd for linux OR windows and is genuinely shared — `packet_boundary` and `stamp_color_bits` each have callers on both backends. `wire_sequence` does not: every call site is in `enc/linux/pyrowave.rs`, which is `#[cfg(all(target_os = "linux", feature = "pyrowave"))]`. Alternating encoder handles are a Linux-side concern (PW5); the Windows backend drives pyrowave's compat device with a single handle and never needs the counter. The module's own `#[cfg(test)]` block does not reference it either, so on Windows the item has zero callers in every target and dead_code is correct — it is the `-D warnings` promotion to a hard error that stops the lib compiling. Scoped to the one item rather than the file, and expressed as `cfg_attr(not(target_os = "linux"), ...)` rather than a bare `allow`, so dead_code stays LIVE on Linux — where the caller lives, and where this function quietly losing its last caller would be a real finding rather than noise. ⚠ Not reproducible off a Windows box: cross-compiling to x86_64-pc-windows-msvc from macOS dies in openh264-sys2's build script (clang++ rejects `-fPIC` for that target) long before the lint stage. The mechanism is nonetheless exact — one item, one cfg, zero callers behind it — and the windows-host and windows-msix legs are the proof. No behaviour change on any platform: this adds a lint attribute and eight lines of comment.	2026-08-09 01:43:54 +02:00
enricobuehler	ebf61cb448	Merge branch 'worktree-wave2-pw5-encode-overlap' into worktree-wave2-pyrowave ... # Conflicts: # crates/pf-encode/src/enc/linux/pyrowave.rs	2026-08-09 01:14:59 +02:00
enricobuehler	4a92c64144	Merge branch 'worktree-wave2-pw7a-jumbo-shard' into worktree-wave2-pyrowave	2026-08-09 01:13:30 +02:00
enricobuehler	2426056465	Merge branch 'worktree-wave2-pw6-streamed-au' into worktree-wave2-pyrowave	2026-08-09 01:13:25 +02:00
enricobuehler	d3aaa16a7d	Merge branch 'worktree-wave2-pw3-dmabuf-latch' into worktree-wave2-pyrowave ... # Conflicts: # packaging/arch/punktfunk-host.install # scripts/steamdeck/install.sh	2026-08-09 01:13:23 +02:00
enricobuehler	2dd65bdd41	Merge pull request 'Opening the Steam menu on the Deck moved the game too — the pad is now held neutral while an overlay owns it' (#131) from worktree-deck-overlay-input-mask into main ... Reviewed-on: #131	2026-08-08 22:59:30 +00:00
enricobuehler	5cbaca7789	feat(client/pads): stop forwarding the pad while the Steam overlay owns it ... On a Deck in Gaming Mode the Steam menu and the QAM are driven by the SAME physical controller the client forwards, so opening either one moved the game on the host as well as Steam's UI — a second, invisible player. Steam Input masks a normal game here; it cannot mask us, because masking happens on Steam Input's virtual pad and we deliberately forward the REAL one (28DE:1205 — the virtual pad has no gyro, trackpads or paddles). SDL ships the exact behaviour we want and it is on by default: presses are dropped while the process has windows but no keyboard focus, releases still get through. It CANNOT fire on a Deck. gamescope resolves focus per Xwayland ctx and the client sits alone in its own, so the Steam overlay — which lives in the root ctx — never takes our X focus away and no FocusOut is ever generated. Measured on glass: with the QAM open, X input focus inside the client's ctx stayed on its window for the whole 4 s, while GAMESCOPE_FOCUSED_APP flipped to 769 (Steam) and GAMESCOPE_FOCUSED_APP_GFX stayed on the app. So the signal is explicit. `overlay_focus` watches those two atoms on the gamescope root ctx — which is NOT our own $DISPLAY under `--xwayland-count 2`, hence the socket-directory walk and the flatpak filesystem line — and the presenter ORs it with window focus into one `set_masked`. Masking is deliberately not `set_forwarding`: that closes the slot and sends GamepadRemove, so the game would see a controller UNPLUG every time somebody opened the QAM. This keeps every slot open and only stops the transitions, after flushing what the host believes is held so a stick deflected at overlay-open stops steering instead of freezing at its last value. On the way back, held buttons are adopted rather than replayed — the A that picked a QAM row must not fire in the game as it closes — while axes are re-sent, since a stick has no press to ghost and SDL only speaks on change. Fails open throughout: no gamescope, no X, or an unreadable signal all leave forwarding exactly as it was. `PUNKTFUNK_OVERLAY_MASK=0` opts out.	2026-08-09 00:55:16 +02:00
enricobuehler	78ba2342b5	Merge pull request 'rom-manager has been putting 0 games in the library since 08-05 — a plugin launch kind, so a scanner can publish tiles the host cannot name' (#129) from worktree-rom-manager-plugin-launch into main ... Reviewed-on: #129	2026-08-08 22:44:44 +00:00
enricobuehler	7d37fe450d	test(pf-encode): run PyroWave at depth 2 on real hardware — without shipping depth 2 ... Wave-2 PW5, the stage-6 experiment. Shipped behaviour is UNCHANGED: `max_inflight` is still 1. Stage 6 is the frame-corruption stage, and its gate is an on-glass tear-hunt with a live compositor, a real client and ten minutes of moving content. That is not runnable from here. But the depth-2 risk has two halves, and one of them lives entirely in this crate — the per-slot resources (`cmd`/`fence`/`csc_set`/y/uv/cursor) and the alternating encoder handles — so that half can be answered now, on the GPU, and the answer is worth having before anyone attempts the other. The experiment drives the backend with two frames genuinely in flight (submit N+1, then poll N) and compares the result against the encoder's OWN synchronous output over the same 16 moving frames. Its own depth-1 decode is the honest reference: pyrowave's raw AU bytes are not reproducible run-to-run (see the stage-3 commit), but its decoded planes are. RESULT, .21 / RTX 5070 Ti (GPU idle at 180 MHz of 3090 — the slow-clock worst case on this card): depth-2 vs depth-1 over 16 frames: worst-case PSNR identical (inf) Bit-identical luma, every frame, in order. So stages 4 and 5 between them are sufficient for the encoder side: doubling the six single-slot resources and alternating two `pyrowave_encoder` handles under one monotonic wire sequence really does make overlap invisible to the decoder. The test is built to fail rather than to pass. Content MOVES every frame (flat fills are the documented false-green trap — a torn frame stitched from two halves of a static card is invisible), it asserts two frames were ACTUALLY in flight rather than silently proving nothing, it asserts the AU count is unchanged, and it carries an off-by-one discriminator that raw PSNR would miss: each overlapped frame must match its own reference BETTER than it matches the previous one, so a pipeline delivering frames one position late fails even though every individual PSNR looks fine. It reaches `max_inflight` directly instead of through a shipped knob, precisely so the shipped value stays 1. ⚠ WHAT THIS DOES NOT COVER, stated here so the next person does not read it as a green light for stage 6: the CAPTURE side. `.process` hands the SPA buffer back to the compositor at callback return while the encode thread holds only a dup of its dmabuf fd, so a second frame in flight widens the window in which the producer may overwrite a buffer we are still reading by a full frame period. Nothing in this crate can test that — it needs a live producer. Stages 1 and 2 are what make it answerable (the pool census says how deep the producer's ring is; the Choice range asks for headroom), and the on-glass hunt is what would settle it. Gates green at CI parity.	2026-08-09 00:30:25 +02:00
enricobuehler	077db416ec	feat(pf-encode): two PyroWave encoder handles, and the 3-bit landmine that makes them work ... Wave-2 PW5 stage 5. Depth is STILL 1 — the handles alternate per frame, one in flight. PyroWave's `Encoder` cannot hold two frames. Not "probably not" — structurally not. `Encoder::Impl` owns ONE each of `wavelet_img_high_res`, `bucket_buffer`, `meta_buffer`, `block_stat_buffer`, `payload_data` and `quant_buffer`, and `Impl::encode` OPENS by discarding them: an image barrier with `VK_IMAGE_LAYOUT_UNDEFINED` as the old layout — a written promise that nothing else is reading it — plus three `fill_buffer` clears. Two encodes recorded into two command buffers and submitted to one queue have no execution dependency in Vulkan (submission order orders the START, not the completion), so N+1's DWT would overwrite the wavelet bands and zero the RDO buckets while N's block packing still reads them. Content-dependent, silent. So overlap means TWO handles on one device, alternated — one per slot. Every resource above is then private per handle, and within a handle the encodes stay strictly serialized (a slot's next frame is recorded only after that slot's previous one retired), which leaves patch 0004's scratch-pool invariant intact without touching it. THE LANDMINE, and it is the reason this stage is its own commit: `sequence_count` ALSO lives on `Impl`, and it is the 3-bit counter stamped into every block header. Two handles each count 1,2,3... alone, so the wire sees 1,1,2,2,3,3.... The decoder restarts a frame only when the value CHANGES (`diff = (hdr.sequence - last_seq) & 0x7; restart = diff != 0`), so a repeat reads as MORE BLOCKS OF THE SAME FRAME: `clear()` never runs, `decoded_frame_for_current_sequence` stays true, and the second frame of each pair is swallowed. Half frame rate, occasional mixed-frame blocks, no error anywhere — on every client, since pf-client-core and the Apple Metal hand-port parse the same field. `patches/0007-encoder-sequence-override.patch` (new, ~38 lines) exposes `Encoder::set_next_sequence` + a `pyrowave_encoder_set_next_sequence` C entry + a `PYROWAVE_SEQUENCE_MASK` define, so ONE monotonic counter on the Rust side is stamped regardless of which handle encodes. The setter stores `(seq - 1) & mask` because `Impl::encode` pre-increments — its contract is about the next ENCODE, not the next store. Inert when unused, so the whole Windows backend is untouched. No `.def` change: the C API is a static archive. PREDICTED, THEN OBSERVED. A negative control on .21 (the override call removed, nothing else) reads the wire out at exactly: [1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 0, 0, 1, 1, 2, 2] which is the analysis's prediction character for character, and with the override: +1 mod 8, all 20 frames, through the 3-bit wrap. THE GATE, `wire_sequence_increments_across_alternating_handles`, checks three things over 20 frames because any one alone could pass while the stream is broken: the wire counter advances by 1 mod 8; ONE persistent decoder (its `last_seq` carried across every push, exactly like a client's) reports every AU decodable; and consecutive decoded pictures DIFFER. Content moves every frame — and the first run caught a trap in the harness itself rather than the encoder: `test_card` starts its LCG at `seed | 1`, so seeds 2 and 3 build a byte-identical card and the test faked the very repeat it hunts. Odd seeds only now, with the reason written down. A runtime self-check backs the test up where the test cannot reach: after packetize, the stamped sequence is compared against what we asked for, and a mismatch logs once per process naming patch 0007. A re-vendor that loses the patch would not fail to build — it would fail on glass, subtly, and this makes it loud instead. Two byte reads per frame. `reset()` rebuilds both handles and `Drop` destroys both, each with the same null-immediately discipline the single handle had (`pyrowave_encoder_destroy` is a bare `delete` with no null check, so a stale pointer left in the field is a double free). Vendored-patch discipline: patch 0007 re-applies clean to a pristine vendor checkout (verified by stashing the vendor tree and re-applying), and `git diff crates/pyrowave-sys/vendor/` touches exactly the four intended files. VERIFIED ON GLASS (.21, RTX 5070 Ti, GPU idle at 180 MHz of 3090): all 8 `#[ignore]`d GPU tests pass, including the new gate and the 4:2:0 / 4:4:4 / 24-bpp PSNR smokes. Gates green at CI parity.	2026-08-09 00:27:28 +02:00
enricobuehler	29248dcab9	feat(pf-encode): PyroWave had six single-slot resources, not the two the plan named ... Wave-2 PW5 stage 4. Pure capacity — `max_inflight` is STILL 1, nothing overlaps yet. The plan named the y/uv images as the thing to double. Reading the backend found five more, and each is a correctness problem under overlap rather than a performance one: * `csc_set` — ONE descriptor set, rewritten every frame by `bind_rgb`. Updating a set still bound by a PENDING command buffer violates VUID-vkUpdateDescriptorSets-None-03047, and on most drivers that is a wrong picture rather than an error. * `y_img`/`uv_img` — the CSC of N+1 storage-writes exactly the images pyrowave is still sampling for N. The barrier comment ("the previous frame's encode already completed under our synchronous fence") was load-bearing and said so. * `cursor_img` + `cursor_stage` — the struct comment stated the assumption outright: *"Single (not ring) because PyroWave encodes one frame synchronously — no in-flight overlap to race."* * `cmd` + `fence` — you cannot record into a PENDING command buffer at all. * `cpu_img`/`cpu_stage` (software capture / tests) — the host writes staging while the previous frame's copy is still pending. All of it moves into a `Slot`, and the encoder now owns `SLOTS` of them. Two, because Granite caps the overlap at two for us: the pyrowave device defaults to `init_frame_contexts(2)` and `next_frame_context()` — called at the top of every `encode_gpu_synchronous` — waits the context it rotates into. A third slot would need a vendored `init_frame_contexts(3)` that is not exposed. `bitstream` and `import_cache` are deliberately NOT per-slot, and the `Slot` doc says why so a later sweep does not "fix" it: `bitstream` is only touched during packetize, i.e. only on the poll side one frame at a time, and `import_cache` retaining the VkImage/VkDeviceMemory per dmabuf inode is precisely what makes it safe for two slots to sample the same imported buffer. `cpu_expand` is shared for the same reason — it is copied into staging before `submit_frame` returns, so no GPU work ever reads it. Each frame carries its slot index in `InFlight` rather than recomputing it, so `wait_and_packetize` cannot wait the wrong fence — the failure that would look like corruption rather than an error. `reset()` now waits EVERY in-flight fence, not just one, which matters the moment depth rises. WHAT IT COSTS, measured from the driver's own memory requirements rather than estimated (.21, RTX 5070 Ti, and there is now an `#[ignore]`d test that prints it on any GPU): 1080p 4:2:0 3872 KiB per slot 7744 KiB for both 4K 4:2:0 12992 KiB per slot 25984 KiB for both 4K 4:4:4 24992 KiB per slot 49984 KiB for both So the extra slot costs ~3.8 MiB at 1080p and ~24 MiB at 4K 4:4:4 — an order of magnitude under the plan's ~25-35 MB / 100-150 MB estimate, because that estimate included pyrowave's internal wavelet and scratch buffers, which stage 5's second encoder handle will add and this stage does not. Affordable on an iGPU. The open line now logs `slots`, `slot_kib` and `slots_kib` so this is visible per session and not only in a test. VERIFIED ON GLASS (.21, GPU idle at 195 MHz of 3090 — slow-clock, the worst case on this card): all 6 `#[ignore]`d GPU tests pass, and all NINE decoded-plane hashes (`ref-dense-{y,cb,cr}`, `ref-chunked-*`, `ref-dense444-*`) are bit-identical to the pre-PW5 base. Decode identity is the meaningful gate here — the raw AU bytes are not reproducible run-to-run even from an unmodified binary, which stage 3's message documents. Gates green at CI parity.	2026-08-09 00:18:38 +02:00
enricobuehler	95962f55d0	refactor(pf-encode): PyroWave waited its fence inside submit — the one backend that did ... Wave-2 PW5 stage 3. Depth is STILL 1; this is the shape change alone. `encode_frame` recorded CSC+encode, queue-submitted, waited the fence and packetized, all inside `Encoder::submit`. Every other backend in this crate puts the wait on the POLL side. That difference is the whole reason the host loop's cadence folds around this encoder: with the wait inline, `submit` returns only after the GPU is done, so the arrival-anchored floor absorbs the encode only while it stays under 0.9x the frame interval. Split into `submit_frame` (ingest -> CSC -> pyrowave encode -> queue-submit -> return) and `wait_and_packetize` (fence wait -> packetize -> AU), with an `InFlight` deque between them capped by `max_inflight`, which is 1. **One is the only value the resources can support today** — `cmd`, `fence`, `csc_set` and the y/uv images are one each, so a second concurrent frame would record into a PENDING command buffer and storage-write images pyrowave is still sampling. `submit` therefore drains to `max_inflight - 1` before recording, which states that invariant in one place instead of leaving it implicit in "the encode is synchronous". The subtle part is the command-buffer state machine, and it is unchanged: the record-and-submit closure still resets `cmd` on every PRE-submit failure (RECORDING/INVALID/EXECUTABLE, never PENDING), and the fence wait still does NOT reset on failure, because a timeout leaves the buffer PENDING where a reset violates VUID-vkResetCommandBuffer-commandBuffer-00045. What changed is that a failed wait now also leaves the entry IN FLIGHT — which is precisely what tells `reset()` there is live GPU work to re-wait before the pyrowave encoder object may be destroyed. `gpu_pending` is gone; `!inflight.is_empty()` is the same fact, and cannot drift from it. The split opened two windows that did not exist when everything ran inline, both closed here: `reconfigure_bitrate` and `set_wire_chunking` can now land BETWEEN a submit and its poll, so the packetize boundary and the bitstream cap are snapshotted into `InFlight` at submit time. Reading the live fields would have let a mid-flight bitrate drop turn a perfectly good frame into "unexpected packet count", and a mid-flight chunking change into an AU with the wrong `chunk_aligned` flag. `flush()` is no longer a no-op — it drains the in-flight frame, so the trait's poll-until-None contract still returns every AU (the `spike` subcommand and the hardware smoke tests are the real users). The perf instrument still measures submit->AU, stamped at submit and taken when the AU becomes readable, so `92326312`'s numbers stay directly comparable; the log line now carries `depth` and says plainly that above depth 1 the number legitimately grows by about one loop period. VERIFIED ON GLASS (.21, RTX 5070 Ti, GPU idle at 180 MHz of 3090 — so these are slow-clock runs, which is the worst case on this card, not the best): all 6 `#[ignore]`d GPU tests pass — the 4:2:0, 4:4:4 and 24-bpp PSNR smokes, the mode-mismatch refusal, the fd-leak check and the golden dump. Byte-identity, honestly: the AU bytes are NOT reproducible, and were not before this commit either. Three runs of the SAME unmodified binary produced three different `au-dense.bin` hashes (ab7ecaf6 / 8735700e / 933b3d40) — the vendored 4:2:0 encoder emits run-varying bytes that the decoder ignores. So the meaningful gate is DECODE identity, and that holds exactly: every decoded plane (`ref-dense-{y,cb,cr}`, `ref-chunked-{y,cb,cr}`, `ref-dense444-{y,cb,cr}`) is bit-identical between the pre-split base and this commit, across four runs. 4:4:4 AUs are additionally bit-stable and match the checked-in Apple fixture exactly. Gates green at CI parity.	2026-08-09 00:11:22 +02:00
enricobuehler	9e598f8595	fix(client): the 4:4:4 switch could cost a Deck its whole codec, and --probe-decode denied the queue it was decoding on ... Two Steam Deck findings from a field report of "the decoder was not found, it fell back to H.264 — but sometimes HEVC worked". **The 4:4:4 advertisement was a promise nothing checked.** `VIDEO_CAP_444` rode the "Full chroma" setting alone. That was safe while a software HEVC decoder existed underneath it; M8 removed one (there is no permissively licensed HEVC CPU decoder, so `software_decodable_codecs()` is H.264|AV1). The host grants 4:4:4 on HEVC ONLY, and answers the resolved chroma in the Welcome before the client builds a decoder — so on a device with no 4:4:4 decode the toggle did not cost crispness, it cost the entire codec: the Vulkan rung refuses the shape at construction, VAAPI refuses it too, there is no CPU rung, and the session reconnects on H.264. AMD has no HEVC 4:4:4 decode on any silicon, so every Deck with that switch on lost HEVC. It is per-profile and default-off, which is exactly why it looked intermittent — a "Work" profile lost HEVC where "Game" kept it, same box, same host. Gated on `hevc_444_hardware_decodable`, which asks the driver through the SAME code the rung uses at construction (`VkH265Decoder::probe_stream_support`), so the advertisement and the rung that must honour it cannot disagree. Both depths are required, not either: with HDR on the host may resolve 4:4:4 10-bit, and a device offering YUV444_8 but not YUV444_10 would land in the same hole. Answering from the Vulkan rung alone is exact rather than approximate — it is the only rung in this build that implements 4:4:4 at all (`pf_vaadec::profile_for` errors on chroma_format_idc 3, pf-dxvadec refuses anything but 4:2:0, the CPU rung is 8-bit 4:2:0). Deliberately NOT extended to VIDEO_CAP_10BIT/HDR: all three rungs implement 10-bit 4:2:0, so a Vulkan-only probe there would withdraw HDR from boxes whose VAAPI/DXVA rung decodes it perfectly — a real regression against a case never observed. The bit arithmetic moves into `video::video_caps_for` so the part that was wrong is testable without a GPU, a host or a Hello; the test is verified non-vacuous against the planted original defect. **`--probe-decode` described a different device from the one that streams.** The RADV video-decode opt-in sat AFTER the --list-adapters/--probe-decode/--list-audio /--pair early exits, so the triage tool never had it. Measured on a Deck (canary e22af40f), same binary back to back: bare `--probe-decode` printed "vulkan video decode: no", "driver decode ops: none (0x0)", "no queue family advertises VIDEO_DECODE"; with RADV_PERFTEST=video_decode in the environment, "YES" and "H.264, H.265, AV1, VP9". Any Deck triage that consulted it reached the opposite of the truth. Hoisted to the top of `run`, ahead of every early exit — nothing touches Vulkan before it (`main` calls `run` directly). Gates, in the Linux container: fmt, plain `cargo build` (not only --all-targets), `clippy --all-targets -D warnings`, and 185 tests.	2026-08-09 00:10:46 +02:00
enricobuehler	c3ecc29117	feat(pf-capture): the zero-copy path never asked the compositor for buffer headroom ... Wave-2 PW5 stage 2, on the number stage 1 just made visible. `build_dmabuf_buffers` set `SPA_PARAM_BUFFERS_dataType` and stopped there — no `SPA_PARAM_BUFFERS_buffers` at all, so the pool depth the whole zero-copy safety argument rests on was entirely the producer's choice, and we never even expressed a preference. This asks for 8 (min 2, max 16). A **Choice Range**, deliberately, not a fixed count. SPA intersects the consumer's and producer's Buffers params, so a fixed 8 against a producer that can only afford 4 empties the intersection and the link stalls in "negotiating" with no error anywhere — the exact trap that cost this codebase the entire Linux cursor channel once, when a 256^2 cursor-meta max failed to intersect Mutter's fixed 384^2 offer. With a range the producer clamps into it and negotiation still succeeds; the min stays at 2 so nothing that works today stops working. The numbers, and what they are not: 8 buffers is ~133 ms of pool at 60 Hz and ~33 ms at 240 Hz, well past the ~3-4 ms capture-to-fence latency PW3/PW4 measured, with room for a second frame in flight. 16 is a ceiling rather than a request — a 4K 4:4:4 buffer is ~25 MB, so 16 of them is ~400 MB of compositor allocation. These are the values we ASK for; what a producer actually allocates is what stage 1's census line reports, and that line is the one to trust. Scoped to the dmabuf pod only. The mappable and SHM-only builders are untouched: their consumers copy out of the buffer inside `.process`, so pool depth is not part of their correctness argument. A test pins the pod SHAPE — Choice, Range, Int children, values default-first — so a later simplification cannot quietly turn the range back into a number and take the negotiation down with it. Gates green at CI parity; on-glass negotiation on each producer is stage 2's own gate and is reported with the stage-1 census numbers.	2026-08-09 00:01:24 +02:00
enricobuehler	6d550530fe	feat(pf-capture): nothing had ever counted the compositor's buffer pool — the number every zero-copy safety argument rests on ... Wave-2 PW5 stage 1, and the one stage with no risk at all. The zero-copy capture path dups the dmabuf fd, publishes the frame, and hands the SPA buffer straight back to the producer at `.process` return — while the encode thread has not yet imported it, let alone read it. The code says so itself ("content stability across the brief import/encode window relies on the compositor's buffer-pool depth, like any zero-copy capture"). That depth is therefore load-bearing: it is the ONLY thing standing between us and the producer overwriting a buffer mid-read. And it had never been measured. Not logged, not asserted, not even requested — `build_dmabuf_buffers` set `SPA_PARAM_BUFFERS_dataType` and nothing else, so whatever the producer picked is what we got, silently. This adds the `add_buffer`/`remove_buffer` stream callbacks PipeWire has always offered and logs the count once per distinct depth: `pool_depth`, `high_water`, and the latest-frame-only `drained` count beside it. One line per session on a stable pool (`.process` runs at the capture rate — an unconditional log would be 240 lines a second of the same number), a second line if a renegotiation changes the depth. `high_water` is tracked separately from `live` because a renegotiation frees the pool before re-allocating it: any decision keyed on the live count would read that dip as "the pool shrank". `remove` saturates at zero rather than wrapping, so an unmatched remove cannot report `u32::MAX` buffers. Measurement only — no behaviour change, and no consumer of the number yet. PW5's later stages need it (a deeper encode pipeline widens the overwrite window by a full frame period), but the number is worth having regardless of whether those stages ever land: it is the answer to "is our zero-copy capture actually safe on this compositor", and until now the honest answer was "nobody knows". 3 tests pin the once-per-depth logging, the renegotiation dip, and the saturating remove. Gates green at CI parity.	2026-08-09 00:01:08 +02:00
enricobuehler	4f5ca5f9bc	docs(pf-capture): KWin/RADV was the last untested producer — it has no fence either ... Closes PW4's one remaining gap. The Steam Deck switched to Desktop Mode gives KWin on RADV, the combination none of the earlier legs covered, and it reports no implicit fence like every other: gamescope + NVIDIA (RTX 5070 Ti) NoFence Mutter + NVIDIA (RTX 5070 Ti) NoFence gamescope + RADV (Deck VANGOGH) 300/300 NoFence, mean 23us, p99 <=100us KWin + RADV (Deck desktop) no fence (older build's wording: waited=false) That is every compositor x vendor this fleet has. PW4 retires with no outstanding doubt rather than "probably fine except one box we never tried". Measured with the Deck's OWN already-authorized binary rather than a scratch build, because KWin grants zkde_screencast_unstable_v1 per EXECUTABLE PATH: it resolves /proc/<pid>/exe against a .desktop's Exec= and caches the grant on first connect, so an unregistered path is refused outright and registering one needs a re-login. The fence probe is pre-existing capture-path code, so a build from July answers the outcome question perfectly well — and nothing of the user's was modified to get it. Comment-only; no behaviour change. fmt + pf-capture clippy -D warnings green.	2026-08-08 23:52:54 +02:00
enricobuehler	5872dfc649	feat(library): a plugin launch kind, so a scanner can publish tiles the host cannot name ... The 2026-08-05 review made `launch.kind = "command"` operator-only, and a reconcile refuses on the FIRST offending entry — so rom-manager, whose every ROM is `<emulator> <args> <rom>`, stopped putting anything in the library at all. Playnite hit the same wall and was rescued with a typed kind the host resolves itself; there is no fixed scheme for "whichever emulator the operator configured, with the core and flags they chose", so that trick does not generalise. So the entry now carries an opaque key and nothing executable, and the host asks the plugin that owns it what to run — at launch time, over the loopback UI port and per-boot secret it already registered. A stolen plugin token stops being command execution: planting an entry is not enough, because the live plugin answers 404 for a key it never published. Nothing executable is persisted or served to a client, and an emulator that moved is picked up on the next launch instead of leaving a dead tile (the same reasoning as `xbox` resolving its AUMID at launch time). The host still SPAWNS it, because only the host can put the process where the stream can see it: on Linux the line is either gamescope's own argv or a spawn carrying the session's compositor env, and the returned child is what session-game-lifetime tracks to know the game exited. A plugin spawning the emulator itself would land it outside both. - library/plugin_launch.rs — the ask: blocking ureq, bounded body, absolute cwd, no control characters, and a log line for every way it can come back empty - library/launch.rs — `plugin_recipe` tried before both per-OS resolvers, plus `launch_is_resolvable` so the async handshake probe never makes the blocking call - native.rs — the session's `resolve_launch` moves onto `spawn_blocking` - plugin-kit — `serveUi({launch})` serves `POST /__launch`; and `SyncError` finally renders its cause, which is why a host refusal with a fully explanatory 403 could reach a plugin's own UI as nothing but "Decode error"	2026-08-08 23:46:05 +02:00
enricobuehler	744bcb468b	feat(host/wire): a jumbo path can now be PROVEN — and the shipped grow never could ... Wave-2 PW7a: a PyroWave session on a proven-jumbo LAN should START at the big shard, because it is the one codec that can never be re-keyed mid-stream (its client parses chunk-aligned AUs in windows of the `Welcome` value, read once over the C ABI). At an 8908-byte shard that is ~6× fewer datagrams per frame — ~49k → ~8k pps at 550 Mb/s — and proportionally less window-tail padding. THE BLOCKER FOUND FIRST: the whole jumbo leg was dead code, not just the missing half. quinn caps a peer's MTU-discovery search at `min(MtuDiscoveryConfig::upper_bound, the OTHER side's advertised max_udp_payload_size)` (`quinn_proto::connection::mtud::SearchState::new`), and `EndpointConfig::max_udp_payload_size` defaults to 1472. Nothing in the repo had ever touched `EndpointConfig`, so raising the host's PROBE ceiling — all `stream_transport_idle` did — could never make discovery settle above 1472, and the shipped mid-session grow's `settled >= sealed_datagram_bytes(target)` gate was unreachable on every path that has ever existed. Two smaller contributors, fixed here too: the watcher stopped sampling the moment `settled >= 1472`, discarding the very climb the proof needs, and a session sealed ABOVE the 1500-byte default was never checked against the path at all. The advertisement is raised on the CLIENT endpoint, under the same `jumbo_wire_mtu()` opt-in as the probe ceiling, because it is not free: quinn sizes its endpoint receive buffer `max_udp_payload_size × max_receive_segments × BATCH_SIZE`, so on a GRO-capable Linux/Android client that is ~2.9 MiB at the default and ~18 MiB at jumbo (47 KiB → 288 KiB on Apple/Windows). Consequence: jumbo now needs the opt-in on BOTH ends. Without it, every byte on the wire and every byte of buffer is exactly what it was. WHY THE GROW IS AS SAFE AS THE CLAMP, which is not obvious — the failure modes are opposite. A stale clamp only makes datagrams smaller than they had to be; a stale grow seals an oversized datagram onto a 1500-byte path, where it is silently dropped, and a PyroWave session cannot recover from that for its whole life. Mirroring the clamp's keying is therefore NOT sufficient. So the memory is demoted: the persisted verdict only decides whether it is worth WAITING for a proof, and what authorises the grow is a LIVE re-proof on the very connection being welcomed — `conn.stats().path.current_mtu` ≥ the sealed target, i.e. a datagram of exactly that size acked by this client, on this connection, seconds ago. The moved laptop cannot inherit anything: its new path's live MTU is 1472 and the grow does not happen, whatever the memory says. The remembered half is keyed strictly anyway — `(local_ip, peer_ip)`, so a verdict earned over the host's 10 GbE NIC does not apply to the same peer over Wi-Fi or a VPN — and carries the operator target it was proven under plus a 6 h TTL. It is erased by any contrary evidence: a lower settle, a session that ended before the window closed (what a client staring at black does), a changed opt-in, or a constrained-path clamp that disagrees. The proof-wait is on the bring-up critical path (`handshake.rs` sends the `Welcome` and only then kicks the display prep), so it is bounded at 300 ms, exits the instant the proof lands, and is entered ONLY for a path a previous session already proved. Its worst case is the moved laptop, and that is self-limiting: that session's watcher erases the verdict. MEASURED, NOT ARGUED: `mtu_discovery_climbs_only_as_high_as_the_peer_advertises` (`#[ignore]`d, loopback — whose own MTU is 64 KiB, so configuration is the only thing that can stop the search), on .21: leg A (server opted in, client NOT): settled at 1472 B UDP payload <- the dead-code proof leg B (both opted in): reached 8972 B in 5 ms <- the fix, and its speed Leg A is the finding restated as an experiment. Leg B says the climb costs ~5 ms once both sides advertise it, so the 300 ms proof-wait is ~60x the loopback convergence time — enough headroom for a real LAN's RTT and per-probe ack delay across the ~11 probes the search takes. Still owed: the A/B on a real jumbo LAN segment (9000-MTU NIC + switch on both ends) — pps per frame, wire/pin ratio, and a PyroWave session observed starting at 8908. Not runnable without the hardware.	2026-08-08 21:53:02 +02:00
enricobuehler	20f4d23f2d	test(pw6): the streamed-AU trap is real — and at 2 % loss it costs exactly nothing ... PW6 shipped behind a knob because one pre-registered risk was unmeasured: a streamed frame whose FINAL block is lost has no totals, so where the whole-AU path hands the consumer a usable blurred partial, a streamed frame may deliver nothing. PyroWave clients opt into partial delivery unconditionally, so this would have been a live behaviour change for every one of them. Measured now, three ways, instead of reasoned about. `tools/loss-harness` gains a partial-delivery leg: FEC pinned OFF, chunk-aligned AUs, deliver_partial ON, realistic 1408/200 geometry, and AU sizes swept across the whole 1..=200-shard range of FINAL-block sizes — because the final block's size is what bounds the exposure. Loss is injected per packet from a seeded xorshift rather than through `loopback_drop_period`, whose deterministic 1-in-N would systematically always-or-never hit the final block, which is the entire question. `tc netem` on `lo` was deliberately not used: the in-process model gives exact per-frame attribution, needs no sudo, cannot disturb a box running a live desktop session, and — decisively — can drop precisely the final block. Leg 1, deterministic (drop exactly the last block, 200 frames): whole-AU delivers 200 partials and 0 losses; streamed delivers 0 partials and 200 total losses. The trap is real and, when it fires, total. Leg 2, random loss, 20 000 frames per cell, same seed and sizes for both shapes. At 2 % the two are indistinguishable — 20000/20000 partials and ZERO vanished frames on both, matching the analytic bound E[loss^k] over final-block sizes k (~1e-4). The gap only appears at 30 % (99.94 % vs 100 % rescue) and 50 % (99.79 %). `complete` is 0 throughout by construction: with FEC off and ~500 packets per AU, essentially every frame is damaged — which is the regime the partial path exists for. The spike gains `--wire-chunk` and a streamed loopback path, so the wire shape is reachable end to end outside a real client: `poll_chunk` drains the AU, `begin_streamed_frame_at`/`seal_streamed_chunk`/`seal_streamed_finish` seal each piece, and the client byte-compares the reassembly. On 120 real PyroWave AUs the streamed legs (56.5 and 2.0 chunks/AU) and the whole-AU control emit a byte-identical 47 373 568-byte stream with 0 mismatches — the cut changes the wire shape and not one byte of content, and with the knob unset it does not engage at all. A new `#[ignore]`d GPU test closes the picture question on real hardware with a BUSY card (gradients + checker + noise), never a flat fill: chunks are whole windows, exactly one `first` and one `last`, the AU decodes through the client's own window walk, and luma PSNR lands at 40.2 dB. Unset the knob and the test refuses to run, which is the default-off claim verified rather than asserted. Verdict recorded in the plan: KEEP IT OFF. The 2 % tie is an argument about typical loss, but the failure is not graceful when it fires and the measured win is host send-side pipelining that nobody has yet put a millisecond number on.	2026-08-08 21:26:25 +02:00
enricobuehler	49f5c815ea	feat(pf-encode): PyroWave can stream its AU to the wire — and newest-wins was never in the way ... PW6 was gated on one question: what happens to the client's newest-wins draining when a PyroWave AU arrives in pieces, given that `Session::set_deliver_frame_parts` refuses to combine with an all-intra stream. The answer is that the doc and the plan conflated two different axes, and the question never applied to this package. Host STREAMED_AU chunks change only the WIRE shape. The reassembler completes such a frame exactly like a whole one (`block_count != 0 && blocks_ok == block_count`) and hands up ONE Frame, so the frame channel still sees one entry per AU and the drain is untouched. What newest-wins genuinely cannot survive is the client's SEPARATE prefix delivery, and the mechanism is sharper than "assumes whole AUs" said: `FrameChannel::pop` counts QUEUE ENTRIES and takes one entry to be one AU. With parts on, one AU pushes several, so `len > 1` stops meaning "the consumer is behind" — the drain fires mid-AU, returns a SUFFIX and clears that same AU's prefixes. For PyroWave that is fatal rather than lossy: the sequence header lives in window 0 of every AU (`au_dims` reads it there), so every frame would arrive headerless, and `FramePart`'s own orphan contract would have a correct consumer abandon essentially all of them. Written into `pop`, `set_deliver_frame_parts` and the handshake, together with what a fix would take (skip whole SUPERSEDED AUs, never split one). That answer shrinks what this package may claim, so the code says so plainly. `encode_frame` is synchronous: the whole AU exists before the first chunk can be polled, so `poll_chunk` is not "emit as produced" and there is no encode/send overlap here (PW6 ⟂ PW5, confirmed). And with the client still receiving one whole Frame there is no decode-while-arriving either — the "~7 ms, decouple e2e latency from AU size" framing needs client work this commit does not do. What IS left is real and host-side: the whole-AU path FEC-protects, packetizes and seals the entire ~830 KB AU before its first datagram may leave the socket, while the streamed path seals and paces each FEC block as it completes. All of the cutting lives in the shared `pyrowave_wire` helper, which compiles and unit-tests on every platform, so both backends' `poll_chunk` / `supports_chunked_poll` are thin delegations — the Windows backend cannot be compiled from a Linux box, and logic written into it directly would ship unverified. Chunks are whole numbers of framing windows because `build_au` gives each window exactly ONE kind; that also makes them shard-aligned for free, which is what the sealer's sentinel bases require. Dense mode never streams (no window framing to cut on). `poll()` now errors while a chunk cursor is live — the trait's one-drain-method-per-AU contract, where double-emitting would put the same bytes on the wire twice under one frame index — and `reset()` drops the cursor so a rebuild cannot splice a dead AU's tail onto a fresh one. No new Encoder trait method, so neither the TrackedEncoder forwarding trap nor the EncoderCaps default trap is in play. Shipped OFF: `PUNKTFUNK_PYROWAVE_STREAMED_AU=1` arms it, `PUNKTFUNK_PYROWAVE_CHUNK_KIB` tunes the 256 KiB target. The pre-registered partial-delivery trap is real and now has a named cost — an unpinned streamed frame (final block lost) is excluded from partial delivery, where the whole-AU path still hands the consumer a usable blur, and PyroWave clients opt into partials unconditionally. The netem loss-harness leg is the prerequisite for default-on and has not been run.	2026-08-08 19:23:05 +02:00
enricobuehler	9232631299	feat(pf-encode): PyroWave had no encode split — so the one cost this program protects was unmeasurable ... Wave-2 PW1's exit criterion, and the instrument it needed. VAAPI and direct NVENC both log a PUNKTFUNK_PERF submit split. PyroWave did not — which meant the single encoder the GPU-priority work exists to defend was the one you could not put a number on. Adds per-frame timing of the synchronous encode (whole `submit`: CSC + encode + fence wait + packetize, which for this backend IS the encode), summarised every 2 s as mean/p50/p99/max. p99 rather than mean-only on purpose. The failure patch 0005 describes is a TAIL event — frames going ~2 ms to 15-18 ms at 95 % game load while the mean barely moves — so a mean-only readout would report "fine" straight through the thing being measured. WHAT IT MEASURED — .21, RTX 5070 Ti (610.57.04), GRID 2 benchmark loop saturating the GPU at 54-87 %, PyroWave 1080p, same binary both arms (only CAP_SYS_NICE differs), 30-frame windows with the warm-up window dropped: arm p50 p99 worst frame default priority (refused) ~2.6 ms ~6.4 ms 9.5 ms REALTIME granted ~3.2 ms ~4.4 ms 5.4 ms REALTIME granted (repeat) ~3.35 ms ~4.8 ms 5.1 ms p99 down ~30 %, worst frame roughly halved, for ~0.6 ms on the median. For a streaming encoder that is the right side of the trade — the tail is what becomes a visible hitch. This CONTRADICTS the patch's only prior datum (RTX 4090 / Windows / WDDM: "did not reduce the spikes"), so patch 0005's header now records the Linux/NVIDIA result beside it, with an explicit "do NOT delete this patch on the strength of the WDDM result — the two stacks disagree". Header prose only; the diff hunks stay byte-identical and `git diff crates/pyrowave-sys/vendor/` is untouched by this commit. Caveats recorded rather than buried: the arms were not interleaved and the game load drifted between them, capture was frame-starved (~2.5 fps) so this is encode latency under contention and not a full-rate stream, and it is two granted runs against one refused run. The direction held across all 25 windows. Also worth knowing for anyone repeating this: `encode_fps` is a VACUOUS metric on this rig. A headless gamescope with no real content emits ~12 fps, so both arms simply report the capture rate. Measure latency, not throughput. Gates green at CI parity.	2026-08-08 18:40:52 +02:00
enricobuehler	f23e0df64c	fix(host): a compositor pin silently vetoed dedicated game sessions ... `PUNKTFUNK_COMPOSITOR` is documented as "which backend to drive", but it also quietly discarded `game_session=dedicated`: `resolve_compositor` gated the dedicated route on `!overridden` and logged nothing either way. A host whose pin was a forgotten validation leftover therefore went on displaying "dedicated" in the console while every launch landed in the desktop instead — for 30 days on the box that surfaced this, the only evidence being the ABSENCE of a log line. The pin still wins, since it is the operator's explicit hand-set knob, but it now says so and names itself. Two further holes the same triage turned up: - The pin put its backend into `available()` unconditionally AND skipped `apply_session_env`'s `XDG_CURRENT_DESKTOP` scrub, so `pick_compositor` could never return `None` — the one place `try_recover_session()` is called from. A pinned host whose gnome-shell had segfaulted therefore spent every connect on 8 doomed `RemoteDesktop.CreateSession: ServiceUnknown` retries while the operator's configured `PUNKTFUNK_RECOVER_SESSION_CMD` sat unreachable behind that arm. Liveness is now read on both paths, and a pin aimed at a dead session takes the recovery exit with an error naming the pin. `needs_live_session()` exempts gamescope, which stands its own session up — pinning it on a headless box stays supported. - A mode switch accepted before the pipeline existed was served the long way round: build at the now-stale mode, then immediately rebuild at the new one in the stream loop. That burns a display create, capture attach and encoder open on every such connect, and because the rebuild is deliberately create-before-drop it stands up two Mutter `RecordVirtual` monitors ~400 ms apart — which segfaults mutter 50.4 inside `meta_monitor_manager_rebuild` and takes down the whole desktop session, along with the game just launched into it (so the GAME looks like what crashed). Bring-up now adopts the newest queued mode and builds once, carrying over the H2/H3 correction ack that the replaced rebuild would have sent. Verified on a real Linux host (192.168.1.21, x86_64): `cargo clippy --workspace --all-targets --locked -- -D warnings`, `cargo fmt --all --check` and the punktfunk-host + pf-vdisplay test suites all clean. The gate was proved non-vacuous against a planted `compile_error!`.	2026-08-08 17:37:02 +02:00
enricobuehler	8387e48ac6	docs(pf-capture): the fence wait is already free — PW4 retires into this comment ... Wave-2 PW4's outcome. The package proposed moving the producer-fence wait off the PipeWire loop thread, and was pre-registered to be ABANDONED if the wait turned out to already be free. It is, on every producer and vendor measured — including the one where implicit sync actually exists. Steam Deck, RADV VANGOGH, gamescope producer (built in distrobox pf2, run on the host): samples=300 mean_us=23 max_us=48 p50=<=100us p99=<=100us signaled=0 no_fence=300 timed_out=0 failed=0 p99 in the first bucket is the plan's own abandonment condition, and the outcome split explains why: 300 of 300 buffers reported NoFence. Same on both NVIDIA producers (gamescope and Mutter's virtual output — the exact no-explicit-sync case the comment cites as the reason the wait exists). So `wait_read_ready` here is one ioctl and a return, not a block. Moving it to the consumer side would buy nothing measurable and would take on the hazard the package itself names — a slot holding a not-yet-ready dmabuf, and `repeat_last` re-waiting a fence it already consumed. Not a trade worth making for 23 microseconds. The 100 ms budget stays: it guards a producer that DOES fence, which is a real thing even if nothing in this fleet does it. KWin/AMD is the one combination still unmeasured, and the histogram from the previous commit is deliberately kept as the way to re-check — run with PUNKTFUNK_PERF=1 and read the p99 bucket. Comment-only; no behaviour change. Gates green at CI parity.	2026-08-08 16:19:34 +02:00
enricobuehler	fb60bf653e	feat(pf-capture): instrument the fence wait PW4 wants to move, before moving it ... Wave-2 PW4, step one of one-so-far. The package's own first line is "investigation step first (measure, then decide)", and it is pre-registered to be ABANDONED if the wait's p99 is ~0 — so the instrument ships before the change, not after. A per-session histogram of `wait_read_ready`, taken on the PipeWire loop thread, which is exactly where the wait is expensive: that thread is the compositor's consumer, so time blocked there delays buffer recycling for the NEXT frame. Logged under PUNKTFUNK_PERF at the same cadence and gate the encode backends use for their submit splits, so a perf run reads as one instrument: samples, mean, max, p50/p99 bucket, and the Signaled/NoFence/TimedOut/failed split. Buckets are coarse on purpose (100us -> 10ms, plus overflow). The decision this feeds is binary — a p99 in the first bucket means the wait is already free and PW4 becomes a comment correction; a p99 past 1ms is a real stall against a 16.6ms frame budget. Edges are placed so those two worlds cannot be confused, and anything past the last edge reports as overflow rather than clamping into the top bucket ("worse than 10ms" is a distinct finding). The outcome split sits next to the timings because "the wait is short" and "there is nothing to wait for" are different results with different consequences, and one data point already shows the second: on gamescope/NVIDIA the probe reports NoFence, i.e. that producer attaches no implicit fence at all. 5 tests pin the arithmetic, including that an empty histogram reports "no answer" rather than a decisive-looking zero — the failure mode that would retire the package on no evidence. No behaviour change: the wait still happens where it always did. Gates green at CI parity.	2026-08-08 15:47:25 +02:00
enricobuehler	2a1c968a0e	Merge pull request 'A gamescope session told every game its display was 60 Hz — and Fedora had no way to install the build that knows better' (#120) from worktree-gamescope-virtual-display into main ... Reviewed-on: #120	2026-08-08 13:41:30 +00:00
enricobuehler	b815e00a87	fix(pf-zerocopy): one dmabuf timeout condemned every later capture on the host, forever ... Wave-2 PW3. The raw-dmabuf passthrough has two very different reasons to switch itself off, and they shared one `AtomicBool`: * the encoder repeatedly failed to import what this compositor allocates — unrecoverable, a driver fact, and the reason this latch was written (it stops the encode-stall recovery rebuilding the same doomed encoder five times and then ending the session, on every connection, forever); * the dmabuf-only capture offer never negotiated — which can simply mean the compositor was mid-restart. Sharing the flag made the second as permanent as the first. One timeout, and EVERY later session on the host captured CPU frames until the process was restarted — including sessions against a completely different compositor and a different node, which had never failed at anything. Nothing said so; the arm line PW2 added would have shown `cpu` with no explanation. Now the two causes have the lifetimes they should have, in a `RawDmabufLatch` that owns both: * Import failures stay sticky. Unchanged threshold (3 consecutive), unchanged hazard coverage. * Negotiation timeouts get a retry budget of 2 — one retry, deliberately small: each failure costs a ~10 s stall, so a larger budget is paid by the user in dead air. One retry survives the mid-restart transient; a compositor that genuinely never accepts keeps the same identity, so it latches on the second try, one extra stall per host lifetime versus the old behaviour. * A capture that negotiates credits the budget back, so an evening of reconnects against a compositor that failed once cannot accumulate its way into a latch. * BOTH are keyed to a capture identity (node id + portal bit). A new node — fresh virtual output, compositor restart, the Bazzite Gaming↔Desktop switch — is a genuinely different question and earns a fresh dmabuf attempt instead of inheriting a verdict about something else. The SAME capture keeps its verdict, which is what preserves the 10 s-stall protection the latch exists for. The session-open line now carries the latch state, so `cpu` is no longer ambiguous between "this host was never going to do dmabuf" and "something failed earlier and we are still living with the verdict" — only the second is a bug worth chasing, and only the second is now visible as one. Atomics rather than a lock because `note_import_ok` is on the per-frame import path; everything else runs at pipeline build or on failure. The state machine is tested against a local instance rather than the process-wide static — seven tests covering both lifetimes, the identity clear, the same-identity hold, the budget credit, and the cause naming. One honest note on the identity: it is the PipeWire node id, not the "(compositor-id, modifier list)" pair the design sketched. Node id is what capture actually has at that point, and it changes on exactly the events that matter here (new virtual output, compositor restart, session switch). Keying on the modifier list too would need the list before the importer is built, which is the wrong order.	2026-08-08 15:40:55 +02:00
enricobuehler	102f550bba	feat(host): use the new gamescope capabilities, and say so when the mode is lost ... Pass --custom-refresh-rates (patch level 3+) and --pipewire-composite-external-overlay (level 4+) on both spawn paths, with the same probe-then-pass shape the HDR and cursor flags already use. A stock gamescope has neither flag and gets neither, which is exactly today's behaviour. New knob PUNKTFUNK_GAMESCOPE_REFRESH_RATES=60,90,120 widens the set a session offers in Steam's in-session display settings. The rate the session actually runs at is always included, so it can only add options; junk entries are skipped rather than failing the host, because the worst a typo can cost is the extra option the operator wanted. And the part that would have turned a week of field triage into one log line: warn_if_mode_lost(). --nested-refresh is the ONLY refresh a headless gamescope has, and it reaches a gamescope-session-plus solely through the GAMESCOPE_BIN wrapper, which the session script is free to lose — a sessions.d file sourced with `set -a` can reassign GAMESCOPE_BIN, and one that sets GAMESCOPECMD outright skips the whole builder. When that happens the stream still runs, still looks right, and the client's own fps counter still reads the negotiated rate (the encode loop repeats the held frame), while the game underneath is capped to 60. Nothing anywhere said so. It warns rather than refusing, deliberately: verify_managed_spawn_flags refuses because its retry resolves a different plan, but a relaunch here would hand the session the same environment and lose the mode the same way, so refusing would only loop. Fails open on the same rule as the flag check — nothing to compare against says nothing. Also corrects the comment above the launch env, which claimed CUSTOM_REFRESH_RATES "generates the mode the session ADVERTISES … what makes games see the real refresh". It never did: no upstream gamescope has --custom-refresh-rates, so gamescope_has_option gated it off and the variable was inert. That belief is why the real lever went unexamined. configuration.md gains the new knob and a warning on PUNKTFUNK_MAX_FPS, which also lowers the refresh the session REPORTS on gamescope — the docs said it does not cap the stream, which is true of the wire and not of what games are told. Linux-verified on Ubuntu: cargo check --all-targets, clippy -D warnings, 133 tests (2 new), cargo fmt --check.	2026-08-08 15:35:58 +02:00
enricobuehler	608baf63be	Merge pull request 'Post-sleep sessions still failed on 0.25.0 — the host was holding open the very device its recovery asks PnP to cycle' (#119) from worktree-vdisplay-reap-pnputil into main ... Reviewed-on: #119	2026-08-08 13:29:09 +00:00
enricobuehler	2bf571a5ad	feat(pf-encode): PyroWave's Linux encode device never asked for the priority its own patch requests ... Wave-2 PW1, first half = Wave-1 WP14 step 4, executed as specced. PyroWave encodes on the same GPU shader cores a game saturates, and that is measured to hurt: patch 0005's header records `encode_gpu_synchronous` going from ~2 ms to 15-18 ms at 95 % game load, with the stream frame rate collapsing. NVENC is immune because it has its own ASIC. The lever for a compute workload is an elevated global-priority QUEUE — a process-priority raise only reorders submission, not hardware preemption. The vendored patch requests exactly that. It is gated `if (!inherit_info)`, and only Windows leaves `inherit_info` null (`pyrowave_create_device_by_compat`, where Granite builds the device itself). Linux passes its own create-infos into `pyrowave_device_create_info`, Granite's `get_existing_create_info()` hands them back, `create_device` takes the inherit branch — and the whole block is skipped. On Linux the knob has never done anything at all. Meanwhile pf-zerocopy's VkBridge has shipped the identical ladder on Linux for some time and calls it "the actual NVIDIA compute-preemption lever"; the encoder that needs it most did not have it. This wires it natively in `open_inner`'s `DeviceHold`: - The extension probe reuses the `dev_ext_props` already fetched for queue_family_foreign, and takes KHR or the EXT alias — the same spelling pf-zerocopy probes, so the two cannot disagree. - `queue_priority_candidates` is a pure fn with the grammar copied from the C patch: unset → realtime, ASCII-lowercased, `off` alone disables, `high` asks for HIGH only, junk falls back to the ladder rather than to off. One env var must not mean two things on two platforms — that is the documentation trap this package exists to close — so the grammar is unit-tested against the patch's, including where they are both deliberately un-clever (neither trims). - The create ladder is REALTIME → HIGH → no-priority, stepping only on a refusal. A refused class can never fail the open, which matters more here than on Windows: this path is reached only by a NEGOTIATED PyroWave session, so a hard error is a dead stream, not a fallback to another encoder. The subtle part is the write-back. `pyrowave_create_device` RETAINS `device_create_info` for the device's lifetime and Granite reads the chain back. If the ladder ends on the no-priority attempt while `_queue_ci[0].p_next` still points at the global-priority struct, Granite is handed a chain the device was not created with. The `None` arm therefore nulls `p_next` before the final create, and the field's doc says why. The enabled extension deliberately STAYS in the list: it really is enabled on the device, it just carries no request. One deviation from the plan, stated because it is a deviation: the ladder also steps down on `ERROR_INITIALIZATION_FAILED`, not only `ERROR_NOT_PERMITTED_KHR`. The plan and the C patch handle only the latter; pf-zerocopy's shipped ladder accepts both. Given a hard error here kills a negotiated session, treating one extra driver-specific refusal as a downgrade is the cheap side of that asymmetry. Also corrects the two vendored notes, which claimed a Linux behaviour the gate made impossible, and records that patch 0005's negative RTX-4090 result is Windows/WDDM and does not transfer to a different driver stack. Patch hunks are byte-identical (header prose only) and `git diff crates/pyrowave-sys/vendor/` is PUNKTFUNK-VENDOR.txt alone. `PYROWAVE_QUEUE_PRIORITY` is now reachable on Linux, so it is documented in the same PR. MEASURED ON GLASS, and it changes what this package is worth on its own — .21, RTX 5070 Ti, NVIDIA 610.43.02, same binary in both arms: as packaged (no capability) every class refused, REALTIME *and* HIGH -> default priority same binary, cap_sys_nice+ep granted REALTIME on the FIRST attempt, no downgrade So the lever is INERT on an unprivileged host, and that is not the RADV-specific downgrade the plan predicted — on NVIDIA it is a downgrade to nothing at all. The ladder itself is proven good across all three legs (unset / high / off): a refused class never fails the open, and `off` enables no extension and logs nothing. It simply has nothing to grant yet. The privilege needed is CAP_SYS_NICE on the host binary, which is NOT what Wave-1 WP3 ships (RLIMIT_NICE, PAM limits, CPUWeight — all different things). That grant is a security-posture change on a network-facing daemon, so it is deliberately NOT in this commit; the warn line now names the capability so an operator is not left guessing, and the docs row says the setting has no effect on most hosts today rather than implying it works. The loaded-GPU encode_us p99 A/B is therefore not run: it needs a GPU-saturating game (hence a desktop session the box does not currently have) and it is pointless before the capability lands, since the unprivileged arm has no priority to measure. NO unit test is possible for the device-create ladder itself — it needs a real Vulkan device. Its coverage is the clippy pass, the grammar tests, and the on-glass log line. Stated here rather than left for a reviewer to wonder about.	2026-08-08 14:37:41 +02:00
enricobuehler	9c24569db6	fix(spike): --codec pyrowave encoded PyroWave off a capture negotiated for somebody else ... Found while taking PW2's on-glass measurement, and it is what made the measurement possible. `spike` built its capture request from `OutputFormat::resolve`, the constructor shared with the GameStream path, which hard-codes `pyrowave: false` ("GameStream never negotiates PyroWave"). On Linux that flag is not cosmetic: `capture_virtual_output` feeds it to `zero_copy_policy` as `ZeroCopyPolicy::pyrowave_session`, which is what puts the capture on the raw-dmabuf passthrough. So `--codec pyrowave` opened a PyroWave encoder over a capture negotiated for a different consumer, and the only way to exercise the real path was the host-global `PUNKTFUNK_ENCODER=pyrowave` lever. That lever cannot stand in for the per-session flag, which is the part that matters here: it resolves the backend to `Pyrowave`, and `linux_zero_copy_is_vaapi_for` returns true for that — so it ALSO flips `backend_is_vaapi` on. A per-session PyroWave negotiation on an auto/NVENC host, where `backend_is_vaapi` is false, was therefore unreachable from the CLI — and that is exactly the configuration whose CPU downgrade logged nothing at all. The spike now sets the flag from its own codec, the same comparison `session_plan::output_format` makes for a real session. With it, the before/after on .21 is unambiguous: origin/main logs zero capture-path lines on that configuration, this branch logs two (the resolved arm, and the named downgrade with its cause and fix).	2026-08-08 14:08:27 +02:00
enricobuehler	fba22c6c64	fix(host/vdisplay): the host no longer vetoes its own wake-from-sleep recovery — control handles close on retire ... The control-device sharing contract was 'bare HANDLE copies, never closed for the process lifetime': retired handles were deliberately kept alive because the pinger/linger threads and the capture delivery closures held raw copies whose soundness depended on no-close. The cost surfaced in the 2026-08-08 field log: after a wake left the driver hostless, every adapter reload came back REFUSED (Generic failure) — and an open control handle is exactly what vetoes the PnP disable (and can wedge the pnputil restart) the recovery leans on. reset-pf-vdisplay.ps1 stops the whole host service precisely to get those handles closed; the in-process recovery could not, because the process could never close them. Ownership is now Arc all the way out: ensure_device/device_handle/ control_device_handle hand out Arc<OwnedHandle> clones, every consumer holds its clone across its IOCTLs (the capture closures each own one — Arc<OwnedHandle> is Send+Sync, ending the isize smuggling), and retiring drops only the manager's reference, so the handle CLOSES when the last in-flight user drains. DeviceSlot::retired is gone. The recovery path now releases the manager's reference at the first absent sighting — the 3 s ABSENT_SETTLE doubles as the drain window — and again before a not-ready-deadline reload, so the PnP cycle finally runs against a device the host is no longer holding open. The driver attaches no meaning to the control file closing (host-gone is the IOCTL-liveness watchdog, EvtFileClose deliberately unhooked), so the close has no driver-side side effects. Lock order note: RECOVERY → device is now taken (the release hooks); the forbidden inverse still never occurs — VdisplayDriver::open never reloads.	2026-08-08 13:37:05 +02:00
enricobuehler	2aa763ce70	feat(pf-capture): a PyroWave session could drop to CPU capture and log nothing at all ... Wave-2 PW2 (design/linux-host-performance-wave2-pyrowave.md). Observability only — no behaviour change to any capture decision — and it lands first because every later package in the program is measured by an A/B whose "before" is currently unreadable. The defect: the capture path's CPU-fallback warning was gated on `backend_is_vaapi`, which reads the HOST-GLOBAL encoder pref. A PyroWave session is negotiated PER SESSION, so on an NVIDIA/auto host that gate is false — and the session then fell out of every arm of the negotiation log chain, emitting nothing whatsoever while paying a full-resolution CPU pixel touch on every frame. A degraded host and a healthy one produced identical logs. Four sites, matching PW2.1-2.4: 1. The CPU-path warning now asks the per-session question (`consumer_kind`) instead of the pref, and names the consumer. Its gate widened to every GPU consumer and excludes only the software encoder, whose native input IS CPU frames — an NVENC session silently on the CPU path is the same defect, not a different one. `pyrowave_session` deliberately outranks `backend_is_vaapi`, because a PyroWave pref flips `backend_is_vaapi` on too (`linux_zero_copy_is_vaapi_for`'s `Pyrowave` arm), so testing vaapi first would swallow every PyroWave session. 2. The raw-passthrough block in `consume_frame` had four silent exits — no format, an SHM/MemFd buffer, no DRM fourcc, a failed `F_DUPFD_CLOEXEC` — each falling out of three nested `if`s into the CPU de-pad path. It is now a labeled block that breaks with a named `PassthroughFallback`, logged once per distinct reason per session with a running count, so a persistent downgrade is distinguishable from a hiccup at renegotiation. `.process` runs per frame, so the rate limit is the shippable part and is what the tests pin. Note `NoFormat` does NOT fall back — the CPU path needs `ud.format` too and returns — so the line says DROPPED for that one. Three of four downgrade; one loses the frame. 3. `force_cpu_for_nvenc_444` told a 4:4:4 PyroWave session it was "on the NVENC path", which is false in every particular: the wavelet encoder never touches NVENC, never swscales to YUV444P, and what it actually loses is the raw-dmabuf passthrough its design assumes. 4. One INFO line at pipeline build states the resolved arm and consumer (`capture pipeline resolved: dmabuf-passthrough → pyrowave`). Nothing stated it before; the 2026-08-08 triage reconstructed it from four files, and for the arm that matters most there was no detail line to reconstruct it from. Also: `spike --codec pyrowave`, so a PyroWave capture→encode pass can be driven without a client. That is the harness the rest of this program measures on, and it did not exist. Gates on .21 at CI parity: fmt, workspace clippy -D warnings, pf-encode clippy with nvenc,vulkan-encode,pyrowave and without, workspace tests.	2026-08-08 13:36:51 +02:00
enricobuehler	4b514cc07c	Merge pull request 'An OLED palette, and split WHETHER the gamepad UI is offered from WHEN it appears' (#116) from worktree-oled-theme-gamepad-ui-split into main ... Reviewed-on: #116	2026-08-08 11:22:34 +00:00
enricobuehler	f242b2d2fc	fix(host/vdisplay): a refused adapter reload now says WHY, and never targets a phantom devnode ... Field log 2026-08-08 (0.25.0, wake from sleep): every session died on 'the adapter devnode could not be reloaded (Generic failure)' — the WMI catch-all — because the REFUSED branch reported only the Disable exception and threw away everything that would identify the failure mode: why the pnputil /restart-device fallback ALSO failed (its exit code — 3010 'needs a reboot' is its own diagnosis), what state the devnode was in, and whether the right devnode was even targeted. That last one is a real trap, not just missing telemetry: Get-PnpDevice lists not-present PHANTOM devnodes (upgrade/reinstall leftovers), and Select-Object -First 1 could hand every recovery attempt a phantom — whose disable and restart both fail exactly like the field log — while a live node sat unexamined. The selector now prefers present nodes (OK before problem-state), and a phantom-only state gets a truthful refusal: no reload can revive a devnode record whose device is gone; only reinstalling re-creates it. The REFUSED line now carries devnode counts, the chosen node's PnP Status + ConfigManager problem code, and the restart exit code, so the next field log decides between handle-veto, phantom, and problem-state instead of reading 'Generic failure'. Decode pinned by test.	2026-08-08 13:22:05 +02:00
enricobuehler	30bd10e301	feat(clients): an OLED palette, and split WHETHER the gamepad UI is offered from WHEN it appears ... Four changes to the client interface, kept together because two of them touch the same rows and the last is a bug the first would have made far more visible. A thirteenth `ui_palette` entry, `oled`. The palette table is hand-mirrored in three languages (`pf-console-ui`'s `library.rs`, `GamepadPalette.swift`, `GamepadPalette.kt`), so it goes into all three at index 1, directly after the brand default — which keeps `PALETTES[0]` the unknown-id fallback and keeps the dark-to-pale cycling order intact. What earns the name is arithmetic, not a darker shade of violet: the ramp's first two stops are literally (0,0,0) and the ground is pure black, so the shaded half of the field is pixels switched off rather than "very dark grey", and the calm mix the form screens sit under lifts toward nothing at all. Mean cell luminance is 0.019 against Violet's 0.254. The bright corner keeps a faint indigo-to-violet ember so the backdrop is still a field with somewhere to go, and that ember carries enough chroma at that luminance (60 degrees of hue travel across 13 of the 16 cells) to satisfy the existing multi-tone assertion without adding `oled` to the near-neutral exemption Graphite and Opal take. Each port gains an `oled_is_actually_black` test that measures the claim — pure-black corner cells, a mean under half the darkest other field's — rather than restating the table. A new device key, `gamepad_ui_mode`. The gamepad-UI switch had been deciding two things at once: whether to offer the controller-optimized interface at all, and that it appears only while a pad is attached. A user asked for the second half to stop applying. `"connected"` (the default, and exactly what the lone Bool meant) and `"always"` separate them, surfaced as a "Show it" row directly under the switch on all five settings surfaces and built only while that switch is on — a picker whose every option decides nothing is worse than no picker. `GamepadUIEnvironment.isActive` takes the mode with NO default argument on purpose: a call site that forgot it would silently strand everyone who chose Always back on "only with a controller", which is the one bug this parameter exists to make impossible. An unrecognized value waits for a controller, so a mode a newer client wrote can never trap an older one in a layout it has no way back out of. It stays a device preference on both platforms, never part of a profile: which interface this device wears has nothing to do with how a host streams to it. The smoothness buffer is hidden under Lowest latency, not dimmed. Everywhere else already hid it — the GTK and WinUI shells, the Apple touch and tvOS screens, the Android touch screen — because under that intent it names a quantity that does not exist. Two surfaces disagreed: Apple's gamepad settings screen left the row live and steppable, and the desktop console dimmed it, having no way to drop a row from a fixed list. That list is now rebuilt each frame through a `row_applies` filter. The concern about a vanishing row moving everything under the cursor does not apply here and the new test says why: the row it drops sits directly BELOW the row that drops it, so the only cursor that can be present when the list shrinks is the one on the intent row, which does not move. Two latent hazards went with it — `apply_row` had been indexing the row list on the assumption the cursor is always in range, and nothing re-clamped that cursor when another writer changed the intent behind the screen's back. Pale palettes were unreadable on tvOS, reported from the field. `GamepadInk` was never the problem: it flips correctly for a pale field, it is not platform-gated, and every tvOS gamepad entry point already published it. The cause is that this app sets `preferredColorScheme` nowhere and declares no `UIUserInterfaceStyle`, so every SYSTEM-derived colour landing on those screens — a `.secondary` placeholder, a `.bordered` button's chrome, a NavigationStack title, a material's frost — resolved against the DEVICE appearance, which the palette cannot reach. On iPhone, iPad and Mac a great many users sit in Light mode, so under a pale palette those colours came out dark and the theme looked correct by accident; an Apple TV is Dark essentially always, so every one of them rendered white on a light field. The mirror image was broken too and had simply never been reported: a dark palette on a Light-mode iPhone was already drawing dark on dark. The scheme is now published beside the ink, once, in `GamepadInkModifier`, because the two are halves of one decision and publishing only the ink silently loses every colour the frameworks draw on the app's behalf. Two structural amplifiers went with it: `ConsoleGlass` had been scoping the scheme to the fill inside its `.background {}` on the tvOS and pre-26 branches while the 26 branch put it on the content, so no console row's own content ever saw it on tvOS; and `LibraryView`'s navigation chrome and its loading, error and empty states sit above `LibraryCoverflowView` and so were never inked at all on tvOS and macOS, where that view is presented directly rather than through the iOS-only `GamepadLibraryScreen` wrapper. That last one exposed a second tvOS gap worth closing in the same breath: `ui_palette` had no row in tvOS's ordinary Settings, and the gamepad settings screen that owns it everywhere else needs an extended-profile controller to open on tvOS. An Apple TV driven by the Siri Remote alone could not reach the palettes at all, which would now include the OLED one. `SettingsView.tvBody` carries a Background row. Verified: pf-console-ui builds, passes `clippy --all-targets -D warnings` and runs 74 tests clean under linux/amd64 (a Mac `cargo check` of that crate is vacuous — every module is cfg'd to linux/windows); `cargo fmt --check` clean for it and pf-client-core. Android `:app` runs 80 tests with 0 failures, including four new `gamepadUiActive` cases and the palette parity table. The Apple package builds for macOS AND tvOS and its 9 palette/gamepad-UI tests pass — the tvOS typecheck is possible because the checked-in xcframework already carries a `tvos-arm64` slice. The tvOS RENDERING fix is compile-verified only; an on-glass Apple TV check under a pale palette is still owed, and is the one thing here that a build cannot answer.	2026-08-08 12:57:12 +02:00
enricobuehler	e4f8c64b9f	Merge pull request 'Library scanners sat in the nav and could not sync local art — and you can now hide one game' (#113) from worktree-plugin-nav-category-and-art into main ... Reviewed-on: #113	2026-08-08 10:39:25 +00:00
enricobuehler	6cffe29b13	feat(host,console): hide individual library titles ... The library had one visibility control and it was all-or-nothing: turn a SOURCE off and every one of its games goes. There was no way to drop a single title — a Proton tool the filter missed, a demo, a game someone doesn't want on the TV — short of hiding the whole launcher it came from. **Where the setting lives.** Not on the entry. Only manual custom entries are stored; a scanner's and a plugin's titles are rebuilt from scratch on every scan and every reconcile, so a flag written onto one would be erased by the next sync — silently, and minutes later, which is the worst possible shape for a setting. So `library-hidden.json` holds the ids, mirroring how `library-scanners.json` holds disabled sources. The id is stable by construction (D2: a claimed store's entries keep `<store>:<external_id>` across reconciles), so a hide survives a re-scan, a plugin restart, and a store's built-in→plugin migration. **Where it takes effect.** In `all_games`, which is the one place every play surface already funnels through — the grid on a client, native clients, the GameStream app list, and launch resolution. Putting it there rather than at each call site is deliberate: a per-surface filter is a rule someone has to remember, and forgetting one is precisely the class of bug the `file://` art asymmetry in the previous commit was. Hiding is curation, not access control — nothing is deleted, and un-hiding is instant. **The console is the one surface that still sees them**, or a hidden title could never be brought back. That exception is a TYPE, not a flag: `GET /library` answers `Vec<GameEntry>` on every lane but the operator's and `Vec<OperatorGameEntry>` on theirs, so a hidden entry cannot reach a paired streaming client by someone forgetting a filter — there is no field there to leak. `hidden` is skipped when false, so the response is byte-identical to today's for a library with nothing hidden. `PUT /library/hidden/{id}` is operator-only — neither the plugin lane nor a paired cert, unlike the scanner toggle. A plugin has no business deciding what its operator sees, and a client must not be able to hide a game on the host it is streaming from. The id is not validated against the current library on purpose: a title can be legitimately absent at that moment (launcher closed, plugin mid-sync, drive unmounted), and refusing the operator's choice in that window is worse than storing an id that matches nothing today. On the card, the poster dims and a Hidden badge says why — a faded tile with no label reads as a broken cover. Its controls stay at full contrast and, unlike an ordinary card's, are not hover-revealed: the un-hide button is the only way out of the state, and hiding it behind a hover would strand anyone on a touch screen. Verified on .21 (Linux): 469 host tests pass (5 new), clippy clean under `-D warnings`, `cargo fmt --all --check` clean. The routing test is the one that earns its keep — every library id contains a colon and Heroic's contain two, so a router that split on it would 404 the console against ids the host itself produced. Console: tsc clean, production build clean, i18n 633 messages across en+de, biome clean on the touched files.	2026-08-08 12:33:54 +02:00
enricobuehler	975fef2048	fix(host/vdisplay): the ghost-monitor reap can no longer fail in silence ... The reap that keeps departed virtual monitors from exhausting the IddCx monitor-slot budget launched pnputil by BARE NAME — under the LocalSystem service's PATH that can miss System32, SilentlyContinue swallowed the miss, and the Rust side logged only when the count was positive: a reap that removed nothing and a box with no ghosts were byte-identical (silence). Ghosts then ratcheted up with every sleep cycle until IOCTL_ADD wedged at 0x80070490 and every session black-screened — and the wedge self-heal shipped in 0.25.0 retried an ADD behind a reap that could never remove anything, which is exactly a persistent post-sleep "no connection" surviving the b6acbd09 probe fix. Same family and same cure as the adapter-reload path one function down: resolve pnputil via $env:SystemRoot (a SYSTEM process must not trust PATH anyway — a planted pnputil.exe would run elevated), pre-seed $LASTEXITCODE to failure before every launch, and report found AND removed unconditionally so "no ghosts" and "removed nothing" are finally distinguishable in a field log. The report parse is split out and pinned by tests like classify_reload_output.	2026-08-08 12:19:48 +02:00
enricobuehler	9089651406	Merge pull request 'The jitter ring only ever learned from clicks — it now grows on near-misses, un-does refused shrinks, and cashes growth on the click it already paid' (#111) from worktree-audio-jitter-lowwater into main ... Reviewed-on: #111	2026-08-08 10:11:10 +00:00
enricobuehler	d237646c66	fix(host,sdk,kit): library scanners sat in the nav, could not sync local art, and so never got their settings ... Three symptoms on .21, two defects. Lutris and Heroic appeared in the console sidebar they explicitly opt out of; Lutris's settings were unreachable from the Library screen; and Lutris and Steam logged `sync (startup) failed: HostRequestError`. **The sidebar is a publish gap.** The console is correct — it keeps `category: "library"` plugins out of the nav (`uiPlugins`, app-shell.tsx) — but the host reports no category for them at all. `defineLibraryPlugin` sets it and `sdk/src/ui.ts` forwards it; what SHIPS does not. `@punktfunk/host` was bumped to 0.1.2 on 2026-07-20 and `category` landed 2026-08-05 without a bump, so the registry's 0.1.2 is the pre-category build and every installed scanner registers without one. Bumps the SDK to 0.1.3 — **inert until it is published**. Because the field rides the untyped `pf.request` seam so an older host ignores it rather than rejecting the registration, dropping it is silent by design. `serveUi` now reads its own directory entry back and warns once when a requested category did not land, the same way `defineLibraryPlugin` already warns when a store claim did not take. That is what turns the next occurrence into a log line instead of a bug report. **The missing settings and the failed sync are ONE defect: a write/read disagreement about `file://`.** `local_art_bytes` decodes a `file://` value before testing containment; `validate_art_paths` handed the raw value to `Path::new`, where `file:///home/u/c.jpg` is a RELATIVE path whose first component is `file:`. It canonicalized against the cwd, failed, and read as "outside every art root". So the host refused every cover the kit's own `fileUrl` helper emits — the documented way for a plugin to publish local art — while the read path would have served those same files. That the two symptoms share a cause is not obvious and is why this is one commit: the Library screen's settings control renders only for `origin: "plugin"`, and a source becomes `plugin` only once it holds a store CLAIM, which is taken during a successful reconcile. Lutris failed at entry 0 and Steam at entry 3, so neither ever claimed its store, both stayed `origin: "builtin"`, and neither got a settings button. Heroic reconciled (its art is http(s)) and has had its settings all along; rom-manager was never affected because zero entries meant it never applied. `art_path_is_servable` now decodes first, so both halves of the confinement judge the same string. Confinement itself is unchanged: an out-of-root path is still refused in `file://` clothing, which the test asserts alongside the accept case. Diagnosing this took the HOST's journal, because both surfaces that should have explained it lied. `HostRequestError` stringified to its bare tag, so the sync engine's `${e.cause}` logged `HostRequestError` and discarded the method, the path and the host's own message; it now renders all three, including an object-shaped cause that used to print `[object Object]`. And the host logged "payload carries a field this lane may not set" for BOTH refusals in `check_entry_fields`, so a 400 about an art path read as an auth problem — it now logs the real reason and the entry title. Verified on .21 (Linux): 463 host tests pass, clippy clean under `-D warnings`, `cargo fmt --all --check` clean. The new art test fails without the fix and passes with it. plugin-kit 71 and SDK 72 tests pass, both typecheck clean, biome clean.	2026-08-08 11:43:30 +02:00
enricobuehler	69728b6f4e	fix(pf-presenter): "Native resolution" streamed the compositor's POINTS, not the panel's pixels ... A CachyOS / KDE Plasma 6.7.4 Wayland client with its 2560x1600@165 laptop panel at 150 % scaling negotiated 1706x1066 for "Native resolution" and streamed a visibly blurry image. Two independent defects, and they stack — which is why forcing the mode to 2560x1600 by hand did not fully fix it either. 1. `SDL_GetDesktopDisplayMode` reports a mode in SCREEN COORDINATES and hands the pixels-per-point ratio back separately as `pixel_density`. We read `m.w`/`m.h` raw. KDE advertises that panel as 1707x1067 points with a density of ~1.4997, `render_scale::apply` even-floors both odd axes, and 1706x1066 goes on the wire — exactly the mode in the reporter's handshake log. Multiplying by the density recovers 2560x1600 to the pixel, because SDL derives it as the output's exact pixels/points ratio. On X11 and Windows SDL never sets a density and `SDL_video.c` normalizes the unset 0.0 to 1.0, so this is inert there: the bug needed a compositor doing FRACTIONAL scaling. 2. The SDL window was created without `HIGH_PIXEL_DENSITY`, so the Wayland surface stayed at buffer scale 1 — the Vulkan swapchain was built at 1707x1067 and KWin upscaled it to the glass. Even a correct 2560x1600 stream was resampled down and then back up. The same flaw silently shrank "Match window", which asks the host for `size_in_pixels()`. The reporter's `SDL_VIDEO_WAYLAND_SCALE_TO_DISPLAY=1` workaround is this same fix applied from outside SDL, which is why it helped. The surrounding code was already written for pixels != points — the swapchain, match-window and pointer mapping all read `size_in_pixels()` while window-size persistence reads logical `size()` — so the flag only makes those two stop being the same number. `display_scale()` starts reporting 1.5 into a swapchain that is 1.5x larger, leaving the OSD the size it already was. Also closes a smaller hole on the way past: only an `Err` from SDL reached the 1920x1080 fallback, so a display that reported a 0x0 mode sent a 0x0 request. Verified on home-worker-5 (CachyOS — the reporter's distro, real SDL 3.4.14): `cargo clippy --all-targets -p pf-presenter -- -D warnings` clean and 18/18 pf-presenter tests pass, three of them new and pinned to the field-reported numbers.	2026-08-08 11:15:58 +02:00
enricobuehler	3bb87d260e	fix(audio): detect jitter before it is audible, and stop re-probing a depth the link just refused ... The 0.25.0 MacBook field report — audio jitter 'at certain points' — is the jitter policy learning exclusively from audible failures, on both of its sides. Growth needed THREE audible underruns before deepening the ring; the A/V sync loop re-tested a shallower ring every five quiet seconds and paid an audible starvation event every time it was wrong, forever; and a grown target was never re-banked — growth raises a threshold, only a re-prime deepens the ring — so a bunching link rode the knife edge, clicking once per bunching period with the 'grown' target sitting inert. A ten-minute simulation of the Wi-Fi power-save pattern (25 ms gaps / 300 ms, −50 ppm skew) measured ~2000 audible events under the shipped policy. Three mechanisms, in JitterPolicy (Linux/Windows/Android) and mirrored in the Swift AudioRing: - NEAR-MISS: a read served with less than one protocol frame left over is the same evidence as an underrun, heard by no one. It grows the target one step per window, BEFORE the click — waiting for the third audible underrun means the user heard two. - SHRINK PROBES: every shrink is armed for five seconds; answered by an underrun or near-miss it is undone on the spot, and a failed sync-driven shrink is not retried for a doubling backoff (60 s → 8 min). A probe that survives resets the backoff. Continuity outranks sync, now with a memory. - HOLLOW RE-PRIME: an underrun while the depth AVERAGE runs more than a step below the target re-primes immediately, spending the click it already cost on the whole refill instead of limping. The average, not the instant, is what separates a hollow ring from one late packet, and it is seeded on prime so a fresh ring is never spuriously hollow. Same simulation after: 9 audible events, tail clean but for the clock-skew re-anchor (a genuinely slow host must re-bank every few minutes; only rate adaptation would remove that, and no client has it). Neutralising the three constants reproduces the ~2000 — the convergence tests fail against the old behaviour. Verified: 203 punktfunk-core tests, 254 Swift tests (5 skipped), clippy -D warnings on punktfunk-core --all-features, cargo fmt --all --check.	2026-08-08 11:05:53 +02:00
enricobuehler	86bb09e2cf	Merge pull request 'Arch could upgrade FFmpeg out from under the host and brick it — and the host now builds against FFmpeg 9' (#108) from worktree-ffmpeg9-support into main ... Reviewed-on: #108	2026-08-08 00:41:33 +00:00
enricobuehler	deeb8b6700	feat(pf-encode): build against FFmpeg 9 ... ffmpeg-next 8.1.0 could not accept FFmpeg 9 at all: ffmpeg-sys-next's version probe covered avcodec majors 56..62 (the range is exclusive of its end), so libavcodec 63 fell outside what it knew how to bind. 9.0.0 widens that to 56..63, which is what actually unblocks Arch. Bump both pins — the unconditional Linux dep and the optional Windows amf-qsv one — and the lock with them. No API drift to fix. The crate major is a CEILING, not a target: one source tree still spans FFmpeg 7.x/libavcodec 61, 8.x/62 and 9.x/63 via per-version cfgs, and every wrapper symbol the NVENC-libav, VAAPI and amf-qsv backends name survives 8.1.0 -> 9.0.0 unchanged. The three hand-written #[repr(C)] hwcontext mirrors are the parts no compiler checks, so they were re-read against the real headers rather than trusted: AVCUDADeviceContext and AVD3D11VAFramesContext are byte-identical across 7.1/8/9, and AVD3D11VADeviceContext gained two trailing UINTs in 8 that 7.1 lacks — which is why that mirror deliberately stops at the common prefix, and why its assertions now say what they do and do not buy you. They pin our layout, not libav's; a green build is not evidence. The CI image is the step that makes this reach users. arch.yml deliberately runs no -Syu ("the image's snapshot IS the build environment"), so the builder stayed frozen on ffmpeg 8 no matter what Arch shipped, and a canary built from that snapshot could not satisfy the soname dep the PKGBUILD now derives. Re-keying ci/ rebuilds it against ffmpeg 9. Ubuntu and Windows deliberately stay put: the noble .deb bundles its own FFmpeg 8 behind an rpath and strips the libav sonames from its Depends, and Windows bundles BtbN DLLs into the signed installer — neither is exposed to the break, BtbN publishes no FFmpeg 9 build, and moving either would re-qualify an encode stack to buy nothing. Verified end to end on 192.168.1.21 (CachyOS, system ffmpeg 2:9.0-5, RTX 5070 Ti): host builds clean and links libavcodec.so.63/libavutil.so.61/libavfilter.so.12/libswscale.so.10 with no unresolved sonames; the ffmpeg-8 compat shim is gone and the service runs with NRestarts=0 and answers 401 on :47990; pf-encode's 67 tests pass; and a live synthetic encode drives real NVENC hardware through FFmpeg 9's libavcodec to a decodable 1080p HEVC stream (180/180 frames, FEC loopback 0 mismatches) with libavcodec.so.63 and libnvidia-encode both mapped into the encoding process.	2026-08-08 02:35:20 +02:00
enricobuehler	cabd011f1d	Merge pull request 'The 272 ms audio buffer was legal: the PipeWire callback filled the buffer ceiling, not the graph's request' (#106) from fix/pw-playback-requested into main ... Reviewed-on: #106	2026-08-08 00:12:02 +00:00
enricobuehler	be86cfcdc0	fix(client/audio): the PipeWire callback stops filling the buffer ceiling every cycle ... The playback process callback sized its writes from the mapped buffer's capacity — PipeWire's quantum-limit, 8192 frames ≈ 170 ms — instead of the graph's per-cycle ask (pw_buffer.requested). Every cycle therefore queued up to 170 ms of PCM downstream of the ring, and, worse, taught JitterPolicy that the device drains 170 ms per callback: the underrun floor (want + one frame) rose above any depth the A/V sync loop may request, so sync measured audio ~280 ms late and was forbidden — by its own continuity rule — from draining it. The first on-glass run of the latency overhaul showed exactly that: audio buffer 272 ms, a/v +284 ms, stable. Honor requested (capacity remains both the ceiling and the fallback for requested == 0), and log requested-vs-capacity once per stream in the shape of the host's per-capture-open quantum line, so the next on-glass report can say which one is sizing the writes. Needs libpipewire >= 0.3.49 (2022-03) for the requested field; every ship target clears that. Verified on .21: cargo clippy -p pf-client-core --all-targets -D warnings clean, 167 tests pass, fmt clean.	2026-08-08 02:04:15 +02:00
enricobuehler	e9e1ec7dc5	fix(pf-inject): the DualShock 4 Windows backend never imported OFF_INPUT ... The Windows host does not build: error[E0425]: cannot find value `OFF_INPUT` in this scope --> crates\pf-inject\src\inject\windows\dualshock4_windows.rs:65:48 error: could not compile `pf-inject` (lib) due to 1 previous error `dualshock4_windows.rs` writes the neutral report straight to `OFF_INPUT` in its bootstrap path — correctly, and exactly as the DualSense and Steam Deck backends do: the devnode does not exist yet at that point, so there is no reader to race and no seqlock to take. Its steady-state path already goes through `publish_input`, which is the v2.3 seqlock. But the import list only names `publish_input`. `steam_deck_windows.rs` imports `OFF_INPUT` explicitly for the same bootstrap write; this one was missed when the list was edited to add `publish_input`. One word in a `use`. No behaviour. WHY CI DID NOT CATCH IT: `pf-inject`'s Windows backends compile only for `*-pc-windows-msvc`, and the crate is host-side, so the client Windows workflow never touches it. A cargo check from a Mac cannot stand in either — pf-inject pulls punktfunk-core and therefore ring, whose C build wants MSVC headers, so the cross-check dies in cc-rs long before it reaches this file. FOUND BY: running windows-host.yml's own build line on the CI runner (.133) against the v0.25.0 release tree before tagging — `cargo build --release -p punktfunk-host --features nvenc,amf-qsv,qsv`. It fails at `pf-inject`, which is step 1 of the host job, so a v0.25.0 tag would have produced no Windows host binary, no installer, and no host asset on the release.	2026-08-08 01:43:11 +02:00
enricobuehler	7f82bca9c0	fix(pf-dxvadec): a wrapped sentence turned "6." into an ordered list ... A doc paragraph in `pic_av1.rs` wrapped so that "first at frame / 6. Releasing…" put `6.` at the start of a line. rustdoc reads that as an ordered-list item starting at 6, which makes the following unindented `///` line a lazy continuation — `clippy::doc_lazy_continuation`, denied by `-D warnings`. Reflowed so the number cannot begin a line. Prose is byte-identical in content; only the wrap points move. No code, no behaviour. WHY THIS MATTERS FOR THE TAG. `pf-dxvadec` is Windows-only, and no Windows leg runs on a push to main — so main being green proves nothing about this. The failure surfaces for the first time in a release tag's fan-out, which is exactly what happened to the FIRST v0.23.0 tag: it went red on Windows clippy for this same lint, and the cure was a tag re-point. Caught pre-tag by re-running the lazy-continuation scanner over the tree while preparing v0.25.0 (0 hits before this commit's parent merged the new decode crates, 1 after). Cannot be verified by compiling here — the crate does not build on macOS — so the evidence is the scanner plus the lint's own rule, not a clippy run.	2026-08-08 01:25:59 +02:00