2797 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
enricobuehler	5cbaca7789	feat(client/pads): stop forwarding the pad while the Steam overlay owns it ... On a Deck in Gaming Mode the Steam menu and the QAM are driven by the SAME physical controller the client forwards, so opening either one moved the game on the host as well as Steam's UI — a second, invisible player. Steam Input masks a normal game here; it cannot mask us, because masking happens on Steam Input's virtual pad and we deliberately forward the REAL one (28DE:1205 — the virtual pad has no gyro, trackpads or paddles). SDL ships the exact behaviour we want and it is on by default: presses are dropped while the process has windows but no keyboard focus, releases still get through. It CANNOT fire on a Deck. gamescope resolves focus per Xwayland ctx and the client sits alone in its own, so the Steam overlay — which lives in the root ctx — never takes our X focus away and no FocusOut is ever generated. Measured on glass: with the QAM open, X input focus inside the client's ctx stayed on its window for the whole 4 s, while GAMESCOPE_FOCUSED_APP flipped to 769 (Steam) and GAMESCOPE_FOCUSED_APP_GFX stayed on the app. So the signal is explicit. `overlay_focus` watches those two atoms on the gamescope root ctx — which is NOT our own $DISPLAY under `--xwayland-count 2`, hence the socket-directory walk and the flatpak filesystem line — and the presenter ORs it with window focus into one `set_masked`. Masking is deliberately not `set_forwarding`: that closes the slot and sends GamepadRemove, so the game would see a controller UNPLUG every time somebody opened the QAM. This keeps every slot open and only stops the transitions, after flushing what the host believes is held so a stick deflected at overlay-open stops steering instead of freezing at its last value. On the way back, held buttons are adopted rather than replayed — the A that picked a QAM row must not fire in the game as it closes — while axes are re-sent, since a stick has no press to ghost and SDL only speaks on change. Fails open throughout: no gamescope, no X, or an unreadable signal all leave forwarding exactly as it was. `PUNKTFUNK_OVERLAY_MASK=0` opts out.	2026-08-09 00:55:16 +02:00
enricobuehler	54666e66da	Merge pull request 'The Apple TV client had no way to show its statistics overlay' (#125) from worktree-tvos-stats-shortcut into main ... Reviewed-on: #125	2026-08-08 21:48:19 +00:00
enricobuehler	bed58b75b6	feat(apple): the statistics overlay is reachable on tvOS ... An Apple TV session had no way to the stats overlay at all. Every other client cycles it in-stream — Ctrl+Alt+Shift+S on the desktops, a three-finger tap on touch — and tvOS has neither a keyboard nor a screen to tap, so the only route was Settings before connecting (or a profile). The docs' own "cycle with" table simply had no row for it. Two surfaces, because an Apple TV may have a controller in the room or only the remote: - Select + X on a controller, cycling one tier per completion. Built like Android's mic chord (Select + Y) and deliberately disjoint from the escape chord — X is none of its four buttons, so reaching for one can never trip the other. Read off the wire mask like the escape chord, so a Select the hold-Select gesture has turned into a guide can't cycle the overlay on its way past. Available on every Apple platform: a controller in both hands is exactly the case the keyboard combo and the three-finger tap can't serve. - Hold Play/Pause on the Siri Remote. Its right-click is therefore deferred until the press resolves — a tap still right-clicks, delivered on release with the release trailing by TAP_PRESS — because a right button held for half a second is a context menu on every desktop this streams. A non-forwarding slot now claims the stats chord's elements too, alongside the escape chord's: on tvOS an unclaimed button's press stays the system's and the chord would silently never complete. Tests pin both chords' masks against their GameController alias lists, that the two overlap only on Select, and that the claim list covers both without duplicates — the failure mode is nothing happening, with nothing logged.	2026-08-08 23:24:09 +02:00
enricobuehler	ce31a9ddfd	Merge pull request 'The Steam Deck updater kept sabotaging its own next update, and hand-deleting a file was the only way through' (#122) from worktree-steamdeck-update-bunnix-dirt into main ... Reviewed-on: #122	2026-08-08 21:17:27 +00:00
enricobuehler	8fe834c89b	Merge pull request 'Every gamescope session ended in a SIGSEGV at exit — the Vulkan device was being destroyed after the driver had gone' (#124) from worktree-gamescope-exit-segfault into main ... Reviewed-on: #124	2026-08-08 21:13:43 +00:00
enricobuehler	9e7713eecf	fix(gamescope): every session ended in a SIGSEGV at exit ... Each gamescope-backed session left a coredump behind. It happened after the compositor had finished its work — "Primary child shut down!", then the crash — so the stream itself looked fine and it surfaced only as a steady drip of coredumps and a non-zero exit from the spawn. It is a static-destruction-order bug, not a race and not anything gamescope does wrong at runtime. `g_device` (CVulkanDevice) and `g_output` (VulkanOutput_t) were plain globals, so glibc ran their destructors from `__run_exit_handlers` once main() returned. Those destructors call back into the driver — `~CVulkanCmdBuffer` -> `vk.FreeCommandBuffers`, `~CVulkanTexture` -> `vk.Destroy*` — but the Vulkan ICD has already been torn down and unloaded by then, so each call jumps through a function pointer into an unmapped page. The faulting address equalling the instruction pointer is the signature: #0 0x00007fe8fd1d1070 in ?? () #1 CVulkanCmdBuffer::~CVulkanCmdBuffer at rendervulkan.cpp:1543 #9 std::vector<unique_ptr<CVulkanCmdBuffer>>::~vector (g_device+1792) #10 CVulkanDevice::~CVulkanDevice at rendervulkan.hpp:768 #11 __run_exit_handlers / exit() Patch 0006 gives both globals storage that is constructed exactly as before but never destroyed; a union member is destroyed only if the union's destructor says so, and ours deliberately does not. Nothing needs freeing there — the process is exiting and the kernel reclaims the device, its command buffers and every GPU allocation. Both objects are needed: pinning only the device relocated the fault into ~VulkanOutput_t. The `.pfhdrN` level deliberately stays at 4. It is a capability tier the host probes before it spawns, and this patch adds no capability — bumping it would advertise a tier that does not exist. Per the PKGBUILD's own rule this ships as a `pkgrel` bump instead. Verified on an NVIDIA box, all six patches `git am`-ing onto the pinned upstream commit and then a RELEASE build (the shipped configuration): version banner 3.16.25-7-gea635c1+pfhdr4 (marker intact) patched, real spawn shape (2752x2064@120 --steam --xwayland-count 1) 6/6 exit 0 distro control, same shape SIGSEGV Not filed upstream, though it is not punktfunk-specific and would apply as-is. Unrelated and left alone: `--xwayland-count 0` dies much earlier, in main() at wlserver.cpp:3215, dereferencing a null `gamescope_xwayland_server_t`. Punktfunk always spawns with `--xwayland-count 1`, so that path is never taken here.	2026-08-08 19:21:39 +02:00
enricobuehler	0cd946acb5	Merge pull request 'The virtual Steam Deck pad's udev rule names a group that four of six install paths never create' (#123) from worktree-steamdeck-group-and-secret-gaps into main ... Reviewed-on: #123	2026-08-08 16:00:47 +00:00
enricobuehler	62a6fa9fac	fix(packaging): create the punktfunk group everywhere the udev rule needs it ... 60-punktfunk.rules chgrp's the usbip vhci attach/detach nodes to a dedicated `punktfunk` group (security-review 2026-08-05 M-4: writing `attach` materialises an arbitrary emulated USB device, so it must not ride on `input`). Four of the six install paths shipped that rule in 0.25.0 without ever creating the group. chgrp then failed, the nodes stayed root:root 0644, and the virtual Steam Deck pad silently never attached — while `usermod -aG punktfunk` failed outright with "group 'punktfunk' does not exist". Affected and fixed: * arch — post_upgrade() called only _ensure_update_group, so every box that reached 0.25.0 by `pacman -Syu` missed it; post_install was correct. * nix — no users.groups.punktfunk at all, though host.users' own description already promised the usbip/vhci pad. Declares it now and adds host.users to both groups. * bazzite sysext — a group is host state and cannot ride an image, and the deb/rpm scriptlets that would create it never run there. * steamdeck install.sh/update.sh — handled `input` only. Both now create the group and join it: running that script IS the statement "make my Deck a host with native pad passthrough". deb and rpm were correct throughout (one postinst/%post for install + upgrade). Also on the Deck path: web.env secret hygiene. install.sh's `chmod 600` sat inside the create-only branch despite a comment calling it "the idempotent belt for a pre-existing file", and update.sh never touched the config dir at all — so an install set up once and only updated since kept web.env world-readable (0644) with the console password and session secret in it. Both scripts now harden ~/.config/punktfunk to 0700 and web.env to 0600 on every run, and say so loudly, because a chmod does not un-leak an already-readable secret: the password still needs rotating. Both group blocks are `if ensure_group ...` rather than `ensure_group || true`: a failed groupadd must not fall through to a usermod against a nonexistent group, which under `set -e` aborted install.sh after the long build and update.sh before the service restart (verified: exit 6, no restart). Docs: the group is now documented where people actually look — the per-distro guides, install.md, steamos-host.md, a new troubleshooting entry for "pad arrives as an Xbox 360 controller", and the uninstall pages. The 0.25.0 notes gain the "group does not exist" caveat and turn the password bullet from "consider rotating" into a real instruction, and CHANGELOG records the known issue against the breaking change that introduced it. Verified: bash -n on all four scripts; the arch scriptlet's post_upgrade driven in a container (creates the group, idempotent on re-run); the ensure_group helper and both membership branches, including a control that reproduces the original bug (chgrp to a missing group leaves the node root:root 0644); the find -perm /0077 probe across 0644/0640/0604/0600/0400 on GNU findutils; `nix flake check --no-build` (the exact CI gate) and a NixOS eval showing alice.extraGroups == ["input","punktfunk"]; docs-site build + typecheck.	2026-08-08 17:53:36 +02:00
enricobuehler	d402e9b996	Merge pull request 'A compositor pin silently vetoed dedicated game sessions — and a mid-bring-up mode switch was killing GNOME outright' (#121) from worktree-dedicated-session-pin-and-recovery into main ... Reviewed-on: #121	2026-08-08 15:38:39 +00:00
enricobuehler	f23e0df64c	fix(host): a compositor pin silently vetoed dedicated game sessions ... `PUNKTFUNK_COMPOSITOR` is documented as "which backend to drive", but it also quietly discarded `game_session=dedicated`: `resolve_compositor` gated the dedicated route on `!overridden` and logged nothing either way. A host whose pin was a forgotten validation leftover therefore went on displaying "dedicated" in the console while every launch landed in the desktop instead — for 30 days on the box that surfaced this, the only evidence being the ABSENCE of a log line. The pin still wins, since it is the operator's explicit hand-set knob, but it now says so and names itself. Two further holes the same triage turned up: - The pin put its backend into `available()` unconditionally AND skipped `apply_session_env`'s `XDG_CURRENT_DESKTOP` scrub, so `pick_compositor` could never return `None` — the one place `try_recover_session()` is called from. A pinned host whose gnome-shell had segfaulted therefore spent every connect on 8 doomed `RemoteDesktop.CreateSession: ServiceUnknown` retries while the operator's configured `PUNKTFUNK_RECOVER_SESSION_CMD` sat unreachable behind that arm. Liveness is now read on both paths, and a pin aimed at a dead session takes the recovery exit with an error naming the pin. `needs_live_session()` exempts gamescope, which stands its own session up — pinning it on a headless box stays supported. - A mode switch accepted before the pipeline existed was served the long way round: build at the now-stale mode, then immediately rebuild at the new one in the stream loop. That burns a display create, capture attach and encoder open on every such connect, and because the rebuild is deliberately create-before-drop it stands up two Mutter `RecordVirtual` monitors ~400 ms apart — which segfaults mutter 50.4 inside `meta_monitor_manager_rebuild` and takes down the whole desktop session, along with the game just launched into it (so the GAME looks like what crashed). Bring-up now adopts the newest queued mode and builds once, carrying over the H2/H3 correction ack that the replaced rebuild would have sent. Verified on a real Linux host (192.168.1.21, x86_64): `cargo clippy --workspace --all-targets --locked -- -D warnings`, `cargo fmt --all --check` and the punktfunk-host + pf-vdisplay test suites all clean. The gate was proved non-vacuous against a planted `compile_error!`.	2026-08-08 17:37:02 +02:00
enricobuehler	12f39e1967	fix(steamdeck): the updater stops dirtying the checkout it just pulled into ... `update.sh --pull` could abort with "Your local changes to the following files would be overwritten by merge: web/bun.nix" — before a single service was restarted — and the only way past it was to delete the file by hand. The updater did it to itself. web/bun.nix is generated (bun2nix, a pure function of web/bun.lock) but committed, because the Nix build fetches node_modules only from it. The web step ran `bun install --frozen-lockfile` without --ignore-scripts, so web's `postinstall` (`bun2nix -o bun.nix`) rewrote that tracked file on every update. Harmless while the committed file is in sync — but main carried a stale web/bun.nix from 1db8f763 to b79d90b4, so any Deck updated in that window had it rewritten to the *correct* content and has been sitting dirty ever since. The SDK step has always passed --ignore-scripts, which is why only web/bun.nix ever went dirty. Two changes, both in install.sh and update.sh: * the web install now passes --ignore-scripts and runs `bun run codegen` explicitly. web has two install lifecycle scripts and we want exactly one: `prepare` IS `bun run codegen` (orval + paraglide + the i18n check) and is required, since src/api/gen, src/paraglide and src/routeTree.gen.ts are gitignored and `prebuild` only re-runs orval; `postinstall` is the one that writes a committed file. Equivalent to the old behaviour minus bun2nix. * --pull restores web/bun.nix and sdk/bun.nix before pulling, which unsticks the installs already broken out there. Deliberately NOT `git reset --hard`: $SRC is the operator's own checkout and may carry real local work, so a still-dirty tree now fails with a message that names the files and the way out instead of git's raw abort. Discarding these two is provably lossless — regenerating them from the lockfiles is exactly what bun2nix does. CI already gates the drift that made this visible (scripts/ci/check-bun-nix.sh, ci.yml), so main cannot ship a stale bun.nix again.	2026-08-08 17:15:49 +02:00
enricobuehler	2a1c968a0e	Merge pull request 'A gamescope session told every game its display was 60 Hz — and Fedora had no way to install the build that knows better' (#120) from worktree-gamescope-virtual-display into main ... Reviewed-on: #120	2026-08-08 13:41:30 +00:00
enricobuehler	eb8c943572	feat(packaging): ship punktfunk-gamescope on RPM and apt too ... Until now the patched gamescope reached exactly four kinds of box: the Bazzite/Fedora-Atomic sysext, the Arch package, the SteamOS installer and a NixOS option. Everyone else was told to build gamescope from source. A traditional Fedora-family box — Nobara, plain Fedora, the HTPCs people actually stream from — therefore ran stock gamescope by default, which streams SDR, cursorless, and tells every game its display is 60 Hz. That is not a user error; there was no package to install. Both new packages REPACK the binary CI already builds rather than building gamescope again: it is a ~10-minute meson compile of an unrelated tree, cached per distro base because the binary is soname-coupled to it. The Arch PKGBUILD stays the one recipe that builds from source, because that is what makepkg is for. - packaging/gamescope/punktfunk-gamescope.spec + build-gamescope-rpm.sh. Version is derived from the binary's own banner (3.16.25.pfhdr4) — the only source that cannot drift from what is in the package. rpmbuild's automatic ELF Requires are what stop an f43 build installing on f44. - packaging/debian/build-gamescope-deb.sh, same shape, with dpkg-shlibdeps for Depends. - rpm.yml packages and publishes it beside the host RPMs; deb.yml gains a cached gamescope build (keyed on packaging/gamescope/** alone) and packages it into the existing publish loop. Both legs are best-effort, matching the sysext's existing rule: no binary, no package, and the host stays on its current SDR path. Neither package Provides or Conflicts with gamescope — it installs as /usr/bin/punktfunk-gamescope and only the sessions the host starts itself resolve it, so a box's own Game Mode keeps using the distro binary. Both refuse to package a binary without the +pfhdr marker. That marker is the host's entire capability probe, so a build that lost the patches would install fine and then silently stream SDR with no cursor. Verified: build-gamescope-deb.sh produces an installable .deb from a stand-in binary (correct version derived from the banner, 0755 tree, control fields) and exits 1 on an unmarked one. The .spec is not yet exercised — no rpm tooling on the box I had; CI's Fedora leg is its first run.	2026-08-08 15:36:19 +02:00
enricobuehler	102f550bba	feat(host): use the new gamescope capabilities, and say so when the mode is lost ... Pass --custom-refresh-rates (patch level 3+) and --pipewire-composite-external-overlay (level 4+) on both spawn paths, with the same probe-then-pass shape the HDR and cursor flags already use. A stock gamescope has neither flag and gets neither, which is exactly today's behaviour. New knob PUNKTFUNK_GAMESCOPE_REFRESH_RATES=60,90,120 widens the set a session offers in Steam's in-session display settings. The rate the session actually runs at is always included, so it can only add options; junk entries are skipped rather than failing the host, because the worst a typo can cost is the extra option the operator wanted. And the part that would have turned a week of field triage into one log line: warn_if_mode_lost(). --nested-refresh is the ONLY refresh a headless gamescope has, and it reaches a gamescope-session-plus solely through the GAMESCOPE_BIN wrapper, which the session script is free to lose — a sessions.d file sourced with `set -a` can reassign GAMESCOPE_BIN, and one that sets GAMESCOPECMD outright skips the whole builder. When that happens the stream still runs, still looks right, and the client's own fps counter still reads the negotiated rate (the encode loop repeats the held frame), while the game underneath is capped to 60. Nothing anywhere said so. It warns rather than refusing, deliberately: verify_managed_spawn_flags refuses because its retry resolves a different plan, but a relaunch here would hand the session the same environment and lose the mode the same way, so refusing would only loop. Fails open on the same rule as the flag check — nothing to compare against says nothing. Also corrects the comment above the launch env, which claimed CUSTOM_REFRESH_RATES "generates the mode the session ADVERTISES … what makes games see the real refresh". It never did: no upstream gamescope has --custom-refresh-rates, so gamescope_has_option gated it off and the variable was inert. That belief is why the real lever went unexamined. configuration.md gains the new knob and a warning on PUNKTFUNK_MAX_FPS, which also lowers the refresh the session REPORTS on gamescope — the docs said it does not cap the stream, which is true of the wire and not of what games are told. Linux-verified on Ubuntu: cargo check --all-targets, clippy -D warnings, 133 tests (2 new), cargo fmt --check.	2026-08-08 15:35:58 +02:00
enricobuehler	818531a26e	feat(gamescope): a headless session now reports its own mode, and the perf overlay reaches the stream ... Two new patches on the pinned upstream, and the marker patch moves last so the banner is stamped after the capabilities it advertises. 0003 — headless: advertise the virtual display's mode and refresh rates. A headless gamescope is how we give a game a display: we pass the client's exact mode and the session runs at it. It never told anyone. CHeadlessConnector returned empty spans from GetModes() and GetValidDynamicRefreshRates() and reported GAMESCOPE_SCREEN_TYPE_INTERNAL, so update_mode_atoms DELETED the mode-list atom (no resolution list) and wlserver fell through to a one-entry refresh list built from g_nOutputRefresh (no refresh list). With --nested-refresh absent that entry is Init()'s 60 Hz default — which is why a field report on a 1920x1080@120 client saw "gamescope only shows 60hz, and there's no other option", and why Overwatch capped itself to 60 while the stream ran at 120. Populate both from the resolved mode, report EXTERNAL, and add --custom-refresh-rates so the offered set can be widened. gamescope-session-plus has probed for that flag for years; upstream never had it, so the CUSTOM_REFRESH_RATES env it plumbs was a no-op everywhere. 0004 — pipewire: optionally composite the external overlay into the capture stream. That layer is mangoapp: the fps/frametime readout the Deck UI turns on. paint_pipewire has never referenced it on any version, so a consumer whose only view of the session is the node sees the overlay it just enabled not appear, with nothing to configure. Behind --pipewire-composite-external-overlay, off by default, same argument as the cursor flag. Its commit id joins the repaint test — the numbers change while the picture behind them is static, exactly the case the existing test skips. Verified: the series git-am's cleanly onto the pinned 8c676c39, and both new functions were extracted verbatim and compiled with -Wall -Wextra under C++23 against stubs, with unit assertions for the parser and the mode/rate publication (sorting, dedup, the running rate always present, re-entrancy, zero rejected). A full gamescope build was not run — no box here has its dependency set; CI's per-Fedora-major leg is the first real compile.	2026-08-08 15:35:37 +02:00
enricobuehler	608baf63be	Merge pull request 'Post-sleep sessions still failed on 0.25.0 — the host was holding open the very device its recovery asks PnP to cycle' (#119) from worktree-vdisplay-reap-pnputil into main ... Reviewed-on: #119	2026-08-08 13:29:09 +00:00
enricobuehler	8f9c72877e	Merge pull request 'An SDK fix could never reach an installed plugin — the runner now carries it' (#117) from worktree-runner-sdk-reconcile into main ... Reviewed-on: #117 sdk-v0.1.4	2026-08-08 12:41:58 +00:00
enricobuehler	8f32976349	Merge pull request 'Library source settings never opened — the drawer still called the old plugin origin' (#118) from worktree-library-settings-origin-split into main ... Reviewed-on: #118	2026-08-08 12:40:44 +00:00
enricobuehler	deef5e4382	fix(console): library source settings 404'd — the drawer still called the old plugin origin ... Opening a library source's settings did nothing, for every library plugin. Confirmed on `.21` against the running console: console origin :47992 /plugin-ui/lutris/__config -> 404 plugin origin :47993 /plugin-ui/lutris/__config -> 401 The drawer fetches a RELATIVE `/plugin-ui/<id>/__config`, so it resolves against the console's own origin — where `middleware/auth.ts` answers 404 for `/plugin-ui/**` unconditionally and by design. That refusal is the 2026-08-05 review's origin split (H-3): plugin UIs moved to their own listener, and neither origin may serve the other's paths. The drawer is the only consumer of `/plugin-ui` that is NOT an iframe — every other caller builds an absolute URL from `pluginOriginFrom(uiConfig)` — so it was the one thing the split broke, and nothing failed loudly enough to notice. The fix is deliberately not to point the drawer at the plugin origin. That needs CORS plus cross-site cookies, and it would put a plugin-controlled response inside a credentialed cross-origin fetch — reopening exactly the hole the split closed. What this drawer needs is DATA, not an embedded UI: `/api/plugin-config/<id>` reads the plugin's `__config` server-side over loopback and returns the JSON same-origin, so no plugin markup or script is ever served from the console origin and the per-boot secret stays on the server, as with the `/plugin-ui` proxy. `/api/**` is always session-gated (`isPublicPath`), so the new route inherits the gate and answers 401 as JSON rather than redirecting to /login — which is what a `fetch` needs and what the old path could never give it. It forwards only GET and PUT, reads the body BEFORE the stale-credential retry (`readRawBody` drains the stream, so a retried PUT would have saved `{}` over the operator's config), and passes the plugin's own body through untouched so a 400's decode issue still reaches the operator. Verified against the real built server: `/api/plugin-config/lutris` answers 401 — the route resolves and is gated, and the BFF catch-all at `api/[...]` does not swallow it — while `/plugin-ui/lutris/__config` still answers 404 on the console origin, i.e. the split is intact. `/api/v1/status` still reaches the BFF. tsc clean, production build clean, i18n 633 messages across en+de, biome clean on both touched files (the one warning in SourceSettings.tsx pre-dates this change).	2026-08-08 14:17:58 +02:00
enricobuehler	32cc8dd529	fix(runner): an SDK fix could never reach an installed plugin ... Publishing `@punktfunk/host@0.1.3` — the release that lets a library scanner register `category`, so Lutris and Heroic stay out of the console nav — reached **no existing install**. Measured on `.21`: the only thing that moved it was deleting `bun.lock` by hand over ssh. A fix that needs an ssh session is not a fix. **Why nothing reached it.** Every plugin resolves the SDK from the plugins tree, and `bun.lock` pins it to an exact version with an integrity hash. Nothing in any user-facing flow re-resolves that pin: installing a plugin, reinstalling it, and even updating it to a newer release all leave the SDK alone, because the plugin's `^0.1.x` range is already satisfied by what is locked. `bun update` does not help either — the plugins are pinned exactly in the root manifest, so there is no direct dependency to update through. **Where the fix belongs.** The runner. It is bundled from this same `sdk/` at the host's release commit (`packaging/arch/PKGBUILD` builds `src/runner-cli.ts` into the punktfunk-scripting package), so `SDK_VERSION` is by construction the SDK matching the host now on disk. A host upgrade is therefore the one moment that can carry an SDK fix to already-installed plugins, and now it does — before any plugin loads, and with no operator action at all. **Why it re-resolves the whole lockfile** rather than pinning the SDK at the root: a targeted `bun add @punktfunk/host@<v>` does NOT work while plugins declare the SDK in their own `dependencies` (all six scanners do, though none import it). bun honours their locked resolution and gives each a private nested copy that then SHADOWS the root — measured, 5 nested copies, which is how I first "fixed" the box while leaving every plugin still importing 0.1.2. A lockless resolve hoists one copy for everyone. Once the plugins drop that spurious dependency this can become the targeted form. Safety, because this runs unattended at boot on a tree the operator's plugins load from: plugin versions are pinned exactly in the root manifest so a re-resolve cannot move them (verified — lutris stays 0.1.0); the lockfile is backed up and restored if the install fails or fails to deliver; and every failure is logged and swallowed, so a dependency refresh can never stop working plugins from starting. The no-op path is the one that runs on every healthy box, so it is tested first: same version, or no SDK at all, touches nothing and logs nothing. The SDK is bumped to 0.1.4 because its published content changed. Republishing 0.1.3 is impossible, and letting source drift from a published version is precisely the defect that produced this whole chain — 0.1.2 was published before it forwarded `category`, then the source changed underneath it without a bump. `version.test.ts` fails if `SDK_VERSION` and `package.json` ever disagree. Verified end to end on `.21` against a tree seeded from the operator's real pre-fix backup: 0.1.2 → 0.1.3 automatically, one hoisted copy, no nested copies, plugin versions preserved, and a second run is a silent no-op. SDK 79 tests pass (5 new), typecheck clean.	2026-08-08 14:07:11 +02:00
enricobuehler	fba22c6c64	fix(host/vdisplay): the host no longer vetoes its own wake-from-sleep recovery — control handles close on retire ... The control-device sharing contract was 'bare HANDLE copies, never closed for the process lifetime': retired handles were deliberately kept alive because the pinger/linger threads and the capture delivery closures held raw copies whose soundness depended on no-close. The cost surfaced in the 2026-08-08 field log: after a wake left the driver hostless, every adapter reload came back REFUSED (Generic failure) — and an open control handle is exactly what vetoes the PnP disable (and can wedge the pnputil restart) the recovery leans on. reset-pf-vdisplay.ps1 stops the whole host service precisely to get those handles closed; the in-process recovery could not, because the process could never close them. Ownership is now Arc all the way out: ensure_device/device_handle/ control_device_handle hand out Arc<OwnedHandle> clones, every consumer holds its clone across its IOCTLs (the capture closures each own one — Arc<OwnedHandle> is Send+Sync, ending the isize smuggling), and retiring drops only the manager's reference, so the handle CLOSES when the last in-flight user drains. DeviceSlot::retired is gone. The recovery path now releases the manager's reference at the first absent sighting — the 3 s ABSENT_SETTLE doubles as the drain window — and again before a not-ready-deadline reload, so the PnP cycle finally runs against a device the host is no longer holding open. The driver attaches no meaning to the control file closing (host-gone is the IOCTL-liveness watchdog, EvtFileClose deliberately unhooked), so the close has no driver-side side effects. Lock order note: RECOVERY → device is now taken (the release hooks); the forbidden inverse still never occurs — VdisplayDriver::open never reloads.	2026-08-08 13:37:05 +02:00
enricobuehler	4b514cc07c	Merge pull request 'An OLED palette, and split WHETHER the gamepad UI is offered from WHEN it appears' (#116) from worktree-oled-theme-gamepad-ui-split into main ... Reviewed-on: #116	2026-08-08 11:22:34 +00:00
enricobuehler	f242b2d2fc	fix(host/vdisplay): a refused adapter reload now says WHY, and never targets a phantom devnode ... Field log 2026-08-08 (0.25.0, wake from sleep): every session died on 'the adapter devnode could not be reloaded (Generic failure)' — the WMI catch-all — because the REFUSED branch reported only the Disable exception and threw away everything that would identify the failure mode: why the pnputil /restart-device fallback ALSO failed (its exit code — 3010 'needs a reboot' is its own diagnosis), what state the devnode was in, and whether the right devnode was even targeted. That last one is a real trap, not just missing telemetry: Get-PnpDevice lists not-present PHANTOM devnodes (upgrade/reinstall leftovers), and Select-Object -First 1 could hand every recovery attempt a phantom — whose disable and restart both fail exactly like the field log — while a live node sat unexamined. The selector now prefers present nodes (OK before problem-state), and a phantom-only state gets a truthful refusal: no reload can revive a devnode record whose device is gone; only reinstalling re-creates it. The REFUSED line now carries devnode counts, the chosen node's PnP Status + ConfigManager problem code, and the restart exit code, so the next field log decides between handle-veto, phantom, and problem-state instead of reading 'Generic failure'. Decode pinned by test.	2026-08-08 13:22:05 +02:00
enricobuehler	27ceab2f6c	Merge pull request 'The SDK could not be published at all — bun publish runs prepare, and prepare needs bun2nix' (#115) from worktree-sdk-publish-prepare-hook into main ... Reviewed-on: #115 plugin-kit-v0.3.3 sdk-v0.1.3	2026-08-08 11:04:33 +00:00
enricobuehler	30bd10e301	feat(clients): an OLED palette, and split WHETHER the gamepad UI is offered from WHEN it appears ... Four changes to the client interface, kept together because two of them touch the same rows and the last is a bug the first would have made far more visible. A thirteenth `ui_palette` entry, `oled`. The palette table is hand-mirrored in three languages (`pf-console-ui`'s `library.rs`, `GamepadPalette.swift`, `GamepadPalette.kt`), so it goes into all three at index 1, directly after the brand default — which keeps `PALETTES[0]` the unknown-id fallback and keeps the dark-to-pale cycling order intact. What earns the name is arithmetic, not a darker shade of violet: the ramp's first two stops are literally (0,0,0) and the ground is pure black, so the shaded half of the field is pixels switched off rather than "very dark grey", and the calm mix the form screens sit under lifts toward nothing at all. Mean cell luminance is 0.019 against Violet's 0.254. The bright corner keeps a faint indigo-to-violet ember so the backdrop is still a field with somewhere to go, and that ember carries enough chroma at that luminance (60 degrees of hue travel across 13 of the 16 cells) to satisfy the existing multi-tone assertion without adding `oled` to the near-neutral exemption Graphite and Opal take. Each port gains an `oled_is_actually_black` test that measures the claim — pure-black corner cells, a mean under half the darkest other field's — rather than restating the table. A new device key, `gamepad_ui_mode`. The gamepad-UI switch had been deciding two things at once: whether to offer the controller-optimized interface at all, and that it appears only while a pad is attached. A user asked for the second half to stop applying. `"connected"` (the default, and exactly what the lone Bool meant) and `"always"` separate them, surfaced as a "Show it" row directly under the switch on all five settings surfaces and built only while that switch is on — a picker whose every option decides nothing is worse than no picker. `GamepadUIEnvironment.isActive` takes the mode with NO default argument on purpose: a call site that forgot it would silently strand everyone who chose Always back on "only with a controller", which is the one bug this parameter exists to make impossible. An unrecognized value waits for a controller, so a mode a newer client wrote can never trap an older one in a layout it has no way back out of. It stays a device preference on both platforms, never part of a profile: which interface this device wears has nothing to do with how a host streams to it. The smoothness buffer is hidden under Lowest latency, not dimmed. Everywhere else already hid it — the GTK and WinUI shells, the Apple touch and tvOS screens, the Android touch screen — because under that intent it names a quantity that does not exist. Two surfaces disagreed: Apple's gamepad settings screen left the row live and steppable, and the desktop console dimmed it, having no way to drop a row from a fixed list. That list is now rebuilt each frame through a `row_applies` filter. The concern about a vanishing row moving everything under the cursor does not apply here and the new test says why: the row it drops sits directly BELOW the row that drops it, so the only cursor that can be present when the list shrinks is the one on the intent row, which does not move. Two latent hazards went with it — `apply_row` had been indexing the row list on the assumption the cursor is always in range, and nothing re-clamped that cursor when another writer changed the intent behind the screen's back. Pale palettes were unreadable on tvOS, reported from the field. `GamepadInk` was never the problem: it flips correctly for a pale field, it is not platform-gated, and every tvOS gamepad entry point already published it. The cause is that this app sets `preferredColorScheme` nowhere and declares no `UIUserInterfaceStyle`, so every SYSTEM-derived colour landing on those screens — a `.secondary` placeholder, a `.bordered` button's chrome, a NavigationStack title, a material's frost — resolved against the DEVICE appearance, which the palette cannot reach. On iPhone, iPad and Mac a great many users sit in Light mode, so under a pale palette those colours came out dark and the theme looked correct by accident; an Apple TV is Dark essentially always, so every one of them rendered white on a light field. The mirror image was broken too and had simply never been reported: a dark palette on a Light-mode iPhone was already drawing dark on dark. The scheme is now published beside the ink, once, in `GamepadInkModifier`, because the two are halves of one decision and publishing only the ink silently loses every colour the frameworks draw on the app's behalf. Two structural amplifiers went with it: `ConsoleGlass` had been scoping the scheme to the fill inside its `.background {}` on the tvOS and pre-26 branches while the 26 branch put it on the content, so no console row's own content ever saw it on tvOS; and `LibraryView`'s navigation chrome and its loading, error and empty states sit above `LibraryCoverflowView` and so were never inked at all on tvOS and macOS, where that view is presented directly rather than through the iOS-only `GamepadLibraryScreen` wrapper. That last one exposed a second tvOS gap worth closing in the same breath: `ui_palette` had no row in tvOS's ordinary Settings, and the gamepad settings screen that owns it everywhere else needs an extended-profile controller to open on tvOS. An Apple TV driven by the Siri Remote alone could not reach the palettes at all, which would now include the OLED one. `SettingsView.tvBody` carries a Background row. Verified: pf-console-ui builds, passes `clippy --all-targets -D warnings` and runs 74 tests clean under linux/amd64 (a Mac `cargo check` of that crate is vacuous — every module is cfg'd to linux/windows); `cargo fmt --check` clean for it and pf-client-core. Android `:app` runs 80 tests with 0 failures, including four new `gamepadUiActive` cases and the palette parity table. The Apple package builds for macOS AND tvOS and its 9 palette/gamepad-UI tests pass — the tvOS typecheck is possible because the checked-in xcframework already carries a `tvos-arm64` slice. The tvOS RENDERING fix is compile-verified only; an on-glass Apple TV check under a pale palette is still owed, and is the one thing here that a build cannot answer.	2026-08-08 12:57:12 +02:00
enricobuehler	1df39d9617	fix(ci/sdk): the SDK could not be published at all — bun publish runs prepare ... `sdk-v0.1.3` failed at the publish step with `bun2nix: command not found`, exit 127. Nothing was published, so 0.1.3 is still free. `bun publish` runs the `prepare` lifecycle script, and sdk's `prepare` is `bun2nix -o bun.nix` — regenerating the nix dependency file. That tool is a devDependency of the repo, not something the `oven/bun:1` publish container has, and the workflow's own install is `--ignore-scripts`, so nothing put it on PATH either. This was latent, not new. `prepare` gained the bun2nix call on 2026-07-27 (1db8f763, "move the bun packages to bun2nix"), while the last SDK publish was 0.1.2, bumped 2026-07-20. So the hook has been broken for every SDK release since it landed, and 0.1.3 is simply the first one to try. `@punktfunk/plugin-kit` has no `prepare` and was never affected, which is why kit 0.3.2 published fine in that window and hid this. The fix is NOT to copy `web/package.json`, which does the same job from `postinstall`. That is right for web — it is never published — and would be worse here: a published package's `postinstall` runs in every CONSUMER's install, so every plugin depending on `@punktfunk/host` would try to run bun2nix and fail. `prepare` is the correct hook for a published package (it does not run for consumers); it just must not assume a repo-maintenance tool exists wherever a publish happens. So the script skips when bun2nix is absent — and ONLY then. A present-but-failing bun2nix still fails the script, because swallowing that would publish with a silently stale bun.nix, which is the exact hand-maintained-hash problem 1db8f763 set out to end. Both directions measured against the same `sh -e` bun and the Gitea runner use: absent → exit 0, present-and-failing → exit 3. `bun publish --dry-run` now completes and reports `+ @punktfunk/host@0.1.3`.	2026-08-08 12:55:37 +02:00
enricobuehler	e4f8c64b9f	Merge pull request 'Library scanners sat in the nav and could not sync local art — and you can now hide one game' (#113) from worktree-plugin-nav-category-and-art into main ... Reviewed-on: #113	2026-08-08 10:39:25 +00:00
enricobuehler	690ff7016b	Merge pull request 'The config page missed the whole 0.25 env-var wave — jumbo frames and ten other knobs documented' (#114) from worktree-docs-config-page-0250-vars into main ... Reviewed-on: #114	2026-08-08 10:37:14 +00:00
enricobuehler	6cffe29b13	feat(host,console): hide individual library titles ... The library had one visibility control and it was all-or-nothing: turn a SOURCE off and every one of its games goes. There was no way to drop a single title — a Proton tool the filter missed, a demo, a game someone doesn't want on the TV — short of hiding the whole launcher it came from. **Where the setting lives.** Not on the entry. Only manual custom entries are stored; a scanner's and a plugin's titles are rebuilt from scratch on every scan and every reconcile, so a flag written onto one would be erased by the next sync — silently, and minutes later, which is the worst possible shape for a setting. So `library-hidden.json` holds the ids, mirroring how `library-scanners.json` holds disabled sources. The id is stable by construction (D2: a claimed store's entries keep `<store>:<external_id>` across reconciles), so a hide survives a re-scan, a plugin restart, and a store's built-in→plugin migration. **Where it takes effect.** In `all_games`, which is the one place every play surface already funnels through — the grid on a client, native clients, the GameStream app list, and launch resolution. Putting it there rather than at each call site is deliberate: a per-surface filter is a rule someone has to remember, and forgetting one is precisely the class of bug the `file://` art asymmetry in the previous commit was. Hiding is curation, not access control — nothing is deleted, and un-hiding is instant. **The console is the one surface that still sees them**, or a hidden title could never be brought back. That exception is a TYPE, not a flag: `GET /library` answers `Vec<GameEntry>` on every lane but the operator's and `Vec<OperatorGameEntry>` on theirs, so a hidden entry cannot reach a paired streaming client by someone forgetting a filter — there is no field there to leak. `hidden` is skipped when false, so the response is byte-identical to today's for a library with nothing hidden. `PUT /library/hidden/{id}` is operator-only — neither the plugin lane nor a paired cert, unlike the scanner toggle. A plugin has no business deciding what its operator sees, and a client must not be able to hide a game on the host it is streaming from. The id is not validated against the current library on purpose: a title can be legitimately absent at that moment (launcher closed, plugin mid-sync, drive unmounted), and refusing the operator's choice in that window is worse than storing an id that matches nothing today. On the card, the poster dims and a Hidden badge says why — a faded tile with no label reads as a broken cover. Its controls stay at full contrast and, unlike an ordinary card's, are not hover-revealed: the un-hide button is the only way out of the state, and hiding it behind a hover would strand anyone on a touch screen. Verified on .21 (Linux): 469 host tests pass (5 new), clippy clean under `-D warnings`, `cargo fmt --all --check` clean. The routing test is the one that earns its keep — every library id contains a colon and Heroic's contain two, so a router that split on it would 404 the console against ids the host itself produced. Console: tsc clean, production build clean, i18n 633 messages across en+de, biome clean on the touched files.	2026-08-08 12:33:54 +02:00
enricobuehler	44c87d7ac1	docs(site): configuration page catches up to 0.25 — jumbo frames and seven other missing knobs ... The env-var reference had fallen behind the v0.25.0 CHANGELOG table. Added, with the semantics taken from the code rather than the changelog one-liners: - PUNKTFUNK_JUMBO / PUNKTFUNK_WIRE_MTU (Network & discovery), with a note explaining the ack-gated mid-session grow, the start-at-1500 behavior, the NIC/switch prerequisites, and the sub-1500 shrink direction of WIRE_MTU - PUNKTFUNK_AUDIO_QUALITY / AUDIO_REDUNDANCY / AUDIO_OUTPUT_MODE — the legacy HOST_AUDIO / KEEP_DEFAULT rows are folded into the OUTPUT_MODE row as the aliases they now are (follow_default wins when both are set) - PUNKTFUNK_NO_AUDIO_MINT (Windows minted-endpoint opt-out) - PUNKTFUNK_PAD_AUDIO / PAD_AUDIO_SLOTS (Gamepads — DualSense speaker+haptics) - PUNKTFUNK_NVENC_SPLIT_ARBITRATE (Advanced performance tuning) - PUNKTFUNK_UI_PLUGIN_PORT / PUNKTFUNK_LIBRARY_ART_ROOTS (Auth, API & paths) - PUNKTFUNK_VAAPI_DEVICE (client-side table) Verified against the actual read sites (pf-host-config, wire_mtu.rs, config.rs jumbo_wire_mtu, pad_audio.rs, minted.rs, art.rs, bun-https.mjs); the page's remaining vars all still exist in code. MDX-compiles clean with GFM.	2026-08-08 12:31:25 +02:00
enricobuehler	975fef2048	fix(host/vdisplay): the ghost-monitor reap can no longer fail in silence ... The reap that keeps departed virtual monitors from exhausting the IddCx monitor-slot budget launched pnputil by BARE NAME — under the LocalSystem service's PATH that can miss System32, SilentlyContinue swallowed the miss, and the Rust side logged only when the count was positive: a reap that removed nothing and a box with no ghosts were byte-identical (silence). Ghosts then ratcheted up with every sleep cycle until IOCTL_ADD wedged at 0x80070490 and every session black-screened — and the wedge self-heal shipped in 0.25.0 retried an ADD behind a reap that could never remove anything, which is exactly a persistent post-sleep "no connection" surviving the b6acbd09 probe fix. Same family and same cure as the adapter-reload path one function down: resolve pnputil via $env:SystemRoot (a SYSTEM process must not trust PATH anyway — a planted pnputil.exe would run elevated), pre-seed $LASTEXITCODE to failure before every launch, and report found AND removed unconditionally so "no ghosts" and "removed nothing" are finally distinguishable in a field log. The report parse is split out and pinned by tests like classify_reload_output.	2026-08-08 12:19:48 +02:00
enricobuehler	9089651406	Merge pull request 'The jitter ring only ever learned from clicks — it now grows on near-misses, un-does refused shrinks, and cashes growth on the click it already paid' (#111) from worktree-audio-jitter-lowwater into main ... Reviewed-on: #111	2026-08-08 10:11:10 +00:00
enricobuehler	2a2427afc8	Merge pull request '"Native resolution" streamed the compositor's points, not the panel's pixels — and the window was never high-DPI either' (#112) from worktree-wayland-native-pixel-density into main ... Reviewed-on: #112	2026-08-08 10:09:55 +00:00
enricobuehler	d237646c66	fix(host,sdk,kit): library scanners sat in the nav, could not sync local art, and so never got their settings ... Three symptoms on .21, two defects. Lutris and Heroic appeared in the console sidebar they explicitly opt out of; Lutris's settings were unreachable from the Library screen; and Lutris and Steam logged `sync (startup) failed: HostRequestError`. **The sidebar is a publish gap.** The console is correct — it keeps `category: "library"` plugins out of the nav (`uiPlugins`, app-shell.tsx) — but the host reports no category for them at all. `defineLibraryPlugin` sets it and `sdk/src/ui.ts` forwards it; what SHIPS does not. `@punktfunk/host` was bumped to 0.1.2 on 2026-07-20 and `category` landed 2026-08-05 without a bump, so the registry's 0.1.2 is the pre-category build and every installed scanner registers without one. Bumps the SDK to 0.1.3 — **inert until it is published**. Because the field rides the untyped `pf.request` seam so an older host ignores it rather than rejecting the registration, dropping it is silent by design. `serveUi` now reads its own directory entry back and warns once when a requested category did not land, the same way `defineLibraryPlugin` already warns when a store claim did not take. That is what turns the next occurrence into a log line instead of a bug report. **The missing settings and the failed sync are ONE defect: a write/read disagreement about `file://`.** `local_art_bytes` decodes a `file://` value before testing containment; `validate_art_paths` handed the raw value to `Path::new`, where `file:///home/u/c.jpg` is a RELATIVE path whose first component is `file:`. It canonicalized against the cwd, failed, and read as "outside every art root". So the host refused every cover the kit's own `fileUrl` helper emits — the documented way for a plugin to publish local art — while the read path would have served those same files. That the two symptoms share a cause is not obvious and is why this is one commit: the Library screen's settings control renders only for `origin: "plugin"`, and a source becomes `plugin` only once it holds a store CLAIM, which is taken during a successful reconcile. Lutris failed at entry 0 and Steam at entry 3, so neither ever claimed its store, both stayed `origin: "builtin"`, and neither got a settings button. Heroic reconciled (its art is http(s)) and has had its settings all along; rom-manager was never affected because zero entries meant it never applied. `art_path_is_servable` now decodes first, so both halves of the confinement judge the same string. Confinement itself is unchanged: an out-of-root path is still refused in `file://` clothing, which the test asserts alongside the accept case. Diagnosing this took the HOST's journal, because both surfaces that should have explained it lied. `HostRequestError` stringified to its bare tag, so the sync engine's `${e.cause}` logged `HostRequestError` and discarded the method, the path and the host's own message; it now renders all three, including an object-shaped cause that used to print `[object Object]`. And the host logged "payload carries a field this lane may not set" for BOTH refusals in `check_entry_fields`, so a 400 about an art path read as an auth problem — it now logs the real reason and the entry title. Verified on .21 (Linux): 463 host tests pass, clippy clean under `-D warnings`, `cargo fmt --all --check` clean. The new art test fails without the fix and passes with it. plugin-kit 71 and SDK 72 tests pass, both typecheck clean, biome clean.	2026-08-08 11:43:30 +02:00
enricobuehler	69728b6f4e	fix(pf-presenter): "Native resolution" streamed the compositor's POINTS, not the panel's pixels ... A CachyOS / KDE Plasma 6.7.4 Wayland client with its 2560x1600@165 laptop panel at 150 % scaling negotiated 1706x1066 for "Native resolution" and streamed a visibly blurry image. Two independent defects, and they stack — which is why forcing the mode to 2560x1600 by hand did not fully fix it either. 1. `SDL_GetDesktopDisplayMode` reports a mode in SCREEN COORDINATES and hands the pixels-per-point ratio back separately as `pixel_density`. We read `m.w`/`m.h` raw. KDE advertises that panel as 1707x1067 points with a density of ~1.4997, `render_scale::apply` even-floors both odd axes, and 1706x1066 goes on the wire — exactly the mode in the reporter's handshake log. Multiplying by the density recovers 2560x1600 to the pixel, because SDL derives it as the output's exact pixels/points ratio. On X11 and Windows SDL never sets a density and `SDL_video.c` normalizes the unset 0.0 to 1.0, so this is inert there: the bug needed a compositor doing FRACTIONAL scaling. 2. The SDL window was created without `HIGH_PIXEL_DENSITY`, so the Wayland surface stayed at buffer scale 1 — the Vulkan swapchain was built at 1707x1067 and KWin upscaled it to the glass. Even a correct 2560x1600 stream was resampled down and then back up. The same flaw silently shrank "Match window", which asks the host for `size_in_pixels()`. The reporter's `SDL_VIDEO_WAYLAND_SCALE_TO_DISPLAY=1` workaround is this same fix applied from outside SDL, which is why it helped. The surrounding code was already written for pixels != points — the swapchain, match-window and pointer mapping all read `size_in_pixels()` while window-size persistence reads logical `size()` — so the flag only makes those two stop being the same number. `display_scale()` starts reporting 1.5 into a swapchain that is 1.5x larger, leaving the OSD the size it already was. Also closes a smaller hole on the way past: only an `Err` from SDL reached the 1920x1080 fallback, so a display that reported a 0x0 mode sent a 0x0 request. Verified on home-worker-5 (CachyOS — the reporter's distro, real SDL 3.4.14): `cargo clippy --all-targets -p pf-presenter -- -D warnings` clean and 18/18 pf-presenter tests pass, three of them new and pinned to the field-reported numbers.	2026-08-08 11:15:58 +02:00
enricobuehler	3bb87d260e	fix(audio): detect jitter before it is audible, and stop re-probing a depth the link just refused ... The 0.25.0 MacBook field report — audio jitter 'at certain points' — is the jitter policy learning exclusively from audible failures, on both of its sides. Growth needed THREE audible underruns before deepening the ring; the A/V sync loop re-tested a shallower ring every five quiet seconds and paid an audible starvation event every time it was wrong, forever; and a grown target was never re-banked — growth raises a threshold, only a re-prime deepens the ring — so a bunching link rode the knife edge, clicking once per bunching period with the 'grown' target sitting inert. A ten-minute simulation of the Wi-Fi power-save pattern (25 ms gaps / 300 ms, −50 ppm skew) measured ~2000 audible events under the shipped policy. Three mechanisms, in JitterPolicy (Linux/Windows/Android) and mirrored in the Swift AudioRing: - NEAR-MISS: a read served with less than one protocol frame left over is the same evidence as an underrun, heard by no one. It grows the target one step per window, BEFORE the click — waiting for the third audible underrun means the user heard two. - SHRINK PROBES: every shrink is armed for five seconds; answered by an underrun or near-miss it is undone on the spot, and a failed sync-driven shrink is not retried for a doubling backoff (60 s → 8 min). A probe that survives resets the backoff. Continuity outranks sync, now with a memory. - HOLLOW RE-PRIME: an underrun while the depth AVERAGE runs more than a step below the target re-primes immediately, spending the click it already cost on the whole refill instead of limping. The average, not the instant, is what separates a hollow ring from one late packet, and it is seeded on prime so a fresh ring is never spuriously hollow. Same simulation after: 9 audible events, tail clean but for the clock-skew re-anchor (a genuinely slow host must re-bank every few minutes; only rate adaptation would remove that, and no client has it). Neutralising the three constants reproduces the ~2000 — the convergence tests fail against the old behaviour. Verified: 203 punktfunk-core tests, 254 Swift tests (5 skipped), clippy -D warnings on punktfunk-core --all-features, cargo fmt --all --check.	2026-08-08 11:05:53 +02:00
enricobuehler	be57587572	Merge pull request 'The release-rebuild prune called a helper that cannot exist in a release rebuild' (#110) from worktree-arch-rebuild-prune into main ... Reviewed-on: #110	2026-08-08 09:03:28 +00:00
enricobuehler	8f1c34c6bf	fix(ci/arch): the release-rebuild prune called a helper that cannot exist there ... The v0.25.0 rebuild published perfectly — registry has punktfunk-host 0.25.0-2 with libavcodec.so=63-64, and it resolves on a real ffmpeg-9 box — then failed its last step with prune_release_assets: command not found `. scripts/ci/gitea-release.sh` sources from the CHECKED-OUT TREE, and a release rebuild checks out the OLD TAG. So the step could only ever see the helpers that existed when that tag was cut, and the prune is gated on exactly that path: the helper was guaranteed absent in the only case that calls it. Adding it to a shared script made it look available at review time while being unreachable at run time. Only the workflow file is read from the dispatched ref, so the logic moves there, inline. Same reasoning documented at both ends, including the corollary worth knowing before the next rebuild: a PKGBUILD fix made after a tag does NOT reach a rebuild of that tag either — the packaging comes from the tag too. Verified by executing the one-liner's exact bytes out of arch.yml under /bin/sh (the shell Gitea actually uses): keeps the new -2 set and gamescope, drops the superseded -1 packages and their .sha256 sidecars, leaves other legs' .dmg/.deb untouched. The `'\n'` survives the shell quoting, which was the part worth proving. Also drops the now-dead helper from gitea-release.sh rather than leaving a function no caller can reach, and leaves a warning there against the next one.	2026-08-08 10:57:49 +02:00
enricobuehler	1ef212a78d	Merge pull request 'v0.25.0 shipped an Arch host no up-to-date box can install — and the pipeline had no way to tell' (#109) from worktree-arch-ffmpeg9-repackage into main ... Reviewed-on: #109	2026-08-08 08:39:32 +00:00
enricobuehler	e044f68500	fix(ci/arch): v0.25.0 shipped a host no Arch box can install, and nothing could tell ... Arch moved FFmpeg 8 -> 9 (every libav soname +1) hours before the release. PR #108 fixed the real bug — packaging/arch/PKGBUILD now binds punktfunk-host to the sonames it actually linked, so pacman refuses an upgrade instead of bricking the install — and re-keyed ci/arch-ci.Dockerfile so the builder would carry FFmpeg 9. The tag was pushed four minutes later. arch.yml and docker.yml have no `needs:` between them, and arch.yml deliberately runs no -Syu ("the image's snapshot IS the build environment"), so the release build pulled the still-FFmpeg-8 `:latest` and published punktfunk-host 0.25.0-1 depends: libavcodec.so=62-64, libavutil.so=60-64, libavfilter.so=11-64, libavdevice.so=62-64, libswscale.so=9-64 against a world that had moved to 63/61/12/63/10. It fails safely — pacman refuses, nothing bricks — but it fails broadly: pacman prepares one transaction, so an unsatisfiable dependency of OURS stopped affected users' entire `pacman -Syu`. Nothing in the pipeline could have caught it. The existing assert proves the dep is VERSIONED; it cannot prove the version EXISTS. So two guards, plus the lever to repair a release that has already shipped: * Preflight parity — compare the builder's libav `provides` against the live repos and `-Syu` the container if they differ. The image is a cache and may lag; on this one axis it may not. Syncs into a throwaway --dbpath so the container never sits in the partial-upgrade state a bare `pacman -Sy` leaves. * Publish gate — resolve every built package with `pacman -U --print` against a PRISTINE --dbpath. Empty db means "nothing is installed", so every dependency must come from the repos exactly as on a user's box. Resolving against the builder's own installed set is what would hide this: a stale ffmpeg satisfies a stale bound. gamescope stays best-effort (dropped from the upload with a warning, never fatal). * workflow_dispatch(release_tag, pkgrel) — a published release cannot be repaired by re-running its tag: pkgrel would stay 1, which is invisible to a box that already recorded the broken build, and the workflow file at the tag can never carry inputs added after it. Dispatched from main it takes the WORKFLOW from main and the SOURCE from the tag, publishes to the stable repo at a higher pkgrel, and replaces the release-page assets (prune_release_assets: upsert replaces by NAME, and a rebuild's filenames differ, so the superseded package would otherwise stay one click away). Verified on a real ffmpeg-9 box (.21, CachyOS) rather than reasoned about: the gate rejects the published 0.25.0-1 host with the user-visible error verbatim, and passes client, web, scripting and gamescope — 0 false positives across all five artifacts. The parity snippet reads today's `provides` correctly (`-Si --dbpath` on an empty db works; pacman does not wrap fields when piped). Version logic exercised on all four paths: rebuild -> 0.25.0-2 stable, tag push and canary unchanged, pkgrel=1 refused. Ships as punktfunk-host 0.25.0-2. README gains the pacman error and what to do about it; CHANGELOG says plainly that 0.25.0's Arch packages were wrong.	2026-08-08 10:34:11 +02:00
enricobuehler	8c94e2517e	fix(plugin-kit): the bun.lock I committed was corrupt, and it blocked the release ... `plugin-kit-v0.3.2` failed at its very first real step: error: Duplicate package path at bun.lock:71:5 InvalidPackageKey: failed to parse lockfile: 'bun.lock' warn: Ignoring lockfile error: lockfile had changes, but lockfile is frozen `@punktfunk/host` was listed TWICE, byte-identically, at lines 69 and 71. I introduced it: the lock had exactly one entry before 10a0ef32 and two after. Running `bun install` to add the biome devDependency duplicated the `file:../sdk` entry — the same `file:`-dependency lock corruption already recorded against the web workspace's overrides. Nothing else in the lock is wrong, so this removes the duplicate entry rather than regenerating (a regenerate risks reproducing it, since the `file:` dep is the cause). Verified with the exact commands the publish workflow runs, in order: `bun install --frozen-lockfile --ignore-scripts` (the step that failed) now succeeds, then the file:-dep repair, `bun run check`, `bun run typecheck`, `bun test` 67/67, `bun run build` — all clean. No source change; 0.3.2 is unpublished, so the tag moves to this commit. plugin-kit-v0.3.2	2026-08-08 02:51:52 +02:00
enricobuehler	08525e618e	Merge pull request 'chore(release): bump workspace version to 0.25.0' (#56) from worktree-release-0250 into main ... Reviewed-on: #56 v0.25.0	2026-08-08 00:45:46 +00:00
enricobuehler	fa2bcd9dbb	docs(release): the last three PRs — FFmpeg 9, the Arch soname trap, and the Linux buffer ceiling that was defeating A/V sync	2026-08-08 02:43:46 +02:00
enricobuehler	353091270d	Merge remote-tracking branch 'origin/main' into worktree-release-0250	2026-08-08 02:42:00 +02:00
enricobuehler	86bb09e2cf	Merge pull request 'Arch could upgrade FFmpeg out from under the host and brick it — and the host now builds against FFmpeg 9' (#108) from worktree-ffmpeg9-support into main ... Reviewed-on: #108	2026-08-08 00:41:33 +00:00
enricobuehler	deeb8b6700	feat(pf-encode): build against FFmpeg 9 ... ffmpeg-next 8.1.0 could not accept FFmpeg 9 at all: ffmpeg-sys-next's version probe covered avcodec majors 56..62 (the range is exclusive of its end), so libavcodec 63 fell outside what it knew how to bind. 9.0.0 widens that to 56..63, which is what actually unblocks Arch. Bump both pins — the unconditional Linux dep and the optional Windows amf-qsv one — and the lock with them. No API drift to fix. The crate major is a CEILING, not a target: one source tree still spans FFmpeg 7.x/libavcodec 61, 8.x/62 and 9.x/63 via per-version cfgs, and every wrapper symbol the NVENC-libav, VAAPI and amf-qsv backends name survives 8.1.0 -> 9.0.0 unchanged. The three hand-written #[repr(C)] hwcontext mirrors are the parts no compiler checks, so they were re-read against the real headers rather than trusted: AVCUDADeviceContext and AVD3D11VAFramesContext are byte-identical across 7.1/8/9, and AVD3D11VADeviceContext gained two trailing UINTs in 8 that 7.1 lacks — which is why that mirror deliberately stops at the common prefix, and why its assertions now say what they do and do not buy you. They pin our layout, not libav's; a green build is not evidence. The CI image is the step that makes this reach users. arch.yml deliberately runs no -Syu ("the image's snapshot IS the build environment"), so the builder stayed frozen on ffmpeg 8 no matter what Arch shipped, and a canary built from that snapshot could not satisfy the soname dep the PKGBUILD now derives. Re-keying ci/ rebuilds it against ffmpeg 9. Ubuntu and Windows deliberately stay put: the noble .deb bundles its own FFmpeg 8 behind an rpath and strips the libav sonames from its Depends, and Windows bundles BtbN DLLs into the signed installer — neither is exposed to the break, BtbN publishes no FFmpeg 9 build, and moving either would re-qualify an encode stack to buy nothing. Verified end to end on 192.168.1.21 (CachyOS, system ffmpeg 2:9.0-5, RTX 5070 Ti): host builds clean and links libavcodec.so.63/libavutil.so.61/libavfilter.so.12/libswscale.so.10 with no unresolved sonames; the ffmpeg-8 compat shim is gone and the service runs with NRestarts=0 and answers 401 on :47990; pf-encode's 67 tests pass; and a live synthetic encode drives real NVENC hardware through FFmpeg 9's libavcodec to a decodable 1080p HEVC stream (180/180 frames, FEC loopback 0 mismatches) with libavcodec.so.63 and libnvidia-encode both mapped into the encoding process.	2026-08-08 02:35:20 +02:00
enricobuehler	b1e0525872	fix(packaging/arch): pacman could upgrade FFmpeg out from under the host and brick it ... `depends=('ffmpeg' ...)` carried no version bound, and pacman is the only one of our packaging formats that does not derive dependencies from ELF DT_NEEDED — rpm auto-generates `libavcodec.so.62()(64bit)`, dpkg-shlibdeps emits `libavcodec62`, nix pins the closure. So when Arch shipped ffmpeg 2:9.0-5 on 2026-08-08 and every soname moved (libavutil .60->.61, libavcodec .62->.63, libavfilter .11->.12, libavdevice .62->.63, libswscale .9->.10), a plain `pacman -Syu` walked every Arch/CachyOS install straight across the break. The result is not a crash we can log: the dynamic loader cannot start the binary at all, so it is exit 127 *before* main() in a systemd restart loop, and because punktfunk-web is a separate bun service with no libav linkage it keeps serving happily while :47990 has nothing listening — which reads as "the mgmt API is broken" rather than "the host is not running". `ldd /usr/bin/punktfunk-host | grep "not found"` is the one-line diagnosis. Depend on the sonames instead of the package. Arch's ffmpeg declares the matching `provides=(libavcodec.so=63-64 ...)`, and makepkg rewrites each bare `libfoo.so` listed in depends into `libfoo.so=<soname>-<arch>` by reading the built binary's DT_NEEDED, so the bound tracks whatever FFmpeg the builder linked against with nothing to hand-maintain across the next bump. pacman now refuses the ffmpeg upgrade rather than bricking the install. A hand-written `ffmpeg<2:9` would have gone stale on the very next major; not bundling FFmpeg the way the .deb does, because that exists only because Ubuntu 24.04 LTS is frozen on 6.1 and can never satisfy the dep, while rolling Arch always ships a current one. Verified on a real ffmpeg-9 box (192.168.1.21): the built package records libavcodec.so=63-64, libavutil.so=61-64, libavfilter.so=12-64, libavdevice.so=63-64 and libswscale.so=10-64, exactly matching DT_NEEDED, with the two libs --as-needed drops left bare and satisfied by any ffmpeg. The new arch.yml step asserts that expansion actually happened. If it ever stops — Arch dropping the soname provides, someone tidying the entries out of depends — the dep silently degrades to an unversioned name that any ffmpeg satisfies, which is exactly the state that caused this, and it is invisible in a green build until a box bricks weeks later.	2026-08-08 02:34:59 +02:00
enricobuehler	4adea10557	Merge pull request 'fix(plugin-kit): regSubKeys could never return a subkey, and adopt biome' (#107) from worktree-kit-regsubkeys into main ... Reviewed-on: #107	2026-08-08 00:23:46 +00:00
enricobuehler	4edb662b63	fix(plugin-kit): regSubKeys could never return a subkey ... Found on hardware by the GOG plugin's own parity gate, on a box with exactly one GOG game installed: HKLM\SOFTWARE\WOW6432Node\GOG.com\Games -> 1 subkey (IRON NEST ...) host's built-in scanner: 1 entry plugin: detect: absent, 0 games parity FAILED - 1 missing, exit 1 `reg.exe` ALWAYS echoes the full hive name in its output rows, never the abbreviation it was given: query `HKLM\SOFTWARE\...` and every line comes back `HKEY_LOCAL_MACHINE\SOFTWARE\...`. regSubKeys built its match prefix from the `HKLM\...` string it was handed, so no line ever matched and it returned `[]` — on every machine, for every key, always. Measured verbatim on .173: reg.exe: [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\GOG.com\Games\2013434102] regSubKeys: [] Its only consumer is the GOG plugin, so the symptom was "GOG reports no games installed" rather than an error — the same shape as the SQLite reader in 0.3.1: a total failure that every layer degrades into an empty library. The contract was wrong too, and the hive bug hid it. regSubKeys returned whole key PATHS while the GOG plugin uses each result as a bare NAME (`const key = \`${GAMES_KEY}\\${id}\``, and the subkey name IS the product id that becomes `external_id`). Even with the prefix fixed, paths would have composed nonsense keys. It now returns names, which is what the sole consumer and its own comment always assumed. Parsing is split into an exported `parseRegSubKeys(stdout, key)` for the same reason `parseRegQuery` is exported — this is a text format that breaks quietly, and it had NO test coverage at all. Six added, using the verbatim .173 output: names not paths, multiple subkeys, grandchildren ignored, the queried key is not its own subkey, case-insensitivity, and empty/error input. Four of the six FAIL against the old behaviour. 0.3.1 -> 0.3.2. Gates: biome clean, tsc clean, 67/67 tests, build clean.	2026-08-08 02:19:30 +02:00
enricobuehler	10a0ef3283	style(plugin-kit): adopt the biome config its own plugins already use ... The kit had NO biome config and no lint script, while every plugin repo that consumes it has both. So its source quietly drifted — unused imports, unsorted imports, formatting — with nothing to catch any of it. Running biome here for the first time reported 20 findings across 8 files. Adds `plugin-kit/biome.json` mirroring the plugin repos' (tab indent, double quotes, recommended lint preset, organizeImports), a `check` script, and `@biomejs/biome` pinned to the same `^2.5.2` the plugins pin — without that pin `bunx biome` resolved 2.4.6, which rejects the 2.5 `rules.preset` key. Two deliberate differences from the plugin repos' copy: * no `vcs.useIgnoreFile` — those are standalone repos with a .gitignore beside the config; plugin-kit is a directory inside this one, and biome errors with "couldn't find an ignore file". The `files.includes` exclusions cover it. * `!examples/**/dist` instead of `!ui/dist` — the kit has examples, not a UI. `css.parser.tailwindDirectives` is carried over and is load-bearing: without it biome cannot parse `@theme` in src/theme.css and reports three parse errors on CSS that is perfectly valid Tailwind v4. Everything here is formatter/import churn except two real findings, both fixed: * `Layer` (library/define.ts) and `Cause` (sync-engine.ts) were imported and never used; * test/spike-httpapi.test.ts read `(reg?.body as …).ui.secret` one line after `expect(reg).toBeDefined()`. The optional chain undoes the assertion: had `reg` been undefined the `.ui` access would throw a TypeError instead of failing the test readably. Now asserted to the type system too. Wired into plugin-kit-publish.yml as a `Lint & format` step ahead of Typecheck, so this cannot rot again. Gates after: biome clean (42 files), tsc clean, 67/67 tests, build clean.	2026-08-08 02:19:06 +02:00