2940 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
enricobuehler	dc4d8d6832	fix(pf-vdisplay): correct the regressions this sweep introduced ... An adversarial review of the sweep's own diff raised 39 claims; 23 survived independent verification. This commit fixes them. Several are cases where the sweep traded one bug for another. **The display budget was enforced in the wrong place.** The new Linux `max_displays` ceiling sat in `registry::acquire` — which runs again on every mid-stream rebuild. All three create-before-drop paths hold the old lease while acquiring the new display, and only the mode-switch path passes `supersedes`, so a session at the ceiling counted itself against the budget and could never recover from capture loss or a Game↔Desktop switch. At `max_displays = 1` that is a single streaming client. Moved to `admission::admit`, which is where Windows has always applied it and which is reached once per connect — so a rebuild cannot hit it. **"Cannot tell" was collapsed into "wrong mode".** `unanimous_output_size` returning `None` for two disagreeing gamescopes was compared with `== Some(target)`, so ambiguity took the destructive branch: a nested per-title gamescope — the normal Game Mode shape — made every connect restart the box's session and kill the running game. Now a three-state `BoxOutputSize`, where `Ambiguous` mirrors the live node instead of re-moding, and the post-restart wait asks "did what we asked for come up" rather than demanding unanimity. **Decide-then-act lost its mutual exclusion.** Re-scoping the `MANAGED_SESSION` guard fixed the shutdown restore but let two concurrent creates at the same mode both relaunch, the second stopping the unit the first was polling. A separate `MANAGED_LAUNCH` mutex restores the exclusion without putting launch progress back into the lock the restore samples. **Per-axis policy salvage was applied to a selector.** `preset` chooses the other axes, so salvaging it to the default silently re-pointed the whole document; it now refuses the document instead. A file whose every axis is unreadable also reported `configured() == Some(default)` — flipping Linux identity from Shared to PerClient — and now correctly reports unconfigured. **The six `#[serde(default)]` on `EffectivePolicy` are reverted**: they loosened `POST/PUT /display/presets` (an omitted axis defaulted where it used to 400), which nobody asked for. The catalog salvage they were added for now lives in a private Deserialize-only mirror type, so the read path stays lenient and the wire contract stays strict. Also: the Windows create path stored the OS-committed refresh in the field `acquire` uses as its resize discriminator, so a same-mode re-acquire looked like a hotplug — the requested and committed modes are now separate fields; `output_within`'s timeout arm detached both reader threads (now bounded by a drain grace, capped at 16 MiB, and logged honestly — a `systemd-run --pipe` unit escapes the process group and cannot be reached); `reenable_outputs_kscreen` abandoned the mode restore whenever kscreen-doctor hit its budget even though the enable may have landed (now tri-state); `write_atomic` replaced a symlinked portal config with a regular file, severing dotfiles management; several new budgets were too short for the helper they bound (`steam -shutdown` was being killed before it could deliver the request; `linger_enabled` read a 300 ms timeout as "not lingering" and hard-failed a correctly configured box); and a restore logged an operator-facing error for a `systemctl` call that had merely outlived its budget while systemd still owned the queued job. Verified: 107 tests on macOS, 202 on Linux (executed in a container, not merely type-checked), Linux and Windows clippy clean at `-D warnings`, fmt clean.	2026-08-11 10:06:16 +02:00
enricobuehler	6b33750edc	fix(pf-vdisplay): one non-UTF-8 byte in a portal config destroyed the whole file — in the module written to prevent exactly that ... `portal_config::ensure_key` folded EVERY read failure into an empty string (`read_to_string(path).unwrap_or_default()`). `upsert("", …)` then produced a file containing only our block, the one-time backup was skipped because `!existing.is_empty()` was false, and the write replaced the user's config — returning `Ok(true)`. So a single Latin-1 character in a comment in `~/.config/hypr/xdph.conf` or `~/.config/xdg-desktop-portal-wlr/config` destroyed the operator's entire portal configuration, with no backup and no warning. The module doc says flat-writing these files "destroyed [everything else] on first connect, silently and permanently" and that this module exists so it cannot happen; that one line re-opened the door. The same shape hit a transient EIO on an NFS or overlay config dir. Now: bytes are read with an explicit match, only `NotFound` may mean "empty", a non-UTF-8 config is refused by name rather than replaced, the backup is taken by BYTES, and the write is atomic (temp + `sync_all` + rename in the same directory, permissions carried over). Five new tests, all running on macOS — `a_non_utf8_config_is_refused_not_replaced` fails against the old code. Also in the wlr/Mutter family: * **Mutter's `Primary` rebuilt kept physicals from scratch** — scale forced to 1.0, transform to 0, disabled heads re-enabled — so a rotated, 2x-scaled or deliberately-disabled monitor came back wrong, while the code went to real trouble to preserve refresh. Each head now carries its pre-connect scale and transform, and x advances by the LOGICAL width. * Three availability probes read session env (`SWAYSOCK`, `XDG_CURRENT_DESKTOP`, `HYPRLAND_INSTANCE_SIGNATURE`) with no `ENV_LOCK` while `apply_session_env` `set_var`s the same keys from another thread — the glibc setenv/getenv race this crate's own lib.rs documents as UB. * `wlroots::create_output` ran a statement before its `OutputGuard` existed, so a raced `wait_new_output` orphaned the output permanently — hyprland takes the guard first. The before/after name diff also ran outside any lock, so two concurrent creates could adopt each other's output. Both now run under a create lock, with a stray sweep on the failure path. * `select_and_cast`'s timeout arm dropped the portal thread's `stop` flag un-set — the same leak Mutter was already fixed for. The guard is now built before the wait, in both copies. * The xdpw chooser file was written per session and never removed, permanently shadowing the config's fallback with the name of an already-unplugged output. Its lifetime is now the handshake, not the session — scoped deliberately, because tying removal to the keepalive would let one session delete another's selection hours later. * Hyprland's headless outputs are now named `PF-<pid>-<n>` and reconciled at startup, so a crashed host's leftovers are reclaimed while a live sibling host's outputs cannot be pulled out from under it. `set_monitor_rule` no longer discards hyprctl's rejection text and then hard-codes a GBM/dmabuf diagnosis it never verified. * Both wlr backends silently dropped the `topology` policy axis: `Primary`/`Exclusive` was accepted, echoed by the mgmt API, applied on three backends and a no-op on two. They now say so. Item 8.1: `swaymsg`, `hyprctl` and the portal `systemctl --user try-restart` calls are bounded through `proc` with named budgets.	2026-08-11 09:22:32 +02:00
enricobuehler	ef72d102b6	fix(pf-vdisplay): KWin's re-enable reported success when it matched no outputs at all, leaving a physical monitor dark ... * **`reenable_outputs` returned `true` when it matched NONE of the requested outputs.** Unresolvable outputs were `continue`d and the return was the apply verdict alone — but an empty `kde_output_configuration_v2` still gets an `applied` event. So a total no-op suppressed the `reenable_outputs_kscreen` backstop and the operator's physical monitor stayed dark. Now counts staged outputs and returns `ok && matched == outputs.len()`, and refuses to apply an empty configuration at all. * **The kscreen restore logged "restored the physical/bootstrap outputs" unconditionally**, with both call results discarded — including when `kscreen_ok` returned false on its 5 s budget, which is exactly the wedged state that fallback exists for. * **`Session::open` swallowed every failure reason** — connect error, barrier timeout, missing global — and three of four callers degraded to kscreen-doctor with zero log. This is the class that hid the KWin >= 6.7 registry regression: a shipped fallback firing silently on every machine. It now logs at warn with the reason and the caller's operation name. * `last_name` was seeded with a name kscreen-doctor can never resolve (KWin's address is `Virtual-punktfunk…`), so the intended default was guarded by an `is_none()` that could never hold and `apply_position` ran against no output. `our_uuid` was never reset per `create` and only assigned under `outcome.handled`, so a supersede positioned the *previous* output and never fell back. * `probe()`'s `roundtrip` was the only unbudgeted compositor wait in the crate — every sibling path is budgeted — and it is reached from an async mgmt handler. Now bounded at 3 s. The pre-`created` dispatch loops gained deadlines and now set `stop` on the timeout arm. * Every `wl_output` global was bound for the session's life with no `GlobalRemove` arm and no `release()`, on the virtual-output path too, which never reads them: unbounded growth on a hotplugging session. * `monitors::list` was the one KWin call site with no kscreen fallback at all, despite `list_monitors` failing on exactly the condition the other four fall back for. It has one now. * `CVT_H_GRANULARITY` and `MANAGED_PREFIX` existed as two literals under prose asserting they match; the second copy now imports the first. The wider facade extraction (item 9.1) is deliberately not in this commit, but its two prerequisites are — a comment at the restore seam records why they had to come first: a fallback arm that returns a value the helper never checked re-introduces the silent success, behind a seam whose selling point is one honest log per decline. Also corrects the `PhysicalMonitor` type doc, which claimed "logical geometry throughout" while `width`/`height` are the mode's PIXELS and `x`/`y` are logical, and adds the `logical_size()` helper that is the only correct way to compare an extent against a position.	2026-08-11 09:22:11 +02:00
enricobuehler	b2c03f1904	fix(pf-vdisplay): a managed launch blocked the shutdown restore that was meant to rescue it, and re-moding could flip the operator's own screen ... The gamescope subsystem — the crate's largest and fastest-churning area, and the one the 2026-07-28 sweep predates most of. * **`MANAGED_SESSION` was held across the ~90 s managed launch**, and the shutdown/idle restore blocks on that same lock — *after* it has already stopped our unit. So the display-manager restore never ran and the box was left with no session at all. `create_managed_session` now decides under the guard and acts outside it, re-acquiring only to store the result; `do_restore_tv_session` consumes the record in a short scope at the top. Same shape the SteamOS twin already used. * **The physical-display guard was bypassed whenever no gamescope node happened to be published.** `if physical_display_connected() { if let Some(node) = find_gamescope_node() { … } }` fell through to `set-environment SCREEN_WIDTH/HEIGHT/CUSTOM_REFRESH_RATES` + `restart` when the node was momentarily absent — gamescope restarting between titles, or built without PipeWire — flipping the operator's own screen to the client's resolution and bouncing a DM-driven login session. The guard now refuses instead of falling through, and the forced `SCREEN_*` values (which were never unset, so every later session on the box inherited them) are tracked and `unset-environment`ed on restore. * **`current_gamescope_output_size()` reported an arbitrary gamescope's `-W`/`-H`** — whichever `/proc` enumerated first — and four consumers treated it as this session's output size. It now answers only when every gamescope on the box agrees, and `None` ("cannot tell") when they differ. `heads.rs` no longer takes it at all: it reads the size off the DRM-backed argv it already selected. Its test previously passed `None`, which is why the hazard was invisible. Resource and honesty fixes: the ATTACH path armed the box's own session-unit bind drop-in and no in-process path ever removed it (now tracked and disarmed on both restore arms); `wait_for_node` never called `try_wait`, so a gamescope that died at `vkCreateDevice` was polled for the full 15 s and the error then blamed headless capture support; `do_restore_tv_session` deleted its crash-recovery state *before* the unbounded work that state records, so a grace-period expiry in that window left the DM down with nothing on disk to heal it; the SteamOS takeover's two failure arms never armed the TV restore though the session-plus twin does; the TV-session restore logged success with the `systemctl` status discarded; the `steam -shutdown` child was dropped un-reaped; and a managed session that took nothing over was never persisted, so a host crash orphaned the transient unit. Item 8.1: the unbounded `pw-dump`, `systemctl`, `loginctl` and `pkexec` calls in this subsystem now go through `proc::{status_within, output_within}` with per-call budgets. `pw-dump` is polled from three separate 45 s loops against the very daemon this file documents gamescope as head-blocking, and until now a hang there pinned the session's stream thread forever.	2026-08-11 09:22:09 +02:00
enricobuehler	db65980979	fix(pf-vdisplay): the ghost-monitor reap fed live devices to pnputil, and two unsafe fns had no unsafe in them ... Windows half of the sweep — the reap bug, a panic that poisons two locks, and a round of unsafe reduction. * **The ghost reap selected the wrong devices.** It filtered `Status -ne 'OK'`, a HEALTH field: that matches devices that are PRESENT but in Error/Degraded/Unknown, not the ABSENT ones the reap is for — and it handed them to `pnputil /remove-device`, contradicting its own documented contract. It runs from `add_monitor`'s mid-session slot-exhaustion recovery, so the blast radius is a live session. Now filters on `-not $_.Present`. * **`ensure_pinger` still used the panicking `thread::spawn` while holding two locks**, poisoning both — the un-fixed twin of a fix that already landed for `ensure_exclusive_watch`. Same shape applied. Unsafe reduction, continuing the program that made pf-win-display's CCD helpers safe fns: * `resolve_target_gdi` and `reisolate_after_swap` were `unsafe fn`s containing zero unsafe operations, and the three call-site SAFETY proofs described FFI they no longer perform. Both are now safe fns and those blocks are gone. * `VdisplayDriver::open`'s `# Safety` section named no caller obligation — the same empty shape an earlier phase already removed from `open_device`. * `(*detail).DevicePath.as_ptr()` derived a pointer from a `[u16; 1]` field and handed it to `CreateFileW`, which reads the whole flexible-array path beyond it. Now taken with `&raw const` from the full struct, so the pointer carries the provenance of the bytes actually read — the same correction already made for `MONITORINFOEXW` in ddc.rs. Comment fixes, all verified against the code: three intra-doc links to a type this crate does not have; a doc-comment run merged so that `shrink_action` — the gate that keeps a `Primary` group's physical panels lit — read as undocumented while its rationale sat on an unrelated polling helper; and the backend module header, which documented itself against a `sudovda` module that does not exist and a fallback the crate says was removed. Adds the first tests for `knobs.rs`, `instance.rs` and `driver.rs` — including `is_privileged_sid`, the security-relevant predicate that decides whether an existing single-instance name is another host or a squat, which had no coverage on any platform.	2026-08-11 08:49:06 +02:00
enricobuehler	a1ff0dde0c	fix(pf-vdisplay): the host promised HDR and cursor forwarding for gamescope sessions it did not start ... `gamescope_ours_and` answered "did WE spawn this gamescope?" by reading `PUNKTFUNK_GAMESCOPE_NODE`. Phase 2.3 deleted the code that published that key — routing.rs's own doc says "Nothing is written back to the two knobs" — but this consumer was never migrated, so the read now returns "not attaching" for every attach. Both consumers then answer for a session this host has no flags on. On a plain box with a foreign gamescope already running, `pick_gamescope_mode` resolves Attach at its fifth rung while the env key stays unset, and the probe half only inspects the resolved BINARY, which is our patched build: * `gamescope_composites_cursor()` returns true, so the host attaches no XFixes reader and blends nothing — while the stock gamescope actually running was never given `--pipewire-composite-cursor`, so the stream carries no pointer at all. * `gamescope_hdr_available()` returns true, so the Welcome fixes `bit_depth` at 10 and the session negotiates BT.2020/PQ over an 8-bit SDR composite. The Welcome cannot take that back. The same two failures hit the `capture_monitor` mirror route on any Bazzite or SteamOS box, where the running Game Mode gamescope is by definition not one this host spawned. The question is now asked of the resolved route rather than the environment, via a pure `session_is_a_foreign_gamescope` that runs — and is tested — on every platform. The residual gap is named in the doc rather than papered over: `create_managed_session`'s create-time degrade to a foreign attach is still invisible to a ladder re-run. Also in this commit: * Two unguarded session-env reads now take `ENV_LOCK` (`detect()`'s `XDG_CURRENT_DESKTOP` fallback and `effective_topology()`'s legacy pins). `apply_session_env` `set_var`s those same keys from another thread, which is the glibc setenv/getenv race this crate's own lib.rs documents as UB. * `mirror.rs`'s `names_ours_conclusively` was a `matches!` whose omitted default was the UNSAFE direction — a new backend would silently get its own virtual displays mirrored. Now exhaustive, so adding a `Compositor` is a compile error at the one site where the answer is a safety decision. * `MirrorDisplay` overrides `poolable_now() -> false`; its `create` always reports `External`, so the trait's `true` default was a pre-create claim contradicting the post-create fact. The trait doc now says plainly that the default is a default and not a fact. * The crate front-door doc listed 3 of 7 backends and quoted line counts half the size of the current crate; `routing.rs`'s summary was attached to the wrong item and described a published env channel that no longer exists; `available()` is no longer documented as cheap when it forks `gamescope --version` and does an unbudgeted Wayland roundtrip per call.	2026-08-11 08:48:49 +02:00
enricobuehler	9d58f4c170	fix(pf-vdisplay): one unreadable byte reverted the host to built-in display defaults, and one bad preset dropped the whole catalog ... The policy layer folded every failure into "unconfigured", then wrote that emptiness back. * **Any parse error reverted the WHOLE policy.** An unknown enum variant, a mistyped scalar, an EACCES or EIO — all became `Err(_) => None`, i.e. the host silently ran on built-in defaults with the operator's `display-settings.json` still sitting on disk. Parsing is now layered: strict first, then per-axis salvage so one unreadable axis costs only that axis, and only `NotFound` is quiet — EACCES/EIO warn loudly that the host is on defaults. `version` is read instead of being blindly rewritten to 1. * **One malformed entry dropped the entire custom-preset catalog**, and the next CRUD atomically renamed the empty vector over the file. Entries are parsed one at a time now; a lossy load is flagged and refuses to overwrite. * `sanitized()` clamped `max_displays` but never `KeepAlive::Duration.seconds`, so a PUT could pin a display for ~136 years — a deadline the reaper never reaches and a nonsense `expires_in_ms` in `/display/state`. Clamped to a day, in both `sanitized()` and `sanitize_preset_fields`, and sanitization now runs on LOAD as well as on write. * The two stores' temp files had fixed names and no write lock, so concurrent saves could interleave serialize -> rename -> in-memory update. Unique suffixes, a lock, and the in-memory update ordered after the rename. * `new_preset_id` never consulted the loaded entries for collisions. * **Manual layout could place an unpinned display exactly on top of a pinned one**: the fallback was the unconditional auto-row prefix sum, blind to where prior members were pinned. Unpinned members now pack clear of the pins. Layout keys are canonicalized and unusable ones dropped at write time rather than persisted-and-ignored. Adds 20 tests, all running on macOS: a 20k-round randomized property test asserting no unpinned member ever overlaps a sibling (verified to fail against the pre-fix `arrange_manual`), the salvage and quarantine paths, the clamps, and a field-count guard that fails the moment a 13th policy axis appears without being wired into the merge path. Note: `partial_json_fills_defaults` was renamed to `serde_defaults_fill_a_partial_document` with no assertion weakened — it pins the FILE contract (an old settings file must still load), which is not the mgmt PUT contract that sweep item 11.1 is about.	2026-08-11 08:48:47 +02:00
enricobuehler	61ff543acc	fix(pf-vdisplay): a new client could be handed a streaming client's display, and a blind /proc scan tore every backend down ... Five defects in the registry/identity half, plus the restructure that finally makes them testable. * **A new client could be assigned a LIVE client's identity slot.** `DisplayIdentityMap::resolve` LRU-evicted purely on its `seen` stamp, with no knowledge of which ids are streaming. On Windows that id keys the manager's slot map, so the newcomer took the plain-JOIN branch and inherited the other client's monitor, capture target and stop flag. `resolve` now takes the live set, never evicts a live id, and REFUSES rather than hand one over — degrading to the shared/auto identity. * **A transient `ActiveKind::None` invalidated every backend entry, including live streaming ones.** A `read_dir("/proc")` that happened to fail satisfied the change test and bumped the session epoch. A `None` observation is no longer evidence a desktop went away, and no longer overwrites the baseline (which would have bumped the epoch on the next poll anyway). * **The Linux pool had no display ceiling at all** — `max_displays` was enforced only on Windows, while the pool keys on the CLIENT-SUPPLIED mode, so each distinct requested resolution minted a new display. Now capped in `linux::acquire`, gated on `poolable_now` so a gamescope attach or managed session (which consumes no pool slot) is not refused. * **Two different definitions of "display group"** — `group_key` and a bare backend-name compare — and only one separated gamescope spawns. Unified as `pool::in_group`. The `position_for_new` collection also lacked the supersede exclusion the topology check 70 lines earlier had, so a mid-stream resize auto-rowed the replacement past its own dying predecessor, walking the display one width to the right on every mode switch. * **Lifecycle events were wrong in both directions**: `Created` fired on keep-alive reuse, and `Released` fired only from the mgmt endpoint — never from a lease drop, the linger reaper, `mark_failed`, `retire` or `invalidate_backend`. All six now emit. Also: `Release::Noop` no longer runs a full teardown (the one outcome the state machine defines as "do nothing"); a failed linger-reaper spawn logs and retries instead of consuming its `Once` and never tearing a kept display down again; group ids are a monotonic per-key counter instead of an index into the currently-live sorted set, so an unrelated group appearing no longer renumbers a display; and a corrupt `display-identity.json` is renamed to `.bad` with a warning rather than silently overwritten, which used to reset every client's stable id and its saved DPI. The pure half of the pool (`Entry`, `group_key`, `epoch_matches`, `take_expired`, `at_display_budget`, `position_for_new`, `assign_group_ids`, `assemble_displays`) is now a non-cfg'd `mod pool`, so the registry's decisions are exercised on every platform's CI instead of only on a Linux box. Crate test count 53 -> 94.	2026-08-11 08:48:15 +02:00
enricobuehler	dd9bbaf1c5	fix(pf-vdisplay): a helper that outran the pipe buffer had its output thrown away as a timeout ... `output_within` read stdout/stderr only after the child exited, and its doc justified that with "these helpers emit at most a few hundred KiB, well under any real pipe pressure". A pipe holds 64 KiB. Anything past that blocks the helper in `write()`, so it never exits, the budget kills it, and a successful query is reported to the caller as `TimedOut` with its answer discarded. The busiest caller is the one that trips it: `pw-dump` on a populated PipeWire graph clears 64 KiB routinely and is polled from the 45 s gamescope loops. Confirmed empirically — a child writing 1 MiB into an undrained pipe never exits. Both pipes are now drained on their own threads, concurrently with the wait. That makes the joins load-bearing, which exposed the second half: the Unix `tree::Guard` was an empty stub whose doc claimed `Child::kill` "already ends the only process there is". It never did for this crate's Linux helpers — `pkexec`, `systemd-run`, `systemctl --user` and the `sh -c` wrappers all fork — and a surviving grandchild holds the pipes' write ends, so a reader would wait for an EOF that never arrives. The child is now the leader of its own process group and the guard `killpg`s it, which is the Unix shape of the Job object the Windows half already used. Also gates `pf-frame`, `pf-gpu` and `pf-encode` to Windows: every use site of all three is `cfg(windows)`, and between them they dragged FFmpeg, ash and openh264 into the Linux build for nothing (sweep item 13.19).	2026-08-11 08:22:16 +02:00
enricobuehler	bde4276632	Merge pull request '0.27.0' (#159) from worktree-release-0270 into main ... chore(release): bump workspace version to 0.27.0 87 commits since v0.26.0. C ABI 17 -> 18 (additive), so a minor rather than a 0.26.x patch. The one red check is nix.yml's `flake` job: `bun run build` for punktfunk-web was OOM-killed (exit 137) inside the nix sandbox, twice, on two different runner hosts. It is not this diff -- main built the identical web sources in 32s, and this commit touches no file under web/ or packaging/nix/. nix.yml does not run on tags, so it cannot affect the release. Tracked as a memory-headroom problem in the gate #158 added. v0.27.0	2026-08-10 19:36:43 +00:00
enricobuehler	147bc82130	chore(release): bump workspace version to 0.27.0 ... 87 commits since v0.26.0. The number is forced rather than chosen: the C ABI moves 17 -> 18, and `scripts/ci/pf-version.sh` already reports PF_BASE=0.27.0. Fills in what `docs/releases/v0.27.0.md` and the `## v0.27.0 — in development` CHANGELOG section deferred to the bump -- the lead-in, the TL;DR, "Before you update", the version table and the commit count -- and merges in the work that landed without notes: the Windows Xbox HID pad, the Apple console-UI batch, and the v0.26.0 field repairs. Everything already accumulated on main is kept as written. Version table, all re-derived at HEAD rather than read off the diff: * wire 2 (unchanged), C ABI 17 -> 18 (ADDED symbol, not widened) * crate dirs 26 -> 27 (`punktfunk-encode-worker`), 39 members * gamescope `+pfhdr4` -> `+pfhdr5` (6 patches -> 7, the PipeWire UAF), pkgrel resets to 1 * driver proto 6, gamepad channel 3, plugin index 1, SDK 0.1.4, plugin-kit 0.4.0 -- all unchanged * `api/openapi.json` stays 0.25.0: it moves only on an API EDIT, and the last one (`6cffe29b`) predates the v0.26.0 tag. It is not a mechanical per-release bump. ⚠ `crates/pf-driver-proto` is NO LONGER byte-identical to the previous release -- it was through both v0.25.0 and v0.26.0, and the last two CHANGELOGs told packagers so. Three additive `device_type`s. Called out explicitly so a packager who has been skipping it stops. The Play whatsnew names the one real Android change (the OLED palette is Eclipse now; display name only, the stored `oled` id is unchanged so saved choices carry over) and is otherwise explicit that the release is host-side. `docs-site/.../running-as-a-service.md` claimed "0.26.0-2 revoked it everywhere". No such version exists -- the Arch registry goes 0.26.0-1 straight to 0.27.0 canaries -- and the corrected 0.26.0 packages shipped under the SAME version string, which is exactly why a machine that installed an early one was never offered the fix. Reworded to say that, since it is the reason this release matters to those users. Gates, all green on this commit: * `cargo fmt --all --check` clean * `cargo metadata --locked` resolves * `Cargo.lock` diff versions-only -- 72/72 changed lines, 36 crates * Play gate's own python3 arithmetic: 400/500 CHARACTERS, not byte-identical to any other release (`wc -c` misleads -- `•` is 3 bytes) * notes voice check: 1 hit, reviewed and kept -- `getcap /usr/bin/punktfunk-host` is a command the reader runs, the same class as the `usermod` line v0.26.0's notes carried * `docs-site` builds NOT DONE: no tag yet.	2026-08-10 20:51:45 +02:00
enricobuehler	30c47eb691	Merge pull request 'NixOS could not detect a graphical session at all — and the module was never checked by CI' (#158) from worktree-nixos-wrapped-comm-detection into main ... Reviewed-on: #158	2026-08-10 18:37:32 +00:00
enricobuehler	bd26949e0a	Merge pull request 'The library's hide button was invisible AND clickable — a corner nobody could see dropped games' (#157) from worktree-library-hide-affordance into main ... Reviewed-on: #157	2026-08-10 18:37:03 +00:00
enricobuehler	61dfc3dadc	Merge remote-tracking branch 'origin/main' into worktree-nixos-wrapped-comm-detection	2026-08-10 20:26:23 +02:00
enricobuehler	1befa8a2c4	docs(nix): bring the Nix docs in line with the module, and fix a stale claim they shared ... There are three places Nix is documented — the public docs-site, packaging/nix/ README.md, and packaging/README.md — plus the changelog. All had drifted. STALE CLAIM, and not only for Nix. install.md said the plugin runner's "user unit ships **disabled** — enable it once you have" something to run. That is true only of Arch and source installs: the deb postinst and RPM %post both `systemctl --global enable punktfunk-scripting.service`, and the Bazzite sysext bakes in a default.target.wants symlink (build-sysext.sh:113). bazzite.md carried the same claim about its own image. Both corrected, per channel, with the reason the default flipped — the library scanners are plugins, so a host without the runner can come up with an empty library — and the `mask`-not-`disable` opt-out the sysext's own comment documents. docs-site: * install.md NixOS — `desktopSession` in the example and explained, the runner no longer needs enabling, and the host/console line says what autoStart does. * running-as-a-service.md — "Restart the host with your desktop" documented the drop-in for packaged installs only; NixOS gets its one-liner beside it. * bazzite.md — the runner is started for you, not "isn't started". packaging/nix/README.md: * option tables gain `desktopSession`, `gamescopeHdr`, `gamescopePackage`, and the `punktfunk` group next to `input` (both are required — the udev rule chgrp's the vhci nodes and fails outright if the group was never created). * "what the module configures" gains the security.wrappers entry, and a note on why the capability sits on the encode worker and never on the host: a wrapper raises it into the ambient set, which lands it in the permitted set and fails KWin's /proc/<pid>/exe readlink identically to a file capability. * the appliance snippet no longer tells you to put pkgs.gamescope on PATH — gamescopeHdr does that with the patched build, and desktopSession is called out as the thing to leave off there. * a caveat recording that `nix flake check` does not check the module, and the two rules for editing module-check.nix (assertions stay pure Nix; assert list-valued unit fields on the lists, not the rendered text). packaging/README.md: the flake ships five packages, not "host + client". CHANGELOG.md v0.27.0: a NixOS section covering the comm/session-detection fix, the module changes including the scripting default flip as an explicit behaviour change, and the flake-check gap — plus the documentation bullets above.	2026-08-10 20:24:21 +02:00
enricobuehler	f8cde0adaf	feat(nix): actually check the NixOS module in CI, and close the sweep's open issues ... THE CI GAP. `nix flake check` does not check `nixosModules`. It forces the value and asserts it is a lambda taking an open attribute set — nothing more; nix's own source carries `// FIXME: if we have a 'nixpkgs' input, use it to check the module.` Measured: a flake whose module sets a nonexistent OPTION, references a nonexistent `pkgs` attribute AND calls a nonexistent `lib` function passes clean, printing `checking NixOS module 'nixosModules.default'... all checks passed!`. nix.yml's header claimed that leg covered the module; it never did, for the module's whole life — on a flake whose history is Nix regressions reaching main invisibly. Closed with `checks.<system>.nixos-module` (packaging/nix/module-check.nix): it evaluates the module against real nixpkgs in four scenarios (desktop, appliance, native-only, client-only) and asserts on the rendered systemd units. The assertions are PURE NIX so instantiating the check runs them — which means the eval-only `--no-build` leg CI already runs is sufficient, and no Rust is built. Stub fake-derivation packages keep it independent of punktfunk-host/-client and the from-source gamescope; crane and bun2nix are provably not needed (they are `throw`s in the wiring test and it still instantiates). 17 checks, including regression guards for every divergence the sweep found and for the KWin identification trap (host ExecStart must stay on the plain store path, never a capability wrapper, while the encode worker points AT the wrapper). Mutation-tested: 8 mutants, each re-introducing one real defect, all 8 rejected, baseline green. The suite already earned it once — its first run failed a correct module because systemd renders `After=` as one space-separated line, so those assertions now read the evaluated lists instead of the text. Also closed from the sweep: * services.punktfunk.host.desktopSession (new, default false) — binds the host to graphical-session.target, the declarative form of the punktfunk-host-desktop-session.conf drop-in. Without it a Plasma/GNOME restart leaves the host holding a Wayland socket and portal D-Bus connection that died with the old compositor: it still listens, still answers, and every session it then serves fails at capture. Off by default because an appliance may never reach that target and would be left permanently stopped. * scripting.autoStart now defaults ON, matching the deb postinst and RPM %post, which both `systemctl --global enable` the runner. It was opt-in here on the reasoning that the runner is inert until you add automation — which stopped being true when the game-library scanners became plugins. A NixOS host came up with an empty library and no obvious reason why. The module and README carried the superseded rationale verbatim; both updated. * A warning when the host is enabled and xdg.portal is not. A warning rather than `xdg.portal.enable = mkDefault true`, because enabling the portal service with no `extraPortals` backend is its own broken state and only the operator knows which backend their compositor needs. * punktfunk-gamescope gets a `build-gamescope` dispatch input. It is on the critical path of every host build (`gamescopeHdr` defaults true) yet nothing compiled it; it tracks nixpkgs' gamescope, so a flake.lock bump — not a change of ours — is what breaks it, and the first to find out would be an operator whose system rebuild fails. All .nix files reformatted with the flake's own declared formatter (nixfmt-rfc-style from the PINNED nixpkgs, not a channel's).	2026-08-10 19:57:10 +02:00
enricobuehler	e93947969f	fix(console): the hide button was invisible AND clickable — a corner nobody could see dropped games ... Hiding a library title shipped in 0.26.0 and was, in practice, unusable: the operator reported there was simply no button, then found it by CLICKING the empty top-right corner of a poster. Both halves of that are the same defect. The card's control row was `opacity-0` until `group-hover`, and `opacity-0` paints nothing while still HIT-TESTING. So the corner of every tile in the grid was a live hide button with no visual presence at all: a stray click there removed that title from every play surface — the client grid, the native clients, the GameStream app list — with nothing on screen having suggested a control was under the cursor. What read as "the button finally appeared" was the hide taking effect, since `hidden` is the one state that drops the `opacity-0`. The feature announced itself by firing. And the reveal rested on hover ALONE. `:hover` never fires on a touch screen, so on a tablet the hide control was unreachable by construction and discoverable only by the blind click above. The original commit spotted this hazard for UN-hide — it kept those controls always-visible so nobody could be stranded in the hidden state — but left the hide side hover-gated, which is the same trap one step earlier. So opacity and `pointer-events` now move together, always: whatever cannot be seen cannot be clicked. `pointer-coarse:` shows the row outright wherever the device has no hover to give, rather than making touch a second-class path. Keyboard reach is unchanged — `pointer-events: none` does not block focus, so tabbing in still trips `focus-within`, which now restores interactivity along with opacity. The eye icon also gains a `title`. On a scanned entry it is the ONLY control on the card, with no edit/delete beside it to read as a toolbar, and an unlabelled eye-with-slash is not a promise that a game is about to leave the library. Verified in the built CSS rather than by eye, because a variant that does not compile fails exactly like the bug being fixed: `@media(pointer:coarse)` emits both `pointer-coarse:opacity-100` and `pointer-coarse:pointer-events-auto`, and it lands at the END of the sheet — media queries add no specificity, so this tie against the base `.pointer-events-none` / `.opacity-0` is won on source order, not by accident. The `group-hover:` and `focus-within:` forms compile to `:is(:where(.group):hover *)` and `:focus-within`, carrying a pseudo-class each, so they win on specificity outright. Console: tsc clean, production build clean, biome clean on the touched file, i18n 633 messages across en+de.	2026-08-10 19:55:13 +02:00
enricobuehler	159bbdbfc2	fix(nix): port three NixOS-module divergences from the shipped systemd units ... A sweep of the Nix packaging against the units the deb/rpm actually install found three decisions that were made, documented and deliberate everywhere else, and simply not carried into packaging/nix/nixos-module.nix. punktfunk-web — StartLimitIntervalSec=0. The unit's EnvironmentFile for the mgmt token is mandatory ON PURPOSE, so the console genuinely fails until the host's first `serve` writes it. systemd's default rate limit (5 starts / 10 s) against RestartSec=2 then gives up permanently after ~10 s — which on an appliance is exactly the window before the host is ready, so a console enabled before the host's first run stayed dead until someone restarted it by hand. scripts/punktfunk-web.service has carried the override since that defect was found; the Nix module omitted it while its own comment went on promising "Restart retries until the host has created it". punktfunk-web — Restart=always, not on-failure. A console that exits 0 has still stopped serving, and on-failure leaves it down. Matches the shipped unit and web-run.cmd on Windows, both of which relaunch bun on ANY exit. An explicit `systemctl --user stop` is unaffected. punktfunk-scripting — the sandbox was missing entirely. The shipped unit confines the runner with NoNewPrivileges, ProtectSystem= strict, ReadWritePaths=%h /tmp and an AF_UNIX/AF_INET/AF_INET6 address-family restriction, plus PrivateTmp=no (a field report: a private /tmp hides /tmp/vhclient and /tmp/.X11-unix, so a plugin launches its vendor binary and then cannot reach the daemon behind it). The NixOS unit had none of it — so the one unit here that executes arbitrary operator TypeScript by design ran strictly LESS confined on NixOS than on every other channel. Verified by evaluating the module against the pinned nixpkgs and rendering the units: assertions clean, cap_sys_nice=ep on the encode-worker wrapper, firewall 47984/47989/47990/47992/47993/48010, and each unit carrying exactly the directives above. That evaluation is NOT something CI does — measured: `nix flake check` passes a nixosModule containing a nonexistent option, a nonexistent pkgs attribute and a nonexistent lib function, printing "checking NixOS module ... all checks passed!" while never evaluating it against nixpkgs. nix.yml's header claims that leg covers the module. It does not; tracked separately.	2026-08-10 19:27:14 +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	88c1e94d94	Merge pull request 'A takeover's mask no longer bars the box's own way back into Game Mode' (#156) from worktree-worktree-gamescope-unmask-midstream into main ... Reviewed-on: #156	2026-08-10 16:23:44 +00: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	e283f17ab4	Merge pull request 'Apple: a Shortcut or a home-screen widget jumps straight into a host's game library' (#155) from worktree-apple-shortcuts-library-widget into main ... Reviewed-on: #155	2026-08-10 14:56:19 +00:00
enricobuehler	1fc184516a	feat(apple): the browse route is real — a Shortcut or a widget jumps straight into a host's library ... The reserved punktfunk://browse/<host-ref> route now routes on Apple: it drives the same libraryTarget every internal surface writes, so the link lands in whichever presentation the current mode owns — the gamepad console's in-place library screen, the touch cover, the macOS sheet, or tvOS's cover. Connect's posture minus the connect: a pin conflict refuses, a live session is never preempted, an unsaved host gets a notice (the library rides the paired mTLS identity, so there is nothing to browse before the host is saved). browse ignores launch=/profile= — nothing streams until a title is picked, and that connect resolves its own profile. On top of the route, the two new front doors: - OpenLibraryIntent ("Open Game Library") beside Connect/Wake/End in Shortcuts/Siri/Spotlight, host-parameterized like the others and round-tripping through the URL — one router, no second path. - A configurable library widget (kind "PunktfunkLibrary", AppIntentConfiguration over HostEntity — the configuration the HostEntity doc comment anticipated): pick a host, tap into its library. Unconfigured it follows the most recent host; a configured host that was removed shows the empty state rather than silently following a different host. Same .never timeline + HostStore push as the hosts widget, now reloading both kinds. DeepLink.browse(host:) is the one emitter both doors share, covered by a round-trip test beside connect's; the parse side was already in the grammar and the vector file. Docs updated (clients, game-library, profiles-and-links).	2026-08-10 14:11:01 +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	5ca0dfdcd2	fix(apple): stream audio coexists with Music instead of fighting it ... Field report, with a competitor cited doing it right: connecting to a host PAUSED the user's Apple Music, and resuming Music mid-stream silenced the stream's audio for good. Both are one defect — the audio session was EXCLUSIVE. Activating it evicted whoever was playing (the pause at connect), and Music's resume evicted us right back; iOS stops the engines on that interruption and restarts nothing, so the stream stayed silent until reconnect. `.mixWithOthers` on every category path (playAndRecord, playback, tvOS) is the heart of it: a mixable session interrupts nobody at activation and is not interrupted by another app's mixable playback — game audio rides over the playlist, the way a console does it. The trade is that a mixable session is nobody's Now Playing app, so the lock screen keeps showing the music. For a game stream that is the correct reading. The other half is `installInterruptionObserver`: interruptions still exist for a mixable session — a phone call, Siri, an app claiming a NON-mixable session of its own — and ending one restarts nothing by itself. On `.ended` the observer re-runs the full activation (an interruption can drop the category, and the earpiece steer is per-route) and revives the engines through the same conservative `reviveStoppedEngines` the route-change and media-reset observers already use — unconditionally, not only on the `.shouldResume` hint: a live stream is the one case where the user's intent to keep hearing it is not in doubt, and the revive already declines when playback never went down. The teardown's `.notifyOthersOnDeactivation` stays as a courtesy for the edge where an old exclusive install interrupted something; a mixable session has nobody to notify. macOS build (session paths are #if'd out there), tvOS typecheck, 284 tests.	2026-08-10 12:47:05 +02:00
enricobuehler	a14b000c9b	feat(apple): the tray gradient blur is back — as a real blur this time ... The form screens' pinned title and legend lost their gradient blur when GamepadTrayScrim went (2590238b): the scrim was `.ultraThinMaterial`, and a material by definition lifts and tints whatever it blurs — it read grey over the aurora, and washed with the palette's ground it read coloured. There is no public way to blur a backdrop without that tint, so the layer was deleted rather than re-tuned, and the rows have scrolled to a raw edge since. Glur's GlurView blurs the backdrop through a gradient with NO material stage on top — the rows soften as they slide under the pinned trays and nothing carries a colour. Three things about the adoption are deliberate: - It is the library's GlurBackdrop product, which uses a private API (a variable-blur CAFilter on UIKit/AppKit). The public `.glur()` modifier is a Metal shader on a view's OWN content and silently no-ops over platform-backed views like ScrollView, so it cannot reach a backdrop at all. GlurBackdrop ships as a separate module precisely so adopters can weigh the App Store exposure; it disables hit testing itself, so the band never eats a touch. - The dependency is pinned by REVISION: GlurBackdrop exists only on main — no release carries it (the newest tag, `1.1`, predates it and is not three-component semver anyway, so `from:` resolution stops at 1.0.4, which doesn't have the product). Wired into BOTH manifests — the package for `swift build`, and the xcodeproj (remote package reference + per-target product deps) for the app targets, which compile these sources themselves and know nothing of Package.swift's dependencies. - The band takes NO content-side overhang, unlike the scrim it replaces — and dropping the scrim's hard-won -44/-72 runway is the point, not an oversight. That runway existed because a material carries body at every alpha and had to dissolve OUTSIDE the tray; carried over here it blurred fully-visible rows at rest (first on-glass verdict). Glur's ramp reaches literal zero, so the band ends exactly at the tray's layout edge: open content untouched, rows soften only where they actually slide under. The 80 pt outer bleed and the pinned shape (`transaction { $0.animation = nil }`) are kept — full-bleed by LAYOUT rather than `.ignoresSafeArea()`, so a push never shows the band growing into place. Mounted exactly where the scrim was: settings, add-host and pair trays (top + bottom) and the library title (top). Glur is attributed on the Acknowledgements screen alongside the bundled font — it is a Swift package, so the Rust-closure notices generator rightly knows nothing about it. macOS build, tvOS typecheck; band placement and the blur itself verified on the iPad on glass.	2026-08-10 12:46:45 +02: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	548eb4fa14	Merge pull request 'gamescope aborted on every connect — a PipeWire use-after-free wearing an "unreachable" assert' (#152) from worktree-gamescope-pipewire-buffer-abort into main ... Reviewed-on: #152	2026-08-10 10:45:05 +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	bac63059a9	feat(apple): drive the console UI from a hardware keyboard ... Asked for by a field user: "make the iPadOS client compatible with keyboard to select games with keyboard arrows, enter to launch". An iPad on a Magic Keyboard and a couch Mac are the same situation the console layout was built for — a screen driven from a distance with a fixed set of directional inputs — and the cursor/confirm/back model already exists here for the pad. A keyboard is a third input onto it, not a new navigation scheme: arrows move, Return and Space activate, Esc backs out, everywhere the controller already worked (carousel, menu lists, prompts) plus the plain poster grid. `active` mirrors each caller's existing controller gate rather than being a second, parallel notion of "who has input". Without that, a launcher sitting under an open screen would keep eating key presses and navigate behind it — the same defect the pad gate exists to prevent. Esc returns `.ignored` when a screen has no back action, so it still reaches the `.cancelAction` shortcut that closes a macOS sheet. The plain grid needed real arithmetic rather than a flat index. It renders up to TWO `LazyVGrid` sections (launchers above titles), so a flat index steps by the wrong amount at the boundary whenever the first section's last row is partial — up from the titles' first row lands mid-launcher-row instead of above. `LibraryGridNav` moves within a section and hands off at its edges preserving the column, clamping into partial rows. It lives in PunktfunkKit because it is edge-case arithmetic and that is the target tests can reach; 12 cases cover the partial row, the hand-off, a stale cursor, an empty grid and a zero column count. The column count comes from the grid's MEASURED width run through `.adaptive`'s own fitting rule, so up/down move exactly one visual row instead of a guess that drifts with window size. Measured via a background GeometryReader — a sibling inside a ScrollView would claim the whole viewport. The grid cursor starts nil and only appears on the first arrow press, so a touch user is never shown a selection they didn't ask for. tvOS is excluded throughout: its focus engine already routes hardware arrows, and these screens hand it navigation authority deliberately. 17 PunktfunkKit tests pass; macOS + tvOS typecheck; launcher and settings verified rendering and navigating in the iPad Pro 13" simulator.	2026-08-10 09:59:28 +02:00
enricobuehler	3daead7d71	fix(apple): the sub-screens' legends sit where the launcher's does ... Carries the display-corner inset (previous commit) through the three screens that pin the same legend pill — settings, add-host, pair — so they don't drift from the launcher the moment the user opens one. Each of those trays is `maxWidth: .infinity, alignment: .leading`, so the pill is left-aligned there too and the iPad's short centre indicator is never in its way; the keyboard tray sits ABOVE the legend in the stack, so pulling the tray down doesn't put keycaps over the strip. And the settings tab strip now takes its padding from the row metrics instead of two fixed numbers. It was the other half of the iPad sizing complaint: the tier work grew the fields under it while the tab pills stayed at phone scale, which read as a tab bar that belonged to a different screen. macOS + tvOS typecheck. Re-landed on the probe spelling: the corner inset is read from `\.displayBottomInset` (DisplayBottomInsetProbe via ContentView), never asked of UIKit during body — the original spelling froze the update graph of any view that called it on device (see the legend-pinning commit).	2026-08-10 09:59:25 +02:00
enricobuehler	18d0009c35	feat(apple): the trust prompt takes controller input ... Trust-on-first-use had no pad wiring at all, and it appears at the worst possible moment for that: mid-connect, with capture already disabled so ContentView can blur the stream and stop forwarding. A pad-only user pressed A to connect, got this card, and found the controller in their hands doing nothing — the only way past was to reach for the screen. A trusts, B cancels, X runs the PIN ceremony instead. The legend only appears with a pad attached; naming controller buttons to a trackpad user would be describing hardware they don't have. `GamepadManager` is observed rather than read once so the bar arrives if a pad wakes up while the card is already open. Safe to poll unconditionally while the card is up: capture is off for its whole lifetime and the home screens are unmounted behind the session view, so nothing else is reading the pad. The A press that STARTED the connect is typically still held when this mounts — `GamepadMenuInput` adopts the held state without firing on start, so it doesn't auto-trust. tvOS is untouched: the focus engine already drives these buttons. macOS + tvOS typecheck.	2026-08-10 09:58:26 +02:00
enricobuehler	8ef5350431	fix(apple): pin the launcher legend to the display's corner ... On an iPad the controls pill sat two to three times further from the bottom of the screen than from the left, so it read as floating rather than tucked into the corner. `safeAreaInset` places its content INSIDE the safe area, so the pill's bottom margin was stacking on top of the device's own ~24 pt home-indicator inset while the leading margin had nothing to stack on. Subtracting that inset is the fix; GETTING the inset is where this commit's history is. Three spellings failed before this one, each silently: - a `GeometryReader` carrying `.ignoresSafeArea()` — a proxy reports no inset for an edge it has been told to ignore, so it can only answer 0; - `.ignoresSafeArea(.container, edges: .bottom)` on the inset CONTENT, which does not move content the inset mechanism itself placed; - asking UIKit for the key window (`UIApplication.shared.connectedScenes…`) DURING body — which answers the right number and then KILLS the asking view. On a physical iPad (never the simulator) that walk re-enters UIKit layout mid-render and SwiftUI silently severs the view's update graph: from then on every `@State` write lands in storage without `body` ever running again. That is exactly how Settings and Add Host stopped opening while their triggers kept firing and `showSettings` kept reading true — no AttributeGraph warning, nothing in the log. Found by bisecting device builds; a build that opens the screen programmatically renders green with input-driven navigation completely dead, so only a real press counts. So the inset is measured where it is knowable: DisplayBottomInsetProbe, a UIView that reads its WINDOW's inset from UIKit's own callbacks (didMoveToWindow / safeAreaInsetsDidChange / layoutSubviews), hops out of the current update, and publishes through `\.displayBottomInset` from ContentView. The legend reads the environment — proven safe on glass — and `gamepadLegendBottomPadding` is pure arithmetic. Tablets only. The padding goes negative to pull the pill back down through the indicator strip, which is safe there because the pill is left-aligned and an iPad's indicator is a short bar in the middle. A phone's indicator is taller and its legend runs most of the width, so the same move would cross it — phones keep the plain margin, and the tier comes from the size classes, so an iPad in a narrow Stage Manager window is treated as the in-hand case it is. macOS + tvOS typecheck; margins and Settings/Add Host opening from a real controller press verified on the iPad itself.	2026-08-10 09:58:20 +02:00
enricobuehler	522ac7bd49	feat(apple): the connect path's modals are pad-navigable ... `.alert` and `.confirmationDialog` are UIKit/AppKit surfaces: a game controller cannot move through their buttons or press one. On iOS/macOS that made every prompt in the connect path a dead end for a pad-only user, and they are not incidental prompts — "Pairing required" is the FIRST thing an unpaired host shows (so pairing was unreachable before it even got to a PIN), "Connection failed" strands the console UI behind a modal only a finger can dismiss, and "Waiting for approval" owns the only Cancel for a connect that may never complete. GamepadPromptView renders those states as a console card with a focus list of actions; the system alerts stand down while it is up. tvOS keeps them — the focus engine drives them natively there, which is exactly why this gap was invisible from that platform. Two things are deliberate rather than incidental: The gate is "not STREAMING", not `model.connection == nil`. A connection object exists well before a stream does — through the pair-required and approval handshakes, precisely when these fire — so gating on the connection would hand those cases back to the system dialog. Streaming is the one state that must keep the alert: there the pad belongs to GamepadCapture. And the overlay hangs off `driven`, not `home`, for the same reason: `home` renders only while the connection is nil, so a prompt mounted there would be skipped in the very case it was written for. The launcher stands down from the controller poll while a prompt is up (`promptActive`) — without it the host carousel keeps scrolling underneath the modal and one A press reaches both. macOS + tvOS typecheck; console UI verified opening Settings in the iPad simulator with the prompts wired in.	2026-08-10 09:56:25 +02:00
enricobuehler	8ab4918923	fix(apple): the host strip stopped flashing as it settles ... Reported from the iPad: the cards arrive, come to rest, and then flash. They did — and it was not the motion. Every card sat at the WRONG fill for as long as the entrance animation ran, then snapped to its real one in a single frame once SwiftUI tore the animation down, roughly a third of a second AFTER the last card had stopped moving. `rotation3DEffect` was the cause. A real 3D transform renders its subtree through an offscreen layer, and these cards carry translucent glass, which resolves differently in there — so the strip showed the aurora through itself for the duration and went opaque the instant the layer was dropped. Measured on an iPad Pro 13", sampling the centred tile: it held #4a3d87 across twelve frames in which nothing moved, then stepped to #423970 — 23/255 of blue in one frame, on every card at once, while the backdrop beside them stayed exactly #713fa0 throughout. Stretching the timeline from 1.02 s to 2.82 s moved the step from 0.70 s to 2.50 s after launch: the same 0.32 s before the end in both runs, which is what proves it is the animation ENDING and not any state the tiles were waiting on. Deleting the rotation deleted the step outright. `compositingGroup()` above and below the transforms each changed nothing, so this is the 3D layer specifically, not compositing in general. The turn is now projected instead of rendered: cos(angle) as a horizontal squeeze IS the orthographic projection of a Y-axis rotation, hinged on the edge the card fans from — which also puts the code behind the doc comment that already described the fan that way (the sign of a rotation carried it before; cos is even, so the anchor has to). Affine, so there is no offscreen pass and no layer to drop. What's lost is the perspective trapezoid, which at card size was never what sold the motion; the fan-out, the stagger and the overshoot are untouched. Also drops the temporary PUNKTFUNK_DIAG_OPEN hook that gated each step of this branch in the simulator. 284 tests pass; macOS + tvOS typecheck; entrance re-recorded on the iPad Pro simulator — the tile now settles monotonically (#4153cf → #383c77 → #39396e → #393a6e) and holds, with the fan-out still reading as a turn.	2026-08-10 09:36:02 +02:00
enricobuehler	09bac99090	feat(apple): pairing you can actually do with a controller ... PairSheet is a `Form` with two `TextField`s. On tvOS the focus engine drives those natively, but on iOS/macOS a controller cannot reach a text field, type into it, or press the button underneath — so for anyone in the console UI, pairing (the ONE thing between a fresh install and a first stream) ended at "now touch the screen". GamepadPairView is the same ceremony in the gamepad UI's own vocabulary: the vertical focus list the settings and add-host screens use, A on a field to open GamepadKeyboard in a bottom tray, B to peel one layer. It mirrors GamepadAddHostView field for field, because it is the same interaction and someone who has added a host should recognise it immediately. The ceremony itself moved to a shared `PairCeremony` used by both presentations, so they can never disagree about what a wrong PIN means, what a host rejection says, or when a late result must be discarded. On iOS it is a shell layer like settings and add-host, and it LEADS the shell's screen order: it blocks a connect the user already asked for and can be raised from on top of the library (launching a title on an unpaired host), so it has to win; backing out reveals whatever it interrupted. macOS has no shell, so its sheet switches content by mode instead. tvOS is untouched. macOS + tvOS typecheck; console UI verified opening Settings in the iPad simulator with the pair screen wired into the shell.	2026-08-10 08:12:50 +02:00
enricobuehler	5db3b3c4fd	feat(apple): the controls legend is clickable ... Every hint cell that names an action is a real button on iOS/iPadOS/macOS. The legend already lists every action a screen has, in one fixed place, so a user without a pad in their hands — an iPad on a stand, a Mac driven by trackpad, anyone running `gamepadUIMode == "always"` — was reading a complete menu they could not press. tvOS keeps them inert deliberately. There is no pointer there, so a tappable cell would have to be FOCUSABLE, and that puts six new stops in the path of a focus engine whose flow on these screens is load-bearing and hard-won — while every action in the legend already has a native route (select, Menu, Play/Pause, the focusable tab pills). Cells that name an INPUT rather than an action stay labels: "↔ Adjust" is the stick itself, and "A Type" over the on-screen keyboard has no tap equivalent because a touch user types by tapping the keycap. Two details that are load-bearing rather than tidy: the decorative hairline gets `allowsHitTesting(false)` (it sits on top of the cells), and the press style's `contentShape` sits below its `scaleEffect` so shrinking the artwork cannot move the target out from under a resting finger and lose the touch-up. macOS + tvOS typecheck; 272 tests pass; console UI verified opening Settings in the iPad simulator.	2026-08-10 08:05:14 +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	ffb1ecfebe	feat(apple): size the console UI for the iPad ... GamepadFormMetrics had exactly two tiers, tvOS and everything-else, so a 13" iPad Pro drew its settings rows, section tabs and legend at iPhone scale in the middle of a very large display — the field verdict was that the sizing "does not adapt to larger screens". There is a third tier now, between the in-hand and 10-foot sets. Chosen from the SIZE CLASSES, not the device idiom: an iPad in a narrow Stage Manager or Split View window keeps the in-hand numbers, because what is being read is the window, not the panel behind it. Phone sizing is untouched. Published from ContentView — the app root — rather than only from `gamepadPaletteInk`. A screen that applies that modifier itself sits ABOVE its own copy of the environment, so its `@Environment` resolves against its parent and would read the bare phone default no matter what the modifier published. The screenshot harness publishes it too, for the same reason: it mounts these screens with no ContentView above them, so an iPad capture used to render the whole gamepad UI at iPhone scale. macOS + tvOS typecheck; the console UI verified in the iPad simulator opening Settings at the tablet tier.	2026-08-10 07:44:36 +02:00
enricobuehler	08e462fee9	fix(apple): Graphite's selected settings tab was white on light grey ... The tab strip's selected pill is FILLED with the palette accent, and `ink.onAccent` — chosen by that accent's own luminance, and documented for "a filled pill's label" — has existed for exactly this since the palettes landed. The strip was using the plain foreground instead, which is white on every dark palette and therefore looked fine on all but one: Graphite's accent is a light grey (luma ≈ 0.80), so its selected tab read white on white.	2026-08-10 07:41:43 +02:00
enricobuehler	2590238b8f	fix(apple): the console sub-screens' backdrop, glass and option band ... Four things the field reported on glass, all in the console's visual layer. The tray scrim is GONE, not re-tuned. It laid `.ultraThinMaterial` across the top and bottom of every form screen, and a material by definition lifts and tints whatever it blurs — so it read grey, and washing it with the palette's ground only made it read coloured. There is no public way to blur a backdrop without that tint, so the layer had to go. The darkening it also provided was never its to provide: the backdrop's own legibility scrim (0.38/0.06/0.08/0.40 — the same gradient pf-console-ui bakes into its shader) has always been one layer down, which is why the console has no tray band. Pale palettes rendered every row, pill and card as a flat white slab, and lowering the tint did nothing, because the opacity came from the glass BODY: `.regular` is a bright, high-body material and a pale palette's `ink.glass` is literal white. Pale palettes take `Glass.clear` now, with a light wash to keep dark ink legible. A focused settings row changed colour in a hard jump, a beat late, while its scale animated smoothly beside it — the focus tint rode `Glass.tint`, and a Glass value is opaque to SwiftUI's animation system. It is a plain fill between the glass and the label now, so the existing animation covers it. The host cards appeared to be swapped for different ones as their entrance landed: `CardEntrance` swings each tile in on a rotation3DEffect, and Liquid Glass samples the backdrop through its own layer, which it cannot do under a 3D transform. Those tiles take the material path (`forceMaterial`). And the option band never turned like a cylinder because the band MASKED itself: a mask rasterises what it covers, flattening `rotation3DEffect`'s perspective, so the projection was computed and discarded every frame. The soft edge is folded into each option's own opacity instead. Its ±1 neighbours stay hidden at rest — showing them reproduced the documented overlap defect ("2752 × 2064" with "280 ×" through it), which is why they were dropped. Also fixes pale palettes washing out: the calm mix added a plusLighter wash of a near-white ground on top of a field already mixed toward it, saturating the form screens to white. macOS + tvOS typecheck; console UI verified opening Settings in the simulator, with no tray band.	2026-08-10 07:33:11 +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	90450ff1f6	feat(apple): the legends remember which pad you own ... `buttonGlyph` asked the LIVE controller for its `sfSymbolsName` and fell back to generic letter glyphs, so the moment a DualSense slept, disconnected or ran flat, every ✕/◯ hint turned into A/B under its owner's hands. Under `gamepadUIMode == "always"` — the console UI up with no pad by design — they were never right at all. GamepadManager now remembers the family of the last controller that was actually attached (`DefaultsKey.lastGamepadKind`, written on selection and deliberately never cleared on disconnect), and the legends resolve live → remembered → generic. Not a user-facing setting: a glyph-style picker is one more row asking a question the app can answer itself, and the remembered pad is right essentially always. GamepadGlyphs maps by POSITION, not by name, because that is what `GCExtendedGamepad`'s buttonA/B/X/Y are. So ✕ is role `.a` (the bottom button), and a Switch pad gets Nintendo's transposed labels rather than Xbox letters printed on the wrong physical buttons. The test asserts every symbol name RESOLVES on the running OS. That is the load-bearing one: `Image(systemName:)` draws an unknown name as nothing at all — no crash, no log, no red build — so a typo would silently blank a legend on device and no amount of building would catch it. macOS + tvOS typecheck; the 5 glyph tests pass; the console UI verified opening its Settings screen in the iPad simulator.	2026-08-10 07:29:33 +02:00
enricobuehler	890b67a863	fix(validation): v5 called jitter a leak — a leak is a trend, not a spread ... v5's verdict was `max - min` over the sampled fd counts with a default tolerance of 0. An encode worker's fd count legitimately moves by one when a dmabuf fd is in flight at the sampling instant, so the spread was permanently 1 and the leg failed on a perfectly healthy box — reported, like every red leg here, as "a shipping blocker, not a flake". Measured on home-nobara-1 (KDE, RTX 5070 Ti), 33 samples over 480 s: 54 54 54 54 54 54 54 54 55 55 54 54 54 55 54 54 55 54 54 54 55 54 …54 It oscillates and ENDS on 54, exactly where it started. Nothing accumulates. The replacement is median-of-thirds: median(last third) - median(first third). That is strictly MORE sensitive to what R2 is actually about — a steady leak moves the trend just as much as it moves the spread, while bounded jitter moves only the spread — so this is not the tolerance being widened to get a green. The spread is still printed, now labelled as jitter when the trend is flat. The warm-up window already covers the one-off first-sight-of-each-buffer cost, so a plateau inside it is by design not a leak; a step that never comes back still trends and still fails. The self-test grows the cases that force this to be a real assertion: the measured oscillation must trend to zero, a synthetic leak must still trend up, a flat series must be flat, and a step that never returns must be caught. Writing them is what caught my own arithmetic — the first draft asserted a leak trend of 12 where the reader correctly says 10. Also records what the v5 log now makes obvious: `--minutes` does NOT set the wall clock. `spike` is frame-count bounded (`seconds * fps`), and a KWin virtual output being driven hard delivers ~197 fps against a `--fps 60` budget, so a "10 minute" run ended after 182 s. Ask for more minutes than you want.	2026-08-10 03:04:05 +02:00
enricobuehler	9cdbfabd4d	fix(validation): v4.e demanded a rung the spike vehicle cannot reach ... v4.e killed the worker mid-session and then required "the encode worker died mid-session" in the spike's log. That line, and the respawn that follows it, are emitted by `RemotePyroWave::reset` — and the only caller of `Encoder::reset` is the real session's `reset_stalled_encoder` loop in native/stream.rs. `spike` is a dev tool with no recovery loop at all: it does encoder.submit(&frame).context("encoder submit")? and exits. So a worker killed under the spike can never reach reset, the line can never appear, and the leg reported FAILED — a red leg here is a shipping blocker, not a flake. for a ladder rung the product implements correctly. A false negative in the one place that must not have one: this kit exists to refuse false PASSes, and a false FAIL spends exactly the same credibility. Verified on glass first, so the rung is not being excused on a reading of the source. home-nobara-1 (KDE, RTX 5070 Ti), real client session, worker pid 44249 killed with -9: `video_streaming` stayed true across the kill, and the host logged pyrowave: respawned the encode worker after a mid-session death worker=/usr/bin/punktfunk-encode-worker priority=Granted(Realtime) encoder submit failed — encoder rebuilt in place, forcing an IDR error=... Broken pipe (os error 32) reset=1 max=5 v4.e now asserts the half the spike can actually observe — the death surfaces as an ATTRIBUTABLE worker-IPC error naming the worker, after real encode windows, and the host process does not die with it. A hang, an unexplained failure, or a dead host still fails. The respawn half is printed as the human follow-up, in the same idiom v1 already uses for its on-glass half, and written into `recipe` with the two commands that close it.	2026-08-10 02:38:55 +02:00
enricobuehler	fdef4c90ce	fix(gamescope): stop the PipeWire use-after-free that aborted a session on every connect ... A managed gamescope session on Nobara 44 (VM 123) died on essentially every client connect. The visible symptom was a black screen; underneath, `punktfunk-gamescope` was SIGABRT crash-looping — 11 coredumps in three minutes — until `gamescope-session-plus` ran out of retries and came up on the *stock* `/usr/bin/gamescope` at its default 1920x1080, which looks like a working game mode and carries none of our capture patches. punktfunk-gamescope: ../src/pipewire.cpp:88: void destroy_buffer( pipewire_buffer*): Assertion `false' failed. #4 __assert_fail #5 destroy_buffer(pipewire_buffer*).cold The abort is a use-after-free wearing an `assert(false); // unreachable`. `pw_buffer->user_data` is associated with its `pipewire_buffer` in exactly one place, at the bottom of `stream_handle_add_buffer` — after all four `goto error` paths, whose label is a bare `delete buffer`. And `stream_handle_remove_buffer` clears `buffer->buffer`, the only route back to the `pw_buffer`, while a still- `copying` buffer is deleted later on the steamcompmgr thread with no way to reach the slot. PipeWire recycles `pw_buffer` slots across renegotiations, so the next remove reads `buffer->type` out of freed memory, falls off the end of the switch and aborts. The host sets the session to the client's mode on connect, and that mode change is what renegotiates the stream — which is why "every connect" was the trigger. Patch 0007 fixes the association rather than the symptom: set `user_data` at allocation so it is valid on every path out of `add_buffer` and clear it on the error path; clear it in `remove_buffer`, the last point both halves are known; null-check the two consumers. The `default:` arm then logs instead of aborting. Offered upstream — nothing about it is punktfunk-specific. Two traps this cost time on, both now written down in the README: * It is NOT HDR-specific. The abort was first seen right after a 10-bit stream negotiated, so `PUNKTFUNK_GAMESCOPE_HDR=0` looked like a workaround. The failing argv carries no `--hdr-enabled` at all. * `gamescope-session-plus` hides it by falling back to stock gamescope, so a session existing proves nothing — read the banner. `.pfhdrN` moves to 5 even though no capability moved: every deployed pfhdr4 binary crash-loops, so an operator needs to be able to tell them apart. All `>=` thresholds in the host's probe are unaffected. Also documents `libstdc++-static` as a build dependency — it is punktfunk's requirement (the script links the C++ runtime statically on purpose), so no `dnf builddep` will ever pull it, and without it meson fails with a message naming neither the flag nor the package. Verified on VM 123 with the patched binary installed: 5 rapid connect/ disconnect cycles plus 3 further sessions, zero new gamescope coredumps (43 before, 43 after), Steam game mode streaming real content at 5120x1440, and `/tmp/chimeraos-short-session-tracker` never created — the short-session latch that used to strand the box in plasma was downstream of this crash.	2026-08-10 02:16:22 +02:00
enricobuehler	8508f8f3c3	Merge pull request 'The gamescope bind is armed on every gamescope box, takes a user namespace that breaks Xwayland, and leaves a drop-in that bricks the next boot' (#151) from worktree-bind-userns into main ... Reviewed-on: #151	2026-08-09 22:41:40 +00: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