1391 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	70b81ac3d7	test(pf-encode): S1c + the D5 confirm — pair flips in place, AUTO really is dead ... S1c `nvenc_cuda_split_subframe_pair_reconfigure`: the leg S1a/S1b excluded. Both pinned sub-frame OFF to isolate the split variable, but a real HEVC arbitration cannot -- split and sub-frame are mutually unsupported there, so engaging split means flipping enableSubFrameWrite in the same breath, a second init param and the one the reconfigure path deliberately pins. RESULT on .21: the PAIR moves in place, accepted, ZERO IDRs, both directions. It also pins the invariant that makes this safe to build on: `subframe_chunks` is latched ONLY in the init path (~line 1625) and is NOT recomputed by reconfigure_bitrate, so a caller flipping sub-frame in place must clear it too or supports_chunked_poll keeps reporting true and poll_chunk busy-polls its whole budget every AU against a numSlices that never advances. The test performs the correct sequence and asserts the state stays coherent, so WP3 has a worked example rather than a warning. `nvenc_cuda_auto_split_with_subframe`: the D5 confirm -- the one claim in the design's defect list that was only ever inferred. The driver reports no "mode I actually chose", so it is settled by timing, at 4K where the gap is ~2x. RESULT: AUTO (env unset) + sub-frame 4904 us/frame, DISABLE + sub-frame 5062, TWO_FORCED without sub-frame 3464. AUTO sits 158 us from DISABLE and 1440 from TWO_FORCED ⇒ D5 CONFIRMED: plain AUTO does not split while sub-frame is on, so the resolver's AUTO fallthrough reads as "let the driver decide" and means "never split". ⚠ TRAP, hit on this test's first run and now documented in it: the env knob CANNOT express plain AUTO. `0` is DISABLE and `1` is AUTO_FORCED, and resolve_split_subframe counts AUTO_FORCED as forced, so passing `1` silently disarms sub-frame and measures a different configuration entirely -- which produced a spurious "D5 REFUTED". Plain AUTO is only reachable as the resolver's fallthrough with the env unset. The leg now asserts sub-frame resolved TRUE, so the test can no longer answer the wrong question quietly. Verified on .21: clippy --features nvenc --all-targets -D warnings clean, all 4 spikes green, the normal 54-test suite unaffected, cargo fmt --all --check clean.	2026-08-06 21:27:18 +02:00
enricobuehler	4b57d11dd8	test(pf-encode): S1 spike — splitEncodeMode CAN change in place, no IDR ... Two on-hardware spikes answering the gate on the split-encode engagement program (design/nvenc-split-encode-engagement-implementation-plan.md). S1a `nvenc_cuda_split_reconfigure_in_place`: can splitEncodeMode change via nvEncReconfigureEncoder with resetEncoder=0, without an IDR? Our "reconfigure must present the SAME init params as the open" rule (windows/nvenc.rs:620) is our own invariant and had never been tested against a driver. It reports rather than asserts the verdict -- both outcomes are legitimate findings -- and only asserts what would invalidate the measurement (session live, engines >= 2, the arms actually differ). Sub-frame is pinned off so the driver can't reject for the wrong reason (HEVC forced-split and sub-frame are mutually unsupported). S1b `nvenc_cuda_split_reconfigure_takes_effect`: the other half -- a driver that accepts the parameter and quietly ignores it looks identical to one that honours it. Three legs at 4K (fresh DISABLE / fresh TWO_FORCED / DISABLE->TWO in place); if C tracks B and not A, the switch is real. RESULT on .21 (RTX 5070 Ti, GB203 Blackwell, driver 610.57.04): NV_ENC_CAPS_NUM_ENCODER_ENGINES = 2 S1a: accepted, ZERO IDRs, both directions. S1b: A fresh DISABLE 5054 us/frame, B fresh TWO_FORCED 2453, C switched in place 2419 -- |C-B|=34 vs |C-A|=2635. It takes effect, and split is a clean ~2x at 4K. Two limits, both recorded in the test docs rather than the commit only. The frames come out at 427 B/AU against an 833 KB CBR quota: the driver hands back zeroed VRAM, so the rotated buffers are identical and rate control skip-codes everything. So this measures the PIXEL-proportional half of the cost only -- the bits/frame regime the field case lives in is untested here, and the test prints an explicit INCONCLUSIVE-on-content line when it detects that. And this is Blackwell 8-bit; the Ada Main10 question is untouched. Verified on .21: clippy -p pf-encode --features nvenc --all-targets -D warnings clean, both spikes green, cargo fmt --all --check clean.	2026-08-06 21:11:52 +02:00
enricobuehler	e9da37aaf6	feat(host/gamelease): a launcher tile's session stops depending on invisible state ... A launcher entry (design D4) has no "the game exited" moment to detect, but the lease was still deciding its lifetime from whatever happened to be true at launch — and the two outcomes disagree: launcher NOT already running the spawned child stays alive -> `Child` lease -> quitting the launcher ends the session launcher ALREADY running the command forwards to the live instance and exits inside SHIM_WINDOW, with no detect signals behind it -> `Untracked` -> the session persists Same tile, two lifetimes, chosen by something the user cannot see. Steam is the case that settles which one is right: Big Picture is a *mode* of an already-running Steam client, not a process — and on a Deck or SteamOS host Steam is always running — so no process signal can express "the launcher's window closed". Heroic has the same shape for a different reason (single-instance Electron: a second invocation forwards and exits). So a launcher entry is now `LeaseKind::Untracked` unconditionally. The check sits AHEAD of `nested`/`child`/`spec`, and that ordering is the fix rather than an implementation detail: a launcher the host just started leaves a live child behind, and tracking that child is precisely the inconsistency being removed. `Untracked` already meant the right things downstream, so nothing else had to change: no watcher thread, `terminate()` is a no-op ("nothing to end" — closing a session must not kill the user's Steam), and no `GameExited` event, so a client does not bounce back to its library when the launcher closes. Threaded as `LaunchTarget::launcher` -> `LeaseRequest::launcher` from the entry's `role`. Three call sites, one of which was the actual trap: the GameStream path does not build its lease from a `LaunchTarget` at all, it goes through a `GsApp` intermediate that silently dropped the field. An operator-typed `apps.json` command has no library entry behind it and is never a launcher tile, so it passes `false` explicitly. The test pins BOTH cases from the table above, plus the same request without the flag still being `Matched` — so the assertions are the flag's doing and not an artifact of the fixture. Gates: punktfunk-host 439 passed / 0 failed on .21 (+1). Not covered here: nothing publishes launcher tiles until the plugins are released, so there was no live exposure to fix — this is the semantics being made deliberate before the first tile is ever clicked.	2026-08-06 18:35:09 +02:00
enricobuehler	453b9850fa	Merge pull request 'Gamepad UI: multi-tone palettes, and a UI that takes its colours from them' (#74) from worktree-gamepad-ui-polish into main ... Reviewed-on: #74	2026-08-06 14:48:24 +00:00
enricobuehler	4a9a1c3ed4	feat(clients/gamepad-ui): multi-tone palettes, and a UI that takes its colours from them ... The first pass built each palette by rotating ONE colour field's hue, and it showed: every option was a single tone at several brightnesses, which reads flat next to any real gradient. A palette is now an ordered ramp of DISTINCT hues. The 4×4 mesh samples that ramp along the diagonal with a fixed per-cell offset table, so neighbouring cells land on different parts of it and the colours pool and swirl instead of banding; the control points' existing drift then moves the pools around. Violet keeps its explicit sixteen colours, so the default is untouched. Twelve of them now, dark first then pale: Violet, Nebula, Abyss, Ember, Moss, Graphite, then Holo, Sunset, Bloom, Dawn, Mint, Opal. Holo and Sunset are straight takes on the two reference gradients — foil and poster. `every_palette_is_multi_tone` measures the hue spread across all sixteen cells and fails under 45° (20° for Graphite and Opal, which are meant to be restrained). It caught Ember at 35°, all reds and oranges — the very flatness this rework exists to remove — and Graphite at 3° despite a comment claiming it drifted cool to warm. Both were rebuilt until the numbers matched the prose. The UI follows the palette now, rather than wearing brand violet over whatever happens to be behind it. Each palette carries an accent and a light flag, and an Ink derived from those (foreground, accent, on-accent, glass, scrim and its strength) is published to the whole tree — a thread-local in the console, an environment value on Apple, a CompositionLocal on Android. Pale palettes flip the ink: dark text on white frost, with the materials, tray scrims and every wash that sits under text following suit. Three things only the renders could have told us: - Additive blending blows out over a pale ground. Android's blobs and Apple's legacy field composite with Plus/plusLighter, which over near-white saturates every blob to white — Holo rendered as a grey wash. Pale palettes blend normally. - A white scrim at the dark field's strength BLEACHES the gradient. Mixing toward black at 0.4 reads as depth; toward white at 0.4 destroys the chroma it is drawn over. The scrim now carries a per-palette strength. - White glass over a bright field has far less separating it from its backdrop than dark glass over a dark one, and needed more body. Verified: console build + clippy -D warnings + 173 tests, Apple build + 200 tests + an iOS-triple typecheck, Android compile + 62 tests, and eyeball passes on real renders of both the vivid and the pale ends (console CPU rasters; a new Roborazzi light-palette scene, which is what exposed the blend-mode bug).	2026-08-06 15:55:26 +02:00
enricobuehler	166e158afe	feat(host/library): an xbox launch kind a de-privileged plugin can publish ... The xbox scanner resolves each package's PackageFamilyName by enumerating %ProgramData%\Microsoft\Windows\AppRepository\Packages. Probed on .173 (design doc S1), that directory is: NT AUTHORITY\LocalService UnauthorizedAccessException <- the plugin runner LocalSystem count=348 <- the host service So an extracted xbox plugin cannot build an AUMID, and `aumid` — which takes a complete `<PFN>!<AppId>` — is unpublishable by one. The design doc offered two fallbacks: entries without `aumid` (they would list but not launch), or a one-shot elevated PFN resolve at install time. This is neither. The plugin sends `<Identity>!<AppId>`, both read straight out of MicrosoftGame.config — which IS readable de-privileged — and the host resolves the publisher hash at LAUNCH time, where it already owns command construction. That keeps D1 intact (the plugin supplies a validated value, the host builds the command), it is the same shape as the `playnite` kind, and resolving late means a package update that changes the publisher hash cannot leave a stale unlaunchable tile behind — which the install-time cache would have. `xbox_pfn` therefore moves from the scan path to the launch path rather than being deleted, and its doc records the privilege asymmetry so the next reader doesn't re-derive it. The charset guard is factored out (`aumid_part` / `valid_aumid`) and shared with the `aumid` kind. On `aumid` it was belt-and-braces — every value was host-derived. On `xbox` it is load-bearing: the Identity arrives over the wire from a plugin, and it is interpolated into a `shell:AppsFolder\…` argument. Validated inbound at reconcile too, so a malformed value is a 400 the plugin author can act on rather than a tile that fails on click. Gates: punktfunk-host 438 passed / 0 failed on .21, and 55/0 for the library tests on .173 (where these arms actually compile). Both counts +1 for the new guard test.	2026-08-06 15:43:26 +02:00
enricobuehler	65996621d8	Merge pull request 'fix(encode/pyrowave): stop stamping GPU scheduling priority over pf-frame's auto gate' (#72) from worktree-pyrowave-gpu-priority into main ... Reviewed-on: #72	2026-08-06 13:15:06 +00:00
enricobuehler	c48e60fbb7	Merge pull request 'Two July fixes that were never merged: rpm FFmpeg modules + the released-pointer double cursor' (#71) from worktree-july-rpm-and-cursor into main ... Reviewed-on: #71	2026-08-06 13:13:33 +00:00
enricobuehler	70684e5079	fix(encode/pyrowave): stop stamping GPU scheduling priority over pf-frame's auto gate ... `windows/pyrowave.rs` raised the process's WDDM scheduling class to HIGH itself, once per process, at every session open. `pf-frame::dxgi::auto_priority_gate` already owns that policy for the whole process and runs from `create_device` — the call the Windows capture path always makes before any PyroWave texture exists. Two owners of one process-wide setting. The audit filed this as "downgrades REALTIME to HIGH", which undersells it. pf-frame's default `auto` mode starts at HIGH and then UPGRADES to REALTIME once it has established that is safe — HAGS off, or HAGS on with VRAM headroom — and leaves a monitor running that drops back when VRAM tightens, because REALTIME + NVIDIA + HAGS + near-full VRAM is a documented NVENC hang. Opening a PyroWave session after that upgrade stamped HIGH back over the class AND orphaned the monitor's decision, losing the ceiling-raise on exactly the GPU-saturated workload PyroWave exists to survive: it encodes on the shader cores a game saturates, where the measured spike is ~2 ms to 15-18 ms. Removed rather than reconciled. `PyroWaveEncoder::open` takes no device, so there was nothing session-specific to preserve, and the surviving owner is strictly better informed — it knows the adapter, HAGS state and VRAM headroom, none of which this call site had. The duplicated knob goes with it: `PUNKTFUNK_GPU_PRIORITY` is retired in favour of `PUNKTFUNK_GPU_PRIORITY_CLASS` (`off|normal|high|realtime|auto`, default `auto`), which is a superset — the removed knob could not express the auto gate at all. No other reference to it exists in the tree. Verified on .173: clippy -D warnings at nvenc,amf-qsv,qsv (host + pf-encode --all-targets), amf-qsv without qsv, qsv alone, no-features, cargo test --features qsv (34 passed), rustfmt — 7 legs green. Windows-only file, so the Linux legs do not compile it.	2026-08-06 15:06:49 +02:00
enricobuehler	2a67c02f7e	fix(clients/cursor): the host must not composite a pointer under a released client's own cursor ... Streaming a KDE desktop showed two cursors: the one the user was moving, and a second one sitting underneath it that never moved. It was not KDE's — KWin 6.7.3 in cursor-as-metadata mode calls `setRenderCursor(false)` on every recorded buffer and hands the cursor item to an exclusive `ItemTreeView`, so `shouldRenderItem()` skips it and no pointer is ever painted into that stream. It was ours. Both clients declared the render model as `captured && desktop`, so ANY released pointer handed compositing back to the host. But releasing does not remove the local cursor — it restores the ordinary window arrow over the video. The host then blends its own pointer in underneath, and since a released client forwards no motion, nothing drives it: it stays frozen wherever the host pointer was last left. Caught live on the host with the render-model diag: cursor diag: client_draws=false blended=true live=Some((-1, 622, true)) x = -1 — parked on the streamed output's left edge, unchanged sample after sample, while the user moved their own cursor around freely. Engaging capture flipped it to `client_draws=true blended=false` and the duplicate vanished, which is why it only looked "stuck when not dragging": dragging means engaged, and engaged was the one state that behaved. The host may composite ONLY while the client holds a grabbed, hidden pointer — the capture model, engaged — which is the single state with no local cursor on screen. Released now counts as "the client draws it": the host stops compositing and keeps forwarding shape/state over the channel (the forwarder ticks on this side of the flip), so re-engaging is seamless and the client's cached shape stays warm.	2026-08-06 15:03:11 +02:00
enricobuehler	6ae2ea6708	Merge remote-tracking branch 'origin/main' into worktree-library-clients	2026-08-06 14:45:36 +02:00
enricobuehler	00d4026054	Merge pull request 'Worktree field kleisty triage' (#69) from worktree-field-kleisty-triage into main ... Reviewed-on: #69	2026-08-06 12:41:28 +00:00
enricobuehler	dd20a17edb	test(host/library): the art tests build a file:// URL Windows can read ... `local_art_bytes_is_confined_and_image_only` and `posix_local_art_is_classified_and_proxied` built their `file://` values as `format!("file://{path}")`. On Windows that yields `file://C:\covers\cover.png`, whose authority is `C:` — a UNC reference, not a local file — so the read half failed on the box and the host suite was red there. The parser is right and the tests were wrong: `@punktfunk/plugin-kit/library`'s `fileUrl` emits `file:///C:/covers/cover.png` (three slashes, forward separators) and `file_url_to_path` documents exactly that. A shared `file_url` helper now builds the value the way the kit does, so both tests exercise the real plugin contract on both platforms rather than a shape no plugin ever sends. Found while gating the Playnite launch kinds on .173 — Linux CI never compiles these arms, so the failure had gone unnoticed. Test-only: no product code changes.	2026-08-06 14:36:04 +02:00
enricobuehler	8ff2c2e1c6	feat(host/library): Playnite can publish again, and gets a fullscreen tile ... The Playnite plugin emits `kind: "command"` for every game (a `start "" "playnite://…"` shell line). The 2026-08-05 review made `command` operator-only, and `privileged_field` refuses a PROVIDER reconcile carrying one — so on this branch the published `@punktfunk/plugin-playnite@0.3.0` cannot publish anything at all. Not a launcher tile: not one game. That is a regression against a shipped plugin, and it is the same hole `launcher_ui` was created to close, one kind further along. Two kinds, both host-owned so D1 holds — the plugin supplies a validated VALUE and never a command line: playnite valued by the game's GUID; resolves to explorer.exe "playnite://playnite/start/<guid>", the same protocol-via-a-concrete-EXE shape the `epic` kind uses. GUID-validated on the way in (so a bad value is a 400 the plugin author can act on) and again at launch. launcher_ui now accepts "playnite" on Windows, resolving to Playnite.FullscreenApp.exe with Playnite's own install dir as the working directory. Fullscreen, not Desktop, is the whole point of a couch tile — and it is also why this one cannot ride the URI the games use: probed on .173, Playnite's registered `playnite://` handler is bound to Playnite.DesktopApp.exe, so no URI opens fullscreen mode. The exe is spawned directly, with the install dir read from Playnite's own uninstall entry (HKCU, then HKLM for a machine-wide install), falling back to %LOCALAPPDATA%\Playnite. `valid_launcher_ui("playnite")` is answered by RESOLUTION rather than by a static list: a host without Playnite installed refuses the entry instead of publishing a tile that does nothing when a user clicks it. That is the same instinct that left Epic, GOG Galaxy and the Xbox app off the list — each still needs its own verified activation, and a guess would ship exactly that dead tile. Gates: punktfunk-host 436 passed / 0 failed on .21 (the Linux arms), and the Windows arms compiled and their library tests run on .173.	2026-08-06 14:35:48 +02:00
enricobuehler	883c317872	feat(clients/library): a launcher tile looks like one, on every client ... The host has been able to describe a launcher entry since M2 — `role: "launcher"`, the `steam_ui` and `launcher_ui` kinds — and the web console has grouped them into their own rail since M4. No other client ever looked. `pf-client-core` decoded `role` into an `is_launcher()` helper with zero call sites, and the shared console model dropped the field entirely on its way to the renderer. So a launcher tile arrived everywhere else as an ordinary game with no cover art: indistinguishable from a title whose poster failed to load, sorted into the middle of the alphabet, and captioned "Play". One contract, implemented in each client's own idiom: * launchers never interleave with titles — they lead, and each group keeps the host's title order * grid surfaces get a labelled section; a coverflow keeps its single carousel and names the group the cursor is in, changing as it crosses the boundary. A second focus rail would mean a new up/down nav model in three renderers for two or three tiles * an art-less launcher gets an accent face naming its launcher, not a title monogram on the neutral one — "opens Steam", not "a cover that didn't load" * anything that is not `"launcher"` is a game, and a host that omits the field renders exactly as before (design D4's intended degradation) * launching is unchanged: the client sends an id, the host resolves the recipe The grouping is enforced once per client stack rather than per screen. In the console UI it is an invariant of `LibraryShared::set_games`, so the cursor arithmetic, the art pump and every future consumer inherit it; on Apple and Android it is applied where the library is fetched/parsed. Fixed in passing: the Apple and Android store badges were hard-coded `isCustom ? "Custom" : "Steam"`, so every Lutris, GOG, Heroic, Epic and Xbox title was labelled "Steam". Both now carry the same store table the Rust clients use. The CLI's `--library` gains a fourth column (`game`/`launcher`), appended rather than folded into an existing one so anything reading the first three is untouched. Gates: punktfunk-host 436 passed / 0 failed and pf-console-ui 49 passed / 0 failed on .21 (three new tests), workspace clippy -D warnings and cargo fmt --check clean there; `swift build` of the full PunktfunkClient and `:app:compileDebugKotlin` clean on macOS; `cargo check` + `clippy -D warnings` for the Windows client on .173. Still unproven on hardware: no launcher tile has been clicked on a real host — that needs the plugins published, which needs this branch's base merged first.	2026-08-06 14:35:24 +02:00
enricobuehler	81b4f76c4d	fix(client): a session ending on purpose stops reading as a failure ... The desktop clients turned every host-side close into "Host ended the session", and a reason string means "abnormal" to everything downstream: the GTK and Windows shells raised a banner, the console overlay drew a status strip. Quitting a game you launched yourself produced all of that. Now only a host error or a lost connection carries a message; the deliberate endings return the silence those shells already give a clean exit, which is also what puts the console back in its library with nothing in the way. The Apple client gains the same distinction. It had one line for every ending — "Session ended by <host>." — which is fine for an operator stopping the session and wrong for a link that died, so each now says what happened. A game exiting stays silent and returns to the library it was launched from. Both read the reason while the connection is still up, because tearing it down is what makes it unreadable, and both fall back to their previous wording when there is no verdict — an older core, or a close that raced the read — rather than inventing a new one for a case they cannot see.	2026-08-06 14:30:46 +02:00
enricobuehler	ec44496285	feat(client): tell clients WHY a session ended, not just that it did ... A session ending was a single bit. A player quitting their game, an operator ending the session from the console, a stop the client itself asked for, a host crashing and a Wi-Fi drop all arrived as the same "closed" — so every client had to write one message covering all of them, and every client picked an error. That is how quitting your own game came to be reported as trouble on all three. The information was already there and thrown away: the host closes with APP_EXITED when a launched game exits, with 0 when it ends the session cleanly and 1 when it fails, and a link that simply dies never closes at all. The connection watcher now classifies that into a PunktfunkEndReason — local, game exited, host ended, host error, lost — and latches it before the shutdown flag, since the two are read by different threads and the reason must never arrive second. Exposed as punktfunk_connection_end_reason. This replaces the game-exited flag added a moment ago rather than joining it: that question is one row of this table, and it was never released. Still additive to any embedder that ignores it, and the host sends the same bytes either way, so the wire is untouched. `is_normal()` is the question nearly every caller actually has, so both the Rust and C surfaces answer it directly rather than making each client re-derive which of five values are worth alarming a user about.	2026-08-06 14:30:33 +02:00
enricobuehler	d4dd5f7a3d	feat(client): a game exiting takes you back to its library ... Quit a game you launched from a host's library and the stream ended with "Session ended by <host>." on the host-selection screen — an error report for something you had just done on purpose, and several taps away from starting the next title. The host has always said what happened: it closes the connection with APP_EXITED when the game it launched for a session exits, and that code's own documentation describes this feature. Nothing ever read it — a search across every client found zero consumers. (It also could not reach anyone until the previous commit, since the close only happens once the lease declares the game gone.) The core now records the reason as it observes the close, latched before the shutdown flag because different threads watch the two, and exposes it as punktfunk_connection_game_exited. Purely additive: a client that never asks behaves exactly as before, the host sends identical bytes, and the wire version is untouched — ABI 17. The Apple client asks while the connection is still up, then treats a game exit as the normal finish it is: no error banner, and if the session began as a library launch it reopens that library so the next title is one tap away. Any other ending — a stop, the host going away, network loss — is unchanged. The other clients keep their existing end-of-session behaviour; the call is there when they want it.	2026-08-06 13:58:57 +02:00
enricobuehler	76e8bd1b98	fix(host/gamelease): a game that exited stops counting as running ... When a launched game's processes are all gone, the watcher asks one last out-of-band question before ending the session: does the launcher still think the game is up? On Windows that reads Steam's per-app `Running` registry flag. It was only ever meant to be a tie-breaker for a scan that momentarily can't see the game — a launcher re-execing, an engine relaunching itself into a new pid. It had no bound. Honouring the flag reset the confirm window every pass, so a flag Steam left set — it does that whenever it doesn't cleanly observe the exit: it crashed, it was closed first, the game re-parented — pinned the lease in `running` for the life of the host. The console kept showing the game, `session_on_game_exit` never fired, and the only way to get the stream back was a manual "End". Reported from the field on Windows 0.24.0. `steam_running_hint` also believes the FIRST hive that says so, so a stale flag in any loaded profile was enough. The absence timer now keeps running instead of being reset, and that is what bounds it: past `VETO_LIMIT` (30 s) with nothing of the game on the box, the launcher's opinion is stale rather than early and the session ends anyway, logged at WARN so it is visible. Ending a moment early is the cheaper failure — the stream drops while the game lives, the user reconnects, and nothing is ever killed. Ending never was the bug. The rule is now a pure `exit_confirmed(gone_for, hint_running)` with a test. The watch loop polls a live process table and can't be unit-tested, which is exactly how an unbounded veto shipped unnoticed.	2026-08-06 13:58:24 +02:00
enricobuehler	fbdad8d917	Merge pull request 'fix(clients): host discovery heals itself, and every client can rescan' (#67) from worktree-host-discovery-refresh into main ... Reviewed-on: #67	2026-08-06 11:51:30 +00:00
enricobuehler	b25e6eda91	fix(clients): host discovery heals itself, and every client can rescan ... A field report from an iPad: the host is not found on first run, and restarting the client finds it. Pull-to-refresh appeared to do nothing. Both were real. The Apple client's discovery had three ways to go permanently deaf, each needing an app relaunch to clear: - A failed resolve was never retried. `browseResultsChangedHandler` only fires when the result SET changes, and a host whose resolve failed is still in the set — so nothing ever re-offered it. - A stuck resolve never ended. `NWConnection` has no timeout, so the throwaway UDP flow used to resolve an address could sit in `.preparing`/`.waiting` forever, and a service with a connection in flight was skipped. - `NWBrowser` parking in `.waiting` was ignored (only `.failed` re-armed). On iOS that is where the local-network privacy prompt lands on first launch after install: the browse starts, the system asks, and the browser waits. Granting does not revive that browser — only a new one sees the grant. That is the reported first-run bug. HostDiscovery now runs a 1 Hz sweep that times out stuck resolves, retries failed ones on a 1→30 s backoff, and re-arms a browser that stopped working; the advert's TXT is re-read on every browse report, so a host that re-keys or flips its pairing policy is followed. Returning to the foreground re-arms the browse (iOS/tvOS: `onAppear` does not fire across background/foreground, and a suspended browse stays dead). Pull-to-refresh did nothing because there was no `.refreshable` in the client at all. Added, plus the explicit control the report asked for: a toolbar Refresh on iOS/macOS, an action-row button on tvOS, a Rescan tile in the gamepad launcher, Scan Again on the empty state, a header-bar button in the GTK client, a hosts-page button on Windows, and Scan again on Android. Decky already had one. The desktop/Android browses needed a rescan trigger to make those buttons mean anything: mdns-sd re-queries on a doubling backoff capped at ONE HOUR, so a long-lived browse is effectively passive and a host that appears later can stay invisible. `discovery::Rescan` forces a fresh query; the wake-and-wait loops use it too, so a host that just booted is noticed in seconds rather than at the next backoff tick. Also fixed, found on the way: clients/windows/src/discovery.rs is a second copy of the browse that d0fa8bd3 ("pin mDNS discovery to IPv4 on every client") missed. It took an arbitrary first address, so when a host's OS responder answered AAAA the Windows GUI rendered a card that failed on every click. It also never noticed a dropped receiver, leaking a thread and a :5353 socket per wake-and-wait. Gates: Apple macOS + iOS (arm64-apple-ios17.0, proven non-vacuous) build clean, 195 tests pass incl. a new one asserting a rescan re-finds a still-advertising host. On .21: fmt, clippy --all-targets -D warnings and build clean for pf-client-core + client-linux + client-session, 117 tests pass. Android :kit: and :app: compileDebugKotlin clean. The Windows client is UNGATED — its CI runner was unreachable.	2026-08-06 13:30:10 +02:00
enricobuehler	5a7f7f0fc5	feat(clients/gamepad-ui): section tabs, background palettes, and a backdrop that moves everywhere ... The console settings were one 30-row scroll, which on a Deck meant thumbing past Video and Audio to reach the pad settings. They are now split across sections — Stream · Video · Audio · Controller · Interface · Profiles, plus Input on the desktop console, which alone carries the touch/mouse rows. L1/R1 walks them, each section remembers where its cursor was, and the names are the same word on every client so a setting is where you looked for it last. Shoulders are not the only route, because a D-pad remote hasn't got any: on Android, Up from the first row moves onto the strip (left/right walks sections there, A drops back in), and on tvOS the pills are focusable, so the focus engine handles it — a Siri Remote has no extended gamepad profile and never reaches the input poll at all. The desktop console needs neither; PageUp and PageDown already map to the same events. New "Background" row, six palettes: Violet (the brand default), Tide, Forest, Ember, Rose, Graphite. A palette is a hue rotation plus a saturation scale over the ONE colour field each client already draws, so every palette inherits its structure and Violet is the identity transform — existing installs see exactly what they see today. The maths is ported three times (Rust/Swift/Kotlin) under one shared `ui_palette` key, with the same assertions pinned in each language. It is presentation only, so it is a device preference and never part of a profile. The form screens no longer have a backdrop of their own. Settings, add-host and pair used to sit on a still gradient; they now wear the same living field at a calm mix — pools dimmed onto the palette's own corner colour, vignette halved so rows that run to the edges don't get crushed. On the desktop console that collapsed the old aurora-over-static crossfade into one shader pass with a chased uniform. Motion speed is identical in both modes on purpose: changing it would make the field jump mid-transition. Nothing in the gamepad UI is backed by a static image now, and Reduce Motion (Apple) / "remove animations" (Android) still freeze it. Also: the settings screen had no raster coverage at all — the eyeball dump is `#[ignore]`d — so a new test draws every tab, and the Android screenshot set gains a console-settings scene. Both earned their keep immediately: the renders showed the extra hint pushing "Done" off a 360 dp phone (the legend scrolls now, and the Section cell only appears where shoulders exist) and the form backdrop crushing its own edges.	2026-08-06 12:39:30 +02:00
enricobuehler	de6b9e94ec	Merge pull request 'fix(client/windows): settings persist when the app isn't installed on C:' (#62) from worktree-client-msix-persist into main ... Reviewed-on: #62	2026-08-05 20:53:38 +00:00
enricobuehler	5ebe840320	fix(client/windows): settings persist when the app isn't installed on C: ... Reported from the field (2026-08-05): a fresh Windows 11 box with a data partition, "New apps will save to: D:", and the client installed there. It launches, finds hosts and streams — but no setting and no profile survives a restart. Reinstalling to C: fixes it completely. The reporter's read was "it's in read-only mode", and that is almost exactly right. The one clue that localises it: the client creates its mTLS identity with a plain `fs::write` on first run and hard-exits if that fails. Their app started, so ordinary file creation in the config directory works. Only the config stores were being lost — and those are the three files that go through `write_atomic`, which writes a sibling temp and renames it over the target. The rename is what breaks. The client ships as a full-trust MSIX package, so its `%APPDATA%` writes are redirected into the package container. When the package lives on a secondary drive, Windows keeps that redirected state on the package's own volume: `C:\Users\<u>\AppData\Local\Packages\<pfn>\` stays a real directory on C:, but its children (LocalCache, RoamingState, …) are junctions to `D:\WpSystem\<SID>\…`. Both sides of our rename still spell `C:\Users\…`, so nothing looks unusual, but they can resolve across that junction boundary — and `std::fs::rename` is `MoveFileExW` with `MOVEFILE_REPLACE_EXISTING` and *not* `MOVEFILE_COPY_ALLOWED`, so a cross-volume move fails outright rather than degrading to a copy. Creating files still works, which is why everything else about the install looks healthy. So the fix is not to make the rename work — it is to stop treating it as the only way to persist. `write_atomic` now falls back to writing the target in place when the atomic route fails. That is the same operation the identity files already use, and those demonstrably round-trip on the affected installs, so the fallback lands on a path we know resolves. It trades crash-atomicity for exactly the writes that would otherwise be lost, and nowhere else: temp+rename stays the normal route everywhere it works. Writing into a redirected location cannot desync from reading it — Microsoft documents one private-location-first resolution order for both, so whichever layer a write lands in is the layer the next read finds. The fallback verifies anyway, by reading the bytes straight back: a write that reports success and disappears is precisely the bug being fixed, so this path does not get to claim success on an `Ok(())` alone. It costs nothing normally — it only runs on an install that has already shown it does something unusual. Two things this uncovered on the way: The temp file was a single shared `<name>.json.tmp`, but these stores have five whole-file writers (WinUI shell, session, console UI, CLI, Decky). Two saving at once collide on it — on Windows the second write hits a sharing violation, and worse, one process can rename the other's half-written bytes over the target. The scratch path now carries the pid. And none of this was visible to anyone. Every save on this page is fire-and-forget by design (a failed settings write must never take a stream down), so ~15 call sites discard the error and the UI cheerfully shows the toggle you just moved. The reporter had no log file to send either, because "Open log folder" was handing out a phantom path — a separate bug, already fixed in f3c0ee47 but not in the 0.24.0 they were running. `store_health` records the last persistence failure centrally, and Settings shows an error bar naming the path when the store is refusing writes, so a client that cannot save says so instead of pretending. `update.rs` had hand-rolled the same temp+rename inline, so it neither cleaned up its temp on a failed rename nor picks up the fallback; it now goes through the one writer. The update floor silently never rising is how a declined update comes back forever. Deliberately NOT done: disabling MSIX AppData virtualization in the manifest (`desktop6:FileSystemWriteVirtualization`). It would stop the redirection at the source, but every existing packaged install's settings, profiles and pairings live inside the container today — turning it off points the client at an empty real `%APPDATA%` and silently resets all of them. That needs a migration, not a manifest flag. Also considered and not taken: resolving the destination directory with `GetFinalPathNameByHandleW` and creating the temp inside the resolved path, to keep atomicity. It does not reliably close this hole — when the target file exists only in the unvirtualized layer while its directory resolves to the private one, the rename still straddles the boundary — and it would rest on canonicalisation behaving through the redirection, which we have never verified on a packaged run. Verified on the RTX box (.173, Windows 11 26200), which is the platform that actually has these rename semantics: `cargo fmt --all --check`, the full `pf-client-core` lib suite (109 passed), and clippy `-D warnings --all-targets` on both `pf-client-core` and `punktfunk-client-windows` — all clean. Also green under linux/amd64 (116 passed). Three new tests: the pid-scoped scratch path, the fallback actually persisting and reading back when the atomic route is blocked, and a genuinely unwritable store surfacing its error instead of swallowing it. The mechanism above is established from documentation and third-party reports, not from a reproduction on a second-drive install — that box does not exist here. The fix does not depend on the diagnosis being exactly right: it repairs any install where the rename fails but a direct write succeeds.	2026-08-05 22:33:36 +02:00
enricobuehler	6f07bd94d3	feat(library): launcher tiles a plugin can actually publish ... Design D4 promised entries that open the LAUNCHER — Steam Big Picture, Heroic, Lutris — and the plumbing for it landed in M2/M4: the `role` field, the `steam_ui` kind, the console's Launchers rail. But nothing could flow through it for anything except Steam. D4 said the other launchers would ride the `command` kind. The 2026-08-05 review then made `launch.kind = "command"` operator-only (it is handed to a shell), so a plugin publishing one is refused with a 403. The two changes are individually right and jointly leave a hole: `steam_ui` was the only launcher kind a plugin could publish, so a Heroic or Lutris tile was unreachable. New `launcher_ui` kind, valued by store id. One kind rather than one per store because every launcher except Steam has exactly a single UI to open; Steam keeps its own kind because it genuinely has two. D1 is preserved — the plugin names a launcher, the host builds the command, and no shell string crosses the wire: heroic -> the same native-or-Flatpak resolution the `heroic` game kind uses, minus --no-gui and minus the URI, so the window itself opens lutris -> bare `lutris`, which opens the window (the URI form is `lutris_id`) Platform-gated to what this host can actually resolve, and validated INBOUND: a value naming a launcher this OS cannot open is a 400 the plugin author can act on, not a tile that silently does nothing when a user clicks it. Windows launchers (Epic, GOG Galaxy, Xbox app) are deliberately absent — each needs its own verified activation and a guess would ship exactly that dead tile. Also closes a WP4.3 item I under-delivered and did not flag: the console's add/edit form had no way to mark an entry as a launcher, so even hand-adding one was impossible. It now has the checkbox — and `formFrom` round-trips it, without which editing a launcher entry would silently demote it to a game, which is the precise bug that file's own comment warns about. Gates on .21: punktfunk-host 435 passed / 0 failed (two new), workspace clippy -D warnings clean, cargo fmt --all --check clean, OpenAPI drift green. Console: orval + paraglide regen, tsc clean, check-i18n at 604 messages for en + de. Still unproven on hardware: no launcher tile has been clicked on a real host. The steam plugin (the first to emit one) is not built yet.	2026-08-05 21:12:19 +02:00
enricobuehler	d2085879da	Merge main: plugin art rides THROUGH the H-2 confinement, not around it ... PR #58 hardened the art proxy in the same three files this branch rewrote, and the two changes pull in opposite directions: #58 narrowed what the host will read from disk, while WP1.2 widened what counts as a local art path so an extracted scanner's covers can be served at all. Resolved so the widening goes through the gate rather than beside it. Kept from #58, unchanged: art_path_is_confined (UNC refusal, canonicalize-or- refuse, config-dir exclusion, roots check), the image-extension whitelist, sniff_image_type, validate_art_paths as write-time validation, the AuthLane privileged-field check on every entry in a reconcile payload, and the launch redaction in GET /library. Three reconciliations: * `local_art_bytes` converts a `file://` value to a path BEFORE calling art_path_is_servable, so the confinement check and the read see the same path. Ordering is the point: percent-decoding happens before canonicalization, so a `%2e%2e` escape cannot hide from the traversal check. Pinned by a test. * `art_roots()` gains $HOME on POSIX. This is the one that would have bitten silently: the list was empty on non-Windows, which was correct while is_local_art_path was Windows-shaped (Playnite is Windows-only, so nothing on a POSIX host was ever classified as local art and the confinement had nothing to confine). Once WP1.2 classifies POSIX paths as local, an empty root list is not "secure by default" — it serves NO plugin art on Linux, which is every cover the lutris and steam plugins emit. $HOME is the exact analogue of the Windows users base #58 already ships, and covers Steam's librarycache and grid overrides, Lutris's coverart/banners (both copies), Heroic's caches and all the Flatpak variants. It is not the load-bearing control: a value still needs an image extension, must canonicalize to a real regular file inside a root and outside the config dir, and must CONTAIN image bytes. * The two tests that both wanted to mutate PUNKTFUNK_LIBRARY_ART_ROOTS became one. Cargo runs tests as parallel threads of a single process, so two tests setting the same env var race. The `file://` and confinement assertions moved into #58's existing confined test; what remains of the WP1.2 test is the pure classification/rewrite half, which touches neither env nor filesystem. Also: `steam_ui` was missing from the list of host-resolved launch kinds in privileged_field's doc comment and in the 403 a plugin sees. Prose only — the check is a denylist (prep, launch.kind = "command"), so steam_ui was never actually refused — but a plugin author reading that error would have concluded otherwise. Gates on .21: punktfunk-host 433 passed / 0 failed (including #58's H-2 tests and the new file:// ones), full workspace tests clean, workspace clippy -D warnings clean, cargo fmt --all --check clean, OpenAPI drift test green.	2026-08-05 19:59:11 +02:00
enricobuehler	0d94ef0dbe	fix(host/mgmt): the field gate returns the refusal, not an error carrying it ... `check_entry_fields` returned `Result<(), Response>`, which trips `clippy::result_large_err` under CI's `-D warnings`: an axum `Response` is 128 bytes and it was riding in the `Err` variant. `Option<Response>` is the shape this always wanted. There is no error value to propagate here — the "error" IS the response the handler sends back — so `None` means "the payload may proceed" and `Some(r)` is the refusal to return. The call sites read the same, one word different. Caught by CI, not by me: I ran `cargo check` and not `cargo clippy -D warnings`.	2026-08-05 19:14:19 +02:00
enricobuehler	defdfbdb58	fix(security): plugin UIs get their own origin ... Closes H-3 of the 2026-08-05 review, the last of its six highs. A plugin's interface was reverse-proxied onto the console's own origin and framed with `allow-same-origin`, so plugin JS ran as first-party code on that origin: one `fetch('/api/**', {credentials:'same-origin'})` and the BFF attached the operator's ADMIN bearer. That reached everything `plugin_may_access` withholds — arm pairing, read the host PIN, approve a device, read `/hooks`. The "open in new tab" link was the same escalation with no iframe involved at all. The fix is not a sandbox attribute, and it is worth writing down why, because the obvious change is the one that does not work. Dropping `allow-same-origin` gives the frame an OPAQUE origin; its subresource requests are then cross-site; the `SameSite=Lax` session cookie stops being sent; every plugin asset 302s to /login and the frame is blank. Nothing about the new-tab link is helped either. So the origin moves instead. A second listener on its own port (default PORT + 1) serves plugin UIs and nothing else: different ORIGIN — scheme+host+PORT — so the same-origin policy separates the plugin from the console: it cannot read the console's DOM, its cross-origin fetch of /api/** is unreadable (no CORS) and cannot mutate (Sec-Fetch-Site sees same-site). same SITE — cookie scope ignores the port and SameSite is computed on the site, so the session cookie still reaches the plugin listener and plugin pages keep working. Enforcement is two refusals and both are load-bearing: the console origin refuses /plugin-ui/**, and the plugin origin refuses everything ELSE — above all /api/**, which would otherwise hand the admin bearer right back to plugin JS that is now same-origin with that listener. Both are unconditional: if the plugin port cannot be bound, plugin UIs are DISABLED and the console says so, rather than falling back to the arrangement this exists to remove. Two consequences that would otherwise bite in the field: The port has to be open. Done for the Windows netsh rule, the firewalld service and the ufw profile. A browser stores a self-signed-certificate exception per ORIGIN, including the port — and a certificate interstitial can never be shown inside an iframe, so the frame would just sit blank with nothing on screen explaining why. A `no-cors` probe distinguishes it (a TLS failure rejects; any HTTP answer, even 401, resolves) and the console renders a card linking the operator to open the port once in a real tab. Also here: the health probe moved server-side to the console origin (it used to rely on being same-origin with the plugin), the postMessage listener now verifies `event.origin` — a real check rather than a tautology — and plugin-kit's `postMessage(..., "*")` is documented as load-bearing, since narrowing it to `location.origin` would now target the plugin's own origin and silently drop every message. Verified against a running console with a fake mgmt API and a fake plugin: console /plugin-ui/** → 404; plugin-origin /api/v1/hooks, /, /login, /_auth/logout → 404; plugin page loads 200 through its own origin; unauthenticated plugin origin → 401 (not a redirect to a /login it does not serve); a forged x-pf-listener header changes nothing on either listener; the plugin's own Clear-Site-Data / Access-Control-Allow-Origin / Set-Cookie are dropped by the proxy allowlist; the plugin origin's CSP names the console as its only frame-ancestors source; and with the port squatted, ui-config reports `unavailable`, the console still refuses /plugin-ui/**, and the console itself keeps working. Still wants on-glass confirmation in a real browser — the cookie and framing behaviour is reasoned from spec, not observed. cargo fmt --all --check clean; cargo check -p punktfunk-host --all-targets green on Windows; web console builds and typechecks.	2026-08-05 17:50:04 +02:00
enricobuehler	8103958169	fix(security): the plugin lane stops being a way in ... Acts on the 2026-08-05 host security review. 36 of its 38 findings; the two exceptions are recorded below and in the review doc. The review's headline is that `plugin_may_access` was the one authorization gate in the system that was allow-by-default — a hand-maintained denylist of route prefixes, where every sibling gate is deny-by-default. Its own doc comment names the two capabilities it exists to withhold, and both were reachable one route over, because ~1450 commits of new routes were added and the list was never one of the things anyone remembered to update. So the gate is now an allowlist, and a test walks the live route table and fails the build for any route that has not been deliberately classified for both non-admin lanes. That test is the actual fix: it is what stops the next route from arriving pre-authorized. Route reachability and field authority turned out to be different questions. A provider plugin has to be able to reconcile its own library entries — that is what a scanner plugin IS — but `prep` and a `command` launch inside that payload are handed to `/bin/sh -c` as the host user, and every execution site documents them as operator-typed. Requests now carry the lane that authorized them, and those two fields are refused to everyone but the operator's own token. The art proxy read any absolute path off disk in the host process, which on Windows is LocalSystem, from a path the plugin lane could write and then read back — so it yielded `mgmt-token`, which is full admin. It now serves only real images (extension AND magic bytes, so a renamed secret fails), only from inside an allowed root, only after canonicalization, and never over UNC; and a path it would refuse to serve can no longer be persisted in the first place. On Windows, the config-dir hardening was skipped exactly when it was needed — it ran only in the branch that CREATES host.env, so the case it was written for (a local user pre-created the directory and planted one) was the one case it never ran in. It is now unconditional and first, an existing host.env is re-owned, and the inheritable OWNER RIGHTS ACE that kept an attacker's files theirs after the directory was re-owned is gone. The identity and token readers were hardening the directory only on the path that GENERATED a new secret, so a planted cert/key or token was adopted verbatim and permanently; they harden before the first read now. `ensure_admin_only_source` is implemented. The 2026-07-05 audit recorded it as FIXED and it was in no commit in this repository's history — the local EoP it described was live, and it is the payload half of the config-dir chain above. Also: the three input planes are bounded and lossy like the mic plane on the same loop already was; Android's library client no longer accepts any publicly-trusted certificate for the pinned host; the usbip vhci nodes get their own group instead of riding on `input`, which every packaging scriptlet tells users to join; a registry URL can no longer inject a TOML table into bunfig.toml; the pairing cooldown is charged before the arming state is read, so armed/disarmed is no longer a free oracle; and the whole Low tier, of which the two worth naming are a clipboard MIME NUL that panicked the host on one control message, and an unauthenticated global logout that let any LAN peer sign the operator out on a loop. NOT fixed, deliberately: H-3 (plugin UIs framed allow-same-origin). Dropping allow-same-origin does not work: the document's origin goes opaque, its subresource requests are then cross-site, the SameSite=Lax session cookie is not sent, and every plugin asset 302s to /login. The "open in new tab" link is the same escalation with no iframe at all, so the sandbox attribute is not where this gets fixed either. It needs a second listener — a distinct origin that is still the same site — which changes the console's deploy model and wants on-glass validation. The mechanism and the dead end are written down at the iframe. H-6 registry authentication, whose other half lives in unom/infra. The in-repo halves are done: workflow_dispatch inputs no longer interpolate into run: blocks (one of them in the step holding UPDATE_MANIFEST_KEY), and the syft installer is pinned to its tag instead of main. Digest pinning is left until the registry is authenticated, because a tag — content-keyed or not — can simply be overwritten while anonymous pushes are accepted. M-5 is half done: the oracle is closed, but binding the arming window needs the console to learn the fingerprint first, which is a knock-then-bind flow rather than an edit. Verified: cargo fmt --all --check clean; cargo check --all-targets green on Linux and on Windows (confirmed non-vacuous — a planted type error in windows/install.rs fails the build); scripts/xcheck.sh windows check green; cargo test -p punktfunk-host --bins 416 passed, the single failure being gamestream::stream::tests::sender_delivers_batches, the known qemu-environmental UDP-loopback flake that fails identically on clean main in the same container; cargo test -p pf-clipboard 13 passed; web console typechecks.	2026-08-05 17:12:12 +02:00
enricobuehler	3d4a659959	feat(host,sdk,kit): store claims, launcher entries, and plugin sources on the wire ... M2 of design/library-scanner-plugins-implementation-plan.md. Everything a library scanner plugin needs is now expressible over the API; all additive. WP2.1/2.2 — store claims (D2). library.json gains a v2 shape ({entries, claims}) that loads the v1 bare array unchanged and is written on the first mutation. PUT /library/provider/{p}?store=<s> claims a store for a provider: its entries then surface with deterministic <store>:<external_id> ids and the store's own badge instead of opaque custom:<id> ones. That identity is the whole point — entry ids, GameStream FNV app ids, client art caches and Moonlight pins all survive a title moving from an in-host scanner to a plugin. One provider per store (409 otherwise); DELETE releases; an empty reconcile does NOT (a store can legitimately have zero titles). While a claim is held, all_games() skips the matching built-in scanner, so the two never double-list during the bridge. WP2.3 — DetectHint gains steam_appid and env_marker, the two store-derived signals the host used to read for itself. Without them a steam plugin's lease tracking would drop from reaper-exact to dir-prefix, and Heroic-under-Proton would lose the only signal that works. Malformed markers are dropped, not honoured — this feeds a path that can end processes. WP2.4/2.5 — role: game|launcher on the entry shapes (serde-default, skipped when default), and a steam_ui launch kind valued bigpicture|desktop that opens the Steam client itself. Validated inbound as well as at launch. WP2.6 — GET/PUT /library/scanners generalizes to SOURCES: built-in scanners minus claimed ones, plus claimed stores, plus any provider with entries. The same library-scanners.json disabled-set backs all of them and the ids match by construction, so a user's disabled state carries over verbatim through the whole migration. A disabled plugin source has its entries filtered at read time, exactly like a disabled scanner. WP2.7/2.8 — plugin registration gains a category field (the console keeps library plugins out of the nav); index entries gain categories and per-platform detect probes, evaluated existence-only into CatalogEntry.detected so the host never re-grows per-store knowledge. Index SCHEMA stays 1 — additive. WP2.9 — OpenAPI + SDK regenerated on Linux; kit wire widened (LaunchSpec.kind is now a plain string documented against the host's vocabulary — closes G3), and ProviderClient.reconcile takes an optional store and returns the host's echoed entries so a caller can detect a pre-M2 host silently ignoring the claim. Also fixes a bug the S3 spike turned up: is_steam_launch gated on a steam:// URI, so a steam_ui launcher entry would have skipped BOTH gamescope's --steam mode and the B1 single-instance free — on a box autologged into game mode, the nested second Steam would see the first and exit, crashing the spawn. It now tests the first token. Gates on .21: workspace tests green (punktfunk-host 425 passed), workspace clippy -D warnings clean, cargo fmt --all --check clean, OpenAPI drift test green. plugin-kit: tsc clean, 20 tests pass.	2026-08-05 09:39:31 +02:00
enricobuehler	a418d2852a	refactor(host/library): launch helpers into launch.rs, art proxy resolves any id ... M1 of design/library-scanner-plugins-implementation-plan.md — behavior-frozen groundwork for lifting the six scanners out into plugins. WP1.1: heroic_command/heroic_launch_prefix, epic_launch_uri, gog_spawn, valid_steam_appid and shortcut_gameid move into library/launch.rs with their unit tests. The scanner modules beside it now do enumeration only, so they can be deleted wholesale later without taking launch logic with them (D1). WP1.2: is_local_art_path accepts file:// (the plugin contract) and POSIX absolute paths, excluding the two /-leading shapes the host itself emits (its own /api/ proxy path and protocol-relative CDN URLs). local_art_bytes percent-decodes and converts a file:// value first. The art proxy and fetch_box_art resolve ANY id against library.json before the legacy steam: branch, so a plugin's entries serve art without the host knowing its store. No API change; no user-visible change.	2026-08-05 09:09:19 +02:00
enricobuehler	1d6f4760f3	Merge branch 'main' into worktree-stall-ride-through	2026-08-05 06:22:41 +00:00
enricobuehler	56adb47026	fix(client-core): pad-audio references the WASAPI module by its mounted name ... The Windows build of pf-client-core has been red on main since the pad-audio merge (#23): pad_audio.rs calls `crate::audio_wasapi::device_by_id`, but lib.rs mounts audio_wasapi.rs AS `crate::audio` via the #[path] per-OS swap — the `audio_wasapi` module name never exists. Windows-gated call site, so every Linux leg stayed green while both `windows / build` targets failed E0433. One-line rename to the mounted path (+ the comment that pointed readers at the phantom name). Verification is the PR's own windows leg — the crate builds on no other platform this path compiles on.	2026-08-05 08:15:02 +02:00
enricobuehler	e5ca213339	fix(core/abr): a starved window is never a decode-knee sample ... Stall program T2 (amplification kill), the phantom-latch half. A deciding window that delivered under a quarter of the target rate (a host-side capture stall, an outage, a mid-window pause) carries starvation-shaped distress — a jump-to-live flush, a keyframe-ask burst — that the decode-cap latch read as decoder evidence: under a periodic capture stall (the RDNA4 standby-sink field cases, one stall every ~5 s) every edge offers another 'backoff' at the SAME rate, and one pair latches a phantom decoder knee at whatever rate the display driver happened to interrupt. The session then fights the cap's re-probe ladder (+12.5% per 16-128 clean windows) for minutes on a decoder that was never the problem. Starved windows still back off (real damage deserves the safe response) but take the same 'not a knee sample either way' arm as a draining backoff: they neither latch a decode cap nor erase the reference a genuine choke set, so a real knee's pair still finds itself around the interruption. The ¼ bar sits deliberately far under the ×¾ utilization bar climbs require. Gates: 44 abr tests green (2 new: the stall-cycle no-latch scenario and the reference-preservation scenario), full core lib suite 346 green (--features quic), fmt + clippy clean.	2026-08-05 00:28:25 +02:00
enricobuehler	e5416646f9	fix(host/send): a stall-resume frame paces at the proven rate instead of blasting ... Stall program T2 (amplification kill), the resume-burst half. The native pace budget was min(0.9 × time-to-deadline, overflow at ~3× stream rate) — for steady-state frames the rate term is smaller and decides, but for an OVERSIZED frame (a capture-stall resume carrying seconds of scene delta, a cold IDR) the deadline term clamped a multi-interval overflow into the remainder of ONE: an instantaneous many-×-stream-rate blast that overruns the socket tx-buffer and loses the very frame that would have ended the freeze. Field fingerprint across three RDNA4 standby-sink cases: WSAENOBUFS(10055) + loss_ppm spikes at stall edges, then a recovery-IDR round trip per retry while the client shows 'current bitrate 0.1'. The budget is now the overflow's wire time at the pace rate itself (send_pacing::native_budget, pure + unit-tested), bounded by an absolute 100 ms ceiling so a pathological frame can't park the send thread; the deadline stays a target, never a license to blast. Steady-state frames produce byte-identical schedules (the rate term already decided); PUNKTFUNK_PACE_FACTOR=0 keeps the legacy deadline-only spread; the GameStream plane's Moonlight-pinned schedule is untouched. Gates: host clippy --all-targets -D warnings + 9 send_pacing tests green (linux/amd64 container), fmt clean.	2026-08-05 00:28:13 +02:00
enricobuehler	d27e62f7c9	fix(pad-audio): close the twelve findings the sweep left open on this branch ... Everything the 2026-08-03 haptics sweep filed against the pad-audio branch (P2 + P3). Four of them are the difference between a feature that works and one that fails silently. **B6 — nothing ever un-muted the coils.** Every rumble report asserts `HAPTICS_SELECT`, which is SDL's "disable audio haptics" bit: the firmware mutes the very voice coils the 0xD1 stream drives. No code anywhere cleared it again, so ONE rumble left tier-A haptics silent for the rest of that pad's life — no error, nothing in a log, and the host happily streaming into a muted actuator. `DsDevice.ds5AudioHapticsReport` is the documented undo (flag0 with both bits clear); written EP0-direct when the stream starts and again after a rumble stop while a stream is live, because the stop report re-mutes on its way past. **B10 — the desktop mix could reach a controller's coils.** Pad endpoints were filtered out inside `plan()` only. The watchdog, Follow mode and the parked default all go through `judge_default`, which classifies by NAME — and a pad endpoint is deliberately stamped "DualSense Wireless Controller" so games treat it as the pad's speaker. No name rule could ever catch one. It now refuses them by identity. **B27 — an out-of-range pad aliased onto a real slot.** The 0xCD plane's pad is the only u16 index and every consumer narrowed it with `as u8` on an assumption nothing enforced, so wire pad 256 steered pad 0's speaker volumes. Rejected at the decoder, which makes the narrowings lossless by construction. An existing test had pinned the bug in place, asserting that wire pad 513 round-trips; corrected, plus a test for the 256→0 alias specifically. **B7 — caps that arrived late were never announced.** The renderer commits the tier-A trade only once its sink opens, which is well past the arrival burst's two 100 ms ticks, and `set_pad_audio_caps` only stored an atomic. The client believed it had pad audio while the host emitted nothing. The input task now compares the live registry against what the last arrival actually carried and re-arms the burst itself — no new plumbing, and no extra traffic when nothing changed. The rest: `needs_aeb_kick` is finally ACTED on (R4) — a stored-but-not-served endpoint is declined rather than opened, because `AUTOCONVERTPCM` makes it succeed and mis-route; a failed provisioning no longer latches `PROVISIONED` for the process lifetime (R5), and `host_cap` retries, so a host that started while the audio stack was busy recovers at the next connect instead of the next reboot; the loopback init timeout reaps its thread instead of detaching one per ~2 s reopen (R6); kind-change restarts are bounded (R3) since the trigger is a client-sent arrival; the devtest uses the endpoint's real channel mask (B11) instead of letting wasapi derive 0x0F against the endpoint's 0x33; the render loop asks `is_session_ended()` rather than spinning at nice -16 (R12); short writes are counted and reported instead of dropping the tail in silence (R13); and a frame addressed to another pad is dropped before it can seed the gap tracker from a foreign sequence space (R14). Verified: punktfunk-host clippy -D warnings **0 on a real Windows box**; Linux/amd64 clippy 0 with **589 tests** (pf-client-core 114, pf-inject 101, punktfunk-client-android 20, punktfunk-core 345+1+8); Android :kit: tests + :app: compile green; fmt clean. Six punktfunk-host tests fail on that Windows box. FIVE fail identically on a tree with no pad-audio code at all (QUIC `Rejected(SetupFailed)` — the box's network environment); the sixth passes 3/3 in isolation and only failed under the parallel run, on a locally-bound ephemeral port. Neither is this change. Still owed: on-glass. This is a hardware feature and none of it has been on a real DualSense since the merge.	2026-08-04 23:55:47 +02:00
enricobuehler	0a72959ef7	Merge main into feat/android-pad-audio ... 86 commits of main, including the whole M1-M12 haptics sweep. Twelve conflicting files; three of them were more than textual. **The capability bits collided.** Both branches allocated the SAME wire bits for DIFFERENT features: `client_caps 0x04` and `host_caps 0x20` are redundant desktop audio on main and pad audio here. Merged naively, a peer would negotiate one and get the other. Pad audio moves to the next free bits — `CLIENT_CAP_PAD_AUDIO = 0x08`, `HOST_CAP_PAD_AUDIO = 0x40` — and the `abi.rs` mirrors move with them (their compile-time equality assertions caught the mismatch, which is exactly what they are for). **Both branches also claimed ABI v15.** Main's shipped (the rumble-policy floor), so the pad-audio surface becomes **v16**. **`native/input.rs` would have reintroduced a fixed bug.** This branch resets `rumble_seq[idx]` on pad removal; M1 established that the client's reorder gate is per-connection with no reset path, so restarting the host counter strands every later envelope until it climbs back. Took main's seq-preserving `clear_pad_feedback` and kept only the branch's `pad_streams.stop(idx)`. The rest: `wiring_plan::plan` now delegates to main's `plan_with_formats`, so the pad-endpoint filter moved into that body and the predicate behind it is factored out as `is_pad_render` (also what B10 needs); `Ds5Feedback::AUDIO` derives from main's `REPORT_ID_LEN` like its siblings; `AudioCtl` joins the explicitly-listed unhandled variants so the guard-false case is covered rather than swept up by a `_`; `include/punktfunk_core.h` regenerated rather than hand-merged.	2026-08-04 23:27:06 +02:00
enricobuehler	92f617a989	Merge remote-tracking branch 'origin/main' into worktree-haptics-m12-dry ... # Conflicts: # clients/android/kit/src/main/kotlin/io/unom/punktfunk/kit/GamepadFeedback.kt # crates/pf-client-core/src/gamepad.rs	2026-08-04 23:11:22 +02:00
enricobuehler	62d35bc4b6	Merge pull request 'fix(core/wire): a truncated trigger datagram stops cancelling the effect it should carry' (#45) from worktree-haptics-m10-wire into main	2026-08-04 21:07:54 +00:00
enricobuehler	fcf4076eb7	Merge remote-tracking branch 'origin/main' into worktree-haptics-m9-richfb ... # Conflicts: # clients/android/kit/src/main/kotlin/io/unom/punktfunk/kit/DsCapture.kt # crates/pf-client-core/src/gamepad.rs	2026-08-04 23:07:18 +02:00
enricobuehler	53eb592c43	Merge pull request 'fix(host/pads): a centred stick reads centred, and a delayed effect waits its turn' (#43) from worktree-haptics-m8-proto into main	2026-08-04 21:03:33 +00:00
enricobuehler	956d8dd8ef	Merge pull request 'fix(host/windows): two virtual pads stop tearing each other's reports' (#39) from worktree-haptics-m7-windows into main	2026-08-04 21:03:13 +00:00
enricobuehler	b2e716ad5f	Merge pull request 'fix(client/desktop): the Deck keeps its trackpad, and a pad stops buzzing at exit' (#38) from worktree-haptics-m6-presenter into main	2026-08-04 21:02:36 +00:00
enricobuehler	ffd5a33598	Merge pull request 'fix(core/rumble): the Deck's keepalive stops being swallowed by its own renewals' (#30) from worktree-haptics-m3-rumble-engine into main	2026-08-04 21:01:32 +00:00
enricobuehler	42a0dd52be	refactor(haptics): one copy of each thing every rumble path was transcribing ... Twelve findings from the sweep's DRY/docs/dead-code tail. Most are small; three found real defects hiding behind the duplication. **The UHID event ABI existed five times.** Every UHID gamepad backend — DualSense, DualShock 4, Switch Pro, Steam Controller, Steam Controller 2 — carried its own verbatim copy of the kernel's constants plus its own `put_cstr`, and they had already drifted: `switch_pro` was missing the SET_REPORT pair entirely, and `steam_controller` read a FIXED 16-byte SET_REPORT window instead of the event's own `size`. That last one is a bug in both directions — a longer report was truncated, and a shorter one had the parser reading whatever the reused event buffer still held past the payload, i.e. acting on rumble values the game never wrote. Now one `uhid_abi` module owns the numbers plus the two accessors that are easy to get subtly wrong, with tests on exactly that. **A dead force-feedback id fallback.** ff-core's `input_ff_upload` picks a free effect slot and writes it into the effect BEFORE uinput forwards the request, so the `id == -1` branch could never run — and allocating from a local counter would have been the wrong answer anyway, since the kernel owns that id space. Removed, with a `debug_assert` where it stood. **Apple's HID path silently dropped weak rumble.** `hidByte` took the top byte with no non-zero floor, so every amplitude below 0x0100 rendered as exactly nothing. Android has always floored it at 1; this was the odd one out. That converter also existed twice byte-identically inside one Gradle module — now one `wireAmplitudeToByte`. Also: the DS5 output-report layout gets named offsets (`dualsense_proto::out_report`) documenting all three transport bases — USB 0, SDL payload −1, Bluetooth +2 — since the differing bases are transport-forced, not drift. `pf-client-core` cannot import them (it and `pf-inject` do not depend on each other, and a DualSense layout has no business in `punktfunk-core`, their only shared crate), so its copy now DERIVES its offsets by explicit subtraction and a test pins the relationship. `PUNKTFUNK_HID_EFFECT_MAX` sizes the struct it describes instead of a second literal 11 — the header now emits `uint8_t effect[PUNKTFUNK_HID_EFFECT_MAX]`. The rumble policy engine's `min_pulse_ms` and `keepalive_ms` docs stop naming cases nothing implements: no in-tree caller sets `min_pulse_ms`, and the macOS DualSense-over-BT keepalive the doc cited CANNOT be served by the quirk, because that renderer skips writes whose levels are unchanged and would swallow the engine's re-emit — it keeps its own keepalive instead. `TrackpadHaptic` is marked as staged scaffolding (the tag is on a shipped wire; removing the variant would not reclaim it). Three ×257-vs-`<<8` doc comments corrected — the scaling itself is fine, both round-trip to 255. `backstop_ms.max(160)` deleted as unreachable (the engine floors at 500). New tests for `Ds5Feedback` and for the Android rumble JNI packing on BOTH sides, with `MAX_PADS <= 16` now a compile-time assertion rather than a comment. Closes S1-S9, S11, T2, T3 (design/haptics-sweep-2026-08-03.md M12). S11's second half is NOT a defect and was left alone: `clients/session/src/main.rs` calls `set_forwarding` unconditionally on every params-build (its own comment explains why — browse mode reuses one service across launches), so `Ctl::Forwarding` routinely arrives unchanged and that early-out is what stops a redundant `sync_open` + Valve-HIDAPI cycle each launch. Verified: pf-inject clippy -D warnings 0 / 91 tests; pf-client-core + punktfunk-core clippy 0 / 437 tests (amd64 container); punktfunk-client-android 7 tests; Android :kit: 6 tests; Apple swift build + 189 tests / 0 failures; cargo fmt --all --check clean. Each new test probed by reverting its fix — the fixed SET_REPORT window fails 3, a broken pack shift fails 3, dropping the amplitude floor fails 1, and a wrong DS5 offset either fails the pin or refuses to compile.	2026-08-04 22:52:38 +02:00
enricobuehler	b31495bea5	fix(host): a leftover Sunshine folder is not a conflict, and a crashed host gives the screen back ... Three things a field report (Discord, upgrade from 0.1x) turned up, all on the Windows host. 1. "It thinks I have Sunshine/Apollo running." It didn't — they were uninstalled. Both uninstallers leave their config/log directory in Program Files behind, and `detect.rs` counted a bare directory, or a service registered at ANY start type (including `disabled`), as a live conflict. The installer's own probe was narrowed to "service start type <= 2" after exactly this cried wolf on a `winget install`, and the tray dropped its always-on warning for the same reason in 3e782852 — the runtime probe never got the same treatment, so the one surface the user actually looks at kept shouting. `Evidence::is_active` now draws the line (running, or set to start on its own) and only active detections reach the startup warning, the `detect-conflicts` exit code, and `/local/summary`. Dormant findings still print in the full report, under a heading that says they need no action — that report is where "why does it think I have Apollo?" gets answered. 2. The console's conflicts card hardcoded "Another game-streaming server is **running** on this machine" regardless of what was found, so a dormant leftover was announced as a running server. It now says "active", and each entry names the observation — `Sunshine (running)`, `Apollo (starts automatically)`. 3. "The exclusive screen never times out going back to re-enabling the display." `isolate_displays_ccd` deactivates the operator's panels and hands the pre-isolate topology to the caller, which restores it at teardown — but that snapshot is PROCESS MEMORY, and Windows deliberately never saves the isolated topology to the CCD database. So a host that crashed, was killed, or was stopped mid-session left the desk dark with nothing in the product to undo it. There was one startup recovery leg already, but only for the EXPERIMENTAL `pnp_disable_monitors` axis, which is off by default — the default Exclusive path had none. `isolate_journal` now marks what an isolate is about to switch off (before the apply, so dying mid-apply is covered), clears the mark on restore, and force-EXTENDs at host startup if a mark survived. EXTEND rather than replaying the saved blob: the blob pins the virtual display's target id, which dies with the crashed host, so a replay would mostly fail BAD_CONFIGURATION into the very same backstop `restore_displays_ccd` already keeps — and EXTEND stays correct across a reboot, where saved ids would be stale.	2026-08-04 22:34:33 +02:00
enricobuehler	1db7058a5d	feat(clients/input): system buttons route around local overlays ... Pressing guide/Steam/QAM collided with the client device's own shell: iOS 26 opens its Game Overlay for the Home press (no app opt-out until iOS 27 makes it a user setting), and a Gaming-Mode client opened BOTH Steam overlays for one press — the local one covering the stream. Two cross-client tier-P settings, zero wire changes: - system_buttons (auto|forward|local): raw guide+misc1 passthrough. Auto forwards everywhere EXCEPT under gamescope, where SteamOS reacts to the same physical press no matter what. - guide_gesture (auto|on|off): hold Select ALONE ~350ms sends the HOST's guide, down until release — held on, that's the host's long-press, which opens a Gaming-Mode host's QAM for regular pads. A Select tap is delivered on release with its up TAP_PRESS (50ms) behind, because per-transition sends fold into seq'd GamepadState snapshots and a back-to-back pair can coalesce into no press at all. A Select inside a combo (the escape chord) passes through untouched. Auto arms it only where the raw press can't reach the host cleanly: gamescope, iOS/iPadOS, tvOS. The same SelectGesture rules live in pf-client-core (pure state machine + unit tests), the Apple client (mask-diff adaptation in GamepadCapture), and Android's GamepadRouter. Settings rows on every surface (GTK, WinUI, console UI, Decky, Apple x2, Android x2) with profile plumbing throughout. punktfunk-session grows a control socket ($XDG_RUNTIME_DIR[/app/$FLATPAK_ID]/punktfunk-session-ctl.sock — the one runtime path a flatpak and the host see identically): 'guide'/'qam' verbs inject synthetic taps. The Decky panel gains a Host menus section (visible while the client runs) whose buttons press the host's Steam/QAM and close the local menu so the host's shows through. iOS 27's GCControllerHomeButtonSettingsManager deep-link is a TODO (the class needs the Xcode 27 SDK to compile). Docs: input, client-settings, steam-deck. Design: punktfunk-planning design/system-buttons-routing.md. Gates: docker clippy --all-targets --locked -D warnings + tests (pf-client-core 88 incl. 6 new gesture tests, pf-console-ui 47), cargo fmt --all --check, swift build (macOS), gradle kit+app compile, decky tsc --noEmit + py_compile. clients/windows not compiled (no box).	2026-08-04 21:46:27 +02:00
enricobuehler	0d407a866d	fix: a host that changed DHCP lease could no longer be streamed from the panel ... An adversarial review of this branch found a regression I introduced, plus three smaller defects. All four are fixed here, each verified on .21. **The regression.** `mergeHosts` names a host by its record's stable id, and `hosts list --json` always emits one (`KnownHosts::load` mints ids for every record). So a launch always went out as `punktfunk launch <uuid>` → `ConnectPlan::for_host` → `HostTarget::from(&KnownHost)`, which copies the address stored ON THE RECORD. Meanwhile the panel deliberately renders the LIVE advert's address. Nothing on a Deck ever writes a moved address back — `discover` and `hosts list` are both reads, and only the desktop shells' hosts pages update one. So after any DHCP move the row read "online" at the new address and every press dialled the old one: a 15 s dead connect, or — if a MAC had ever been learned — a black Steam "game" for the full 90 s wake budget. Proven with a stub session binary: `launch abc-123` emitted `--connect 10.0.0.5:9777` for a host answering at `10.0.0.99`. This worked on origin/main, which dialled `toHost(v).host` — the advert's address. The fix restores that without giving up stable ids: `hosts add <new-addr> --fp <known-fp>` now MOVES the matching record instead of filing a second one (the fingerprint is the identity — this is the same rule that makes the verb idempotent), and the panel re-points a host it can see has moved before launching it. Verified: `moved 10.0.0.5:9777 to 10.0.0.99:9777`, one record still, and `launch abc-123` then emits `--connect 10.0.0.99:9777`. **"No hosts yet" was also how a missing client looked.** `_cli_argv()` returning None becomes `client-unavailable`, which the panel dropped on the floor — so a Deck with no client installed was told its network was empty, under a button that launches the client that isn't there. It now says which of the two it is. **The browse worker never exited on a quiet LAN.** `discover_for` drops the receiver and the doc claimed that stops the thread. It does not: the worker parks in `recv()`, and the arms that ignore an event (`SearchStarted`, `ServiceFound`, `SearchStopped`, a v6-only advert) never touch the sender, so on a LAN with no Punktfunk host nothing ever wakes it. Harmless today because the only caller is a short-lived CLI process, but the function invites in-process use, where it would leak a thread and an mDNS daemon per call. Now polled with a 250 ms tick and a check at the top of the loop. Verified: ten back-to-back browses settle back to the baseline thread count. **A `pair=optional` host was recorded as paired.** Every unsaved host now goes through the trust sheet (it has no pin, so it cannot stream without one), but the sheet's only non-PIN action ran `--request-access`, which persists `paired: true` on Ready. An optional host admits anyone who pins its identity — there is no operator decision, so nothing was approved and the same box read "paired" here and "trusted" in the desktop client. Such a host now gets **Connect** instead, which pins and streams without claiming an approval, and the "approve this Deck" toast is no longer shown to someone who has nobody to ask. Also: `PF_CLIENT_BIN` was the one launch-option value never validated — a client installed under a path with a space would split Steam's tokenizer.	2026-08-04 21:26:09 +02:00
enricobuehler	414380fc9e	fix(cli): discover reads the host store without writing to it ... `KnownHosts::load()` mints a stable id for any record that lacks one and SAVES it — which makes it a write, and `discover` was calling it purely to annotate what the browse found with saved/paired. It never hands those ids back to anyone. That matters because the Decky panel issues `discover` and `hosts list` together, in parallel. Against a store written before ids existed, both processes read it, both mint DIFFERENT ids for the same record, and both save. Whichever loses the race has already handed its ids to its caller — so the panel could draw a row whose host reference no longer resolves, and pressing it would exit 5 ("no saved host matches") until the next refresh settled things. `KnownHosts::read()` is `load` without the mint: the store exactly as it is on disk. `discover` uses it; every caller that dials a host by id still uses `load`, so ids are still minted the first time anything needs one. Verified on a fixture store with no ids: `punktfunk discover` leaves it byte-identical, and a following `punktfunk hosts list` mints as before.	2026-08-04 21:07:37 +02:00
enricobuehler	2d43275fcb	fix(core/abi)!: stop exporting 149 unprefixed macros into every embedder's namespace ... BREAKING (C header only): constants such as MAX_PADS, TAG_LEN, ABI_VERSION, INPUT_MAGIC and the whole BTN_/AXIS_ family are now PUNKTFUNK_-prefixed. cbindgen emits a bare #define per `pub const`, so those names landed in the namespace of every C program that includes the header. The rename table already said this was the rule and already carried the handful someone had noticed — and its own comment spells out why it matters: a clashing #define silently takes the last definition rather than failing to compile, so the failure mode is a wrong value, not a build error. This is the remaining 149. Associated constants are deliberately left alone. cbindgen already qualifies those with their type name, which is the very property whose absence makes a bare MAX_PADS dangerous — they are namespaced, just not by us. Nothing in this repository consumed the unprefixed spellings except one Swift test, which sat next to lines already using the prefixed form because its constant happened never to have been added to the table; it is updated here. The C harness links and runs against the regenerated header. Scheduled deliberately: the sweep flagged this for a release boundary, and 0.24.0 has shipped. External C embedders using the old spellings must add the prefix; there is no silent breakage, since the old names simply stop existing.	2026-08-04 20:52:58 +02:00