46 Commits

Include renames

Author	SHA1	Message	Date
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	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	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	f94191d927	fix(vdisplay/linux): stop destroying the user's portal config, and honour the /tmp promise the docs made ... Both wlr-family backends need ONE key set in a config file the user also owns — `chooser_cmd` in xdpw's `[screencast]`, `custom_picker_binary` in xdph's `screencopy { … }`. Both did it by `fs::write`-ing a COMPLETE file over whatever was there, so every other setting the user had in `~/.config/xdg-desktop-portal-wlr/config` or `~/.config/hypr/xdph.conf` was destroyed on first connect — silently, permanently, no backup. They now set that one key in place and keep every other line byte-for-byte, with a one-time `create_new` backup the first time we touch a file we did not write (once, so a later edit cannot overwrite the user's ORIGINAL with our own earlier output). The merge lives in its own module because a merge is only worth doing if it cannot corrupt what it merges into: seven tests cover the three cases per grammar — block absent, key present, key absent — plus idempotence (which is what keeps the caller from restarting the portal on every connect) and the empty-file shape. Four of them FAIL against the old whole-file write, so they are not vacuous. The module is declared unconditionally though only Linux calls it: the logic is pure string handling, and tests that guard a user's real config should run on every platform's CI, not only where the callers compile. Separately, seven call sites resolved the runtime dir as `env::var("XDG_RUNTIME_DIR").unwrap_or_else(|_| "/tmp".into())` while their own doc comments promised the opposite — "per-user, 0700 — NOT a world-writable /tmp path another local user could pre-create or rewrite between our write and xdph's read". One of those paths is an executable xdph then RUNS. `Ok("")` was the same defect's other half: it yielded a path relative to the process CWD rather than any runtime dir. All seven now go through one resolver that applies the rule `session.rs` already had (non-empty, else `/run/user/<uid>`, never /tmp). The picker shim also gets its mode at CREATION rather than a chmod afterwards, so it is never briefly world-readable while being a file something else executes. And identity.rs was the only writer in the workspace creating `pf_paths::config_dir()` — which holds the host private key, the pairing allow-list and the mgmt token — with a plain `create_dir_all` instead of the 0700 `create_private_dir` every other writer uses. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 19:46:15 +02:00
enricobuehlerandClaude Opus 5	8b076f5cc9	fix(vdisplay): the gamescope sub-mode is a per-session value, not a process-global env write ... Completes what the env-lock fix started. `apply_input_env` published its decision into PUNKTFUNK_GAMESCOPE_NODE/_SESSION and `GamescopeDisplay::create` read it back out — with the lock released in between, and with the GameStream plane, the mid-stream switch watcher and the capture-loss rebuild all re-running the writer. So session B's routing decision could retarget session A's `create`: A asks for a bare spawn, B connects, A attaches to B's session instead. The decision now travels as a `GamescopeRoute` return value and is carried on the backend INSTANCE via `set_gamescope_route` — the discipline `set_launch_command` already documents two lines above it ("Carried on the backend instance — NOT a process-global env var — so concurrent sessions can't stomp each other's launch target"). Nothing writes the two keys any more; they are read once, as operator overrides, and `create`/`poolable_now`/`launch_is_nested` all answer from the session's own route. The route carries its payload rather than just the verdict, so the managed session flavour and the attach node id stop being separate env reads too. Threaded through both planes: handshake -> SessionContext -> `vd`, and the GameStream `open_source` -> `run`. Three re-resolution points needed the same treatment and each would have silently downgraded a session to a bare spawn without it — the switch watcher's rebuilt backend, the capture-loss rebuild (which can swap the whole instance), and the operator-pinned path, which deliberately skips the input-backend write but still needs a route. That last one is why the ladder is split out as `resolve_gamescope_route`: a `PUNKTFUNK_COMPOSITOR` pin must not silently mean "bare spawn" on a box pinned to the managed session. `#[must_use]` on both entry points found the capture-loss site, which I had missed. Verified on 192.168.1.21: whole workspace `cargo check -p punktfunk-host`, clippy --all-targets clean over the host and pf-vdisplay, 100 pf-vdisplay tests, and the live GNOME create/drop still green. Windows + Linux xcheck clean on the Mac. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 19:46:15 +02:00
enricobuehlerandClaude Opus 5	80e57c70be	fix(vdisplay): the env lock covered its writers and not its readers, and the gamescope ladder read back its own output ... Two halves of the same problem — process env used as shared mutable state. `apply_session_env` set XDG_RUNTIME_DIR / DBUS_SESSION_BUS_ADDRESS / WAYLAND_DISPLAY / HYPRLAND_INSTANCE_SIGNATURE / SWAYSOCK under ENV_LOCK, while detection read those same five keys with no lock at all, from five points spread across a `/proc` scan. That is exactly the hazard ENV_LOCK's own doc names: glibc `setenv` can realloc `environ` and free the old value string, so a concurrent `getenv` reads freed memory — UB documented there as "could crash the host". It is reachable today: the host's session watcher calls `detect_active_session` every second for a stream's lifetime while a second client's connect runs `apply_session_env` on a spawn_blocking thread. Detection now samples all five into an `EnvProbe` in ONE locked read and scans from that snapshot. Taking the lock around the whole of `detect_active_session` would have been simpler and wrong: it walks `/proc` every second, and holding a process-wide lock across a directory walk trades this problem for the one Phase 7 is about. The readers become pure functions of their inputs, which is also what let the tests stop mutating process env to steer them — `without_inherited_swaysock` is gone, replaced by handing in a probe. Empty values are now treated as absent, so `XDG_RUNTIME_DIR=""` falls back to /run/user/<uid> instead of yielding a relative path. The gamescope sub-mode ladder had a nastier version: `apply_input_env` WRITES PUNKTFUNK_GAMESCOPE_NODE/_SESSION to publish the sub-mode it chose, and read the same keys back as operator overrides. The Attach arm sets `_NODE=auto`, and `node_env` sits at rung 2 of the ladder — above `dedicated_launch` at rung 3 — so one Attach decision latched Attach for the rest of the host's life and silently overrode `game_session=dedicated`. Only rung 1 could escape it, because the Spawn arm that would have cleared the keys sits below the rung that by then always fired. The overrides are now sampled once, before this module has written anything, which keeps their actual meaning: "the operator set this before we ran". The live reads that remain (`launch_is_nested`, `poolable_now`) are deliberate — those consume the published decision. And gamescope's `create` read both keys unguarded, racing the writer and skipping the lock its two siblings take for the same keys; it now takes one guarded snapshot. Verified on Linux (.25): 100 passed, 1 ignored. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 19:45:36 +02:00
enricobuehlerandClaude Opus 5	787756e68b	test(vdisplay/mutter): the on-glass lever for the GNOME backend, and what it took to see the leak ... `live_mutter_create_drop`, `#[ignore]`d in the same convention as the Windows backend's live tests: the real four-step handshake, hold, then drop the keepalive and let the RAII teardown revert it. Verified against gnome-shell on 192.168.1.21 — node_id came back in ~5 ms, preferred_mode as asked, and the topology reverted. Two things that would otherwise be re-derived by whoever validates this next, both of which cost a wrong answer here first. The virtual monitor does NOT appear in DisplayConfig's GetCurrentState just because `create` succeeded — its size follows the PipeWire negotiation, so without a consumer attached there is no monitor to census. A before/after monitor diff therefore proves nothing about this backend, which is the trap the first attempt fell into. And a short-lived process cannot exhibit the abandoned-thread leak at all: exiting drops the D-Bus connection, which makes Mutter tear the session down no matter which code is running. Reproducing it needs the process held alive past the failed create, and the observable is the live RemoteDesktop session object, not the monitor: `gdbus introspect -d org.gnome.Mutter.RemoteDesktop -o /org/gnome/Mutter/RemoteDesktop` lists a `node Session` child per live session. With a 1 ms create timeout forced and the process held 20 s, that probe reads 0 with b89a36a6 and 1 without it — the orphan thread parked on a live session. Both read 0 after exit, which is precisely why this only ever bit a long-running host. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 19:45:11 +02:00
enricobuehlerandClaude Opus 5	69bc92afed	fix(vdisplay/mutter): a create timeout no longer abandons the session thread with the desktop dark ... `create` gave up after 45 s and dropped its `stop` flag WITHOUT setting it — the `StopGuard` that owns the only `store(true)` was built on the success path only. The thread meanwhile discarded its own send failure with `let _ =`, so it sailed past the dead channel, made the virtual output PRIMARY, and parked in `while !stop` for the rest of the process's life holding the D-Bus connection that IS the monitor's lifetime. Its teardown was unreachable. Under the default topology that orphan applies a SOLE-monitor APPLY_TEMPORARY config. Every physical head goes dark, and Mutter reverts such a config only once the virtual monitor disappears — which the parked thread prevents. There is no in-process recovery: each retry adds another orphan and another virtual monitor. The other three portal/D-Bus backends never had this — kwin.rs, hyprland.rs and wlroots.rs all `?` on that exact send. Mutter is now the same shape, via a shared `report_node` that stops the session when the opener has gone. Two more layers behind it, because the send can also LAND in the moment `recv_timeout` gives up: `create` and `stream_existing_output` build their guards BEFORE the wait, so every error arm signals the thread on its way out, and the thread re-checks the flag before it touches topology — so a doomed session never applies a sole-monitor config at all, rather than applying one and reverting it a tick later. The fix lands once because the duplication that caused it is gone first: `connect` and `connect_monitor` shared ~72 verbatim lines, and the mirror path repeating the session path's `let _ = send` is precisely what that copy bought. Both now share `open_rd_sc` (steps 1-2) and `start_and_await_node` (step 4). Also stops a physical hotplug stealing the virtual monitor's identity. `wait_virtual_connector` took "any connector absent from the pre-snapshot" across a window spanning a ~10 s stream wait plus 6 s of polling; TOPOLOGY_LOCK keeps sibling sessions out of it but a hotplug is not ours to serialise, and the session's topology apply and scale persistence would then be aimed at the operator's new panel. It now prefers the connector advertising the client's exact WxH — the discriminator `make_virtual_primary` already matches on — falls back to the old behaviour when that singles nothing out, and warns when more than one candidate appears. Tests: `pick_virtual` split out of the polling loop so the choice is testable without a session bus. Verified on Linux (192.168.1.25): 99 passed, and the hotplug case FAILS against the old first-new-connector logic, so it is not vacuous. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 19:45:11 +02:00
enricobuehlerandClaude Opus 5	6782aa0054	fix(vdisplay): stop the suite reporting ok for tests that never ran, and let clippy see the KWin backends ... Three coverage holes, all of the same shape — a gate that looks green because nothing is behind it. The Windows half (~3,400 lines) had no executed tests. Its only two `#[test]`s opened with `if env::var("PUNKTFUNK_PF_VDISPLAY_LIVE").is_err() { return; }`, so without the hardware they passed without running, and no CI job compiled the crate's test targets at all — `-p punktfunk-host` builds pf-vdisplay as a dependency, which never reaches a `#[cfg(test)]` module. Both live tests are `#[ignore]`d now (an unrun hardware test should say `ignored`), and windows-host.yml gains the `--all-targets` lint plus a real test step. The link question that keeps the host and pf-encode on clippy-only does not apply: pf-encode is `default = []` and nothing here turns on nvenc/amf-qsv/qsv. Settled on the runner to the same standard as pf-capture's step — 46 passed, 2 ignored. `#![allow(clippy::all, ...)]` at the top of kwin.rs and kwin_output_mgmt.rs was meant for wayland-scanner output, but the generated modules already carry their own copy of that attribute — so the file-level one was only ever silencing 2,366 lines of hand-written backend, with `clippy::correctness` (deny-by-default) among the casualties. Dropping it found a dead match arm in the `kde_output_configuration_v2` dispatch; that one is now exhaustive on purpose, so a re-vendored XML that adds an event fails the build instead of dropping it silently. (The sibling `_ => {}` in the DeviceMode dispatch is NOT dead — `ModeEvent::Removed` really does reach it and get swallowed, which is a separate defect.) `dead_code` is now enforced on Linux, where ~10k of the ~17k lines live, instead of allowed crate-wide behind a rationale that had stopped being true. It turned up no genuinely dead code: four items, every one live from tests or another platform, now annotated with which. One deserved the comment most — `Entry::keepalive` is "never read" because it is an RAII guard whose `Drop` releases the compositor output, so deleting it as unused would release every pooled display the moment it was created. Two tests were not testing what they claimed. `another_uids_socket_is_ignored` asserted the sway-socket ownership guard but never reached it — `find_sway_socket` filters on the `sway-ipc.<uid>.` filename prefix first, so the foreign-uid file was rejected by name and the assertion held even with `md.uid() != uid` deleted. It is renamed to what it does cover, and the real leg is a new `#[ignore]`d root test that chowns a correctly-named socket (querying with a non-matching pid, or the exact-path shortcut would return before the guard and make it vacuous all over again). And proc.rs's tests were ungated while the module is compiled everywhere, so they would have gone red on Windows the first time anyone ran them: `#[cfg(all(test, unix))]` now, with a `cmd /c` twin that does run there. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 19:45:11 +02:00
enricobuehlerandClaude Opus 5	eb4ab91627	feat(host): a frame limiter for the game, not for the stream ... PUNKTFUNK_MAX_FPS caps how fast the compositor lets the game render. It deliberately does NOT touch the session: the client still negotiates and receives its full rate, because the encode loop re-encodes the held frame whenever the compositor produced no new one, and a repeat of an unchanged picture is an almost-empty P-frame. So a 60-capped game on a 120 Hz session still puts 120 frames a second on the wire — and the GPU time the game gives up goes to capture and encode instead, which is the point (on a laptop or a handheld, it goes to heat and battery too). Capping the stream would be a different and mostly unwanted feature: it hands the client fewer frames than it asked for and saves the game's GPU nothing. gamescope is the compositor that has the lever, so it is the one that gets it: the rate becomes --nested-refresh, which is what gamescope clamps the game to. All three sessions we own take it — the bare spawn's -r, the managed gamescope-session-plus wrapper's PF_HZ, and the SteamOS PATH shim's. In the managed path the limit lands on PF_HZ alone and NOT on CUSTOM_REFRESH_RATES, so the mode the session advertises stays the client's — that is what makes games see the real refresh rather than the box's EDID. Two scoping notes. Under gamescope the cap is the nested output's rate, so everything it composites moves at it, not the game alone; there is only the one output. And the attach path (PUNKTFUNK_GAMESCOPE_NODE) mirrors a gamescope we do not own, so it has no lever to pull and is untouched. Closes #13 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 19:14:10 +02:00
enricobuehlerandClaude Opus 5	0c4e582b29	fix(gamescope): a managed session now proves our flags reached it ... The bare spawn builds gamescope's argv itself. The two managed modes hand the flags over indirectly — `gamescope-session-plus` through `GAMESCOPE_BIN` + `PF_HDR_ARGS`, SteamOS through a PATH shim — and a session free to ignore either would exec the distro's gamescope carrying none of them. Half of that failure was already loud: HDR dies on the bit depth the Welcome fixed before the display existed. The other half was silent. The host had been told the compositor would paint the pointer, so it stopped painting one, and nobody did — a stream that is correct in every respect except that it has no cursor, which nothing in the logs would have said. So both managed paths now read the running compositor's `/proc/<pid>/cmdline` once its node appears, and refuse the session when a flag we passed is missing. The plan is fixed by then (`cursor_blend` feeds the encoder open, which precedes the display), so this session cannot be corrected in place; instead the capability is latched off for the process and the spawn fails, and the retry resolves a correct SDR host-composited session. One rejected attempt per boot, then it converges. Fails OPEN at every ambiguity: no flags expected, or no readable gamescope in `/proc`, says nothing. And it accepts ANY running gamescope carrying the flags, because a box commonly has a second one — the Nobara test box runs its own game-mode `/usr/bin/gamescope --steam` beside ours. That leaves only false PASSES possible, and the flag that matters cannot produce one: `--pipewire-composite-cursor` exists nowhere but our patch set. Two things fell out of writing it. `gamescope_argvs` matches argv[0]'s basename with `ends_with`, not `==` — the old equality test would have missed our own `punktfunk-gamescope`, which is what `current_gamescope_output_size` was already scanning for. And `hdr-probe` gained a line for who paints the cursor, the one capability with no symptom of its own until you compare two streams. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 18:03:30 +02:00
enricobuehler	fd648aa776	feat(gamescope): put the cursor in the node, so a session can be zero-copy ... gamescope keeps the pointer out of its PipeWire node — it lives on a hardware plane for scanout, and `paint_pipewire()` composites a separate, reduced frame that never includes it. So punktfunk has always reconstructed it from XFixes and blended it in host-side. That blend is what has been blocking the zero-CSC encode path, and the cost is larger than it sounds: `VulkanVideoEncoder::open` refuses the RGB-direct (EFC) source for any session with `cursor_blend`, because that front end is fixed-function and has no blend stage. `cursor_blend_for` sets it unconditionally for gamescope. Net effect: a gamescope session paid a full-frame colour-conversion pass per frame, forever, for a pointer. So put the cursor where it belongs. A second carried gamescope patch adds `--pipewire-composite-cursor` (off by default — the node has never carried it, and a consumer that draws its own would get two), painting it with the same `MouseCursor::paint` call the scanout composite uses. It scales for free: paint_pipewire has already set `currentOutputWidth/Height` to the capture size, which is what that function scales against. The repaint test grows the cursor's state beside the commit ids — a pointer-only move produces no commit, so without it the composited cursor would freeze on a static screen while the real one moved, and a cursor that became hidden would never be erased. Host side, the `+pfhdr` marker becomes a monotonic PATCH LEVEL, so one probe answers every capability the session must know before it is planned (level 1 = HDR formats, level 2 = the cursor flag). `cursor_blend_for` and the `gamescope_cursor` resolver both consult it through one helper, because they have to agree: the reader without the blend is a wasted X11 connection, the blend without the reader is a stream with no pointer, and both together with a gamescope that paints its own would draw two. ⚠ The two indirect spawn modes carry the flag through `PF_HDR_ARGS`, so this shares a dependency with the HDR flags: a session that ignores `GAMESCOPE_BIN`/`PATH` and execs the distro's gamescope gets neither. HDR fails loudly there (negotiation timeout + SDR latch); a missing cursor would be silent. Noted in packaging/gamescope/README.md as worth a post-spawn `/proc/<pid>/cmdline` check if it ever bites.	2026-07-28 18:03:30 +02:00
enricobuehler	689297c86e	feat(hdr): a gamescope session streams true HDR10, decided before the Welcome ... The Linux native plane has been 8-bit for a reason that stopped being true: `capturer_supports_hdr()` returned a flat `false` because Mutter's virtual monitors are SDR-only upstream. That is still right for Mutter, KWin and wlroots — and wrong for gamescope, whose node can now offer 10-bit BT.2020 PQ (packaging/gamescope). Open the three gates that held it off, together: * the capture-side gate becomes SOURCE-AWARE (`capturer_supports_hdr_for`): Windows keeps its platform answer, gamescope asks whether the resolved binary offers the formats, everything else stays false. It must be truthful rather than optimistic — the Welcome is irrevocable, and PQ frames on an 8-bit encoder are a deliberate hard error — so every term is a static fact resolved before anything is spawned, including "do we spawn gamescope at all" (an attach inherits someone else's flags and can promise nothing); * `want_hdr` reaches the capturer: `open_virtual_output` grew the parameter it never had, and the host arm stopped dropping `want.hdr` on the floor; * the spawn gains `--hdr-enabled --hdr-debug-force-support` on all three sub-modes (bare args, the `GAMESCOPE_BIN` wrapper, the SteamOS PATH shim), from one shared `hdr_args` — the force flag is what makes it work headless, and forgetting it looks exactly like a negotiation failure. Two things that would have gone wrong quietly: * the keep-alive reuse key gains `hdr`. gamescope cannot turn HDR on live, so a kept SDR display handed to an HDR session would give the game no HDR surfaces while the stream negotiated PQ over an SDR composite — wrong, and not obviously broken. Same for the managed session-plus/SteamOS reuse check. * the HDR-negotiation-failure latch becomes PER SOURCE. It was one process-wide flag, so a monitor that left HDR mode would have disabled gamescope HDR until the host restarted, and vice versa — two facts with nothing in common but the word HDR. GameStream follows the same shape: `host_hdr_capable` gains the gamescope arm, and the RTSP gate's live BT.2100 monitor probe is scoped to the portal source — a headless box has no monitor to be in HDR mode, so running it there would hard-refuse every gamescope HDR session. Off by default for one release (`PUNKTFUNK_GAMESCOPE_HDR=1`), and `punktfunk-host hdr-probe` now answers for both Linux HDR sources.	2026-07-28 18:02:13 +02:00
enricobuehler	0868b6a364	fix(vdisplay): compositor availability follows the live session, not the env ... GNOME/Mutter reported "Unavailable" on a host sitting in a live Mutter session — and, on the same request, "Default", because the two columns had different sources. available() asked each backend, and those probes read the process env (XDG_CURRENT_DESKTOP for Mutter, WAYLAND_DISPLAY for KWin's registry handshake, SWAYSOCK for sway) — env a host started outside the session (systemd --user, a TTY, ssh) never inherited. It is only retargeted at the live session on the connect path, so the answer also flipped depending on whether anyone had connected yet. Both columns now come from the same /proc scan detect() already used: the live session's compositor is usable by definition, as is an explicit operator pin, and the per-backend probe stays as the fallback for backends that are not the live session (gamescope, which spawns its own). A live KWin without the zkde_screencast grant now surfaces as available and fails at create with that probe's precise message, which beats "no usable compositor" on a box visibly running KDE. Mutter's env sniff stays deliberately narrow — one var, not three. XDG_CURRENT_DESKTOP is the one apply_session_env owns end to end (written per connect, scrubbed when nothing is live); sniffing DESKTOP_SESSION alongside would resurrect the bug that scrub exists to prevent, where a stale value after a gnome-shell crash routes the next client into a dead session. Non-Linux hosts now report no compositors at all rather than five Linux backends flagged unavailable with no default — on Windows the pf-vdisplay driver is the only backend and vdisplay::open ignores the argument, so the old list read as broken detection instead of "not applicable here". The console says so explicitly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit eb7ba3d6177552f5c3ed6a15439404084869c636)	2026-07-28 17:01:59 +02:00
enricobuehlerandClaude Opus 5	b08226dbf1	feat(vdisplay): mirror a pinned monitor on sway and Hyprland ... P5 of design/per-monitor-portal-capture.md, and the end of a hole worth naming: the pin was accepted, persisted and offered in the console while `create` bailed on these two backends, so a sway or Hyprland host with a monitor selected failed EVERY session. Both already ship the mechanism — a managed portal-chooser config plus a per-session selection file (xdpw's `Monitor: NAME`, xdph's `[SELECTION]screen:NAME`) — so mirroring is that same chooser pointed at a physical connector instead of a headless output we created. The keepalive stops the cast and nothing else; the monitor is the compositor's. The selection write is now serialized against the handshake that reads it (SELECTION_LOCK, applied to the virtual-output paths too). That file is one per-user path: whoever writes last before the portal reads wins, and the loser does not fail — it silently captures the other session's output. `managed` is no longer grounds for refusal everywhere. It is conclusive only where the name is ours by construction (KWin's `Virtual-punktfunk`, Hyprland's `PF-N`); sway names EVERY headless output `HEADLESS-N`, its own included, so the old rule would have refused to mirror any output on a headless sway box — exactly the remote setup this feature serves. Found on-glass, and now a test. Verified on a two-output headless sway: asking for HEADLESS-1 yields 1280x720 frames and HEADLESS-2 yields 1920x1080, so the chooser really does steer per request. Hyprland is compile-only — no Hyprland box exists. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	045deaf77a	fix(vdisplay/kwin): bind the output-device REGISTRY — KWin 6.7 stopped ... advertising per-output globals Found on-glass while testing monitor enumeration: KWin 6.7.3 advertises kde_output_device_registry_v2 and NOT one kde_output_device_v2 global per output. This module only ever bound the globals, so on a current KWin it saw zero devices. That is not just an enumeration gap — it silently disabled the whole in-process output-management path, which exists precisely because kscreen-doctor wedges. The live 0.19.2 host on the test box logs "kde_output_management unavailable — kscreen-doctor fallback" on EVERY session, so every topology apply there has been going through the tool this module was written to stop using. Both models are supported now: the per-output globals older KWin sends, and the registry's `output` events. Devices from the registry arrive a round later than globals do, so the handshake takes one more barrier — skipped when nothing is still awaiting its `done`, so the classic path costs nothing. Verified on KWin 6.7.3: enumeration now reports HDMI-A-1 1920x1080@60 at +0,+0 scale 1.35 primary, matching kscreen-doctor exactly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	bf2f54a5fe	feat(vdisplay): mirror a pinned monitor on Mutter, and scope the HDR probe ... P3 of design/per-monitor-portal-capture.md. Mutter's mirror is the same private ScreenCast session the virtual path already drives, one call different — RecordMonitor instead of RecordVirtual — so it inherits what makes that path work headlessly: a direct D-Bus API that needs no interactive approval, unlike the xdg portal a background service could never answer. Deliberately not under TOPOLOGY_LOCK: that serializes operations which add or remove a monitor or apply a monitor configuration, and mirroring does neither. Nothing is created, no layout changes, and teardown is just Stop — the SIGSEGV-adjacent ordering the virtual path must observe cannot arise when no monitor is being removed. The GNOME HDR probe now honors the pin. Asking "is ANY monitor in BT.2100 mode" was fair while capture took whatever head it was handed; once the operator names one, an HDR TV on the next connector must not talk the host into offering PQ formats for the SDR panel it is actually streaming. A pin that names no live head reports SDR rather than falling back to "any" — the session is about to fail on that same missing monitor, and an over-claimed HDR offer would be a second, quieter wrong answer. ⚠️ RecordMonitor's exact signature is read from the interface, not yet confirmed against a live gnome-shell; no GNOME box was reachable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	53c772702f	feat(host): list-monitors CLI, and two bugs it caught on-glass ... An operator configuring an unattended host has to learn the connector names from somewhere, and "curl the management API before the host is configured" is not it. `punktfunk-host list-monitors` prints them with geometry and flags the pinned one. Running it under a real sway immediately caught two defects the unit tests could not: - the query used the `swaymsg` command helper, which inserts `--`, so `-t get_outputs` came back as "Unknown/invalid command '-t'". Queries now go through a `swaymsg_query` helper that cannot make that mistake. - compositors write the literal "Unknown" rather than leaving make/model empty, so the picker label read "Unknown Unknown". One `describe` helper now treats that as absent, for all four backends. Verified on a headless two-output sway: names, modes, positions, scale and the case-insensitive pin all resolve. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	93c2765db7	feat(vdisplay): mirror a pinned physical monitor on KWin ... P2 of design/per-monitor-portal-capture.md. zkde_screencast's stream_output records an output KWin already has — the connector name IS the selection, so there is no dialog, no portal and no chooser for a background service to answer. It arrives as a VirtualDisplay reporting DisplayOwnership::External, which already means "someone else's display, merely mirrored: no keep-alive, no topology, no reuse". So the rule that we must never disable, move or "restore" a monitor the user is sitting in front of holds by construction rather than by everyone remembering it — and create() ignores the client's requested mode for the same reason: a panel runs at the mode its owner set. Routing lives in vdisplay::open, the one place every session opens a display, so the pin cannot be honored on one plane and ignored on another. The host sets the libei anchor from the same pin (pf-vdisplay must not depend on pf-inject), which is what makes absolute input land on the mirrored head instead of a same-sized neighbour. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	95e3314d9a	feat(vdisplay): enumerate the host's physical monitors ... P0 of per-monitor capture (design/per-monitor-portal-capture.md): nothing in the tree could answer "what heads does this host have?", which both a monitor pin and a console picker need first. One read per compositor, each beside the code that already speaks that dialect: KWin's kde_output_device_v2 (the topology session now also records geometry + scale), Mutter's DisplayConfig.GetCurrentState, swaymsg get_outputs, hyprctl monitors. Logical geometry throughout, because x/y is what identifies a head — two monitors can share a size but never an origin. PUNKTFUNK_CAPTURE_MONITOR parses here and is reported at startup, loudly including that it is not yet enforced: a knob that is read but inert has to say so, or "it didn't work" reads as a bug. GET /display/monitors always answers 200 with an explained empty list, so a compositor-less host renders as "nothing to pick", not as a broken console. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehler	6be865f33f	fix(host): a host that is stopped hands the box's session back first ... Until now the host had no signal handling at all: SIGTERM killed it outright. That is fine for a host that owns nothing — but a managed gamescope takeover owns the box's session, and on a mask-fragile display manager (Nobara's plasmalogin) it has STOPPED that display manager for the length of the stream. Killed there, the host leaves a box with no graphical session and nothing left to restart it: the crash-restore state lives in $XDG_RUNTIME_DIR, which logind removes along with the user manager, so not even the next host start can heal it. `systemctl --user restart punktfunk-host` mid-stream — or a package update doing it for you — was enough to strand a box until someone reached a VT. So SIGTERM and SIGINT now restore first and exit after. The restore runs on a blocking thread (it shells out) under a 20s grace, well inside systemd's TimeoutStopSec, and a host that took nothing over exits immediately. `restore_takeover_now` is the synchronous sibling of the debounced disconnect restore, and deliberately ignores the keep-alive policy the latter honors: `keep_alive=forever` pins a session for the NEXT client, which means nothing once the host that would serve them is exiting. Both paths now share one `takeover_live()` predicate instead of repeating the four-way "is anything ours" test. Checked on Linux: clippy -D warnings on punktfunk-host + pf-vdisplay, tests, rustfmt.	2026-07-27 19:04:20 +02:00
enricobuehler	f3615f83a5	fix(gamescope): the takeover no longer kills the host it is running in ... Field report, Nobara + 0.20.0: switching into Game Mode mid-stream disconnects the client and the box never lights up again. His journal has the whole mechanism, ten seconds apart: 12:34:18.9 freed Steam: stopped the display manager for this stream 12:34:29.0 systemd[1685]: Stopping punktfunk-host.service Stopping the display manager ends the user's last login session. The packaged host is a `systemd --user` unit, so logind then stops user@1000.service once UserStopDelaySec elapses — 10s by default on Nobara — and takes the host with it. The stream dies, the scheduled restore never runs, and the display manager stays down with nothing left to restart it: a black box that needs a VT to recover. Exactly the two symptoms reported, and the intermittency is just whether an active Gaming Mode session was there to trigger the takeover at all. It never showed on the repro VM because lingering was enabled there for the earlier sessionless tests (`Linger=yes` — confirmed on the VM today), which is precisely the thing that breaks the dependency: logind keeps the user manager alive with no session. Our KDE/GNOME/Arch setup guides already ask for it; his box, following the KDE route, did not have it. So the takeover now ensures lingering BEFORE it touches the display manager: `loginctl enable-linger` directly (allow_active in logind's own policy — verified working unprivileged on Nobara), else the packaged helper gains a `linger` verb that enables it for PKEXEC_UID alone, never a caller-named user. If neither works the takeover is refused with an actionable error and managed degrades to attach — mirroring the box's own session is strictly better than a screen that needs a VT. Hosts that cannot be reached this way (root, a system unit) skip the check: the cgroup test is a pure `cgroup_under_user_manager` with a unit test, matched against the real shapes on a Nobara box (`user@1000.service/app.slice/...` vs a `session-N.scope`). Also documents the requirement in the gamescope guide's Nobara section. Checked on Linux: clippy -D warnings, 78 tests, rustfmt; helper verified with `sh -n`, and the linger enable/disable round-trip run live on the Nobara VM.	2026-07-27 19:04:20 +02:00
enricobuehler	eae1837a3a	fix(gamescope): a managed takeover never waits on a dialog nobody can see, nor acts on a months-old sentinel ... Two ways the Nobara DM-stop takeover could end a session and leave the box dark, both found while triaging a 0.20.0 field report (managed round-trip: "my client disconnects and my monitor doesn't turn back on", intermittent). 0.20.0 is the first release where that box runs the takeover for real — before it, no package shipped the polkit privilege, so managed always degraded to attach and never touched the display manager. Privileged verbs are non-interactive now. `try_stop_display_manager` and `restore_display_manager` try a plain system-bus `systemctl` first, and without `--no-ask-password` that asks polkit for INTERACTIVE authorization. On a box where the host runs inside the user's graphical session, polkit hands that to the session's agent: a password dialog on the box's own screen, which during a takeover is off or mid-switch. Nobody sees it, nobody answers it, and the call blocks on the stream's own thread — the capture-loss rebuild, or the restore worker — while the rebuild budget burns. The takeover then lands after the session it was for already ended. With the flag it fails immediately ("interactive authentication required"), which is what both callers are already written for: the packaged pkexec helper (allow_any, no agent needed) takes it from there. A sentinel with no baseline is not a request. `session_select_requested` read "no baseline recorded" as "the sentinel appeared during the session" — but `~/.config/steamos-session-select` is a permanent file, so every box whose user has ever switched sessions has one. The baseline was recorded only after a SUCCESSFUL launch, leaving a real window: takeover succeeds, launch fails, the client retries inside the 5s restore debounce (which the retry cancels), and the honor gate fires on a months-old write — pushing the box to the desktop the user never asked for, plus a 120s grace refusing to relaunch game mode. Now the baseline is taken at takeover too (setting STOPPED_DM is what arms the gate), and "never baselined" reads as no request. `SESSION_SELECT_BASELINE` carries both states explicitly, and the decision is a pure `sentinel_advanced` with a unit test for all six cases. Checked on Linux: cargo check --all-targets, clippy -D warnings, 77 tests, rustfmt.	2026-07-27 19:04:20 +02:00
enricobuehlerandClaude Fable 5	0323158a3e	fix(vdisplay/gamescope): a fresh dedicated launch streams from the first second ... A freshly spawned headless gamescope never delivered a single PipeWire buffer when a game was launched: gamescope only composites (and only on a composite pushes a capture buffer) when a client paints, and a nested Steam bootstrap paints nothing until its UI's first frame — far longer than the 10 s first-frame budget. The native plane's retry ladder then killed the half-booted Steam on every attempt and started from zero; the GameStream plane died on its single wait. Reused live displays worked, which pointed away from the real cause (root-caused on .41 with a raw pw_stream probe: `sleep infinity` nested → 0 buffers ever, `vkcube` nested → 60/s immediately). Every bare spawn now backgrounds the host's own splash client (`gamescope-splash`, hidden subcommand) beside the nested app: a dark window with a subtle breathing bar painted at ~2.5 Hz — damage from the first second, so capture gets its first frame within the budget on both planes. In `--steam` mode gamescope composites only windows whose appid is in the root `GAMESCOPECTRL_BASELAYER_APPID` list (live-proven: even a painting vkcube gets zero composites without it), so the splash declares itself as the Steam UI (STEAM_GAME=769) and seeds the baselayer iff unset; Steam's own rewrite at game launch hands composite focus to the game with no action on our side. PUNKTFUNK_GAMESCOPE_SPLASH=0 is the escape hatch. The dedicated Steam launch is also shaped with `-gamepadui` instead of `-silent`: the nested Steam is Big Picture — the identity gamescope's `--steam` integration is built around — so the boot shows the gamepad UI instead of the desktop client window flashing through the stream, and gamescope's focus rules (game outranks the Steam UI appid) cover what `-silent` was working around. On-glass on .41 (Bazzite, RTX 5070 Ti, gamescope c31743d): cold connect + Balatro launch delivers frames on the first attempt on both a cold and a torn-down-then-fresh spawn; Big Picture boot → game handover confirmed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 00:28:59 +02:00
enricobuehlerandClaude Fable 5	8d5a9f66c9	fix(gamescope): ship a packaged privilege path for the DM-stop takeover ... Field report (Nobara, 0.19.2): entering Game Mode mid-stream left the monitor on and the stream mirroring at the desktop's resolution. Root cause: the DM-flavor takeover needs privilege to stop plasmalogin, the polkit rule is a docs-only manual step nobody installs, so every managed entry silently degraded to ATTACH — and with a physical display connected the attach path mirrors the box's own session at its own mode. Ship the privilege with the packages instead: a root helper (libexec/punktfunk/pf-dm-helper, verbs stop|restore) behind its own polkit action (io.unom.punktfunk.dm-helper, allow_any — the same mechanism Nobara's os-session-select uses, and the helper derives the DM unit from the display-manager.service symlink itself so callers never name a unit across the privilege boundary). The host tries the plain system-bus verbs first (root / operator rule still take precedence), then pkexec's the helper; the restore paths (idle restore + in-stream desktop-switch honor) use the same ladder so a takeover that needed the helper can always be undone by it. Packaged in rpm/deb/arch (Arch under /usr/lib/punktfunk with the policy's exec.path annotation rewritten; the host probes both layouts). Nix is left out deliberately: store paths can't match the probe, NixOS keeps the manual rule. Docs updated — the rule snippet stays as the scoped alternative. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 23:41:29 +02:00
enricobuehler	7781d09e26	feat(linux): log if unsupported / too low gamescope version discovered	2026-07-24 20:57:44 +02:00
enricobuehlerandClaude Opus 4.8	64511af4d3	fix(kwin): install >60Hz custom modes in-process too — KWin path is now kscreen-free ... Follow-up to the previous commit: the only KWin topology op still shelling out to kscreen-doctor was the >60 Hz custom-mode INSTALL (`set_custom_refresh`). Port it to `kde_output_management_v2` so the whole KWin path is kscreen-free on modern KWin. `kwin_output_mgmt::set_custom_mode` builds a one-entry `kde_mode_list_v2` (set_resolution / set_refresh_rate / set_reduced_blanking=full / add_mode), applies it via `kde_output_configuration_v2.set_custom_modes` (since 18), waits for KWin to generate the mode (its CVT generator may align the width down — matched with the same height-exact / width-within-8 / refresh-within-1Hz gate as before), then selects it — which changes the output size and drives the sacrificial-birth stream renegotiation. `kwin::create`'s want_high branch tries this first and only resolves a kscreen id + calls `set_custom_refresh` if it returns None (pre-6.6 KWin without set_custom_modes, or the compositor not answering) — so a >60 Hz session on a box where kscreen-doctor wedges no longer eats a 5 s resolve timeout either. Bonus: `set_custom_modes` REPLACES the custom list, so reconnects are idempotent — no more one-custom-mode-per-connect growth of the user's display list. Verified: cargo test -p pf-vdisplay (73 pass), clippy -D warnings clean, fmt clean. The set_custom_modes round-trip is proven live on KWin 6.6.4: apply=applied, and a 1648x928@75 request generates 1648x928@74.901 (CVT fractional refresh, caught by the 1 Hz tolerance). The mode SELECT + full >60 Hz stream is still owed on-glass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 12:47:34 +02:00
enricobuehlerandClaude Opus 4.8	86d5d66660	fix(kwin): drive display topology over kde_output_management_v2, not kscreen-doctor ... A KDE host on Nobara stopped disabling its physical screens and creating the virtual output the moment it updated: streaming still came up, but bring-up took ~26 s and the streamed output never became the desktop (`also_disabled=[]`). Root cause is not our topology logic — it's that every `kscreen-doctor` call on the reporter's session wedges. kscreen-doctor drives libkscreen, which (per setup) waits on the kscreen KDED module over D-Bus; when that layer is stuck it blocks in its own connect and never returns, so all five topology queries hit their 5 s budget and got killed (host log). Reproduced live on a Nobara / KWin 6.6.4 box: `kscreen-doctor -j` there times out at 8 s, every time. But the compositor's OWN Wayland is fully responsive on that same session — the host just created a virtual output over it via zkde_screencast. So drive the topology (resolve our output, take primary, disable the physical/bootstrap outputs, capture their modes, re-enable on teardown, position) directly over `kde_output_management_v2` + `kde_output_device_v2` instead of shelling out. On that same Nobara box the in-process path binds management (v19) and enumerates the outputs in 2.4 ms — ~3400x faster than the 8 s hang, and immune to whatever wedges the standalone tool. - vendor kde-output-management-v2 / kde-output-device-v2 (KWin advertises mgmt v19, device v20); generate client bindings inline (the interdependent-protocol module split from the wayland-protocols crate; needs the `bitflags` dep for the device protocol's bitfield enums). - new `kwin_output_mgmt`: bounded enumerate-then-apply over one Wayland connection; every wait is time-bounded so a genuinely wedged compositor degrades to `handled = false` and the old kscreen-doctor path still runs. - `kwin::create` topology + `apply_position` prefer the in-process path (address our output by its stable device UUID, supersede-robust) with kscreen-doctor as the fallback. The 60 Hz path now makes ZERO kscreen-doctor calls; only the >60 Hz custom-mode install still shells out (its in-process port is a follow-up). Verified on Linux: cargo test -p pf-vdisplay (73 pass), clippy --all-targets -D warnings clean, fmt clean, punktfunk-host checks clean. In-process enumeration proven live against KWin 6.6.4 (the reporter's env); the disable/apply path is not yet on-glass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 12:47:33 +02:00
enricobuehlerandClaude Fable 5	a3e21d9227	feat(vdisplay/gamescope): honor in-stream 'Switch to Desktop' under the managed DM takeover ... First on-glass test of the DM-flavor takeover confirmed the black-screen fix, but exposed that the managed model could not switch back: Steam's in-stream session-select is a silent no-op while the display manager is stopped (every config-write branch in os-session-select requires the DM to be running), so the capture loss it causes just relaunched game mode. The user pass of the switch script does leave one durable trace — the ~/.config/steamos-session-select sentinel, written before any DM check. The managed launch now baselines its mtime; a capture loss with the sentinel advanced reads as the switch request and is honored by replaying the switch with the DM up: restore the display manager, run the distro's own os-session-select (its internal pkexec is authorized allow_any by the distro policy, so it works from the host's sessionless context), then stop the autologin game-mode unit so Relogin lands in the newly selected desktop. The capture-loss re-detection then follows KWin as it comes up; a 120 s post-honor grace stops the rebuild loop from racing the booting desktop back into game mode (superseded early if the box's own game-mode unit reappears — the desktop→game leg stays fast). The baseline is re-recorded on crash-restore so a pre-existing sentinel never reads as a fresh request. Every verb in the sequence was live-validated on the Nobara repro VM. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 11:49:24 +02:00
enricobuehlerandClaude Fable 5	e35dad529b	fix(vdisplay/gamescope): DM-flavor-aware session takeover — stop masking Nobara's plasmalogin to death ... Field report (Nobara 43 HTPC): switching the host to Steam Game Mode mid-stream permanently black-screened the box. Live-proven root cause on a Nobara repro VM: our takeover masks the box's gamescope-session-plus unit, plasmalogin's Relogin=true then fails its session Exec repeatedly and trips systemd's start limit within ~1 s — the display manager dies, and our restore verb (unmask + user start) cannot bring a seatless gamescope back. Only 'reset-failed + restart' of the DM recovers. The takeover is now display-manager-flavor-aware: - SDDM (Bazzite/SteamOS) keeps the proven mask+SIGKILL path unchanged. - plasmalogin/unknown DMs never mask: with privilege (root or an operator polkit rule scoped to the DM unit — documented) the host stops the DM for the stream and restores it with reset-failed + restart (PUNKTFUNK_RECOVER_SESSION_CMD as fallback), recorded in the persisted takeover state so a host crash still restores; without privilege the managed takeover degrades to ATTACH and mirrors the box's live Game Mode instead of destabilizing the seat. Both legs of the privileged cycle live-verified on the repro VM (headless managed session works with zero login sessions; render nodes are 0666). A loaded-but-inactive leftover instance never triggers the DM stop. Companion fixes from the same triage: - ensure_box_gamescope_mode gains the attach-only rebuild-probe guard both managed paths already had (stale post-capture-loss detection restarted the box's unit), and no longer re-modes a box that drives a physical display — attach mirrors on-glass; re-mode is the headless-box model. - Capture-loss rebuilds targeting gamescope get a 100 s budget: the 40 s budget expired inside the first 45 s Steam-cold-start launch attempt, a guaranteed single-shot failure. - A PUNKTFUNK_COMPOSITOR pin now WARNs once per capture loss when the live session no longer matches it (the pin disables session-following — the reporter's original stream-death trigger). - A managed session that took nothing over (client gamescope pin beside a live desktop) is stopped on disconnect instead of being orphaned forever. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 11:49:24 +02:00
enricobuehlerandClaude Fable 5	ac3dc4323f	fix(native/session): make the stop flag enforceable so a session can't outlive its client ... Native sessions could survive long after the client was gone, in two independent ways. HOST: `stop` was only advisory. The one thing that ends a session is the stream thread returning — every teardown (conn.close, the joins, and the RAII drops of the session permit, admission entry and stream marker) sits after that await, and nothing forced the issue. The encode loop checks `stop` between iterations, so any unbounded call INSIDE one never reaches the check, and one stuck syscall became a permanent zombie: it held its semaphore slot (four of those and the host stops accepting QUIC entirely), its admission entry (a later client gets "host busy" forever), and not even the console's Stop button could clear it — that button sets this same flag. * Bound the wait: once the session has been told to stop, the thread gets STREAM_STOP_GRACE (90 s, well past the 40 s capture-rebuild budget) to return, then teardown runs anyway. The thread is detached, not killed — Rust can't cancel a blocking thread — so it keeps its capturer/encoder until the stuck call returns, but the session's slot and admission entry come back and the host keeps serving. It logs at ERROR as the host wedge it is. * Bound the audio/input joins too — the last unbounded await in teardown. * Take the session permit AFTER the QUIC handshake instead of before `accept()`, so a host at its concurrency cap still accepts and the waiting client sees a live path instead of a silent dial timeout. * Bound the compositor helpers that caused the wedge in the first place: new pf-vdisplay `proc::{status_within, output_within}` kill a child that outlives its budget. `kscreen-doctor` is a Wayland client of the very compositor it configures, so against a wedged KWin it never returned; same for systemctl/dbus against a stuck session bus. CLIENTS: the connection was never closed, so the host was right to keep the session — it still had a live, keep-alive-answering peer. * Android: backgrounding did no teardown at all, and Android doesn't suspend the process, so the worker kept answering keep-alives until the OS reclaimed it (on a TV box, never). End the session on ON_STOP, via the existing onDispose path; a plain close, not a quit, so the host lingers the display for a fast return. * Apple: the .background arm was iOS-only AND gated on an opt-in that defaults off, so backgrounding did nothing — while the `audio` background mode kept the app (and its connection) alive indefinitely. Act unconditionally, and cover tvOS. * Core: `conn.close()` only queues the frame, and run_pump is the body of a block_on whose runtime is dropped the instant it returns, so the driver could never put it on the wire — a deliberate quit reached the host as silence (8 s idle timeout, no quit code, and the linger meant for an unwanted disconnect). Carry the endpoint out of the handshake and flush with wait_idle(), the same discipline the pairing and probe paths already use. Linux check/clippy/tests green: 262 host, 71 pf-vdisplay (incl. new bounded-process tests), 231 core. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 02:11:49 +02:00
enricobuehlerandClaude Opus 4.8	3a33a69401	fix(kwin): select the custom mode KWin actually built, not the one we asked for ... A KDE host streaming to a phone-shaped client fell back to 60 Hz even though the 120 Hz mode was sitting right there in KDE's display list, one manual click away. KWin generates every custom mode's timing with libxcvt, whose first step is `hdisplay_rnd = hdisplay - (hdisplay % 8)`. A 2868x1320@120 request (iPhone 16 Pro Max) therefore becomes 2864x1320@119.92 — 4 px narrower, fractional refresh. We then asked kscreen-doctor for `mode.2868x1320@120`; its `findMode` matches a mode's id or its own `WxH@qRound(Hz)` name, so that string matched nothing, the select silently no-op'd, the output stayed on its sacrificial birth mode, and `size_applied` came back false → "KWin rejected the custom mode" → 60 Hz. Widths like 1920/2560/3840 are all multiples of 8, which is why only clients with phone-shaped panels ever hit this. Resolve the mode out of the output's OWN list instead and address it by kscreen mode id: exact height, width at most one cell narrower than asked, refresh within 1 Hz (which excludes the native 60 Hz entry). `set_custom_refresh` now returns the whole achieved mode, and `create` reports that as the output's `preferred_mode` — so the capturer's renegotiation gate waits for the size KWin will actually deliver and the encoder opens against it, rather than starving on the requested one. Also skip `addCustomMode` when a usable mode is already installed: kscreen-doctor APPENDS to the list and KWin persists it per output name, so the old code grew the user's display list by one entry per connect. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 00:55:36 +02:00
enricobuehlerandClaude Opus 4.8	d5ae8dcc3e	feat(capture): gamescope cursor via XFixes shape + QueryPointer position (Phase C) ... gamescope excludes its pointer from the PipeWire node it feeds us and can't embed one either (`set_hw_cursor` is inert), so every gamescope stream was cursorless. Read the pointer from gamescope's nested Xwayland instead — XFixesGetCursorImage for shape/hotspot/visibility, core QueryPointer for position — and publish a CursorOverlay into the capturer's existing `cursor_live` slot, so the encoder blend composites it into the video exactly like the SPA_META_Cursor path. - pf-capture/src/linux/xfixes_cursor.rs (new): the XFixes reader. Connects to EVERY nested Xwayland (Gaming Mode runs one per --xwayland-count) and follows the focused one each tick (the display whose pointer moves), reading that display's own cursor shape. Un-premultiplies ARGB -> straight RGBA. Drop stops the thread. - Capturer::attach_gamescope_cursor + the PortalCapturer override spawn it into the same `cursor_live` slot; pf_vdisplay::gamescope_xwayland_cursor_targets discovers the (DISPLAY, XAUTHORITY) pairs via the GAMESCOPE_WAYLAND_DISPLAY scan. - host: SessionPlan.gamescope_cursor (set from the compositor at both resolve sites AND on a mid-stream Desktop->Gaming switch); the blend gate now builds the encoder blend for gamescope; a sibling composite arm attaches capturer.cursor() per tick for capture-mode clients (no channel needed). native NV12 is disabled for these sessions — that encode path can't blend the cursor (it assumes gamescope embeds the pointer), so we capture RGB and route to the proven CUDA VkSlotBlend / compute-CSC blend. - the pipewire thread no longer clobbers `cursor_live` with None on a buffer that carries no SPA_META_Cursor (gamescope) — that raced the XFixes writer and strobed the composited pointer on/off. On-glass (home-bazzite-2, RTX 5070 Ti, Gaming Mode): cursor visible + steady in Big Picture and CS2 menus, follows focus between the two Xwaylands, hidden in-game. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:47:53 +02:00
enricobuehlerandClaude Fable 5	925130d1f9	feat(vdisplay): compositor-embedded pointer for sessions without the cursor channel (Phase B) ... Since the cursor-channel work, every Linux virtual output was created in metadata pointer mode — making ALL sessions depend on host-side cursor compositing, including the ones that can never use the channel (Moonlight/ GameStream, legacy clients, capture-mode starts). Those sessions paid the blend bring-up per session and, whenever a visible cursor was composited, the loss of NVENC's stream-ordered submit — for a strictly worse cursor than the compositor's own. Mirror the Windows no-regression gate: the already-wired per-session set_hw_cursor(cursor_forward) now drives the Linux backends too. A cursor-channel session gets metadata (shapes forwarded, composite flip blends host-side — today's validated path, unchanged); every other session gets the pointer compositor-EMBEDDED at creation (KWin zkde pointer=2, Mutter cursor-mode=1, wlroots/hyprland portal CursorMode::Embedded — their pre-channel default; the portal pair also gains the Metadata arm for channel sessions, wired but untested on-glass). SessionPlan.cursor_blend narrows to cursor-forward sessions and rides into the direct-SDK NVENC open, which skips the Vulkan slot-blend bring-up entirely when off — embedded sessions ring on plain CUDA surfaces and pay zero cursor cost, per-session or per-frame. The keep-alive registry's reuse key grows the created pointer mode (new VirtualDisplay::hw_cursor getter): a kept embedded display has no cursor metadata for a channel session to forward, and a kept metadata display would leave a channel-less session with no pointer in its frames. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:47:53 +02:00
enricobuehlerandClaude Fable 5	af87549052	fix(linux/vdisplay): KWin virtual outputs stream above 60 Hz via sacrificial-birth renegotiation ... KWin's ScreenCastStream builds its PipeWire format offer — including the maxFramerate cap it actively throttles delivery to — ONCE at stream creation, when the virtual output sits at its hardcoded birth 60 Hz. A kscreen custom-mode change afterwards updates the OUTPUT (readback says 240) but never the offer, so every consumer negotiates max=60 and the stream delivers 60 (pw-dump-verified on KWin 6.6.4). The only path that rebuilds the offer is the stream's own resize handling: a source SIZE change while recording re-runs buildFormats — picking up the output's current refresh — and renegotiates the live stream. So above 60 Hz, birth the output at a sacrificial height (+16), then install + select the real WxH@hz custom mode: the first frame recorded after the consumer connects triggers KWin's resize path, which renegotiates the live stream to WxH@hz. The capturer holds (requeues) buffers until the negotiated size matches — new expect_exact_dims plumbing VirtualOutput → registry (fresh creates only) → open_virtual_output → a self-disarming gate in the process callback — bounded by a 3 s deadline that accepts the producer's dims rather than wedging the session into the first-frame retry loop. set_custom_refresh reads back the full active mode; a size reject (pre-6.6 KWin) recreates plain at the real size @60. Every kscreen operation now addresses the output by its NUMERIC id, resolved by matching the managed name-prefix AND the just-created birth size (newest id wins): a mode-switch supersede reuses the per-slot output NAME (deliberately, for KWin's per-name config persistence) while the superseded sibling is still alive, and name addressing hit the FIRST match = the OLD output — on-glass that resized the live session's display out from under it (wrong-res/black), read the old output back as 'mode applied', and set the old output primary while the replacement starved at its birth mode. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:47:53 +02:00
enricobuehlerandClaude Fable 5	afe120bf34	fix(linux/vdisplay): kwin virtual output ships the cursor as metadata too ... Same trap as the Mutter backend: zkde_screencast pointer mode 2 (embedded) never delivers SPA_META_Cursor, starving both the cursor channel and the encoder blend. Mode 4 (metadata) feeds both. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Fable 5	315ffaf144	fix(linux/vdisplay): mutter virtual monitor ships the cursor as SPA_META_Cursor ... RecordVirtual was created with cursor-mode EMBEDDED, which never delivers cursor metadata — the cursor channel had nothing to forward (client-drawn cursor invisible) and the always-built encoder blend had nothing to composite (host-drawn cursor invisible too). Metadata mode feeds both: non-forwarding sessions get the blended pointer (same pixels Mutter would have embedded), forwarding sessions strip the overlay and send shape/state. The capturer already negotiates the meta on every stream (meta_param). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Fable 5	35923080fb	fix(host/linux): scale degenerate-region absolute coords by the session's real output size ... The raw-client-pixels fallback is exact only while the managed session runs at the client's mode. When they diverge — foreign-gamescope attach at its own resolution, supersample/under-render, transitions — raw pixels drift or land out of range. The EIS relay file now carries the session's current output size as a second "WxH" line (from current_gamescope_output_size()); the injector scales normalized client positions into it, keeping raw pixels only as the last resort. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 10:53:14 +02:00
enricobuehlerandClaude Fable 5	2562663fc6	fix(host/linux): survive and self-heal dead gamescope sessions on headless SteamOS boxes ... Three fixes for the "most connects simply fail" trap on a SteamOS host with no physical display (VM testbox, panel-less mini PC): - restore path: skip the restore-to-physical-panel when no DRM connector reports a connected display — removing the headless drop-in and restarting gamescope-session.target on such a box just crash-loops gamescope and strands every later connect on "no usable compositor". Keep the headless session (and the takeover state) instead. - connect path: when no live graphical session exists but the MANAGED gamescope infra is present (SteamOS gamescope-session / Bazzite session-plus), route to the gamescope takeover — which rebuilds the session at the client's mode — instead of failing the connect. - error delivery: a session-setup failure used to just drop the QUIC connection, reaching the client as "control stream finished mid-frame" (indistinguishable from transport trouble). Close with a typed setup-failed code (0x68, RejectedSetupFailed = -29) carrying the error text, and give the client handshake/pairing error paths a short grace for the CONNECTION_CLOSE to beat the stream error it caused. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 09:50:30 +02:00
enricobuehlerandClaude Opus 4.8	58b27acbd5	fix(vdisplay/session): scrub the dead desktop's WAYLAND_DISPLAY from the user-manager env ... settle_desktop_portal pushes the live desktop's WAYLAND_DISPLAY into the systemd --user manager (import-environment) so a re-activated portal inherits the right session — but the import PERSISTS after that desktop dies. Every later user unit then inherits the stale socket, including gamescope-session.target: gamescope sees WAYLAND_DISPLAY, runs NESTED, and aborts with "Failed to connect to wayland socket: wayland-0" — observed live on a Deck, where Game Mode could not start at all (autologin crash-looped) until the var was unset by hand. Two-layer fix, mirroring the protection launch_session already gives its transient unit: - observe_session_instance: when a desktop compositor instance goes away, unset WAYLAND_DISPLAY/DISPLAY from the manager env (a desktop bounce is harmless — the next portal settle re-imports). - write_steamos_dropin: UnsetEnvironment=DISPLAY WAYLAND_DISPLAY on the takeover drop-in, unit-scoped belt-and-suspenders for host-initiated restarts. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-21 11:06:55 +02:00
enricobuehlerandClaude Opus 4.8	333c8979e9	fix(vdisplay/gamescope): capture-loss rebuild probes must not steal the box session ... Observed live on a Deck host: the user switched Game Mode → Desktop, KDE came up in 0.8 s — and the capture-loss rebuild's FIRST detection ran inside that gap, still said Gaming, and its gamescope re-acquire restarted gamescope-session.target. On SteamOS that steals the seat: the user was yanked out of the KDE session they had just chosen, the two session managers fought (job canceled / dependency failed), no gamescope node appeared within 30 s, and the stream died at the 40 s rebuild budget. A rebuild probe acting on possibly-stale detection must never stop, relaunch, or take over box sessions. New pf_vdisplay::rebuild_probe_scope (RAII, counted): while held, the gamescope managed/takeover create paths only attach to a live node and fail fast otherwise — no stop_autologin_sessions, no session-plus relaunch, no gamescope-session.target restart. The capture-loss loop holds it for the first 4 s after a loss (the detection-ambiguity window); after that, destructive rebuilds are allowed again, so a genuine switch INTO Game Mode still gets its headless takeover. Probe failures are instant, so the loop now paces itself at ~2 Hz instead of spinning. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-21 11:00:02 +02:00
enricobuehlerandClaude Opus 4.8	b89dbfa979	feat(gamescope): end dedicated stream on Steam game exit + auto --steam ... Dedicated single-game sessions now end cleanly when the launched game quits, and Steam launches get gamescope's Steam integration without an operator env knob. End-on-exit: the existing APP_EXITED close only fired when gamescope's PipeWire node vanished, which never happens for Steam — the nested `steam` is the resident singleton client and stays up after a game quits, so gamescope (and its node) never die and the stream sat on a hidden Steam session forever. Add a Steam AppId reaper watcher (pf-vdisplay .../gamescope/discovery.rs): steam_appid_from_launch() parses steam://rungameid/<id>; wait_for_steam_game_exit() waits for the game to start (<=300s grace) then exit (3s confirm); steam_game_running() scans same-uid /proc for Steam's launch reaper matching both the `SteamLaunch` and `AppId=<id>` argv tokens (exact-match; reaper lifetime == game lifetime, so shader precompile can't false-trigger). The host spawns a pf1-gamewatch thread for nested Steam launches that closes the connection with APP_EXITED (launcher clients return to their library) and sets quit/stop; cancelled via stop if the session ends first. Non-Steam nested launches keep the node-death path (gamescope's child IS the game). Flags: auto-enable `--steam` whenever the launch is a Steam launch (was only the global PUNKTFUNK_GAMESCOPE_STEAM knob, default-off) — in-game overlay / Steam+X / gamepad-UI nav for Steam titles with no operator config. New opt-in PUNKTFUNK_GAMESCOPE_GRAB_CURSOR adds `--force-grab-cursor` for a real game launch (FPS mouselook); default OFF because it forces relative mode, which breaks absolute-pointer games/menus. Verified: fmt clean; clippy -D warnings clean on the three crates; pf-vdisplay 64/0 (incl. new steam-appid parse test); punktfunk-host builds + 186/0; reaper /proc detection smoke-tested (detect, exact non-match, gone-after-exit). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 16:24:34 +02:00
enricobuehlerandClaude Opus 4.8	86d9f49473	style(pf-vdisplay): rustfmt under the pinned 1.96.0 toolchain ... The W6.2 pf-vdisplay extraction (27a5d8da) committed six spots that the pinned rustfmt (rust-toolchain.toml = 1.96.0) reformats — a short closure collapse and chain-call wrapping. No semantic change; makes cargo fmt --all --check green so the combined push does not land CI red on pre-existing format drift. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 15:38:12 +02:00
enricobuehlerandClaude Opus 4.8	27a5d8daac	refactor(host/W6.2): extract virtual-display orchestration into the pf-vdisplay crate ... vdisplay.rs + vdisplay/* (the per-compositor Linux backends — KWin zkde-screencast, wlroots swaymsg, Mutter RemoteDesktop, Hyprland — and the Windows IddCx/pf-vdisplay driver backend, behind one VirtualDisplay trait; the mode-conflict admission registry, the display policy/identity/custom-preset state, and the session-env / gamescope routing) move into crates/pf-vdisplay (plan §W6). The DDC/CI panel-power control (used only here) and the KWin zkde protocol XML move with it. This completes the host-crate decomposition: capture, encode, inject, and vdisplay are now four subsystem crates over the shared leaves, and punktfunk-host is the orchestrator (serve/supervisor + native + gamestream + mgmt). Coupling breaks (all down-only, cargo-tree acyclic): - capture::dxgi identity -> pf_frame::dxgi; win_display/monitor_devnode/ console_session_mismatch -> pf-win-display leaf; can_open_another_session -> pf-encode (the NVENC session-budget admission gate — acyclic peer edge). - The registry's DisplayCreated/DisplayReleased emits into the host SSE event bus invert to a leaf hook: pf-vdisplay emits a neutral DisplayEvent to a host-registered DISPLAY_EVENT_SINK, so it never reaches the orchestrator's events module. - The IddCx driver module is renamed pf_vdisplay -> driver (its old name collided with the crate name through the host's `mod vdisplay` shim glob). The host keeps `mod vdisplay { pub use pf_vdisplay::* }` so every crate::vdisplay::* path (serve/mgmt/native/the capture FrameChannelSender seam) is unchanged; the heavy deps (wayland/ashpd/tokio + the zkde protocol) moved with the crate. Co-authored: a fail-closed IOCTL-reply-length security fix (reject short/zeroed pf-vdisplay driver replies before trusting protocol_version/target_id/wudf_pid/luid, security-review 2026-07-17) rides this commit in the moved driver module. Verified: Linux clippy -D warnings (pf-vdisplay + host nvenc,vulkan-encode,pyrowave --all-targets) + pf-vdisplay 63/63 + host 167/167 tests; Windows clippy -D warnings (pf-vdisplay --all-targets + host nvenc,amf-qsv --all-targets) Finished exit 0. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 12:14:08 +02:00