111 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	dfebb9dfbb	chore(safety): hoist the unsafe lints into the workspace tables (WP2c hoist) ... undocumented_unsafe_blocks joins unsafe_op_in_unsafe_fn in [workspace.lints], and the ~100 scattered per-file #![deny(...)] attributes (85 files) are deleted — a new crate, or a new module in an old one, is now covered on creation rather than on remembering. The per-file form is how pf-vkhdr-layer, wdk-probe and half of pf-clipboard stayed uncovered. There are THREE workspaces, so the claim is made three times: the main Cargo.toml, packaging/windows/drivers (workspace table + [lints] workspace = true in all seven members), and packaging/windows/pf-vkhdr-layer (its [lints] table, previous commit). pf-update now opts into workspace lints; the two vendored member snapshots (cros-codecs, usbip-sim) stay out deliberately and now both say so. Newly-covered fallout was two link-sanity tests (pyrowave-sys, libvpl-sys) — proofs written. Stale prose that claimed the workspace held unsafe_op_in_unsafe_fn at "warn" (it has been deny) or pointed at the deleted attributes is corrected. nvenc_core.rs is carved OUT of the unsafe_op_in_unsafe_fn fence: its exemption rationale ("raw entry-table calls almost line for line") was false — the file makes zero FFI calls. Its unsafe surface is C-union writes whose soundness hangs on which codec arm is active, and its own 4:4:4 note records the shipped bug (hevcConfig bytes stamped onto an AV1 config) that per-operation blocks make visible. It now runs the strictest discipline in the crate: clippy::multiple_unsafe_ops_per_block at deny, one union access per block, each naming its codec guard. Verified here: cargo fmt clean in all three workspaces; native clippy -D warnings clean for everything that compiles on macOS (the three pre-existing mac-native failures — pf-client-core wol.rs, pf-encode dead-code/closure-call, probe mic_burst — reproduce on the clean tree). Linux/Windows legs ride the .25/.133 gate.	2026-08-11 23:26:28 +02:00
enricobuehler	bc70a58fb1	Merge main into chore/rust-safety-programme ... Two conflicts: the test-module import list in gamescope.rs (union — the branch's takeover-state tests and main's WSI opt-out tests both stay), and next_frame_timed_out in pf-capture, where the branch still carried the pre-#168 else-if chain — resolved to main's match-based refactor, which already embeds the same arm semantics plus the provisional-budget latch gate.	2026-08-11 22:34:38 +02:00
enricobuehler	9e28cd101c	fix(pf-vdisplay): the WSI opt-out never reached the games — the session script re-exports it ... A Nobara 44 field box on 0.27.0 got a working Game Mode takeover — right mode, right refresh, perf overlay in the stream — and then every game it launched played sound and took input over a BLACK PICTURE, with no error anywhere. #144 disabled the distro's `VkLayer_FROG_gamescope_wsi` with `--setenv=ENABLE_GAMESCOPE_WSI=0` on the transient unit, because that layer speaks the distro gamescope's `gamescope_swapchain` protocol and ours rejects its `swapchain_feedback`, killing the client. `gamescope-session-plus` then runs an unconditional `export ENABLE_GAMESCOPE_WSI=1` near the top of the script, before it launches anything — so the opt-out lived exactly as long as it took the script to start, and gamescope, Steam and every game got the layer back. The host logged that it had disabled it, which is what made this cost a field round-trip: the claim was true of the unit and false of everything in it. Nothing else looked wrong because the casualty is Vulkan clients specifically. Steam's Big Picture UI is not one, so the session came up looking perfectly healthy right up until a game started. Send `DISABLE_GAMESCOPE_WSI=1` as well. The Vulkan loader resolves an implicit layer's two manifest knobs in a fixed order (`loader_implicit_layer_is_enabled`): `enable_environment` must equal `"1"` to switch the layer on, and `disable_environment` is consulted last — "has priority over everything else" — where the mere PRESENCE of the variable, at any value, forces it off. The session script never mentions that one, so it is the only one that survives it. Both spellings now go out through one place, so the transient unit (`launch_session`) and the box's own session drop-in (`write_session_plus_dropin`) cannot drift apart — the same shape `SessionBind` already uses for the bind. `ENABLE_GAMESCOPE_WSI=0` stays alongside for a layer built without a `disable_environment`, and because it is what an operator reads the unit for.	2026-08-11 20:14:19 +02:00
enricobuehler	4b686f026a	Merge branch 'main' into worktree-vd-sweep-2 ... # Conflicts: # api/openapi.json	2026-08-11 10:57:35 +02:00
enricobuehler	dc4d8d6832	fix(pf-vdisplay): correct the regressions this sweep introduced ... An adversarial review of the sweep's own diff raised 39 claims; 23 survived independent verification. This commit fixes them. Several are cases where the sweep traded one bug for another. **The display budget was enforced in the wrong place.** The new Linux `max_displays` ceiling sat in `registry::acquire` — which runs again on every mid-stream rebuild. All three create-before-drop paths hold the old lease while acquiring the new display, and only the mode-switch path passes `supersedes`, so a session at the ceiling counted itself against the budget and could never recover from capture loss or a Game↔Desktop switch. At `max_displays = 1` that is a single streaming client. Moved to `admission::admit`, which is where Windows has always applied it and which is reached once per connect — so a rebuild cannot hit it. **"Cannot tell" was collapsed into "wrong mode".** `unanimous_output_size` returning `None` for two disagreeing gamescopes was compared with `== Some(target)`, so ambiguity took the destructive branch: a nested per-title gamescope — the normal Game Mode shape — made every connect restart the box's session and kill the running game. Now a three-state `BoxOutputSize`, where `Ambiguous` mirrors the live node instead of re-moding, and the post-restart wait asks "did what we asked for come up" rather than demanding unanimity. **Decide-then-act lost its mutual exclusion.** Re-scoping the `MANAGED_SESSION` guard fixed the shutdown restore but let two concurrent creates at the same mode both relaunch, the second stopping the unit the first was polling. A separate `MANAGED_LAUNCH` mutex restores the exclusion without putting launch progress back into the lock the restore samples. **Per-axis policy salvage was applied to a selector.** `preset` chooses the other axes, so salvaging it to the default silently re-pointed the whole document; it now refuses the document instead. A file whose every axis is unreadable also reported `configured() == Some(default)` — flipping Linux identity from Shared to PerClient — and now correctly reports unconfigured. **The six `#[serde(default)]` on `EffectivePolicy` are reverted**: they loosened `POST/PUT /display/presets` (an omitted axis defaulted where it used to 400), which nobody asked for. The catalog salvage they were added for now lives in a private Deserialize-only mirror type, so the read path stays lenient and the wire contract stays strict. Also: the Windows create path stored the OS-committed refresh in the field `acquire` uses as its resize discriminator, so a same-mode re-acquire looked like a hotplug — the requested and committed modes are now separate fields; `output_within`'s timeout arm detached both reader threads (now bounded by a drain grace, capped at 16 MiB, and logged honestly — a `systemd-run --pipe` unit escapes the process group and cannot be reached); `reenable_outputs_kscreen` abandoned the mode restore whenever kscreen-doctor hit its budget even though the enable may have landed (now tri-state); `write_atomic` replaced a symlinked portal config with a regular file, severing dotfiles management; several new budgets were too short for the helper they bound (`steam -shutdown` was being killed before it could deliver the request; `linger_enabled` read a 300 ms timeout as "not lingering" and hard-failed a correctly configured box); and a restore logged an operator-facing error for a `systemctl` call that had merely outlived its budget while systemd still owned the queued job. Verified: 107 tests on macOS, 202 on Linux (executed in a container, not merely type-checked), Linux and Windows clippy clean at `-D warnings`, fmt clean.	2026-08-11 10:06:16 +02:00
enricobuehler	6b33750edc	fix(pf-vdisplay): one non-UTF-8 byte in a portal config destroyed the whole file — in the module written to prevent exactly that ... `portal_config::ensure_key` folded EVERY read failure into an empty string (`read_to_string(path).unwrap_or_default()`). `upsert("", …)` then produced a file containing only our block, the one-time backup was skipped because `!existing.is_empty()` was false, and the write replaced the user's config — returning `Ok(true)`. So a single Latin-1 character in a comment in `~/.config/hypr/xdph.conf` or `~/.config/xdg-desktop-portal-wlr/config` destroyed the operator's entire portal configuration, with no backup and no warning. The module doc says flat-writing these files "destroyed [everything else] on first connect, silently and permanently" and that this module exists so it cannot happen; that one line re-opened the door. The same shape hit a transient EIO on an NFS or overlay config dir. Now: bytes are read with an explicit match, only `NotFound` may mean "empty", a non-UTF-8 config is refused by name rather than replaced, the backup is taken by BYTES, and the write is atomic (temp + `sync_all` + rename in the same directory, permissions carried over). Five new tests, all running on macOS — `a_non_utf8_config_is_refused_not_replaced` fails against the old code. Also in the wlr/Mutter family: * **Mutter's `Primary` rebuilt kept physicals from scratch** — scale forced to 1.0, transform to 0, disabled heads re-enabled — so a rotated, 2x-scaled or deliberately-disabled monitor came back wrong, while the code went to real trouble to preserve refresh. Each head now carries its pre-connect scale and transform, and x advances by the LOGICAL width. * Three availability probes read session env (`SWAYSOCK`, `XDG_CURRENT_DESKTOP`, `HYPRLAND_INSTANCE_SIGNATURE`) with no `ENV_LOCK` while `apply_session_env` `set_var`s the same keys from another thread — the glibc setenv/getenv race this crate's own lib.rs documents as UB. * `wlroots::create_output` ran a statement before its `OutputGuard` existed, so a raced `wait_new_output` orphaned the output permanently — hyprland takes the guard first. The before/after name diff also ran outside any lock, so two concurrent creates could adopt each other's output. Both now run under a create lock, with a stray sweep on the failure path. * `select_and_cast`'s timeout arm dropped the portal thread's `stop` flag un-set — the same leak Mutter was already fixed for. The guard is now built before the wait, in both copies. * The xdpw chooser file was written per session and never removed, permanently shadowing the config's fallback with the name of an already-unplugged output. Its lifetime is now the handshake, not the session — scoped deliberately, because tying removal to the keepalive would let one session delete another's selection hours later. * Hyprland's headless outputs are now named `PF-<pid>-<n>` and reconciled at startup, so a crashed host's leftovers are reclaimed while a live sibling host's outputs cannot be pulled out from under it. `set_monitor_rule` no longer discards hyprctl's rejection text and then hard-codes a GBM/dmabuf diagnosis it never verified. * Both wlr backends silently dropped the `topology` policy axis: `Primary`/`Exclusive` was accepted, echoed by the mgmt API, applied on three backends and a no-op on two. They now say so. Item 8.1: `swaymsg`, `hyprctl` and the portal `systemctl --user try-restart` calls are bounded through `proc` with named budgets.	2026-08-11 09:22:32 +02:00
enricobuehler	ef72d102b6	fix(pf-vdisplay): KWin's re-enable reported success when it matched no outputs at all, leaving a physical monitor dark ... * **`reenable_outputs` returned `true` when it matched NONE of the requested outputs.** Unresolvable outputs were `continue`d and the return was the apply verdict alone — but an empty `kde_output_configuration_v2` still gets an `applied` event. So a total no-op suppressed the `reenable_outputs_kscreen` backstop and the operator's physical monitor stayed dark. Now counts staged outputs and returns `ok && matched == outputs.len()`, and refuses to apply an empty configuration at all. * **The kscreen restore logged "restored the physical/bootstrap outputs" unconditionally**, with both call results discarded — including when `kscreen_ok` returned false on its 5 s budget, which is exactly the wedged state that fallback exists for. * **`Session::open` swallowed every failure reason** — connect error, barrier timeout, missing global — and three of four callers degraded to kscreen-doctor with zero log. This is the class that hid the KWin >= 6.7 registry regression: a shipped fallback firing silently on every machine. It now logs at warn with the reason and the caller's operation name. * `last_name` was seeded with a name kscreen-doctor can never resolve (KWin's address is `Virtual-punktfunk…`), so the intended default was guarded by an `is_none()` that could never hold and `apply_position` ran against no output. `our_uuid` was never reset per `create` and only assigned under `outcome.handled`, so a supersede positioned the *previous* output and never fell back. * `probe()`'s `roundtrip` was the only unbudgeted compositor wait in the crate — every sibling path is budgeted — and it is reached from an async mgmt handler. Now bounded at 3 s. The pre-`created` dispatch loops gained deadlines and now set `stop` on the timeout arm. * Every `wl_output` global was bound for the session's life with no `GlobalRemove` arm and no `release()`, on the virtual-output path too, which never reads them: unbounded growth on a hotplugging session. * `monitors::list` was the one KWin call site with no kscreen fallback at all, despite `list_monitors` failing on exactly the condition the other four fall back for. It has one now. * `CVT_H_GRANULARITY` and `MANAGED_PREFIX` existed as two literals under prose asserting they match; the second copy now imports the first. The wider facade extraction (item 9.1) is deliberately not in this commit, but its two prerequisites are — a comment at the restore seam records why they had to come first: a fallback arm that returns a value the helper never checked re-introduces the silent success, behind a seam whose selling point is one honest log per decline. Also corrects the `PhysicalMonitor` type doc, which claimed "logical geometry throughout" while `width`/`height` are the mode's PIXELS and `x`/`y` are logical, and adds the `logical_size()` helper that is the only correct way to compare an extent against a position.	2026-08-11 09:22:11 +02:00
enricobuehler	b2c03f1904	fix(pf-vdisplay): a managed launch blocked the shutdown restore that was meant to rescue it, and re-moding could flip the operator's own screen ... The gamescope subsystem — the crate's largest and fastest-churning area, and the one the 2026-07-28 sweep predates most of. * **`MANAGED_SESSION` was held across the ~90 s managed launch**, and the shutdown/idle restore blocks on that same lock — *after* it has already stopped our unit. So the display-manager restore never ran and the box was left with no session at all. `create_managed_session` now decides under the guard and acts outside it, re-acquiring only to store the result; `do_restore_tv_session` consumes the record in a short scope at the top. Same shape the SteamOS twin already used. * **The physical-display guard was bypassed whenever no gamescope node happened to be published.** `if physical_display_connected() { if let Some(node) = find_gamescope_node() { … } }` fell through to `set-environment SCREEN_WIDTH/HEIGHT/CUSTOM_REFRESH_RATES` + `restart` when the node was momentarily absent — gamescope restarting between titles, or built without PipeWire — flipping the operator's own screen to the client's resolution and bouncing a DM-driven login session. The guard now refuses instead of falling through, and the forced `SCREEN_*` values (which were never unset, so every later session on the box inherited them) are tracked and `unset-environment`ed on restore. * **`current_gamescope_output_size()` reported an arbitrary gamescope's `-W`/`-H`** — whichever `/proc` enumerated first — and four consumers treated it as this session's output size. It now answers only when every gamescope on the box agrees, and `None` ("cannot tell") when they differ. `heads.rs` no longer takes it at all: it reads the size off the DRM-backed argv it already selected. Its test previously passed `None`, which is why the hazard was invisible. Resource and honesty fixes: the ATTACH path armed the box's own session-unit bind drop-in and no in-process path ever removed it (now tracked and disarmed on both restore arms); `wait_for_node` never called `try_wait`, so a gamescope that died at `vkCreateDevice` was polled for the full 15 s and the error then blamed headless capture support; `do_restore_tv_session` deleted its crash-recovery state *before* the unbounded work that state records, so a grace-period expiry in that window left the DM down with nothing on disk to heal it; the SteamOS takeover's two failure arms never armed the TV restore though the session-plus twin does; the TV-session restore logged success with the `systemctl` status discarded; the `steam -shutdown` child was dropped un-reaped; and a managed session that took nothing over was never persisted, so a host crash orphaned the transient unit. Item 8.1: the unbounded `pw-dump`, `systemctl`, `loginctl` and `pkexec` calls in this subsystem now go through `proc::{status_within, output_within}` with per-call budgets. `pw-dump` is polled from three separate 45 s loops against the very daemon this file documents gamescope as head-blocking, and until now a hang there pinned the session's stream thread forever.	2026-08-11 09:22:09 +02:00
enricobuehler	db65980979	fix(pf-vdisplay): the ghost-monitor reap fed live devices to pnputil, and two unsafe fns had no unsafe in them ... Windows half of the sweep — the reap bug, a panic that poisons two locks, and a round of unsafe reduction. * **The ghost reap selected the wrong devices.** It filtered `Status -ne 'OK'`, a HEALTH field: that matches devices that are PRESENT but in Error/Degraded/Unknown, not the ABSENT ones the reap is for — and it handed them to `pnputil /remove-device`, contradicting its own documented contract. It runs from `add_monitor`'s mid-session slot-exhaustion recovery, so the blast radius is a live session. Now filters on `-not $_.Present`. * **`ensure_pinger` still used the panicking `thread::spawn` while holding two locks**, poisoning both — the un-fixed twin of a fix that already landed for `ensure_exclusive_watch`. Same shape applied. Unsafe reduction, continuing the program that made pf-win-display's CCD helpers safe fns: * `resolve_target_gdi` and `reisolate_after_swap` were `unsafe fn`s containing zero unsafe operations, and the three call-site SAFETY proofs described FFI they no longer perform. Both are now safe fns and those blocks are gone. * `VdisplayDriver::open`'s `# Safety` section named no caller obligation — the same empty shape an earlier phase already removed from `open_device`. * `(*detail).DevicePath.as_ptr()` derived a pointer from a `[u16; 1]` field and handed it to `CreateFileW`, which reads the whole flexible-array path beyond it. Now taken with `&raw const` from the full struct, so the pointer carries the provenance of the bytes actually read — the same correction already made for `MONITORINFOEXW` in ddc.rs. Comment fixes, all verified against the code: three intra-doc links to a type this crate does not have; a doc-comment run merged so that `shrink_action` — the gate that keeps a `Primary` group's physical panels lit — read as undocumented while its rationale sat on an unrelated polling helper; and the backend module header, which documented itself against a `sudovda` module that does not exist and a fallback the crate says was removed. Adds the first tests for `knobs.rs`, `instance.rs` and `driver.rs` — including `is_privileged_sid`, the security-relevant predicate that decides whether an existing single-instance name is another host or a squat, which had no coverage on any platform.	2026-08-11 08:49:06 +02:00
enricobuehler	a1ff0dde0c	fix(pf-vdisplay): the host promised HDR and cursor forwarding for gamescope sessions it did not start ... `gamescope_ours_and` answered "did WE spawn this gamescope?" by reading `PUNKTFUNK_GAMESCOPE_NODE`. Phase 2.3 deleted the code that published that key — routing.rs's own doc says "Nothing is written back to the two knobs" — but this consumer was never migrated, so the read now returns "not attaching" for every attach. Both consumers then answer for a session this host has no flags on. On a plain box with a foreign gamescope already running, `pick_gamescope_mode` resolves Attach at its fifth rung while the env key stays unset, and the probe half only inspects the resolved BINARY, which is our patched build: * `gamescope_composites_cursor()` returns true, so the host attaches no XFixes reader and blends nothing — while the stock gamescope actually running was never given `--pipewire-composite-cursor`, so the stream carries no pointer at all. * `gamescope_hdr_available()` returns true, so the Welcome fixes `bit_depth` at 10 and the session negotiates BT.2020/PQ over an 8-bit SDR composite. The Welcome cannot take that back. The same two failures hit the `capture_monitor` mirror route on any Bazzite or SteamOS box, where the running Game Mode gamescope is by definition not one this host spawned. The question is now asked of the resolved route rather than the environment, via a pure `session_is_a_foreign_gamescope` that runs — and is tested — on every platform. The residual gap is named in the doc rather than papered over: `create_managed_session`'s create-time degrade to a foreign attach is still invisible to a ladder re-run. Also in this commit: * Two unguarded session-env reads now take `ENV_LOCK` (`detect()`'s `XDG_CURRENT_DESKTOP` fallback and `effective_topology()`'s legacy pins). `apply_session_env` `set_var`s those same keys from another thread, which is the glibc setenv/getenv race this crate's own lib.rs documents as UB. * `mirror.rs`'s `names_ours_conclusively` was a `matches!` whose omitted default was the UNSAFE direction — a new backend would silently get its own virtual displays mirrored. Now exhaustive, so adding a `Compositor` is a compile error at the one site where the answer is a safety decision. * `MirrorDisplay` overrides `poolable_now() -> false`; its `create` always reports `External`, so the trait's `true` default was a pre-create claim contradicting the post-create fact. The trait doc now says plainly that the default is a default and not a fact. * The crate front-door doc listed 3 of 7 backends and quoted line counts half the size of the current crate; `routing.rs`'s summary was attached to the wrong item and described a published env channel that no longer exists; `available()` is no longer documented as cheap when it forks `gamescope --version` and does an unbudgeted Wayland roundtrip per call.	2026-08-11 08:48:49 +02:00
enricobuehler	9d58f4c170	fix(pf-vdisplay): one unreadable byte reverted the host to built-in display defaults, and one bad preset dropped the whole catalog ... The policy layer folded every failure into "unconfigured", then wrote that emptiness back. * **Any parse error reverted the WHOLE policy.** An unknown enum variant, a mistyped scalar, an EACCES or EIO — all became `Err(_) => None`, i.e. the host silently ran on built-in defaults with the operator's `display-settings.json` still sitting on disk. Parsing is now layered: strict first, then per-axis salvage so one unreadable axis costs only that axis, and only `NotFound` is quiet — EACCES/EIO warn loudly that the host is on defaults. `version` is read instead of being blindly rewritten to 1. * **One malformed entry dropped the entire custom-preset catalog**, and the next CRUD atomically renamed the empty vector over the file. Entries are parsed one at a time now; a lossy load is flagged and refuses to overwrite. * `sanitized()` clamped `max_displays` but never `KeepAlive::Duration.seconds`, so a PUT could pin a display for ~136 years — a deadline the reaper never reaches and a nonsense `expires_in_ms` in `/display/state`. Clamped to a day, in both `sanitized()` and `sanitize_preset_fields`, and sanitization now runs on LOAD as well as on write. * The two stores' temp files had fixed names and no write lock, so concurrent saves could interleave serialize -> rename -> in-memory update. Unique suffixes, a lock, and the in-memory update ordered after the rename. * `new_preset_id` never consulted the loaded entries for collisions. * **Manual layout could place an unpinned display exactly on top of a pinned one**: the fallback was the unconditional auto-row prefix sum, blind to where prior members were pinned. Unpinned members now pack clear of the pins. Layout keys are canonicalized and unusable ones dropped at write time rather than persisted-and-ignored. Adds 20 tests, all running on macOS: a 20k-round randomized property test asserting no unpinned member ever overlaps a sibling (verified to fail against the pre-fix `arrange_manual`), the salvage and quarantine paths, the clamps, and a field-count guard that fails the moment a 13th policy axis appears without being wired into the merge path. Note: `partial_json_fills_defaults` was renamed to `serde_defaults_fill_a_partial_document` with no assertion weakened — it pins the FILE contract (an old settings file must still load), which is not the mgmt PUT contract that sweep item 11.1 is about.	2026-08-11 08:48:47 +02:00
enricobuehler	61ff543acc	fix(pf-vdisplay): a new client could be handed a streaming client's display, and a blind /proc scan tore every backend down ... Five defects in the registry/identity half, plus the restructure that finally makes them testable. * **A new client could be assigned a LIVE client's identity slot.** `DisplayIdentityMap::resolve` LRU-evicted purely on its `seen` stamp, with no knowledge of which ids are streaming. On Windows that id keys the manager's slot map, so the newcomer took the plain-JOIN branch and inherited the other client's monitor, capture target and stop flag. `resolve` now takes the live set, never evicts a live id, and REFUSES rather than hand one over — degrading to the shared/auto identity. * **A transient `ActiveKind::None` invalidated every backend entry, including live streaming ones.** A `read_dir("/proc")` that happened to fail satisfied the change test and bumped the session epoch. A `None` observation is no longer evidence a desktop went away, and no longer overwrites the baseline (which would have bumped the epoch on the next poll anyway). * **The Linux pool had no display ceiling at all** — `max_displays` was enforced only on Windows, while the pool keys on the CLIENT-SUPPLIED mode, so each distinct requested resolution minted a new display. Now capped in `linux::acquire`, gated on `poolable_now` so a gamescope attach or managed session (which consumes no pool slot) is not refused. * **Two different definitions of "display group"** — `group_key` and a bare backend-name compare — and only one separated gamescope spawns. Unified as `pool::in_group`. The `position_for_new` collection also lacked the supersede exclusion the topology check 70 lines earlier had, so a mid-stream resize auto-rowed the replacement past its own dying predecessor, walking the display one width to the right on every mode switch. * **Lifecycle events were wrong in both directions**: `Created` fired on keep-alive reuse, and `Released` fired only from the mgmt endpoint — never from a lease drop, the linger reaper, `mark_failed`, `retire` or `invalidate_backend`. All six now emit. Also: `Release::Noop` no longer runs a full teardown (the one outcome the state machine defines as "do nothing"); a failed linger-reaper spawn logs and retries instead of consuming its `Once` and never tearing a kept display down again; group ids are a monotonic per-key counter instead of an index into the currently-live sorted set, so an unrelated group appearing no longer renumbers a display; and a corrupt `display-identity.json` is renamed to `.bad` with a warning rather than silently overwritten, which used to reset every client's stable id and its saved DPI. The pure half of the pool (`Entry`, `group_key`, `epoch_matches`, `take_expired`, `at_display_budget`, `position_for_new`, `assign_group_ids`, `assemble_displays`) is now a non-cfg'd `mod pool`, so the registry's decisions are exercised on every platform's CI instead of only on a Linux box. Crate test count 53 -> 94.	2026-08-11 08:48:15 +02:00
enricobuehler	dd9bbaf1c5	fix(pf-vdisplay): a helper that outran the pipe buffer had its output thrown away as a timeout ... `output_within` read stdout/stderr only after the child exited, and its doc justified that with "these helpers emit at most a few hundred KiB, well under any real pipe pressure". A pipe holds 64 KiB. Anything past that blocks the helper in `write()`, so it never exits, the budget kills it, and a successful query is reported to the caller as `TimedOut` with its answer discarded. The busiest caller is the one that trips it: `pw-dump` on a populated PipeWire graph clears 64 KiB routinely and is polled from the 45 s gamescope loops. Confirmed empirically — a child writing 1 MiB into an undrained pipe never exits. Both pipes are now drained on their own threads, concurrently with the wait. That makes the joins load-bearing, which exposed the second half: the Unix `tree::Guard` was an empty stub whose doc claimed `Child::kill` "already ends the only process there is". It never did for this crate's Linux helpers — `pkexec`, `systemd-run`, `systemctl --user` and the `sh -c` wrappers all fork — and a surviving grandchild holds the pipes' write ends, so a reader would wait for an EOF that never arrives. The child is now the leader of its own process group and the guard `killpg`s it, which is the Unix shape of the Job object the Windows half already used. Also gates `pf-frame`, `pf-gpu` and `pf-encode` to Windows: every use site of all three is `cfg(windows)`, and between them they dragged FFmpeg, ash and openh264 into the Linux build for nothing (sweep item 13.19).	2026-08-11 08:22:16 +02:00
enricobuehler	c817e4bec0	fix(pf-vdisplay): a CAPPED compositor refuses /proc/exe — NixOS+KDE still undetectable ... v0.27.0 resolved the nixpkgs wrapper decoration (`.kwin_wayland-w`) through `/proc/<pid>/exe`. On the box that fix was written for, the kernel refuses that link. Reading `/proc/<pid>/exe` is not gated on owning the process: `cap_ptrace_access_check` requires the reader's effective set to be a superset of the target's PERMITTED set. NixOS's own Plasma module ships `security.wrappers.kwin_wayland = { capabilities = "cap_sys_nice+ep"; }`, and our host must stay uncapped — a capability is precisely what makes it unidentifiable to KWin (#136). So the two traps compose: the name NEEDS `exe` because nixpkgs wrapped the binary, and `exe` is DENIED because NixOS capped it. `detect_active_session` went back to `ActiveKind::None`, and every connect died `no usable compositor` with `wayland="-"` — the identical signature to the bug #158 fixed, which is why a box worked around with a decoy process broke again when the decoy went away. `match_name` now falls through to `argv[0]` (`/proc/<pid>/cmdline`) when `exe` is unreadable. It reads correctly for the same reason `ps` does: make-wrapper's wrapper `exec -a "$0"`s the hidden binary, so `argv[0]` survives the decoration `comm` does not. It is consulted LAST and never overrides a readable `exe` — it is the process's own claim about itself, and a same-uid process can set it to anything; the worst a spoof achieves is aiming detection at a backend that then fails its own availability probe. MEASURED (Linux 6.x, same-uid reader, target holding cap_sys_nice), for a file capability and for the ambient form `security.wrappers` actually uses — identically: /proc/<pid> owner ✅ real uid (so the uid filter upstream was never the problem) comm ✅ readable (decorated + truncated, unusable alone) exe ❌ EACCES cmdline (argv[0]) ✅ readable End-to-end against a LIVE capped, `.kwin_wayland-wrapped` process, old resolver vs new, both extracted verbatim from their own sources: v0.27.0 answers `.kwin_wayland-w` (no match) in both capped scenarios and `kwin_wayland` uncapped; the fixed one answers `kwin_wayland` in all three. Also reached by the same rung: gamescope carries `cap_sys_nice` on a number of distros, so a wrapped-and-capped gamescope was equally invisible to the foreign-gamescope probe. Tests are fixture-driven (a temp dir with `comm`/`exe`/`cmdline`), for the reason #158 documented: a renamed `/bin/sleep` stand-in dies instantly on multi-call coreutils and reads exactly like the resolver being broken. 11 tests extracted verbatim and executed on Linux as a non-root user — 0 failures. `cargo fmt --check` and `scripts/xcheck.sh linux clippy` (`--all-targets`) clean. Refs #158, #136.	2026-08-10 23:23:59 +02:00
enricobuehler	61dfc3dadc	Merge remote-tracking branch 'origin/main' into worktree-nixos-wrapped-comm-detection	2026-08-10 20:26:23 +02:00
enricobuehler	002702bcec	fix(pf-vdisplay): NixOS sessions were undetectable — comm is the WRAPPER's name ... The session probe decided "is a desktop live?" by reading /proc/<pid>/comm for every process of our uid and exact-matching it against "kwin_wayland" / "gamescope" / "gnome-shell" / "Hyprland". comm is the kernel's name for the executed FILE, truncated to 15 bytes — not argv[0]. nixpkgs wraps essentially every graphical binary: wrapProgram moves the real ELF aside to `.<name>-wrapped` and installs a wrapper under the original name, which then `exec -a "$0"`s the hidden file. So on NixOS the kernel reports `.kwin_wayland-w` (15 bytes of `.kwin_wayland-wrapped`) while ps/pgrep -a show a perfectly ordinary `kwin_wayland`, because they read argv. Measured against a live kernel: `.kwin_wayland-w`, `.kwin_wayland_w` (KWin's own kwin_wayland_wrapper), `.gamescope-wrap`, all 15 bytes. Nothing downstream could recover from that one string comparison: - detect_active_session returned ActiveKind::None on a *running* KDE desktop; - wayland_display is only resolved for a detected kind, so the connect log reported wayland="-" even though WAYLAND_DISPLAY was correct; - pick_compositor's Auto arm returns the DETECTED backend, so a live, fully working KWin sitting in available() was never chosen — every connect died "no usable compositor"; - and PUNKTFUNK_COMPOSITOR could not rescue it: pinned_at_a_dead_session consults the same probe, turning the miss into a hard error instead. No environment variable reached the comparison — the XDG_CURRENT_DESKTOP fallback in detect() is only on the pinned path. Capture itself was never at fault: a decoy process merely NAMED kwin_wayland satisfied the probe and the stream came up against the real KWin. Resolve the name through /proc/<pid>/exe (the full, untruncated file name) and strip the nixpkgs decoration. Both the leading `.` and the trailing `-wrapped` are required before anything is stripped, so KWin's own real `kwin_wayland_wrapper` binary keeps its name rather than collapsing into `kwin_wayland` and handing the probe the parent's PID. The comm fast path is kept for every ordinary distro — one read, no readlink, and no name that matched before can stop matching. Also applied to foreign_gamescope_running, which had the same defect: nixpkgs wraps gamescope too, so the attach-vs-spawn ladder saw no foreign session. Tests are fixture-driven rather than spawn-driven on purpose: a stand-in has to be a real ELF that tolerates being renamed, and /bin/sleep is not one — modern coreutils is a multi-call binary that dispatches on the executable's own name, so a copy called `.kwin_wayland-wrapped` exits instantly and /proc/<pid>/exe is gone before it can be read. That failure looks exactly like this resolver being broken; it cost one debugging round here and the same trap is already recorded in punktfunk-host's /proc matcher.	2026-08-10 18:38:14 +02:00
enricobuehler	657e82cd29	fix(gamescope): a takeover's mask no longer bars the box's own way back into Game Mode ... A managed takeover runtime-masks the box's `gamescope-session-plus@*` unit so its session supervisor cannot restart it underneath our Steam. The only unmask ran in `do_restore_tv_session`, on client disconnect — so for the whole stream the mask stayed on, and it silently barred the door the user was most likely to walk through next. `mask_unit`'s own doc said the mask "blocks nothing" on images whose sddm helper execs the session script directly. That is half right, and the half it gets wrong is this bug: on f43 bazzite-deck the script's last act is systemctl --user --wait start gamescope-session-plus@${CLIENT}.service (verified on the .41 VM). What the mask fails to stop is the RELOGIN LOOP — sddm keeps trying regardless, which is why stopping the DM is the real defense. What it very much does stop is the unit, and with it every entry into game mode, including the user's own deliberate "Return to Gaming Mode" after a mid-stream switch to the desktop. Steam then sits on its "Switch to Desktop…" modal forever. `--runtime` lives in tmpfs, so a reboot cleared it — hence "it works right after a reboot" — and a plain `unmask` does not (measured: still `masked-runtime`). So the mask's sound lifetime is shorter than the takeover's: it ends the moment the box stops being ours. The mid-stream session watcher already detects exactly that, so it now lifts the mask on a confirmed switch to a desktop session — ahead of the `compositor_for_kind` arm, because a switch we cannot follow still has to unbar the return. `Gaming` and `None` deliberately do not lift: a takeover's own managed session reads as `Gaming` and one momentarily down between relaunches reads as `None`, and lifting on either would void the mask for the whole stream, in exactly the SDDM-storm window it exists for. Fixes a second, worse leak on the way: `honor_session_select_switch` consumed `STOPPED_AUTOLOGIN` — the only record of what carries a mask — without unmasking, so under a DM-stop takeover the disconnect restore found an empty list and lifted nothing. That mask outlived not just the stream but the boot. It is also what let that path's own step 1 work at all, since the DM's autologin heads back into game mode through precisely this unit. The lift is idempotent, keeps the restart list intact (the disconnect restore still owes those units a `start`), and every hand-back path now routes through it. Verified on Linux: `switch_ends_mask_window` decision table, plus an ignored end-to-end test driving real `systemctl --user` (masked → survives Gaming/None → lifted by a desktop switch → restart list intact → idempotent). Proven non-vacuous by planting "Gaming also lifts", which fails it on the during-stream assert.	2026-08-10 17:16:29 +02:00
enricobuehler	6695300b67	fix(pf-vdisplay): the gamescope bind took a user namespace that broke Xwayland, and left a drop-in that bricked the next boot ... Field-diagnosed on Nobara (fc44, canary g13179011), where Game Mode became unstartable and the box was handed to plasma. #144's bind works — the patched build genuinely reaches a session script that hardcodes /usr/bin/gamescope — but a mount namespace in a systemd USER unit is also a USER namespace, and only this uid is mapped in it. Measured on the box: on disk / in a unit without the bind : drwxrwxrwt 2 0 0 /tmp/.X11-unix in a unit WITH the bind : drwxrwxrwt 2 65534 65534 /tmp/.X11-unix uid_map inside : 1000 1000 1 wlroots checks that /tmp/.X11-unix is "owned by root or us", sees nobody, and refuses: wlserver: [xwayland/sockets.c:100] /tmp/.X11-unix not owned by root or us wlserver: [xwayland/sockets.c:217] No display available in the first 33 -> SIGSEGV in run_pipewire Three ~10 s failures then feed chimeraos' short-session tracker, session-plus stops even trying, and steamos-session-select rewrites the user's session to plasma. So the symptom an operator reports is "thrown onto KDE and I can't get back" — two removes from the cause. Two further bugs found while fixing it, each worse than the one reported: * THE BIND WAS ARMED EVERYWHERE. The condition was only `gamescope_bin() != /usr/bin/gamescope`, so every box with punktfunk-gamescope installed took a namespace it has no use for — Bazzite, SteamOS-likes, the Deck. The blast radius was every gamescope box, not just the hardcoded-path ones the mechanism exists for. Now the host READS the session script and arms only where it never mentions GAMESCOPE_BIN and names /usr/bin/gamescope outright; everything else is bit-for-bit pre-#144, no namespace at all. An unreadable script does not arm. * THE DROP-IN OUTLIVED ITS SOURCES. It was written to ~/.config/systemd/user/ on the TEMPLATE, so it also applied to the box's OWN autologin unit at every boot — while both paths it binds live in tmpfs. After a reboot the drop-in survives and its sources do not, and BindReadOnlyPaths= with a missing source fails the unit outright. THAT is why the field symptom survived a reboot. It now lives in $XDG_RUNTIME_DIR (dies with the login session), removal covers both the runtime and the legacy $HOME path, and restore_takeover_on_startup does that removal unconditionally at host start — which is the upgrade path for every box already running canary g13179011. Without it, updating the host would not un-brick them. * A bind was armed even when gamescope_bin() fell back to the bare name "gamescope". The wrapper execs `gamescope` through PATH inside the unit — onto the path we just bound the wrapper over. Fork bomb. Refused ahead of even the operator's force. Where the bind IS armed it now carries its own compensation: a user-owned $XDG_RUNTIME_DIR/punktfunk-x11 bound read-WRITE over /tmp/.X11-unix (Xwayland creates the socket there), so the ownership check sees "us". Skipped when that directory is already ours or absent — neither is the hazard. Stale sockets are pruned by connect-test so a SIGKILLed session cannot walk the 33 display slots away. And rather than trust that reasoning, the host now ASKS THE BOX before arming: it runs the field reproduction with the real property set — `systemd-run --user --wait --collect --property=<the same args> -- stat -c %u /tmp/.X11-unix` — and arms only if the answer is our uid. Anything else (65534, a rejected property, no user manager, a blown 10 s budget) means no bind, and the session runs stock gamescope: no HDR, no in-node cursor, but it STARTS. A runtime backstop disarms and relaunches if a session launched with the bind armed produces no node in its window, latching one-way per process. The XFixes-cursor concern that argued against relocating the socket does not hold: the only host-side X client is spawned under `plan.gamescope_cursor`, which is `gamescope && !gamescope_composites_cursor()`, and our shipped +pfhdr4 build is patch level 4 — so on the very route where the bind arms, that reader is never constructed.	2026-08-10 00:39:18 +02:00
enricobuehler	fb309e0262	fix(pf-vdisplay): the takeover blamed polkit for a group it never named, and offered two remedies that cannot work ... Field triage on Nobara, 2026-08-09. Every connect degraded to ATTACH — which on that box mirrors a game-mode session the host never configured, and looked like a black screen on every connect. The host said: the packaged pf-dm-helper polkit action is missing or was denied (reinstall the punktfunk package, or install the display-manager polkit rule from the docs) Every clause of that was wrong. The action was installed, `allow_any`, and its exec.path annotation matched the installed helper; pkexec authorized it and RAN the helper. The helper refused, and said exactly why: pf-dm-helper: user 'nobara-user' is not in the 'punktfunk' group — refusing. Grant it with: sudo usermod -aG punktfunk nobara-user (then re-login) That text never reached the log, because `dm_helper` ran the helper with `.status()` — which discards stderr and collapses the exit code to a bool. The one thing that would have ended the investigation in seconds was thrown away at the call site, and the caller then guessed. Neither suggested remedy adds anyone to a group, so a reader who followed both stayed broken and learned the docs were useless. It fails soft, with no error and no failed unit, so nobody finds it on purpose. Now: `.output()`, and four failure modes that stay distinguishable because they need different fixes — helper not installed, pkexec could not run it, polkit denied it (pkexec's own 126/127), and the helper ran and refused, whose stderr rides through VERBATIM rather than being re-described. Null stdin too, so a pkexec that decides to prompt gets EOF instead of parking a stream thread on a tty read. The same gate gates the `linger` verb, so on a sessionless host an unjoined user fails there first — carrying the reason there as well, or the misdiagnosis just moves one message earlier. A new startup preflight says it before a stream is being built rather than during one, gated so it cannot nag a box that would never attempt a takeover: not root, a display-manager alias exists, a managed session launcher exists, a packaged helper exists, and the user is not in the group. It reads membership from the user database rather than this process's groups, deliberately: that is what the helper reads (it runs as root and resolves the caller from the database), so `usermod -aG` satisfies the DM gate immediately and the warning stops. Using `getgroups()` would keep warning on a box where the takeover already works. Packaging said the group was for "the virtual Steam Deck pad (usbip)" — so anyone without a Deck pad correctly skipped it and landed here by following instructions properly. All three scriptlets now lead with Game Mode, name both grants, and record that creating the group is necessary and NOT sufficient. Docs get the same treatment: the group is an admonition above the DM-flavor list in gamescope.md, a black-screen entry in troubleshooting.md that tells the reader to read the quoted reason FIRST, and the per-distro install pages no longer frame it as pad-only.	2026-08-09 23:15:34 +02:00
enricobuehler	46390739d8	fix(pf-vdisplay): the box's OWN session unit needs the gamescope bind too ... `launch_session` spawns a transient unit and can hand `systemd-run` the `BindReadOnlyPaths` directly, but a box that owns an autologin `gamescope-session-plus@<client>.service` is RESTARTED IN PLACE instead — no `systemd-run`, so that path kept running Nobara's hardcoded `/usr/bin/gamescope` and the previous commit fixed only half the problem. Found on the box: after a reboot the host took the `ensure_box_gamescope_mode` path (the autologin unit was live) rather than the managed one. Deliver the same two fixes as a drop-in on that unit — the bind, and the WSI opt-out when the box's layer was built for a different gamescope — plus `PF_HZ`/`PF_HDR_ARGS`, which the wrapper reads and would otherwise default to 60 Hz. `daemon-reload` before the restart or systemd runs the old unit. Best-effort: a failure to write it must not block a restart that would otherwise work, and it is a no-op on a box already resolving to `/usr/bin/gamescope`. ⚠ REMOVED on restore, deliberately. Leaving it would put the patched build — and our HDR and cursor flags — under the user's ORDINARY game mode, which is exactly what `packaging/gamescope/README.md`'s "sits BESIDE the distro package" rule exists to prevent. The bind is ours only for as long as we are driving the session. `ensure_box_gamescope_mode` grows an `hdr` param to build those args; both call sites already had it in scope (`self.hdr`, and `create_managed_session`'s parameter). Gate: `scripts/xcheck.sh linux clippy` clean (0 warning/error lines), `cargo fmt` clean.	2026-08-09 20:28:00 +02:00
enricobuehler	3500e95660	fix(pf-vdisplay): make Nobara's session run the patched gamescope, and stop the WSI layer killing every client ... Two independent reasons a Nobara box could never stream from a gamescope session, both found on glass (VM 123, Nobara 44, RTX 5070 Ti). **1. The session ran a stock gamescope, so the host refused it.** Nobara's `gamescope-session-plus` builds its command as GAMESCOPECMD="/usr/bin/gamescope \ and reads `GAMESCOPE_BIN` NOWHERE. All three of our spawn levers miss at once: the env var is ignored, and an absolute path cannot be redirected by a PATH shim. So the session ran stock gamescope, the capability probe rejected it, and every session died with "pipeline build failed (out of retries) … it ignored GAMESCOPE_BIN / the PATH shim". `~/.gamescope-cmd.log` — which the script writes with the exact command it ran — settles that in one line, and is the first thing to read on any such report. Fixed by binding our wrapper over `/usr/bin/gamescope` inside the transient unit's mount namespace (`BindReadOnlyPaths`). Deliberately a bind, not a replacement: punktfunk-gamescope ships under its own name precisely so it sits BESIDE the distro package, and the bind is scoped to the session — nothing outside it sees the redirect and nothing is written to `/usr`. Skipped when the resolved binary already IS `/usr/bin/gamescope`. **2. With the patched gamescope finally running, every Vulkan client died — black screen.** The box's `VkLayer_FROG_gamescope_wsi` ships with the DISTRO's gamescope and speaks its `gamescope_swapchain` protocol. Ours disagrees, so the compositor rejects the client's `swapchain_feedback` ("message too short") and drops it. Steam never paints; there is no other symptom, which is what makes it expensive to find. Measured with `vkcube` under each build, layer on: ours 3.16.25-17 ON -> 1 rejected client ours 3.16.25-17 OFF -> 0 OLD pin 3.16.25-4 ON -> 1 rejected client stock 3.16.23.2 ON -> 0 ⭐ The upstream protocol XML is BYTE-IDENTICAL between the distro's commit (5cdb5b0) and our pin — same interface version, same `uuuuuus` signature — so this is the distro patching gamescope, not a version bump. Hence the gate is "do the upstream triples differ", not a floor, and an unreadable version on either side leaves the layer alone rather than degrading a box that works (Bazzite/SteamOS, where it has always been fine). ⚠⚠ The old pin fails identically, so REVERTING the pin bump fixes nothing here — this is pre-existing, not a regression from 5fb8dce4. Verified against the UNPATCHED distro script, reproducing exactly what this code emits: the session's own log reports `punktfunk-gamescope version 3.16.25-17-ga87390d+pfhdr4`, with 0 swapchain_feedback errors, 0 client-communication errors and 0 aborts. Gate: `scripts/xcheck.sh linux clippy` clean (0 warning/error lines), `cargo fmt` clean. Non-vacuity re-verified per the xcheck note — a planted type error in the new function produced 3 errors, and removing it went back to Finished. Still open, deliberately NOT addressed here: a 10-bit HDR stream aborts gamescope in `destroy_buffer` (upstream `pipewire.cpp:88`), which is a separate defect.	2026-08-09 20:15:52 +02:00
enricobuehler	e8a4f54c07	fix(pf-vdisplay): the capability-hint test asserted the environment, not the code ... `silent_without_capabilities` called the real `capability_denial_hint()` and asserted it returns "", on the strength of a doc comment that read "The test process has no capabilities." That is true on a dev box and false in CI, where the runner container is root with a full permitted set. main went red on 0f79587d with: left: " — NOTE: this process carries capabilities (CapPrm=0x000001ffffffffff) …" right: "" Nothing was wrong: the hint fired correctly, on a process that really did hold every capability. The test was reading the ambient environment and calling it a property of the code. `permitted_caps_from_status` had already been split out for exactly this reason — "so that shape is testable without a capability-carrying process to point at" — but only the PARSE half. The message half still went to /proc/self/status. This finishes the split: `capability_denial_hint_for(Option<u64>)` holds the formatting and takes the mask, `capability_denial_hint()` reads /proc and delegates. Both keep their callers, so neither is dead code. Also adds `names_the_mask_and_the_repair_when_capped`. Without it the silent case passes just as well against a function that returns "" unconditionally — which is the failure mode this repo has been bitten by before, and the reason every decode fix carries a counterfactual. No behaviour change: the three error paths call the same function and get the same string. ⚠ Verification is CI. `kwin.rs` is `#[cfg(target_os = "linux")]`, so it does not compile on the macOS host this was written from; `cargo fmt --all --check` is clean and a Linux container check was attempted but the stock rust image has no cmake for audiopus_sys, so it never reached the test. ci.yml going green on main is the proof — and unlike the case it replaces, this test now fails or passes for reasons that have nothing to do with the machine running it. Does not touch the v0.26.0 tag: ci.yml runs on `push: branches: [main]` and `pull_request` only, and no tag leg runs cargo test.	2026-08-09 10:39:41 +02:00
enricobuehler	42ee6c5628	fix(packaging): the host's CAP_SYS_NICE made it invisible to KWin, killing every KDE session ... 0.26.0-1 setcap'd `cap_sys_nice=ep` on /usr/bin/punktfunk-host so the encoder could open an elevated global-priority Vulkan queue. On every KDE box that ended desktop streaming outright: KWin virtual output failed: KWin does not expose zkde_screencast_unstable_v1 to this client reported from CachyOS on NVIDIA and on AMD, surviving a clean reinstall of host and client, and worked around only by KWIN_WAYLAND_NO_PERMISSION_CHECKS=1. The two cannot coexist. KWin hands out its restricted protocols — zkde_screencast_unstable_v1, which mints our virtual output, and org_kde_kwin_fake_input, which injects input — only to a client it can IDENTIFY, by resolving that client's /proc/<pid>/exe and matching it against an installed .desktop's Exec=. The kernel refuses that readlink to any reader whose effective set is not a superset of the target's PERMITTED set (cap_ptrace_access_check), and KWin holds no capabilities. So the instant the binary carries one, KWin's executablePath() is empty, nothing matches, and the global is never advertised — presenting exactly as a missing or mis-installed .desktop file. Measured on CachyOS (kernel 7.1.6), same-uid reader, cap_sys_nice=ep on the target: no capability .............................. readlink /proc/<pid>/exe OK capability ................................. EPERM capability + prctl(PR_SET_DUMPABLE, 1) ..... EPERM <- dumpable is NOT the gate capability dropped + PR_SET_DUMPABLE(1) .... OK <- only an uncapped process works The third row also rules out the reflex fix of moving the grant to systemd AmbientCapabilities=, which lands CAP_SYS_NICE in the very same permitted set. Nothing short of not holding the capability restores identification, so the host does not get one. The cost is pacing only. pf-zerocopy's device create already walks REALTIME -> HIGH -> default when a priority class is refused, and pf-frame's thread nice is a documented best-effort no-op without the capability — so this is 0.25.0's behaviour exactly, which is the behaviour that worked. * packaging/arch/punktfunk-host.install: grant -> revoke. post_upgrade strips the capability from boxes that already ran 0.26.0-1's scriptlet. A pacman upgrade writes a new inode and file capabilities do not survive that, so this is belt-and-braces for reinstall/downgrade paths. * pf-vdisplay kwin.rs: all three "KWin does not expose zkde_screencast" errors now read /proc/self/status and, if this process holds ANY capability, name it with its CapPrm mask and the `setcap -r` that repairs it. The failure stays impossible to diagnose from the Wayland side otherwise, and it is not unique to our own packaging — a hand-rolled setcap does it too. Verified on 192.168.1.21 (CachyOS): the capability/dumpable matrix above; cargo check and cargo clippy --all-targets -- -D warnings clean for pf-vdisplay; both new unit tests pass; and the hint itself exercised end-to-end, silent uncapped and firing with CapPrm=0x0000000000800000 under cap_sys_nice=ep. The shipped punktfunk-host-0.26.0-1-x86_64.pkg.tar.zst was unpacked to confirm its .INSTALL carries the setcap on both post_install and post_upgrade. Ships as 0.26.0-2 — packaging plus one crate, no version bump.	2026-08-09 09:37:30 +02:00
enricobuehler	f23e0df64c	fix(host): a compositor pin silently vetoed dedicated game sessions ... `PUNKTFUNK_COMPOSITOR` is documented as "which backend to drive", but it also quietly discarded `game_session=dedicated`: `resolve_compositor` gated the dedicated route on `!overridden` and logged nothing either way. A host whose pin was a forgotten validation leftover therefore went on displaying "dedicated" in the console while every launch landed in the desktop instead — for 30 days on the box that surfaced this, the only evidence being the ABSENCE of a log line. The pin still wins, since it is the operator's explicit hand-set knob, but it now says so and names itself. Two further holes the same triage turned up: - The pin put its backend into `available()` unconditionally AND skipped `apply_session_env`'s `XDG_CURRENT_DESKTOP` scrub, so `pick_compositor` could never return `None` — the one place `try_recover_session()` is called from. A pinned host whose gnome-shell had segfaulted therefore spent every connect on 8 doomed `RemoteDesktop.CreateSession: ServiceUnknown` retries while the operator's configured `PUNKTFUNK_RECOVER_SESSION_CMD` sat unreachable behind that arm. Liveness is now read on both paths, and a pin aimed at a dead session takes the recovery exit with an error naming the pin. `needs_live_session()` exempts gamescope, which stands its own session up — pinning it on a headless box stays supported. - A mode switch accepted before the pipeline existed was served the long way round: build at the now-stale mode, then immediately rebuild at the new one in the stream loop. That burns a display create, capture attach and encoder open on every such connect, and because the rebuild is deliberately create-before-drop it stands up two Mutter `RecordVirtual` monitors ~400 ms apart — which segfaults mutter 50.4 inside `meta_monitor_manager_rebuild` and takes down the whole desktop session, along with the game just launched into it (so the GAME looks like what crashed). Bring-up now adopts the newest queued mode and builds once, carrying over the H2/H3 correction ack that the replaced rebuild would have sent. Verified on a real Linux host (192.168.1.21, x86_64): `cargo clippy --workspace --all-targets --locked -- -D warnings`, `cargo fmt --all --check` and the punktfunk-host + pf-vdisplay test suites all clean. The gate was proved non-vacuous against a planted `compile_error!`.	2026-08-08 17:37:02 +02:00
enricobuehler	2a1c968a0e	Merge pull request 'A gamescope session told every game its display was 60 Hz — and Fedora had no way to install the build that knows better' (#120) from worktree-gamescope-virtual-display into main ... Reviewed-on: #120	2026-08-08 13:41:30 +00:00
enricobuehler	102f550bba	feat(host): use the new gamescope capabilities, and say so when the mode is lost ... Pass --custom-refresh-rates (patch level 3+) and --pipewire-composite-external-overlay (level 4+) on both spawn paths, with the same probe-then-pass shape the HDR and cursor flags already use. A stock gamescope has neither flag and gets neither, which is exactly today's behaviour. New knob PUNKTFUNK_GAMESCOPE_REFRESH_RATES=60,90,120 widens the set a session offers in Steam's in-session display settings. The rate the session actually runs at is always included, so it can only add options; junk entries are skipped rather than failing the host, because the worst a typo can cost is the extra option the operator wanted. And the part that would have turned a week of field triage into one log line: warn_if_mode_lost(). --nested-refresh is the ONLY refresh a headless gamescope has, and it reaches a gamescope-session-plus solely through the GAMESCOPE_BIN wrapper, which the session script is free to lose — a sessions.d file sourced with `set -a` can reassign GAMESCOPE_BIN, and one that sets GAMESCOPECMD outright skips the whole builder. When that happens the stream still runs, still looks right, and the client's own fps counter still reads the negotiated rate (the encode loop repeats the held frame), while the game underneath is capped to 60. Nothing anywhere said so. It warns rather than refusing, deliberately: verify_managed_spawn_flags refuses because its retry resolves a different plan, but a relaunch here would hand the session the same environment and lose the mode the same way, so refusing would only loop. Fails open on the same rule as the flag check — nothing to compare against says nothing. Also corrects the comment above the launch env, which claimed CUSTOM_REFRESH_RATES "generates the mode the session ADVERTISES … what makes games see the real refresh". It never did: no upstream gamescope has --custom-refresh-rates, so gamescope_has_option gated it off and the variable was inert. That belief is why the real lever went unexamined. configuration.md gains the new knob and a warning on PUNKTFUNK_MAX_FPS, which also lowers the refresh the session REPORTS on gamescope — the docs said it does not cap the stream, which is true of the wire and not of what games are told. Linux-verified on Ubuntu: cargo check --all-targets, clippy -D warnings, 133 tests (2 new), cargo fmt --check.	2026-08-08 15:35:58 +02:00
enricobuehler	fba22c6c64	fix(host/vdisplay): the host no longer vetoes its own wake-from-sleep recovery — control handles close on retire ... The control-device sharing contract was 'bare HANDLE copies, never closed for the process lifetime': retired handles were deliberately kept alive because the pinger/linger threads and the capture delivery closures held raw copies whose soundness depended on no-close. The cost surfaced in the 2026-08-08 field log: after a wake left the driver hostless, every adapter reload came back REFUSED (Generic failure) — and an open control handle is exactly what vetoes the PnP disable (and can wedge the pnputil restart) the recovery leans on. reset-pf-vdisplay.ps1 stops the whole host service precisely to get those handles closed; the in-process recovery could not, because the process could never close them. Ownership is now Arc all the way out: ensure_device/device_handle/ control_device_handle hand out Arc<OwnedHandle> clones, every consumer holds its clone across its IOCTLs (the capture closures each own one — Arc<OwnedHandle> is Send+Sync, ending the isize smuggling), and retiring drops only the manager's reference, so the handle CLOSES when the last in-flight user drains. DeviceSlot::retired is gone. The recovery path now releases the manager's reference at the first absent sighting — the 3 s ABSENT_SETTLE doubles as the drain window — and again before a not-ready-deadline reload, so the PnP cycle finally runs against a device the host is no longer holding open. The driver attaches no meaning to the control file closing (host-gone is the IOCTL-liveness watchdog, EvtFileClose deliberately unhooked), so the close has no driver-side side effects. Lock order note: RECOVERY → device is now taken (the release hooks); the forbidden inverse still never occurs — VdisplayDriver::open never reloads.	2026-08-08 13:37:05 +02:00
enricobuehler	f242b2d2fc	fix(host/vdisplay): a refused adapter reload now says WHY, and never targets a phantom devnode ... Field log 2026-08-08 (0.25.0, wake from sleep): every session died on 'the adapter devnode could not be reloaded (Generic failure)' — the WMI catch-all — because the REFUSED branch reported only the Disable exception and threw away everything that would identify the failure mode: why the pnputil /restart-device fallback ALSO failed (its exit code — 3010 'needs a reboot' is its own diagnosis), what state the devnode was in, and whether the right devnode was even targeted. That last one is a real trap, not just missing telemetry: Get-PnpDevice lists not-present PHANTOM devnodes (upgrade/reinstall leftovers), and Select-Object -First 1 could hand every recovery attempt a phantom — whose disable and restart both fail exactly like the field log — while a live node sat unexamined. The selector now prefers present nodes (OK before problem-state), and a phantom-only state gets a truthful refusal: no reload can revive a devnode record whose device is gone; only reinstalling re-creates it. The REFUSED line now carries devnode counts, the chosen node's PnP Status + ConfigManager problem code, and the restart exit code, so the next field log decides between handle-veto, phantom, and problem-state instead of reading 'Generic failure'. Decode pinned by test.	2026-08-08 13:22:05 +02:00
enricobuehler	975fef2048	fix(host/vdisplay): the ghost-monitor reap can no longer fail in silence ... The reap that keeps departed virtual monitors from exhausting the IddCx monitor-slot budget launched pnputil by BARE NAME — under the LocalSystem service's PATH that can miss System32, SilentlyContinue swallowed the miss, and the Rust side logged only when the count was positive: a reap that removed nothing and a box with no ghosts were byte-identical (silence). Ghosts then ratcheted up with every sleep cycle until IOCTL_ADD wedged at 0x80070490 and every session black-screened — and the wedge self-heal shipped in 0.25.0 retried an ADD behind a reap that could never remove anything, which is exactly a persistent post-sleep "no connection" surviving the b6acbd09 probe fix. Same family and same cure as the adapter-reload path one function down: resolve pnputil via $env:SystemRoot (a SYSTEM process must not trust PATH anyway — a planted pnputil.exe would run elevated), pre-seed $LASTEXITCODE to failure before every launch, and report found AND removed unconditionally so "no ghosts" and "removed nothing" are finally distinguishable in a field log. The report parse is split out and pinned by tests like classify_reload_output.	2026-08-08 12:19:48 +02:00
enricobuehler	d2085879da	Merge main: plugin art rides THROUGH the H-2 confinement, not around it ... PR #58 hardened the art proxy in the same three files this branch rewrote, and the two changes pull in opposite directions: #58 narrowed what the host will read from disk, while WP1.2 widened what counts as a local art path so an extracted scanner's covers can be served at all. Resolved so the widening goes through the gate rather than beside it. Kept from #58, unchanged: art_path_is_confined (UNC refusal, canonicalize-or- refuse, config-dir exclusion, roots check), the image-extension whitelist, sniff_image_type, validate_art_paths as write-time validation, the AuthLane privileged-field check on every entry in a reconcile payload, and the launch redaction in GET /library. Three reconciliations: * `local_art_bytes` converts a `file://` value to a path BEFORE calling art_path_is_servable, so the confinement check and the read see the same path. Ordering is the point: percent-decoding happens before canonicalization, so a `%2e%2e` escape cannot hide from the traversal check. Pinned by a test. * `art_roots()` gains $HOME on POSIX. This is the one that would have bitten silently: the list was empty on non-Windows, which was correct while is_local_art_path was Windows-shaped (Playnite is Windows-only, so nothing on a POSIX host was ever classified as local art and the confinement had nothing to confine). Once WP1.2 classifies POSIX paths as local, an empty root list is not "secure by default" — it serves NO plugin art on Linux, which is every cover the lutris and steam plugins emit. $HOME is the exact analogue of the Windows users base #58 already ships, and covers Steam's librarycache and grid overrides, Lutris's coverart/banners (both copies), Heroic's caches and all the Flatpak variants. It is not the load-bearing control: a value still needs an image extension, must canonicalize to a real regular file inside a root and outside the config dir, and must CONTAIN image bytes. * The two tests that both wanted to mutate PUNKTFUNK_LIBRARY_ART_ROOTS became one. Cargo runs tests as parallel threads of a single process, so two tests setting the same env var race. The `file://` and confinement assertions moved into #58's existing confined test; what remains of the WP1.2 test is the pure classification/rewrite half, which touches neither env nor filesystem. Also: `steam_ui` was missing from the list of host-resolved launch kinds in privileged_field's doc comment and in the 403 a plugin sees. Prose only — the check is a denylist (prep, launch.kind = "command"), so steam_ui was never actually refused — but a plugin author reading that error would have concluded otherwise. Gates on .21: punktfunk-host 433 passed / 0 failed (including #58's H-2 tests and the new file:// ones), full workspace tests clean, workspace clippy -D warnings clean, cargo fmt --all --check clean, OpenAPI drift test green.	2026-08-05 19:59:11 +02:00
enricobuehler	8103958169	fix(security): the plugin lane stops being a way in ... Acts on the 2026-08-05 host security review. 36 of its 38 findings; the two exceptions are recorded below and in the review doc. The review's headline is that `plugin_may_access` was the one authorization gate in the system that was allow-by-default — a hand-maintained denylist of route prefixes, where every sibling gate is deny-by-default. Its own doc comment names the two capabilities it exists to withhold, and both were reachable one route over, because ~1450 commits of new routes were added and the list was never one of the things anyone remembered to update. So the gate is now an allowlist, and a test walks the live route table and fails the build for any route that has not been deliberately classified for both non-admin lanes. That test is the actual fix: it is what stops the next route from arriving pre-authorized. Route reachability and field authority turned out to be different questions. A provider plugin has to be able to reconcile its own library entries — that is what a scanner plugin IS — but `prep` and a `command` launch inside that payload are handed to `/bin/sh -c` as the host user, and every execution site documents them as operator-typed. Requests now carry the lane that authorized them, and those two fields are refused to everyone but the operator's own token. The art proxy read any absolute path off disk in the host process, which on Windows is LocalSystem, from a path the plugin lane could write and then read back — so it yielded `mgmt-token`, which is full admin. It now serves only real images (extension AND magic bytes, so a renamed secret fails), only from inside an allowed root, only after canonicalization, and never over UNC; and a path it would refuse to serve can no longer be persisted in the first place. On Windows, the config-dir hardening was skipped exactly when it was needed — it ran only in the branch that CREATES host.env, so the case it was written for (a local user pre-created the directory and planted one) was the one case it never ran in. It is now unconditional and first, an existing host.env is re-owned, and the inheritable OWNER RIGHTS ACE that kept an attacker's files theirs after the directory was re-owned is gone. The identity and token readers were hardening the directory only on the path that GENERATED a new secret, so a planted cert/key or token was adopted verbatim and permanently; they harden before the first read now. `ensure_admin_only_source` is implemented. The 2026-07-05 audit recorded it as FIXED and it was in no commit in this repository's history — the local EoP it described was live, and it is the payload half of the config-dir chain above. Also: the three input planes are bounded and lossy like the mic plane on the same loop already was; Android's library client no longer accepts any publicly-trusted certificate for the pinned host; the usbip vhci nodes get their own group instead of riding on `input`, which every packaging scriptlet tells users to join; a registry URL can no longer inject a TOML table into bunfig.toml; the pairing cooldown is charged before the arming state is read, so armed/disarmed is no longer a free oracle; and the whole Low tier, of which the two worth naming are a clipboard MIME NUL that panicked the host on one control message, and an unauthenticated global logout that let any LAN peer sign the operator out on a loop. NOT fixed, deliberately: H-3 (plugin UIs framed allow-same-origin). Dropping allow-same-origin does not work: the document's origin goes opaque, its subresource requests are then cross-site, the SameSite=Lax session cookie is not sent, and every plugin asset 302s to /login. The "open in new tab" link is the same escalation with no iframe at all, so the sandbox attribute is not where this gets fixed either. It needs a second listener — a distinct origin that is still the same site — which changes the console's deploy model and wants on-glass validation. The mechanism and the dead end are written down at the iframe. H-6 registry authentication, whose other half lives in unom/infra. The in-repo halves are done: workflow_dispatch inputs no longer interpolate into run: blocks (one of them in the step holding UPDATE_MANIFEST_KEY), and the syft installer is pinned to its tag instead of main. Digest pinning is left until the registry is authenticated, because a tag — content-keyed or not — can simply be overwritten while anonymous pushes are accepted. M-5 is half done: the oracle is closed, but binding the arming window needs the console to learn the fingerprint first, which is a knock-then-bind flow rather than an edit. Verified: cargo fmt --all --check clean; cargo check --all-targets green on Linux and on Windows (confirmed non-vacuous — a planted type error in windows/install.rs fails the build); scripts/xcheck.sh windows check green; cargo test -p punktfunk-host --bins 416 passed, the single failure being gamestream::stream::tests::sender_delivers_batches, the known qemu-environmental UDP-loopback flake that fails identically on clean main in the same container; cargo test -p pf-clipboard 13 passed; web console typechecks.	2026-08-05 17:12:12 +02:00
enricobuehler	3d4a659959	feat(host,sdk,kit): store claims, launcher entries, and plugin sources on the wire ... M2 of design/library-scanner-plugins-implementation-plan.md. Everything a library scanner plugin needs is now expressible over the API; all additive. WP2.1/2.2 — store claims (D2). library.json gains a v2 shape ({entries, claims}) that loads the v1 bare array unchanged and is written on the first mutation. PUT /library/provider/{p}?store=<s> claims a store for a provider: its entries then surface with deterministic <store>:<external_id> ids and the store's own badge instead of opaque custom:<id> ones. That identity is the whole point — entry ids, GameStream FNV app ids, client art caches and Moonlight pins all survive a title moving from an in-host scanner to a plugin. One provider per store (409 otherwise); DELETE releases; an empty reconcile does NOT (a store can legitimately have zero titles). While a claim is held, all_games() skips the matching built-in scanner, so the two never double-list during the bridge. WP2.3 — DetectHint gains steam_appid and env_marker, the two store-derived signals the host used to read for itself. Without them a steam plugin's lease tracking would drop from reaper-exact to dir-prefix, and Heroic-under-Proton would lose the only signal that works. Malformed markers are dropped, not honoured — this feeds a path that can end processes. WP2.4/2.5 — role: game|launcher on the entry shapes (serde-default, skipped when default), and a steam_ui launch kind valued bigpicture|desktop that opens the Steam client itself. Validated inbound as well as at launch. WP2.6 — GET/PUT /library/scanners generalizes to SOURCES: built-in scanners minus claimed ones, plus claimed stores, plus any provider with entries. The same library-scanners.json disabled-set backs all of them and the ids match by construction, so a user's disabled state carries over verbatim through the whole migration. A disabled plugin source has its entries filtered at read time, exactly like a disabled scanner. WP2.7/2.8 — plugin registration gains a category field (the console keeps library plugins out of the nav); index entries gain categories and per-platform detect probes, evaluated existence-only into CatalogEntry.detected so the host never re-grows per-store knowledge. Index SCHEMA stays 1 — additive. WP2.9 — OpenAPI + SDK regenerated on Linux; kit wire widened (LaunchSpec.kind is now a plain string documented against the host's vocabulary — closes G3), and ProviderClient.reconcile takes an optional store and returns the host's echoed entries so a caller can detect a pre-M2 host silently ignoring the claim. Also fixes a bug the S3 spike turned up: is_steam_launch gated on a steam:// URI, so a steam_ui launcher entry would have skipped BOTH gamescope's --steam mode and the B1 single-instance free — on a box autologged into game mode, the nested second Steam would see the first and exit, crashing the spawn. It now tests the first token. Gates on .21: workspace tests green (punktfunk-host 425 passed), workspace clippy -D warnings clean, cargo fmt --all --check clean, OpenAPI drift test green. plugin-kit: tsc clean, 20 tests pass.	2026-08-05 09:39:31 +02:00
enricobuehler	b31495bea5	fix(host): a leftover Sunshine folder is not a conflict, and a crashed host gives the screen back ... Three things a field report (Discord, upgrade from 0.1x) turned up, all on the Windows host. 1. "It thinks I have Sunshine/Apollo running." It didn't — they were uninstalled. Both uninstallers leave their config/log directory in Program Files behind, and `detect.rs` counted a bare directory, or a service registered at ANY start type (including `disabled`), as a live conflict. The installer's own probe was narrowed to "service start type <= 2" after exactly this cried wolf on a `winget install`, and the tray dropped its always-on warning for the same reason in 3e782852 — the runtime probe never got the same treatment, so the one surface the user actually looks at kept shouting. `Evidence::is_active` now draws the line (running, or set to start on its own) and only active detections reach the startup warning, the `detect-conflicts` exit code, and `/local/summary`. Dormant findings still print in the full report, under a heading that says they need no action — that report is where "why does it think I have Apollo?" gets answered. 2. The console's conflicts card hardcoded "Another game-streaming server is **running** on this machine" regardless of what was found, so a dormant leftover was announced as a running server. It now says "active", and each entry names the observation — `Sunshine (running)`, `Apollo (starts automatically)`. 3. "The exclusive screen never times out going back to re-enabling the display." `isolate_displays_ccd` deactivates the operator's panels and hands the pre-isolate topology to the caller, which restores it at teardown — but that snapshot is PROCESS MEMORY, and Windows deliberately never saves the isolated topology to the CCD database. So a host that crashed, was killed, or was stopped mid-session left the desk dark with nothing in the product to undo it. There was one startup recovery leg already, but only for the EXPERIMENTAL `pnp_disable_monitors` axis, which is off by default — the default Exclusive path had none. `isolate_journal` now marks what an isolate is about to switch off (before the apply, so dying mid-apply is covered), clears the mark on restore, and force-EXTENDs at host startup if a mark survived. EXTEND rather than replaying the saved blob: the blob pins the virtual display's target id, which dies with the crashed host, so a replay would mostly fail BAD_CONFIGURATION into the very same backstop `restore_displays_ccd` already keeps — and EXTEND stays correct across a reboot, where saved ids would be stale.	2026-08-04 22:34:33 +02:00
enricobuehlerandClaude Opus 5	b6acbd096e	fix(host/vdisplay): waking the PC stops failing the first session ... A woken Windows host refused every connection with "pf-vdisplay driver interface not found", on a box where the driver was installed and running. Resuming re-enters D0 and re-registers the IddCx control interface while the rest of the resume storm is still going. A client reconnecting a second after wake lands inside that gap. `ensure_available` probed exactly ONCE, so it read the gap as a dead driver and answered a device that was seconds from ready by disabling and re-enabling it — then gave the interface 4 s to come back, which a contended post-resume PnP does not meet. The session failed, and the log blamed a missing install. The recovery also could not tell whether it had recovered anything. It ran the whole cycle under `SilentlyContinue` and reported `(Get-PnpDevice).Status` — the DEVICE's status, not the cycle's outcome — so a disable that was REFUSED left the adapter untouched, started, and reading `OK`. That is the reporter's `cycled the adapter device … status=OK` line: a recovery that never happened, announcing success. And a refusal is the expected case here, not the exotic one: reset-pf-vdisplay.ps1 stops the host service first precisely because the host holds the driver's control device open, a step an in-process cycle structurally cannot take. - Distinguish a devnode MID-TRANSITION (interface registered, not started yet, or the open refused) from one genuinely ABSENT. Wait the first out; only the second earns a reload. `Probe` carries the counts. - Report what the reload DID, not what the device looks like afterwards: every failable step is `-ErrorAction Stop` in a `try`, and `pnputil /restart-device` is the fallback for the in-use device that `Disable-PnpDevice` refuses. Failure paths re-enable, so a half-cycle can never strand the adapter DISABLED. - Give the interface 15 s to arrive after a reload, not 4 — under a 30 s hard ceiling so a permanently wedged devnode still fails predictably. - Serialize recovery: N sessions racing in after a wake perform ONE reload, not N interleaved ones. The lock is taken only where no manager lock is held, so the order stays one-way. - Retire the manager's cached control handle when a reload runs, instead of letting the next session discover it via a failed IOCTL. - Surface the real reason. `ensure_available` returns `Result`, so the log names how long it waited, whether a reload ran, and how many interface instances were seen in what state — the detail that would have identified this from the field report's log alone. `VdisplayDriver::open` now shares the wait (brief, no reload) instead of carrying a second, drifted copy of it — that path is also reached by `hw_cursor_capable` mid-handshake, where a reload would be the wrong trade for one capability bool. Windows-gated, so verified with scripts/xcheck.sh (check + clippy -D warnings, --all-targets) and cargo fmt; on-glass wake test still owed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 13:12:54 +02:00
enricobuehlerandClaude Opus 5	362595b20f	fix(vdisplay/kwin): the streamed output declares it mirrors nothing, so a stored replicationSource can't clone a panel into the stream ... KWin stores output configuration per *setup* — the exact set of connected outputs, matched by EDID/connector — in `kwinoutputconfig.json`, and `replicationSource` is one of the fields it saves and restores (`OutputConfigurationStore::storeConfig` / `setupToConfig`). Our virtual output carries a STABLE name on purpose, so once any setup has an entry making `Virtual-punktfunk` a mirror of a physical head, KWin re-applies it to OUR output on every session that reproduces that same monitor set — and only that set, which is why the failure looks environment-dependent: a field report has the stream cloning the panel whenever exactly one monitor is live, and behaving normally the moment the others come back (a different setup key, a different stored entry). A mirroring output is not a desktop. KWin's `applyMirroring` overrides its scale and render offset to the source's, so the stream carries the physical screen's viewport at the physical screen's size instead of the mode the client negotiated. The protocol says the rest out loud on `priority`: "an output may not be in the output order if it's disabled or mirroring another screen" — so the primary assertion this module works so hard to verify silently stops meaning anything too. Nothing we sent ever contradicted the stored value. The topology config enabled our output, took priority 1 and disabled the others, but never stated the one property that decides whether the thing is its own screen. Now it does: `set_replication_source(ours, "")` rides along in the config we already build (free, idempotent — an empty source is exactly what KWin resolves to "mirrors nothing"), gated on management v13 where the request appeared, since wayland-rs does not range-check requests and an out-of-range opcode would kill the connection. `extend`/`auto` issue no topology calls by design — the streamed output is meant to join the desk without rearranging it — but a mirror is not an arrangement, it is a broken source under every topology. So they get `clear_replication_source`, which enumerates and applies ONLY when our output really is mirroring. The device's `replication_source` event is now read, so the state is visible: a mirrored streamed output names its source in a warn instead of leaving "the stream just shows my monitor" as something only the reporter can see. Verified on 192.168.1.25 (Ubuntu, cargo 1.96): `cargo test -p pf-vdisplay` 128 pass (7 in `kwin_output_mgmt`), `cargo clippy -p pf-vdisplay --all-targets --locked -D warnings` clean, `scripts/xcheck.sh linux` clean, fmt clean. NOT yet on-glass — no KDE box here reproduces a stored mirror; the reporter's setup is the real test. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 11:55:34 +02:00
enricobuehlerandClaude Fable 5	2a6bf3c421	fix(vdisplay/gamescope): the takeover stops a live session's DM on every flavor — the mask never stopped SDDM's relogin ... The managed takeover masked gamescope-session-plus@*.service and trusted the mask to hold SDDM's Relogin=true loop at bay. On images whose sddm session helper execs the session script directly (/etc/sddm/wayland-session gamescope-session-plus steam — f43 bazzite-deck), the relogin never touches the unit: SDDM relogged in ~3x/s for the whole stream, each attempt a full bash --login session start failing against the managed instance. Live on the .41 VM (2026-07-31): 328 forks/s, load 6+, 1481 logind sessions in 8 minutes, the journal flooded past its own rotation — and a 5070 Ti that "could not hold 240fps". A DM that drove a LIVE gaming session is now stopped for the stream's duration on every flavor (the fragile-flavor machinery — lingering guard, pkexec dm-helper, restore via reset-failed+restart, crash-persisted state — already existed and is reused as-is; a pure dm_plan() derives the decision and is unit-tested). The flavors now differ only in the degraded mode when the stop is impossible: SDDM falls back to mask-only (the storm tax, but Steam stays protected — never attach), fragile DMs still fail the takeover into the attach degrade. The mask stays as belt-and-braces for the window before the stop and for images that do route the relogin through the unit. Verified: scripts/xcheck.sh linux clippy (-D warnings, --all-targets) clean; pf-vdisplay suite 125/125 on Ubuntu 26.04. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 17:59:00 +02:00
enricobuehlerandClaude Opus 5	553676282a	feat(windows): the brand reads Punktfunk on every device Windows shows ... Device Manager, the firewall list and the monitor name all said "punktfunk". The brand is Punktfunk. Renamed: the [Strings] blocks of all four driver INFs (device descriptions, install disks, provider, manufacturer), the `description` on every SwDeviceProfile the host creates, pf-mouse's HID manufacturer + product strings, pf-vdisplay's IddCx endpoint friendly + manufacturer names, the EDID 0xFC display-name descriptor — so Windows now shows `Generic Monitor (Punktfunk)` — and the netsh firewall rule names. The EDID edit is a single byte (0x70 -> 0x50) and needs no hand-patched checksum: Edid::generate_with already recomputes both block checksums after patching the serial. Deliberately left lowercase, because these are IDENTITIES rather than display names and renaming them would orphan installed state: * the SwDeviceCreate enumerator `w!("punktfunk")` — it IS the SWD\PUNKTFUNK\... path every pad instance id is built from * pf-paths' `join("punktfunk")` — C:\ProgramData\punktfunk * the CN=punktfunk-driver cert subject, which purge_driver_certs and both driver build scripts match by string * install.rs' `lo.contains("punktfunk virtual display")` probes, whose haystack is to_ascii_lowercase()d, so they already match the capitalised name Nothing is orphaned by the renames that DID happen either: netsh rule names, Get-NetFirewallRule -DisplayName and PowerShell's -match are all case-insensitive, so the firewall delete paths and reset-pf-vdisplay.ps1's -AdapterName / -GhostMatch defaults still reap what every release up to 0.22.1 created. Cosmetic, with two consequences worth knowing: it takes a driver rebuild + re-sign to appear at all, and an existing devnode keeps its cached FriendlyName until it is recreated. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 12:30:46 +02:00
enricobuehlerandClaude Fable 5	1f59498c5c	fix(host/linux): a no-channel session composites the metadata cursor — Mutter never embeds on a virtual stream ... The capture-latched client (console.rs latched_mouse) never advertises CLIENT_CAP_CURSOR, so its session resolved cursor_blend=false and asked Mutter to EMBED the pointer. On a Mutter virtual stream that is a fiction: since Mutter 48 (7ff5334a, hw-cursor inhibition removed) the software cursor overlay is suppressed stage-globally whenever any physical head realizes a HW cursor — dmabuf-recorded frames blit the view without a pointer, and cursor-only motion schedules no re-record either (mutter#4939). Probed on-glass on Mutter 50.3: embedded + relative motion = frozen frame counter; SPA_META_Cursor positions kept flowing in the same setup. So the no-channel session now takes the path that was verified end to end: cursor-as-metadata + the host composites, permanently — the same arm a channel session lands in after its capture-model flip. Embedded remains only the can't-blend fallback (libav VAAPI/NVENC, software). - session_plan::cursor_blend_for grows the no-channel arm (codec + depth in, the same CUDA-payload prediction handshake makes); gamescope excluded so patch-2+ keeps its native-NV12 zero-copy shape - the encode loop's composite refresh + one-shot breadcrumbs now cover the no-channel session; the park schedule keeps retrying while its composite is starved (relative-only clients cannot park themselves) - the compositor retarget re-applies set_hw_cursor — the rebuilt display used to come up EMBEDDED even for channel sessions - the GameStream virtual source takes the same rule (it never has a channel); its stream_body blend flag mirrors the request - punktfunk-probe grows --cursor-nochannel (the latched-capture client, headless); cursor-probe grows --dump (PPM frames + a content-change counter, the pixel evidence the embedded A/B lacked) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 00:35:25 +02:00
enricobuehlerandClaude Fable 5	ddd0e5cc5d	fix(vdisplay/kwin): primary is a PRIORITY, and the log now reads the answer back ... A field report (CachyOS, KWin 6.7.3, Plasma): topology primary streams the new virtual display but the desktop stays on the physical — while the host logs primary_taken=true on every apply. Both halves were real: * KWin's handler for kde_output_configuration_v2.set_primary_output is literally '// intentionally ignored' (verified in the 6.7.3 source). The output order is driven by per-output set_priority (management >= 3; we bind up to v22 and never called it). Exclusive only ever LOOKED right because disabling every other output leaves KWin nothing else to promote. Now: ours gets priority 1 and every other enabled output is renumbered uniquely behind it, exactly what kscreen-doctor does — the reporter proved that path applies and sticks on their box. set_primary_output is still sent for pre-v3 compositors. * primary_taken echoed the REQUEST. The log now waits one sync barrier for KWin's post-apply priority events and reports primary_verified from the read-back — a request the compositor ignores can never ship a green log again; the mismatch is a WARN naming the symptom. First-slot-wins refinement the working priorities made necessary: a SAME-NAMED output is this slot's own predecessor mid-supersede (mode switches create the replacement before dropping the old), not a sibling whose primary must be respected — deferring to it handed primary to whatever KWin promoted when the predecessor vanished a moment later. On-glass (nested KWin 6.7.3): fresh create, high-refresh custom-mode create, and the mode-switch supersede all read back verified=true; exclusive still disables + restores the other output in-process. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 17:59:24 +02:00
enricobuehlerandClaude Opus 5	664c26cb2b	fix(vdisplay): a pin with no heads to mirror must not refuse the session ... The streamed-screen pin is host-wide and persisted, but the session it applies to is not. A box that boots between a desktop (heads to mirror) and a nested or headless Game Mode (none) carried the pin into a session where `monitors::resolve` could only fail — and since `vdisplay::open` is the one place every session opens a display, that failure was a host refusing to stream at all rather than one streaming the normal way. Pinning a monitor in Desktop mode bricked Game Mode. A compositor reporting NO heads whatsoever now degrades to the virtual-display path with the reason logged. Narrow on purpose: a pin that misses among heads that DO exist stays the hard error §5.2 makes it — showing someone a different screen than they asked for is the failure worth refusing over, and "there are no screens here" is not that. An enumeration ERROR also stays on the mirror path, so the session fails with the real reason instead of quietly ignoring the operator. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:23:32 +02:00
enricobuehlerandClaude Opus 5	028462ef6d	feat(vdisplay/gamescope): a Game Mode session drives a real head — list it, and mirror it ... The per-monitor capture feature shipped with gamescope written off as "nested, therefore no physical heads of its own", and `monitors::list` returned a hard-coded empty Vec for it. That premise holds for a gamescope nested in another compositor and for the headless ones this crate spawns — but not for the deployment people actually stream from: a Bazzite/SteamOS Game Mode session is the DRM master and drives the TV directly. On such a box the console's picker was permanently empty, on exactly the hardware the feature was asked for. `gamescope/heads.rs` answers the narrow question instead — is this gamescope on the DRM backend, and which connector is it lighting? — from `/proc/<pid>/cmdline` (the backend flag and `--prefer-output`; gamescope publishes no protocol that reports its own output) and `/sys/class/drm` (what is plugged in, plus each connector's EDID for the picker label and the panel's preferred timing). The nested/headless shapes still answer an empty list, which is what they always meant. Mirroring needs no new capture code: gamescope composites its one head into a PipeWire node it already publishes, so the mirror arm is an ATTACH to that node — the gaming session is not stopped, relaunched or re-moded, which is the whole difference between "stream the panel I am looking at" and the MANAGED takeover that deliberately blanks it. Refresh comes from the EDID and never from `--nested-refresh`: that flag is the rate gamescope composites the nested game at, and reading it as the connector's rate would let a session launched at 60 cap a 120 Hz TV for the whole stream. Verified against home-bazzite-1's live EDID: manufacturer `1e6d` -> GSM, name descriptor -> "LG TV SSCR2", preferred timing 594 MHz / 4400x2250 -> 3840x2160@60. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:23:32 +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	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	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
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	33a31427ae	fix(vdisplay): locks held across seconds-long work, an AB/BA inversion, and a panic that poisons the manager ... Phase 7's contained half. 7.1's writer split and 7.3's reservation are NOT here — see the plan; both need more than a local edit. **Lock-order inversion, gamescope.** `create_managed_session_steamos` held MANAGED_SESSION while taking STEAMOS_TOOK_OVER (and `persist_takeover`'s locks), while `do_restore_tv_session` takes STEAMOS_TOOK_OVER first and MANAGED_SESSION second — AB/BA between a connect and the restore worker, which genuinely run concurrently (`vd.create` runs off the registry lock; the worker is its own thread). The connect path now drops its guard before the pair and re-acquires after `poll_managed_node`, the shape `create_managed_session` already used. And `takeover_live` held all four statics at once — in a `||` chain every `.lock()` temporary lives to the end of the statement — for four reads; scoped bindings drop each guard before the next, taking it out of the ordering graph entirely. **`observe_session_instance` decided and acted under one lock.** It held LAST_INSTANCE across `invalidate_backend` (which drops keep-alive displays through the registry lock) and a `systemctl` shell-out on a 10 s budget, from three call sites including a per-second watcher. It decides under the lock and acts outside now; the baseline is advanced inside it, so a concurrent observer cannot run the action twice. **`admit` held the live-session table across the budget checks** — `manager::snapshot()` blocks on the manager `state` lock, which is itself held across DDC round trips and three 3 s activation ladders. Every connect, disconnect and mgmt read queued behind one slow display operation. The guard is scoped to `decide` alone. **GameStream never registered**, so its display was invisible to both Windows budgets (they gate on `!live.is_empty()`) and a native connect could be admitted past capacity the box had already spent. It registers now, anonymously, for the session's lifetime. **`ensure_exclusive_watch` panicked on a failed thread spawn** while holding BOTH `exclusive_watch` and (via its caller) `state` — poisoning the two locks the whole manager runs on, so every later acquire and mgmt read would panic on `.lock().unwrap()`. It logs and degrades instead: no re-assert watchdog is a degradation, a wedged manager is not. Also fixes two things only a Windows build shows, both mine: Phase 2.3 left `gamescope_route` unused there (every reader is Linux-gated), which `-D warnings` in Windows CI would have rejected — I had only run the host clippy on Linux. And Phase 5.4's helper-safening reaches a FOURTH crate, pf-inject, which xcheck does not lint. Verified on .173: `cargo clippy -p punktfunk-host -p pf-vdisplay --all-targets` clean across the whole tree; local fmt, both xcheck targets and 53 tests green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 19:46:15 +02:00
enricobuehlerandClaude Opus 5	093c66cb1a	fix(vdisplay/windows): a failed resize left a phantom monitor, and a refresh-only one silently didn't happen ... Three defects in the mid-stream resize path. **A failed re-arrival put a DEAD monitor back in the slot.** `re_add` REMOVEs the old driver monitor before it ADDs the new one, so its only fallible step past that point means the old monitor is gone — yet the caller answered an `Err` by re-inserting the `Monitor` struct it had handed in, complete with a dead `key`, a departed `target_id` and a stale `gdi_name`. Every later `acquire` then joined a monitor that did not exist. It now rolls back: on ADD failure it re-ADDs at the OLD mode, so the session keeps streaming what it already had. The outcome is a three-way `ReAdd` enum because the distinction matters and a `Result` cannot carry it — `Arrived` stores the new monitor, `RolledBack` stores the RECOVERED one (a re-arrival mints a fresh `target_id`, so the struct the caller handed in is stale either way), and `Lost` means both ADDs failed and the slot must be left EMPTY so the next acquire creates a monitor rather than joining a phantom. **A refresh-only change reported success at the old refresh.** `wait_mode_advertised` compared resolution only, so a same-WxH new-Hz request answered "already advertised": the fast path skipped the `IOCTL_UPDATE_MODES` that would have taught the driver the new rate, `set_active_mode` fell back to the best advertised rate <= requested, and the resize returned Ok. It matches `dmDisplayFrequency` now, so an unadvertised refresh routes to UPDATE_MODES / the re-arrival instead. And `mon.mode = mode` recorded what was ASKED FOR. `set_active_mode` deliberately falls back to a lower advertised refresh rather than lose the client's resolution, so the field could claim a rate the display was not running — and it is what the next resize diffs against and what `/display/state` reports. It records what actually committed now, read back via the new `active_mode` (`active_resolution` delegates to it), and logs when the two differ. Deliberately NOT done by tightening `wait_mode_settled`: that gates the re-arrival fallback, so requiring an exact refresh there would force a full re-arrival every time the OS legitimately picked a lower rate. **A short IOCTL_ADD reply leaked an IddCx slot.** The IOCTL had SUCCEEDED — the driver already created the monitor and took a slot; only the reply was short — and the bail undid none of it. The slot pool is small enough that ~16 leaks wedge every later ADD at 0x80070490, which is the wedge the ghost-reap in this same function exists to recover from. It now issues the compensating REMOVE with the session id already in scope, and says so at error level if that fails too. Windows runner: clippy --all-targets clean, pf-vdisplay 55 passed, pf-capture 18 passed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 19:46:15 +02:00