3033 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
enricobuehler	6f81ec24ba	fix(ci): gate C counts comments, and a comment named the env mutators verbatim ... 55a3d8b9 (#181) added the edition-2024 lint-level rationale to the session bin's header naming std::env::set_var/remove_var — gate C's grep counts comments by contract, so main went red at 5 mentions against the 4-call-site baseline. Reword the comment instead of raising the baseline: a baseline of 5 with one comment inside would hide the next real call site. Verified: scripts/ci/check-unsafe-hygiene.sh clean, cargo fmt clean.	2026-08-12 18:57:07 +02:00
enricobuehler	539236de91	Merge pull request 'feat(pad-audio): Linux hosts stream pad audio — the per-pad PipeWire sink (WP3)' (#182) from worktree-linux-pad-audio into main	2026-08-12 16:55:06 +00:00
enricobuehler	118758ff0b	fix(pad-audio): the Linux pad sink speaks GE-Proton's AUX0-3 channel shape ... A field report (GE-Proton 11-5, real DualSense on-host) surfaced the missing constraint: haptics only work when the pad's card runs the Pro Audio profile — because GE's route opens the node through its bundled pipewire-alsa plugin with aux_channels=1, and its pulse fallback forces a PA AUX0..3 map with stream.dont-remix (proton-ds5-haptic patches 0013/0115/0116: "the hidden PipeWire parent for a DualSense output exposes AUX0 through AUX3"). A positioned FL FR RL RR sink puts those writers through position channelmix instead of index passthrough. The sink now advertises AUX0..AUX3. Proven on the box: an AUX-mapped rear-pair-only tone captures index-exact (speaker pair 0.0000, coil pair 0.3662); a positioned stray stream folds into the speaker pair and never excites the coils. The devtest reports per-pair peaks so exactly this class of remix bug is visible. Also confirmed from the GE patch set while here: device matching is device.bus/vendor.id/product.id + the Sony/Wireless_Controller name substrings (both of which the sink carries), and the MMDevice container is now synthesized from the wine-side HID USB parent (patch 0112) — the old pure-PW-node GUID_NULL concern no longer applies on GE >= 11-4.	2026-08-12 18:53:35 +02:00
enricobuehler	dcde856178	feat(pad-audio): Linux hosts stream pad audio — the per-pad PipeWire sink (WP3) ... The 0xD1 plane was Windows-host-only: host_cap() answered false and spawn() was a stub everywhere else, so an Android tier-A client against a Linux host negotiated the cap off and stayed on wire rumble. The whole downstream machinery (framer, silence gate, lanes, 0xD1 send) was already capture- agnostic — only the capturer was WASAPI. - audio/linux/pad_sink.rs: one Audio/Sink stream node per DualSense-family pad, minted with the identity the matchers read (ALSA-style node.name with the pad's pairing MAC, description "Wireless Controller", bus/vendor/ product/form-factor proplist, per-pad serial), 4-ch F32 48 kHz FL FR RL RR, no default-sink claim, priority.session 50. The process() callback IS the capture. PUNKTFUNK_PAD_SINK_NAME/_DESC override the strings for field debugging ({pad}/{mac} expand). - native/pad_audio.rs: the shared logic and lanes compile on Linux; pad_audio_thread is generic over the capturer (open-with-backoff kept); host_cap() Linux arm = client asked + PUNKTFUNK_PAD_AUDIO + a reachable PipeWire socket; spawn() Linux arm mints the sink lazily in the streamer thread. spawn() gains an edge flag (Edge identity; ignored on Windows). - devtest pad-sink-test: mint one sink and capture from it, no client — the WP3 on-glass gate. Verified on a Bazzite 44 host: identity served through pipewire-pulse, rear-pair (voice-coil) tone captured bit-exact over both the native and pulse legs. - docs: PUNKTFUNK_PAD_AUDIO{,_SLOTS} are no longer (Windows); the roadmap non-goal narrows to Bluetooth client pads. Gates (fedora:44 container, natively on the .41 box): cargo build --release --locked (nvenc+vulkan-encode), clippy --all-targets -D warnings, cargo test pad_audio+pad_sink 11/11, cargo fmt.	2026-08-12 18:53:35 +02:00
enricobuehler	77918674c3	Merge pull request 'An over-declared HEVC level no longer demotes native Vulkan decode, and the Windows client legs build again' (#181) from worktree-vk-level-gate-clamp into main	2026-08-12 16:48:56 +00:00
enricobuehler	faefbae830	fix(pf-presenter): spell MAKEINTRESOURCE(1) as ptr::without_provenance — clippy 1.96's manual_dangling_ptr reads the integer-ordinal cast as a dangling pointer and fails the Windows -D warnings gate (masked on main by the client bins failing to build first)	2026-08-12 18:47:45 +02:00
enricobuehler	44fa12a298	test(pf-vkdecode): bind the PTL level reads so the SAFETY comments precede their unsafe blocks (clippy::undocumented_unsafe_blocks counts nothing inside macro arguments)	2026-08-12 18:47:45 +02:00
enricobuehler	55a3d8b919	fix(clients/session): the edition-2024 session bin cannot build on Windows ... The half of the #177 fallout #180's follow-up could not reach: WP20 wrapped the session bin's single-threaded-startup env writes in the `unsafe {}` blocks edition 2024 requires — under `#![forbid(unsafe_code)]`, which no inner attribute can override, so `punktfunk-client-session` fails with two hard errors on every Windows leg (main push runs 17615/17616 red at Build; verified on .173). Same resolution as #180 gave the GTK shell: `forbid` becomes `deny`, and the three documented SAFETY sites carry the localized `#[allow(unsafe_code)]` pf-update models.	2026-08-12 18:47:45 +02:00
enricobuehler	a02014ec19	fix(pf-vkdecode): treat an over-declared stream level as a clamp, not a refusal ... A 2026-08-12 field report (RTX 5060 client): every HEVC session demoted to D3D11VA with 81 "outside device caps: stream level (Std code point 12) above the device's maxLevelIdc (H.265 Std level 11)" refusals — the host's AMF encoder stamps general_level_idc 6.2 (the codec maximum) on a 4K120 stream that needs 5.2, and NVIDIA's driver caps H.265 decode at 6.1. The hardware decodes the actual stream trivially; only the declaration was oversized. AV1 passed the same gate, which is why "native-vulkan runs only with AV1". The declared level is a claim, and the stream's real demands are enforced where they are physical facts — coded extent and DPB depth, both checked at session build. So the up-front level gate (H.264 + H.265) now warns once and proceeds, and every SPS/VPS handed to the Vulkan parameters object has its level clamped to the device ceiling (a set above maxLevelIdc is invalid usage). AV1's gate is untouched: its code space is the bitstream's own and no over-declaration has been seen in the field. Verified on .173 (RTX 4090, driver 610.88): HEVC and AV1 both decode on the native Vulkan rung at 60 fps against an NVENC host; unit tests pin the clamp (lowers, only lowers, mutates the driver-visible block in place).	2026-08-12 18:46:57 +02:00
enricobuehler	5f55b820bc	Merge pull request 'Edition-2024 follow-up: the three gates only the PR's own CI could reach' (#180) from worktree-edition-2024 into main	2026-08-12 16:34:13 +00:00
enricobuehler	57703fe31c	Merge remote-tracking branch 'origin/main' into worktree-edition-2024	2026-08-12 18:30:50 +02:00
enricobuehler	90a3304c2b	Merge pull request 'The Windows host no longer blocks system sleep while idle' (#179) from worktree-win-sleep-blockers into main ... Reviewed-on: #179	2026-08-12 16:30:11 +00:00
enricobuehler	017867f211	fix(ci): the gates the PR run reaches and the boxes could not ... - adl_emul.rs adl_malloc: panic-free (a reachable expect in an extern fn is an abort — gate B; the Err arm is unreachable, ADL treats null as failure) - punktfunk-host main.rs: reword the carve-out comments so gate C's textual count stays at its baseline (comments count) - clients/linux: forbid(unsafe_code) -> deny with two named allows — the SDL device-filter clear and the spawn test's HOME scoping are unsafe calls in edition 2024 (caught by the aarch64 leg, the only one with glib)	2026-08-12 17:44:15 +02:00
enricobuehler	ef0af3b558	docs(changelog): the Windows host no longer blocks system sleep while idle	2026-08-12 17:41:08 +02:00
enricobuehler	535e95c4c0	fix(punktfunk-host): idle-stop the virtual-mic stream so a Windows host can sleep ... The mic pump's WASAPI backend rendered silence into the virtual mic's render endpoint (typically the Steam Streaming Microphone) for the whole host lifetime. A RUNNING stream makes the Windows audio stack hold a kernel power request ("An audio stream is currently in use", visible in powercfg /requests), so every idle Punktfunk host blocked system sleep forever — field-reported 2026-08-12 ("doesn't go to sleep anymore since installing punktfunk; powercfg shows the Steam Streaming Microphone"). Stop the render stream (IAudioClient::Stop — client stays initialized, the mic endpoint keeps existing) after 10 s of silence-only output at an unchanged queue length, and park the render thread on a condvar the producer notifies on the empty->non-empty edge, so the next mic frame resumes the stream within one device period — well under the jitter buffer's prime depth, so nothing audible changes. Keying the idle window on the queue LENGTH (not emptiness) also covers a sub-prime tail a vanished client left behind, while any fresh burst moves the length and resets the window instead of being dropped. During a session the box stays awake through the session's own DisplayWakeRequest (pf-frame), never through this silence. PUNKTFUNK_MIC_ALWAYS_ON=1 restores the old always-running stream in case a virtual audio driver misbehaves while its render side is paused.	2026-08-12 17:39:22 +02:00
enricobuehler	b385f0a031	Merge pull request 'Rust edition 2024: the whole tree, with the env-mutation class made visible (WP20)' (#177) from worktree-edition-2024 into main ... Reviewed-on: #177	2026-08-12 15:38:22 +00:00
enricobuehler	7528fd48a9	Merge pull request 'A stats tier picked between streams reached nothing until the app was restarted' (#178) from worktree-console-stats-tier-relatch into main ... Reviewed-on: #178	2026-08-12 15:38:03 +00:00
enricobuehler	c68e0be688	Merge remote-tracking branch 'origin/main' into worktree-edition-2024	2026-08-12 17:27:27 +02:00
enricobuehler	71c1970b93	fix(client/console): a stats tier picked between streams reached nothing until a restart ... Field report: "no matter what I select the stats overlay is stuck showing as detailed" on the Deck, cured by restarting the client app. The console (Gaming Mode, and therefore Decky) builds its window and its run loop ONCE and streams every session through them, and the loop took its stats tier from the settings snapshot read at process start. Its own settings screen writes the chosen tier to the file and redraws its row, so the choice looked taken while every stream kept the tier the process happened to start on — Detailed for anyone who had been on Detailed. Only a restart re-read it. The desktop shells were never affected: they spawn a session process per stream, which resolves settings for itself. The tier now rides `SessionParams` per launch, so browse mode adopts what THIS launch resolved and the start-of-process value only seeds the loop until the first stream. Two things fall out of resolving per launch rather than per process: a profile bound to a host can finally move the tier in console mode (part of the documented P4 gap), and the adoption sits in the `Start` arm rather than `StreamState::new`, so the codec-fallback retry can't snap the overlay back and undo an in-stream cycle. The `--stats` rule (a floor that lifts Off to Normal and demotes nothing) was written out three times and is now one tested helper. The rest of the console's latched presentation tier — touch and mouse model, shortcut inhibit, match-window, render scale — is unchanged and still needs the models rebuilt per launch. Gate: clippy --all-targets -D warnings, plain build, and tests for pf-client-core, pf-presenter and punktfunk-client-session, all green in pf-lxcheck2 (linux/amd64); clippy proven non-vacuous by touching the four edited files. cargo fmt --all --check clean.	2026-08-12 17:26:33 +02:00
enricobuehler	f373dffb5e	chore: migrate the main workspace and pf-vkhdr-layer to edition 2024 (WP20) ... The safety half of the rust-safety programme's §8.4: `std::env::set_var`/`remove_var` are `unsafe fn` in edition 2024, converting the class of bug the programme found the hard way (the 972af299 environ data race lived in a file with ZERO occurrences of the word `unsafe`) from invisible to counted and compiler-enforced. Manifests: [workspace.package] edition 2021→2024, rust-version 1.82→1.85 (the pinned toolchain is 1.96.0, so no toolchain bump — only the declared floor rises); the 13 crates pinning `edition = "2021"` literally now inherit it (Trap 1: the root bump alone reaches only `edition.workspace = true` crates and would have left pf-encode/pf-capture/pf-inject et al. on 2021 while reading as complete); pf-driver-proto's stale rust-version 1.82 pin now inherits; pf-vkhdr-layer (a separate workspace, inherits nothing) bumped to 2024. The four vendored crates (fec-rs, cros-codecs, usbip-sim, the patched ndk) stay on 2021 deliberately — upstream code stays pristine. The excluded usbip-poc standalone PoC is untouched. Mechanical, done textually across ALL cfg branches so no platform's half is left behind (Trap 3 — 44% of the host's unsafe is Windows-only and a one-platform `cargo fix` misses it): 148 `#[no_mangle]` → `#[unsafe(no_mangle)]` (83 in abi.rs); 12 bare extern blocks → `unsafe extern`; `gen` is a reserved keyword, so pf-vdisplay's generation stamps (registry.rs, windows/manager.rs) and the WinUI shell's animation counters rename gen → generation (internal identifiers only, no serde/wire surface); two match-ergonomics patterns take the compiler's suggested reference form. env mutation: every `set_var`/`remove_var` site (20 files) now sits in an `unsafe` block whose SAFETY comment states the real serialization argument (pf-vdisplay's ENV_LOCK, CONFIG_DIR_TEST_LOCK, ART_ROOTS_LOCK, vkdecode's gpu_lock, the `--test-threads=1` contracts of the hardware spikes, or single-threaded startup). Two genuine hazards surfaced en route — exactly the WP3b-class finds this migration exists to make visible — and are fixed here: - windows/service.rs spawned the network-profile warner thread BEFORE `load_host_env()`, so a child-spawning thread (child spawn snapshots the env block) was live while `set_var` ran in a loop; the load now precedes the spawn. - pf-console-ui's `fake_home()` re-set HOME outside its OnceLock on EVERY call, so two parallel tests could race the write; the set now happens exactly once inside `get_or_init`. cbindgen (Trap 2): 0.29.4 parses `#[unsafe(no_mangle)]` — verified empirically; the header regenerates byte-identical. The ci.yml drift check could never catch "failed to regenerate" (build.rs demotes a cbindgen failure to a warning and writes nothing, leaving the checked-in header untouched and the diff clean), so the step now first asserts the "punktfunk-core: wrote" line and the absence of "cbindgen failed" (sh -e safe: no `!` pipeline, no tee-masked exit). rustfmt: style_edition pinned to 2021 at the root — edition 2024 would otherwise flip the style edition and reformat ~370 untouched files inside this same commit, burying the migration diff. The drivers workspace pins its already-current 2024 style. Adopting the 2024 style tree-wide is its own future one-line-plus-reformat commit. Census: the primary metric moves UP BY DESIGN — 2435 → 2453 operations, unsafe blocks 1534 → 1577, and env_set_var is now a counted category (45 ops). The newly counted env sites are a truer number, not a regression; baseline snapshot saved as punktfunk-planning design/rust-safety-census-baseline-2026-08-12-edition-2024.txt. Gate C's env ratchet is now compiler-enforced (the hygiene-script header says so); the two shrunk file counts (nvenc_cuda 49→2 via the test helpers, shell/tests 2→1) are lowered in the same commit per the gate's own rule. Drop order (the semantic change most likely to bite this codebase): the migration lint `-W tail-expr-drop-order` reports zero findings on the macOS-visible halves of pf-encode / pf-zerocopy / pf-capture / pf-frame; the Linux and Windows halves run the same lint on the gate boxes. The four #[ignore]d alloc/drop-cycle tests on the hardware boxes remain owed, as before this change.	2026-08-12 16:12:35 +02:00
enricobuehler	28b6633058	Merge pull request 'feat(display): edid_lock policy axis — pin AMD connector EDID emulation while streaming' (#176) from worktree-edid-lock-toggle into main	2026-08-12 13:12:11 +00:00
enricobuehler	c58217e403	Merge pull request 'fix(client): stop the double-arm race re-freezing RFI-healed streams' (#174) from worktree-gate-double-arm-fix into main	2026-08-12 13:11:51 +00:00
enricobuehler	23f9b1130e	Merge pull request 'Black-stream fixes: CCD restore snapshot pruning, iOS silent-black recovery, devnode journal retention' (#175) from worktree-black-stream-fixes into main	2026-08-12 13:11:29 +00:00
enricobuehler	c2c71f0ac5	Merge pull request 'fix(vdisplay/driver,pf-frame): no punktfunk process holds REALTIME GPU priority by default' (#173) from worktree-rt-gpu-priority-defaults into main	2026-08-12 13:11:02 +00:00
enricobuehler	6a506a8fa9	fix(vdisplay/driver,pf-frame): no punktfunk process holds REALTIME GPU priority by default ... The RX 9070 XT field A/B (2026-08-11/12 logs) convicted BOTH of our REALTIME GPU-scheduling levers of generating the metronomic capture-stall class the stall program has chased for weeks — compose-silence holes of 150-800 ms in which ETW shows NO process presenting while the GPU stays responsive: - the vdisplay driver's IddCxSetRealtimeGPUPriority raise beat at ~1.75-1.78 s (PFVD_NO_RT_GPU=1 alone removed that metronome: ~0.35 stalls/s metronomic -> 10 sparse aperiodic over 3.9 min); - the host auto-gate's HIGH->REALTIME upgrade (pf-frame dxgi.rs, T2.3) beat at ~3.58 s in the AV1 sessions where it promoted (vram_pct=1, 12:59:26); pinning PUNKTFUNK_GPU_PRIORITY_CLASS=high removed that residual too (13:45 session: zero metronomic, stall rate at the clean-run baseline). Neither period matches any punktfunk clock: the full periodic-actor census (driver: event-paced drain + 16 ms E_PENDING wait, 33 ms cursor poll, 3 s watchdog reap; host: 250 ms descriptor poll, 5/50/100 ms probes + ~2 s scanline retarget, 2 s VRAM gate, 2 s exclusive re-assert, 3.33 s pinger, 1 s stats, ~1 Hz phase-lock, fps/2 LTR marks) has nothing in the 1.69-2.29 s band, and every host-side actor ran unchanged in the A/B that killed the fast metronome. The periodicity is emergent from holding an unreachable-priority queue against the WDDM scheduler on this AMD family (the period even differs by which of our processes holds REALTIME); it is not a punktfunk cadence being amplified, so there is nothing punktfunk-periodic to fix - the fix is to stop holding REALTIME by default, which is also canonical parity (no shipping IDD raises it, and HIGH was the class that delivered the original Sunshine-parity encode win). - Driver: PFVD_NO_RT_GPU (default-ON, opt-OUT) becomes the PFVD_RT_GPU ladder, default OFF on every vendor: unset = no raise (canonical IDD behavior); =thread = SetGPUThreadPriority(+7), a graduated in-band middle rung for field A/B (not default: unmeasured here, and the host measured the same call as "no help" for its own starvation case); anything else = the old REALTIME DDI. PFVD_NO_RT_GPU stays recognized and WINS over the opt-in, so the field boxes that carry it through the default-ON era keep meaning OFF. Both directions remain A/B-able without a rebuild (machine env + device restart). The CPU half of the original branch-2 hardening (MMCSS / TIME_CRITICAL) is untouched - it addressed the delivery holes that were actually observed. - Host: PUNKTFUNK_GPU_PRIORITY_CLASS default auto -> high. `auto` (the gated REALTIME upgrade) stays available as an explicit opt-in, `realtime` still pins; unrecognized values now land on the HIGH default instead of silently opting into the gate - a typo must not buy the hazard. The VRAM/HAGS gate machinery is unchanged for `auto`; it guards the NVENC-hang hazard but cannot see this one. - stall.rs: the no-OS-event METRONOMIC warning now carries rt_gpu_driver / rt_gpu_host fields (the machine-env state of both levers) and names clearing them as the FIRST cure, ahead of the display-hardware suspects - a field log self-answers the triage question this program just spent a week on. No console policy axis for the driver knob: the lever is default-safe now, the driver reads config at WUDFHost scope where machine env already matches the device-restart lifecycle, and a policy axis would need pf-driver-proto churn (or a device-key registry write) for an experimental lever that only exists to be A/B-ed. If the `thread` rung ever proves out as a default-worthy raise, that is the moment to revisit.	2026-08-12 13:57:20 +02:00
enricobuehler	712ee935d6	fix(win-display): a failed devnode re-enable must keep its crash-journal entry ... enable_instances cleared every requested id from the pnp-disabled-monitors journal unconditionally — a mid-life re-enable failure erased its own crash-recovery entry, so neither the running host nor the next start would ever retry, leaving the operator's monitor disabled (invisible to Windows and every display listing) until a manual Device Manager fix. Field 2026-08-12 (Android-client host running the pnp_disable_monitors axis): displays gone from the client after 2-3 sessions, only a full host restart bringing them back — the restart path only works while the journal still has the entry. Only successfully re-enabled ids clear now; failures stay journaled (and are logged with the consequence) so startup_recover retries them.	2026-08-12 13:30:04 +02:00
enricobuehler	a2aa0a5f97	fix(apple): never sit black AND silent while the video format is unseeded ... Both pumps (Stage2Pipeline + the stage-1 StreamPump) dropped every AU in a silent guard while 'format' was nil — the opening IDR's parameter sets never arrived or never parsed, and under the host's infinite GOP nothing re-delivers them unless the client asks. Field 2026-08-12 (iOS, H265): sessions decoding nothing, requesting nothing, host streaming perfectly — a black stream with zero recovery requests, randomly self-healing only when some later event produced a fresh IDR. While format is nil after the first received AU, the pumps now set awaitingIDR (routing through the existing 100 ms-throttled recovery.request()) and log the state once, so a lost/unparsed opening IDR converts to a normal recovery round-trip instead of a permanent silent black.	2026-08-12 13:16:58 +02:00
enricobuehler	d6b9862f1e	fix(win-display): prune unplugged targets from the CCD restore snapshot ... A monitor unplugged mid-session left the teardown replaying a snapshot whose paths reference an absent target — SetDisplayConfig rejects the WHOLE array with 0x57 ERROR_INVALID_PARAMETER, nothing restores, the desk stays dark, and the next session snapshots the wreckage (the poisoned-snapshot chain; field 2026-08-12: rc=0x57 across a mid-session unplug, then sessions flipping between black and working at random, incl. one that genuinely encoded black). The restore now prunes the snapshot against a live QDC_ALL_PATHS availability sweep before replaying: stale paths drop, the mode table is rebuilt with only the entries the survivors reference (an orphaned mode entry is itself an 0x57), and an empty survivor set skips the apply so the dark-desk backstop decides. Verbatim behavior is unchanged when everything is still attached or when the availability query itself fails.	2026-08-12 13:15:02 +02:00
enricobuehler	f4e39a442b	feat(display): edid_lock policy axis — pin AMD connector EDID emulation while streaming ... Productizes the adl-emul probe (the prior commit) as the display-policy axis its PR promised: the ADL FFI moves to pf_win_display::adl_emul (one surface shared by the probe tool and the host, so a reporter's probe and the console's toggle exercise byte-identical driver calls), and an EXPERIMENTAL edid_lock axis joins ddc_power_off/pnp_disable_monitors — orthogonal to presets, off by default. At the first Exclusive isolate the host pins each occupied AMD connector's live EDID + ADL_EMUL_MODE_ALWAYS (the software HPD dummy) BEFORE the physicals deactivate; last-member teardown unlocks. Pinned emulation outlives the process, so a crash journal (edid-lock-active.json) unlocks on the next host start, mirroring the pnp_disable_monitors recovery. Inert without an AMD driver. The console shows the toggle ONLY when the GPU inventory lists an AMD adapter — the lever exists nowhere else, and a toggle that can never act is the 'saved and then did nothing' trap the enforced-axes list exists to prevent.	2026-08-12 08:47:42 +02:00
enricobuehler	a0577cb86e	feat(tools/display-disturb): adl-emul — AMD connector-emulation probe (software HPD dummy) ... The standby-sink stall program's §3 dead-end list marked ADL EmulationMode 'likely Pro-gated' on field hearsay, with 'probe once, log rc' as the owed falsification — never run. Three RX 9070 XT field cases later (ASUS VG32VQ1B/DP, Odyssey G60SD/DP, LG UltraGear 32GS95UE/HDMI), this is that probe, shippable to reporters: read-only caps/board-layout/connection-state walk by default, --lock pins the live EDID + ADL_EMUL_MODE_ALWAYS on occupied connectors (the software HPD-holding dummy), --unlock restores. Every call prints the bench's epoch_ms correlation line with the decoded ADL rc — ADL_ERR_NOT_SUPPORTED(-8) vs ADL_OK on consumer Adrenalin is the Pro-gating answer, and a --lock run during a stream with the sink asleep is the direct A/B for the metronomic stall class. atiadlxx.dll is bound dynamically (absent = clean exit 2), structs mirror adl_structures.h verbatim, and the probe touches only connectors the board-layout walk enumerated. Gates: check/clippy -D warnings (msvc cross-target) + fmt clean; native stub unaffected.	2026-08-12 08:16:33 +02:00
enricobuehler	2a62fe7857	fix(client): stop the double-arm race re-freezing RFI-healed streams ... Every unrecoverable loss armed the client's freeze gate twice: instantly at frame-index-gap detection (which fires the RFI), and ~120 ms later when the reassembler ages the lost frame into frames_dropped and poll() re-armed unconditionally. An LTR-RFI recovery anchor lands in ~60 ms — between the two signals — so the stale climb re-froze a bit-exact-healed stream, the host swallowed the re-ask as an RFI echo, and the picture stayed frozen until the overdue backstop extracted a full IDR: the field 'H265 freezes on every loss, AV1 fine' signature on AMD hosts (AMF is the only LTR-RFI backend; the slower IDR path usually lands after the climb and dodged the race). The gap-arm now pre-credits the expected climb (ReanchorGate::arm_expecting_drops; credit expires after DROP_CREDIT_WINDOW so a straggler-filled gap can't mask a later real loss), and poll() consumes credited climbs instead of re-arming. Plumbed through every embedder: pf-client-core's session pump, Android's sync/async loops (note_frame_index now returns the gap width), and the Swift client via new ABI exports punktfunk_connection_note_frame_index_ex + punktfunk_reanchor_gate_arm_expecting_drops (additive; the bool ABI stays).	2026-08-12 08:11:35 +02:00
enricobuehler	66ba61b12c	Merge pull request 'Safety round 2: ASAN+LSAN over the C ABI boundary, two soundness fixes, and WP4's AvFrame RAII' (#172) from worktree-safety-round-2 into main ... Reviewed-on: #172	2026-08-12 05:57:16 +00:00
enricobuehler	5002849737	feat(pf-encode): WP4 — AvFrame/AvSwsContext RAII across all three libav backends ... Two newtypes beside AvBuffer/AvFilterGraph (same house shape: alloc/from_raw rejects the allocator's null once, as_ptr lends, Drop frees, no Clone; NonNull inside so the Options get a niche). 8 av_frame_alloc + 3 sws_getContext sites converted; all 22 hand-placed av_frame_free and 5 sws_freeContext calls are gone, and the three hand-written Drop impls (CpuInner, SystemInner, NvencEncoder) with them. The live defect this closes: ZeroCopyInner::submit (ffmpeg_win) leaked the frame AND one pooled hwframe surface on each of three ? exits between the pool pull and the send — under a SAFETY comment asserting no leak — and with POOL=8, eight such failures starved the pool and wedged the encoder with no error naming the cause. Every exit now returns the surface. Drop-order care (the hidden cost the survey flagged): NvencEncoder's sws_csc moved to field #1 (its hand-Drop freed it before all fields; this path runs on every stall-watchdog recovery via *self = fresh); CpuInner's nv12/sws declaration order flipped to match its hand-Drop; SystemInner's already agreed. Pinned by FIELD ORDER comments, not offset_of asserts — the survey's assert suggestion is the wrong tool: offset_of measures repr(Rust) memory layout, which the compiler may reorder independently of the declaration order that drop order actually follows. The dmabuf path keeps its early descriptor release via an explicit drop() at the exact point the hand-written free sat. Gates: .25 clippy -D warnings + tests green (nvenc,vulkan-encode,pyrowave); .133 check --all-targets + clippy --release -D warnings + 80 tests green (nvenc,amf-qsv,qsv; test step needs ffmpeg\bin on Path — 0xC0000135 otherwise). Owed on hardware: the #[ignore]d alloc/drop cycles on .136/.116/.173/.47 and the pool-exhaustion assertion (9th submit succeeds after 8 forced failures).	2026-08-12 00:31:14 +02:00
enricobuehler	9a59504ba4	fix(punktfunk-core): validate InputKind before forming &InputEvent in the C ABI ... abi.rs's two send-input entry points built &InputEvent straight out of caller memory with ev.as_ref(); InputKind is repr(u8) with 16 valid discriminants, so a C embedder writing ev->kind = 42 was immediate UB the moment the reference formed — in a file whose stated principle is that failures become status codes. New read_input_event() checks null, reads the tag as a raw byte, validates through the same InputKind::from_u8 the wire path uses, and only then forms the reference; bad tags return InvalidArg. Every other field is a plain integer, valid for any pattern. Test stages the event in MaybeUninit storage so the test itself never holds a reference to the invalid value. 380 lib tests + the C harness round-trip + clippy -D warnings green on .25; header regenerated.	2026-08-12 00:12:01 +02:00
enricobuehler	e8c306b9c0	fix(punktfunk-host): WP3c/3d — align the TOKEN_USER buffer, make EqualSid fail closed ... 3c: forming &TOKEN_USER (align 8) out of a bare [u8; 256] (align 1) was UB by the validity rule whenever the stack slot landed misaligned — shipped codegen happened to 8-align it, which is luck, not a contract. Fixed with a repr(align(8)) wrapper that keeps the buffer at 256 BYTES; the comment records why [u64; 32] is the wrong shape (len() would silently become 32 and misclassify every hand-run host as SYSTEM via ERROR_INSUFFICIENT_BUFFER, invisibly to a SYSTEM-side test). Length arg now size_of_val. 3d: EqualSid().is_ok() read BOTH 'SIDs differ' and 'EqualSid failed' as Err, so a genuine failure yielded 'not SYSTEM' — the fail-OPEN direction, contradicting the documented fail-closed contract. Now split three ways on the last-error code, with SetLastError(0) cleared first so a stale value cannot misclassify. Gate: cargo check -p punktfunk-host + cargo clippy --release -D warnings both green on .133 (real MSVC, fresh extraction, sentinel-verified).	2026-08-12 00:12:00 +02:00
enricobuehler	c3b57438e1	chore(ci): c-abi-asan job in audit.yml — the harness under ASAN+LSAN, weekly + on demand ... Same shape as the miri job (dated nightly, own san- cache prefixes, non-blocking day one via a step-level ::warning::, a proved-it-ran grep). run.sh gains PF_SAN_TOOLCHAIN so CI can pin its dated nightly — bare +nightly would ask for the rolling channel the job never installs. Both the pinned and vanilla paths re-verified green on .25.	2026-08-12 00:02:26 +02:00
enricobuehler	e20b614059	chore(safety): PF_SAN sanitizer gate for the C ABI harness ... PF_SAN=address builds the punktfunk-core staticlib on nightly with -Zsanitizer/-Zbuild-std and the C harness with clang -fsanitize, so ASAN instruments both sides of the boundary at once and LSAN (detect_leaks=1) becomes the first automated check on abi.rs's Box::into_raw/from_raw leak contract. Verified on the .25 box: green run passes byte-exact; deleting one punktfunk_session_free() in the harness makes LSAN report the 308 Rust-side allocations behind the handle and the script exit 1. The harness binary moves from mktemp to target/ — a debug+ASAN static binary can exceed a tmpfs /tmp (it did, on .25's 3.6G tmpfs).	2026-08-11 23:58:06 +02:00
enricobuehler	6eb89b3f34	Merge pull request 'The lint ratchets (WP2b + WP2c): crate-level gaps closed, the three-workspace hoist, three blocking grep gates' (#171) from worktree-lint-ratchets into main	2026-08-11 21:57:26 +00:00
enricobuehler	bbd26ea82c	Merge pull request 'Miri interprets the FFI-free leaf crates, one of them at MSVC layout' (#169) from worktree-miri-ci into main	2026-08-11 21:57:24 +00:00
enricobuehler	549fdf238b	Merge branch 'main' into worktree-lint-ratchets	2026-08-11 21:57:17 +00:00
enricobuehler	3ea411fa39	Merge branch 'main' into worktree-miri-ci	2026-08-11 21:57:15 +00:00
enricobuehler	3b2fcd076d	Merge pull request 'chore(api): regenerate openapi.json — #164's unpair change rewrote the unpairClient description without regenerating' (#170) from worktree-openapi-regen into main	2026-08-11 21:57:07 +00:00
enricobuehler	d67ab9ede4	chore(safety): two .133 gate findings — cfg the abi lock helper, re-anchor a layer proof ... The tray leg builds punktfunk-core with default-features off, where lock_recover's only callers (the quic-gated punktfunk_connection_* entry points) do not exist — dead code under -D warnings. The helper takes the same feature gate. In pf-vkhdr-layer, rustfmt had reflowed destroy_surface's lookup into a multiline closure, leaving the SAFETY comment outside the closure that contains its unsafe block — the box's clippy rightly stopped accepting the adjacency. The comment moves inside, directly above the block.	2026-08-11 23:51:01 +02:00
enricobuehler	abec2a1457	chore(safety): nvenc_core — plain union-arm writes are safe by language rule ... The .25 gate corrected the carve-out: rustc flags `unsafe { u.arm.field = x }` as unused_unsafe — plain assignment through a union projection is safe (writing an arm cannot itself be UB; the hazard is the mismatched READ). The 11 plain writes go back to bare statements under their codec matches. What stays in per-op unsafe blocks with arm-guard proofs is the real unsafe surface: union reads, borrows, and the bindgen bitfield-setter calls — which is exactly the surface the shipped 4:4:4 bug lived on (set_chromaFormatIDC stamped under a wrong codec).	2026-08-11 23:45:36 +02:00
enricobuehler	5f097d530d	chore(safety): exempt the two bindings-only sys crates from the hoisted deny ... Linux fallout from the hoist the mac could not see: bindgen emits unsafe blocks (layout tests/accessors) into OUT_DIR, where nobody hand-writes SAFETY proofs — pyrowave-sys failed clippy on .25 with 17 of them, and libvpl-sys would do the same on the Windows leg. Both crates are bindings-only by charter (the safe wrapper lives with the consumer), so the allow is crate-wide with the rationale at the crate root; the hand-written link-sanity tests keep their proofs by convention.	2026-08-11 23:41:39 +02:00
enricobuehler	2bfd1cd2d5	chore(safety): three unsafe-hygiene grep gates, blocking in ci.yml (WP2c gates) ... scripts/ci/check-unsafe-hygiene.sh — textual gates for three classes no lint covers: A. unsafe fn markers carrying no contract. unsafe_op_in_unsafe_fn forces real ops into blocks, so an unsafe fn with no `unsafe` in its body is a marker with no contract (db659809 found two by hand). Contract-deferring fns (Vec::set_len shape) waive with `// unsafe-fn-no-op-ok: <reason>`; fenced files and `unsafe extern "ABI" fn` (signature-mandated markers) are skipped structurally. B. unwrap/expect/panic! inside extern "C"/"system" bodies — an abort since Rust 1.81, not linted, not fuzzable (8b98d0b3). catch_unwind bodies are exempt; `// panic-in-extern-ok: <reason>` waives a deliberate abort. C. Safe-but-process-global APIs (env::set_var/remove_var, sigaction, setlocale, set_current_dir) — the 972af299 environ race lived in a file with zero occurrences of the word `unsafe`. Per-file count ratchet with the baseline in the script; any increase or new file fails. Making gate B clean on main surfaced 14 real instances of exactly its class — `.lock().unwrap()` in unguarded extern fns, where a poisoned mutex aborts the embedding process: six punktfunk-core abi.rs entry points (poll_frame, next_au, next_audio, next_audio_pcm, next_cursor_shape, next_clipboard), seven Android JNI entry points, and the Windows client's deeplink wnd_proc. All fixed with poison-recovering locks (the slots are last-value caches, valid whatever a poisoned writer left) and Option::insert for the set-then-unwrap shape; punktfunk-core's 203 lib tests pass. Gate A's findings were six genuine contract-deferring fns — waived with reasons, not fixed, because the markers are correct. Gate-of-the-gate: all three shown to FAIL on deliberately planted instances (marker fn, panicking extern callback, env::set_var in an unlisted file) and to run clean on the tree, before the ci.yml step made them blocking.	2026-08-11 23:36:17 +02:00
enricobuehler	dfebb9dfbb	chore(safety): hoist the unsafe lints into the workspace tables (WP2c hoist) ... undocumented_unsafe_blocks joins unsafe_op_in_unsafe_fn in [workspace.lints], and the ~100 scattered per-file #![deny(...)] attributes (85 files) are deleted — a new crate, or a new module in an old one, is now covered on creation rather than on remembering. The per-file form is how pf-vkhdr-layer, wdk-probe and half of pf-clipboard stayed uncovered. There are THREE workspaces, so the claim is made three times: the main Cargo.toml, packaging/windows/drivers (workspace table + [lints] workspace = true in all seven members), and packaging/windows/pf-vkhdr-layer (its [lints] table, previous commit). pf-update now opts into workspace lints; the two vendored member snapshots (cros-codecs, usbip-sim) stay out deliberately and now both say so. Newly-covered fallout was two link-sanity tests (pyrowave-sys, libvpl-sys) — proofs written. Stale prose that claimed the workspace held unsafe_op_in_unsafe_fn at "warn" (it has been deny) or pointed at the deleted attributes is corrected. nvenc_core.rs is carved OUT of the unsafe_op_in_unsafe_fn fence: its exemption rationale ("raw entry-table calls almost line for line") was false — the file makes zero FFI calls. Its unsafe surface is C-union writes whose soundness hangs on which codec arm is active, and its own 4:4:4 note records the shipped bug (hevcConfig bytes stamped onto an AV1 config) that per-operation blocks make visible. It now runs the strictest discipline in the crate: clippy::multiple_unsafe_ops_per_block at deny, one union access per block, each naming its codec guard. Verified here: cargo fmt clean in all three workspaces; native clippy -D warnings clean for everything that compiles on macOS (the three pre-existing mac-native failures — pf-client-core wol.rs, pf-encode dead-code/closure-call, probe mic_burst — reproduce on the clean tree). Linux/Windows legs ride the .25/.133 gate.	2026-08-11 23:26:28 +02:00
enricobuehler	f675b3710e	chore(api): regenerate openapi.json — fcf4c9fd rewrote the unpairClient description without regenerating	2026-08-11 23:23:08 +02:00
enricobuehler	23fa03b051	chore(safety): close the three crate-level lint gaps (WP2b) ... pf-vkhdr-layer — the sharpest gap: an implicit layer injected into every Vulkan game process, 32 unsafe usages, zero SAFETY comments, own workspace so no lint table reached it, and an explicit missing_safety_doc allow. Now: a [lints] table (unsafe_op_in_unsafe_fn + clippy::undocumented_unsafe_blocks, both deny), the allow removed, every unsafe operation in an explicit block with a real proof (loader layer protocol / Vulkan valid-usage), # Safety docs on the contract-carrying fns, const layout asserts for the SurfaceFormat2Raw mirror, the five helpers with no caller-facing contract demoted to safe fns, and the two redundant `unsafe impl Send` deleted (fn pointers and vk handles are Send intrinsically — the type-check proves it). wdk-probe — 21 unsafe blocks, 12 proofs: the 9 missing SAFETY comments are written (the iddcx_rt.rs DDI slot-dispatch ones are about table population and PFN/index pairing, not pattern fill), the sibling denies added at the crate root, missing_safety_doc allow dropped, # Safety on DriverEntry, and the crate joins windows-drivers.yml's clippy list — it was the only driver crate not in it. pf-clipboard — the undocumented_unsafe_blocks deny moves from host/windows.rs to the crate root so host/wayland.rs (4 blocks), host/mutter.rs (2) and any future backend under host/ are covered on creation. All existing blocks already carry proofs; free today, structural tomorrow. Verified here: pf-vkhdr-layer cargo fmt --check + clippy --release -D warnings at x86_64-pc-windows-msvc. wdk-probe and pf-clipboard compile checks need the WDK/Linux boxes and ride the .133/.25 gate.	2026-08-11 23:10:00 +02:00
enricobuehler	6e4638dab5	ci(audit): interpret the FFI-free leaf crates under Miri, one at MSVC layout ... Adds a non-blocking `miri` job to audit.yml, per rust-safety-programme.md §7. What it buys is one narrow, real thing: pf-driver-proto interpreted CROSS-COMPILED to x86_64-pc-windows-msvc, on a Linux runner, with no Windows box in the loop. That crate is `#![forbid(unsafe_code)]` and path-dep'd by BOTH the main workspace and the driver workspace, so it is the layout oracle for every frame and IOCTL crossing that boundary, and nothing else in CI checks it at MSVC layout. It is NOT unsafe coverage — Miri can execute on the order of 2% of the host's unsafe and cannot run ash, windows-rs, ffmpeg, CUDA or the WDK — so no "Miri coverage" number is reported anywhere. Three steps, every one of them measured on 192.168.1.25 with a cold target dir and cold sysroot cache, on the dated toolchain the job installs, BEFORE being committed: step A pf-driver-proto + pf-host-config + pf-gpu 21 + 12 + 4 pass 43 s step B pf-driver-proto @ x86_64-pc-windows-msvc 21 pass 26 s step C punktfunk-core fec::gf8 with +avx2,+ssse3 2 pass 63 s Four corrections to the §7.3 job spec, found while doing this and folded into comments: * `-p punktfunk-core fec packet crypto` does not parse — cargo rejects the extra positionals. Corrected (filters after `--`) it selects 63 tests and was killed at a 25-minute cap with not one test complete, so the bulk step is dropped entirely and only the narrow `fec::gf8` selection is kept, timed at 63 s. * `nightly-2026-08-10` resolves to rustc 1.99.0-nightly (969b803cb 2026-08-09), NOT the 12c36e253 2026-08-10 the doc cites: `nightly-<date>` names the day rustup PUBLISHED the build, which is compiled from the previous day's commit. The doc's hash came from the ROLLING `nightly` channel and was mislabelled. All three steps were re-run and are green on the dated pin actually installed here. * fec-rs dispatches its GF(2^8) multiply through RUNTIME `is_x86_feature_detected!`, so step C's RUSTFLAGS are load-bearing in both directions. Verified by probe: bare, avx2=false and the step would silently interpret the scalar fallback; with the flags, avx2=true and `_mm256_shuffle_epi8` genuinely executes under the interpreter. GFNI stays false either way, so that branch is simply not covered. * `RUSTC_WRAPPER: ""` is a guard, not a fix, and the comment says so — audit.yml sets no sccache today, and cargo-miri warns "Ignoring `RUSTC_WRAPPER`, Miri does not support wrapping" and carries on regardless. Non-blocking via a step-level `||`, not job-level continue-on-error, following the precedent audit.yml already documents for docs-site-audit. Each step additionally asserts a non-zero pass count, so a crate rename or a filter that stops matching surfaces as a warning rather than as a green zero-test run. Both paths were exercised directly: a failing run emits the annotation and still exits 0, and a zero-selection run trips the guard, while a green run with empty bin/doctest targets does not false-positive. Leak checking stays ON (no -Zmiri-ignore-leaks); the two deliberate leaks in the tree are named in a comment so whoever expands coverage annotates those sites instead of blanket- disabling the check. pf-bitstream and the FFI crates are excluded with the reasons inline so they are not helpfully re-added. `paths:` is deliberately not widened to crates/pf-driver-proto/** — that filter is workflow-level and would fire all six audit jobs on every driver-proto edit.	2026-08-11 22:52:28 +02:00