3003 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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	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
enricobuehler	0c2ac333ae	Merge pull request 'Chore/rust safety programme' (#164) from chore/rust-safety-programme into main	2026-08-11 20:47:15 +00:00
enricobuehler	bc70a58fb1	Merge main into chore/rust-safety-programme ... Two conflicts: the test-module import list in gamescope.rs (union — the branch's takeover-state tests and main's WSI opt-out tests both stay), and next_frame_timed_out in pf-capture, where the branch still carried the pre-#168 else-if chain — resolved to main's match-based refactor, which already embeds the same arm semantics plus the provisional-budget latch gate.	2026-08-11 22:34:38 +02:00
enricobuehler	ce25aca7bd	Merge pull request 'Two black screens from the .41 field session — a NO_FOCUS window stole the composite, and one truncated timeout downgraded the host forever' (#168) from worktree-blackscreen-fixes into main	2026-08-11 20:32:16 +00:00
enricobuehler	5587699a85	Merge pull request 'Every pinned card gets a library, and it launches with that card's profile' (#167) from worktree-console-pinned-profile-library into main	2026-08-11 20:30:03 +00:00
enricobuehler	c946fcdcb5	Merge pull request 'build(web): silence rollup's "use client" directive warnings in the nitro pass' (#166) from build/web-silence-rollup-directive-warnings into main	2026-08-11 20:29:36 +00:00
enricobuehler	fcf4c9fd63	fix(mgmt): unpair now revokes a LIVE session on both planes ... An unpair removed the certificate but left the revoked client's running session streaming until the client chose to leave. Now it is a complete revocation: - GameStream: when the removed certificate owns the active launch, the session is quit_session'd — the ENet control thread's ended-session arm gives the client the standard TERMINATION+disconnect. (An owner-less launch cannot be attributed and is left to the WP0 port teardown when the last pairing goes.) The endpoint docstring's long-standing caveat ('removes the client from the listing without severing its ability to reconnect') is retired: TLS handshakes complete by design, authorization is per-request, and a live session no longer survives its own revocation. - Native: session_status::stop_by_fingerprint signals the unpaired client's live session(s) to tear down deliberately (quit+stop), matched by the registry's client label — the fingerprint's 12-hex-char prefix for every pairable client; anonymous/TOFU sessions carry IP labels and are never touched (they have no pairing to revoke). (The unpair-didn't-PERSIST half of 'unpairing was broken' was already fixed in 13d57210 — save_paired was never called; this closes the other half.) Gates: Linux amd64 both flavors clippy --all-targets -D warnings clean; session_status 2/2 (new revocation test), the extended paired-clients test green in both flavors, native_pairing test green.	2026-08-11 22:17:41 +02:00
enricobuehler	cc8eb7df08	feat(clients): every pinned card gets a library, and it launches with that card's profile ... The console fix before this one closed the leak on one client. The same question has a different wrong answer on each of the others, so this closes it everywhere: a pinned host+profile card can be browsed, and every title launched off a pinned card's shelf streams with that card's profile. Two shapes of bug, one per client: **The library was not offered on a pinned card at all** — Apple (both UIs: `hasLibrary: profile == nil` on the console tile, no menu item on the touch card), Android (`hasLibrary` required `pinnedProfileId == null`, and the console host options gated Library on `pin == null`), GTK (the pinned card's menu had Connect, Copy link, Create shortcut, Unpin — no library) and Windows (pinned tiles had no menu whatsoever). Each was justified in a comment as "a pin is a shortcut, not a second host, so the host-level actions stay on the host's tile" — right about wake, pair, edit and forget, wrong about the library. Browsing is not a property of the machine: it is this card's connect with a title picked first, which is exactly what a shortcut is for. So the library joins Connect on every pinned surface, and the host-level actions stay where they were. **The launch dropped the profile.** GTK already carried it (its library clones the card's whole ConnectRequest) and Windows already carried it (its library page launches through the shared target, which the tile parks). Apple did not: the library was keyed on a bare `StoredHost`, so `launchTitle` connected with `.inherit` and the host's binding won even from a pinned card. Android was worse still, and not only for pins — `LibraryScreen` dialled `connectToHost` with the RAW settings, so a library launch applied NO profile at all, not even the host's binding, on every host. Its host list resolves `settings.effectiveFor(profileStore.resolveFor(kh, oneOff))`; its library resolved nothing. So the shelf, not the host, is now the unit both clients navigate by. Apple gets a `LibraryTarget` (host + `ProfileSelection`) threaded through `libraryTarget`, the shell's screen enum, both presentations and `SessionModel`; Android passes the pinned id into `LibraryScreen` and resolves it there through the same `ProfileStore.resolveFor` rule the connect path uses. Falling out of that: * a game that exits returns to the shelf it was launched from, pin and all, rather than to the host's default one — `SessionModel.launchedShelf` on Apple, `ActiveSession.libraryProfileId` → `LibraryReturn` on Android. Android also drops a pin that was unpinned while the game ran, rather than reopening a card that no longer exists. * Android's stats overlay finally names the profile a library launch used (`profileName` was never set on that path). * Apple's `punktfunk://browse/<host>` honours `profile=`, which it parsed and ignored — and refuses an unknown or ambiguous reference exactly as the connect route does (§10.6) rather than degrading to the binding. * every shelf says which one it is, in the card's own `host · profile` shape: the console's title, GTK's page title, Android's ConsoleHeader, Apple's navigation title and its console heading. Verified per platform, none of it on trust: * console + GTK: fmt, build, clippy `-D warnings` and 85 tests green in the pf-lxcheck2 container (a Mac `cargo test -p pf-console-ui` compiles nothing). * Apple: `swift build` green for macOS, iOS and tvOS. Worth all three — the tvOS pass alone caught `navigationDestination(item:)` needing Hashable, and an iOS-only screen was confirmed genuinely compiled by planting a type error. * Android: `compileDebugKotlin` + unit tests, with HomeTilesTest's pin expectation flipped to match. * Windows: `cargo check --all-targets` + clippy `-D warnings` on the CI runner, cold (3m10s) — that client cannot compile on a Mac.	2026-08-11 22:13:54 +02:00
enricobuehler	6ca192b9ab	fix(packaging/gamescope): +pfhdr6 — a GAMESCOPE_NO_FOCUS window can no longer steal the composite ... Patch 0008: honor GAMESCOPE_NO_FOCUS in steamcompmgr's focus selection. hhd (Handheld Daemon) sets the atom once at init on its hhd-ui overlay window and never clears it; MangoHud sets it too; show/hide for these clients runs over the STEAM_OVERLAY protocol. NOTHING consumed the atom — not upstream gamescope, not Bazzite's fork (checked ba148 by strings) — so a mapped-but-unpainted hhd-ui window (it crash-loops under a headless punktfunk takeover and remaps on every respawn, stamping Steam's appid 769) was an ordinary focus candidate, and steamcompmgr picked it over Big Picture. The composite, and the stream fed from it, went black while every health signal stayed green: on .41 the client sat decoding 60 fps at 0.1 Mb/s of black, GAMESCOPE_FOCUSED_WINDOW named the hhd-ui window with GAMESCOPE_NO_FOCUS(CARDINAL)=1 on it, and killing hhd-ui brought the picture back the same second. The patch wires the atom exactly like GAMESCOPE_EXTERNAL_OVERLAY — read at map, PropertyNotify-tracked with MakeFocusDirty, skipped by both focus-candidate collectors (X11 and XDG) — and touches neither compositing nor appID, so a NO_FOCUS window still paints if the baselayer protocol brings it into view; it is only barred from being CHOSEN. Applies cleanly on the full 0001..0008 series from the bare 5fb8dce4 pin (verified with git am). Banner +pfhdr5 → +pfhdr6, PKGBUILD 3.16.25.pfhdr6-1; README gains the 0008 row, the missing +pfhdr5 ledger row, and the reconciled bump rule (a bugfix bumps the level only when field triage must read the difference off a box's banner — 0007's crash-loop, 0008's lost composite).	2026-08-11 22:07:24 +02:00
enricobuehler	022ede651f	fix(pf-capture): the truncated first attempt no longer latches the sticky downgrades ... The pipeline retry loop deliberately shortens its first attempt's first-frame wait to 2.5s so a stream bound during a gamescope re-init fails over quickly. But the portal capturer's timeout diagnosis treated EVERY expiry as a verdict: it latched whichever offer it implicated — HDR capture off for the source, the raw-dmabuf offer off, the EGL→CUDA offer off — process-wide and permanently, when the attempt was truncated by design and a gamescope cold start routinely delivers nothing inside that window while accepting every offer a few seconds later (observed on .41: pid 1962 hit the expiry at connect and every later session in that process ran silently degraded). This is bug #6 from the pf-capture sweep, verified then and unfixed until now. The truncated attempt is now declared PROVISIONAL end to end: a new `Capturer::next_frame_within_provisional` (default: delegates) lets the retry loop say "this budget is the schedule, not a verdict", and the portal capturer's timeout classification — split out as the pure `classify_first_frame_timeout` + `timeout_convicts`, with tests — names the same suspect in the error text but latches nothing unless the expired budget was full-length.	2026-08-11 22:06:31 +02:00
enricobuehler	9c6e06d3b9	feat(host): GameStream is now a cargo feature — WP19, compile-time isolation ... A new 'gamestream' feature (default ON — every stock package is behaviorally identical, and GameStream stays runtime-opt-in via --gamestream / PUNKTFUNK_GAMESTREAM) gates the whole Moonlight-protocol surface: control (the ENet plane), rtsp, nvhttp, pairing, serverinfo, the _nvstream mDNS advert, the compat media path (stream/video/audio), pen/gamepad/input decode, apps, crypto, cert (the RSA identity), and tls's Moonlight-client-cert leniency. AppState keeps the shared vocabulary unconditional and cfg-gates the Moonlight-only fields; the mgmt API's PIN endpoints (routes, handlers, OpenAPI entries, lane classifications, tests) exist only under the feature. Building --no-default-features --features pyrowave yields the hardened NATIVE-ONLY host: no rusty_enet (the c2rust-transpiled C ENet stack, 158 unsafe sites) and no rsa (the identity split's legacy fallback became a pem-only read — rustls/ring serves an existing RSA cert without the crate — so the accepted Marvin advisory no longer applies to native-only builds). Both claims are ASSERTED, not assumed: a new CI leg keeps the native-only flavor clippy-clean and fails if cargo tree finds either crate in its graph. serve --gamestream (or the env knob) against such a binary refuses to start with a clear error rather than serving less than the operator configured. En route: the logs-paging test assumed a quiet process-global log ring between its cursors and raced other tests' legitimate log lines (the identity tests added new emitters) — it now asserts on its own markers within the page. Gates: Linux amd64 — BOTH flavors clippy --all-targets -D warnings clean; default tests identity 3/3, mgmt 37/37, gamestream 59/59; native-only tests identity 3/3, mgmt 35/35, residue 4/4; rusty_enet+rsa absent native-only, present default. .133 Windows — both flavors clippy clean (clean-first, sentinel-checked), tree claims hold, and the WP0 port-lifecycle functional gate PASSES on the default build.	2026-08-11 22:05:30 +02:00
enricobuehler	f5fa9649b7	fix(console): a pinned card's library launches with that card's profile ... Pinning a profile onto a host gives it its own card on the console home, and pressing A on that card has always connected with the pinned profile as the one-off the resolver prefers over the host's binding. Y on the same card opens a library — it is paired and saved, which is the only thing the hint bar asks — and every title launched off that shelf went out with no profile at all, so the host's default binding won. Connecting straight from the card honoured the profile; going through its library did not, which is the shape a user reads as "the pin works until I pick a game". The screen was the leak: LibraryScreen copied the row's address, port, fingerprint and mgmt port, and dropped `pin` — so its launch had nothing to send and hardcoded `profile: None`, under a comment asserting that game launches follow the binding. They should follow the card: a launch off a pinned card's shelf is that card's connect with a title attached. The screen now carries the row's pin and sends its id as the one-off. It also says so, in the card's own `host · profile` shape: the shelf's title names the profile, and so does the connecting card, so which of a host's cards you came in on is legible from the screen rather than inferred from the tile you pressed two screens ago. Off the host's primary tile there is no pin and nothing changes — `None`, and the binding decides. Console-only. The Apple and Android consoles keep Y off pinned cards outright (`hasLibrary: profile == nil`), the GTK client clones the card's whole ConnectRequest — profile included — into its library, and the Windows client offers "Browse library" from the primary tile only. The console's own copy-link and wake-then-connect paths already carried the pin. Both directions are tested, and the pinned one was checked against a reverted fix: it fails with exactly the reported symptom (left: None, right: "hdr").	2026-08-11 21:42:14 +02:00
enricobuehler	1009e14a44	build(web): silence rollup's "use client" directive warnings in the nitro pass ... The nitro server build re-bundles the whole dep tree (`noExternals: true`), so every React package shipping a `"use client"` banner earns a MODULE_LEVEL_DIRECTIVE warning — ~150 locally, ~800 in CI — which buries the warnings worth reading. Ignoring the banner is correct rather than papered over: this bundle is the Bun/Nitro server, not an RSC module graph, and TanStack Start splits client from server with its own transform, so nothing downstream consults it. Supplying `onwarn` replaces nitro's own handler, so its three filters (CIRCULAR_DEPENDENCY, EVAL, "Unsupported source map comment") are restated. Verified: `bun run build` drops from 148 such lines to 0 with no other log delta; `tsc --noEmit` and `biome check` clean.	2026-08-11 21:00:19 +02:00
enricobuehler	e658ad726b	feat(host): the identity split — the native planes get their own P-256 identity ... One RSA-2048 identity served every plane, because Moonlight mandates RSA and the planes grew out of the GameStream host. The native punktfunk/1 QUIC plane and the management API now share a separate ECDSA P-256 identity (native-cert.pem/native-key.pem, src/identity.rs): ring-generated via rcgen (no rsa crate on the native path — the accepted Marvin advisory stops applying once WP19 gates the compat planes), real SANs (localhost, loopback, machine hostname — the legacy cert had none), and browser-compatible on purpose: Ed25519 was rejected because no mainstream browser accepts an Ed25519 server cert and /api/docs is opened in one. GameStream keeps the RSA identity untouched (Moonlight pins it; its pairing hashes bind its X.509 signature bytes). Migration is pin-preserving by construction. Clients TOFU-pin ONE leaf-DER SHA-256 for both QUIC and the mgmt/library API, so the identity is resolved ONCE in serve (the planes cannot race the first-run mint) under the rule: identity files exist → use them; else the native trust store is EMPTY → mint P-256 (fresh installs); else keep presenting the legacy RSA cert the paired clients pinned, and log the migration path (unpair all, restart, re-pair). Fingerprint pinning is algorithm-agnostic — existing shipped clients pair against P-256 hosts unchanged. Followers updated: the tray's loopback pin and the plugin SDK's mgmt CA prefer native-cert.pem → cert.pem; the Windows runner ACL grant lists both (the grant loop tolerates absent files). The in-process native tests now run on an EPHEMERAL identity — they previously read, and would newly have MINTED, identity files in the real config dir, which on a dev box that is also a live host would have switched its identity and stranded every pinned client. Gates: Linux amd64 clippy --all-targets -D warnings clean (host+tray); identity 2/2, mgmt 37/37, control 6/6, native 68/68 (C-ABI roundtrips over the ephemeral identity). .133 Windows clippy clean; the port-lifecycle gate re-run PASSES with the split live — the fresh host minted P-256 and served mgmt over it (curl 200/204), ports tracked the paired list as before.	2026-08-11 20:52:01 +02:00
enricobuehler	21f43d7f48	Merge pull request 'Games ran black in Nobara's Game Mode — the session script re-exports the WSI variable #144 cleared' (#165) from worktree-nobara-wsi-layer-clobber into main ... Reviewed-on: #165	2026-08-11 18:33:05 +00:00
enricobuehler	8d1e5ab5dd	Merge pull request 'The Android console grows up — the desktop's real backdrop, Apple's drum, and the cross-client tables stop drifting in silence' (#163) from worktree-android-console-visual-refresh into main ... Reviewed-on: #163	2026-08-11 18:32:00 +00:00
enricobuehler	23d0452157	feat(host): GameStream opt-in on every route; the native plane is deny(unsafe_code)-enforced ... The user direction after WP0: ENet exists only for Moonlight, so the native plane must be provably safe and the compat planes a deliberate choice. Opt-in, everywhere. Windows already was (unchecked installer task). The three opt-out surfaces are flipped: the shipped systemd user unit (deb/RPM/Arch/ sysext) no longer bakes --gamestream into ExecStart — a new PUNKTFUNK_GAMESTREAM=1 host.env knob (pf-host-config, OR-ed with the CLI flag) is the packaged opt-in; the NixOS module default goes true→false, with a module-check assertion that unset = native-only; the Deck installer takes --gamestream to opt in (--no-gamestream kept as explicit-off). Docs (quickstart, running-as-a-service, moonlight, ubuntu/fedora/arch firewall sections, gnome/sway, how-it-works) rewritten to the opt-in shape; the CHANGELOG carries the upgrade note. Enforced-safe. punktfunk-core is #![deny(unsafe_code)] crate-wide — every module that parses network bytes is safe Rust as a compile error, not a census result. Carve-outs are exactly two documented classes, neither of which interprets attacker bytes: the client surface (abi, client) and the transport syscall-batching shims (udp/{apple,linux,windows}, qos_windows). In punktfunk-host, the modules a secure-default host exposes — native (cfg-not-test: its tests exercise the client C ABI on purpose), native_pairing, mgmt, mgmt_token, discovery, wol — are #[forbid(unsafe_code)]. Gates: Linux amd64 container clippy --all-targets -D warnings clean over core+host-config+host; core 204 tests green under the deny; mgmt 46/46, control 6/6. .133 Windows clippy (shipped features, clean-first, sentinel-checked) clean — covers the qos_windows/udp-windows carve-outs. macOS + iOS cargo check green (the apple.rs carve-out compiles for real).	2026-08-11 20:21:16 +02:00
enricobuehler	9e28cd101c	fix(pf-vdisplay): the WSI opt-out never reached the games — the session script re-exports it ... A Nobara 44 field box on 0.27.0 got a working Game Mode takeover — right mode, right refresh, perf overlay in the stream — and then every game it launched played sound and took input over a BLACK PICTURE, with no error anywhere. #144 disabled the distro's `VkLayer_FROG_gamescope_wsi` with `--setenv=ENABLE_GAMESCOPE_WSI=0` on the transient unit, because that layer speaks the distro gamescope's `gamescope_swapchain` protocol and ours rejects its `swapchain_feedback`, killing the client. `gamescope-session-plus` then runs an unconditional `export ENABLE_GAMESCOPE_WSI=1` near the top of the script, before it launches anything — so the opt-out lived exactly as long as it took the script to start, and gamescope, Steam and every game got the layer back. The host logged that it had disabled it, which is what made this cost a field round-trip: the claim was true of the unit and false of everything in it. Nothing else looked wrong because the casualty is Vulkan clients specifically. Steam's Big Picture UI is not one, so the session came up looking perfectly healthy right up until a game started. Send `DISABLE_GAMESCOPE_WSI=1` as well. The Vulkan loader resolves an implicit layer's two manifest knobs in a fixed order (`loader_implicit_layer_is_enabled`): `enable_environment` must equal `"1"` to switch the layer on, and `disable_environment` is consulted last — "has priority over everything else" — where the mere PRESENCE of the variable, at any value, forces it off. The session script never mentions that one, so it is the only one that survives it. Both spellings now go out through one place, so the transient unit (`launch_session`) and the box's own session drop-in (`write_session_plus_dropin`) cannot drift apart — the same shape `SessionBind` already uses for the bind. `ENABLE_GAMESCOPE_WSI=0` stays alongside for a layer built without a `disable_environment`, and because it is what an operator reads the unit for.	2026-08-11 20:14:19 +02:00
enricobuehler	13d5721049	feat(gamestream): the ENet control port exists only while a pairing does (WP0) ... rusty_enet — a c2rust-style transpile of C ENet, 158 unsafe sites — parsed unauthenticated UDP on 47999 from GameStream startup, before any client had ever paired: the host's entire pre-auth-reachable unsafe surface. Pairing itself is HTTPS on nvhttp and never touches the port, so it now binds only while the paired-client list is non-empty: a Gate in control.rs reconciles the port to the list (armed only under --gamestream), pairing phase 4 brings it up before the new client can /launch, and removing the last pairing tears it down — a live client gets the same termination+disconnect farewell as a host-side session end. A never-paired host on a hostile LAN exposes no ENet. En route: the management API's unpair never called save_paired, so a restart resurrected the client — and would now have silently re-opened the port; it persists (the test now runs against a throwaway PUNKTFUNK_CONFIG_DIR so it can't clobber a real paired.json). rusty_enet is pinned =0.4.0 per the WP, left to the cargo-audit job to flag advisories against it. Gate (amd64 container): clippy --all-targets -D warnings clean; gamestream::control 6/6; mgmt::tests 37/37 incl. the regenerated api/openapi.json. On-box .133 verification (ports/pair/stream) still owed.	2026-08-11 19:29:50 +02:00
enricobuehler	d4366e7464	fix(pf-encode): the Vulkan extension probe walked a driver-filled array with no bound ... `ext_advertised` did `CStr::from_ptr(e.extension_name.as_ptr())` over a driver-filled `[c_char; VK_MAX_EXTENSION_NAME_SIZE]`, and `vk_build.rs` open-coded the identical call a second time. Neither had an in-Rust bound: a driver that fills all 256 bytes without a NUL runs the walk into the NEXT `ExtensionProperties`, and on the LAST element past the allocation. The SAFETY comment asserted the spec guarantee ("a spec-guaranteed NUL-terminated byte array") instead of enforcing it. That is the defect class this programme keeps finding: a proof that restates what the other side promised rather than checking it. Vulkan drivers are exactly the other side. The bounded answer already shipped in the same crate — `pyrowave.rs:210` uses ash's `extension_name_as_c_str()` for the identical job. It stops at VK_MAX_EXTENSION_NAME_SIZE and returns Err when there is no terminator, so a malformed entry is a non-match instead of an overrun. Both sites now route through the one helper, which is no longer unsafe at all. Deletes 2 unsafe operations and one duplicated walk. ⚠ The pre-existing test could not have caught this: it only ever built well-formed, NUL-terminated entries. Added a case whose LAST element is 256 non-NUL bytes — the exact shape that used to leave the array — and a prefix-match case, so the bound is now asserted rather than assumed. Verified on 192.168.1.25 (Ubuntu, cargo 1.96.0 — the pinned toolchain): cargo check -p pf-encode --features vulkan-encode,pyrowave --locked ok cargo test -p pf-encode --features vulkan-encode,pyrowave ext_advertised 2 passed / 0 failed cargo clippy -p pf-encode --all-targets --locked --features vulkan-encode,pyrowave -- -D warnings clean Linux-only code (`enc/linux/`), so the Windows leg is unaffected.	2026-08-11 16:34:34 +02:00
enricobuehler	cd72f77a3c	fix(pf-encode): the AMF layout guards broke Windows clippy — 0*SLOT and 1*SLOT ... `27f08340` wrote every vtable offset assertion as `offset_of!(T, f) == N * SLOT` so the slot INDEX stays visible in the assertion. For N=0 and N=1 that is `0 * SLOT` and `1 * SLOT`, which clippy rejects as `erasing_op` and `identity_op` — six errors, and windows-host.yml runs clippy with `-D warnings`, so the branch as pushed would have turned the Windows leg red. This is the blind spot the programme document names in §1.5, demonstrated on the programme's own first code commit: 44% of the host's unsafe is `#[cfg(windows)]`, no Linux or macOS check compiles it, and `cargo fmt`/`cargo check` on a Mac are all clean. Only the .133 gate sees it. Fixed with a `const fn slot(i: usize) -> usize` rather than by writing the two offending cases as bare `0` and `SLOT`: that would have made those two the only assertions where the slot index is invisible, and the index is the entire point. Also records the cheap local gate that would have caught this without a Windows round-trip: `amf_sys.rs` depends on nothing but `c_void`, so copying it into a throwaway one-file crate and running `cargo clippy -- -D warnings` reproduces the exact error on any host. Verified by reintroducing `0 * SLOT` and watching the harness fail with the same message the runner gave. Verified on 192.168.1.133 (Windows CI runner, the box with the WDK), after a `cargo clean -p pf-encode` that reported `Removed 47 files, 135.5MiB` so the recompile is real and not a cached green: cargo check -p pf-encode ok cargo check -p pf-encode --all-targets --features nvenc,amf-qsv,qsv ok cargo clippy -p pf-encode --all-targets --features nvenc,amf-qsv,qsv -- -D warnings exit 0 (was 101) cargo clippy -p punktfunk-host --features nvenc,amf-qsv,qsv -- -D warnings exit 0 (was 101) The gate also greps the extracted tree for the assertions before building, so a stale upload cannot produce a passing run.	2026-08-11 16:28:59 +02:00
enricobuehler	cd3f5474bf	fix(pf-driver-proto): a layout test read an align-8 struct out of an align-1 buffer ... `control_structs_roundtrip_through_bytes` built the legacy-size wire form in a stack `let mut legacy = [0u8; 40]` (align 1) and then called `bytemuck::from_bytes::<control::AddRequest>`. `AddRequest` opens with `session_id: u64`, so it is align 8, and `from_bytes` hands back a REFERENCE into the buffer — it panics unless the buffer happens to be 8-aligned. A stack `[u8; 40]` usually is, which is why this passed on every machine and every CI leg since it was written. Under Miri it fails outright: Miri does not let an accidentally-favourable stack slot stand in for a guarantee. Switched to `pod_read_unaligned`, which reads by value and has no alignment precondition. That is not a new idea here — `ChannelProof::parse` at lib.rs:1013 already carries a comment saying "`pod_read_unaligned`, NOT `from_bytes`" for exactly this reason. This site is the only other one in the crate that reads a POD out of a stack byte array; every other `from_bytes` call in the tests reads from `bytes_of(&x)`, which is aligned by construction. Test-only, so no shipped defect — but the crate is `#![forbid(unsafe_code)]` and is path-dep'd by BOTH the main workspace and the driver workspace, so it is the layout oracle for every frame and IOCTL that crosses that boundary. A test that cannot be trusted to fail is worth fixing there more than anywhere else. Found by the first Miri run ever performed against this repo. Verified on 192.168.1.25 (Ubuntu, cargo 1.96.0): cargo +nightly miri test -p pf-driver-proto 21/21 cargo +nightly miri test -p pf-driver-proto --target x86_64-pc-windows-msvc 21/21 cargo test -p pf-driver-proto --locked ok cargo clippy -p pf-driver-proto --all-targets --locked -- -D warnings clean The cross-target run is the interesting one: it interprets the crate at MSVC layout on a Linux box with no Windows anywhere. Nothing else in CI does that.	2026-08-11 13:57:34 +02:00
enricobuehler	972af2992f	fix(pf-capture): the gamescope cursor fallback rewrote environ under a live multithreaded host ... `connect_via_env_swap` did set_var("XAUTHORITY", …) / connect / restore, guarded by a mutex that serialised this source against itself and against nothing else. `getenv` takes no lock. setenv/unsetenv rewrite the process-global `environ`, and glibc REALLOCATES that array when a variable is added — while, at that exact moment, the PipeWire thread is inside pw_init()'s dlopen making bare getenv() calls and EGL/CUDA init is running alongside. The file's own doc already called the pattern "unsound from a live multithreaded host"; it stayed as a fallback. Three things made it worse than the comment suggested: - The damaging branch is the one where XAUTHORITY is ABSENT and therefore gets ADDED (the realloc case). scripts/punktfunk-host.service deliberately does not import the login shell's environment, so absent is the DOCUMENTED NORMAL configuration for the shipped unit, not an edge case. - `rediscover` re-runs this every 2 s for the whole session. A display whose connect fails is never pushed into `displays`, so the dead-display skip never covers it — the race is not once at startup, it repeats forever. - It is unfixable in place. Sharing pf_vdisplay's ENV_LOCK is the wrong layer: it cannot make C `getenv` take a lock. The fix is to stop writing `environ` at all. Connecting with an explicitly empty auth token is what the swap actually achieved: we only reach the fallback when our own lookup found no usable MIT-MAGIC-COOKIE-1 entry, and x11rb's internal lookup reads the same file with a STRICTER matcher (it matches family/address too, which we deliberately do not), so where we find nothing it finds nothing either and connects unauthenticated. That is exactly why the swap "worked" against a nested Xwayland started without -auth. Gives up one case: an .Xauthority using an auth family we decline to guess at but x11rb would have handled. A gamescope Xwayland writes a single-entry MIT-MAGIC-COOKIE-1 file, so it is not reachable here, and declining to attach a cursor overlay beats tearing `environ` out from under a live session. Also removes XAUTH_LOCK, whose only user this was. Verified on 192.168.1.25 (Ubuntu, cargo 1.96.0 — the pinned toolchain, pipewire dev headers present): `cargo check -p pf-capture --locked` and `cargo clippy -p pf-capture --all-targets --locked -- -D warnings` both clean. Not verified on glass: the fallback is only reached when the cookie parse fails, so a normal gamescope session does not enter it. Forcing it needs a nested Xwayland started without -auth, or a mangled cookie file, on .181/.136.	2026-08-11 13:54:56 +02:00
enricobuehler	df6f270e7b	chore(safety): forbid unsafe on the crates that are already at zero ... Five permanent ratchets, all free today — the point is that they cannot regress tomorrow. Each crate was re-measured at the commit, not taken from a survey. `forbid(unsafe_code)`: punktfunk-encode-worker the binary that carries cap_sys_nice. Its header claims "no Wayland, no D-Bus, no network, no plugins"; this makes the memory-safety half of that claim mechanical. `forbid`, not `deny`, so it cannot be re-opened by an #[allow] further down. pf-update-check parses a signed, network-fetched manifest and its own header says it "owns the part where being wrong is a security bug". Signature checking is worthless if the parser around it can be walked out of bounds. pf-vaadec its header states the design constraint outright — it links no libva and compiles on macOS, "which is the point". The crate is full of hand-declared libva repr(C) mirrors; one raw deref and it stops being the CPU-testable half. tools/cursor-probe free, and a probe is where "just deref it to see" is most tempting. `deny(unsafe_code)` + one localized allow: pf-update root runs this. Its single unsafe operation, a bare geteuid, moves into a named `effective_uid()` helper carrying the crate's one #[allow(unsafe_code)]. Deliberately NOT rewritten to rustix, contrary to the programme document's first draft: pf-update's Cargo.toml states that its zero-dependency posture IS a security invariant of a root helper ("no HTTP client, no TLS, no argument parsing"), and the extern block says the same. Pulling a general-purpose syscall crate into a root helper to delete one `unsafe` would trade a real property for a cosmetic one. The localized allow keeps the ratchet: any NEW unsafe anywhere in the crate is a build error. Verified: `cargo check -p pf-vaadec -p pf-update-check` and `cargo check -p pf-update -p cursor-probe` clean on macOS, plus `cargo check -p pf-update --target x86_64-unknown-linux-gnu` — pf-update's whole body is behind `cfg(target_os = "linux")`, so the macOS check does not reach the line that changed. punktfunk-encode-worker is not built here (pf-encode's C dependencies do not cross-compile from macOS) and needs the Linux CI leg.	2026-08-11 13:49:41 +02:00
enricobuehler	27f0834025	fix(pf-encode): const-assert the AMF vtable and POD layouts ... amf_sys.rs mirrors five AMF COM vtables by hand and amf.rs dispatches through them BY SLOT POSITION — 18 distinct slots across the five tables. The mirrors carried 118 `Slot` placeholders whose only job is to hold the following slots at their C offsets, and not one layout assertion of any kind. A slot inserted, removed or reordered in an AMF header bump calls an arbitrary function pointer through a mismatched signature: no compile error, no runtime signal. `AMF_MIN_VERSION` does not defend against this. It checks a version NUMBER, not a layout, and it is a floor with no ceiling. The three POD checks that did exist (`AmfVariant`, `AmfGuid`, `AmfHdrMetadata`) lived in amf.rs's `#[cfg(test)]` module, so they were verified only when someone ran pf-encode's tests, on Windows, with AMF enabled — and NEVER in a release build, which is exactly where a mis-mirrored `AMFVariantStruct` does its damage: it crosses the FFI BY VALUE on every SetProperty. This is the same hole `a8dd348b` closed for the cuda.h mirrors and missed here. Adds ~40 `const _: () = assert!(...)` guards next to the mirrors: size of each of the five vtables, the byte offset of every slot amf.rs actually calls, the three POD layouts promoted out of the test module, and the AMFData/AMFBuffer shared-prefix agreement that `create_surface_from_dx11_native`'s AMFSurface-through-AMFData reinterpretation silently depends on. Verified by compiling amf_sys.rs standalone (it needs only `c_void`, and a repr(C) struct of code pointers has the same layout on any 64-bit target, so a macOS const-eval proves the Windows arithmetic), and by deliberately breaking one offset to confirm the guard actually fires rather than silently passing. That check earned its keep immediately: `alloc_buffer` sits at slot 43, not 42. Counting AMFInterface(3) + AMFPropertyStorage(10) + the AMFContext block by hand is exactly the error these assertions exist to catch. Zero runtime behaviour change. The `AMF_MIN_VERSION` ceiling is deliberately NOT part of this commit: a ceiling would make the next AMF driver release refuse encode on every AMD box, so it needs a warn-and-continue policy plus an env override and a real AMF session to gate it.	2026-08-11 13:49:25 +02:00
enricobuehler	db6683a585	chore(safety): commit the unsafe census, fix its two bugs, record the baseline ... Founding commit for a host-focused Rust safety programme. Adds the census tool that measures the programme, the 2026-08-11 baseline it produces, and the programme document itself. The metric is SHIPPED NON-FFI UNSAFE OPERATIONS: 713. Raw `unsafe {}` block count is the wrong target and the workspace manifest already says why — 63.3% of unsafe operations in host scope (1542 of 2435) are a single third-party FFI call that ash/windows-rs/ffmpeg mark unsafe on our behalf. A block count also rewards merging blocks, ignores SAFETY comments, and IMPROVES when code moves from Linux to Windows, because no local check can see the Windows half. The tool shipped here had two defects, both fixed: - `in_test_mod` cached parsed `#[cfg(test)]` spans in a dict keyed on `id(src)`, the memory ADDRESS of the source string. CPython recycles addresses, so once one file's source was collected the next file's string could be allocated at the same address and silently inherit the previous file's test spans. Ten consecutive runs over an unchanged tree produced 694, 695, 696, 701, 703, 709, 710, 713, 714 and 721. Fixed by holding a strong reference to the string beside its spans, which makes the address un-recyclable while the entry is live. Five consecutive runs now agree exactly. - The layout-assertion regex matched `const _: () = assert!(...)` but not the `const _: () = { ... };` block form, which 18 files use — including abi.rs, pf-inject/linux/gamepad.rs and pf-capture/.../idd_push/probes.rs. It reported 102 unguarded repr(C) declarations across 25 files where the true figure is 60 across 22, defaming three well-guarded files. A metric that is not reproducible is not a ratchet. The acceptance gate for this commit is therefore five consecutive identical runs, not one. Baseline: 713 shipped non-FFI unsafe operations; 60 unguarded repr(C) declarations across 22 files; unsafe reachable pre-authentication by an unpaired peer = 0 first-party.	2026-08-11 13:42:05 +02:00
enricobuehler	7ffafb5ef3	chore(api): regenerate openapi.json after merging main ... `main` gained the launcher brand tokens (`f62a48d4`) while this branch was open, and both sides touch the generated document — so it was regenerated from the MERGED source rather than text-merged. Verified to carry both: the 18 launcher-token entries from main, and this branch's corrected schema descriptions. No `required` array changed, so no client regeneration is needed.	2026-08-11 11:03:42 +02:00
enricobuehler	4b686f026a	Merge branch 'main' into worktree-vd-sweep-2 ... # Conflicts: # api/openapi.json	2026-08-11 10:57:35 +02:00
enricobuehler	d6132f7523	chore(api): regenerate openapi.json for the pf-vdisplay policy doc corrections ... The sweep rewrote doc comments on `ToSchema` types (`KeepAlive`, `Topology`, `ModeConflict`, `Identity`, `LayoutMode`, `Layout`, `DisplayPolicy`, `EffectivePolicy`), and utoipa emits those verbatim as schema descriptions — so the checked-in snapshot went stale and `mgmt::tests::openapi_document_is_complete_and_checked_in` would have failed. Several of the corrected descriptions were shipping outright falsehoods to API consumers. The worst: `KeepAlive::Forever` documented itself as "**Not honored until the display-lifecycle stage**" while the mgmt handler honors it end-to-end and the `gaming-rig` preset selects it (sweep item 11.7). Diff is descriptions only — the `required` arrays are unchanged, so no SDK or client regeneration is needed. Generated with `cargo run -p punktfunk-host -- openapi` in `ci/rust-ci.Dockerfile` under `--platform linux/amd64`, and confirmed by running the host's own drift test there (37 mgmt tests). `docs-site/public/openapi.json` is deliberately untouched: it is already ~34 KB behind `api/` from earlier work, and refreshing it here would sweep in unrelated changes.	2026-08-11 10:55:27 +02:00
enricobuehler	dc4d8d6832	fix(pf-vdisplay): correct the regressions this sweep introduced ... An adversarial review of the sweep's own diff raised 39 claims; 23 survived independent verification. This commit fixes them. Several are cases where the sweep traded one bug for another. **The display budget was enforced in the wrong place.** The new Linux `max_displays` ceiling sat in `registry::acquire` — which runs again on every mid-stream rebuild. All three create-before-drop paths hold the old lease while acquiring the new display, and only the mode-switch path passes `supersedes`, so a session at the ceiling counted itself against the budget and could never recover from capture loss or a Game↔Desktop switch. At `max_displays = 1` that is a single streaming client. Moved to `admission::admit`, which is where Windows has always applied it and which is reached once per connect — so a rebuild cannot hit it. **"Cannot tell" was collapsed into "wrong mode".** `unanimous_output_size` returning `None` for two disagreeing gamescopes was compared with `== Some(target)`, so ambiguity took the destructive branch: a nested per-title gamescope — the normal Game Mode shape — made every connect restart the box's session and kill the running game. Now a three-state `BoxOutputSize`, where `Ambiguous` mirrors the live node instead of re-moding, and the post-restart wait asks "did what we asked for come up" rather than demanding unanimity. **Decide-then-act lost its mutual exclusion.** Re-scoping the `MANAGED_SESSION` guard fixed the shutdown restore but let two concurrent creates at the same mode both relaunch, the second stopping the unit the first was polling. A separate `MANAGED_LAUNCH` mutex restores the exclusion without putting launch progress back into the lock the restore samples. **Per-axis policy salvage was applied to a selector.** `preset` chooses the other axes, so salvaging it to the default silently re-pointed the whole document; it now refuses the document instead. A file whose every axis is unreadable also reported `configured() == Some(default)` — flipping Linux identity from Shared to PerClient — and now correctly reports unconfigured. **The six `#[serde(default)]` on `EffectivePolicy` are reverted**: they loosened `POST/PUT /display/presets` (an omitted axis defaulted where it used to 400), which nobody asked for. The catalog salvage they were added for now lives in a private Deserialize-only mirror type, so the read path stays lenient and the wire contract stays strict. Also: the Windows create path stored the OS-committed refresh in the field `acquire` uses as its resize discriminator, so a same-mode re-acquire looked like a hotplug — the requested and committed modes are now separate fields; `output_within`'s timeout arm detached both reader threads (now bounded by a drain grace, capped at 16 MiB, and logged honestly — a `systemd-run --pipe` unit escapes the process group and cannot be reached); `reenable_outputs_kscreen` abandoned the mode restore whenever kscreen-doctor hit its budget even though the enable may have landed (now tri-state); `write_atomic` replaced a symlinked portal config with a regular file, severing dotfiles management; several new budgets were too short for the helper they bound (`steam -shutdown` was being killed before it could deliver the request; `linger_enabled` read a 300 ms timeout as "not lingering" and hard-failed a correctly configured box); and a restore logged an operator-facing error for a `systemctl` call that had merely outlived its budget while systemd still owned the queued job. Verified: 107 tests on macOS, 202 on Linux (executed in a container, not merely type-checked), Linux and Windows clippy clean at `-D warnings`, fmt clean.	2026-08-11 10:06:16 +02:00
enricobuehler	8b98d0b3ec	fix(pf-capture): a sweep found nine real defects behind comments that asserted the opposite ... Reviewed the whole crate (15.6 kloc) for bugs, safety, structure and comment truth. Both compile gates are green: `scripts/xcheck.sh windows clippy` and `cargo clippy -p pf-capture --all-targets --locked -- -D warnings` in the amd64 CI image (the Linux half needs libpipewire, so it cannot ride xcheck). Code defects, each one contradicted by a comment sitting next to it: * `pipeline_depth` clamped to `OUT_RING` (3) while both `repeat_last` and `OUT_RING` state the safe maximum is 2. `d` frames in flight need `d + 1` textures, so `PUNKTFUNK_IDD_DEPTH=3` rotated onto the slot NVENC was still reading and the convert overwrote it in place — torn frames, silently. Now `OUT_RING - 1`. * The GDI cursor poller published `visible: true` for a NULL `hCursor` carrying `CURSOR_SHOWING` — how an app hides the pointer for its own window. The last rasterised arrow was then blended into a game that had hidden its cursor. Every rasterise gate already tested `handle != 0`; the published verdict now agrees. * The ETW event callback did `RING.lock().unwrap()`. That is an `extern "system"` fn, so a poisoned lock panicked across an FFI boundary and ABORTED the host — a diagnostic taking down capture. Poison-tolerant now, which also makes the poison unreachable. * `ChannelBroker::send` bounded the ring with `debug_assert`, so a release build instead panicked mid-`duplicate_and_deliver`, unwinding past the reap and leaking every handle already planted in the driver's WUDFHost. Refuses before the first duplication. * `set_active(false)` did not clear `stall_since`, so a pooled capturer carried a stale stall clock into its next stream and reported capture loss microseconds in. * `attach_gamescope_cursor` evaluated `spawn` before dropping the old source: two readers published into one slot, and a failed spawn destroyed a working reader. Idempotent now. * `PUNKTFUNK_FORCE_SHM` used a bare `== "1"` compare, silently ignoring `=true`/`=on`. * `spa_meta_bitmap.offset == 0` is SPA's "no image data" signal, distinct from the `bitmap_offset == 0` position-only case. Unhandled, it decoded the header's own words as cursor pixels and cached them. * A `VideoInfoRaw::parse` failure was swallowed, so a malformed Format pod surfaced as the generic "no acceptable format" timeout. It is logged, and parsed once, not twice. Comment corrections, all verified against the code they describe: four claims that a failed open falls back to DDA (removed — the caller drops the keepalive under "no fallback"); three comparisons to the removed WGC path; "we do NOT gate HDR on the client's VIDEO_CAP_10BIT" (it does, in three places); the P010 sampler's "4 explicit taps / 2x2 box" (two taps, left-cosited — the box was the bug it replaced); the cursor meta cap quoted as 256x256 (1024, and 256 is the value that cost the whole Linux cursor channel on-glass); the poller's "~60 Hz" (4 ms, ~250 Hz); "several minutes of coverage" (~26 s); "8 frames in 400 ms >= 20 fps" (7 intervals, so 17.5); three "process-wide" HDR latch claims (per-source, which is why HdrSource exists); a SAFETY proof claiming a view is "unmapped never" (Drop unmaps it); the Linux module header describing a bounded channel and BGRx-only frames (one-deep overwriting slot, several formats); and a doc line stranded on `DisplayDescriptor` by an earlier split, restored to `IddPushCapturer`, which had none.	2026-08-11 10:04:58 +02:00