1983 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
enricobuehler	8e7ba00d2d	refactor(encode/linux): third fence off — vaapi.rs, and VaapiHw::new needed no marker at all ... Same criterion as the last two: `vaapi.rs`'s sites are pointer dereferences and libav ctx calls, not ash, so a proof here carries an argument. Three regions, three arguments. `VaapiHw::new` also loses its `unsafe fn` outright, and the contrast with its CUDA twin is the whole point: `CudaHw::new` keeps the marker because it is HANDED a `CUcontext` the caller must vouch for, while this one takes four scalars and opens the VAAPI device itself. Two functions of near-identical shape, opposite answers, decided by whether a caller can supply something broken. The other two regions keep their markers (`open_vaapi_encoder`/`_mode` are handed raw `*mut AVBufferRef`s) and gain the proofs they lacked. The encoder-config block now records the fact that makes it sound rather than obvious: `av_buffer_ref` returns a NEW reference the codec context adopts, so the callee shares the caller's device/frames buffers instead of consuming them — which is also why the low-power entrypoint ladder can retry with the same two pointers after a failed attempt. The frames-pool block reuses the `CudaHw::new` argument: alloc returns null-or-initialized and `AvBuffer::from_raw` rejects null, so the `?` leaves before any field store can run. One call site dropped its `unsafe {}` and its comment with it — the comment argued that libav was initialized, which is a real precondition of the call but not one a caller can violate, so it is now a note rather than a contract. 14 fenced files -> 11. Verified on .21 (fmt + both CI clippy steps rc=0) and, because this is the live VAAPI construct path rather than dead code, ON THE AMD 780M (.116, pf-build distrobox): `vaapi_cpu_encode_smoke`, `dmabuf_inner_alloc_drop_cycles` and `vaapi_probe_smoke` all pass — 3 passed / 0 failed, H265 + AV1 probes still true in both 8- and 10-bit.	2026-07-29 00:20:35 +02:00
enricobuehler	ee29b3c3a9	refactor(client-core): three decoder lift methods that took nothing to get wrong ... `D3d11Decoder::lift`, `VaapiDecoder::map_dmabuf` and `VulkanDecoder::extract` each take `&mut self` and NOTHING else. They dereference `self.frame`, the `*mut AVFrame` the decoder allocates in its own constructor and owns until `Drop` — a pointer no caller supplies, can replace, or can invalidate. None carried a `# Safety` section, and each body was already one `unsafe {}` with its proof, so the marker was pure ceremony and its removal moves nothing. All three live in files the workspace `deny` already covers (`video_vulkan.rs` since the fence came off it), so they stay fully enforced. Worth recording why this is where the marker sweep STOPS for these two crates: every remaining candidate in pf-encode and pf-client-core sits inside a fenced file, and there removing a marker is not free. The fence excuses `unsafe_op_in_unsafe_fn`, which only applies to `unsafe fn` BODIES — a safe fn always needs explicit blocks — so unmarking an ash-dense helper forces exactly the whole-body `unsafe {}` this program rejected when it rejected `cargo fix`. The way to reach those is to reclaim the file first, not to unmark inside it. Verified on .21: fmt + `clippy --workspace --all-targets -- -D warnings` + the feature-gated `-p pf-encode` step, all rc=0.	2026-07-29 00:20:35 +02:00
enricobuehler	d72822ced7	refactor(encode/linux): second fence off — CudaHw::new's pointer walk gets its proof ... `linux/mod.rs`'s fifteen sites are the same kind as `video_vulkan.rs`'s, not the ash kind: nine raw pointer dereferences and six libav calls, all inside `CudaHw::new`, which had no `unsafe` block and therefore no proof of the one thing worth proving here — that the pointer chain it walks is live. The marker STAYS (`cu_ctx: *mut c_void` is a `CUcontext` the caller must supply valid). The body is now two blocks, one per phase, because there are two distinct arguments to make. Both turn on the same non-obvious fact: `av_hwdevice_ctx_alloc`/`av_hwframe_ctx_alloc` return null or a ref whose `data` libav has ALREADY initialized, and `AvBuffer::from_raw` rejects null — so the `?` leaves before any of the field stores below it can run. That is what makes the `(*dev_ctx)`/`(*fc)` writes in-bounds stores on live allocations rather than a hope, and it is exactly the reasoning that was missing. The device block also records the ordering constraint that was implicit: `cuda_ctx` must be stored BEFORE `av_hwdevice_ctx_init`, which reads it. Two files now need no exemption: 14 fenced -> 12. Both were removable for the same reason — their sites are pointer dereferences, where a proof carries an argument, unlike the ash backends where it could only restate the call. That is the criterion for which fence to attack next, not file size. Verified on .21: fmt + `clippy --workspace --all-targets -- -D warnings` + the feature-gated `-p pf-encode --features nvenc,vulkan-encode,pyrowave` step, all rc=0 with no allow in either file.	2026-07-29 00:20:35 +02:00
enricobuehler	ed4bbc6b0b	refactor(client-core): the first fence comes off — video_vulkan.rs is at zero ... `video_vulkan.rs` was fenced with the other thirteen GPU/FFI backends, but it never belonged with them: its four sites are not ash calls, they are RAW POINTER DEREFERENCES inside the two FFmpeg `lock_queue`/`unlock_queue` callback trampolines — exactly the case where the lint pays, and where a proof carries an argument instead of restating a signature. Both bodies had none at all. They keep `unsafe extern "C"`: FFmpeg invokes them with a `*mut AVHWDeviceContext`, which is a real contract, now written down. What was missing is why the dereference chain is sound, and it is worth stating because it is not obvious — the trampoline casts between pf_ffvk's `AVHWDeviceContext` and ffmpeg-sys's (the same C struct declared twice), reads `user_opaque`, and dereferences it as a `QueueLock`. That pointer borrows `VkCtxStorage::_queue_lock`, an `Arc<QueueLock>` whose field doc already says it exists to outlive every call the context can make. The proof now connects those two facts, so a future edit to the storage's lifetime has something to contradict. With that, the file needs no exemption and the workspace `deny` covers it: 14 fenced files -> 13. This is what removing a fence is supposed to look like — the sites that are worth narrowing get narrowed, and the exemption disappears rather than being renewed. Verified on .21: fmt + `clippy --workspace --all-targets -- -D warnings` + the feature-gated `-p pf-encode` step, all rc=0 with no allow in the file.	2026-07-29 00:20:35 +02:00
enricobuehler	5b2be889f9	refactor(capture/windows): two # Safety sections that stated no contract ... The previous commit took the markers with no `# Safety` at all. These two HAVE one, and that is what makes them worth naming: a section can exist and still describe nothing a caller can violate. `resolve_render_adapter` takes **no arguments**. Its section read "calls DXGI factory/adapter enumeration; returns owned COM objects or an error" — a summary of the body. With no parameters and no globals touched, there is no way to call it wrongly. `create_nv12` asked that "`device` must be a live D3D11 device". It takes `&ID3D11Device`, a borrowed reference-counted COM wrapper, so the borrow itself is that guarantee — safe Rust cannot produce a dangling one. The remainder ("the returned texture is owned by the caller") is an ownership note, the same distinction `service::open_log_handle` already draws in its doc. Every other parameter is a plain scalar. Both bodies already had their explicit block, so again nothing moved. `create_nv12`'s proof said "on the live `device` borrow (per the contract above)" and now says the borrow is what keeps it live — a proof that pointed at a contract being deleted had to stop pointing at it. The other four were read and KEPT, and they are the shape of a real one: `channel::send` and `duplicate_and_deliver` take raw `HANDLE`s; `prepare_blend_scratch` requires the caller to hold the slot's keyed mutex before it copies; `pyro_fence_signal` must run on the thread owning the immediate context, which is load-bearing precisely because `IddPushCapturer` is `unsafe impl Send` and so CAN be moved. `verify_is_wudfhost` (raw `HANDLE`, and the driver-channel security check) keeps its marker too. pf-capture: 21 `unsafe fn` -> 8, every survivor carrying an obligation a caller can actually break. Verified on .47: pf-capture clippy `-D warnings` rc=0 + 18 Windows tests pass, host/pf-encode/ pf-vdisplay green; Linux .21 fmt + both CI clippy steps rc=0.	2026-07-29 00:20:35 +02:00
enricobuehler	9e8473b46a	refactor(capture/windows): eleven D3D11 helpers had no caller contract ... The DXGI converters (`HdrP010Converter`, `BgraToYuvPlanes`, `VideoConverter`), the cursor blend pass, and `create_ring_slots` declared their methods `unsafe fn` because their bodies are D3D11 FFI. That is a property of the body, not an obligation on the caller, and their own proofs said so: "`?`-checked D3D11 methods on the live `device` borrow". Every parameter is either a borrowed windows-rs COM wrapper (`&ID3D11Device`, `&ID3D11DeviceContext`, `&ID3D11Texture2D`, the views) or a plain `u32`/`bool`/`DXGI_FORMAT`; each body builds its own descriptors from those and every interface it creates owns its reference. There is nothing a caller can pass that makes them unsound. Not one of the eleven carried a `# Safety` section — the marker had no stated contract to inherit, which is the tell. Each body was already one `unsafe {}` with its proof, so this is purely subtractive: no block moved and no proof was written. The four call sites lost `unsafe {}` wrappers whose own comments gave the game away — "`X::new` is `unsafe` (it compiles D3D11 shaders…)", "`create_ring_slots` is an `unsafe fn` (it makes D3D11/DXGI COM calls)" — comments explaining that the marker described the callee's body rather than anything the caller had to guarantee. `compile_shader` KEEPS its `unsafe fn`: it takes `PCSTR`, a raw pointer the caller must guarantee points at a NUL-terminated literal. That is the line — a contract a caller can actually break. pf-zerocopy was surveyed the same way and deliberately left alone: its CUDA/Vulkan helpers look identical by signature but state real obligations ("the shared context is current", "single-threaded use of handles this bridge owns"), so signature screening finds candidates and only reading decides. pf-capture already denies both `unsafe_op_in_unsafe_fn` and `undocumented_unsafe_blocks`, so the crate stays fully enforced; the reduction is in obligations, not in warnings. It now has exactly one `unsafe fn` left. Verified on the Intel box .47: pf-capture clippy `-D warnings` rc=0 and its 18 Windows tests pass, with host/pf-encode/pf-vdisplay clippy still green; Linux .21 fmt + both CI clippy steps rc=0.	2026-07-29 00:20:35 +02:00
enricobuehler	50531c8e9e	fix(host/display): a screen picker that cannot stream a screen now says so instead of saving ... The Windows console's "Streamed screen" picker SAVED and then did nothing. `capture_monitor` is platform-neutral, so the PUT persisted; every consumer of it is Linux-gated, so a virtual display was still created on connect. The operator got a control that acknowledged the click and changed nothing — the worst of the three possible behaviours. The root cause is not a missing gate, it is a missing BACKEND. Per-monitor capture is Linux/portal only: `vdisplay::open`'s mirror arm is `#[cfg(target_os = "linux")]` because `pf-capture` has no Windows entry point that can capture an arbitrary head. Its sole Windows entry point is `open_idd_push`, a frame channel pushed by our OWN IddCx virtual display; DXGI Desktop Duplication was deliberately REMOVED (`windows/dxgi.rs` keeps the GPU-preference hook only to stop DXGI reparenting the virtual display off the pinned adapter, and says so). So there is nothing for a pin to aim at, and exposing the picker got ahead of that. Decision of record (user, this session): mark it unsupported now rather than build the Windows backend here. A Windows mirror backend is a real feature gap and a project of its own — it needs a duplication capturer plus everything the IDD-push path carries today (cursor sidechannel, 444, 10-bit, PyroWave, HDR) re-plumbed through it — not a follow-on to an enumeration commit. Three places, so the answer is consistent wherever it is asked: * `MonitorsResponse.pin_supported` — a CAPABILITY, reported by the build that would have to honor the pin rather than sniffed from the OS client-side. When a Windows mirror backend lands this flips and the console needs no change. `pinned` stays `None` off-Linux deliberately, and now says why: it is what the console highlights as "sessions stream this", and highlighting a head nothing will capture is the same lie in a different place. * `enforced` drops `capture_monitor` off Linux. That list is exactly the "which controls are live vs. coming soon" contract, and claiming this one unconditionally is what let the picker ship enabled. * The PUT drops a non-Linux `capture_monitor` instead of storing it, and logs that it did. COERCED, not rejected with a 400: this PUT is WHOLE-OBJECT, so a host that already stored a pin would have every later settings save rejected over a field the operator cannot see — taking the other axes down with it. This way such a policy self-heals on the next write. Console: the picker renders read-only with an explanation, reusing the `envLocked` shape rather than inventing a second one (`locked = envLocked || !pinSupported`). Managed heads were ALREADY excluded from selection here (`mon.enabled && !mon.managed`), which is the "grey out, never filter blindly" rule working as intended — the heads stay listed and explicable. `pin_supported` defaults to TRUE when absent so an older host, which only ever shipped this picker where it worked, is not retroactively locked out. ⚠️ `api/openapi.json` is hand-patched — punktfunk-host does not build on macOS, so the spec could not be regenerated from the binary. The shape was verified by running the real generator over it: orval emits `pin_supported: boolean` (required, no `?`) on `MonitorsResponse`. Verified: `bun run codegen` (orval + paraglide + i18n parity: 434 messages, en + de), `bun run build`, `bun run lint` (tsc --noEmit) all clean. Rust verified separately on .173 — see the next commit's note if that lands, since neither xcheck target covers punktfunk-host.	2026-07-29 00:18:27 +02:00
enricobuehler	ed021a13ee	test(vdisplay): give the 3.2 case eyes — a subscriber, and the probe that splits the two candidates ... §5 3.2 reproduces on glass and the shipped fix is not sufficient: the panel stays dark after teardown. Two candidates were left undistinguished by the first on-glass run — the adopted snapshot was already poisoned, or the dark-desk backstop never fired — because the case had no way to tell them apart. This adds that way. **The subscriber.** The adoption arm and `restore_displays_ccd`'s backstop announce themselves ONLY through `tracing`, and a bare `cargo test` harness installs no subscriber, so both events went nowhere. `tracing-subscriber` becomes a DEV-dependency of pf-vdisplay (the shipped host's closure through this crate is unchanged) and `init_test_tracing` wires it: `try_init` so a second live case in the same binary is a no-op rather than a panic, `with_test_writer` so it interleaves with the harness rather than racing `println!`, `RUST_LOG` still winning over the `debug` default. `live_inplace_resize` gets it too — its comment claimed tracing-subscriber "is not a dep of this crate, run the host binary for traced runs", which was the same blindness written down as a limitation. It no longer holds. **The probe is the actual discriminator, and it needs no logs at all.** Member 1's isolate is INJECTED to fail, so nothing of ours deactivates anything there. Sampling `active_physicals()` immediately after member 1's create therefore answers the question directly: * empty -> the arriving IddCx monitor took the desktop on its own. Every snapshot from that instant on records "panel off", so member 2's adopted snapshot is POISONED AT BIRTH and restoring it faithfully restores darkness. Adoption works; the snapshot SOURCE is the defect. * non-empty -> poisoning is excluded and the break is downstream: no adoption line means teardown's restore was never gated on, a backstop line with a non-zero force-EXTEND rc means the remedy itself failed. The failing assertion now reads that verdict out instead of asserting one cause, so the next on-glass run reports which link broke rather than only that one did. ⚠️ Still UNRUN on glass — this is the instrument, not the measurement. Needs .173's CONSOLE session (ssh is session 0 and CCD sees nothing there), and it can leave the desk dark: recover with `SDC_USE_DATABASE_CURRENT|SDC_APPLY`, not EXTEND, which returns rc=31 against a single display. Checked while writing this, and recorded so it is not re-derived: the "backstop is structurally inert on a one-display box" theory does NOT survive. Both real call sites restore BEFORE the virtual is REMOVEd, so two displays are connected and the preset applies — `live_force_extend_*` measured exactly that (1 -> 1 -> 2). The documented residual is narrower: a restore that fails once the virtual is already gone. Verified: `xcheck.sh windows clippy` clean (it passes `--all-targets`, so this test code really is compiled), `cargo fmt --all --check` clean. ⚠️ `Cargo.lock` moves with this commit and must not be split from it. CI runs `cargo clippy --workspace --all-targets --locked`, so a new dependency edge whose lockfile entry is missing does not degrade to a re-resolve — it FAILS the build outright. The dev-dependency adds one line (pf-vdisplay gains a `tracing-subscriber` edge; the package itself was already in the graph via punktfunk-host and pf-encode, so nothing new is vendored).	2026-07-29 00:18:27 +02:00
enricobuehler	8381fd73ef	test(vdisplay): bound the 3.2 case's creates, and what it found on glass ... A hang must fail the case, not wedge the box. The first attempt at this case hung inside `create`; killing the harness skipped every `Drop` and leaked an IddCx monitor, and a few of those exhaust the driver's slot pool — after which every later run wedges too and only a reboot clears it. Both creates now run on a worker thread with a 45 s budget, so the harness exits NORMALLY, which is what lets the driver reap the session. Re-run with matched host+drivers: no hang, no leak, and the box came back with the panel lit. ⭐ With that guard in, §5 3.2 REPRODUCED ON GLASS for the first time (.173, LG TV attached, host 0.21.0 + drivers 9.9.728.2241, first isolate injected to fail): physicals before : [(4352, "LG TV SSCR2 [HDMI]")] after member 1 (isolate INJECTED to fail): [(260, "punktfunk [punktfunk-virtual]")] after member 2 (isolate REAL) : [(260, …), (264, …)] physicals during : [] physicals after teardown : [] <-- the operator's panel, still dark So the shipped 3.2 fix — adopt the first SUCCESSFUL isolate as the group's restore snapshot — is necessary but NOT sufficient. Two candidate reasons, both worth checking before changing code: * The adopted snapshot is already POISONED. The panel went dark at member 1's create even though our isolate never ran (the injected failure), because the arriving IddCx monitor took the desktop on its own. Member 2's isolate then snapshotted a topology in which the physical was ALREADY inactive, so restoring it faithfully restores "TV off". This is the same poisoned-snapshot chain §5 already records from the field logs. * `restore_displays_ccd`'s dark-desk backstop did not rescue it either. Worth its own look, since 21eda37a is what first made that condition evaluable at all (before it, our own display counted as a lit physical and the guard could never fire). ⚠️ Not yet distinguished, because this case installs no tracing subscriber: whether the adoption arm fired at all, and whether the backstop ran and failed or never ran. That is the next diagnostic — `live_inplace_resize` shows the pattern for wiring a subscriber into a live case. Also confirms 21eda37a in the field: the virtual displays report `tech=punktfunk-virtual` and are correctly absent from the physicals list, which is what makes "physicals after teardown: []" mean what it says rather than counting our own output as the operator's panel.	2026-07-29 00:18:27 +02:00
enricobuehler	22f2686680	feat(vdisplay/windows): the console can finally show the operator's real screens ... `GET /display/monitors` returned an empty list on every Windows host, plus a LINUX error string: `monitors::list` is a per-compositor dispatch whose non-Linux arm bails, and it never even got that far because `detect()` was not cfg-gated — on Windows it fell through to an `XDG_CURRENT_DESKTOP` sniff and failed with advice about setting `PUNKTFUNK_COMPOSITOR`, which the handler puts VERBATIM into the response. So the console showed no physical screen and its only explanation was Linux troubleshooting (sweep §13.17). The data was there all along. `target_inventory()` already walks the CCD database; it now also reports the geometry that walk had in hand — the driving source's position and mode, the GDI device name, the refresh rational, and `primary`. No second CCD walker. * `monitors::list_windows()` maps that onto `PhysicalMonitor`. Two fields cannot mean on Windows what they mean on Linux and are reported honestly rather than invented: `scale` is always 1.0 (Windows scaling is per-monitor DPI applied per application, not a compositor-global logical scale — so the geometry is PIXELS), and an INACTIVE head gets zeroed geometry because the CCD mode indices are only valid for active paths. Inactive heads are still listed, per `list`'s own contract, so "why can't I pick it?" keeps an answer. * `managed` is finally truthful. The doc says only KWin can tell a virtual output from a real head; Windows can too, via our own EDID manufacturer id in the device path (21eda37a). * `detect()` gets an honest non-Linux arm, the operator pin gated with it — naming a Wayland compositor on Windows could never be honoured either. * The handler reports `compositor: "windows"` instead of null-plus-a-Linux-error. ON GLASS (.173, host 0.21.0, TV attached): connector=\\.\DISPLAY1 enabled=true managed=false primary=true 3840x2160 @165Hz pos=(0,0) "LG TV SSCR2" Pinned by an `#[ignore]`d hardware case that asserts at least one NON-managed head is visible — the exact thing that was missing. Read-only, so it is safe against a live host. This also gives `capture_monitor` a picker on Windows, where the handler currently hardcodes `pinned: None`; wiring that is left for the per-monitor-capture work rather than smuggled in here. Verified on .173: `clippy -p punktfunk-host -p pf-vdisplay -p pf-win-display --all-targets -- -D warnings` clean; both xcheck targets clean.	2026-07-29 00:18:27 +02:00
enricobuehler	735cd99e8f	fix(ci/windows): the web install was the one CI site still running lifecycle scripts ... The Windows host job died in "Build + smoke-boot web console (bun)": $ bun2nix -o bun.nix error: bun is not installed in %PATH% error: postinstall script from "punktfunk-web" exited with 255 bun install failed (255) `web`'s `postinstall` is `bun2nix -o bun.nix` — Nix codegen that shells out to `bun` on PATH. This job runs a fetched PORTABLE bun by absolute path (`$env:BUN_EXE`), so PATH has none and the script aborted the install, taking the installer, the driver bundle and the publish steps with it. Every other web install in CI already passes `--ignore-scripts` — ci.yml (twice), web-screenshots.yml, sdk-publish.yml, plugin-kit-publish.yml, and the SDK install 25 lines further down THIS SAME FILE. This one line was the lone exception: the same N-1-of-N seam asymmetry the pf-vdisplay sweep keeps turning up. Nothing here needs those scripts — `bun run build` re-runs its own `prebuild` codegen, and ci.yml proves the build works after an `--ignore-scripts` install — and `bun.nix` is a Nix artifact this job neither consumes nor commits. deb.yml still regenerates it (bun on PATH there), so the self-regenerating contract is unchanged. ⚠️ Honest about the evidence: I could NOT reproduce the failure on .173. Invoking the portable bun by absolute path with `where bun` empty, the postinstall SUCCEEDED there — bun made itself resolvable to its own lifecycle script, which the SYSTEM-account runner evidently does not. So this is not a reproduced-then-fixed A/B. It is justified instead by construction: `--ignore-scripts` removes the dependency on bun2nix (and on how bun2nix locates bun) altogether, and aligns the step with every sibling. If the job goes green, that is the confirmation. ⚠️ Related trap for whoever deploys the console by hand: rebuilding `web/.output` does NOT take effect until the `PunktfunkWeb` SCHEDULED TASK is restarted — restarting the host service does not touch it. A server left running from before a rebuild serves HTML referencing the OLD asset hashes while disk holds the new ones, so every asset 500s while `/login` still returns 200. Hit on .173 today; `Stop-ScheduledTask PunktfunkWeb; Start-ScheduledTask PunktfunkWeb` fixes it.	2026-07-29 00:18:27 +02:00
enricobuehlerandClaude Opus 5	3d25482469	feat(client/windows): pinned host+profile tiles render in the grid ... The menu could pin since the last commit but nothing appeared, which is worse than not offering it. Each host's pins now render right after it, sharing its live status because they read the same record, with the profile named on an accent chip. A pin whose profile was deleted simply doesn't render. A pinned tile carries no menu of its own: it is a shortcut, not a second host, and pin/unpin already live on the primary tile's menu — the one place you decide it. Its hover key is `<fp>#<profile-id>` so two tiles for one host don't light up together. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 00:18:12 +02:00
enricobuehlerandClaude Opus 5	2a088e13a4	feat(client/windows): bind a host to a profile, connect with one, pin one, copy its link ... The WinUI half of §5.2: `Target` carries a one-off profile into the session's `--profile`, the host editor gains the binding picker, and the tile names its bound profile on a chip so what a plain click will do is visible without opening anything. Shape notes, both forced by this toolkit rather than chosen: - The flyout has no submenus, so "Connect with", "Pin as card" and "Unpin card" are flat items, one per profile, matched by prefix. The prefixes end in ": " so a profile named "Copy link" can't collide with a fixed entry. - The binding picker commits on change rather than at Save. The rest of that sheet is text boxes with draft refs, which need a Save; a ComboBox doesn't, and making it wait would be the odd one out. Semantics stay identical to the Linux client, because they are the design's, not the platform's: "Connect with" never rebinds, "Default settings" is `Some("")` so it really does override a bound host for one session, and a binding whose profile was deleted reads as Default settings and resolves to it. `pf_client_core::clipboard::set_text` is the small addition the crate needed for "Copy link" — the OS clipboard plumbing was already there, just private to the streaming bridge. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 00:17:15 +02:00
enricobuehlerandClaude Opus 5	b220daf537	feat(client/windows): the settings screen edits profiles too ... P1 on the WinUI shell. The same surface now edits either layer, switched by a combo above the section title — one settings UI, not a second editor that drifts from the first. The interesting difference from GTK is where the override gets recorded. This shell commits PER CONTROL, so it cannot hand over a list of touched rows the way a commit-on-close dialog can. Instead each control hands `SettingsOverlay::absorb` the effective settings before and after it fired, and absorb records the field that moved. The comparison is against what the control was SHOWING, not against the globals, so setting a value to whatever the global happens to be still records an override — the pin the design asks for — and nothing is ever removed by inference. ⚠️ The content key becomes `(scope, section)`. Keyed on section alone, switching scope diffs one scope's controls into the other's, which re-sets each reused ComboBox's items (clearing WinUI's selection) while skipping `selected_index` wherever the two scopes' values compare equal — the combos then render blank until touched. That is the same trap the section key already existed for, one axis wider. Only profileable rows render in profile scope: auto-wake, the library toggle, the decoder and GPU pickers and the forwarded-pad picker are facts about this device or this network, not about "Game vs Work". Two shapes follow from this toolkit rather than from the design. Creating a profile takes an auto-numbered name and is renamed from the row below, because ContentDialog here is text-only and cannot hold a text field — the same constraint that put the host editor in a tile. And Delete arms a root state that renders the confirmation declaratively, since dialogs here are elements with `is_open`, not calls. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 00:12:43 +02:00
enricobuehlerandClaude Opus 5	8299151a09	fix(client-core): drop nine GTK-client files a stray copy left in the crate ... An `rsync` with the wrong destination dropped the Linux shell's sources into `crates/pf-client-core/src/` and they rode along with the previous commit. Nothing referenced them — `lib.rs` never declared the modules, so they were dead weight rather than a build break — but a crate that says it is UI-agnostic must not have a GTK shell sitting in it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 00:04:57 +02:00
enricobuehlerandClaude Opus 5	ad99be2fb2	feat(client): the overlay learns absorb + clear, so per-control shells can edit profiles too ... Groundwork for the Windows half of P1, and a dedup of the Linux one. The two shells commit differently: GTK writes once when the dialog closes (so it can hand over a list of touched rows), WinUI writes on every control change (so it can't). `absorb` serves the second shape — give it the effective settings before and after one control fired, and it records the field that moved. That is deliberately NOT the diff-on-save the design rejects. The comparison is against the EFFECTIVE settings, i.e. what the control was actually showing, not against the globals — so setting a value back to whatever the global happens to be still records an override, which is exactly the pin the design wants. It only ever adds; removing an override stays an explicit, separate operation. `clear` is that operation, keyed by the overlay's own field names, with `resolution` as the one alias for the width/height/match-window tri-state a single control drives on every client. The GTK reset path now calls it instead of carrying its own `match` — that second list was already a place where the two could drift, and the next client would have made it a third. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 00:04:26 +02:00
enricobuehlerandClaude Opus 5	22cb975659	feat(client/linux): "Create shortcut…" — a double-clickable entry for a host or a pinned profile ... D1's last Linux piece (design/client-deep-links.md §5). The shortcut is a CONTAINER FOR A URL, not a second launch mechanism: it invokes the client with a positional `punktfunk://…`, the same door xdg-open and a browser prompt use. That is what makes it survive things it has no control over — scheme registration being lost, the host moving to a new address, the store being wiped — because the URL itself carries the stable id, the address and the pin. A pinned card writes its profile into the shortcut, so "Desktop · Work" on the app grid is one double-click to that exact session. Two sanitisation points that are not cosmetic: the filename is slugged to ASCII (a host called "Büro · Mac" must still produce a writable name), and the `Name=` value is flattened to one line — desktop entries are line-oriented, so a newline in a host name would end the key and turn the rest into another one. Under flatpak the sandbox cannot write ~/.local/share/applications, so the user gets the URL to place themselves — the fallback the design already sanctions. The `org.freedesktop.portal.DynamicLauncher` route, which exists for exactly this and shows its own confirmation, is the intended upgrade there and is not built yet. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 00:01:46 +02:00
enricobuehlerandClaude Opus 5	bd0103b1ac	feat(client/linux): a host edit sheet, and with it the clipboard toggle Linux never had ... Linux had "Rename" and nothing else, so two per-host settings that already existed in the store and on the Apple and Windows clients had no surface here at all: the per-host clipboard opt-in, and now the profile binding. A Linux user could not turn on a feature they were already paying the storage for. The sheet holds exactly the things that are properties of the HOST rather than of the stream — its name, whether this machine shares its clipboard with it, and which settings profile a plain click uses. A binding whose profile was deleted reads as "Default settings" and is cleaned up on save, which is the same "dangling resolves as none" rule the connect path follows. The menu entry becomes "Edit…", and the function and message follow: a `rename_dialog` that opens an "Edit Host" sheet is exactly the drift that confuses the next reader. Pinning stays in the card menu rather than doubling as a list of toggles here — one place to pin is enough, and it is the place you are already looking when you decide to. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 23:54:50 +02:00
enricobuehlerandClaude Opus 5	b9a7163556	feat(client/linux): the speed test writes where the tested host reads, and cards can copy their link ... Two WP3 pieces. **Speed test (§5.3).** Measuring the slow retro box downstairs used to re-tune the desktop upstairs: Apply always wrote the GLOBAL bitrate, which the design calls the sharpest existing symptom of the missing feature. It now writes the layer that host actually resolves bitrate from — the bound profile's override if it has one, the global if the host is unbound. A bound host whose profile inherits bitrate could legitimately mean either, so it gets both buttons instead of a guess. The target depends only on the host, so it is resolved before the test finishes and the button says where it will write ("Set in “Game”"). A one-off (a pinned card's profile) wins over the binding, and a dangling binding falls back to the global — the same precedence a connect uses. **Copy link.** Host and pinned cards can copy their own `punktfunk://` URL — the self-emitted form carrying the stable id *and* host+fp, so a link pasted into a Playnite entry or a Stream Deck macro still resolves after the host re-addresses or the store is wiped. A pinned card copies its profile with it, which is the whole point of pinning it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 23:53:20 +02:00
enricobuehlerandClaude Opus 5	08ec0f4239	feat(client/linux): pin a host+profile as its own card ... §5.2a: a profile you reach for regularly shouldn't live behind a context menu. Pinning one puts *Desktop · Work* in the grid next to *Desktop*, and clicking it is a plain one-click connect with that profile. The pin is presentation state on the host record — `pinned_profiles`, which has been in the store since P0 and unused until now. Deliberately NOT a duplicated host entry: that would fork pairing, WoL MACs and renames, and every host-level action would then need a "which card owns this" rule. So a pinned card is the same record rendered again with a profile attached: it shares the host's live status because it reads the same record, and a pin whose profile was deleted simply doesn't render. What each card offers follows from what it is. The primary card keeps the host actions and gains "Pin as card ▸" (listing only profiles not already pinned; "Default settings" isn't pinnable — the primary card is that). A pinned card offers the one-offs and its own removal, and deliberately not pair/rename/forget — it is a shortcut, not a second host, and offering destructive host actions there would blur the distinction. One action serves both directions: which kind of card it sits on decides whether it pins or unpins. Verified on .21: a host bound to "Game" renders its primary card with a neutral Game chip and, right after it, the pinned "Work" card with an accent chip, both showing the same online/paired state. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 23:49:06 +02:00
enricobuehlerandClaude Opus 5	b485f91f52	feat(client/linux): overridden rows say so, and can go back to inheriting ... The gap in what the scope switcher shipped: a profile was a one-way door. Overrides are recorded on touch and never inferred from comparing values — which is the right model, and exactly why "not overridden" needs an explicit way back. Each overridden row now carries an accent dot in its prefix and a reset button in its suffix, so which settings a profile actually changes is legible without reading every value against the defaults. Reset queues the field, re-opens the dialog in the same scope and lets the close handler commit everything else first — so one code path still builds the rows, including the rebuilt ones showing the inherited value again. Clears are applied after the touched fields for a reason: resetting a ComboRow can fire its change handler on the way past, and "back to inheriting" is the later, explicit intent. An unknown field in the cleared set warns rather than silently doing nothing — this list and the write-back list have to stay in step. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 23:34:42 +02:00
enricobuehlerandClaude Opus 5	fa430646ff	fix(packaging): the Pulse shim is never the client's, and never the host's requirement ... Same bug as the Arch package, in the other two packagings. The .deb CLIENT recommended `pipewire-pulse`. Apt installs Recommends by default and the shim Conflicts with `pulseaudio`, so this proposed pulling the user's sound server out from under them in exchange for something the client cannot use: audio.rs drives libpipewire-0.3 directly and opens no Pulse socket. (SDL is initialized with zero subsystems — gamepads only, on demand — so it brings no audio backend either.) The RPM HOST hard-Required `pipewire-pulseaudio`, which conflicts with `pulseaudio` on Fedora too — uninstallable for anyone running real PulseAudio. The host doesn't speak Pulse either; the shim is for the GAMES, which commonly emit through the PulseAudio API, and real PulseAudio serves those equally well. Demoted to Recommends, so the default Fedora box is unchanged and the informed choice stops being blocked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 23:14:56 +02:00
enricobuehlerandClaude Opus 5	7d18468477	fix(packaging/arch): a client that never speaks Pulse must not demand the Pulse shim ... `punktfunk-client` hard-depended on `pipewire-pulse`, which CONFLICTS with `pulseaudio` — so anyone keeping real PulseAudio could not install the client at all ("unresolvable package conflicts detected"), even though the client has no use for the shim: audio.rs drives libpipewire-0.3 directly for both playback and the mic uplink, and never opens a Pulse socket. Dropped it from the client. The host doesn't speak Pulse either — it captures the sink monitor natively — but the shim is genuinely useful there, for the GAMES, which commonly emit through the PulseAudio API. That's an optdepend, and one real `pulseaudio` satisfies just as well, so the host stops blocking that choice too. Both now match what the .deb and the RPM already said (Recommends / "degrade gracefully without it"); only the Arch package had hardened it into a conflict. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 23:14:56 +02:00
enricobuehler	6de325a6b6	fix(ci): the unsafe lint said warn while CI enforced it as deny, and main went red ... `unsafe_op_in_unsafe_fn = "warn"` was adopted workspace-wide in 39513528 on the assumption that `warn` is a soft setting you can clear at leisure. It is not: ci.yml runs `cargo clippy … -D warnings`, which promotes it to a hard error, so main has failed on EVERY commit since — Linux `rust` and `rust-arm64` both dying on `pf-client-core` with 70 E0133 errors, and windows-host.yml alongside them. A lint level that understates its own severity is worse than a strict one, so this states what CI already does — `deny` — and writes the exemptions down instead. Fourteen GPU/FFI backend files take `#![allow(unsafe_op_in_unsafe_fn)]`, each with its reason and the workspace Cargo.toml carrying the argument in full. They are not "not done yet": measured across them, 64% of the sites are a single third-party FFI call (ash, pyrowave-sys, libav, the NVENC/AMF entry tables), and of the 44 `unsafe fn`s only 4 have a body containing no unsafe operation at all. Since pf-encode also denies `undocumented_unsafe_blocks`, narrowing them means a hand-written SAFETY comment per line that could only restate the signature — the exact noise that made `unsafe` stop meaning anything here before. Everything else stays at zero and enforced, and each allow is removable on its own terms. Two smaller things this had to clear, both invisible to the job that would have caught them: - `service.rs`: `undocumented_unsafe_blocks` wants the proof on EACH block, and a comment covering a group of consecutive `unsafe` statements only credits the first — so the two `OwnedHandle` wraps became their own statements. Windows-gated, so only the .47 gate sees it. 37a42078 fixed the same class of failure in pf-frame/dxgi.rs concurrently; that fix is taken as-is here. - `clients/linux/ui_settings.rs`: `show`'s deletion left its doc comment stranded on `show_scoped`, which silently merged two unrelated doc blocks onto one fn. Removed. Verified by running the real CI commands, not proxies: on .21 fmt + `clippy --workspace --all-targets -- -D warnings` + the feature-gated `-p pf-encode --features nvenc,vulkan-encode,pyrowave` + build + test, all rc=0; on the Intel box .47 all four windows-host.yml clippy invocations, all rc=0. The arm64 job lints pf-client-core and punktfunk-client-linux, both covered here.	2026-07-28 22:32:30 +02:00
enricobuehler	f40c90aa23	refactor(host/inject/win-display): the Win32 unsafe surface is the FFI call, not the function ... `spawn_in_active_session` existed only to launder `spawn_inner`'s `unsafe fn` marker — and its own comment said why that marker was empty: the callee "has no caller-side preconditions, it validates the session/token itself and owns every handle it opens". A marker that documents the absence of a contract is not a contract. The two collapse into one safe fn whose `unsafe` now sits on the eight Win32 calls, each with the proof it actually needs. Kept `unsafe fn` exactly where a caller CAN break something: `merged_env_block` (a `*const u16` block it must trust), `spawn_host` (a borrowed job `HANDLE`), `desktop_name` (an `HDESK`), `inject_following_desktop` (a live synthetic-pointer device). Those bodies gain explicit blocks instead — `merged_env_block`'s pointer walk is the one place here where the proof is load-bearing rather than restating a signature, and it now says why the scan cannot run off the block's end. With those four files at zero, all three crates take `deny(unsafe_op_in_unsafe_fn)` at the root, next to the `undocumented_unsafe_blocks` deny they already had. The pair matters: alone, the older deny is satisfied by an `unsafe fn` body, which needs no blocks at all and so can hide an unproven FFI call. The workspace lint stays `warn` — it is a ratchet over the encoder backends still to be cleared, and a crate that reaches zero should not be able to drift back silently. Windows E0133 214 -> 182 (the remainder is the ash/AMF-dense encode backends). Verified on the Intel box .47 and on Linux .21: no errors, no `unused_unsafe`, no dead-code fallout.	2026-07-28 22:31:11 +02:00
enricobuehlerandClaude Opus 5	808eba7292	feat(client/linux): bind a host to a profile, or connect with one just this once ... The other half of P1 on GTK (design/client-settings-profiles.md §5.2): until now a profile could be created and edited but only *used* through `--profile` or a URL. Host cards get two menus, and they are separate on purpose — the predictability rule is that connecting with a profile must never change what the card does next time. - **Connect with ▸** is a one-off. It rides `ConnectRequest.profile` into the session's `--profile` flag and touches no stored state. "Default settings" in that menu is `Some("")`, not `None`: on a bound host, asking for the defaults is a real choice and has to survive as a value rather than degrade into "use the binding". - **Default profile ▸** is the explicit rebinding act. It writes straight onto the host record — the binding IS a field there, so there is no map to keep in step — matched by fingerprint, else by address, like every other per-host lookup in this client. - The card carries a **chip** naming its bound profile, so what a plain click will do is visible without opening a menu. A binding whose profile was deleted shows nothing and connects with the defaults, which is exactly what the resolver does. A URL's `profile=` now takes the same one-off route, since it is the same kind of thing. Verified on .21: `punktfunk://connect/Bound%20Box?profile=Work` against a host bound to "Game" spawned a session that logged `profile=Work id=bbbbbbbbbbbb` — the one-off won, and the binding on disk was untouched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 22:24:56 +02:00
enricobuehler	37a42078a0	fix(xcheck): mirror [workspace.lints] too — and the two things that hid behind it ... `scripts/xcheck.sh` stopped working the moment the workspace adopted its unsafe discipline (`52191071`). That commit added `[lints] workspace = true` to every crate manifest, and a member inheriting a lint table the workspace ROOT does not define does not merely lose the lint — cargo refuses to parse the manifest at all: error inheriting `lints` from workspace root manifest's `workspace.lints` `workspace.lints` was not defined The generated root mirrored `[workspace.package]` but nothing else. It now mirrors every `[workspace.lints.*]` table generically, so a future table (clippy, rustdoc, …) is picked up without touching the script again. That mattered more than a broken helper, because xcheck is the ONLY thing that lints these crates for Windows — the Windows CI job clippies `-p punktfunk-host -p punktfunk-tray`, which does not lint a dependency. So while it was down, two real failures sat on main unseen: * **pf-frame `dxgi.rs`, 8 × `clippy::undocumented_unsafe_blocks`.** `307ca88b`/`0a710fdf` split the D3DKMT/DXGI calls into one `unsafe` block per FFI call under a single shared SAFETY comment, but the lint wants a proof per block — a comment two lines up with an intervening statement does not count. Each site now carries its own. Not "as above", which this sweep already found to be a proof that rots when the block it points at moves. * **pf-win-display `input_desktop.rs`, one E0133.** `GetUserObjectInformationW` is an unsafe operation in an `unsafe fn` body, which `unsafe_op_in_unsafe_fn` (now warn workspace-wide, and `-D warnings` here) requires to sit in its own block. The SAFETY proof was already written; only the block was missing. The `&&` chain in `elevate_process_gpu_priority` keeps two separate blocks rather than one around the chain — wrapping it would destroy the short-circuit and always issue the relative-priority call. Same trap this sweep hit in `wait_mode_settled`. Verified: both xcheck targets clean again.	2026-07-28 22:17:43 +02:00
enricobuehler	21eda37aa3	fix(win-display): punktfunk's own display is not one of the operator's panels ... The IddCx driver declares `DISPLAYCONFIG_OUTPUT_TECHNOLOGY_HDMI` for its monitors (`packaging/windows/drivers/pf-vdisplay/src/monitor.rs`, `IDDCX_MONITOR_INFO::MonitorType`), and `output_tech_class`'s allowlist reads HDMI as a real external panel. So every consumer of `target_inventory` counted OUR OWN virtual display among the operator's physical monitors. Measured on .173: both targets came back `external_physical`, `[(4352, "LG TV SSCR2", HDMI), (257, "punktfunk", HDMI)]`. That is not cosmetic. `restore_displays_ccd` ends with the last-resort guarantee that the desk is never left all-dark: let (connected, lit) = target_inventory().filter(external_physical) … if connected > 0 && lit == 0 { force_extend_topology() } The restore runs BEFORE the virtual is REMOVEd, so our own still-active display kept `lit >= 1` and the backstop could NEVER fire — in exactly the situation it was written for. It also made our display a candidate "physical suspect" in the disturbance-attribution inventory, which `TargetInventory`'s own doc rules out ("only indirect/virtual targets (our own IDD included)"). Targets carrying our EDID manufacturer id ("PNK", stamped by the driver's edid.rs) are now classified `external_physical = false`, tech `punktfunk-virtual`. Matching on the monitor device path rather than the friendly name — the path carries the manufacturer id the OS itself derived — and on both spellings, since the CCD device-interface path uses `#` (`\\?\DISPLAY#PNK0000#…`) while the PnP instance id for the same monitor uses `\` (`DISPLAY\PNK0000\1&15ecd195&5&UID264`, observed on .173). Allowlist-shaped like `output_tech_class`, so a third-party virtual display is never silently adopted. ON GLASS, read-only, on .173 — and it caught the backstop's trigger live: target 264 active=true external_physical=false tech=punktfunk-virtual "punktfunk" target 4352 active=false external_physical=true tech=HDMI "LG TV SSCR2" The physical is dark while our virtual holds the desktop. Post-fix that is `connected=1, lit=0` — the backstop fires. Pre-fix it was `connected=2, lit=1` — suppressed. The new hardware case is deliberately READ-ONLY (creates and destroys nothing) so it is safe against a live host; repeated IddCx create/destroy churn is what wedges the driver's slot pool. Also adds `manager::FAIL_NEXT_ISOLATES`, a `#[cfg(test)]` seam that fails the next N `isolate_displays_ccd` calls, with every call site in manager.rs routed through it. The Phase-3 recovery legs fire only on a failed isolate, which real hardware does not produce, so they cannot otherwise be exercised. `#[cfg(test)]` rather than an env knob: this crate's live tests compile under `cfg(test)`, so no production switch exists that could disable display isolation on an operator's box. The §5 3.2 case built on it is included but is NOT yet a passing on-glass result — see the plan for where it got to. Verified on .173: clippy -p punktfunk-host -p pf-vdisplay --all-targets and -p pf-win-display --all-targets clean; pf-vdisplay 56 pass, pf-win-display 2 pass + hardware cases; both xcheck targets clean.	2026-07-28 22:17:26 +02:00
enricobuehler	2b2c6f045d	test(vdisplay): pin the force-EXTEND backstop on glass, with a real panel attached ... `force_extend_topology` does two jobs — stop a fresh IddCx monitor being CLONED onto the existing panel, and serve as `restore_displays_ccd`'s last-resort "the desk is not left dark" backstop. Probed directly on .173 with only the LG TV connected, its preset returns rc=31 ERROR_GEN_FAILURE while SDC_USE_DATABASE_CURRENT returns 0, which reads like a backstop that cannot back anything up. On glass it is not, and this case is the measurement that settled it. Active paths went 1 -> (virtual up) 1 -> (after force-EXTEND) 2: with one connected display there is nothing to extend across, hence rc=31; with the virtual present there are two and the preset applies. Both real call sites run in exactly that state — the restore fires BEFORE the REMOVE, so the virtual is still there. No defect. Recording it so nobody re-derives the alarming half from the rc alone. ⭐ It also caught the clone hazard live: the arriving virtual monitor did NOT get its own active path (1 -> 1); only the forced EXTEND gave it one (-> 2). That is exactly the "no distinct source -> no frames" case the function's own doc describes, observed rather than assumed. ⚠️ Residual, noted not asserted: a restore that fails once the virtual is already gone is back to one connected display, where EXTEND returns 31 and cannot re-light anything. Context for the sweep's other on-glass claims: the earlier `live_create_drop` and `live_inplace_resize` passes on this box were taken with the TV POWERED OFF (every monitor devnode Code 45), so they proved the driver round trip but never exercised deactivating a real panel. Re-run now with the TV attached, `live_inplace_resize` still reports in_place=true (target 257 -> 257, 2356x1332), so Phase 6.2 holds with a physical present. Verified on .173: clippy -p punktfunk-host -p pf-vdisplay --all-targets and -p pf-win-display --all-targets clean, 56 pass + 3 ignored, no orphans.	2026-07-28 22:17:26 +02:00
enricobuehler	ea9a25d3b1	fix(win-display): a host with nothing lit is an ANSWER, not a failed CCD query ... `query_active_config` asked `QueryDisplayConfig` for the active topology even when the sizing call had just answered `numPaths = 0`. Windows rejects a zero-count query rather than handing back an empty set, so "nothing is active" came back as "the query failed". Zero active paths is an ordinary state, not a broken one: every panel off or in standby, a KVM switched away, a headless box between its adapter arriving and its first monitor. The `None` propagated into the two places that matter — `count_other_active` reported failure where the honest answer is `Some(0)`, and `isolate_displays_ccd` bailed at its first line, which is exactly the teardown-gate condition whose recovery legs exist to stop the operator's physical panels being left dark (sweep §5 3.1). MEASURED on .173 (RTX 4090, Win11 26200) with the TV powered off — every monitor devnode Code 45, `numPaths = 0` for `QDC_ALL_PATHS` too — in a live, logged-on CONSOLE session: `GetDisplayConfigBufferSizes` returns 0 paths and `QueryDisplayConfig` then returns 0x57 ERROR_INVALID_PARAMETER (0x5 ERROR_ACCESS_DENIED from session 0). This is the mechanism behind the plan's ⭐ note that `count_other_active(&[])` yields `None` on that box: not the API refusing us, just a query nobody should have made. Three changes, one defect: * `query_active_config` short-circuits `numPaths == 0` to an empty-but-valid config. * `isolate_displays_ccd` returns that empty snapshot straight away instead of entering its retry loop. Nothing is active, so nothing needs deactivating and nothing needs restoring; the loop's re-commit exists to drive the IddCx adapter's COMMIT_MODES, and with no path at all there is no config to commit — four attempts would each log a rejected apply and sleep 250 ms to reach the topology we already have. `restore_displays_ccd` already treated an empty config as the no-op it is, so the round trip stays consistent. * `set_virtual_primary_ccd` goes through the shared query. It carried a verbatim copy of it — same flags, same shape — and was therefore the one CCD entry point that would not have inherited the fix. Same seam asymmetry this crate keeps producing, and two hand-written unsafe blocks go with it. Also this file's first tests. The case is `#[ignore]`d hardware, so it reports `ignored` rather than a vacuous `ok` when nobody runs it. On-glass A/B in the console session on .173: it passes with the short-circuit and FAILS without it, naming the conflation. A box that does have a display lit passes either way. ⚠️ The test is read-only and must stay that way — the obvious companion assertion, `isolate_displays_ccd(&[])`, is deliberately not written: an empty keep set means "keep nothing", so on a box with displays it would deactivate every one of them. Verified on .173: `clippy -p punktfunk-host -p pf-vdisplay --all-targets` and `clippy -p pf-win-display --all-targets` both clean, pf-vdisplay 56 pass, pf-win-display 1 pass + 1 ignored. Both xcheck targets clean.	2026-07-28 22:17:26 +02:00
enricobuehler	5a14d2b3f4	fix(vdisplay): the helper budget must end the tree, not just the process we spawned ... `Child::kill` is one `TerminateProcess`: it ends exactly the process we launched. On Unix that is the whole story here — `kscreen-doctor`, `systemctl`, `pw-dump` are single processes we exec directly. On Windows there is no direct exec, so every helper is reached through a shell (`cmd /c …`, `powershell -Command "… | pnputil …"`) and the process that actually hangs is a GRANDCHILD. Killing the shell left it running, holding the stdio handles and the working directory it inherited from us, which means the budget bounded nothing. Not theoretical: it is why a fully green `cargo test -p pf-vdisplay` still failed its CI job on `33a31427`. The suite's own hung-helper case orphaned a 60-second `ping.exe`; it kept the build step's stdout pipe open past the runner's 10 s WaitDelay ("exec: WaitDelay expired before I/O complete") and pinned `crates\pf-vdisplay` so the workspace could not be cleaned up. The tests reported `55 passed; 0 failed` in the same log. Spawned children are now enrolled in a Job object. Job membership is inherited across `CreateProcess`, so one `TerminateJobObject` ends every descendant, and `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE` makes that hold on paths that never reach the explicit call — an early `?`, a panic — because closing the last handle is then itself the kill. Best-effort: a box that cannot make a job object degrades to the single-process kill it did before rather than failing the query, the same stance as the already-ignored `Child::kill`. `output_within` ends the tree BEFORE `wait_with_output`. That read runs to EOF, and a grandchild outliving the helper holds the write end — the one way this "bounded" helper could still hang forever. The new test is the permanent lever, and it is not vacuous: it asserts the grandchild reached its first marker before asserting it never reached its second. Verified on .173 (Win11 26200): 56 pass, `clippy -p punktfunk-host -p pf-vdisplay --all-targets` clean, no `ping.exe` survivors. A/B with the job disabled: the test fails with "a grandchild outlived the budget" and one orphan survives. On the CI runner .133 the job APIs were also checked directly, as Administrator (already inside a job — nesting works) and as SYSTEM: both kill the tree. Trap for anyone editing that test: a .cmd file is read in the OEM code page, so an absolute path baked into it is mangled the moment the temp dir holds a non-ASCII character (`C:\Users\Enrico Bühler\…` arrives as `B?hler`) and every redirect fails with "path not found". It uses `%~dp0` instead, so the file stays pure ASCII.	2026-07-28 22:17:26 +02:00
enricobuehlerandClaude Opus 5	cf419d8b6f	feat(client/linux): the settings dialog edits profiles, not just the defaults ... P1's core on GTK (design/client-settings-profiles.md §5.1). The same surface now edits either layer: a scope switcher at the top of General swaps between "Default settings" and one profile's overrides. Deliberately not a second editor — a parallel one would drift from this one field by field, which is exactly what the "one settings UI" principle is there to prevent. Three decisions carry the design's semantics into this file: - Rows always show the EFFECTIVE value — the global underneath with the profile's overrides applied — so a row the profile doesn't touch reads as the live global. That is what "inherit by default" has to look like. - Overrides are recorded ON TOUCH, never by diffing values at save time. A profile may therefore pin a value that happens to equal today's global and keep it when the global later moves. The handlers that record this are installed after the seed pass, or opening a profile would override every row in it. - Only profileable rows render in profile scope. Auto-wake, the library toggle, the decoder and GPU pickers, the audio endpoints, the forwarded-pad picker and the detected pad list are facts about this device or this network, not about "Game vs Work" (§3's tier G/H), so they simply aren't there. Switching scope closes the dialog — which commits the layer being edited — and asks the app to re-open in the new one, so there is a single code path that builds the rows and no ambiguity about commit ordering. Both scopes read the controls through one shared closure; the tri-state resolution row is the obvious trap if they ever diverged. Create / Rename / Duplicate / Delete live in the switcher's group. Names are unique case-insensitively and the prompt refuses duplicates in place rather than after the dialog is gone. Delete counts what actually breaks — hosts that fall back to the defaults, pinned cards that disappear — and leaves bindings dangling on purpose: they resolve as "no profile" everywhere, and rewriting every host record here would be a second, racier source of truth. `PUNKTFUNK_SHOT_SETTINGS_SCOPE` puts the screenshot scene into profile scope, so both halves of the surface are capturable. Verified on .21 under Xvfb: the switcher, the per-profile actions and the tier filtering render, and the Statistics row seeds to the Game profile's "Detailed" rather than the global's value. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 22:05:29 +02:00
enricobuehlerandClaude Opus 5	6cf5d4ab87	feat(client/linux): punktfunk:// links open the GTK client ... D1's activation half (design/client-deep-links.md §4.1). The client already had a `--connect` CLI, but nothing claimed the scheme, so nothing outside a terminal could start a stream: no browser prompt, no xdg-open, no double-clickable shortcut. The `.desktop` entries gain `MimeType=x-scheme-handler/punktfunk;` and `Exec=… %u`, and the rpm scriptlet joins deb and arch in running `update-desktop-database` — an entry nothing indexes claims nothing. (nix substitutes the Exec line by prefix, so `%u` survives; flatpak's exported entry is renamed to the app id by the standard mechanism.) In the app, `HANDLES_OPEN` plus a positional-URL argv is the whole mechanism, and the second half is the interesting one: argv stays withheld from GApplication as before EXCEPT when it carries a URL, and then GIO's own single-instance forwarding delivers it to the running window over D-Bus. Clicking a link with Punktfunk already open reuses that window instead of racing a second instance, and we wrote no IPC to get it. A URL that lands during a cold start (before the model exists) is parked rather than dropped — silently losing a link is the one outcome that would make the feature untrustworthy. Routing is four lines of translation, because the decisions are the brain's: parse, resolve the host, resolve the profile, refuse. A link that resolves becomes exactly the message a card click raises — the same wake, trust gate, and error surfaces — so there is no second connect path to keep in sync. A link to a host we don't know, or know but never pinned, opens the ordinary PIN ceremony seeded with what the link claimed, which is how "a URL may never pair or trust on its own" stays true while still being useful. Never preempting a live session is checked here, since only this layer knows one is running. Verified on .21 under Xvfb against hand-authored stores: `connect/Bound%20Box?launch=` resolved the host by name, carried the launch id through the trust gate, and spawned the session; `punktfunk://pair/1234` and an unknown `profile=` both refused before any dial. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 21:37:10 +02:00
enricobuehler	c262bf43df	refactor(host): three more Windows unsafe fns that had no caller contract ... Continues the crate-by-crate `unsafe_op_in_unsafe_fn` work. Same finding as pf-frame: the useful move is often deleting the `unsafe fn` marker, not decorating the body. `install_steam_audio_pair` (no arguments) and `try_install_steam_audio(&str)` are now safe fns. The call sites had already worked this out — both carried a SAFETY comment opening "`install_steam_audio_pair` is `unsafe` only because it `LoadLibraryExW`s `newdev.dll`", i.e. the obligation was never the caller's. Making them safe deletes 14 lines of that prose from two call sites and moves the real reasoning next to the `LoadLibraryExW`/`transmute`/call chain it actually describes. wasapi_mic.rs: 8 -> 0. `make_job` (no arguments, and it wraps its handle in an `OwnedHandle` before the first fallible step) and `open_log_handle(&Path)` are safe fns too. The latter returns a raw `HANDLE`, but that is an ownership obligation, not a safety one — nothing a caller does with it can cause UB, and it is inherited by the child and closed there. service.rs: 19 -> 14. `spawn_host` keeps `unsafe fn`: it takes a raw `HANDLE`, and an invalid one is UB. That is a contract worth stating, so it keeps the marker. Windows-only note: `LoadLibraryExW` here already passes `LOAD_LIBRARY_SEARCH_SYSTEM32`, so the newdev.dll load cannot pick up a planted DLL from the working directory — now recorded in the SAFETY note rather than left implicit. Verified on Windows .47: punktfunk-host clean at EXITCODE=0 — zero errors, zero unused-unsafe. Crate's own files now 29 E0133 (interactive.rs 15, service.rs 14), down from 42.	2026-07-28 21:31:42 +02:00
enricobuehler	307ca88ba7	refactor(frame): dxgi.rs to zero E0133, and two of its unsafe fns didn't need to be ... First crate done under `unsafe_op_in_unsafe_fn`. 23 sites -> 0, and the file's `unsafe fn` count drops 5 -> 2, because narrowing was the wrong answer for two of them: `enable_inc_base_priority` takes no arguments and touches only the current process's own token. `hags_enabled` takes a `LUID`, a plain value with no pointer a caller could get wrong, and builds every gdi32 argument struct locally. Neither leaves a precondition for a caller to uphold, so neither should have been `unsafe fn` at all — they are now safe fns with the unsafe confined inside, which deletes the obligation from their callers rather than restating it. That is a strictly better outcome than wrapping their bodies, and it is invisible if you treat the lint as a mechanical find-and-wrap. `d3dkmt_set_scheduling_priority_class` stays `unsafe fn`: it takes a `HANDLE`, and an invalid one is UB. That contract is real, so it keeps the marker and gains narrow blocks inside instead. The rest is narrowing. The clearest win is `elevate_process_gpu_priority`, whose `ONCE.call_once(|| unsafe { .. })` had 25 lines inside one block — a `match` on a config enum, three `tracing!` arms and an early return — for exactly one call that needed it. That block is gone; only the `d3dkmt_*` call carries `unsafe` now. Every remaining block is scoped to the FFI call it covers and carries a SAFETY note naming what makes it hold: which handle is live, which local the callee writes, which size matches which variable. Verified: Windows .47 pf-frame clean at EXITCODE=0 — zero errors, zero E0133, zero unused-unsafe. Linux .21 pf-frame zero errors (dxgi.rs is Windows-gated, checked for regressions in the shared parts).	2026-07-28 21:31:42 +02:00
enricobuehler	0a710fdfe5	refactor(frame): narrow make_device's unsafe to the FFI calls themselves ... First slice of the `unsafe_op_in_unsafe_fn` work on the Windows-gated code, and a deliberate demonstration of the shape the rest should take. `cargo fix` is NOT the tool here. Its suggestion for this lint wraps the entire function body: pub unsafe fn make_device(..) -> Result<..> { unsafe { ..40 lines.. }} One block spanning everything, `{ unsafe {` / `}}` bracing, and — the actual problem — zero change in how much code runs unchecked. It makes the status quo explicit rather than smaller, which is the opposite of the goal. Narrowed by hand instead: four blocks, each around the FFI call that needs it (`D3D11CreateDevice`, two `SetGPUThreadPriority`, `SetMaximumFrameLatency`), each with its own SAFETY note. The `Option` handling, the `?`, the `if let Ok(..)` casts and the `tracing!` calls are back outside, where the compiler checks them. Roughly 40 unchecked lines become 6. Fixed two of my own mistakes in the same pass: `elevate_process_gpu_priority` and `auto_priority_gate` are ALREADY safe fns, and I had wrapped their calls in `unsafe` out of momentum. Unnecessary `unsafe` is not free — it is the same "this is scary" noise the lint exists to remove, and the compiler only warns about it. That mistake is a good argument against doing the remaining ~590 sites mechanically. pf-frame drops 23 -> 19 E0133. The remaining three functions in this file need a different answer, not just narrowing: `enable_inc_base_priority` takes no arguments and touches only the current process's own token, so it has NO caller contract and should become a SAFE fn with unsafe blocks inside — which removes an `unsafe fn` rather than decorating it. Same likely for `hags_enabled(LUID)`, whose only argument is a plain value. Verified on Windows .47: pf-frame checks clean at EXITCODE=0, no errors, no unused-unsafe warnings.	2026-07-28 21:31:42 +02:00
enricobuehler	a3843b6996	test(encode): the VAAPI dmabuf path verified on AMD silicon, and its owner-only fields say so ... Closes the last unverified leg of the AvBuffer work. `DmabufInner` was the heaviest ownership change in the crate — four owned objects (DRM device, derived VAAPI device, DRM-PRIME frames ctx, filter graph) whose eight failure branches each repeated the same four-line unwind, once inside a macro, plus a ninth copy in `Drop` — and it had no coverage at all. `vaapi_cpu_encode_smoke` does not reach it: that drives the swscale/CPU-upload path, which uses `VaapiHw` and never builds a graph. `dmabuf_inner_alloc_drop_cycles` loops construct/drop, which is the whole contract now that every handle releases itself. **It passes on a Radeon 780M**, as do the two pre-existing VAAPI tests, so `VaapiHw` and `DmabufInner` are both hardware-verified rather than compile-only. Also fixes three more owner-only fields the AMD box surfaced: `graph`, `vaapi_device` and `drm_device` are `never read` since the hand-written `Drop` that used to read them is gone. Same call as the decoders and the QSV pair — annotate rather than delete (removing `graph` would free it while `src`/`sink` still point into it) or underscore-rename (which hides what they hold). `drm_frames` is NOT annotated: `submit` genuinely reads it per frame. I had missed these twice: my Linux log greps searched "never constructed|never used", which does not match "never read". The check now includes all three spellings. Two environment notes worth keeping, both diagnosed by testing OUTSIDE our code first (ffmpeg's own CLI reproduced each): * Inside a distrobox on an immutable host, VAAPI needs `LIBVA_DRIVERS_PATH=/run/host/usr/lib64/dri`. The container's mesa (25.3.6) is older than the host's (26.0.4) and every encoder open fails with a bare ENOSYS — "Function not implemented", naming nothing. The test doc says so. * `cargo check --workspace` in that container fails on `glib-sys` (no GTK dev headers). Unrelated to this branch; .21 checks the full workspace clean. Verified: AMD .116 (Radeon 780M, Mesa 26.0.4) full pf-encode suite 33 passed / 0 failed plus all 3 ignored VAAPI hardware tests green. Linux .21 workspace check exit 0 / zero errors, pf-encode 33/0, pf-client-core 34/0, and zero dead-code warnings across all three spellings.	2026-07-28 21:31:42 +02:00
enricobuehler	4241bc0383	fix(encode/windows): enable D3D11 multithread protection before libav sees the device ... libav turns on `ID3D11Multithread::SetMultithreadProtected` in `d3d11va_device_create` — the path where it creates the device itself. We take the other path, `d3d11va_device_init`, because we hand it the capturer's existing `ID3D11Device`, and that path does not. Nothing enabled it on our side either, so it was simply off. Two consequences, one of them shipping since long before this branch: QSV zero-copy could not open at all. `av_hwdevice_ctx_create_derived(QSV <- D3D11VA)` ends in `MFXVideoCORE_SetHandle`, and MFX rejects a device without multithread protection as `MFX_ERR_UNDEFINED_BEHAVIOR (-16)`. libav reports that as "Error setting child device handle", which names neither the cause nor the cure. AMF — the DEFAULT Windows zero-copy path — has been running with a lock that does nothing. We deliberately leave `lock`/`unlock` null so libav installs its `d3d11va_default_lock`, and that lock is `ID3D11Multithread::Enter`/`Leave`, which are documented no-ops while protection is off. The lock libav installs to serialise our capture thread against its encode thread has therefore never actually serialised anything. That is the more serious half of this fix, and it is not QSV-specific. Measured on the Intel VM (UHD 750, FFmpeg 7.1.5 + libvpl), sweeping device flags x adapter x protection: BGRA -> QSV derive FAILED (-16) BGRA +MT -> QSV derive OK BGRA|VIDEO +MT -> QSV derive OK `D3D11_CREATE_DEVICE_VIDEO_SUPPORT` makes no difference in either direction, and the same result holds on both Intel adapters the box enumerates. Protection is the only variable that matters, and it read back `was=false` every time, confirming nothing else had enabled it. The hypothesis came from ffmpeg's own CLI succeeding at the identical derive (`-init_hw_device d3d11va=d3d -init_hw_device qsv=q@d3d`) — the only difference being who created the device. With this, `zerocopy_qsv_alloc_drop_cycles` passes on real Intel silicon, which also makes the QSV arm of the AvBuffer refactor hardware-verified rather than compile-only. Its doc comment now points back here, since a future regression will present as that same opaque "child device handle" line. NOT flipped: `zerocopy_active` still defaults QSV off. The derive works and the handles construct and release cleanly, but that is not the same as a validated streaming session, and the default should move on glass evidence, not on this. Verified on .47 (Intel UHD 750): full pf-encode --features amf-qsv suite 39 passed / 0 failed, d3d11hw_alloc_drop_cycles green, zerocopy_qsv_alloc_drop_cycles green, and the native VPL path (qsv_encode_live_smoke) still green. Linux .21: workspace check exit 0 / zero errors, pf-encode 33/0, pf-client-core 34/0.	2026-07-28 21:31:42 +02:00
enricobuehler	2d78d2a514	test(encode): D3d11Hw verified on real silicon; the QSV derive is broken upstream of us ... Ran the QSV probe on the Intel VM (UHD 750, FFmpeg 8). It fails — and not in the code it was written to cover: [AVHWDeviceContext] Error setting child device handle: -16 ZeroCopyInner::open(QSV) failed on iteration 0: derive QSV device from D3D11VA That is `MFX_ERR_UNDEFINED_BEHAVIOR` out of `MFXVideoCORE_SetHandle`, raised inside `av_hwdevice_ctx_create_derived` — libav's own code, called with the same arguments as before this branch. Confirmed pre-existing by A/B: the same probe, written against unmodified `origin/main` with the raw-pointer struct, fails byte-identically on the same box at the same first iteration. The ownership change is not implicated. It is also not the hardware. `qsv::tests::qsv_encode_live_smoke` — the native VPL backend, untouched by this branch — encodes real H.264 on that box via VPL 2.15 with its own D3D11 zero-copy. So QSV works; libav's QSV-from-D3D11VA derive is what does not. That matches `zerocopy_active` already defaulting QSV **off** pending Intel validation, and is now a measured fact rather than a suspicion. The test stays, `#[ignore]`d, with the finding in its doc comment so the next Intel driver / FFmpeg bump re-checks it instead of the question being quietly dropped. What that leaves is real coverage of the half that IS reachable anywhere: `d3d11hw_alloc_drop_cycles` loops construct/drop on `D3d11Hw`, the hwdevice + frames-pool pair both Windows zero-copy vendors share, so it covers the AMF path's ownership without needing AMD hardware. **It passes on the Intel box: 8 cycles, no abort.** Adapter selection is factored into `test_hw_device`, which prefers a vendor and skips the Microsoft Basic Render Driver — a punktfunk host enumerates our own virtual-display adapter too, so `EnumAdapters1(0)` is not a safe assumption. Verified: QSV VM .47 full `pf-encode --features amf-qsv` suite 39 passed / 0 failed (EXITCODE=0), with `d3d11hw_alloc_drop_cycles` green on real silicon. Linux .21 workspace check exit 0 / zero errors, pf-encode 33/0, pf-client-core 34/0.	2026-07-28 21:31:41 +02:00
enricobuehler	564797a12a	test(encode): a QSV construct/drop smoke test, and AvFilterGraph goes Linux-only ... Two loose ends ahead of running this on real Intel silicon. `zerocopy_qsv_alloc_drop_cycles` covers the one ownership question in the crate that was genuinely ambiguous. `ZeroCopyInner::open` builds a `D3d11Hw` and then DERIVES a QSV device + frames ctx from it, and the tuple it used to return handed those two derived pointers out twice — once as the encoder's args, once as the pair moved into `Self`. Free for raw pointers, two owners for `AvBuffer`. Looping construct/drop is what separates the outcomes: a double-unref aborts in the CRT, a missed one leaks an Intel device per session. Nothing else reaches this code — `zerocopy_enabled` defaults QSV OFF, and the native VPL backend supersedes this whole file unless `PUNKTFUNK_QSV_FFMPEG=1` — so the test calls `open` directly and sidesteps both gates, the same shape as `cuda_hw_alloc_drop_cycles`. `AvFilterGraph` is now `#[cfg(target_os = "linux")]`. The Windows gate had been reporting `struct AvFilterGraph is never constructed` since a960dff8 and I had been filtering it out of my own log greps (searching for "never read", which does not match "never constructed"). It is true: the VAAPI dmabuf path is the only filter-graph user, and the AMF/QSV backends build no graph. Cfg'd out rather than `allow`ed, so it cannot outlive its last caller unnoticed. Verified. Windows .133: `cargo test -p pf-encode --features amf-qsv --no-run` at EXITCODE=0 with the AvFilterGraph warnings gone (107 -> 105), and the test binary lists `ffmpeg_win::tests::zerocopy_qsv_alloc_drop_cycles`. Linux .21: workspace check exit 0 / zero errors, pf-encode 33 passed / 0 failed, pf-client-core 34 passed / 0 failed, and zero dead-code warnings there (AvFilterGraph is live on Linux). NOTE for running it: the test binary needs `C:\Users\Public\ffmpeg\bin` on PATH at RUNTIME. `FFMPEG_DIR` is build-time only, and without the DLLs the harness exits silently with no output at all — which reads exactly like a test that does not exist.	2026-07-28 21:31:41 +02:00
enricobuehler	e60fee7da6	refactor(encode): the QSV derived pair stops being two owners of the same pointer ... `ZeroCopyInner` held the QSV device + frames ctx as nullable raw pointers, where null meant "AMF, which feeds D3D11 frames directly" — a convention documented in a comment and enforced by three `is_null()` checks. `Option<AvBuffer>` says it in the type, so the checks and the hand-written `Drop` both go away. The reason this one was left out of the previous commit is the aliasing. `open` built a five-element tuple whose QSV arm handed the SAME two pointers out twice: once as the encoder's `dev_ref`/`frames_ref`, once as the pair moved into `Self`. For raw pointers that is free; for an owning type it is two owners and a double-unref. Ownership and borrowing are now separated — the pair is owned in `qsv_frames`/`qsv_device`, and the encoder's arguments are `as_ptr()` views taken from whichever owner applies. `open_win_encoder` takes its own refs of what it is handed, so lending transfers nothing. Net: all 13 `av_buffer_unref` calls in this file are gone (the last two hand-written Drops with them), including the encoder-open failure arm, which collapses to `?` now that every handle releases itself. Field order pinned and commented, as with the others: QSV frames, QSV device, then `enc`, then `hw` — reproducing the old `Drop`, which ran ahead of all fields and so released the derived pair before the encoder's AddRef'd copies and the D3D11 refs. `qsv_device` picked up an `#[allow(dead_code)]`: `qsv_frames` is still read by the send path, but the device is now purely an owner (the frames ctx and the encoder each hold their own ref). Same call as the decoders — deleting it would free the device early, an underscore name would hide it. Verified on BOTH: Windows .133 `cargo check -p pf-encode --features amf-qsv --all-targets` EXITCODE=0, no dead-code warnings, and confirmed non-vacuous (log shows `Removed 23 files, 36.2MiB` then a real `Checking pf-encode`). Linux .21 `cargo check --workspace --all-targets` exit 0 / zero errors, pf-encode 33 passed / 0 failed, pf-client-core 34 passed / 0 failed, and `cuda_hw_alloc_drop_cycles` still passing on real CUDA. The QSV path itself still wants Intel silicon to exercise.	2026-07-28 21:31:41 +02:00
enricobuehler	5b142a7e85	refactor(encode): the Windows D3D11VA hwdevice owns its refs ... `D3d11Hw::new` is the third instance of the same shape as `CudaHw` and `VaapiHw` — alloc a hwdevice, deref to fill it, init, alloc a frames ctx, deref, init — with the same hand-written unwind: three `av_buffer_unref` calls spread over the failure branches plus a `Drop` repeating the pair. It gets the same treatment, so all three libav hwdevice wrappers in the crate now share one release path. Field order carries the semantics here as in the other two: frames declared before device, so declaration-order dropping reproduces what the hand-written `Drop` did. `ZeroCopyInner`'s `qsv_device`/`qsv_frames` are deliberately NOT converted in this commit. They are nullable (null for AMF, which feeds D3D11 frames directly), and the QSV branch hands the same two pointers out twice — once as the encoder's `dev_ref`/`frames_ref` and once as the owned pair moved into the struct. Modelling that needs `Option<AvBuffer>` plus a borrow/own split so the aliasing does not become two owners, which is a different change from the mechanical one this commit makes. Verified on the Windows runner .133: `cargo check -p pf-encode --features amf-qsv --all-targets` at EXITCODE=0. Confirmed non-vacuous — the log shows `cargo clean -p pf-encode` removing 23 files / 36.2 MiB followed by a real `Checking pf-encode`, because a fast green on that box can otherwise just be cargo reusing artifacts whose timestamps outrank the freshly-extracted sources.	2026-07-28 21:31:41 +02:00
enricobuehler	06a406adf2	refactor(client): the D3D11VA decoder owns its refs too, and the owner-only fields say so ... Completes the decoder trio. `D3d11vaDecoder::new` had the same cascading unwind as the VAAPI and Vulkan constructors — four branches each unref'ing the hwdevice by hand — and `d3d11va_decode_supported` opened a frames context it released on one exit path while relying on the null check for the other. Both are `AvBuffer` now. The one surviving `av_buffer_unref` in the file is deliberate: it runs before ownership is taken, on the `av_hwdevice_ctx_init` failure ahead of `from_raw`. The Windows gate then caught something worth keeping: `field hw_device is never read`, in all three decoders. It was true and it was new — the hand-written `Drop` used to be the field's only reader, so moving the unref into the type left a field that is *purely* an owner. The compiler cannot express that, so each one now carries a doc comment saying what it is and an explicit `#[allow(dead_code)]`. Deleting the field would free the device early; renaming it `_hw_device` would silence the lint by hiding what it holds. Neither is what we mean. Verified on BOTH platforms this time. Windows runner .133 (the toolchain env from the runner notes, plus `PF_FFVK_VULKAN_INCLUDE` for pf-ffvk): `cargo check -p pf-client-core --all-targets` at EXITCODE=0, clean of the dead-code warnings. Linux .21: `cargo check --workspace --all-targets` exit 0 / zero errors, pf-client-core 34 passed / 0 failed, pf-encode 33 passed / 0 failed.	2026-07-28 21:31:41 +02:00
enricobuehler	a42ab075a8	refactor(client): the hardware decoders own their hwdevice ref ... `VaapiDecoder::new` and `VulkanDecoder::new` create a hwdevice and then do several more fallible things with it — resolve `vkWaitSemaphores`, find the decoder, alloc the context, open it — and every one of those branches unref'd the device by hand, with a `Drop` doing it once more. Six hand-written unrefs between them, each one a line somebody has to remember when adding a step. `video_libav::AvBuffer` owns it instead, so an early `bail!` releases it and the branches carry nothing. It is a deliberate second copy of `pf-encode`'s type: the crates do not depend on each other (host encode and client decode share no code path), and this one needs something the host's does not — see below — so hoisting it to a shared crate would mean giving that crate an ffmpeg dependency and both sets of semantics to save about twenty lines. That extra piece is `into_raw`. `pick_vulkan` hands its frames context to the codec (`(*ctx).hw_frames_ctx = fr` — the codec unrefs it when the context closes), so the wrapper must give up ownership rather than drop. Making the transfer explicit is the point: dropping an `AvBuffer` there too would be exactly the double-unref this type exists to prevent. Two `av_buffer_unref` calls survive in `video_vulkan.rs` on purpose. One runs before ownership is taken (the `av_hwdevice_ctx_init` failure, ahead of `from_raw`); the other releases the codec's OWN pre-existing frames ctx before we replace it, which was never ours to model. Field order preserved: `hw_device` stays declared after `ctx`, so it still releases after each `Drop` frees packet/frame/context — the order the hand-written unref had. Verified on .21 (CachyOS, FFmpeg 62): `cargo check --workspace --all-targets` clean at exit 0 with zero errors — the workspace-wide check owed since the AvBuffer commit — plus pf-client-core 34 passed / 0 failed and pf-encode 33 passed / 0 failed. The decoders themselves still need real VAAPI/Vulkan playback to exercise.	2026-07-28 21:31:41 +02:00
enricobuehler	eb9c5be20d	refactor(encode): the VAAPI dmabuf path stops unwinding by hand ... `DmabufInner::open` builds four owned objects — a DRM device, a VAAPI device derived from it, a DRM-PRIME frames context, and a filter graph — and every one of its eight failure branches unwound them by hand. The same four-line block (`avfilter_graph_free` + three `av_buffer_unref`s) appeared eight times, once *inside a macro*, plus a ninth copy in `Drop`. Adding a step to that function meant remembering to extend the unwind at exactly the right depth; getting it wrong leaks a device per failed session (the persistent listener accumulates them) or frees one twice. All eight are gone. `AvBuffer` already owned the buffer refs; `AvFilterGraph` now does the same for the graph, so each handle is owned the moment it exists and an early `bail!` releases whatever was built so far. `open` lost ~40 lines of cleanup and gained none. Field order in `DmabufInner` is load-bearing and says so: graph, frames, VAAPI device, DRM device, then `enc` LAST. Fields drop in declaration order, and that sequence reproduces the old hand-written `Drop` exactly — including that it ran ahead of every field, so all four were released before ffmpeg-next dropped the encoder. Everything here holds its own reference, so refcounting makes any order sound; the ordering is pinned so a future reorder cannot quietly change what ships. One subtlety preserved deliberately: the buffersrc parameters take `drm_frames` BORROWED, not ref'd (`av_buffersrc_parameters_set` takes its own ref). That is now `drm_frames.as_ptr()` — same borrow, same single owned ref, no new leak. Verified on .21 (CachyOS, RTX 5070 Ti, FFmpeg 62): `cargo check -p pf-encode --all-targets` clean at exit 0, `cargo test -p pf-encode` 33 passed / 0 failed, and `cuda_hw_alloc_drop_cycles` still passes against real CUDA. vaapi.rs now contains zero `av_buffer_unref` and zero `avfilter_graph_free` calls, down from 40 and 8. The dmabuf path itself still needs AMD/Intel silicon to exercise end to end.	2026-07-28 21:31:41 +02:00
enricobuehler	7adc1db672	refactor(encode): AVBufferRef ownership moves into an RAII handle ... `CudaHw::new` and `VaapiHw::new` are the same shape — alloc a hwdevice, deref it to fill fields, init, alloc a frames ctx, deref, init — and both unwound by hand: `av_buffer_unref` on every failure branch (three in CUDA, two in VAAPI) plus a hand-written `Drop` repeating the pair. That shape has two failure modes and the compiler can see neither: add a branch and forget the cleanup (leak), or let two cleanup paths run (double-unref, an abort inside glibc). `libav::AvBuffer` owns the ref instead. It null-checks on the way in — the check each caller open-coded — and unrefs exactly once on drop, so an early `?` releases whatever was built so far and the failure branches carry no cleanup at all. Both hand-written `Drop` impls are gone, and `linux/mod.rs` goes from seven `av_buffer_unref` calls to zero. The one subtlety, called out at both structs: these two fields must stay declared frames-BEFORE-device. Fields drop in declaration order, and the code being replaced deliberately unref'd frames first (a frames ctx holds its own reference on its device). Refcounting makes either order sound, but a field reorder should not silently change what ships, so the ordering is load-bearing and commented as such. Also adds `cuda_hw_alloc_drop_cycles` — the RAII path had NO test coverage: the NVENC smoke tests take the CPU path and never construct a `CudaHw`, and the VAAPI twin's tests need AMD/Intel silicon. Looping construct/drop is what catches the double-unref (abort) and the leak (allocator growth) this refactor is about. Verified on Nobara (RTX 5070 Ti): `cargo check -p pf-encode --all-targets` clean at exit 0, `cargo test -p pf-encode` 33 passed / 0 failed, and `cuda_hw_alloc_drop_cycles` passes against a real CUDA device — eight construct/drop cycles, no abort. `VaapiHw` is compile-verified only; it is the identical shape but no AMD/Intel box was reachable to run its two ignored tests.	2026-07-28 21:31:41 +02:00
enricobuehler	5219107177	chore(unsafe): the workspace adopts the drivers' unsafe discipline ... `packaging/windows/drivers/*` has run `deny(unsafe_op_in_unsafe_fn)` + `deny(clippy::undocumented_unsafe_blocks)` for a while, with `forbid(unsafe_code)` on the modules that need no unsafe at all. The main workspace had no lint config whatsoever, so nothing stopped a clean crate from quietly growing an `unsafe`, and nothing distinguished the handful of genuinely-unsafe lines inside a 600-line `unsafe fn` from the safe ones surrounding them. Three things, all mechanical: * `#![forbid(unsafe_code)]` on the eight crates that already contain zero unsafe (`pf-driver-proto`, `pf-host-config`, `pf-paths`, the three clean clients, both tools). These were clean by accident, not by contract; now they are clean by contract. * `unsafe_op_in_unsafe_fn = "warn"` workspace-wide. `unsafe fn` states a contract the CALLER must uphold — it was never meant to switch off checking for the whole body. Measured fallout is 300 sites on Linux, and they are concentrated: six files carry all of them, while `punktfunk-core`, `pf-frame`, `pf-clipboard` and `pf-vdisplay` are already at zero. `warn` (not `deny`) so the build stays green while those six are worked down; it flips to `deny` once they are. This is also the Rust 2024 default, so it pays off the edition migration early. * `proc::current_uid()` replaces eight `unsafe { libc::getuid() }` blocks. Each site had copied out the same SAFETY note verbatim, which is the tell: `getuid()` is parameterless, always succeeds and touches no memory, so there is no contract for a caller to uphold and no reason for the unsafe to be visible eight times. One `unsafe` behind a safe wrapper, none at the call sites. Verified: `pf-vdisplay` builds clean on Linux (Nobara) at zero E0133; the macOS-buildable crates build clean locally. No behaviour change.	2026-07-28 21:31:41 +02:00
enricobuehlerandClaude Opus 5	37edb1cc1a	refactor(clients): both shells wake through the shared state machine ... The last of C0's duplication: GTK's `wake_and_connect` and the WinUI shell's ran their own copies of the same 90 s / 6 s / 1 s loop, and the Windows one's comment said it "mirrors the Apple HostWaker" — now it literally does, because both drive `WakeWait`. What is left in each shell is the part that genuinely differs: its dialog or screen, its advert drain, its re-key, and its route back into the trust gate. Behavioural review, since a sleeping host to test against wasn't available: - GTK polled every 500 ms and resent on a wall-clock timer; it now ticks once a second like every other implementation. Up to half a second slower to notice a host coming back, and exactly the reference cadence in exchange. - GTK took the FIRST matching advert in a drain and returned mid-loop; it now drains fully and takes the last, i.e. the freshest address. Same connect, fresher re-key. - Windows sent one packet before the loop AND one on its first pass; the machine owns the packets now, so that duplicate is gone. Resends still land at 6 s, 12 s, … and the budget still expires at 90 s. - Both keep their own cancel path, their own re-key, and their own error surface. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 21:01:47 +02:00
enricobuehlerandClaude Opus 5	983ff8e78d	fix(session/console): a profile must not advertise a cursor channel the presenter isn't drawing ... Found reviewing the P0 wiring. The console builds its window and input models ONCE, from the global defaults, and they live across every launch — but each launch now re-resolves the host's profile. So a profile that sets `mouse_mode: desktop` on a host, while the global stays `capture`, made the session advertise `CLIENT_CAP_CURSOR` ("this client draws the host cursor itself") to a presenter latched in capture mode, which draws no cursor: the host stops compositing the pointer and the stream has no visible cursor at all — the exact failure the capability's own doc comment warns about. The advertisement now follows the LATCHED mouse model, which is the one that is actually true of the presenter. Everything the host is told about the stream itself — mode, bitrate, codec, audio, pad — keeps honoring the binding, and the comment says which fields are latched and why, so the console's presentation-tier gap is documented rather than rediscovered. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 20:46:29 +02:00
enricobuehlerandClaude Opus 5	eab4829630	feat(client): the brain layer — one connect plan, one wake machine, one spawn ... C0 of design/client-architecture-split.md. Wake-then-connect exists three times today — GTK's `WakeConnect`/`wake_fallback`, the WinUI shell's `wake_and_connect` (whose comment says it "mirrors the Apple HostWaker"), and Apple's `HostWaker` itself — and the deep-link and profile work was about to make it five. `pf-client-core` already held the ingredients (wol, discovery, trust, library, session); what was missing was the layer that composes them, so every front-end composed them itself. `ConnectPlan` is a resolved intent: which host, which pin, which launch id, which profile, the effective settings, whether to wake. One constructor per door — a card click, a CLI verb, a URL — one type out. `ConnectPlan::resolve` is pure (stores in, plan out), which is what lets the URL router be tested without a config directory; `for_host` is the convenience that loads them. `plan_from_link` is where the deep-link security rules actually live, rather than in each shell: a contradicted fingerprint refuses and says which host it was about, an ambiguous name refuses instead of picking the first, a profile the catalog can't honor refuses BEFORE anything is dialled, and an unknown — or known-but-never-pinned — host becomes a confirmation sheet carrying the claimed name and expected pin, so the first connect is verified rather than blind TOFU. Preempting a live session stays with the caller: only the front-end knows one is running. `WakeWait` is Apple's `HostWaker` cadence as a pure step function — packet at 0 s and every 6 s, presence polled every second, 90 s budget, and a PARK (not an error) at the end, because "it didn't wake in 90 s" is usually "give it 10 more". As a step function each front-end drives it from its own loop and they still agree, and the whole cadence is testable without waiting 90 seconds. Session spawn, its argv and its stdout contract move here too, and the GTK shell now spawns through them — so "which flags does a stream get" and "what does ready mean" have one answer for the shells, the console and the coming CLI. `--profile` deliberately does NOT ride a plain card click: the session resolves the host's binding through the same helper, and passing it would be a second source of truth for one decision. Not yet adopted: the two shells' wake paths. That swap changes the most-used path in the product and the handoff wants it verified on glass with a genuinely sleeping host, which this session couldn't do — so the state machine lands, the duplication stays until it can be verified away. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 20:45:07 +02:00