228 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	55dbb14cf4	docs(windows): the signing pages still told users to import a certificate we no longer publish ... Azure Artifact Signing chains to a public root, so neither the host installer nor the client MSIX ships a .cer any more and users import nothing. install.md, install-client.md and windows-host.md still walked through importing one — and because the pre-Azure files are still sitting in the package registry those URLs return 200 rather than 404, so following the docs didn't fail loudly, it quietly planted a retired self-signed cert in machine Root and TrustedPublisher. Verified on glass against the 0.29 canary while checking the release: both artifacts verify Valid, timestamped, and publicly trusted, and the MSIX installs with nothing imported. Also corrected while here: the MSIX publisher change makes a different package identity, so installs from 0.28.1 or earlier need an uninstall rather than an upgrade (and a packaged app's settings go with it, so the client pairs again); a silent UPGRADE reuses the task selection the previous install recorded instead of the wizard defaults, so a once-declined installgamepad silently keeps stale gamepad drivers; installaudiocable stopped being a task name in 4a621de6; and Add-AppxPackage from a non-interactive session can fail 0x80070005 when the Windows App Runtime it depends on is in use.	2026-08-14 23:50:00 +02:00
enricobuehler	b2146f33fe	fix(apple): the app menu ate ⌘Q, so the host's compositor never saw the chord ... With the default modifier layout ⌘ is Super on the host, which makes ⌘Q the chord a Hyprland/KDE/GNOME user reaches for first. AppKit dispatches menu key equivalents before the stream view ever sees a keyDown, so it quit the client instead. Not Hyprland-specific. `InputCapture`'s local keyDown monitor now claims every ⌘ chord while input is captured and forwards it to the host itself. It has to send from there: the monitor runs ahead of BOTH the menu and `StreamLayerView.keyDown`, and on macOS that second one is the host's only key path (the GCKeyboard send has been iOS-only since e414ec0) — so returning nil to keep the menu out takes the host's copy with it. The file's own comment said the opposite, that swallowing keys "risks starving GC's own delivery"; on macOS there is no GC delivery to starve, which is why this could never have been a one-line `return nil`. Verified against AppKit rather than assumed: a standalone harness posting a synthetic ⌘Q confirms the monitor sees it first and that returning nil stops the menu item firing, with a passed-through ⌘W as the control. ⌘⎋ and ⌃⌘F stay client-side whatever the setting says — forward those and a captured stream is a room with no door. ⌘Tab, ⌘Space and Mission Control are out of reach for a local monitor: macOS claims them before any app sees them, and catching them needs a CGEventTap and an Accessibility prompt, which is a product decision rather than a code one. This answers to the cross-client "Capture system shortcuts" (`Settings::inhibit_shortcuts`), which the Apple client had no answer to because SDL's keyboard grab is what implements it everywhere else. Default on, profileable like its siblings, and — matching the SDL clients — inert under the desktop mouse model, which is something you ⌘Tab away from. Two adjacent defects fixed on the way, both the same root cause. macOS stops delivering keyUp while ⌘ is held, so a forwarded chord key is released when the last ⌘ comes up rather than waiting for an up that may never arrive, and the one-shot `suppressedVK` latch is cleared in the same place — left pending (⌃⌘F's F, ⌘⎋'s Esc) it would go on to eat the next press of that key. Chord matching also stopped comparing the raw `deviceIndependentFlagsMask`, which carries Caps Lock and the arrows' .function/.numericPad bits: with Caps Lock on, ⌘⎋ and ⌃⌥⇧Q — both escape hatches — were not recognized at all. On glass still owed: a clean compile proves nothing for an input grab.	2026-08-14 22:04:30 +02:00
enricobuehler	99eb679c07	feat(clients): a moved mgmt port now outlives the advert that announced it ... Moving the mgmt port off 47990 (the fix for sharing a box with a Sunshine fork, whose web UI owns that port) only ever worked for as long as mDNS did. The real port lived in the advert and nowhere else: every client read it live and threw it away, so on a VPN, a routed subnet, or any multicast-dead network the library silently fell back to a port nothing was listening on. `KnownHost` gains `mgmt_port: Option<u16>` + `effective_mgmt_port()` + `learn_mgmt_port()`, exactly the shape `mac` and `os` already use ("learned from the advert while online, persisted so it survives the host going to sleep") — except this one is load-bearing rather than cosmetic, so `upsert` states the preserve rule explicitly instead of relying on the does-not-mention-it accident that `clipboard_sync` survives by, and `upsert_trusted` carries it across a re-key. Wired through all four client families, each of which was wrong in its own way: * CLI / Windows / Linux reached for `DEFAULT_MGMT_PORT` at the call site — the constant is the FALLBACK, not the answer. Windows also needed the port on `Target`, which the library screen has instead of a `KnownHost`. * The session console read `advert.and_then(mgmt_port)` with NO saved fallback, two lines above an `os` that gets the three-rung treatment right. It now matches, and learns on every tick. * Linux's `mgmt_port_for` consulted live adverts only; it now falls back to the store. * Android never carried the port at all — its native discovery record stopped at 8 fields. Added `mgmt` as the 9th (the record's own documented "new fields append, never reorder" rule), then through `DiscoveredHost` -> `KnownHost` -> `LibraryScreen`. * Apple LOOKED done and was not: `StoredHost.mgmtPort` and `effectiveMgmtPort` have existed all along, but nothing anywhere wrote the field and the `mgmt` TXT was never parsed — so it was permanently nil and every Apple client resolved to 47990 regardless. That is worse than the honest omissions above, because it reads as finished. Now parsed, carried on `DiscoveredHost`, and written by `HostStore.updateMgmtPort` at the same site that learns MACs and the OS chain. Also `PUNKTFUNK_NATIVE_PORT` in host.env, finishing the pair with PUNKTFUNK_MGMT_BIND: `--native-port` was likewise CLI-only and died on a package upgrade. A bad value is a startup ERROR rather than the silent fall back to 9777 that `PUNKTFUNK_DATA_PORT` still does — the failure that reads as "I moved the port and the client still can't reach me". The client side of the native port already worked (`KnownHost.port` is persisted, `--connect HOST:PORT` names it). Adding the field broke three `KnownHost` literals in tests, which is the `Default` impl's stated purpose working ("adding a field here can't silently produce records that lack it"). All three now carry 47991 — deliberately NOT the default, so the assertions cannot pass vacuously against a hardcode. New coverage: forward-compat decode of a store predating the field, the resolver fallback, re-key carry-forward, and on Android the 9th-field parse plus 0/non-numeric/out-of-range all reading as unknown. What this does NOT fix: a host that moved its mgmt port and has NEVER been seen over mDNS. Nothing tells the client where to look, and the honest fix is for the host to announce it in-band — the `Welcome` message has an established "append a trailing field, older peer decodes to the default" pattern for exactly this, at the cost of a C ABI accessor and a bump. Left for a separate change. Verified: Linux (punktfunk-rust-ci/pf-lxcheck2, amd64) `cargo check --all-targets` clean for pf-host-config, punktfunk-host, pf-client-core, punktfunk-cli, punktfunk-client-linux and punktfunk-client-session — the last confirmed non-vacuous by planting a compile_error! and watching the gate fail (cargo prints "Compiling", not "Checking", for bin-only packages, so the usual marker grep lies about it). Android: :kit + :app compileDebugKotlin clean, ParseRecordTest 12/12 with both new cases named in the XML. Apple: xcframework built, `swift build` complete, SharedFoundationTests pass. cargo fmt --all --check clean. NOT verified: the Windows client (192.168.1.133 unreachable).	2026-08-14 19:44:19 +02:00
enricobuehler	bb78117504	feat(host): moving the management port off 47990 now survives, and the console follows ... 47990 is the management API's port and also Sunshine's (and Apollo's, and Vibeshine's) web UI port. With the GameStream planes off it is the ONLY port the two still share, so moving it is the whole of what "run both on one box" needs — except moving it was barely possible: * `--mgmt-bind` was the sole route, and it lives in a unit file / service registration that a package upgrade rewrites. There was no `host.env` key, so the change did not survive. * The literal 47990 appeared in SIX places — mgmt::DEFAULT_PORT, the Windows service's console launch, scripts/punktfunk-web.service, the NixOS module, web/web-run.cmd, and the console's own default. Nothing downstream could learn a different port, so moving the listener silently left the console proxying to a port nothing was listening on. Now there is one source of truth. `PUNKTFUNK_MGMT_BIND` joins `host.env` (the `--gamestream` / PUNKTFUNK_GAMESTREAM shape: either source works, the CLI flag wins), and `serve` publishes the port it ACTUALLY bound to ~/.config/punktfunk/mgmt-endpoint, in the same KEY=VALUE form mgmt-token already uses so it is sourceable as a systemd EnvironmentFile and readable by the Windows service's existing read_env_file_value. Every consumer derives from that; the 47990 literals survive only as the fallback that keeps an OLD host working with a NEW console. The two unit files drop their hardcoded `Environment=PUNKTFUNK_MGMT_URL=` rather than layering a default beneath the file: whether Environment= or EnvironmentFile= wins is a directive-ordering question, and the hand-written unit and the Nix-generated one do not order the same way. No default, no precedence puzzle — the server's own built-in fallback covers a host that never wrote the file. Two robustness details worth naming, because both fail in the same direction: * mgmt-endpoint is written write-then-rename. A torn read would set PUNKTFUNK_MGMT_URL to EMPTY, which is worse than a missing file — a built-in default only rescues an *unset* variable. * mgmtUrl() now treats blank as unset, which `??` alone does not. The publish happens in parse_serve next to the token persistence, so both files appear together; the console's unit gates on mgmt-token, and its Restart=always picks up a lost race anyway. What this does NOT change: a lost 47990 bind is still fatal to the whole host (the bind sits in tokio::try_join! with the native plane), and running two Moonlight-compatible hosts at once is still unsupported — on Windows the exclusive display topology is a second, independent conflict. Both are documented rather than altered. Verified on Linux in punktfunk-rust-ci (amd64): cargo check --all-targets clean for punktfunk-host and pf-host-config with the "Checking punktfunk-host" marker confirmed present (a first run exited 0 having compiled nothing — the warm shared target dir judged it fresh), 40/40 mgmt tests pass including the new one pinning the published line against both parsers that consume it. Console: tsc --noEmit clean, bun test server/ 9/9. cargo fmt --all --check clean.	2026-08-14 19:44:19 +02:00
enricobuehler	6eb5edaff4	feat(audio): capture gain on punktfunk/1, and a soft knee instead of the clamp that made boosting a trap ... `PUNKTFUNK_AUDIO_GAIN` had two defects that compounded. It existed only on the GameStream plane, so on native `punktfunk/1` it silently did nothing — and since WASAPI loopback is tapped UPSTREAM of the endpoint's master volume, turning the host's speaker slider up does not change the level a client receives either. Between the two there was no host-side way at all to lift a quiet desktop mix on the protocol that matters. And where it did apply it was `(s * gain).clamp(-1.0, 1.0)` — a hard clip. Flat-topping a waveform is a first-derivative discontinuity, which radiates harsh high-order harmonics, so any operator who pushed past roughly 1.5x heard gross distortion long before reaching the level they were chasing. A field report of "+18 dB and everything warbles" is the expected output of that line, not a fault anywhere downstream of it. `punktfunk_core::audio::apply_gain` replaces the clamp with a tanh soft knee above 0.7 (~-3.1 dBFS), chosen for three properties: C1-continuous where the branches meet (slope 1 on both sides, so the onset of limiting is not itself an audible event), bounded by construction (asymptotic to 1.0, and +-inf maps to +-1.0, so nothing leaves out of range), and odd-symmetric (benign harmonics, no DC). It is a memoryless waveshaper, so it costs zero latency in the realtime encode path. Unity is a no-op inside `apply_gain` itself, not merely at the call sites, so the default wire stays byte-for-byte identical and a future caller that forgets to gate cannot quietly bend every peak. `capture_gain` is now shared by both planes and rejects the two values that are always typos: non-positive (would invert or mute) and above 8.0/+18 dB (capped, and said out loud). This buys headroom, NOT loudness. It cannot close a peak-to-loudness gap against already-limited broadcast content; that needs a compressor with a real time constant, which this deliberately is not, and the docs say so. `SOFT_LIMIT_KNEE` is excluded from cbindgen: it is host-side capture processing that no C embedder can act on, and exporting it would add a bare `#define` against the config's own R21 rule. Verified by regenerating `include/punktfunk_core.h` — byte-identical, ABI 19 untouched.	2026-08-14 18:49:29 +02:00
enricobuehler	13aa59c575	fix(vdisplay): the wlr-family backends asserted a cursor mode instead of negotiating it, so the portal refused the call ... Hyprland and wlroots both hardcoded portal `CursorMode::Metadata` whenever the session had negotiated the cursor channel, and never asked the backend what it supports. That is not a soft failure: xdg-desktop-portal's FRONTEND validates the requested mode against the backend's `AvailableCursorModes` and fails the call with `"Unavailable cursor mode %x"` before the backend ever sees it. So a cursor-forward session (desktop mouse mode) died at `select_sources`, surfacing as "pipeline build failed" and a black client, with `unavailable cursor mode 4` in the portal log. Field report 2026-08-14. MEASURED on .21 the same day, and it is worse than the report suggested: against a LIVE Hyprland 0.56.2 with xdg-desktop-portal-hyprland 1.4.1 and xdg-desktop-portal 1.22.1 — all current — `AvailableCursorModes` reads **3** (Hidden|Embedded) on both the backend impl interface and the frontend. xdph does not offer the metadata cursor at all, so this broke EVERY cursor-forward session on current Hyprland, not merely on old installs. Updating the portal would not have helped. xdpw is the same from the other end: its screencast.c refuses METADATA outright. pf-capture's own portal path has always negotiated (`choose_cursor_mode`); this restates that ladder in pf-vdisplay, which may not depend on pf-capture. The downgrade is graceful rather than merely survivable: with the portal on Embedded no `SPA_META_Cursor` arrives, so the host feeds the cursor channel nothing and a cursor-forward client draws nothing of its own — one pointer, not two. `PUNKTFUNK_PORTAL_CURSOR_MODE=auto|hidden|embedded|metadata` pins the preference for a backend that advertises a mode it implements badly, which negotiation cannot detect. It is a preference only: pins run the same ladder, so no value can re-create the refused request. The module is declared unconditionally so its ladder tests run on every CI leg rather than only the one that compiles `mod hyprland` — including a Linux-only test pinning our bit values against ashpd's enum, verified non-vacuous by planting a wrong discriminant (ashpd answers 4 for Metadata, the number in the report). The regression test uses 3, the bitfield measured on glass. Linux: 225 tests pass, clippy --all-targets -D warnings clean.	2026-08-14 10:27:14 +02:00
enricobuehler	6dd4add11b	fix(library): Steam's art lives in Program Files, which was never an allowed art root ... A field report: the Steam plugin installed, the grid stayed empty, and the only clue was one warn per sync — `art.hero: local art must be an image file … inside an allowed art root`. Two defects, both here. The art roots defaulted to the users base (`C:\Users`, from `%PUBLIC%`'s parent). That covers the launchers that install per-user, but not Steam, which installs to `C:\Program Files (x86)\Steam` and keeps both the things the plugin publishes there — `appcache\librarycache\<appid>\<hash>\` and each account's `userdata\<id>\config\grid\`. So every cover was out of root. It is a v0.28.0 regression: the built-in scanner the plugin replaced served covers through the legacy `steam:` art-proxy branch, which never passed through the H-2 confinement, so deleting the scanner routed that art through a gate it had never been measured against. `art_roots()` now also carries every Steam install it can find, from the three Program Files vars and from HKLM `Valve\Steam\InstallPath` so a Steam on another drive counts too. POSIX needs no equivalent — native and Flatpak Steam are both already under `$HOME`. The confinement is not weakened. It exists to stop the host (SYSTEM) reading what the plugin lane (LocalService) cannot reach itself; the Steam directory is readable by LocalService already, so nothing there is reachable *because* the host is privileged, and the extension, regular-file, magic-byte and config-dir gates still apply on top. Tested: `config.vdf` is not servable from an art root, nor is a non-image wearing `.png`. Second, and the reason this cost a whole library rather than a thumbnail: the provider reconcile validated art per entry and 400'd the WHOLE payload on the first bad value. A path mismatch therefore deleted every game from that store, and the plugin — which only ever sees `HostRequestError` — could not say which. A reconcile now strips unservable local art and syncs the rest, logging one aggregated warn with the count, an example path and the env var. The invariant the 400 held is unchanged: no unservable path is persisted. The operator's own single-entry writes keep the hard 400, because there the path was typed by hand and silence would be the wrong answer. Verified on Linux (.25: 493/493, clippy clean) and Windows (.133: 12/12 art tests, clippy clean). The new Windows test is hermetic — it repoints `%ProgramFiles(x86)%` at a synthetic Steam tree rather than asserting over whatever Steam the box happens to have, since the vacuous version of that test is what would have let this ship. Confirmed non-vacuous by disabling the fix: it fails on "the DEFAULT art roots must include it".	2026-08-14 08:38:43 +02:00
enricobuehler	082c65755f	fix(packaging): every channel ships the WSI layer, so in-game HDR works off a stock install ... The previous commit built the layer and taught the host to use it, but only the Arch PKGBUILD carried the files, so every other channel still landed on the no-game-HDR fallback. This finishes the job. The packaging scripts now take `--stage`, the DESTDIR the gamescope build script wrote, instead of a path to one binary. That is the part worth keeping: the next file this package needs will not require a new flag in four scripts and two workflows. CI caches the whole staged tree for the same reason. The gs-cache key already hashes packaging/gamescope/**, which this commit changes, so stale caches in the old single-file shape cannot be restored into the new layout. Channels, all of them: rpm spec gains Source1/Source2 and %files entries deb build-gamescope-deb.sh copies the layer into the package root Arch PKGBUILD (previous commit); the sysext extracts the whole usr tree sysext bazzite takes --gamescope-stage; arch asserts the layer arrived nix the derivation keeps, renames and rewrites the layer rather than deleting it with everything else A missing layer is fatal in every one of them, not best-effort. A package that carries the compositor without it looks completely healthy and then silently denies every game an HDR10 swapchain -- the exact failure this whole change exists to end, so it must not be possible to ship it again by accident. Two things needed care: The layer manifest carries an ABSOLUTE library_path baked in at build time, so every channel has to install the .so at exactly that path. That means literal /usr/lib/punktfunk, not %{_libdir} (which is /usr/lib64 on Fedora) and not a Debian multiarch triplet. Nothing links the .so by soname -- the loader dlopens it by that path -- so multilib has no claim here. The rpm and nix install checks now read the path back out of the manifest and fail if it names a file the package does not install, because a manifest pointing at nothing is the silent shape of this bug. NixOS has no /usr, so the layer lives inside the gamescope derivation and the host's path is overridable via PUNKTFUNK_GAMESCOPE_WSI_LAYER_DIR, which the module sets -- the same posture as PUNKTFUNK_GAMESCOPE_BIN, and documented. The manifest rewrite moved out of a heredoc into packaging/gamescope/rewrite-wsi-layer-manifest.py because the FHS builds and the Nix store both need it and must rename the layer identically; two copies would drift into a host looking for a name only one of them produces. Verified: 214 pf-vdisplay tests pass in a linux container, clippy -D warnings and rustfmt clean, bash -n on all five changed shell scripts, both workflow YAMLs parse, and the rewrite script was run against a synthetic FROG manifest to confirm it renames/repoints/regates while preserving the `functions` block -- which is the field that decides whether the layer loads at all. NOT verified: no nix on this machine, so gamescope.nix, flake.nix and the module are unevaluated; no gamescope build, no package build of any kind, and no game has taken an HDR swapchain on glass.	2026-08-13 23:37:48 +02:00
enricobuehler	c29e720324	fix(gamescope): HDR sessions anchored SDR white a stop bright, and never said game HDR was unreachable ... Field report 2026-08-13, Bazzite host in gaming mode to an iPad: Steam's Big Picture UI looked glaring and over-saturated while HDR game content looked washed out, both on the same stream. Those are one error. gamescope maps everything that is not an HDR game -- the desktop, the Steam overlay, an SDR title -- into the session's PQ container at --hdr-sdr-content-nits, and we only passed that flag when an operator had set PUNKTFUNK_GAMESCOPE_SDR_NITS. Unset, gamescope used its own default of 400, while every first-party client anchors diffuse white at 203 (BT.2408 reference white; the Apple presenter hands exactly that to CAEDRMetadata.hdr10's opticalOutputScale). The two ends were nearly a stop apart, so the UI landed above SDR white and the client's tone-mapper worked from a reference point the host had never used, flattening the content around it. The flag is now always passed, defaulting to 203. The knob still overrides it for anyone who wants a brighter or dimmer desktop. Separately, and visible in the same log: the two HDR decisions in a gamescope session are made independently. hdr_args() never consults wsi_layer_matches_our_gamescope(), so when the WSI-layer version check fires -- which it does on essentially every Bazzite box, since we pin our own gamescope rev and the check compares version triples -- the session launches advertising HDR while having made an HDR10 swapchain unreachable for every game in it. That layer is the only route to one, so a title told to render HDR renders it into an SDR swapchain and looks washed out, with nothing anywhere saying why. It now warns. The behaviour of the check itself is deliberately left alone: re-enabling a genuinely mismatched layer black-screens every Vulkan client, which is worse than losing HDR, and that trade needs a real box to retest. Verified: scripts/xcheck.sh linux clippy clean on pf-vdisplay (-D warnings), rustfmt clean. Not yet verified on glass.	2026-08-13 22:59:30 +02:00
enricobuehler	4ebe7d1185	fix(host): the plugin runner was located by FHS path only, so NixOS never found it ... On NixOS every plugin PACKAGE op failed with "the plugin runner isn't installed" on a box where the runner was installed, enabled and running. `runner_command()` checked FHS locations exclusively — /usr/bin, the /usr/lib + /usr/share pair behind it, and the ~/.local mirror the SteamOS installer lays down. Nix ships punktfunk-scripting as a derivation of its OWN, so its wrapper is neither beside the host binary nor anywhere under /usr, and no rung could ever match. Service ops go through systemd and were unaffected, which is what made it read as arbitrary: `plugins status` said running/enabled while `plugins add` said not installed. Resolution now matches punktfunk-encode-worker's: PUNKTFUNK_SCRIPTING -> beside the host binary -> PATH -> /usr -> ~/.local. PATH is the rung Nix lands on. The /usr rungs stay AFTER it rather than being dropped, because a systemd unit's PATH need not include /usr/bin. As with the encode worker the env override is deliberately not existence-checked — a named path that is wrong should fail naming itself, not fall through to some other runner. Lifted into a pure injected function so the whole table is testable, which is also how the regression is pinned: removing the PATH rung fails the NixOS row specifically. Second half, and the reason the Rust change alone would not have fixed the console: the NixOS module now puts the runner on the HOST UNIT's `path`. The console installs plugins from inside the host service, whose PATH is exactly that unit list — `environment.systemPackages` only ever covered an operator's interactive shell. Without it the CLI would have been fixed and the console would not. module-check.nix gains both the positive and the negative assertion, so CI's `nix flake check --no-build` holds the property. The error text named only apt and SteamOS; it now names NixOS and the override. The ~/.local/bin symlink workaround is no longer needed.	2026-08-13 20:27:26 +02:00
enricobuehler	7403450a8d	feat(host/library)!: the six built-in scanners become plugins — M6/WP6.4 ... The host no longer scans any launcher itself. `library/{steam,epic,gog,heroic, lutris,xbox}.rs` and the `scanner_defs()` table are gone; `GET /library/scanners` now lists exactly what the operator installed, every row `origin: "plugin"`. This is the end of the migration whose bridge half shipped in v0.26.0. The plugins have been published and index-pinned since 2026-08-08, so the replacement has been in the field for the whole bridge window. A host with no library plugins installed has an empty grid — that is the upgrade note. The console's one-click install per source (the D9 nudge) is unchanged and still never auto-installs. Nothing about a title changes when its plugin takes over, and that is why this could be a deletion rather than a rewrite: a plugin CLAIMS its store (D2), and a claimed entry surfaces under the deterministic `<store>:<external_id>` id the scanner used to produce. Entry ids, GameStream FNV-1a app ids, client art caches, Moonlight pins, the per-source toggles and the per-entry hides all key on that id and none of them move. `library-scanners.json` keeps its name, shape and contents: an operator who had `steam` off still has it off, with no migration. Kept deliberately: * `launch.rs` in full. Launch is host-owned by design D1 — a plugin publishes a validated value, the host builds the command — so every typed kind survives. `xbox_pfn()` MOVED here out of the deleted `xbox.rs`: resolving a package Identity to its PackageFamilyName needs `AppRepository` enumeration, readable by the host (LocalSystem) and denied to the plugin runner (LocalService). That measured asymmetry is the whole reason the `xbox` launch kind exists, so the resolver is launch vocabulary, not scanner vocabulary. * `SourceOrigin::Builtin`. No host build emits it, but the console ships as its own package and drives an N-1 host that still does, so the variant stays in the schema and the console keeps its `builtin` handling. * A store-label table, so a source row does not rename itself from "Steam" to `steam` the day its plugin takes over. Removed with the scanners: the background cover-art warmer and its on-disk cache (they existed only for GOG and Xbox, the two sources that had to ask a network catalog what a cover was — a plugin resolves art while it scans), the legacy `steam:` branch of the art proxy, and `GameMeta::pc()`. The host now makes no outbound HTTP request to build a library at all. Dependency audit, as WP6.4 required: `rusqlite` (with its bundled, cc-compiled SQLite) and `roxmltree` leave the graph — verified no other users. `winreg` stays: `launch.rs`, `procscan/windows.rs` and two `audio/windows/` modules need it. `base64`/`ureq` stay, exactly as the plan predicted. A stale `library-art-cache.json` from an older host is ignored, not migrated.	2026-08-13 16:51:19 +02:00
enricobuehler	5fbf04f56d	Ship punktfunk-gamescope on apt, support Debian 13, and state the real host floor (#190)	2026-08-13 10:21:52 +00:00
enricobuehler	85980b425e	docs: state the real host floor — Ubuntu 26.04+ / Debian 13+ — and name Debian everywhere ... The floor that matters is the DESKTOP, not the package: 24.04 installs punktfunk-host and then has no compositor over the version floors and no gamescope, which reads as a bug rather than an unsupported base. The requirements page now leads with a per-release table separating 'package installs' from 'can actually host', and install.md carries the same caveat next to the apt row. Debian was already a supported target after the previous commits but was still invisible at the entry points — README's install table, the docs index cards, and the 'what you need' list all said Ubuntu only. All three now name Debian and carry the version floor.	2026-08-13 12:20:33 +02:00
enricobuehler	107fa3472d	docs: Linux Mint 22.x cannot host, and 24.04 gives the host no compositor ... Measured on a real linuxmintd/mint22-amd64 image and on Ubuntu 24.04. The package installs on both, which is exactly what makes this easy to miss — nothing on the box can then produce a stream: * Cinnamon cannot host a virtual display (Muffin has no RecordVirtual). * gamescope is absent from 24.04 and cannot be built for it: the tree needs wayland >= 1.23.1 (has 1.22.0), libinput >= 1.26 (1.25), libavif >= 1.2.1 (1.0.4), pixman >= 0.44 (0.42), plus libdisplay-info2 and libxcb-errors0, neither of which 24.04 packages at all. * Switching desktop does not rescue it — 24.04 has KWin 5.27 (floor 6.5.6) and GNOME Shell 46 (floor 48). Only sway 1.9 is even a candidate. So the gamescope route documented for Cinnamon holds for LMDE 7 (Debian 13, verified end to end) but NOT for Linux Mint 22.x — which is every mainstream Mint until Mint 23 lands on a 26.04 base in December 2026. Both the Debian and Ubuntu pages now say so, and the Debian page carries a per-edition table. Also states what Debian 13 itself can drive: GNOME 48.7 and sway 1.10 are above the floors; its KWin 6.3.6 is below.	2026-08-13 12:12:52 +02:00
enricobuehler	030bc8a1c2	docs(debian): use deb822 sources for non-free, not apt-add-repository ... software-properties-common is not available in Debian 13, so the apt-add-repository line could not have worked. Debian 13 keeps its sources in deb822 format; edit Components there instead (verified in a trixie container — the NVIDIA driver it then offers is 550, above our 535 floor).	2026-08-13 11:47:20 +02:00
enricobuehler	346385bad8	fix(deb): ship punktfunk-gamescope on apt at last, and support Debian 13 ... `punktfunk-gamescope` had never been published to the apt registry — not in any release. It was built inside the host job's Ubuntu 24.04 image, where it cannot build: our pin vendors wlroots 0.19.3, which floors `wayland-server` at 1.23.1, and noble ships 1.22.0 (it also lacks libxcb-errors-dev and has only libdisplay-info 0.1.1). Every rung of that path was a `::warning::` returning 0 and the one hard gate ran last by design, so v0.26.0 and v0.27.0 both released with the package missing while docs-site told apt users to install it. The same tags shipped it fine for Arch, Fedora 44 and Bazzite. It now builds in its own job on Debian 13 (ci/gamescope-trixie.Dockerfile), the oldest apt base the tree configures on. One package serves Debian 13 AND Ubuntu 26.04 — measured by installing and running it on both — because the build also vendors libdisplay-info via the new `--extra-fallback` option: linked against the distro copy it demands `libdisplay-info2` on trixie, which Ubuntu 26.04 does not have (it carries libdisplay-info3). The option is opt-in, so the Arch/Fedora/nix outputs are byte-for-byte unchanged. Ubuntu 24.04 gets no gamescope package and cannot — its wayland is too old to run one however built. Debian 13 is now a documented host target. That needed no packaging change at all: the host .deb's glibc-2.39 floor and bundled FFmpeg already made it installable, and it had been working for a long time while docs-site said Debian was unsupported and unverified. Verified by installing: host, web console and plugin runner install, resolve every soname and run. The desktop client stays Ubuntu-26.04-only (built there, floors at `libc6 >= 2.43`; Debian 13 has 2.41). Compositor detection now answers Cinnamon (Mint, LMDE) with the route that works instead of advice that cannot help. Muffin forked from Mutter 3.36: `org.cinnamon.Muffin.ScreenCast` has only RecordMonitor/RecordWindow, never RecordVirtual, and xdg-desktop-portal-xapp implements no ScreenCast — so no value of PUNKTFUNK_COMPOSITOR makes a Cinnamon desktop host a virtual display. The error names headless gamescope, which needs no desktop compositor. The XDG sniff moved into a pure function so those branches are testable; Cinnamon is matched before GNOME, since it is a GNOME derivative and the generic arm would otherwise hand it the Mutter backend (caught by the new test). New `smoke-install` job installs every published package from the registry in pristine ubuntu:24.04, ubuntu:26.04 and debian:trixie images, asserts each binary resolves its libraries and runs, and insists the version served is the one this run built. Nothing in deb.yml had ever installed a package it produced, which is how both of the above survived unnoticed. ⚠ Bootstrap: seed `punktfunk-gamescope-trixie:latest` into the LAN registry once (docker.yml builds it thereafter) or the new job cannot start.	2026-08-13 11:43:54 +02:00
enricobuehler	ba16237c35	fix(bazzite): the shipped template pinned ATTACH, so Game Mode mirrored the box's screen instead of giving the client its own display ... Field report: "on Bazzite when using gaming mode it is mirroring the main display instead of giving the client its own." It is our own template that does it. `packaging/bazzite/host.env` set `PUNKTFUNK_GAMESCOPE_ATTACH=1`, and every install path — rpm, deb, Arch, nix — ships that file as `/usr/share/punktfunk/host.env.bazzite` with the docs telling people to copy it verbatim. So the recommended Bazzite setup turned the attach override ON for everyone. That override is rung 2 of `pick_gamescope_mode`, ABOVE `dedicated_launch` at rung 3. The rung comment calls the operator overrides a debug/CI escape hatch, which is right — but we were shipping one as a distro default, so on a Bazzite box the managed takeover and the dedicated game session were both unreachable. A game launched from a client's library could not get a session of its own either, which is the case the dedicated route exists for. With a physical display connected, attach then takes the `physical_display_connected()` arm and streams the box's own head at the box's own mode: the mirror the reporter saw. The template now forces nothing and lets the per-connect detection answer, which on a box with `gamescope-session-plus` is MANAGED. Attach stays available, documented as the opt-in it is, with the mirror and the dedicated-session cost stated. Because managed depends on the `punktfunk` group to stop the display manager, the template now says so where someone choosing a model will read it, rather than only in the distro guide. Also fixes the off-switch. Both overrides were read with `var_os(..).is_some()`, so `PUNKTFUNK_GAMESCOPE_ATTACH=0` meant ATTACH ON — the opposite of what the line says, and of every other knob on this host. They now use the shared `env_on` grammar, so `0|false|off|no` disable and a bare `=1` keeps working. Anyone who "turned attach off" in an older host.env had it on the whole time. Note an upgrade never rewrites an existing `~/.config/punktfunk/host.env`, so boxes set up from an older template keep the pin until the line is deleted by hand; the Bazzite and HDR pages now say that. Verified: `scripts/xcheck.sh linux` check + clippy `-D warnings` clean, pf-vdisplay 206/0 under rust:1.96, `cargo fmt --all --check` clean. Gate proved non-vacuous against a planted `compile_error!` in routing.rs.	2026-08-13 09:45:52 +02:00
enricobuehler	6774c4e7a2	feat(wol): support WoWLAN so Wi-Fi hosts wake like wired ones ... The host's arming check asked `ethtool` about every NIC, which is the wrong question for Wi-Fi: the magic-packet trigger lives in nl80211's WoWLAN state, and most wireless drivers print `Wake-on: d` whether or not it is armed. An armed Wi-Fi host was therefore told it was NOT armed, and handed an `ethtool -s wlan0 wol g` its driver rejects. A NIC with an nl80211 phy (`/sys/class/net/<i>/phy80211`) is now asked `iw phy <phy> wowlan show` instead, and the warning carries WoWLAN-correct guidance — `iw ... wowlan enable magic-packet`, plus the NetworkManager `802-11-wireless.wake-on-wlan magic` that survives a reconnect. Two fallbacks for when `iw` can't answer (missing binary, driver without the command, or privilege the user-level host service lacks): a POSITIVE ethtool reading counts (brcmfmac & co do report there), a negative one never does, and sysfs `device/power/wakeup` reading `disabled` is conclusive in the negative. The client sender now emits from a socket bound to EACH non-loopback interface's own address rather than leaving the path to the routing table. A station in WoWLAN sleep stays associated and its AP buffers broadcast frames for it until the next DTIM beacon — but only if the datagram reaches the wireless segment at all, and with a VPN or mesh interface holding the default route `255.255.255.255` never did. A failed bind falls back to the routed socket, so no segment is lost. Tests: `iw`/`ethtool` output parsing split from the commands so both are unit- tested on any platform, and a new end-to-end test asserts a real listener receives the 102 magic-packet bytes. Verified on Linux (Ubuntu 26.04, 12 interfaces): `cargo fmt --all --check`, `cargo clippy -p punktfunk-core -p punktfunk-host --all-targets --locked -- -D warnings`, and both wol test sets green. NOT yet exercised against real Wi-Fi hardware — no Wi-Fi Linux box was reachable.	2026-08-13 00:49:21 +02:00
enricobuehler	dcde856178	feat(pad-audio): Linux hosts stream pad audio — the per-pad PipeWire sink (WP3) ... The 0xD1 plane was Windows-host-only: host_cap() answered false and spawn() was a stub everywhere else, so an Android tier-A client against a Linux host negotiated the cap off and stayed on wire rumble. The whole downstream machinery (framer, silence gate, lanes, 0xD1 send) was already capture- agnostic — only the capturer was WASAPI. - audio/linux/pad_sink.rs: one Audio/Sink stream node per DualSense-family pad, minted with the identity the matchers read (ALSA-style node.name with the pad's pairing MAC, description "Wireless Controller", bus/vendor/ product/form-factor proplist, per-pad serial), 4-ch F32 48 kHz FL FR RL RR, no default-sink claim, priority.session 50. The process() callback IS the capture. PUNKTFUNK_PAD_SINK_NAME/_DESC override the strings for field debugging ({pad}/{mac} expand). - native/pad_audio.rs: the shared logic and lanes compile on Linux; pad_audio_thread is generic over the capturer (open-with-backoff kept); host_cap() Linux arm = client asked + PUNKTFUNK_PAD_AUDIO + a reachable PipeWire socket; spawn() Linux arm mints the sink lazily in the streamer thread. spawn() gains an edge flag (Edge identity; ignored on Windows). - devtest pad-sink-test: mint one sink and capture from it, no client — the WP3 on-glass gate. Verified on a Bazzite 44 host: identity served through pipewire-pulse, rear-pair (voice-coil) tone captured bit-exact over both the native and pulse legs. - docs: PUNKTFUNK_PAD_AUDIO{,_SLOTS} are no longer (Windows); the roadmap non-goal narrows to Bluetooth client pads. Gates (fedora:44 container, natively on the .41 box): cargo build --release --locked (nvenc+vulkan-encode), clippy --all-targets -D warnings, cargo test pad_audio+pad_sink 11/11, cargo fmt.	2026-08-12 18:53:35 +02:00
enricobuehler	23d0452157	feat(host): GameStream opt-in on every route; the native plane is deny(unsafe_code)-enforced ... The user direction after WP0: ENet exists only for Moonlight, so the native plane must be provably safe and the compat planes a deliberate choice. Opt-in, everywhere. Windows already was (unchecked installer task). The three opt-out surfaces are flipped: the shipped systemd user unit (deb/RPM/Arch/ sysext) no longer bakes --gamestream into ExecStart — a new PUNKTFUNK_GAMESTREAM=1 host.env knob (pf-host-config, OR-ed with the CLI flag) is the packaged opt-in; the NixOS module default goes true→false, with a module-check assertion that unset = native-only; the Deck installer takes --gamestream to opt in (--no-gamestream kept as explicit-off). Docs (quickstart, running-as-a-service, moonlight, ubuntu/fedora/arch firewall sections, gnome/sway, how-it-works) rewritten to the opt-in shape; the CHANGELOG carries the upgrade note. Enforced-safe. punktfunk-core is #![deny(unsafe_code)] crate-wide — every module that parses network bytes is safe Rust as a compile error, not a census result. Carve-outs are exactly two documented classes, neither of which interprets attacker bytes: the client surface (abi, client) and the transport syscall-batching shims (udp/{apple,linux,windows}, qos_windows). In punktfunk-host, the modules a secure-default host exposes — native (cfg-not-test: its tests exercise the client C ABI on purpose), native_pairing, mgmt, mgmt_token, discovery, wol — are #[forbid(unsafe_code)]. Gates: Linux amd64 container clippy --all-targets -D warnings clean over core+host-config+host; core 204 tests green under the deny; mgmt 46/46, control 6/6. .133 Windows clippy (shipped features, clean-first, sentinel-checked) clean — covers the qos_windows/udp-windows carve-outs. macOS + iOS cargo check green (the apple.rs carve-out compiles for real).	2026-08-11 20:21:16 +02:00
enricobuehler	d715225960	Merge pull request 'Launcher tiles get their launcher's logo — a brand token on the wire, the vector in every client' (#162) from worktree-launcher-icons into main ... Reviewed-on: #162	2026-08-11 04:58:36 +00:00
enricobuehler	f62a48d4a9	feat(library): launcher tiles get their launcher's logo — a brand token on the wire, the vector in every client ... A launcher tile (role: "launcher", design D4) shipped no art on purpose: a launcher's own icon is square, every client cover-crops a 2:3 poster, and the crop turns a mark into a strip. So the tiles were the launcher's name on a flat accent face — legible, and the blandest thing in the grid. Entries now carry an optional `icon`: the NAME of a brand mark, never image bytes and never a URL. `[a-z][a-z0-9-]{0,31}`, shape-validated by the host on every lane (a client interpolates the value into a resource name or an asset lookup, so the guard belongs upstream of all of them, and each client re-checks rather than trusting the peer). A token rather than art because the alternative is closed by construction, and deliberately: the art proxy serves what the bytes ARE (sniff_image_type) and SVG is not on that list — it is script-capable XML and the console renders library art in a browser. Widening that sniff would trade a rendering nicety for a stored-XSS surface. Naming the mark keeps the refusal intact, keeps the glyph vector at whatever size a tile happens to be, lets it take the tile's ink, and adds nothing to a reconcile payload that is already body-limited. The cost is that a third-party plugin cannot ship a mark no client bundles; its tile falls back to the launcher's name, exactly as before, and the fix is a PR adding the master. assets/launcher-icons/ holds seven monochrome masters with per-mark provenance and licensing (Simple Icons CC0: lutris, heroic, epic, gog; Font Awesome CC BY: steam, xbox; Playnite's own logo, MIT). steam is generated FROM assets/os-icons/steam.svg so the SteamOS host badge and the Steam launcher tile can never drift. scripts/gen-launcher-icons.sh bakes the three derivatives that cannot consume a master (GTK symbolic SVG, Windows PNG, Apple template PDF) and — unlike gen-os-icons.sh, which prints path data for a human to paste — GENERATES the three inline registries (web console, Android ImageVector, pf-console-ui Skia). Three clients x seven paths of up to 3 kB is a transcription error waiting to happen, and a mangled character is a silently wrong logo rather than a build failure. The generated Rust goes through rustfmt, since `cargo fmt --all --check` is a CI gate and a generated file that fails it would fail every regeneration. All six renderers draw the mark CONTAINED, never cover-cropped: the masters' viewports are not square (steam 496x512, playnite 1024x1024) and filling a 2:3 frame would reproduce the strip this exists to avoid. Every one keeps its old fallback for a token it has no art for. Epic, GOG and Xbox marks ship dormant. Those plugins' launcher switches are off by default and emit nothing, because the host has no verified launcher_ui activation for them yet — shipping the art now keeps turning one on the one-line plugin change those plugins promise, instead of also needing a release of all six clients. api/openapi.json and the SDK are regenerated (the spec's version field was stale at 0.25.0 and now reads 0.26.0, which is the crate's actual version — an unrelated line that regeneration necessarily corrects). Verified: host cargo check, clippy -D warnings across pf-client-core / pf-console-ui / punktfunk-client-session / punktfunk-client-linux, plain build, pf-console-ui tests (77, including a new one asserting all seven masters parse under Skia and one asserting the letterbox stays inside its box), pf-client-core tests (188), cargo fmt --all --check, Apple swift build, Android compileDebugKotlin, web tsc + vite build, plugin-kit tsc, biome. The Windows client is NOT compile-verified — it cannot be built from a Mac (scripts/xcheck.sh covers only the capture stack by design) and CI does not build it either; its tile change needs a real box before it ships.	2026-08-10 23:26:47 +02:00
enricobuehler	147bc82130	chore(release): bump workspace version to 0.27.0 ... 87 commits since v0.26.0. The number is forced rather than chosen: the C ABI moves 17 -> 18, and `scripts/ci/pf-version.sh` already reports PF_BASE=0.27.0. Fills in what `docs/releases/v0.27.0.md` and the `## v0.27.0 — in development` CHANGELOG section deferred to the bump -- the lead-in, the TL;DR, "Before you update", the version table and the commit count -- and merges in the work that landed without notes: the Windows Xbox HID pad, the Apple console-UI batch, and the v0.26.0 field repairs. Everything already accumulated on main is kept as written. Version table, all re-derived at HEAD rather than read off the diff: * wire 2 (unchanged), C ABI 17 -> 18 (ADDED symbol, not widened) * crate dirs 26 -> 27 (`punktfunk-encode-worker`), 39 members * gamescope `+pfhdr4` -> `+pfhdr5` (6 patches -> 7, the PipeWire UAF), pkgrel resets to 1 * driver proto 6, gamepad channel 3, plugin index 1, SDK 0.1.4, plugin-kit 0.4.0 -- all unchanged * `api/openapi.json` stays 0.25.0: it moves only on an API EDIT, and the last one (`6cffe29b`) predates the v0.26.0 tag. It is not a mechanical per-release bump. ⚠ `crates/pf-driver-proto` is NO LONGER byte-identical to the previous release -- it was through both v0.25.0 and v0.26.0, and the last two CHANGELOGs told packagers so. Three additive `device_type`s. Called out explicitly so a packager who has been skipping it stops. The Play whatsnew names the one real Android change (the OLED palette is Eclipse now; display name only, the stored `oled` id is unchanged so saved choices carry over) and is otherwise explicit that the release is host-side. `docs-site/.../running-as-a-service.md` claimed "0.26.0-2 revoked it everywhere". No such version exists -- the Arch registry goes 0.26.0-1 straight to 0.27.0 canaries -- and the corrected 0.26.0 packages shipped under the SAME version string, which is exactly why a machine that installed an early one was never offered the fix. Reworded to say that, since it is the reason this release matters to those users. Gates, all green on this commit: * `cargo fmt --all --check` clean * `cargo metadata --locked` resolves * `Cargo.lock` diff versions-only -- 72/72 changed lines, 36 crates * Play gate's own python3 arithmetic: 400/500 CHARACTERS, not byte-identical to any other release (`wc -c` misleads -- `•` is 3 bytes) * notes voice check: 1 hit, reviewed and kept -- `getcap /usr/bin/punktfunk-host` is a command the reader runs, the same class as the `usermod` line v0.26.0's notes carried * `docs-site` builds NOT DONE: no tag yet.	2026-08-10 20:51:45 +02:00
enricobuehler	1befa8a2c4	docs(nix): bring the Nix docs in line with the module, and fix a stale claim they shared ... There are three places Nix is documented — the public docs-site, packaging/nix/ README.md, and packaging/README.md — plus the changelog. All had drifted. STALE CLAIM, and not only for Nix. install.md said the plugin runner's "user unit ships **disabled** — enable it once you have" something to run. That is true only of Arch and source installs: the deb postinst and RPM %post both `systemctl --global enable punktfunk-scripting.service`, and the Bazzite sysext bakes in a default.target.wants symlink (build-sysext.sh:113). bazzite.md carried the same claim about its own image. Both corrected, per channel, with the reason the default flipped — the library scanners are plugins, so a host without the runner can come up with an empty library — and the `mask`-not-`disable` opt-out the sysext's own comment documents. docs-site: * install.md NixOS — `desktopSession` in the example and explained, the runner no longer needs enabling, and the host/console line says what autoStart does. * running-as-a-service.md — "Restart the host with your desktop" documented the drop-in for packaged installs only; NixOS gets its one-liner beside it. * bazzite.md — the runner is started for you, not "isn't started". packaging/nix/README.md: * option tables gain `desktopSession`, `gamescopeHdr`, `gamescopePackage`, and the `punktfunk` group next to `input` (both are required — the udev rule chgrp's the vhci nodes and fails outright if the group was never created). * "what the module configures" gains the security.wrappers entry, and a note on why the capability sits on the encode worker and never on the host: a wrapper raises it into the ambient set, which lands it in the permitted set and fails KWin's /proc/<pid>/exe readlink identically to a file capability. * the appliance snippet no longer tells you to put pkgs.gamescope on PATH — gamescopeHdr does that with the patched build, and desktopSession is called out as the thing to leave off there. * a caveat recording that `nix flake check` does not check the module, and the two rules for editing module-check.nix (assertions stay pure Nix; assert list-valued unit fields on the lists, not the rendered text). packaging/README.md: the flake ships five packages, not "host + client". CHANGELOG.md v0.27.0: a NixOS section covering the comm/session-detection fix, the module changes including the scripting default flip as an explicit behaviour change, and the flake-check gap — plus the documentation bullets above.	2026-08-10 20:24:21 +02:00
enricobuehler	1fc184516a	feat(apple): the browse route is real — a Shortcut or a widget jumps straight into a host's library ... The reserved punktfunk://browse/<host-ref> route now routes on Apple: it drives the same libraryTarget every internal surface writes, so the link lands in whichever presentation the current mode owns — the gamepad console's in-place library screen, the touch cover, the macOS sheet, or tvOS's cover. Connect's posture minus the connect: a pin conflict refuses, a live session is never preempted, an unsaved host gets a notice (the library rides the paired mTLS identity, so there is nothing to browse before the host is saved). browse ignores launch=/profile= — nothing streams until a title is picked, and that connect resolves its own profile. On top of the route, the two new front doors: - OpenLibraryIntent ("Open Game Library") beside Connect/Wake/End in Shortcuts/Siri/Spotlight, host-parameterized like the others and round-tripping through the URL — one router, no second path. - A configurable library widget (kind "PunktfunkLibrary", AppIntentConfiguration over HostEntity — the configuration the HostEntity doc comment anticipated): pick a host, tap into its library. Unconfigured it follows the most recent host; a configured host that was removed shows the empty state rather than silently following a different host. Same .never timeline + HostStore push as the hosts widget, now reloading both kinds. DeepLink.browse(host:) is the one emitter both doors share, covered by a round-trip test beside connect's; the parse side was already in the grammar and the vector file. Docs updated (clients, game-library, profiles-and-links).	2026-08-10 14:11:01 +02:00
enricobuehler	35b5ee6a36	Merge pull request 'punktfunk-encode-worker: GPU priority via a capability-carrying worker, with WP3 on-glass complete' (#153) from worktree-worktree-encode-worker into main ... Reviewed-on: #153	2026-08-10 10:45:23 +00:00
enricobuehler	fb309e0262	fix(pf-vdisplay): the takeover blamed polkit for a group it never named, and offered two remedies that cannot work ... Field triage on Nobara, 2026-08-09. Every connect degraded to ATTACH — which on that box mirrors a game-mode session the host never configured, and looked like a black screen on every connect. The host said: the packaged pf-dm-helper polkit action is missing or was denied (reinstall the punktfunk package, or install the display-manager polkit rule from the docs) Every clause of that was wrong. The action was installed, `allow_any`, and its exec.path annotation matched the installed helper; pkexec authorized it and RAN the helper. The helper refused, and said exactly why: pf-dm-helper: user 'nobara-user' is not in the 'punktfunk' group — refusing. Grant it with: sudo usermod -aG punktfunk nobara-user (then re-login) That text never reached the log, because `dm_helper` ran the helper with `.status()` — which discards stderr and collapses the exit code to a bool. The one thing that would have ended the investigation in seconds was thrown away at the call site, and the caller then guessed. Neither suggested remedy adds anyone to a group, so a reader who followed both stayed broken and learned the docs were useless. It fails soft, with no error and no failed unit, so nobody finds it on purpose. Now: `.output()`, and four failure modes that stay distinguishable because they need different fixes — helper not installed, pkexec could not run it, polkit denied it (pkexec's own 126/127), and the helper ran and refused, whose stderr rides through VERBATIM rather than being re-described. Null stdin too, so a pkexec that decides to prompt gets EOF instead of parking a stream thread on a tty read. The same gate gates the `linger` verb, so on a sessionless host an unjoined user fails there first — carrying the reason there as well, or the misdiagnosis just moves one message earlier. A new startup preflight says it before a stream is being built rather than during one, gated so it cannot nag a box that would never attempt a takeover: not root, a display-manager alias exists, a managed session launcher exists, a packaged helper exists, and the user is not in the group. It reads membership from the user database rather than this process's groups, deliberately: that is what the helper reads (it runs as root and resolves the caller from the database), so `usermod -aG` satisfies the DM gate immediately and the warning stops. Using `getgroups()` would keep warning on a box where the takeover already works. Packaging said the group was for "the virtual Steam Deck pad (usbip)" — so anyone without a Deck pad correctly skipped it and landed here by following instructions properly. All three scriptlets now lead with Game Mode, name both grants, and record that creating the group is necessary and NOT sufficient. Docs get the same treatment: the group is an admonition above the DM-flavor list in gamescope.md, a black-screen entry in troubleshooting.md that tells the reader to read the quoted reason FIRST, and the per-distro install pages no longer frame it as pad-only.	2026-08-09 23:15:34 +02:00
enricobuehler	f26d21125d	docs: the capability moves to the encode worker, and the host must never be given one ... Rewrites the "GPU scheduling priority" section around the split: punktfunk-encode-worker carries cap_sys_nice=ep, punktfunk-host carries nothing on any channel, ever. The KWin identification mechanism is spelled out in plain words and the failure line is quoted verbatim ("KWin does not expose zkde_screencast_unstable_v1 to this client") so someone searching for their symptom lands on the explanation. The warning names all three ways an operator would reach for the capability — hand setcap, a systemd AmbientCapabilities= line, a NixOS security.wrappers entry — because all three put it in the same permitted set and all three cost KDE desktop streaming. That is the failure mode that made this worth documenting: it looks exactly like a missing .desktop and survives reinstalling both ends. configuration.md gains PUNKTFUNK_ENCODE_WORKER (path, or `off` to force the in-process encoder) and re-describes PYROWAVE_QUEUE_PRIORITY as an intent forwarded to whichever process does the encode. kde.md gains one line on the troubleshooting bullet someone actually lands on: getcap on the host must print nothing. The published 0.26.0 notes are deliberately untouched — they are the record of what shipped. The flipped phrasing lives in v0.27.0's notes instead; v0.26.0.md:37 ("a system privilege that turns out to stop KDE recognising the host at all") is the line that goes stale when this ships.	2026-08-09 12:51:01 +02:00
enricobuehler	4d383811c0	fix(packaging): the same CAP_SYS_NICE broke KDE on FIVE channels, not one — Bazzite included ... The Arch fix in the previous commit was incomplete. 0.26.0-1 granted the host CAP_SYS_NICE through every Linux channel we ship, and each one breaks KWin identification the same way: * packaging/rpm/punktfunk.spec .......... %caps(cap_sys_nice=ep) in %files <- Fedora AND Bazzite via rpm-ostree layering * packaging/bazzite/build-sysext.sh ..... setcap on the staging tree, recorded by mksquashfs * packaging/debian/build-deb.sh ......... setcap in the postinst * packaging/nix/nixos-module.nix ........ security.wrappers with capabilities = "cap_sys_nice=ep" * scripts/steamdeck/install.sh .......... setcap on $BIN, six lines after writing the .desktop whose Exec= it thereby voids Bazzite was NOT a separate fault, as first reported here — it is this one. Verified by mounting the published punktfunk-0.26.0-1-x86-64.raw: `getcap usr/bin/punktfunk-host` reports cap_sys_nice=ep, stored as security.capability in the squashfs. The claim in packaging/arch/build-sysext.sh that "file capabilities don't survive this squashfs path" is false and is corrected here; mksquashfs records them, which is exactly why the image shipped one. NixOS deserves its own note: a security.wrappers entry does not dodge the problem. The wrapper raises the capability into its AMBIENT set before exec'ing the store binary, precisely so it survives — which lands CAP_SYS_NICE in the exec'd process's permitted set and fails the readlink identically to a file capability. ExecStart now points at the store path directly, which is also the path packages.nix substitutes into the .desktop's Exec=, so the two finally agree. Measured blast radius of holding a capability, same-uid reader, CachyOS kernel 7.1.6: /proc/PID/exe ....... EPERM <- KWin's identification. Desktop sessions die. /proc/PID/root/* .... EPERM <- xdg-desktop-portal reads .flatpak-info here to resolve an app id; the wlroots and Hyprland backends go through it /proc/PID/environ ... EPERM /proc/PID/cgroup .... OK /proc/PID/status .... OK /proc/PID/cmdline ... OK Compositor backends, by exposure: KWin is broken outright (proven, field-confirmed). gamescope has no identity gate and was never affected, which matches the field — only Desktop mode was reported. Mutter drives Mutter's own D-Bus API, not the portal, and looks unaffected. wlroots and Hyprland go through the ScreenCast portal, whose app-id resolution reads a path the capability blocks — a real exposure, not something I reproduced end to end. The sysext build now HARD-FAILS if a capability is staged, rather than trusting that the RPM payload never carries one: a merged sysext's /usr is read-only squashfs, so a bad image cannot be repaired on the box, and the spec was one %caps() away from baking one in again. Docs corrected, because they advertised the capability as a feature: * docs-site running-as-a-service "GPU scheduling priority" — rewritten: the host carries no capability, why it must not, and how to clear a 0.26.0-1 install (Bazzite needs a new image) * docs-site configuration.md — the PYROWAVE_QUEUE_PRIORITY row no longer claims the packages grant it * packaging/bazzite/README.md — §6.5 still described the kde-desktop-setup.sh behaviour from before it stopped writing KWIN_WAYLAND_NO_PERMISSION_CHECKS and started REMOVING it; plus a note that 0.26.0-1 Desktop mode cannot be repaired in place * packaging/arch/README.md — the false "capabilities don't survive the sysext" line * CHANGELOG v0.26.0 PW1 — annotated with the 0.26.0-2 correction rather than rewritten, and the owed PyroWave-under-load A/B now says it needs a gamescope-only box Verified: bash -n on all five changed shell files; nix-instantiate --parse on nixos-module.nix and packages.nix; the published 0.26.0-1 sysext mounted and its capability read; getcap on an uncapped file exits 0 with empty output, so the new build assertion cannot false-positive.	2026-08-09 09:56:36 +02:00
enricobuehler	d3aaa16a7d	Merge branch 'worktree-wave2-pw3-dmabuf-latch' into worktree-wave2-pyrowave ... # Conflicts: # packaging/arch/punktfunk-host.install # scripts/steamdeck/install.sh	2026-08-09 01:13:23 +02: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	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	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	767e67caf4	feat(packaging): grant the host CAP_SYS_NICE, without which the GPU-priority lever does nothing ... Wave-2 PW1, second half. The companion commit wires `PYROWAVE_QUEUE_PRIORITY` into the Linux PyroWave device; this is what makes it work on a packaged host. Measured on .21 (RTX 5070 Ti, NVIDIA 610.43.02), same binary in both arms: as packaged (no capability) every class refused, REALTIME *and* HIGH -> default priority same binary, cap_sys_nice+ep granted REALTIME on the FIRST attempt, no downgrade RADV behaves the same way. So this is not the RADV-specific "expect one downgrade to HIGH" the plan predicted — without the capability there is no elevated priority at all, on any vendor, and the knob is decoration. Worth being precise about what is being granted, because it is a network-facing daemon. CAP_SYS_NICE permits raising scheduling priority (nice, ioprio, affinity, RT class) and nothing else: no filesystem access, no network privilege, no user switching, and it is NOT setuid. The repo already ships exactly this capability on its gamescope binary for the same reason. Two side effects that will otherwise confuse someone debugging: a capability-carrying binary is AT_SECURE, so the loader ignores LD_LIBRARY_PATH/LD_PRELOAD for it (note this box was propped up by exactly such a shim during the ffmpeg-9 soname break — that workaround would now be silently ignored), and core dumps are suppressed by default. Per packaging path, because none of them are the same: - Arch: a `_grant_sched_capability` in the scriptlet, called from post_install AND post_upgrade — a replaced binary is a new inode, so the capability does not survive an upgrade by itself. - Debian: the same setcap in the postinst `configure` branch. - RPM: `%caps(cap_sys_nice=ep)` on the binary in `%files`, which is the rpm-native form — rpm then applies it on install, restores it on upgrade, and verifies it. A `%post setcap` does none of those. - NixOS: `security.wrappers`, because a store path is read-only and shared and cannot be setcap'd. The unit's ExecStart moves to `config.security.wrapperDir` — without that the wrapper exists and the service still runs the uncapped store path, which is the whole failure this fixes. - Steam Deck: setcap in the installer's sudo block. That box needs it most (one small Van Gogh GPU shared between the game and the encode). The binary lives under $HOME, so unlike the /etc drop-ins it survives a SteamOS A/B update on its own and needs no atomic-keep entry — but it does need re-applying after each rebuild, which re-running the installer does. - Bazzite sysext: at IMAGE BUILD time, before mksquashfs. It cannot be done in the merge hook (a merged sysext's /usr is read-only squashfs) and it cannot ride in from the RPM either — rpm keeps capabilities in its own header and `rpm2cpio | cpio` carries only the payload, so the staged file arrives with none. mksquashfs does record security.capability (only security.selinux is excluded), so a setcap on the staging tree is what lands in the image. Needs root/CAP_SETFCAP; a plain-user CI build warns and ships without it rather than failing a release over a performance lever. Every one of them is best-effort and cannot fail an install: a box without libcap, or a filesystem that cannot store capabilities, simply runs at default priority exactly as it does today. Documented in the same PR — the configuration row now says the packages grant it, and running-as-a-service gets a section explaining what it is, how to check it (`getcap`), and how to remove it (`setcap -r`, or just `PYROWAVE_QUEUE_PRIORITY=off`), including the two debugging side effects. Verified: the Arch scriptlet grants the capability from a fake package root exactly as pacman would invoke it, and the resulting binary reaches REALTIME end to end on the RTX 5070 Ti; the RPM spec's %caps line parses under rpmspec in a Fedora 41 container; the NixOS module parses under nix-instantiate; all five edited shell scripts pass `bash -n`. No Rust file changed in this commit, so the CI-parity Rust gates from the companion commit still stand.	2026-08-08 15:24:54 +02:00
enricobuehler	2bf571a5ad	feat(pf-encode): PyroWave's Linux encode device never asked for the priority its own patch requests ... Wave-2 PW1, first half = Wave-1 WP14 step 4, executed as specced. PyroWave encodes on the same GPU shader cores a game saturates, and that is measured to hurt: patch 0005's header records `encode_gpu_synchronous` going from ~2 ms to 15-18 ms at 95 % game load, with the stream frame rate collapsing. NVENC is immune because it has its own ASIC. The lever for a compute workload is an elevated global-priority QUEUE — a process-priority raise only reorders submission, not hardware preemption. The vendored patch requests exactly that. It is gated `if (!inherit_info)`, and only Windows leaves `inherit_info` null (`pyrowave_create_device_by_compat`, where Granite builds the device itself). Linux passes its own create-infos into `pyrowave_device_create_info`, Granite's `get_existing_create_info()` hands them back, `create_device` takes the inherit branch — and the whole block is skipped. On Linux the knob has never done anything at all. Meanwhile pf-zerocopy's VkBridge has shipped the identical ladder on Linux for some time and calls it "the actual NVIDIA compute-preemption lever"; the encoder that needs it most did not have it. This wires it natively in `open_inner`'s `DeviceHold`: - The extension probe reuses the `dev_ext_props` already fetched for queue_family_foreign, and takes KHR or the EXT alias — the same spelling pf-zerocopy probes, so the two cannot disagree. - `queue_priority_candidates` is a pure fn with the grammar copied from the C patch: unset → realtime, ASCII-lowercased, `off` alone disables, `high` asks for HIGH only, junk falls back to the ladder rather than to off. One env var must not mean two things on two platforms — that is the documentation trap this package exists to close — so the grammar is unit-tested against the patch's, including where they are both deliberately un-clever (neither trims). - The create ladder is REALTIME → HIGH → no-priority, stepping only on a refusal. A refused class can never fail the open, which matters more here than on Windows: this path is reached only by a NEGOTIATED PyroWave session, so a hard error is a dead stream, not a fallback to another encoder. The subtle part is the write-back. `pyrowave_create_device` RETAINS `device_create_info` for the device's lifetime and Granite reads the chain back. If the ladder ends on the no-priority attempt while `_queue_ci[0].p_next` still points at the global-priority struct, Granite is handed a chain the device was not created with. The `None` arm therefore nulls `p_next` before the final create, and the field's doc says why. The enabled extension deliberately STAYS in the list: it really is enabled on the device, it just carries no request. One deviation from the plan, stated because it is a deviation: the ladder also steps down on `ERROR_INITIALIZATION_FAILED`, not only `ERROR_NOT_PERMITTED_KHR`. The plan and the C patch handle only the latter; pf-zerocopy's shipped ladder accepts both. Given a hard error here kills a negotiated session, treating one extra driver-specific refusal as a downgrade is the cheap side of that asymmetry. Also corrects the two vendored notes, which claimed a Linux behaviour the gate made impossible, and records that patch 0005's negative RTX-4090 result is Windows/WDDM and does not transfer to a different driver stack. Patch hunks are byte-identical (header prose only) and `git diff crates/pyrowave-sys/vendor/` is PUNKTFUNK-VENDOR.txt alone. `PYROWAVE_QUEUE_PRIORITY` is now reachable on Linux, so it is documented in the same PR. MEASURED ON GLASS, and it changes what this package is worth on its own — .21, RTX 5070 Ti, NVIDIA 610.43.02, same binary in both arms: as packaged (no capability) every class refused, REALTIME *and* HIGH -> default priority same binary, cap_sys_nice+ep granted REALTIME on the FIRST attempt, no downgrade So the lever is INERT on an unprivileged host, and that is not the RADV-specific downgrade the plan predicted — on NVIDIA it is a downgrade to nothing at all. The ladder itself is proven good across all three legs (unset / high / off): a refused class never fails the open, and `off` enables no extension and logs nothing. It simply has nothing to grant yet. The privilege needed is CAP_SYS_NICE on the host binary, which is NOT what Wave-1 WP3 ships (RLIMIT_NICE, PAM limits, CPUWeight — all different things). That grant is a security-posture change on a network-facing daemon, so it is deliberately NOT in this commit; the warn line now names the capability so an operator is not left guessing, and the docs row says the setting has no effect on most hosts today rather than implying it works. The loaded-GPU encode_us p99 A/B is therefore not run: it needs a GPU-saturating game (hence a desktop session the box does not currently have) and it is pointless before the capability lands, since the unprivileged arm has no priority to measure. NO unit test is possible for the device-create ladder itself — it needs a real Vulkan device. Its coverage is the clippy pass, the grammar tests, and the on-glass log line. Stated here rather than left for a reviewer to wonder about.	2026-08-08 14:37:41 +02:00
enricobuehler	2aa763ce70	feat(pf-capture): a PyroWave session could drop to CPU capture and log nothing at all ... Wave-2 PW2 (design/linux-host-performance-wave2-pyrowave.md). Observability only — no behaviour change to any capture decision — and it lands first because every later package in the program is measured by an A/B whose "before" is currently unreadable. The defect: the capture path's CPU-fallback warning was gated on `backend_is_vaapi`, which reads the HOST-GLOBAL encoder pref. A PyroWave session is negotiated PER SESSION, so on an NVIDIA/auto host that gate is false — and the session then fell out of every arm of the negotiation log chain, emitting nothing whatsoever while paying a full-resolution CPU pixel touch on every frame. A degraded host and a healthy one produced identical logs. Four sites, matching PW2.1-2.4: 1. The CPU-path warning now asks the per-session question (`consumer_kind`) instead of the pref, and names the consumer. Its gate widened to every GPU consumer and excludes only the software encoder, whose native input IS CPU frames — an NVENC session silently on the CPU path is the same defect, not a different one. `pyrowave_session` deliberately outranks `backend_is_vaapi`, because a PyroWave pref flips `backend_is_vaapi` on too (`linux_zero_copy_is_vaapi_for`'s `Pyrowave` arm), so testing vaapi first would swallow every PyroWave session. 2. The raw-passthrough block in `consume_frame` had four silent exits — no format, an SHM/MemFd buffer, no DRM fourcc, a failed `F_DUPFD_CLOEXEC` — each falling out of three nested `if`s into the CPU de-pad path. It is now a labeled block that breaks with a named `PassthroughFallback`, logged once per distinct reason per session with a running count, so a persistent downgrade is distinguishable from a hiccup at renegotiation. `.process` runs per frame, so the rate limit is the shippable part and is what the tests pin. Note `NoFormat` does NOT fall back — the CPU path needs `ud.format` too and returns — so the line says DROPPED for that one. Three of four downgrade; one loses the frame. 3. `force_cpu_for_nvenc_444` told a 4:4:4 PyroWave session it was "on the NVENC path", which is false in every particular: the wavelet encoder never touches NVENC, never swscales to YUV444P, and what it actually loses is the raw-dmabuf passthrough its design assumes. 4. One INFO line at pipeline build states the resolved arm and consumer (`capture pipeline resolved: dmabuf-passthrough → pyrowave`). Nothing stated it before; the 2026-08-08 triage reconstructed it from four files, and for the arm that matters most there was no detail line to reconstruct it from. Also: `spike --codec pyrowave`, so a PyroWave capture→encode pass can be driven without a client. That is the harness the rest of this program measures on, and it did not exist. Gates on .21 at CI parity: fmt, workspace clippy -D warnings, pf-encode clippy with nvenc,vulkan-encode,pyrowave and without, workspace tests.	2026-08-08 13:36:51 +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	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	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	bfed711921	Merge remote-tracking branch 'origin/main' into audio/latency-overhaul	2026-08-08 00:16:02 +02:00
enricobuehler	70e6b80200	fix(client/android): place audio with the picture on Android too ... The core, Linux, Windows and host halves of the audio latency overhaul landed with Android deliberately left inert: `JitterPolicy`'s sync target defaults to `None`, so this ring kept behaving exactly as it always had. What was missing was not the loop but its REFERENCE — nothing here published where a frame actually reached glass, and a controller with no reference is the mechanism you can prove is present but that cannot act. This wires both halves. The decode thread now reads the host capture `pts_ns` that every `AudioPacket` has always carried and that this client, like every other, dropped on the floor. Against the ring depth (published by the AAudio callback through the shared `AudioSyncCell`) and the video plane's end-to-end figure it computes audio_e2e = (now + buffered_ahead + clock_offset) − pts_ns av_offset = audio_e2e − video_e2e (> 0 ⇒ audio behind the picture) and asks the ring for a depth that closes it. Only ASKS: `set_sync_target` is clamped between the underrun-driven adaptive floor and the hard cap, so a link whose jitter genuinely needs more buffer than the picture is away keeps its buffer and the residual is reported instead of being taken out of the listener's stream. Continuity outranks sync, on this ring as on the others. The reference comes from `DisplayTracker`'s `OnFrameRendered` callback — the one place in the client that knows a frame truly latched — and it is computed ABOVE the HUD gate now. A sync loop that only ran while the overlay was up would be off on exactly the devices that report latency; the stats LOCK stays gated, which is what that early-return was really protecting. Both decode loops feed it, so sync works with "Low-latency mode" off as well. Two deliberate refusals: * The figure is published RAW. The HUD shaves the OS present floor off its shown display/end-to-end numbers — metrics report what Punktfunk controls — but sound has to reach the ear when the light reaches the eye, and a floor-shaved reference would place audio a whole latch period early on every device. * Below API 33 there is no render callback, so there is no confirmed present and the loop stays inert (target `None` ⇒ today's behaviour exactly). The release instant is NOT substituted for it: a release targets a FUTURE vsync and runs a whole latch period (8-21 ms measured) ahead of glass, well outside the loop's deadband — it would place audio early on every frame while looking like it was working. The plane is also no longer invisible. Ring depth and the smoothed offset ride the stats array at 33/34 and the Detailed HUD carries `audio buffer N ms · a/v ±N ms`, the same wording the desktop HUD uses — both numbers, because a deep ring on a jittery link is correct behaviour and only the offset separates that from audio simply held late. The 1 Hz logcat line gains `av_ms` beside its depth, and the depth itself now has ONE publisher: the counter copy is gone in favour of the sync cell both readers already share. The escape hatch is two levers. `PUNKTFUNK_NO_AV_SYNC=1` keeps the contract the desktop clients document, but an app launched from the launcher inherits no environment, so the one a field tester can actually reach is `adb shell setprop debug.punktfunk.no_av_sync 1` — no rebuild, exactly like `debug.punktfunk.presenter`. A loop that steers playback has to be bisectable on the device that reports the regression. Verified: `cargo ndk -t arm64-v8a check` clean; `cargo clippy -p punktfunk-client-android --all-targets -- -D warnings` clean on the host lane CI lints, and the Android target introduces no new findings (5 pre-existing lints in audio/mic/pad_audio/vsync are unchanged — the android-gated modules are never linted by the host workspace); `cargo fmt --all --check` clean; `./gradlew :app:testDebugUnitTest` green. The new HUD test was proven non-vacuous by planting the defect first — dropping the render call fails its three positive assertions and leaves the three absence assertions passing, which is the shape a test that "passes for the wrong reason" would not have. design/audio-latency-overhaul.md W4. Apple (W6) still keeps today's behaviour.	2026-08-07 23:51:15 +02:00
enricobuehler	979ed8f426	docs(clients/pads): say that an X-Box virtual pad has nowhere to put motion ... G17's motion half. The docs described what the CLIENT sends and stopped there, which made a promise the host does not always keep. The support matrix said a desktop client forwards motion from any pad SDL exposes a gyro on "and the host injects it into the matching virtual pad". The first clause is true; the second is only true when the virtual pad has a motion plane. The X-Box 360 and One backends do not — no gyro in their HID contract — so the host parses every sample and discards it. That is where *Automatic* lands anything it does not recognise as Sony or Valve, an 8BitDo with a perfectly good gyro included, and where a Switch Pro lands on a Windows host with no `hid-nintendo` backend to fold it into. A reader following the old text would conclude their gyro was broken. The failure has no other symptom: motion just does nothing. So both pages now say what to do about it — pick a DualSense-class type — and the client-settings page says it where the choice is actually made, next to the degrade paragraph that explains why a session ends up on an X-Box pad in the first place. The Deck's Steam-Input requirement moves out of Decky's settings blurb, which is the one place a Deck user streaming FROM the Deck would never look. With Steam Input on, Steam hands the app its own virtual X-Box pad, so no controller-type choice can help: there is no gyro on the pad the client can see. The picker help text now mentions motion on GTK and Android, which is where it was missing — Windows already said it and Apple says it in its own words. One sentence, the same sentence, so the four clients answer the question the same way. This is the doc side of the on-screen notice that shipped earlier in this branch. The two exist for the same reason and now agree: the client says it when it detects the case, the docs say it when someone goes looking. Not covered: the preset COUNTS in note 1 ("Android and the console home offer six … Windows and Apple offer five") are still unverified against the four pickers, and the Apple picker's missing Steam Deck entry is a code gap rather than a doc one. Both are noted in the plan and left for their own change rather than guessed at here. Gate: Linux CI image fmt + `clippy --locked --all-targets -D warnings` on punktfunk-client-linux (the GTK string is compiled) plus the core crates and their tests; Android `:app:compileDebugKotlin` + `:app:testDebugUnitTest`. Green.	2026-08-07 20:11:28 +02:00
enricobuehler	8551e88fcb	merge: bring current main into the audio-substrate branch ... Two conflicts, both unions of independent removals/fixes: main fixed the same three install.rs SAFETY comments this branch fixed (main's phrasing kept), and the runner provisioning drops BOTH env lines — main removed PF_FFVK_VULKAN_INCLUDE (pf-ffvk is gone since the FFmpeg replacement), this branch removed VBCABLE_DIR (the retirement).	2026-08-07 17:49:50 +02:00
enricobuehler	4a621de6b1	chore(packaging): retire VB-Cable — audio's substrate is Steam's drivers ... The other half of the audio-substrate decision (spikes S2+S3 green, minted endpoints landed in the previous commit): stop bundling a third-party kernel driver the host no longer needs. installer the VB-CABLE task, payload, silent-install run and the donationware notice are gone; a suppressible notice tells a Steam-less box that audio needs Steam INSTALLED (never running) and that installing it later just works. A cable from an older install is still deliberately not removed. packer + CI -VbCableDir/VBCABLE_DIR, the staged-payload check and the runner provisioning download are gone; SBOM drops the redistributed-driver component. winget the VB-Audio bundling-grant agreement becomes the honest Steam requirement (surfaced on the unattended path where no wizard is on screen). docs windows-host/uninstall/security/echo say what actually ships: no kernel-mode driver of our own, endpoints minted from Valve's vendor-signed drivers, VB-CABLE mentioned only as the historical fallback that keeps working. host wording the mic-open guidance and module headers lead with Steam; the NAME ladder itself is untouched — demoting 'cable input' was considered and rejected (on a box where minting transiently fails, the SSM would outrank an installed cable, steal the silent sink, and make audio host-audible).	2026-08-07 11:27:29 +02:00
enricobuehler	3a35773b70	Merge origin/main; 4:4:4 has no software floor, and the ABI is 17 ... Reconciling with #85 (FFmpeg is gone from the client). Two of my claims were true against the pre-merge tree and false against this one. Note 4 said the desktop clients need no 4:4:4 decode probe "because every rung can display full chroma — swscale converts for the software rung". There is no swscale any more. The CPU floor is openh264 + rav1d, it is 4:2:0 8-bit by contract and has no HEVC at all, so it refuses a 4:4:4 stream rather than converting one. The client still advertises the bit unprobed, which was the point of the original fix, but the honest reason is different: full chroma is a hardware path (Vulkan RExt, NVIDIA today), and what catches a box whose hardware 4:4:4 fails is note 2's codec reconnect, not a downgraded picture. Note 13 repeated the same wrong premise and now names both halves of its warning. The C ABI is 17, not the 14 I read before the merge. Textual side of the conflict: #85 rewrote the Codecs column and notes 1-3 of the same table while leaving note 4's stale 4:4:4 text alone. Theirs kept in full; only the 4:4:4 column and note 4 are mine.	2026-08-07 11:25:17 +02:00
enricobuehler	f1e7ec3535	docs: the 4:4:4 story catches up with the code that ships it ... The support matrix said the desktop clients' Full chroma switch "has no effect today" and that only the Apple client asks for 4:4:4. Both stopped being true in July: `clients/session/src/main.rs` advertises VIDEO_CAP_444 whenever the setting is on, deliberately with no client-side probe, because every desktop decode rung can display full chroma — the Vulkan presenter samples the 2-plane 4:4:4 pool formats and swscale converts for the software rung. So Linux, Windows and Apple all ask; Android is the one that genuinely doesn't implement it. The other half was HDR. `9f72a3b6` gave the Windows IDD-push capturer a packed 10-bit BT.2020 PQ RGB output, so NVENC encodes HEVC Main 4:4:4 10 and the two compose — the matrix still said "4:4:4 and HDR together is refused", and hdr.md still called PyroWave the only exception. Linux is the side that keeps the trade: handshake.rs resolves the depth back to 8 for a 4:4:4 session, so full chroma wins and the stream is SDR. Three cells move ❌ → ⚠️ rather than ✅ on purpose. The client half is unconditional, but the host half is not: HEVC 4:4:4 means an NVIDIA host, or PyroWave on any vendor. The notes say which, and point at the stats overlay's `4:4:4→4:2:0` tag — this negotiation is the one that fails loudly. Also: C ABI version 13 → 14; PyroWave's ≈8K 4:4:4 block-index ceiling now has a note; and the roadmap no longer calls Intel 4:4:4 a hardware limit, which the matrix and vaapi.rs both contradict — VCN can't, VAAPI hasn't. Spot-checked and left alone as still accurate: the Linux client clipboard stub, VAAPI declining 4:4:4, Android having no 4:4:4 at all, and the wire / driver / gamepad-channel versions.	2026-08-07 10:58:58 +02:00
enricobuehler	bbbcf321e5	Merge origin/main into worktree-native-decode-m0 ... main moved 93 commits while this branch ran. Two conflicts, both where main's new work sat next to M10's excision: packaging/flatpak/io.unom.Punktfunk.yml — main added the vendored gamescope WSI layer (the only route to HDR on a Deck) and, before it, a vulkan-headers module. Took both: this branch predates them and deletes neither. But the headers module's stated consumer was pf-ffvk's bindgen over FFmpeg's hwcontext_vulkan.h, and M10 deleted pf-ffvk — so it now reads as dead weight to the next person. It is not: the WSI layer IS a Vulkan layer, compiles against those headers, and builds after it, so module order is the dependency. Rewrote the rationale to say so, including why dropping it would be expensive to discover — flatpak.yml has no pull_request: trigger, so a manifest break reaches main invisibly and a tag then ships no Linux flatpak. Also recorded that the native decoder needs nothing from there: pf-vkdecode reaches Vulkan through ash, which is pure Rust bindings, no bindgen, no C headers. crates/pf-console-ui/src/screens/settings.rs — main restructured the gamepad settings into TABS, which removed the per-row section headers; this branch had left Some("Video") untouched from the merge base and added the pre-M10 decoder migration next to it. Git could not tell those apart. Took main's structure (no header, its deliberate change) with this branch's migration layered on: a stored `vulkan`, `vaapi` or `d3d11va` names no preset in the tabbed list and would render as "—", then silently rewrite the user's preference on the next save. Gates on the merged tree, Linux container: fmt clean; cargo check --workspace --all-targets clean; clippy --workspace --all-targets -D warnings clean; tests green across pf-vkdecode (187), pf-client-core (163), pf-console-ui (58) and punktfunk-host (447 of 448 — the one failure is the pre-existing gamestream::stream::tests::sender_delivers_batches, a UDP-loopback EINTR under qemu that fails identically on a pristine HEAD).	2026-08-07 10:50:32 +02:00
enricobuehler	5c05246098	feat: M10 — FFmpeg is gone from the client ... cargo tree -p punktfunk-client-session finds no ffmpeg. The host still does, which is the whole point: pf-encode keeps libavcodec unconditionally and no host workflow, packaging script or licence file was touched. Deleted: crates/pf-ffvk, video_vulkan.rs, video_vaapi.rs, video_libav.rs, the libavcodec half of video_d3d11.rs, the av_log machinery, ffmpeg::codec::Id as the decoder's vocabulary (the quic CODEC_* wire constants now serve, which is why the evidence table was keyed on them), DecodedImage::VkFrame and ::Dmabuf, the presenter's AVVkFrame lane, and the ffmpeg-fallback feature with everything behind it. DrmFrameGuard collapses from an enum to a newtype, which removes an unsafe impl Send. Roughly 25,000 lines. Then the CI, packaging, licensing and docs work the plan's §6 lists: the Windows workflows lose FFMPEG_DIR, PF_FFVK_VULKAN_INCLUDE and their PATH prepend; the MSIX loses its DLL wildcard; the client .deb stops emitting libav sonames on its own because depends come from dpkg-shlibdeps; arch, flatpak and nix drop the dependency; and the README's "FFmpeg 7 or 8" contract narrows to the host. Three defects reached users' machines in the first cut, and none was in the deletion itself. All three desktop Settings UIs offer vulkan, vaapi and d3d11va as stored decoder values, so those strings sit in shipped settings files today. Refusing them by name — which is the correct rule for a stale pin — would have bricked every upgraded client whose owner ever touched that dropdown. They now migrate onto the native rung for the same hardware family, at decoder construction AND at each dialog's lookup, because a legacy value that matches no preset displays as "Automatic" and silently rewrites the user's preference on the next save. M9's evidence filter was deleted on the argument that with no libavcodec twin below, barring an unproven rung removes hardware decode rather than moving down one rung. That is true on Windows and false on Linux for Intel and every unknown vendor id, where prefer_vulkan_first is false and the order is native-vaapi → native-vk: a rung that has decoded nothing anywhere sitting above one that is 250/250 on three drivers. Every Intel Linux desktop would have moved from libavcodec VAAPI, shipping for years, onto pf-vaadec by default — and a rung that constructs and then produces wrong pixels leaves only by the error-streak demotion, which this codebase already documents as not tripping on the B580's strobing. The filter is restored as a narrow, pure, testable rule: an unproven rung yields to a proven one, and to nothing else. Windows deliberately passes no rung below, because that vendor family is the one with a measured wrong-pixel report against Vulkan decode, and trading no evidence for evidence of corruption is the wrong direction. And the notices still said FFmpeg was bundled. The root file is what both desktop clients include_str! and what the MSIX ships, three lines under the new card saying no FFmpeg is bundled; Apple's Acknowledgements said it too, on iOS, tvOS and macOS. The generator now emits four per-client files scoped by transitive closure — 0 FFmpeg mentions in each, verified — while the root file keeps it for the host. That also ends the standing false attribution of ffmpeg-next, GTK4, windows-rs and the NVENC SDK to an iPhone. Windows has no reachable box, so it was compiled instead: a cross clippy at -D warnings on x86_64 and aarch64-pc-windows-msvc with the C toolchain stubbed so build scripts run without linking. That gate immediately caught an include_str! path one directory too deep, which nothing else could have. Gates: container clippy -D warnings, 160 tests, workspace check, both Windows targets clean, client ffmpeg count 0 and host 2. The four decode crates are untouched, so the hardware rungs' 250/250 stands. ⚠ Owed and unrun: no GPU has executed any of this milestone. M8's on-glass software check, M7's D3D11 and VAAPI AV1 hardware legs, and M9's field bake all still want hardware, and the bake window and criteria remain the user's.	2026-08-07 08:58:47 +02:00
enricobuehler	185a69c806	fix(web/plugins): a plugin's interface loads again, instead of an empty panel ... Two separate things had to be wrong for this, and both were. The frame's own policy locked it out. Plugin UIs moved to their own origin so a plugin cannot act as the logged-in operator, and the plugin origin names the console as the only page allowed to frame it. It built that name from the incoming request — but Nitro hands the app a synthetic request with no TLS socket, so an HTTPS console reads back as `http:`. The header said `frame-ancestors http://host:47992` while the operator was on `https://host:47992`, and the browser refused the frame outright (ERR_BLOCKED_BY_RESPONSE). Nothing on screen said so; the reason was only in devtools. The scheme now comes from the listener's own TLS state, stamped at bind time, with x-forwarded-proto winning when something in front terminated TLS for us — the one case where the browser's scheme is not ours. And the port was shut. 47993 was added to the firewall definitions, but an already-open firewall does not pick a new port up: ufw expands an app profile into rules when you allow it and keeps those, so editing the profile on upgrade changes nothing, and firewalld needs a reload. Every upgraded Linux host kept a 47992-only rule, silently. The packages now notice on upgrade and print the one command that fixes it, without touching the running firewall. The NixOS module and the container image never learned the port at all; both now open it. Also: the console no longer mounts the frame while it is still checking whether that origin is reachable. A firewalled port drops rather than refuses, so the check hangs for the browser's whole connect timeout, and mounting meanwhile is exactly the empty panel with no explanation. The card that follows now names both causes it can be — an untrusted certificate for that port, or a closed one — because from a browser the two are indistinguishable. The rule is now a pure function with tests, since its failure mode is a well-formed header that only a browser rejects. Verified on glass against home-worker-5 (.21) and its ROM Manager plugin: the frame was refused before, renders the plugin's UI after.	2026-08-06 22:33:57 +02:00