1640 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	fcf4c9fd63	fix(mgmt): unpair now revokes a LIVE session on both planes ... An unpair removed the certificate but left the revoked client's running session streaming until the client chose to leave. Now it is a complete revocation: - GameStream: when the removed certificate owns the active launch, the session is quit_session'd — the ENet control thread's ended-session arm gives the client the standard TERMINATION+disconnect. (An owner-less launch cannot be attributed and is left to the WP0 port teardown when the last pairing goes.) The endpoint docstring's long-standing caveat ('removes the client from the listing without severing its ability to reconnect') is retired: TLS handshakes complete by design, authorization is per-request, and a live session no longer survives its own revocation. - Native: session_status::stop_by_fingerprint signals the unpaired client's live session(s) to tear down deliberately (quit+stop), matched by the registry's client label — the fingerprint's 12-hex-char prefix for every pairable client; anonymous/TOFU sessions carry IP labels and are never touched (they have no pairing to revoke). (The unpair-didn't-PERSIST half of 'unpairing was broken' was already fixed in 13d57210 — save_paired was never called; this closes the other half.) Gates: Linux amd64 both flavors clippy --all-targets -D warnings clean; session_status 2/2 (new revocation test), the extended paired-clients test green in both flavors, native_pairing test green.	2026-08-11 22:17:41 +02:00
enricobuehler	9c6e06d3b9	feat(host): GameStream is now a cargo feature — WP19, compile-time isolation ... A new 'gamestream' feature (default ON — every stock package is behaviorally identical, and GameStream stays runtime-opt-in via --gamestream / PUNKTFUNK_GAMESTREAM) gates the whole Moonlight-protocol surface: control (the ENet plane), rtsp, nvhttp, pairing, serverinfo, the _nvstream mDNS advert, the compat media path (stream/video/audio), pen/gamepad/input decode, apps, crypto, cert (the RSA identity), and tls's Moonlight-client-cert leniency. AppState keeps the shared vocabulary unconditional and cfg-gates the Moonlight-only fields; the mgmt API's PIN endpoints (routes, handlers, OpenAPI entries, lane classifications, tests) exist only under the feature. Building --no-default-features --features pyrowave yields the hardened NATIVE-ONLY host: no rusty_enet (the c2rust-transpiled C ENet stack, 158 unsafe sites) and no rsa (the identity split's legacy fallback became a pem-only read — rustls/ring serves an existing RSA cert without the crate — so the accepted Marvin advisory no longer applies to native-only builds). Both claims are ASSERTED, not assumed: a new CI leg keeps the native-only flavor clippy-clean and fails if cargo tree finds either crate in its graph. serve --gamestream (or the env knob) against such a binary refuses to start with a clear error rather than serving less than the operator configured. En route: the logs-paging test assumed a quiet process-global log ring between its cursors and raced other tests' legitimate log lines (the identity tests added new emitters) — it now asserts on its own markers within the page. Gates: Linux amd64 — BOTH flavors clippy --all-targets -D warnings clean; default tests identity 3/3, mgmt 37/37, gamestream 59/59; native-only tests identity 3/3, mgmt 35/35, residue 4/4; rusty_enet+rsa absent native-only, present default. .133 Windows — both flavors clippy clean (clean-first, sentinel-checked), tree claims hold, and the WP0 port-lifecycle functional gate PASSES on the default build.	2026-08-11 22:05:30 +02:00
enricobuehler	e658ad726b	feat(host): the identity split — the native planes get their own P-256 identity ... One RSA-2048 identity served every plane, because Moonlight mandates RSA and the planes grew out of the GameStream host. The native punktfunk/1 QUIC plane and the management API now share a separate ECDSA P-256 identity (native-cert.pem/native-key.pem, src/identity.rs): ring-generated via rcgen (no rsa crate on the native path — the accepted Marvin advisory stops applying once WP19 gates the compat planes), real SANs (localhost, loopback, machine hostname — the legacy cert had none), and browser-compatible on purpose: Ed25519 was rejected because no mainstream browser accepts an Ed25519 server cert and /api/docs is opened in one. GameStream keeps the RSA identity untouched (Moonlight pins it; its pairing hashes bind its X.509 signature bytes). Migration is pin-preserving by construction. Clients TOFU-pin ONE leaf-DER SHA-256 for both QUIC and the mgmt/library API, so the identity is resolved ONCE in serve (the planes cannot race the first-run mint) under the rule: identity files exist → use them; else the native trust store is EMPTY → mint P-256 (fresh installs); else keep presenting the legacy RSA cert the paired clients pinned, and log the migration path (unpair all, restart, re-pair). Fingerprint pinning is algorithm-agnostic — existing shipped clients pair against P-256 hosts unchanged. Followers updated: the tray's loopback pin and the plugin SDK's mgmt CA prefer native-cert.pem → cert.pem; the Windows runner ACL grant lists both (the grant loop tolerates absent files). The in-process native tests now run on an EPHEMERAL identity — they previously read, and would newly have MINTED, identity files in the real config dir, which on a dev box that is also a live host would have switched its identity and stranded every pinned client. Gates: Linux amd64 clippy --all-targets -D warnings clean (host+tray); identity 2/2, mgmt 37/37, control 6/6, native 68/68 (C-ABI roundtrips over the ephemeral identity). .133 Windows clippy clean; the port-lifecycle gate re-run PASSES with the split live — the fresh host minted P-256 and served mgmt over it (curl 200/204), ports tracked the paired list as before.	2026-08-11 20:52:01 +02:00
enricobuehler	23d0452157	feat(host): GameStream opt-in on every route; the native plane is deny(unsafe_code)-enforced ... The user direction after WP0: ENet exists only for Moonlight, so the native plane must be provably safe and the compat planes a deliberate choice. Opt-in, everywhere. Windows already was (unchecked installer task). The three opt-out surfaces are flipped: the shipped systemd user unit (deb/RPM/Arch/ sysext) no longer bakes --gamestream into ExecStart — a new PUNKTFUNK_GAMESTREAM=1 host.env knob (pf-host-config, OR-ed with the CLI flag) is the packaged opt-in; the NixOS module default goes true→false, with a module-check assertion that unset = native-only; the Deck installer takes --gamestream to opt in (--no-gamestream kept as explicit-off). Docs (quickstart, running-as-a-service, moonlight, ubuntu/fedora/arch firewall sections, gnome/sway, how-it-works) rewritten to the opt-in shape; the CHANGELOG carries the upgrade note. Enforced-safe. punktfunk-core is #![deny(unsafe_code)] crate-wide — every module that parses network bytes is safe Rust as a compile error, not a census result. Carve-outs are exactly two documented classes, neither of which interprets attacker bytes: the client surface (abi, client) and the transport syscall-batching shims (udp/{apple,linux,windows}, qos_windows). In punktfunk-host, the modules a secure-default host exposes — native (cfg-not-test: its tests exercise the client C ABI on purpose), native_pairing, mgmt, mgmt_token, discovery, wol — are #[forbid(unsafe_code)]. Gates: Linux amd64 container clippy --all-targets -D warnings clean over core+host-config+host; core 204 tests green under the deny; mgmt 46/46, control 6/6. .133 Windows clippy (shipped features, clean-first, sentinel-checked) clean — covers the qos_windows/udp-windows carve-outs. macOS + iOS cargo check green (the apple.rs carve-out compiles for real).	2026-08-11 20:21:16 +02:00
enricobuehler	13d5721049	feat(gamestream): the ENet control port exists only while a pairing does (WP0) ... rusty_enet — a c2rust-style transpile of C ENet, 158 unsafe sites — parsed unauthenticated UDP on 47999 from GameStream startup, before any client had ever paired: the host's entire pre-auth-reachable unsafe surface. Pairing itself is HTTPS on nvhttp and never touches the port, so it now binds only while the paired-client list is non-empty: a Gate in control.rs reconciles the port to the list (armed only under --gamestream), pairing phase 4 brings it up before the new client can /launch, and removing the last pairing tears it down — a live client gets the same termination+disconnect farewell as a host-side session end. A never-paired host on a hostile LAN exposes no ENet. En route: the management API's unpair never called save_paired, so a restart resurrected the client — and would now have silently re-opened the port; it persists (the test now runs against a throwaway PUNKTFUNK_CONFIG_DIR so it can't clobber a real paired.json). rusty_enet is pinned =0.4.0 per the WP, left to the cargo-audit job to flag advisories against it. Gate (amd64 container): clippy --all-targets -D warnings clean; gamestream::control 6/6; mgmt::tests 37/37 incl. the regenerated api/openapi.json. On-box .133 verification (ports/pair/stream) still owed.	2026-08-11 19:29:50 +02:00
enricobuehler	d4366e7464	fix(pf-encode): the Vulkan extension probe walked a driver-filled array with no bound ... `ext_advertised` did `CStr::from_ptr(e.extension_name.as_ptr())` over a driver-filled `[c_char; VK_MAX_EXTENSION_NAME_SIZE]`, and `vk_build.rs` open-coded the identical call a second time. Neither had an in-Rust bound: a driver that fills all 256 bytes without a NUL runs the walk into the NEXT `ExtensionProperties`, and on the LAST element past the allocation. The SAFETY comment asserted the spec guarantee ("a spec-guaranteed NUL-terminated byte array") instead of enforcing it. That is the defect class this programme keeps finding: a proof that restates what the other side promised rather than checking it. Vulkan drivers are exactly the other side. The bounded answer already shipped in the same crate — `pyrowave.rs:210` uses ash's `extension_name_as_c_str()` for the identical job. It stops at VK_MAX_EXTENSION_NAME_SIZE and returns Err when there is no terminator, so a malformed entry is a non-match instead of an overrun. Both sites now route through the one helper, which is no longer unsafe at all. Deletes 2 unsafe operations and one duplicated walk. ⚠ The pre-existing test could not have caught this: it only ever built well-formed, NUL-terminated entries. Added a case whose LAST element is 256 non-NUL bytes — the exact shape that used to leave the array — and a prefix-match case, so the bound is now asserted rather than assumed. Verified on 192.168.1.25 (Ubuntu, cargo 1.96.0 — the pinned toolchain): cargo check -p pf-encode --features vulkan-encode,pyrowave --locked ok cargo test -p pf-encode --features vulkan-encode,pyrowave ext_advertised 2 passed / 0 failed cargo clippy -p pf-encode --all-targets --locked --features vulkan-encode,pyrowave -- -D warnings clean Linux-only code (`enc/linux/`), so the Windows leg is unaffected.	2026-08-11 16:34:34 +02:00
enricobuehler	cd72f77a3c	fix(pf-encode): the AMF layout guards broke Windows clippy — 0*SLOT and 1*SLOT ... `27f08340` wrote every vtable offset assertion as `offset_of!(T, f) == N * SLOT` so the slot INDEX stays visible in the assertion. For N=0 and N=1 that is `0 * SLOT` and `1 * SLOT`, which clippy rejects as `erasing_op` and `identity_op` — six errors, and windows-host.yml runs clippy with `-D warnings`, so the branch as pushed would have turned the Windows leg red. This is the blind spot the programme document names in §1.5, demonstrated on the programme's own first code commit: 44% of the host's unsafe is `#[cfg(windows)]`, no Linux or macOS check compiles it, and `cargo fmt`/`cargo check` on a Mac are all clean. Only the .133 gate sees it. Fixed with a `const fn slot(i: usize) -> usize` rather than by writing the two offending cases as bare `0` and `SLOT`: that would have made those two the only assertions where the slot index is invisible, and the index is the entire point. Also records the cheap local gate that would have caught this without a Windows round-trip: `amf_sys.rs` depends on nothing but `c_void`, so copying it into a throwaway one-file crate and running `cargo clippy -- -D warnings` reproduces the exact error on any host. Verified by reintroducing `0 * SLOT` and watching the harness fail with the same message the runner gave. Verified on 192.168.1.133 (Windows CI runner, the box with the WDK), after a `cargo clean -p pf-encode` that reported `Removed 47 files, 135.5MiB` so the recompile is real and not a cached green: cargo check -p pf-encode ok cargo check -p pf-encode --all-targets --features nvenc,amf-qsv,qsv ok cargo clippy -p pf-encode --all-targets --features nvenc,amf-qsv,qsv -- -D warnings exit 0 (was 101) cargo clippy -p punktfunk-host --features nvenc,amf-qsv,qsv -- -D warnings exit 0 (was 101) The gate also greps the extracted tree for the assertions before building, so a stale upload cannot produce a passing run.	2026-08-11 16:28:59 +02:00
enricobuehler	cd3f5474bf	fix(pf-driver-proto): a layout test read an align-8 struct out of an align-1 buffer ... `control_structs_roundtrip_through_bytes` built the legacy-size wire form in a stack `let mut legacy = [0u8; 40]` (align 1) and then called `bytemuck::from_bytes::<control::AddRequest>`. `AddRequest` opens with `session_id: u64`, so it is align 8, and `from_bytes` hands back a REFERENCE into the buffer — it panics unless the buffer happens to be 8-aligned. A stack `[u8; 40]` usually is, which is why this passed on every machine and every CI leg since it was written. Under Miri it fails outright: Miri does not let an accidentally-favourable stack slot stand in for a guarantee. Switched to `pod_read_unaligned`, which reads by value and has no alignment precondition. That is not a new idea here — `ChannelProof::parse` at lib.rs:1013 already carries a comment saying "`pod_read_unaligned`, NOT `from_bytes`" for exactly this reason. This site is the only other one in the crate that reads a POD out of a stack byte array; every other `from_bytes` call in the tests reads from `bytes_of(&x)`, which is aligned by construction. Test-only, so no shipped defect — but the crate is `#![forbid(unsafe_code)]` and is path-dep'd by BOTH the main workspace and the driver workspace, so it is the layout oracle for every frame and IOCTL that crosses that boundary. A test that cannot be trusted to fail is worth fixing there more than anywhere else. Found by the first Miri run ever performed against this repo. Verified on 192.168.1.25 (Ubuntu, cargo 1.96.0): cargo +nightly miri test -p pf-driver-proto 21/21 cargo +nightly miri test -p pf-driver-proto --target x86_64-pc-windows-msvc 21/21 cargo test -p pf-driver-proto --locked ok cargo clippy -p pf-driver-proto --all-targets --locked -- -D warnings clean The cross-target run is the interesting one: it interprets the crate at MSVC layout on a Linux box with no Windows anywhere. Nothing else in CI does that.	2026-08-11 13:57:34 +02:00
enricobuehler	972af2992f	fix(pf-capture): the gamescope cursor fallback rewrote environ under a live multithreaded host ... `connect_via_env_swap` did set_var("XAUTHORITY", …) / connect / restore, guarded by a mutex that serialised this source against itself and against nothing else. `getenv` takes no lock. setenv/unsetenv rewrite the process-global `environ`, and glibc REALLOCATES that array when a variable is added — while, at that exact moment, the PipeWire thread is inside pw_init()'s dlopen making bare getenv() calls and EGL/CUDA init is running alongside. The file's own doc already called the pattern "unsound from a live multithreaded host"; it stayed as a fallback. Three things made it worse than the comment suggested: - The damaging branch is the one where XAUTHORITY is ABSENT and therefore gets ADDED (the realloc case). scripts/punktfunk-host.service deliberately does not import the login shell's environment, so absent is the DOCUMENTED NORMAL configuration for the shipped unit, not an edge case. - `rediscover` re-runs this every 2 s for the whole session. A display whose connect fails is never pushed into `displays`, so the dead-display skip never covers it — the race is not once at startup, it repeats forever. - It is unfixable in place. Sharing pf_vdisplay's ENV_LOCK is the wrong layer: it cannot make C `getenv` take a lock. The fix is to stop writing `environ` at all. Connecting with an explicitly empty auth token is what the swap actually achieved: we only reach the fallback when our own lookup found no usable MIT-MAGIC-COOKIE-1 entry, and x11rb's internal lookup reads the same file with a STRICTER matcher (it matches family/address too, which we deliberately do not), so where we find nothing it finds nothing either and connects unauthenticated. That is exactly why the swap "worked" against a nested Xwayland started without -auth. Gives up one case: an .Xauthority using an auth family we decline to guess at but x11rb would have handled. A gamescope Xwayland writes a single-entry MIT-MAGIC-COOKIE-1 file, so it is not reachable here, and declining to attach a cursor overlay beats tearing `environ` out from under a live session. Also removes XAUTH_LOCK, whose only user this was. Verified on 192.168.1.25 (Ubuntu, cargo 1.96.0 — the pinned toolchain, pipewire dev headers present): `cargo check -p pf-capture --locked` and `cargo clippy -p pf-capture --all-targets --locked -- -D warnings` both clean. Not verified on glass: the fallback is only reached when the cookie parse fails, so a normal gamescope session does not enter it. Forcing it needs a nested Xwayland started without -auth, or a mangled cookie file, on .181/.136.	2026-08-11 13:54:56 +02:00
enricobuehler	df6f270e7b	chore(safety): forbid unsafe on the crates that are already at zero ... Five permanent ratchets, all free today — the point is that they cannot regress tomorrow. Each crate was re-measured at the commit, not taken from a survey. `forbid(unsafe_code)`: punktfunk-encode-worker the binary that carries cap_sys_nice. Its header claims "no Wayland, no D-Bus, no network, no plugins"; this makes the memory-safety half of that claim mechanical. `forbid`, not `deny`, so it cannot be re-opened by an #[allow] further down. pf-update-check parses a signed, network-fetched manifest and its own header says it "owns the part where being wrong is a security bug". Signature checking is worthless if the parser around it can be walked out of bounds. pf-vaadec its header states the design constraint outright — it links no libva and compiles on macOS, "which is the point". The crate is full of hand-declared libva repr(C) mirrors; one raw deref and it stops being the CPU-testable half. tools/cursor-probe free, and a probe is where "just deref it to see" is most tempting. `deny(unsafe_code)` + one localized allow: pf-update root runs this. Its single unsafe operation, a bare geteuid, moves into a named `effective_uid()` helper carrying the crate's one #[allow(unsafe_code)]. Deliberately NOT rewritten to rustix, contrary to the programme document's first draft: pf-update's Cargo.toml states that its zero-dependency posture IS a security invariant of a root helper ("no HTTP client, no TLS, no argument parsing"), and the extern block says the same. Pulling a general-purpose syscall crate into a root helper to delete one `unsafe` would trade a real property for a cosmetic one. The localized allow keeps the ratchet: any NEW unsafe anywhere in the crate is a build error. Verified: `cargo check -p pf-vaadec -p pf-update-check` and `cargo check -p pf-update -p cursor-probe` clean on macOS, plus `cargo check -p pf-update --target x86_64-unknown-linux-gnu` — pf-update's whole body is behind `cfg(target_os = "linux")`, so the macOS check does not reach the line that changed. punktfunk-encode-worker is not built here (pf-encode's C dependencies do not cross-compile from macOS) and needs the Linux CI leg.	2026-08-11 13:49:41 +02:00
enricobuehler	27f0834025	fix(pf-encode): const-assert the AMF vtable and POD layouts ... amf_sys.rs mirrors five AMF COM vtables by hand and amf.rs dispatches through them BY SLOT POSITION — 18 distinct slots across the five tables. The mirrors carried 118 `Slot` placeholders whose only job is to hold the following slots at their C offsets, and not one layout assertion of any kind. A slot inserted, removed or reordered in an AMF header bump calls an arbitrary function pointer through a mismatched signature: no compile error, no runtime signal. `AMF_MIN_VERSION` does not defend against this. It checks a version NUMBER, not a layout, and it is a floor with no ceiling. The three POD checks that did exist (`AmfVariant`, `AmfGuid`, `AmfHdrMetadata`) lived in amf.rs's `#[cfg(test)]` module, so they were verified only when someone ran pf-encode's tests, on Windows, with AMF enabled — and NEVER in a release build, which is exactly where a mis-mirrored `AMFVariantStruct` does its damage: it crosses the FFI BY VALUE on every SetProperty. This is the same hole `a8dd348b` closed for the cuda.h mirrors and missed here. Adds ~40 `const _: () = assert!(...)` guards next to the mirrors: size of each of the five vtables, the byte offset of every slot amf.rs actually calls, the three POD layouts promoted out of the test module, and the AMFData/AMFBuffer shared-prefix agreement that `create_surface_from_dx11_native`'s AMFSurface-through-AMFData reinterpretation silently depends on. Verified by compiling amf_sys.rs standalone (it needs only `c_void`, and a repr(C) struct of code pointers has the same layout on any 64-bit target, so a macOS const-eval proves the Windows arithmetic), and by deliberately breaking one offset to confirm the guard actually fires rather than silently passing. That check earned its keep immediately: `alloc_buffer` sits at slot 43, not 42. Counting AMFInterface(3) + AMFPropertyStorage(10) + the AMFContext block by hand is exactly the error these assertions exist to catch. Zero runtime behaviour change. The `AMF_MIN_VERSION` ceiling is deliberately NOT part of this commit: a ceiling would make the next AMF driver release refuse encode on every AMD box, so it needs a warn-and-continue policy plus an env override and a real AMF session to gate it.	2026-08-11 13:49:25 +02:00
enricobuehler	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	8b98d0b3ec	fix(pf-capture): a sweep found nine real defects behind comments that asserted the opposite ... Reviewed the whole crate (15.6 kloc) for bugs, safety, structure and comment truth. Both compile gates are green: `scripts/xcheck.sh windows clippy` and `cargo clippy -p pf-capture --all-targets --locked -- -D warnings` in the amd64 CI image (the Linux half needs libpipewire, so it cannot ride xcheck). Code defects, each one contradicted by a comment sitting next to it: * `pipeline_depth` clamped to `OUT_RING` (3) while both `repeat_last` and `OUT_RING` state the safe maximum is 2. `d` frames in flight need `d + 1` textures, so `PUNKTFUNK_IDD_DEPTH=3` rotated onto the slot NVENC was still reading and the convert overwrote it in place — torn frames, silently. Now `OUT_RING - 1`. * The GDI cursor poller published `visible: true` for a NULL `hCursor` carrying `CURSOR_SHOWING` — how an app hides the pointer for its own window. The last rasterised arrow was then blended into a game that had hidden its cursor. Every rasterise gate already tested `handle != 0`; the published verdict now agrees. * The ETW event callback did `RING.lock().unwrap()`. That is an `extern "system"` fn, so a poisoned lock panicked across an FFI boundary and ABORTED the host — a diagnostic taking down capture. Poison-tolerant now, which also makes the poison unreachable. * `ChannelBroker::send` bounded the ring with `debug_assert`, so a release build instead panicked mid-`duplicate_and_deliver`, unwinding past the reap and leaking every handle already planted in the driver's WUDFHost. Refuses before the first duplication. * `set_active(false)` did not clear `stall_since`, so a pooled capturer carried a stale stall clock into its next stream and reported capture loss microseconds in. * `attach_gamescope_cursor` evaluated `spawn` before dropping the old source: two readers published into one slot, and a failed spawn destroyed a working reader. Idempotent now. * `PUNKTFUNK_FORCE_SHM` used a bare `== "1"` compare, silently ignoring `=true`/`=on`. * `spa_meta_bitmap.offset == 0` is SPA's "no image data" signal, distinct from the `bitmap_offset == 0` position-only case. Unhandled, it decoded the header's own words as cursor pixels and cached them. * A `VideoInfoRaw::parse` failure was swallowed, so a malformed Format pod surfaced as the generic "no acceptable format" timeout. It is logged, and parsed once, not twice. Comment corrections, all verified against the code they describe: four claims that a failed open falls back to DDA (removed — the caller drops the keepalive under "no fallback"); three comparisons to the removed WGC path; "we do NOT gate HDR on the client's VIDEO_CAP_10BIT" (it does, in three places); the P010 sampler's "4 explicit taps / 2x2 box" (two taps, left-cosited — the box was the bug it replaced); the cursor meta cap quoted as 256x256 (1024, and 256 is the value that cost the whole Linux cursor channel on-glass); the poller's "~60 Hz" (4 ms, ~250 Hz); "several minutes of coverage" (~26 s); "8 frames in 400 ms >= 20 fps" (7 intervals, so 17.5); three "process-wide" HDR latch claims (per-source, which is why HdrSource exists); a SAFETY proof claiming a view is "unmapped never" (Drop unmaps it); the Linux module header describing a bounded channel and BGRx-only frames (one-deep overwriting slot, several formats); and a doc line stranded on `DisplayDescriptor` by an earlier split, restored to `IddPushCapturer`, which had none.	2026-08-11 10:04:58 +02:00
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	d715225960	Merge pull request 'Launcher tiles get their launcher's logo — a brand token on the wire, the vector in every client' (#162) from worktree-launcher-icons into main ... Reviewed-on: #162	2026-08-11 04:58:36 +00:00
enricobuehler	f62a48d4a9	feat(library): launcher tiles get their launcher's logo — a brand token on the wire, the vector in every client ... A launcher tile (role: "launcher", design D4) shipped no art on purpose: a launcher's own icon is square, every client cover-crops a 2:3 poster, and the crop turns a mark into a strip. So the tiles were the launcher's name on a flat accent face — legible, and the blandest thing in the grid. Entries now carry an optional `icon`: the NAME of a brand mark, never image bytes and never a URL. `[a-z][a-z0-9-]{0,31}`, shape-validated by the host on every lane (a client interpolates the value into a resource name or an asset lookup, so the guard belongs upstream of all of them, and each client re-checks rather than trusting the peer). A token rather than art because the alternative is closed by construction, and deliberately: the art proxy serves what the bytes ARE (sniff_image_type) and SVG is not on that list — it is script-capable XML and the console renders library art in a browser. Widening that sniff would trade a rendering nicety for a stored-XSS surface. Naming the mark keeps the refusal intact, keeps the glyph vector at whatever size a tile happens to be, lets it take the tile's ink, and adds nothing to a reconcile payload that is already body-limited. The cost is that a third-party plugin cannot ship a mark no client bundles; its tile falls back to the launcher's name, exactly as before, and the fix is a PR adding the master. assets/launcher-icons/ holds seven monochrome masters with per-mark provenance and licensing (Simple Icons CC0: lutris, heroic, epic, gog; Font Awesome CC BY: steam, xbox; Playnite's own logo, MIT). steam is generated FROM assets/os-icons/steam.svg so the SteamOS host badge and the Steam launcher tile can never drift. scripts/gen-launcher-icons.sh bakes the three derivatives that cannot consume a master (GTK symbolic SVG, Windows PNG, Apple template PDF) and — unlike gen-os-icons.sh, which prints path data for a human to paste — GENERATES the three inline registries (web console, Android ImageVector, pf-console-ui Skia). Three clients x seven paths of up to 3 kB is a transcription error waiting to happen, and a mangled character is a silently wrong logo rather than a build failure. The generated Rust goes through rustfmt, since `cargo fmt --all --check` is a CI gate and a generated file that fails it would fail every regeneration. All six renderers draw the mark CONTAINED, never cover-cropped: the masters' viewports are not square (steam 496x512, playnite 1024x1024) and filling a 2:3 frame would reproduce the strip this exists to avoid. Every one keeps its old fallback for a token it has no art for. Epic, GOG and Xbox marks ship dormant. Those plugins' launcher switches are off by default and emit nothing, because the host has no verified launcher_ui activation for them yet — shipping the art now keeps turning one on the one-line plugin change those plugins promise, instead of also needing a release of all six clients. api/openapi.json and the SDK are regenerated (the spec's version field was stale at 0.25.0 and now reads 0.26.0, which is the crate's actual version — an unrelated line that regeneration necessarily corrects). Verified: host cargo check, clippy -D warnings across pf-client-core / pf-console-ui / punktfunk-client-session / punktfunk-client-linux, plain build, pf-console-ui tests (77, including a new one asserting all seven masters parse under Skia and one asserting the letterbox stays inside its box), pf-client-core tests (188), cargo fmt --all --check, Apple swift build, Android compileDebugKotlin, web tsc + vite build, plugin-kit tsc, biome. The Windows client is NOT compile-verified — it cannot be built from a Mac (scripts/xcheck.sh covers only the capture stack by design) and CI does not build it either; its tile change needs a real box before it ships.	2026-08-10 23:26:47 +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	7a8f63e906	Merge pull request 'The console UI answers the iPad field test — and the screen that would never open again was a UIKit read mid-render' (#154) from worktree-apple-gamepad-relanded into main ... Reviewed-on: #154	2026-08-10 10:51:03 +00:00
enricobuehler	35b5ee6a36	Merge pull request 'punktfunk-encode-worker: GPU priority via a capability-carrying worker, with WP3 on-glass complete' (#153) from worktree-worktree-encode-worker into main ... Reviewed-on: #153	2026-08-10 10:45:23 +00:00
enricobuehler	84faeb1bf1	docs(pf-encode): Linux Main10 is live — the 'inert until Phase 5.1' comment outlived the code ... The bit_depth field said '8 on Linux until Phase 5.1 lands a P010 capture path'. The code outran it: the gamescope HDR capture patches offer 10-bit BT.2020/PQ, nvenc_fmt maps X2Rgb10/X2Bgr10 to ARGB10/ABGR10, and is_ten_bit_input flips bit_depth and hdr from the negotiated input. Verified on home-nobara-1: 'resolved session plan ... bit_depth: 10, hdr: true' on the direct backend. A 10-bit frame deliberately takes neither the NV12 nor the YUV444 convert (both compute CSCs write 8-bit planes) and rides packed RGB to the encoder, which does its own BT.2020 CSC — pf-capture/src/linux/pipewire.rs owns that gate. So Main10 needed no P010 path to arrive, and P010 is now a perf follow-up (skip NVENC's internal CSC, as NV12 does for SDR), not the thing that makes 10-bit work.	2026-08-10 12:39:46 +02:00
enricobuehler	ad63994cb9	fix(pf-encode): the 10-bit probe was the last ffmpeg NVENC open on a direct-SDK host ... `can_encode_10bit`'s Linux NVIDIA arm answered "can this GPU encode 10-bit?" by opening an ffmpeg `hevc_nvenc` encoder. On a host that then streams over the direct SDK, that is the LOG-3 field bug: one ffmpeg NVENC open in a direct-SDK process wedges every later open process-wide with `NV_ENC_ERR_INVALID_VERSION` until the host restarts. `can_encode_444` was moved off the ffmpeg probe for exactly this reason on 2026-07-27. The 10-bit one was deliberately left behind, on the reading that "Linux HDR genuinely rides the libav P010 path". `open_video` contradicts that: if cuda && nvenc_direct_enabled() { // no 10-bit exclusion … NvencCudaEncoder::open(…, bit_depth, …) A CUDA capture goes to the direct backend at whatever depth was resolved, and `is_ten_bit_input` already accepts the packed 10-bit RGB (`X2Bgr10`) that a gamescope HDR capture negotiates. So on a default NVIDIA host the probe was loading ffmpeg's NVENC client for a session that never uses it. Observed on home-nobara-1 2026-08-10, gamescope + RTX 5070 Ti, client HDR on: resolved session plan … bit_depth: 10, hdr: true pipewire format negotiated … xBGR_210LE mapped=Some(X2Bgr10) modifier=0 hdr=true encoder submit failed — encoder rebuilt in place … NV_ENC_ERR_INVALID_VERSION encoder did not recover after repeated in-place rebuilds — ending the video session and with `PUNKTFUNK_NVENC_DIRECT=0` (nothing mixes, libav serves everything) the same HDR session streams clean: 0 errors, bit_depth=10, hdr: true. The 10-bit cap now rides `nvenc_cuda::probe_support()`'s existing throwaway session — the same place the 4:4:4 cap already rides, queried per listed GUID with `NV_ENC_CAPS_SUPPORT_10BIT_ENCODE`, which is what the Windows NVENC arm has always done (`enc/windows/nvenc.rs`). Unanswered fails CLOSED: an 8-bit session beats a wedged one. A host that will really serve over libav (`PUNKTFUNK_NVENC_DIRECT=0`, or a build without `--features nvenc`) keeps the ffmpeg probe, where it validates the actual path and ffmpeg's client is loaded anyway. ⚠ NOT YET VALIDATED ON GLASS. Gates are green — clippy `-D warnings` with `--features nvenc,vulkan-encode,pyrowave` on linux/amd64, 67 pf-encode tests, fmt — but the end-to-end HDR run is still owed. This branch is 42 commits behind main and its build cannot complete a punktfunk/1 handshake on home-nobara-1 at all (it stalls between "audio channels resolved" and "encode bit depth" and times out at 10 s, on EVERY attempt). That stall is NOT this change: a control build with only the routing reverted stalls identically, and the released 0.27.0 RPM on the same box handshakes fine and reaches `bit_depth=10`. Rebase onto main before re-testing.	2026-08-10 12:30:24 +02:00
enricobuehler	a23c028492	fix(host): the console reported the resolution the client asked for, not the one it got ... `/api/v1/local/summary` (and the console card behind it) read the live-stats mode slot, which bring-up seeded from the NEGOTIATED mode: let live_mode = Arc::new(AtomicU64::new(pack_mode( mode.width, mode.height, interval_hz(interval)))); The refresh was already corrected there — the comment says so, because KWin caps a virtual output's rate — but the SIZE was still the request. Only a mid-stream resize ever fixed it: the rebuild path below publishes `delivered_mode(frame..)`, and bring-up never did. Attach is what makes this matter rather than being pedantry. On a box with a physical display the gamescope backend logs gamescope: box drives a physical display — attaching at its own mode (no re-mode) client_w=5120 client_h=1440 and streams the panel's size. Measured on home-nobara-1 with a 1080p HDMI panel attached: the capture negotiated 1920x1080 and NVENC opened 1920x1080@240, while the summary reported 5120x1440 — the console confidently naming a resolution nobody was watching, which is exactly the shape of the stale attach-path report noted on .41 in July ("reusing w=5120 h=1440" while the session was really 1080p). Seeding the slot from `delivered_mode(frame.width, frame.height, interval)` uses the same helper the rebuild path already trusts, and changes only the two fields that were wrong — its refresh term IS `interval_hz(interval)`, so that half is bit-for-bit what it was. This publishes the STATS slot only. It deliberately does not send the client a corrective `Reconfigured`: that remains owed exactly where it already was, under `adopted_at_bringup`, because an ordinary connect's mode came from the Welcome rather than from an accept the client has already acted on. Verified on home-nobara-1, attach session against a 1080p panel: summary session: {"width":1920,"height":1080,"fps":240} actually captured: pipewire format negotiated width=1920 height=1080 Before the change the same session reported 5120x1440.	2026-08-10 07:55:18 +02:00
enricobuehler	5b3ea6e8db	fix(pf-encode): one NVENC open failure could kill every session on the box ... `punktfunk-host` died twice on home-nobara-1 with the same stack: __strlen_evex <- av_vbprintf <- format_line <- av_log_default_callback <- ff_cuda_check <- ff_nvenc_encode_init <- avcodec_open2 <- NvencEncoder::open <- NvencEncoder::reset <- virtual_stream once as an outright SIGSEGV mid-session, and once as a thread wedged in that stack so the service never answered SIGTERM and systemd escalated to SIGABRT ("State 'stop-sigterm' timed out. Aborting."). Both times a client's session was rebuilding its encoder. The blast radius is the whole host process — every other client's session goes with it. The fault is in libav, not here. `ff_cuda_check` logs the failing CUDA call as `"%s failed -> %s: %s"` using an `err_name`/`err_string` pair the error lookup does not always fill, and glibc then walks whatever was on the stack. We cannot patch the distro's FFmpeg, so the fix denies it the chance to format: the guard already used by the 4:4:4 probe drops the level to AV_LOG_FATAL across the open, and `av_log_default_callback` returns on the level check before `format_line` — these messages are AV_LOG_ERROR. The failure is not swallowed; it still comes back as `Err(e)` and is reported with our own context, which now says the libav text was deliberately silenced so nobody hunts for a message that will not come. Scoped to the `open_with` call ALONE. The ENOSYS arm immediately below recurses into `Self::open`, and `QuietLibavLog` holds a non-reentrant global mutex — wrapping the whole `match` would have deadlocked the intra-refresh retry. Verified on home-nobara-1 (fc44, libavcodec 62). With CUDA made unavailable so the open fails inside the CUDA layer, the old binary prints [hevc_nvenc @ ..] cuInit(0) failed -> CUDA_ERROR_NO_DEVICE: no CUDA-capable device is detected — that line IS `ff_cuda_check` formatting the two `%s` — and the fixed binary does not; both exit 1 with our error instead. A successful open is unaffected on both the direct-SDK and the libav paths (90/90 frames, identical output size). What this does NOT claim: the uninitialized-pointer condition itself was not reproduced on demand — it depends on the CUDA error lookup failing to fill the strings, and in the forced case above it filled them fine. What is demonstrated is that the formatting call which faulted is no longer reached during the open.	2026-08-10 07:46:47 +02:00
enricobuehler	beb639f067	fix(ui): the OLED palette is called Eclipse now ... Every other background reads as a place or a material — Violet, Nebula, Abyss, Ember, Moss, Graphite, Holo, Sunset, Bloom, Dawn, Mint, Opal — and "OLED" was a spec sheet sitting among them, naming the panel it suits rather than what it looks like. It looks like black with a thin violet corona at one corner, which is an eclipse, and that puts it beside Nebula and Abyss. The ID stays "oled" in all three clients: it is the stored ui_palette value AND the cross-client key, so renaming it would orphan every saved choice and silently desync Apple, Android and the console UI. Only the label moved. No test or doc pinned the old string. Palette tests pass; macOS builds.	2026-08-10 07:30:30 +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	5d7091bf87	Merge pull request 'The Windows Xbox pad: make games actually see it' (#149) from worktree-xbox-pad-wgi-visibility into main ... Reviewed-on: #149	2026-08-09 21:36:29 +00:00
enricobuehler	e19f11bb0d	feat(abi/apple): carry the trigger motors to non-Rust clients — ABI 18, next_rumble_cmd2 ... The `0xCA` wire already carries the two Xbox impulse-trigger motors (v3), and the Rust decode path already parses them; `datagram_task.rs` dropped them on the floor with a comment naming exactly this work as what remained. The blocker was the C ABI: every non-Rust client pulls rumble through `punktfunk_connection_next_rumble_cmd`, whose out-params cannot carry two more channels. PunktfunkStatus punktfunk_connection_next_rumble_cmd2( PunktfunkConnection *c, uint16_t *pad, uint16_t *low, uint16_t *high, uint16_t *left_trigger, uint16_t *right_trigger, uint32_t *backstop_ms, uint32_t timeout_ms); ⚠️ ADDED, not widened. `_cmd` keeps its signature and its values bit-identical for handle-only traffic — out-of-tree embedders depend on it and `docs/embedding-the-c-abi.md` documents it, so silently changing an exported symbol would break every consumer at once. `nm` on the staticlib shows all four rumble entry points still exported. `ABI_VERSION` 17 → 18; every other site reads it dynamically, so there are no hardcoded mirrors to drift. ⚠️ ONE HONEST BEHAVIOURAL DELTA, documented in `abi.rs` and pinned by a test: against a trigger-driving host a `_cmd` caller now receives commands with `low == high == 0` where the demux previously dropped the update entirely. They are idempotent handle stops, and the redundant-stop suppression cannot fold them because the command as a whole is not silent. Zero cost today — nothing sources non-zero triggers. The dedupe-jitter proof was RE-DERIVED rather than widened, which is the kind of thing that quietly rots when a tuple grows: the nudge touches only `low` by ±1 LSB and `emit` is only reached with a non-silent level, so the nudged tuple can collide with the four-field stop sentinel only at `(1,0,0,0)`. A test pins both directions — refuse at `(1,0,0,0)`, flip freely at `(1,0,lt,0)`. Apple renders them: `RumbleRenderer` gains `Motor?` slots at `GCHapticsLocality.leftTrigger` / `.rightTrigger` beside the existing handles. A controller without trigger actuators degrades silently — a nil engine yields a nil slot and `reconcile` no-ops — and absent localities are never logged, because on most pads that is the normal case rather than a fault. The macOS DualSense raw-HID branch stays a deliberate no-op: a DualSense has ADAPTIVE triggers, not trigger rumble motors, and inventing a mapping there would buzz the wrong thing. 🛑 BUILT AHEAD OF A PRODUCER, DELIBERATELY, AND NOTHING HERE CLAIMS OTHERWISE. Nothing can currently source trigger rumble on Windows and that is measured, not assumed: `XINPUT_VIBRATION` has two members, and GameInput — the only four-motor API — does not enumerate an xinputhid-promoted Xbox pad at all, verified against a REAL Microsoft Elite which is equally invisible to it while classic XInput reads it live. So this path has never been exercised end to end and the comments say so. VERIFIED * `cargo test -p punktfunk-core --features quic --lib` 378 passed on macOS, 203 on Windows; clippy `-D warnings` clean with and without default features; `cargo fmt --all --check` clean. * The generated header is regenerated and idempotent on re-run (CI diffs it). * SWIFT ACTUALLY COMPILES AND RUNS: `swift build` clean and `swift test` 262 passed / 0 failures in `clients/apple`, against a locally built xcframework. (Editor SourceKit errors about `PunktfunkCore`/`DualSenseHID` are index noise from that gitignored artifact — a real build resolves both, and the `DualSenseHID` references are untouched by this change.) * `cargo build -p punktfunk-host` clean on Windows. NOT VERIFIED * End to end — see above; there is no producer. * Whether a real Xbox pad on Apple actually reports the two trigger localities. The degrade needs no code, but the positive case is untested. * `pf-client-core` (the SDL renderer) does not build on macOS at baseline and is unbuilt here. It only reads `RumbleCommand` fields and never constructs one, so added fields cannot break it, but it still calls `_cmd`; wiring `SDL_RumbleGamepadTriggers` is separate work. ANDROID: NOT DONE, and it should stay that way for now. `pack_rumble` packs pad/backstop/low/high into bits 0..52 of a `jlong` with `-1` reserved as a sentinel — two more `u16` do not fit. The right fix if ever wanted is the direct-`ByteBuffer` shape `nativeNextHidout` already uses in the same file (zero-allocation, caller-owned, the established idiom), not a second `jlong` (racy across two calls) nor `long[]` (an allocation per pull). But no Android device exposes trigger actuators at all, so there is nothing to render. Separately stale and also not fixed: `NativeBridge.kt`'s KDoc still documents the v2 `ttl_ms` layout rather than `backstop_ms`.	2026-08-09 23:30:02 +02:00
enricobuehler	7f1f7ba87c	fix(pads/windows): say WHY a pad index is taken, and stop the devtest lying when it is ... Debugging the on-glass session, a devtest run died with error=create gamepad bootstrap mailbox Global\pfds-boot-0: Zugriff verweigert (0x80070005) (install/repair: punktfunk-host.exe driver install --gamepad) and then — this is the part that cost real time — kept printing "virtual Xbox One S Controller up", streamed frames into nothing, and let the operator measure the INCUMBENT pad on that index. The XInput packet count sat frozen and read as "the pad is dead", which was a wrong conclusion drawn from a harness that had already failed and not said so. WHAT IT ACTUALLY WAS. Pad lifetime is deliberately tied to the SESSION (native/input.rs: "the gamepads are created and torn down with the session"), and a live session's pad legitimately owns `Global\pfds-boot-0`. The mailbox's SDDL is `D:P(A;;GA;;;SY)(A;;GA;;;LS)` — SYSTEM and LocalService only — and the host service runs as LocalSystem while a hand-run devtest runs as an elevated Administrator, which is in neither ACE. `CreateFileMappingW` over an existing name is really an OPEN, access-checked against the incumbent's DACL, so it returned ACCESS_DENIED and bailed at the `?` BEFORE reaching the `ERROR_ALREADY_EXISTS` branch that already had the right sentence. That branch only ever fires when both processes run as the same account. The name is per-index on purpose and stays that way: `Global\pfds-boot-{index}` is the rendezvous the driver polls, and its existence doubles as host-liveness. Making it per-process would let two hosts build two devices on one wire index — the "the game sees two controllers" bug. The collision is correct; only the diagnosis was wrong. * `gamepad_raii.rs` classifies the failure: on ACCESS_DENIED it probes with `OpenFileMappingW`, which separates what the OS collapsed — object-manager lookup precedes the access check, so absent gives FILE_NOT_FOUND and present-but-forbidden gives ACCESS_DENIED. It now says the mailbox belongs to a live session's pad and that nothing is wrong with the drivers. * `pad_slots.rs` carries that as a typed `PadCreateFault` through the anyhow chain, so `ensure` prints the fault's remedy instead of the per-backend reinstall hint, plus the pad index. * `devtest.rs` now BAILS when no pad was actually built, instead of announcing success. This is the fix that matters: every probe an operator runs next will still find a device on that index. * `native.rs` names what a detached input thread still holds, since that is one of the ways a pad can outlive its session. DELIBERATELY NOT CHANGED, with reasons: the session-scoped pad lifetime (intentional and documented); the mailbox naming (load-bearing, above); the retry/backoff (latching would resurrect the `broken` flag `PadGate` exists to kill); the 10 s thread-detach in `serve_session` and the service's `TerminateProcess` shutdown — both are real ways a devnode can outlive its owner, but neither is evidenced in the field case and inventing a fix for an unobserved path is how you get a regression instead of a bugfix. `pf-inject/lib.rs` drops the `cfg(any(linux, windows))` gate on `pad_gate`/`pad_slots`. Neither touches an OS pad API, and the gate meant a classification whose entire subject is a `cfg(windows)` failure could not be tested on a dev machine at all. VERIFIED * ON WINDOWS (.173): `cargo test -p pf-inject --lib` 109/109; `cargo build -p punktfunk-host` clean. Both agents' Windows code was compile-UNVERIFIED before this run. * macOS: 5 new tests, including one that pins the anyhow downcast through the exact three-layer context chain the Windows code builds — the assumption that could not otherwise be checked. * `cargo fmt --all --check` clean. NOT VERIFIED * That a LocalSystem-owned mailbox really answers `OpenFileMappingW` with ACCESS_DENIED rather than FILE_NOT_FOUND from an Administrator token. That is reasoned from the object manager's lookup-then-access-check order, not measured. Repro on .173: hold a session pad on index 0, run the devtest from an elevated console, and check the new sentence appears.	2026-08-09 23:29:30 +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	2b1843ed1c	fix(drivers/pf-gamepad): the right stick is Z/Rz — as declared, it was dead ... Found on glass, first real streaming session: everything worked except the right stick, and Steam correctly showed "Xbox One S Controller". `XBOX_RDESC` declared the right stick as `Rx`/`Ry`. `xinputhid`, which translates our HID collection into XUSB, maps `Z`/`Rz` to the right stick and does not treat `Rx`/`Ry` as one, so those two axes reached nothing. Two usage bytes. Left and right were declared identically here — same collection, same globals, same size and count — so the usages were the entire difference, which is what makes the diagnosis airtight rather than plausible. Note `DUALSENSE_RDESC`, a real capture, also uses `Z`/`Rz` for its right stick and puts the TRIGGERS on `Rx`/`Ry`; that is most likely where the original mistake came from. ⚠️ Byte offsets are unchanged — still 16×2 at bit 5.0 — so `xbox_proto`'s layout tests and the host-side packing are untouched. This is a pure relabelling. 🛑 THE REAL LESSON IS THE HARNESS, AND IT IS FIXED HERE TOO. This survived every bench measurement because `dualsense-windows-test` drove LS-X and the A button and left the other five analogue axes at zero. `XInputGetState` read `RX [0..0]`, which I read as "the devtest doesn't move it" — true, and useless: a harness that exercises one axis cannot tell "this axis is not mapped" from "nothing is driving it", and the two are indistinguishable in every consumer. The devtest now sweeps all six axes on distinct phases and ramps both triggers, so one run shows which axes arrive AND that they are not crosstalking onto each other's bytes. MEASURED ON .173, same run shape before and after, devtest sweeping all six axes: before: LX [-11264..24576] LY [-32768..31744] RX [0..0] RY [-1..-1] LT [0..248] RT [7..255] after: LX [-8192..26624] LY [-32768..31744] RX [-32768..31744] RY [-24576..10240] LT [0..248] RT [7..255] VERIFIED * `cargo test -p pf-inject --lib` 104/104 on Windows; `xbox` subset 11/11 on macOS — the layout tests still pass because nothing moved. * Driver rebuilds and signs; the descriptor is still 223 bytes so the `wReportLength` const assert is undisturbed. * `cargo fmt --all --check` clean. NOT VERIFIED * Not yet re-tested in a real streaming session — that is the next on-glass run. * ⚠️ A leftover finding from the same session, unrelated to this fix and NOT investigated: the session's pad devnode SURVIVES client disconnect and keeps the `Global\pfds-boot-0` bootstrap mailbox, so a devtest run afterwards fails with `Zugriff verweigert (0x80070005)` and silently measures the stale pad instead. Restarting the service releases it. Worth its own look.	2026-08-09 22:19:25 +02:00
enricobuehler	4f9071b980	feat(pads/windows): three Xbox identities — Wireless, One S and Elite Series 2 ... Until now there was one Xbox identity, `device_type = 4` / `045E:0B13`, and Windows folded a client's `XboxOne` request onto it because the only Windows Xbox backend was the XUSB companion, which presents one fixed 360 identity and cannot vary it. The HID backend can, so the fold goes and two identities join it: devtype 4 045E:0B13 pf_xboxwireless Xbox Wireless Controller devtype 5 045E:02FD pf_xboxones Xbox Wireless Controller (One S) devtype 6 045E:0B22 pf_xboxelite Xbox Elite Wireless Controller Series 2 `GamepadPref::XboxElite` takes wire byte 11 — the first unassigned one, and the round-trip test previously asserted `from_u8(11) == Auto` with a comment saying assigning it must update that; the sentinel moved to 12. The C ABI mirror and the generated header moved with it. ⭐ ALL THREE SHARE ONE REPORT DESCRIPTOR, deliberately. In HID terms they are the same pad; the descriptor is the report shape, not the identity. §3 of the handoff records that our single hand-written descriptor already cost three separate bugs, and inventing two more would multiply that debt for no measured gain. They differ in VID/PID, product string, hardware id and Device Manager description only. ⚠️ All three install `pfGamepadXbox`, the section that attaches the `xinputhid` bus filter. That was the open risk: Microsoft's `xinputhid.inf` promotes by an explicit hardware-id allow-list containing `02D1, 02DD, 02E3, 02EA, 0B00, 0B0A, 0B13, 02FF` — and NEITHER `02FD` NOR `0B22` is on it. Measured on .173: promotion does not care, because it comes from our own AddReg rather than from matching Microsoft's ids. All three gain `IG_00`, register an XUSB interface, and are read live by classic XInput. Had this gone the other way the two new identities would have been strictly worse than the one they joined. The XUSB escape hatch needed a runtime degrade to stay honest. `pick_gamepad` is compile-time only, so with `PUNKTFUNK_XBOX_BACKEND=xusb` the host would have resolved and echoed `xboxelite` in its `Welcome` while actually building a 360 pad. `degrade_xbox_identity` folds the identity back at runtime, mirroring `degrade_if_no_uhid`. VERIFIED ON WINDOWS (.173 — none of this compiles on macOS; the driver needs the WDK and the rest is `cfg(windows)`): * `cargo test -p pf-inject --lib` 104/104 — including `hwid_matches_inf`, `hwid_devtype_table_matches_the_driver` and `only_the_xbox_identity_installs_the_xinputhid_section`, all now sweeping the whole identity set and asserting the section split in both directions. * `cargo test -p punktfunk-core --lib gamepad` 7/7; `cargo check -p punktfunk-host` clean. * Driver builds and signs; the descriptor/`wReportLength` const asserts still hold with the descriptor shared three ways. * ON GLASS, per identity, via the new `--xboxones` / `--xboxelite` devtest legs: each gets its own devnode (`PF_XBOX_0` / `PF_XBOX_ONES_0` / `PF_XBOX_ELITE_0`), each HID child gains `IG_00`, each registers an XUSB interface, and XInput reads each live (packets advancing, `buttons=0x1000`). * macOS: `cargo fmt --all --check` clean in both workspaces. NOT VERIFIED / NOT DONE * **Elite paddles are NOT implemented.** `BTN_PADDLE1..4` would need descriptor buttons, and once `xinputhid` promotes the pad it claims the HID collection exclusively — XInput has no paddle fields and the HID consumers that do may be locked out, so the buttons would likely reach nobody. The decisive measurement is cheap and named in the code: hold a paddle bit set and see whether a user-mode HID reader still gets reports. Until then the Edge remains the only virtual pad with native back-button slots and nothing should be advertised otherwise. * **No client picker offers the Elite**, and none can auto-detect it — SDL3's `GamepadType` has no Elite variant. It is reachable today only via `PUNKTFUNK_GAMEPAD=xboxelite` or a hand-edited client setting. All five clients ship the same curated six options by deliberate parity, so adding one is a cross-client UX change, not part of this. * Nothing here has run in a real streaming session; every measurement came from the devtest.	2026-08-09 21:41:53 +02:00
enricobuehler	1317901122	Merge pull request 'Uninstalling the Windows host left every audio device it minted behind forever — and the installer script documented that as a decision' (#145) from worktree-win-audio-uninstall-cleanup into main ... Reviewed-on: #145	2026-08-09 19:30:31 +00:00
enricobuehler	bd5735b803	feat(pads/windows): make the HID Xbox pad the default, and carry the trigger motors on the wire ... Three changes that only make sense together: the HID backend becomes the default now that it is a superset of the XUSB one, the rumble datagram grows the two Xbox impulse-trigger motors, and the INF-shape tests learn about the Xbox identity's own install section. WP-E — `PUNKTFUNK_XBOX_BACKEND` now defaults to `hid`; `=xusb` is the escape hatch. The knob existed for exactly one reason, recorded in its own doc comment: the HID pad could not reach classic XInput, so defaulting to it would trade a known-working path for an unproven one. That objection is gone — with the `xinputhid` bus filter the INF now attaches, the HID pad is promoted like real hardware and keeps classic XInput while gaining everything XUSB never had (Steam, SDL, RawInput, DirectInput, joy.cpl, WGI) plus rumble, which XUSB could not source at all. The escape hatch stays because promotion leans on Microsoft's inbox `xinputhid.inf`; if a servicing update changes it, one env var restores the old behaviour with no reinstall. An unrecognised value takes the DEFAULT rather than the opt-out, so a typo cannot silently drop a user onto the path with no HID collection. WP-D — the `0xCA` rumble datagram gains a v3 form: v1 7 B: [0xCA][u16 pad][u16 low][u16 high] v2 10 B: … [u8 seq][u16 ttl_ms] v3 14 B: … [u16 lt][u16 rt] v3 is built FROM v2's bytes rather than restating the layout, so the prefix relationship is structural instead of a convention two encoders have to keep agreeing on, and every reader gates with `>=`. The four levels share one seq and one ttl on purpose: they are one statement of the pad's feedback at one instant, and sharing means the whole v2 apparatus — renewal cadence, stop burst, the client's seq gate, the lease clamp — governs the triggers with no new code. The new `RumbleUpdate` fields are plain `u16`, not `Option`: on a level-triggered plane "absent" must mean zero, because "absent → keep the previous value" is the stuck-rumble bug in a new costume. Only one backend can ever source them — the Windows HID Xbox pad, whose output report 0x03 carries them. `XINPUT_VIBRATION` and evdev `FF_RUMBLE` have two members and no third, so every other producer sends `lt = rt = 0`. ⚠️ The two TRIGGER `enable`-mask bits remain CONJECTURE. Bits 2/3 = left/right handle are measured; bit 0/1 = the triggers are inferred from field order and nothing else. `parse_xbox_output` says so inline, and no test asserts them — every test vector uses masks (0xFF, 0x00, 0x0C, 0xF3) whose expectations hold whichever bits turn out to be right. XInput cannot settle this: it has two motors. The INF tests — `hwid_matches_inf` matched the install section by the exact string `=pfGamepad,` and so stopped seeing the Xbox hardware ids the moment that identity moved to its own `pfGamepadXbox` section. It failed loudly, which is the good outcome; it is now prefix-matched and tolerant of further per-identity sections. Added `only_the_xbox_identity_installs_the_xinputhid_section`, which asserts the split in BOTH directions: the Xbox line must not install the shared section, and no other line may install the Xbox one. Merging them back is a one-line edit that looks like tidying and would hand a DualSense to Microsoft's Xbox translator. VERIFIED * ON WINDOWS (.173, the only place this code compiles): `cargo test -p pf-inject --lib` 104/104, including the new trigger tests and both INF tests; `cargo check -p punktfunk-host` clean. * macOS: `cargo fmt --all --check` clean; `cargo test -p punktfunk-core --features quic` rumble suite 22/22, including v3 round-trip and v3<->v2 cross-version parsing. * The pre-existing `c_abi_harness_round_trips` failure on macOS is `ld: library 'opus' not found` and reproduces with these changes stashed. NOT VERIFIED * No trigger rumble has ever been observed end to end — nothing can drive it yet (see the conjecture note above), and no client renders it. * The default flip has NOT been exercised in a real streaming session; every measurement so far came from the devtest harness. That is the on-glass run. * Non-Rust clients do not decode v3. They are blocked on a C ABI entry point first (`punktfunk_connection_next_rumble_cmd` has fixed out-params, ABI_VERSION 17); Apple could render it via GCHapticsLocality.leftTrigger/.rightTrigger, Android structurally cannot (its packed jlong is full) and has no trigger actuators anyway.	2026-08-09 21:10:08 +02:00
enricobuehler	d87a8df28d	fix(windows): uninstall removes the audio devices the host mints ... The field report: uninstalling punktfunk left "Punktfunk Speakers", "Punktfunk Microphone" and the per-pad "Wireless Controller" endpoints sitting in Windows' Sound settings forever. They have no installer payload behind them, which is why nothing in the uninstall touched them. The host mints them at RUNTIME as extra devnodes on Valve's streaming-audio drivers, and both providers deliberately re-resolve their devnode across restarts instead of re-minting it — so they persist by design. Persistent across restarts must not mean permanent: the .iss even documented leaving them behind as a decision. New `driver uninstall --audio` leg (a third Inno [UninstallRun] entry, after the two driver legs and well after `service uninstall`, since a live host re-mints on its next wiring pass): * restores the default playback device first, if a host that died mid-stream left it parked on our loopback sink — otherwise Windows re-picks by its own ranking rather than giving the operator back the device they had; * removes every MEDIA-class devnode carrying one of our three durable owner markers (pad slot, minted role, probe), phantoms included; * deletes each endpoint's MMDevices record, resolved through the devnode link BEFORE the devnode goes. Marker-matched, never name-matched: our instances are name-identical to Steam's own, and Steam's devnodes, its drivers, and a VB-CABLE from the era when we bundled one carry no marker and stay untouched. A ROOT\ enumeration guard means a marker-shaped value on a real sound card can never cost the user their hardware. The registry half is best-effort: those keys are SYSTEM-owned and the uninstaller runs elevated but as a user, so on a stock box the record survives as an inert NOTPRESENT entry that Sound settings only shows behind "Show Disconnected Devices". The device itself is gone either way, and seizing ownership of SYSTEM registry keys from an uninstaller is a worse thing to ship than that scrap.	2026-08-09 20:53:22 +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	003ce8bea7	Merge pull request 'Every NVIDIA gamescope HDR stream had red and blue swapped — and a sysext step added in a release was unreachable forever' (#143) from worktree-hdr-rb-swap-nvidia into main ... Reviewed-on: #143	2026-08-09 15:34:02 +00:00
enricobuehler	d2a2bcc25d	feat(drivers/pf-xusb): answer the async input wait, and put xinputhid on the stack ... The two things this driver's README has always listed as the missing WGI/GameInput work, both user-mode, neither needing a bus driver: `IOCTL_XUSB_WAIT_FOR_INPUT` is now pended on a manual queue and completed by the periodic timer on a dwPacketNumber edge, answering with the same 29-byte GET_STATE payload the synchronous path serves. Declining it was enough for classic xinput1_4, which just falls back to sync GET_STATE polling — that is why the pad has always worked there. It is not enough for WGI/GameInput, which poll asynchronously: to them a decline is a refusal, not a fallback. Completion is edge-gated because releasing a waiter on an unchanged packet spins its caller at timer rate. WAIT_GUIDE_BUTTON stays declined — we have no state to signal on. The INF adds UpperFilters=xinputhid on the XUSB devnode. Note the earlier attempt put that filter on the HID child of the *other* backend, which was simply the wrong devnode: XInput does not read HID at all, it enumerates GUID_DEVINTERFACE_XUSB, which is what this driver registers. Verified on .173: build + sign + catalog exit 0; infverif "INF is VALID"; the devnode starts Status OK with UpperFilters=xinputhid readable back from its enum key; and XInput still sees the pad (slot 1 live alongside the box's real Elite in slot 0), so the async queue is no regression to the path that already worked. NOT yet measured: whether WGI/GameInput now admit the pad. `IG_` is the wrong probe for this driver — it is a HID-path artifact and pf-xusb is System-class with no HID child, so its absence says nothing either way. That needs a real WinRT/GameInput enumeration test.	2026-08-09 17:29:10 +02:00
enricobuehler	4e04c2bbf8	feat(host/pads): route the Xbox pad to the HID backend behind PUNKTFUNK_XBOX_BACKEND=hid ... Wires `xbox_windows` into the per-pad router so an Xbox-family pad can be built as a real HID device instead of the XUSB companion, and adds the knob that selects between them. Opt-in rather than the new default, deliberately. XUSB is what classic-XInput games read today; the HID pad buys the Steam / WGI / GameInput / DirectInput visibility XUSB can never have, but whether Windows promotes it into an Xbox-profile device that XInput and WGI Gamepad accept is still the open question. Flipping the default before that is settled would trade a known-working path for an unproven one. The two backends are mutually exclusive per pad by construction — one match arm or the other — because presenting both hands a game two controllers for one pair of hands. Verified on .173: cargo check -p punktfunk-host exit 0, clippy -D warnings clean, `cargo test -p punktfunk-host gamepad` 8/8 green, fmt clean.	2026-08-09 17:03:25 +02:00