2856 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
enricobuehler	bc9201d136	fix(packaging/gamescope): bump the pin past upstream's capture-format probe, and sign the RPM ... Three things, one delivery path — a Fedora/Nobara box getting the patched gamescope. **The pin moves 8c676c39 -> 5fb8dce4** (3.16.25-1 -> 3.16.25-11). The commit that matters is ff6b924, `rendervulkan: fall back to XBGR2101010 when XRGB2101010 is unsupported`: it probes `linearTilingFeatures` for STORAGE+SAMPLED and captures as XBGR2101010 where A2R10G10B10 linear storage is unavailable — which is every NVIDIA. That covers the paths that are upstream's rather than ours: the RGB intermediate `paint_pipewire()` acquires when the stream is YCbCr, and AVIF screenshots. #143 fixed our own node host-side; this is the other half, and its commit message asked for exactly this bump. All six patches rebased. Only 0006 conflicted: upstream's f8be7ee added `vulkan_has_drm_modifiers_for_features()` immediately above the `g_device` declaration our patch turns into a reference — both kept. 0003 and 0005 come out byte-identical; 0006 also picks up the `--zero-commit --no-signature` form 0001-0005 already used. **Patch 0001 now offers `xBGR_210LE` BEFORE `xRGB_210LE`**, mirroring the host-side `HDR_FORMAT_ORDER` rationale on the producer end. A consumer takes the first pod it can use, and we were handing third-party consumers (OBS and friends) the one format NVIDIA fills byte-reversed under a correct-looking label. Deliberately NOT done by calling upstream's `vulkan_get_rgb10_capture_format()`, which is what pw_pods.rs proposes: that symbol landed after 3.16.25, so it would break `packaging/nix/gamescope.nix` — which applies these patches to whatever gamescope nixpkgs pins — with an opaque C++ error instead of a patch conflict. The reorder gets the same outcome on any base. Note added there so the next reader does not "fix" it. **And the RPM was never signed.** `Sign RPMs` runs right after `Build RPM`; the gamescope RPM is built ~90 steps later, behind its own ~10-minute cache, so it missed the signing pass entirely — every punktfunk-gamescope RPM ever published went out unsigned. The repo file we tell users to install carries `gpgcheck=1`, so `dnf install punktfunk-gamescope` failed with "The package is not signed" on every Fedora and Nobara box. The package was in the channel the whole time and could not be installed from it, which is worse than absent: the notes and the docs-site both say it is there. `sign-rpms.sh` now takes explicit paths (defaulting to `dist/*.rpm` as before) and a second pass signs this one before publish, fail-closed on a tag like the first. Verified on Nobara 44 (VM 123, RTX 5070 Ti passthrough), canary 0.27.0-0.ci12611.g516a2954: * Builds clean in the fc44 CI image; banner `3.16.25-17-ga87390d+pfhdr4` (11 upstream + our 6), so the marker the host probes still reads 4 — no capability moved, hence pkgrel 3 and `.pfhdrN` staying put. * `pw-cli enum-params` on the live node: BGRx, NV12, **xBGR_210LE (81), xRGB_210LE (80)** — 8-bit consumers still negotiate bit-for-bit, 10-bit now leads with the safe one. * All four patched flags present, `--pipewire-composite-external-overlay` included. * Patch 0006 confirmed working by comparison, which is the only way to see it: the new build exits 0 where both the pre-0006 `+pfhdr2` build and the stock 3.16.23.2 abort with 134. * Signing fix proven with a throwaway key: `Signature: (none)` -> `digests signatures OK`. * Host health on the canary: synthetic spike 300/300 encoded, loopback 300 recovered, 0 mismatches. One unexplained one-off: the very first headless run after install segfaulted at exit (SIGSEGV, after "Primary child shut down!"). Not reproduced in 11 subsequent runs across every flag combination, so it is recorded rather than diagnosed — the binary is stripped and there is no symbolised core.	2026-08-09 18:00:28 +02:00
enricobuehler	003ce8bea7	Merge pull request 'Every NVIDIA gamescope HDR stream had red and blue swapped — and a sysext step added in a release was unreachable forever' (#143) from worktree-hdr-rb-swap-nvidia into main ... Reviewed-on: #143	2026-08-09 15:34:02 +00:00
enricobuehler	235b8e55d4	Merge pull request 'chore(web): console onto @unom/ui 0.9.2' (#142) from worktree-console-unom-092 into main ... Reviewed-on: #142	2026-08-09 15:32:35 +00:00
enricobuehler	0b252403cd	fix(web): fix the card inset at the root, not at the call sites ... The broken inset on the Displays configuration card was the symptom. The cause is structural, and it had already been diagnosed at least twice in-tree without being fixed. Two faults, both in components/ui/card.tsx: 1. The padding was a RESPONSIVE COMPOUND: `p-4 pt-0 sm:p-6 sm:pt-0`. tailwind-merge resolves conflicts only within a variant, so any call-site override won at the base and lost at `sm:` — correct on a phone, wrong on every desktop. Measured on the Displays card before this change: padding-top 24px at 500px, 0px at 1440px. 2. `pt-0` encoded an assumption about a SIBLING that nothing enforced — "a CardHeader is above me and supplies the top inset". Delete the header, which is exactly what tabbing a page does since the tab label replaces the card title, and the top inset silently vanishes at ≥640px. Fix: - One single-variant utility, `p-padding-card` — the same `--spacing-padding-card` token @unom/ui's own Card uses, so nested cards finally agree on their inset. A single variant cannot half-lose an override. - Top inset is now self-correcting: `[&:not(:first-child)]:pt-0`. Ask the DOM instead of the author. A headerless CardContent keeps its inset with nothing to remember. Seven call sites had grown their own compensation in five dialects — `p-6`, `p-card pt-card sm:pt-card` (×3), `p-4 sm:pt-6` (×3), `pt-4 sm:pt-6`, and my own `pt-6` from the tabs commit. All removed; they are the symptom-fixes this replaces. LogsCard even carried a six-line comment correctly describing the trap and working around it locally — that comment is now three lines saying it no longer needs saying. `flush` stays: full-bleed content is a real intent, expressed as a prop the component honours rather than a utility that has to out-argue the one already there. Guarded by UI/Card → "Inset with and without header", a headered/headerless pair that has to look identical on every side. It must be checked at BOTH widths — a single width cannot show this class of bug, which is why it kept surviving. Verified by measuring computed padding at 500px and 1440px: first child 20px on all four sides, after-a-header 0px top and 20px elsewhere, identical at both widths. tsc clean, biome clean on every touched file, 9/9 server tests, build + i18n clean, 32/32 screenshots.	2026-08-09 17:23:09 +02:00
enricobuehler	0ab17ee81d	fix(packaging): a post_merge step added in a release was unreachable forever ... A sysext upgrade is driven by the script from the OLD image -- /usr/bin/punktfunk-sysext is replaced by the very `systemd-sysext refresh` that runs mid-upgrade -- so a post_merge step ADDED in the new release is executed by nobody. The old script does not have it, and the new script never gets a turn: from then on `update` matches the "already on $cur" branch and returns before post_merge. The step is permanently unreachable on exactly the installs that need it, and nothing says so. Field-proven on the Bazzite host that took 0.25.0 -> 0.26.0 (2026-08-09). The casualty was the `punktfunk` group, which post_merge learned to create in 0.26.0 (62a6fa9f): 0.25.0's script ran the upgrade, so the group was never created, and every `punktfunk-sysext update` since has said "nothing to do". `pf-dm-helper` gates on membership in that group, so it refused every caller -- pkexec authorised it and the helper then declined itself -- and every managed gamescope takeover fell back to "stopping the display manager needs privilege", leaving sddm's autologin Relogin loop churning logind sessions for the whole stream. Re-run post_merge when already current. Everything in it is idempotent (guarded getent/groupadd, `install` of /etc mirrors, udevadm reload/trigger, sysctl, modprobe), so convergence is the honest behaviour and "nothing to do" was a lie about host state. Add an explicit `reapply` verb too, so the steps a sysext image cannot carry can be re-applied without reinstalling the image. Also print the membership hint. Creating the group is necessary but NOT sufficient and the difference is invisible until a stream fails: joining stays opt-in by design (writing vhci `attach` materialises an arbitrary emulated USB device), so post_merge now names the exact usermod when SUDO_USER is not a member. Matched with `grep -qx` so `punktfunk-update` does not read as `punktfunk`. bash -n clean; shellcheck clean apart from the pre-existing SC1091 on `. /etc/os-release`, which fires on the unmodified file too.	2026-08-09 17:08:24 +02:00
enricobuehler	31aef4b09f	feat(web): tab the Virtual displays page ... Same pill strip the plugin UIs use, via @unom/ui's Tabs: Configuration | Live displays. The page was two stacked cards, and the configuration card ALONE is taller than the viewport — the existing comment on the unsaved badge says as much, because that height is how pending edits went unnoticed. The live-display list sat below all of it, so in practice it was off screen. Two details that are not cosmetic: - The dirty marker moved from the card header onto the Configuration TRIGGER. Behind a tab the old badge would vanish entirely while Live was open — a strictly worse version of the problem it was added to solve. On the trigger it survives both tabs, and the Custom block keeps its own inline badge for when the tab IS open. - The strip is extracted as a presentational `DisplayTabs` rather than inlined in `DisplaySection`. The container calls `useBlocker`, which needs a router, so it cannot render in Storybook — and this page's story exists specifically to pin the MOTION NESTING of the preset grid (a card sets no delayChildren, so tiles nested one level deeper stop staggering). Inserting tabs changes that ancestor chain, so the story has to render the real one or it passes for the wrong reason. Adds Pages/Displays → "Unsaved on other tab", which switches to Live with a dirty draft: if the marker ever goes silent there, the warning is gone exactly when it matters. Verified: tsc clean, biome clean, `bun test server/` 9/9, vite build + i18n check clean, Storybook builds, 32/32 screenshots.	2026-08-09 16:58:46 +02:00
enricobuehler	97928516a0	fix(pf-capture): every NVIDIA HDR stream had red and blue swapped ... gamescope's capture textures are mappable, hence linear-tiled, and NVIDIA does not implement linear-tiled STORAGE for A2R10G10B10_UNORM_PACK32. Upstream says it plainly in rendervulkan.cpp: "imageStore lands in XBGR order there, swapping R/B". So the composite writes XBGR bytes into a buffer still LABELLED XRGB2101010, and our patch's spa_format_to_drm() derives that label from the negotiated SPA format alone, never asking the hardware what it can actually write. The host then believed the label, correctly at every step: xRGB_210LE -> PixelFormat::X2Rgb10 -> NV_ENC_BUFFER_FORMAT_ARGB10. DRM XRGB2101010 really is "B in the low 10 bits" and NVENC ARGB10 really is "B in the lowest 10 bits"; the Windows twin (R10G10B10A2 -> ABGR10) is correct by the same rule. Every mapping audits clean because the label was right and only the CONTENT was wrong -- which is why this survived a full trace of both ends. Fix the preference host-side: offer xBGR_210LE FIRST. The first compatible consumer pod wins, so that is what a gamescope session lands on, and an XBGR2101010 texture is one NVIDIA writes in its own order -- label and content agree. It costs nothing elsewhere: A2B10G10R10_UNORM_PACK32 is the universally supported packed-10 format, it is what upstream's own fallback picks, and X2Bgr10 has a first-class encoder path (NVENC ABGR10, VAAPI X2BGR10LE). xRGB_210LE stays as the second pod so a producer offering only it can still negotiate HDR instead of dropping to the SDR downgrade. Doing it here rather than in the patch set is deliberate: the real fix is for spa_format_to_drm() to offer only what vulkan_get_rgb10_capture_format() reports, but that function landed after 3.16.25 and the pin is 3.16.25-7-g60561e2+pfhdr4 (0 "2101010" strings in the shipped binary), so the deployed gamescope cannot self-correct. This ships in the host binary with no gamescope rebuild. Field-confirmed on the RTX 5070 Ti Bazzite host with 0.26.0, and confirmed host-side rather than client-side by reproducing the identical swap from two unrelated clients (16" MacBook Pro and Mac Studio). SDR was never affected -- it takes no packed-10 path. Gate (pf-lxcheck2, linux/amd64): fmt clean, clippy --all-targets -D warnings clean, cargo test -p pf-capture 60 passed / 0 failed incl. the new hdr_offers_xbgr_before_xrgb order pin.	2026-08-09 16:58:15 +02:00
enricobuehler	d13d253c2f	chore(web): @unom/ui 0.8.16 → 0.9.2 ... Brings the console onto the current design system. 0.9.x adds the Badge, Spinner, Skeleton, Switch, Table, EmptyState and CodeBlock primitives, and 0.9.2 carries the form fixes found while overhauling the rom-manager plugin UI: - Select's border and focus ring resolved to `--main`, which is the FOREGROUND here (`--main: var(--foreground)` in web/src/styles.css), so the trigger wore a near-white border and a 3px near-white focus ring. Its chevron and placeholder were painted `--secondary`, a SURFACE colour, and all but vanished. Now on `--input`/`--ring`, the same tokens InputText already used. - InputNumber declares a color-scheme, so the browser-drawn spinner arrows stop being near-black on a near-black field. Both defects were live in this console too — the console palette is what exposes them. Verified: codegen + vite build clean, `tsc --noEmit` clean, `bun test server/` 9/9, Storybook builds, 31/31 screenshots. A probe over all 61 stories reports ZERO page errors, and the two stories containing a Select now render it at h-input-height with `border: rgb(42, 33, 72)` (the input token) and a muted-foreground chevron. Note: the console's components/ui/ wrapper layer is unchanged and still required — @unom/ui's DialogContent remains a surface with no Portal or placement, which is exactly what web/src/components/ui/dialog.tsx supplies.	2026-08-09 16:27:08 +02:00
enricobuehler	516a295432	Merge pull request 'My gamescope gate withheld the host .deb it was meant to protect — the release still ships the KDE-breaking one' (#140) from worktree-gamescope-gate-placement into main ... Reviewed-on: #140	2026-08-09 09:12:55 +00:00
enricobuehler	2c190b27b4	Merge pull request 'Switching audio device mid-stream killed the sound for the rest of the session — AVAudioEngine stops itself, and nothing ever restarted it' (#141) from worktree-audio-device-switch-silence into main ... Reviewed-on: #141	2026-08-09 09:10:52 +00:00
enricobuehler	3cfa5ca194	Merge pull request 'The capability-hint test asserted the environment, not the code — main is red on a machine where nothing is wrong' (#139) from worktree-kwin-capability-test-env into main ... Reviewed-on: #139	2026-08-09 09:10:33 +00:00
enricobuehler	bf913c5706	fix(apple): switching audio device mid-stream killed the sound for the rest of the session ... Field report, macOS client, host-independent: start a stream with AirPods in, take them out — nothing on the speakers; put them back in — nothing in the AirPods either. Only restarting the whole stream brought audio back. An AVAudioEngine does not follow the audio hardware. When the output device changes under a running engine, its IO unit sees the new hardware, THE ENGINE STOPS ITSELF, and it posts AVAudioEngineConfigurationChange. It stays stopped until somebody starts it again, and nothing here ever did — no error, no log line, just a session rendering silence from that moment on. Putting the AirPods back in is a second stop, not a recovery, which is exactly why that half of the report looked so strange. Measured on the client's own playback topology (source node -> main mixer, 48 kHz stereo) by moving the default output device programmatically: render callbacks go from ~94/s to zero the instant the device changes, and both restarting the same engine and building a fresh one resume them. The fix watches the hardware and rebuilds the topology the session was started with, on whatever device is there now. Three triggers, because no single one covers the ground: - the engine's own configuration-change notification, every platform — the direct signal, but it can only be posted BY an engine, so it cannot report a rebuild that failed to start; - a CoreAudio HAL default-output-device listener on macOS — independent of any engine and of the engine's topology. This is what makes the recovery work for the voice-processing engine, which is the DEFAULT macOS configuration (mic and echo cancellation both default on) and whose notification behaviour could not be verified: no Mac in the fleet can initialize VPIO at all; - route-change and media-services-reset on iOS/tvOS, where the session rather than the device is what moves. The route observer is now installed for mic-off (.playback) sessions and on tvOS too — it used to be iOS-and-mic-only, for the earpiece steer, but every platform has engines a route change can stop. They collapse into one debounced rebuild (one switch produces a burst), with a floor between rebuilds so a device that renegotiates in a loop cannot spin the session, and a short retry ladder for a device caught mid-transition — a rebuild that fails leaves no engine to post the next notification, so that path must not simply give up. The ring is deliberately carried across: the drain thread keeps decoding through the switch, and the ring's overflow policy has already dropped whatever went stale while the engine was down. A rebuild is only ever done when it concerns us. A healthy engine that followed the change on its own is left alone, and somebody changing the system default while this session is pinned to a named speaker is none of our business — rebuilding for that would cost an audible gap for nothing. The trigger wiring is split into AudioDeviceWatcher for one reason: an end-to-end test of the recovery needs a live session, which needs a host, and punktfunk-host does not build on macOS — so the part where a silent failure costs the session ALL of its audio would otherwise ship unverified. On its own the watcher is pointed at the real hardware from a unit test: a real default-output-device move must reach the owner, our engine's notification must get through, a foreign engine's must not. Neutralizing the wiring fails both positive tests and neither negative one. AudioDeviceSwitchTests drives the real SessionAudio through the out-and-back switch against the loopback host; it skips wherever that fixture cannot run (which is every Mac, today) and the open host's frame budget is raised so it outlives the switch.	2026-08-09 11:03:10 +02:00
enricobuehler	5bd92dac5d	fix(ci): my gamescope gate withheld the host .deb it was supposed to protect ... The gate #135 added fails the job at the gamescope BUILD step. In deb.yml that step runs before "Publish to the Gitea apt registry" and "Attach the host .deb to the Gitea release", so failing it skipped both. Consequence on the v0.26.0 tag, and it is the worst thing in this release so far: the host .deb on the release is from 00:17 — re-point #1, BEFORE #136 revoked CAP_SYS_NICE. Every other .deb is from 08:29-08:31. So the published Debian host still runs `setcap cap_sys_nice=ep` in its postinst, which is exactly what makes the host unidentifiable to KWin and kills every KDE desktop session. A gate meant to protect the release withheld the fix for it and left the broken artifact in place. rpm.yml has the identical latent bug and only escaped it because Fedora went green: a gamescope failure there would skip the sysext image, the feed publish and the release attach, withholding the punktfunk RPMs and .raw images too. Both now warn at the build/package steps and gate as the LAST step of the job, after everything has published. A missing EXTRA must never stop a good artifact shipping — go red afterwards instead. Also: name noble's dependencies outright. `apt-get build-dep gamescope` gives it almost nothing (the distro has no comparable package), which is why this peeled one dep per CI cycle — wayland-protocols, then xdamage. The full set is derived from the Arch package's depends+makedepends, which is the build that demonstrably works, plus wlroots' own (it is a forced fallback subproject). One `apt-get` per name on purpose: a single transaction aborts wholesale on one unknown package, installing NOTHING and hiding the real gap behind a name typo. Per-package, best-effort, with the missing name echoed; the end-of-job gate is what actually decides. ⚠ Verification: both YAML files parse; every gamescope-touching `run:` block is `bash -n` clean with matrix placeholders substituted (9 blocks); the .deb glob matches build-gamescope-deb.sh's documented output (`dist/punktfunk-gamescope_<version>_<arch>.deb`) and the RPM glob excludes debuginfo/debugsource exactly as the attach loop above it does. The noble dep NAMES cannot be proven from macOS — that is what the next tag run decides, and it now decides it without holding the host .deb hostage.	2026-08-09 10:52:42 +02:00
enricobuehler	e8a4f54c07	fix(pf-vdisplay): the capability-hint test asserted the environment, not the code ... `silent_without_capabilities` called the real `capability_denial_hint()` and asserted it returns "", on the strength of a doc comment that read "The test process has no capabilities." That is true on a dev box and false in CI, where the runner container is root with a full permitted set. main went red on 0f79587d with: left: " — NOTE: this process carries capabilities (CapPrm=0x000001ffffffffff) …" right: "" Nothing was wrong: the hint fired correctly, on a process that really did hold every capability. The test was reading the ambient environment and calling it a property of the code. `permitted_caps_from_status` had already been split out for exactly this reason — "so that shape is testable without a capability-carrying process to point at" — but only the PARSE half. The message half still went to /proc/self/status. This finishes the split: `capability_denial_hint_for(Option<u64>)` holds the formatting and takes the mask, `capability_denial_hint()` reads /proc and delegates. Both keep their callers, so neither is dead code. Also adds `names_the_mask_and_the_repair_when_capped`. Without it the silent case passes just as well against a function that returns "" unconditionally — which is the failure mode this repo has been bitten by before, and the reason every decode fix carries a counterfactual. No behaviour change: the three error paths call the same function and get the same string. ⚠ Verification is CI. `kwin.rs` is `#[cfg(target_os = "linux")]`, so it does not compile on the macOS host this was written from; `cargo fmt --all --check` is clean and a Linux container check was attempted but the stock rust image has no cmake for audiopus_sys, so it never reached the test. ci.yml going green on main is the proof — and unlike the case it replaces, this test now fails or passes for reasons that have nothing to do with the machine running it. Does not touch the v0.26.0 tag: ci.yml runs on `push: branches: [main]` and `pull_request` only, and no tag leg runs cargo test.	2026-08-09 10:39:41 +02:00
enricobuehler	f80636f901	Merge pull request 'The release notes advertise a privilege 0.26.0 deliberately does not grant' (#138) from worktree-notes-capsysnice-correction into main v0.26.0	2026-08-09 08:13:45 +00:00
enricobuehler	0f79587dd6	docs(release): the notes claimed a privilege 0.26.0 deliberately does not grant ... The user-facing v0.26.0 notes said, of the PyroWave GPU-priority lever: "it is now, and the package grants the host the permission that switch needs" That was true of 0.26.0-1 and is now the opposite of true. Granting CAP_SYS_NICE made the host unidentifiable to KWin and killed desktop streaming on every KDE box across all five Linux channels, so 0.26.0-2 revokes it everywhere and must keep doing so. The lever is wired natively on Linux for the first time — that part stands — but it is dormant on an ordinary install, and the notes have to say so rather than advertise a speed-up nobody gets. CHANGELOG.md was already corrected in #136 (the 0.26.0-2 note under PW1 and the qualifier on the owed A/B). This is the user-facing half, which #136 did not touch: * the PyroWave bullet now leads with what DID land (two encoder handles, the capture buffer headroom) and describes the priority switch as present but dormant, with the reason. * a new Fixed entry for the KDE breakage itself. Worth telling users even though the release was never announced: 0.26.0-1 packages did reach the registries, and anyone who pulled one has a desktop session that fails with a missing-screencast error surviving a clean reinstall. It also explains the dormancy the bullet above now refers to. Deliberately NOT written as a "Before you update" action: upgrading strips the capability by itself on every channel, so there is nothing for a reader to do. Commit count 47 -> 52. Voice check clean (0 internal-vocabulary hits above "## For developers"); notes 67 lines.	2026-08-09 10:12:58 +02:00
enricobuehler	651a7a82a1	Merge pull request '0.26.0-1 gave the host CAP_SYS_NICE, which made it invisible to KWin — every KDE desktop session died, on five packaging channels' (#136) from worktree-kwin-capability-identification into main ... Reviewed-on: #136	2026-08-09 08:04:43 +00: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	42ee6c5628	fix(packaging): the host's CAP_SYS_NICE made it invisible to KWin, killing every KDE session ... 0.26.0-1 setcap'd `cap_sys_nice=ep` on /usr/bin/punktfunk-host so the encoder could open an elevated global-priority Vulkan queue. On every KDE box that ended desktop streaming outright: KWin virtual output failed: KWin does not expose zkde_screencast_unstable_v1 to this client reported from CachyOS on NVIDIA and on AMD, surviving a clean reinstall of host and client, and worked around only by KWIN_WAYLAND_NO_PERMISSION_CHECKS=1. The two cannot coexist. KWin hands out its restricted protocols — zkde_screencast_unstable_v1, which mints our virtual output, and org_kde_kwin_fake_input, which injects input — only to a client it can IDENTIFY, by resolving that client's /proc/<pid>/exe and matching it against an installed .desktop's Exec=. The kernel refuses that readlink to any reader whose effective set is not a superset of the target's PERMITTED set (cap_ptrace_access_check), and KWin holds no capabilities. So the instant the binary carries one, KWin's executablePath() is empty, nothing matches, and the global is never advertised — presenting exactly as a missing or mis-installed .desktop file. Measured on CachyOS (kernel 7.1.6), same-uid reader, cap_sys_nice=ep on the target: no capability .............................. readlink /proc/<pid>/exe OK capability ................................. EPERM capability + prctl(PR_SET_DUMPABLE, 1) ..... EPERM <- dumpable is NOT the gate capability dropped + PR_SET_DUMPABLE(1) .... OK <- only an uncapped process works The third row also rules out the reflex fix of moving the grant to systemd AmbientCapabilities=, which lands CAP_SYS_NICE in the very same permitted set. Nothing short of not holding the capability restores identification, so the host does not get one. The cost is pacing only. pf-zerocopy's device create already walks REALTIME -> HIGH -> default when a priority class is refused, and pf-frame's thread nice is a documented best-effort no-op without the capability — so this is 0.25.0's behaviour exactly, which is the behaviour that worked. * packaging/arch/punktfunk-host.install: grant -> revoke. post_upgrade strips the capability from boxes that already ran 0.26.0-1's scriptlet. A pacman upgrade writes a new inode and file capabilities do not survive that, so this is belt-and-braces for reinstall/downgrade paths. * pf-vdisplay kwin.rs: all three "KWin does not expose zkde_screencast" errors now read /proc/self/status and, if this process holds ANY capability, name it with its CapPrm mask and the `setcap -r` that repairs it. The failure stays impossible to diagnose from the Wayland side otherwise, and it is not unique to our own packaging — a hand-rolled setcap does it too. Verified on 192.168.1.21 (CachyOS): the capability/dumpable matrix above; cargo check and cargo clippy --all-targets -- -D warnings clean for pf-vdisplay; both new unit tests pass; and the hint itself exercised end-to-end, silent uncapped and firing with CapPrm=0x0000000000800000 under cap_sys_nice=ep. The shipped punktfunk-host-0.26.0-1-x86_64.pkg.tar.zst was unpacked to confirm its .INSTALL carries the setcap on both post_install and post_upgrade. Ships as 0.26.0-2 — packaging plus one crate, no version bump.	2026-08-09 09:37:30 +02:00
enricobuehler	08eaf337e8	Merge pull request 'v0.26.0 promised a Fedora and an apt gamescope that were never built' (#135) from worktree-gamescope-rpm-deb-builddeps into main	2026-08-09 07:22:59 +00:00
enricobuehler	39869031be	fix(ci): the gamescope RPM and .deb never built, and a warning let the tag ship anyway ... v0.26.0's notes and docs-site say the patched gamescope is now installable on Fedora and on Debian/Ubuntu. Neither package exists on the release. Both builds failed inside best-effort steps that emit `::warning::` and return 0, so every job stayed green and the only evidence was a warning nobody reads. Arch built fine, which is why it is the sole gamescope package attached. Two distinct missing build deps, same root cause: `dnf builddep gamescope` / `apt-get build-dep gamescope` resolve the DISTRO'S OLDER PACKAGED gamescope, which does not need what the pinned master tree needs. Fedora (f43 AND f44) /usr/sbin/ld: cannot find -lstdc++ have you installed the static version of the stdc++ library ? ERROR: Compiler sccache c++ cannot compile programs. build-punktfunk-gamescope.sh appends `-static-libstdc++ -static-libgcc` to LDFLAGS deliberately, so the binary still starts on SteamOS's older libstdc++. Without libstdc++-static that trips meson's very FIRST sanity check, so nothing builds at all. Debian/Ubuntu noble protocol/meson.build:7:17: ERROR: Neither a subproject directory nor a wayland-protocols.wrap file was found. The tree carries no wrap fallback for wayland-protocols. Both proven deps are installed WITHOUT `|| true` so a rename is loud. The remaining Arch makedepends the older packaged gamescope may not pull (glm, cmake, libXcursor, wayland-protocols-devel on Fedora) stay best-effort, since meson finds fallbacks and a name that moves between releases should not fail the job. And the part that actually matters: on `refs/tags/v*` a missing gamescope is now an ERROR, not a warning. A release must not be able to make a claim its own CI silently dropped. Gated in two places per platform — the build step, and the packaging step that is authoritative and also covers the cache path (the build step is skipped entirely on a cache hit, so a stale cache would otherwise reach packaging and skip in silence). Canary keeps the old best-effort behaviour. Deliberately NOT gated: the sysext leg. The notes make no claim about gamescope inside the sysext, and with the build fixed gs-cache is populated so it gets the binary anyway — gating it would add release-blocking risk with no matching promise. ⚠ Verification is CI itself: both YAML files parse, and every gamescope-touching `run:` block is `bash -n` clean with the matrix placeholders substituted. The dep names cannot be proven from macOS; the rpm and deb legs on the next tag are the proof, and they are now hard-gated, so a wrong name fails loudly instead of shipping another empty promise.	2026-08-09 09:22:20 +02:00
enricobuehler	55f361cb92	Merge pull request 'The v0.26.0 tag went red on Windows — a Linux-only reader tripped dead_code' (#134) from worktree-pyrowave-wire-dead-code into main	2026-08-08 23:44:44 +00:00
enricobuehler	2079411f4f	fix(pf-encode): the Windows host could not compile — a Linux-only reader tripped dead_code ... The v0.26.0 tag went red on windows-host at the clippy step, after a clean build: error: function `wire_sequence` is never used --> crates\pf-encode\src\enc\pyrowave_wire.rs:68:15 = note: `-D dead-code` implied by `-D warnings` `pyrowave_wire` is cfg'd for linux OR windows and is genuinely shared — `packet_boundary` and `stamp_color_bits` each have callers on both backends. `wire_sequence` does not: every call site is in `enc/linux/pyrowave.rs`, which is `#[cfg(all(target_os = "linux", feature = "pyrowave"))]`. Alternating encoder handles are a Linux-side concern (PW5); the Windows backend drives pyrowave's compat device with a single handle and never needs the counter. The module's own `#[cfg(test)]` block does not reference it either, so on Windows the item has zero callers in every target and dead_code is correct — it is the `-D warnings` promotion to a hard error that stops the lib compiling. Scoped to the one item rather than the file, and expressed as `cfg_attr(not(target_os = "linux"), ...)` rather than a bare `allow`, so dead_code stays LIVE on Linux — where the caller lives, and where this function quietly losing its last caller would be a real finding rather than noise. ⚠ Not reproducible off a Windows box: cross-compiling to x86_64-pc-windows-msvc from macOS dies in openh264-sys2's build script (clang++ rejects `-fPIC` for that target) long before the lint stage. The mechanism is nonetheless exact — one item, one cfg, zero callers behind it — and the windows-host and windows-msix legs are the proof. No behaviour change on any platform: this adds a lint attribute and eight lines of comment.	2026-08-09 01:43:54 +02:00
enricobuehler	4d1a1348c0	Merge pull request 'chore(release): bump workspace version to 0.26.0' (#133) from worktree-release-0260 into main	2026-08-08 23:29:38 +00:00
enricobuehler	e5180a5b7d	chore(release): bump workspace version to 0.26.0 ... 47 commits since v0.25.0, most of them from field reports on 0.25.0 itself, plus Wave 2 of the PyroWave Linux host-performance program. Nothing breaks: the wire protocol stays at 2 and the C ABI stays at 17, so this release adds no call, no message and no capability bit. pf-driver-proto is byte-for-byte identical to v0.25.0 and to v0.24.0. Four new environment variables (PUNKTFUNK_OVERLAY_MASK, PUNKTFUNK_GAMESCOPE_REFRESH_RATES, PUNKTFUNK_PYROWAVE_CHUNK_KIB, PUNKTFUNK_PYROWAVE_STREAMED_AU), verified new by git grep at the v0.25.0 tag rather than assumed. plugin-kit goes 0.3.2 -> 0.4.0 for the `plugin` launch kind; the SDK goes 0.1.2 -> 0.1.4; gamescope patch level +pfhdr2 -> +pfhdr4. Two behaviour changes make a client advertise LESS than it used to, both deliberate: VIDEO_CAP_444 is now probed against the driver rather than ridden off the setting alone (every Steam Deck with "Full chroma" on was losing HEVC entirely, not crispness — no AMD silicon decodes HEVC 4:4:4), and the Decky client-update check now reports a failure instead of dressing it up as "up to date". Bump is the same four files as 0.25.0: Cargo.toml, Cargo.lock, docs/releases/v0.26.0.md, docs/releases/whatsnew/v0.26.0.txt — plus the CHANGELOG.md section, which the split at 0.25.0 made part of the ritual. Gates run locally, all green: * cargo fmt --all --check clean * cargo metadata --locked resolves * Cargo.lock diff versions-only, 70/70 changed lines, 35 crates * Play whatsnew gate 398/500 chars, not byte-identical to any other release * notes voice check 0 internal-vocabulary hits above "## For developers" Notes are 66 lines against 0.25.0's 83, covering 47 commits. Still owed on glass and recorded in the CHANGELOG's verification table: iPhone + Bluetooth listen, Apple TV stats overlay, MacBook audio listen, the Deck HEVC/4:4:4 retest, a Windows wake-from-sleep cycle, and the PyroWave-under-game-load A/B with CAP_SYS_NICE actually granted.	2026-08-09 01:28:39 +02:00
enricobuehler	4070d043d6	Merge pull request 'PyroWave on Linux: the GPU-priority knob never fired, a dmabuf timeout condemned the host, and the jumbo grow was dead code' (#132) from worktree-wave2-pyrowave into main ... Reviewed-on: #132	2026-08-08 23:23:12 +00:00
enricobuehler	ebf61cb448	Merge branch 'worktree-wave2-pw5-encode-overlap' into worktree-wave2-pyrowave ... # Conflicts: # crates/pf-encode/src/enc/linux/pyrowave.rs	2026-08-09 01:14:59 +02:00
enricobuehler	4a92c64144	Merge branch 'worktree-wave2-pw7a-jumbo-shard' into worktree-wave2-pyrowave	2026-08-09 01:13:30 +02:00
enricobuehler	2426056465	Merge branch 'worktree-wave2-pw6-streamed-au' into worktree-wave2-pyrowave	2026-08-09 01:13:25 +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	2dd65bdd41	Merge pull request 'Opening the Steam menu on the Deck moved the game too — the pad is now held neutral while an overlay owns it' (#131) from worktree-deck-overlay-input-mask into main ... Reviewed-on: #131	2026-08-08 22:59:30 +00:00
enricobuehler	5cbaca7789	feat(client/pads): stop forwarding the pad while the Steam overlay owns it ... On a Deck in Gaming Mode the Steam menu and the QAM are driven by the SAME physical controller the client forwards, so opening either one moved the game on the host as well as Steam's UI — a second, invisible player. Steam Input masks a normal game here; it cannot mask us, because masking happens on Steam Input's virtual pad and we deliberately forward the REAL one (28DE:1205 — the virtual pad has no gyro, trackpads or paddles). SDL ships the exact behaviour we want and it is on by default: presses are dropped while the process has windows but no keyboard focus, releases still get through. It CANNOT fire on a Deck. gamescope resolves focus per Xwayland ctx and the client sits alone in its own, so the Steam overlay — which lives in the root ctx — never takes our X focus away and no FocusOut is ever generated. Measured on glass: with the QAM open, X input focus inside the client's ctx stayed on its window for the whole 4 s, while GAMESCOPE_FOCUSED_APP flipped to 769 (Steam) and GAMESCOPE_FOCUSED_APP_GFX stayed on the app. So the signal is explicit. `overlay_focus` watches those two atoms on the gamescope root ctx — which is NOT our own $DISPLAY under `--xwayland-count 2`, hence the socket-directory walk and the flatpak filesystem line — and the presenter ORs it with window focus into one `set_masked`. Masking is deliberately not `set_forwarding`: that closes the slot and sends GamepadRemove, so the game would see a controller UNPLUG every time somebody opened the QAM. This keeps every slot open and only stops the transitions, after flushing what the host believes is held so a stick deflected at overlay-open stops steering instead of freezing at its last value. On the way back, held buttons are adopted rather than replayed — the A that picked a QAM row must not fire in the game as it closes — while axes are re-sent, since a stick has no press to ghost and SDL only speaks on change. Fails open throughout: no gamescope, no X, or an unreadable signal all leave forwarding exactly as it was. `PUNKTFUNK_OVERLAY_MASK=0` opts out.	2026-08-09 00:55:16 +02:00
enricobuehler	9c854893bc	Merge pull request 'plugin-kit 0.4.0 — publish the launch surface #129 added, because rom-manager's main is red until it exists' (#130) from worktree-plugin-kit-040 into main ... Reviewed-on: #130 plugin-kit-v0.4.0	2026-08-08 22:53:39 +00:00
enricobuehler	6b7997cace	chore(plugin-kit): 0.4.0 — the launch surface a plugin needs to publish a tile the host cannot name ... `serveUi({launch})`, `PluginLaunchTarget` and `makeLaunchHandler` (#129) are new API, so this is a minor bump rather than a patch. It also carries `SyncError.message`, without which a host refusal reaches a plugin's own UI as the bare tag `SyncError` and nothing else. Unblocks rom-manager, whose main is currently RED: it merged the consuming change while still pinning `^0.2.0`, so `bun install --frozen-lockfile` there resolves a kit without these exports and the typecheck fails on all three. Publishing this and then bumping that pin is the fix — in that order, because the lockfile cannot resolve 0.4.0 until it exists on the registry. Tag `plugin-kit-v0.4.0` to publish; the workflow asserts the tag matches this version.	2026-08-09 00:52:37 +02:00
enricobuehler	78ba2342b5	Merge pull request 'rom-manager has been putting 0 games in the library since 08-05 — a plugin launch kind, so a scanner can publish tiles the host cannot name' (#129) from worktree-rom-manager-plugin-launch into main ... Reviewed-on: #129	2026-08-08 22:44:44 +00:00
enricobuehler	7d37fe450d	test(pf-encode): run PyroWave at depth 2 on real hardware — without shipping depth 2 ... Wave-2 PW5, the stage-6 experiment. Shipped behaviour is UNCHANGED: `max_inflight` is still 1. Stage 6 is the frame-corruption stage, and its gate is an on-glass tear-hunt with a live compositor, a real client and ten minutes of moving content. That is not runnable from here. But the depth-2 risk has two halves, and one of them lives entirely in this crate — the per-slot resources (`cmd`/`fence`/`csc_set`/y/uv/cursor) and the alternating encoder handles — so that half can be answered now, on the GPU, and the answer is worth having before anyone attempts the other. The experiment drives the backend with two frames genuinely in flight (submit N+1, then poll N) and compares the result against the encoder's OWN synchronous output over the same 16 moving frames. Its own depth-1 decode is the honest reference: pyrowave's raw AU bytes are not reproducible run-to-run (see the stage-3 commit), but its decoded planes are. RESULT, .21 / RTX 5070 Ti (GPU idle at 180 MHz of 3090 — the slow-clock worst case on this card): depth-2 vs depth-1 over 16 frames: worst-case PSNR identical (inf) Bit-identical luma, every frame, in order. So stages 4 and 5 between them are sufficient for the encoder side: doubling the six single-slot resources and alternating two `pyrowave_encoder` handles under one monotonic wire sequence really does make overlap invisible to the decoder. The test is built to fail rather than to pass. Content MOVES every frame (flat fills are the documented false-green trap — a torn frame stitched from two halves of a static card is invisible), it asserts two frames were ACTUALLY in flight rather than silently proving nothing, it asserts the AU count is unchanged, and it carries an off-by-one discriminator that raw PSNR would miss: each overlapped frame must match its own reference BETTER than it matches the previous one, so a pipeline delivering frames one position late fails even though every individual PSNR looks fine. It reaches `max_inflight` directly instead of through a shipped knob, precisely so the shipped value stays 1. ⚠ WHAT THIS DOES NOT COVER, stated here so the next person does not read it as a green light for stage 6: the CAPTURE side. `.process` hands the SPA buffer back to the compositor at callback return while the encode thread holds only a dup of its dmabuf fd, so a second frame in flight widens the window in which the producer may overwrite a buffer we are still reading by a full frame period. Nothing in this crate can test that — it needs a live producer. Stages 1 and 2 are what make it answerable (the pool census says how deep the producer's ring is; the Choice range asks for headroom), and the on-glass hunt is what would settle it. Gates green at CI parity.	2026-08-09 00:30:25 +02:00
enricobuehler	077db416ec	feat(pf-encode): two PyroWave encoder handles, and the 3-bit landmine that makes them work ... Wave-2 PW5 stage 5. Depth is STILL 1 — the handles alternate per frame, one in flight. PyroWave's `Encoder` cannot hold two frames. Not "probably not" — structurally not. `Encoder::Impl` owns ONE each of `wavelet_img_high_res`, `bucket_buffer`, `meta_buffer`, `block_stat_buffer`, `payload_data` and `quant_buffer`, and `Impl::encode` OPENS by discarding them: an image barrier with `VK_IMAGE_LAYOUT_UNDEFINED` as the old layout — a written promise that nothing else is reading it — plus three `fill_buffer` clears. Two encodes recorded into two command buffers and submitted to one queue have no execution dependency in Vulkan (submission order orders the START, not the completion), so N+1's DWT would overwrite the wavelet bands and zero the RDO buckets while N's block packing still reads them. Content-dependent, silent. So overlap means TWO handles on one device, alternated — one per slot. Every resource above is then private per handle, and within a handle the encodes stay strictly serialized (a slot's next frame is recorded only after that slot's previous one retired), which leaves patch 0004's scratch-pool invariant intact without touching it. THE LANDMINE, and it is the reason this stage is its own commit: `sequence_count` ALSO lives on `Impl`, and it is the 3-bit counter stamped into every block header. Two handles each count 1,2,3... alone, so the wire sees 1,1,2,2,3,3.... The decoder restarts a frame only when the value CHANGES (`diff = (hdr.sequence - last_seq) & 0x7; restart = diff != 0`), so a repeat reads as MORE BLOCKS OF THE SAME FRAME: `clear()` never runs, `decoded_frame_for_current_sequence` stays true, and the second frame of each pair is swallowed. Half frame rate, occasional mixed-frame blocks, no error anywhere — on every client, since pf-client-core and the Apple Metal hand-port parse the same field. `patches/0007-encoder-sequence-override.patch` (new, ~38 lines) exposes `Encoder::set_next_sequence` + a `pyrowave_encoder_set_next_sequence` C entry + a `PYROWAVE_SEQUENCE_MASK` define, so ONE monotonic counter on the Rust side is stamped regardless of which handle encodes. The setter stores `(seq - 1) & mask` because `Impl::encode` pre-increments — its contract is about the next ENCODE, not the next store. Inert when unused, so the whole Windows backend is untouched. No `.def` change: the C API is a static archive. PREDICTED, THEN OBSERVED. A negative control on .21 (the override call removed, nothing else) reads the wire out at exactly: [1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 0, 0, 1, 1, 2, 2] which is the analysis's prediction character for character, and with the override: +1 mod 8, all 20 frames, through the 3-bit wrap. THE GATE, `wire_sequence_increments_across_alternating_handles`, checks three things over 20 frames because any one alone could pass while the stream is broken: the wire counter advances by 1 mod 8; ONE persistent decoder (its `last_seq` carried across every push, exactly like a client's) reports every AU decodable; and consecutive decoded pictures DIFFER. Content moves every frame — and the first run caught a trap in the harness itself rather than the encoder: `test_card` starts its LCG at `seed | 1`, so seeds 2 and 3 build a byte-identical card and the test faked the very repeat it hunts. Odd seeds only now, with the reason written down. A runtime self-check backs the test up where the test cannot reach: after packetize, the stamped sequence is compared against what we asked for, and a mismatch logs once per process naming patch 0007. A re-vendor that loses the patch would not fail to build — it would fail on glass, subtly, and this makes it loud instead. Two byte reads per frame. `reset()` rebuilds both handles and `Drop` destroys both, each with the same null-immediately discipline the single handle had (`pyrowave_encoder_destroy` is a bare `delete` with no null check, so a stale pointer left in the field is a double free). Vendored-patch discipline: patch 0007 re-applies clean to a pristine vendor checkout (verified by stashing the vendor tree and re-applying), and `git diff crates/pyrowave-sys/vendor/` touches exactly the four intended files. VERIFIED ON GLASS (.21, RTX 5070 Ti, GPU idle at 180 MHz of 3090): all 8 `#[ignore]`d GPU tests pass, including the new gate and the 4:2:0 / 4:4:4 / 24-bpp PSNR smokes. Gates green at CI parity.	2026-08-09 00:27:28 +02:00
enricobuehler	fd98406868	Merge pull request 'The Decky plugin's "update the client" has never once detected an update' (#128) from worktree-decky-client-update into main ... Reviewed-on: #128	2026-08-08 22:21:08 +00:00
enricobuehler	5c70a90358	Merge pull request 'A Steam Deck could lose HEVC entirely to a chroma switch nothing checked — and the tool you'd triage it with denied the queue it was decoding on' (#127) from worktree-deck-hevc-shape-gates into main ... Reviewed-on: #127	2026-08-08 22:20:39 +00:00
enricobuehler	29248dcab9	feat(pf-encode): PyroWave had six single-slot resources, not the two the plan named ... Wave-2 PW5 stage 4. Pure capacity — `max_inflight` is STILL 1, nothing overlaps yet. The plan named the y/uv images as the thing to double. Reading the backend found five more, and each is a correctness problem under overlap rather than a performance one: * `csc_set` — ONE descriptor set, rewritten every frame by `bind_rgb`. Updating a set still bound by a PENDING command buffer violates VUID-vkUpdateDescriptorSets-None-03047, and on most drivers that is a wrong picture rather than an error. * `y_img`/`uv_img` — the CSC of N+1 storage-writes exactly the images pyrowave is still sampling for N. The barrier comment ("the previous frame's encode already completed under our synchronous fence") was load-bearing and said so. * `cursor_img` + `cursor_stage` — the struct comment stated the assumption outright: *"Single (not ring) because PyroWave encodes one frame synchronously — no in-flight overlap to race."* * `cmd` + `fence` — you cannot record into a PENDING command buffer at all. * `cpu_img`/`cpu_stage` (software capture / tests) — the host writes staging while the previous frame's copy is still pending. All of it moves into a `Slot`, and the encoder now owns `SLOTS` of them. Two, because Granite caps the overlap at two for us: the pyrowave device defaults to `init_frame_contexts(2)` and `next_frame_context()` — called at the top of every `encode_gpu_synchronous` — waits the context it rotates into. A third slot would need a vendored `init_frame_contexts(3)` that is not exposed. `bitstream` and `import_cache` are deliberately NOT per-slot, and the `Slot` doc says why so a later sweep does not "fix" it: `bitstream` is only touched during packetize, i.e. only on the poll side one frame at a time, and `import_cache` retaining the VkImage/VkDeviceMemory per dmabuf inode is precisely what makes it safe for two slots to sample the same imported buffer. `cpu_expand` is shared for the same reason — it is copied into staging before `submit_frame` returns, so no GPU work ever reads it. Each frame carries its slot index in `InFlight` rather than recomputing it, so `wait_and_packetize` cannot wait the wrong fence — the failure that would look like corruption rather than an error. `reset()` now waits EVERY in-flight fence, not just one, which matters the moment depth rises. WHAT IT COSTS, measured from the driver's own memory requirements rather than estimated (.21, RTX 5070 Ti, and there is now an `#[ignore]`d test that prints it on any GPU): 1080p 4:2:0 3872 KiB per slot 7744 KiB for both 4K 4:2:0 12992 KiB per slot 25984 KiB for both 4K 4:4:4 24992 KiB per slot 49984 KiB for both So the extra slot costs ~3.8 MiB at 1080p and ~24 MiB at 4K 4:4:4 — an order of magnitude under the plan's ~25-35 MB / 100-150 MB estimate, because that estimate included pyrowave's internal wavelet and scratch buffers, which stage 5's second encoder handle will add and this stage does not. Affordable on an iGPU. The open line now logs `slots`, `slot_kib` and `slots_kib` so this is visible per session and not only in a test. VERIFIED ON GLASS (.21, GPU idle at 195 MHz of 3090 — slow-clock, the worst case on this card): all 6 `#[ignore]`d GPU tests pass, and all NINE decoded-plane hashes (`ref-dense-{y,cb,cr}`, `ref-chunked-*`, `ref-dense444-*`) are bit-identical to the pre-PW5 base. Decode identity is the meaningful gate here — the raw AU bytes are not reproducible run-to-run even from an unmodified binary, which stage 3's message documents. Gates green at CI parity.	2026-08-09 00:18:38 +02:00
enricobuehler	95962f55d0	refactor(pf-encode): PyroWave waited its fence inside submit — the one backend that did ... Wave-2 PW5 stage 3. Depth is STILL 1; this is the shape change alone. `encode_frame` recorded CSC+encode, queue-submitted, waited the fence and packetized, all inside `Encoder::submit`. Every other backend in this crate puts the wait on the POLL side. That difference is the whole reason the host loop's cadence folds around this encoder: with the wait inline, `submit` returns only after the GPU is done, so the arrival-anchored floor absorbs the encode only while it stays under 0.9x the frame interval. Split into `submit_frame` (ingest -> CSC -> pyrowave encode -> queue-submit -> return) and `wait_and_packetize` (fence wait -> packetize -> AU), with an `InFlight` deque between them capped by `max_inflight`, which is 1. **One is the only value the resources can support today** — `cmd`, `fence`, `csc_set` and the y/uv images are one each, so a second concurrent frame would record into a PENDING command buffer and storage-write images pyrowave is still sampling. `submit` therefore drains to `max_inflight - 1` before recording, which states that invariant in one place instead of leaving it implicit in "the encode is synchronous". The subtle part is the command-buffer state machine, and it is unchanged: the record-and-submit closure still resets `cmd` on every PRE-submit failure (RECORDING/INVALID/EXECUTABLE, never PENDING), and the fence wait still does NOT reset on failure, because a timeout leaves the buffer PENDING where a reset violates VUID-vkResetCommandBuffer-commandBuffer-00045. What changed is that a failed wait now also leaves the entry IN FLIGHT — which is precisely what tells `reset()` there is live GPU work to re-wait before the pyrowave encoder object may be destroyed. `gpu_pending` is gone; `!inflight.is_empty()` is the same fact, and cannot drift from it. The split opened two windows that did not exist when everything ran inline, both closed here: `reconfigure_bitrate` and `set_wire_chunking` can now land BETWEEN a submit and its poll, so the packetize boundary and the bitstream cap are snapshotted into `InFlight` at submit time. Reading the live fields would have let a mid-flight bitrate drop turn a perfectly good frame into "unexpected packet count", and a mid-flight chunking change into an AU with the wrong `chunk_aligned` flag. `flush()` is no longer a no-op — it drains the in-flight frame, so the trait's poll-until-None contract still returns every AU (the `spike` subcommand and the hardware smoke tests are the real users). The perf instrument still measures submit->AU, stamped at submit and taken when the AU becomes readable, so `92326312`'s numbers stay directly comparable; the log line now carries `depth` and says plainly that above depth 1 the number legitimately grows by about one loop period. VERIFIED ON GLASS (.21, RTX 5070 Ti, GPU idle at 180 MHz of 3090 — so these are slow-clock runs, which is the worst case on this card, not the best): all 6 `#[ignore]`d GPU tests pass — the 4:2:0, 4:4:4 and 24-bpp PSNR smokes, the mode-mismatch refusal, the fd-leak check and the golden dump. Byte-identity, honestly: the AU bytes are NOT reproducible, and were not before this commit either. Three runs of the SAME unmodified binary produced three different `au-dense.bin` hashes (ab7ecaf6 / 8735700e / 933b3d40) — the vendored 4:2:0 encoder emits run-varying bytes that the decoder ignores. So the meaningful gate is DECODE identity, and that holds exactly: every decoded plane (`ref-dense-{y,cb,cr}`, `ref-chunked-{y,cb,cr}`, `ref-dense444-{y,cb,cr}`) is bit-identical between the pre-split base and this commit, across four runs. 4:4:4 AUs are additionally bit-stable and match the checked-in Apple fixture exactly. Gates green at CI parity.	2026-08-09 00:11:22 +02:00
enricobuehler	9e598f8595	fix(client): the 4:4:4 switch could cost a Deck its whole codec, and --probe-decode denied the queue it was decoding on ... Two Steam Deck findings from a field report of "the decoder was not found, it fell back to H.264 — but sometimes HEVC worked". **The 4:4:4 advertisement was a promise nothing checked.** `VIDEO_CAP_444` rode the "Full chroma" setting alone. That was safe while a software HEVC decoder existed underneath it; M8 removed one (there is no permissively licensed HEVC CPU decoder, so `software_decodable_codecs()` is H.264|AV1). The host grants 4:4:4 on HEVC ONLY, and answers the resolved chroma in the Welcome before the client builds a decoder — so on a device with no 4:4:4 decode the toggle did not cost crispness, it cost the entire codec: the Vulkan rung refuses the shape at construction, VAAPI refuses it too, there is no CPU rung, and the session reconnects on H.264. AMD has no HEVC 4:4:4 decode on any silicon, so every Deck with that switch on lost HEVC. It is per-profile and default-off, which is exactly why it looked intermittent — a "Work" profile lost HEVC where "Game" kept it, same box, same host. Gated on `hevc_444_hardware_decodable`, which asks the driver through the SAME code the rung uses at construction (`VkH265Decoder::probe_stream_support`), so the advertisement and the rung that must honour it cannot disagree. Both depths are required, not either: with HDR on the host may resolve 4:4:4 10-bit, and a device offering YUV444_8 but not YUV444_10 would land in the same hole. Answering from the Vulkan rung alone is exact rather than approximate — it is the only rung in this build that implements 4:4:4 at all (`pf_vaadec::profile_for` errors on chroma_format_idc 3, pf-dxvadec refuses anything but 4:2:0, the CPU rung is 8-bit 4:2:0). Deliberately NOT extended to VIDEO_CAP_10BIT/HDR: all three rungs implement 10-bit 4:2:0, so a Vulkan-only probe there would withdraw HDR from boxes whose VAAPI/DXVA rung decodes it perfectly — a real regression against a case never observed. The bit arithmetic moves into `video::video_caps_for` so the part that was wrong is testable without a GPU, a host or a Hello; the test is verified non-vacuous against the planted original defect. **`--probe-decode` described a different device from the one that streams.** The RADV video-decode opt-in sat AFTER the --list-adapters/--probe-decode/--list-audio /--pair early exits, so the triage tool never had it. Measured on a Deck (canary e22af40f), same binary back to back: bare `--probe-decode` printed "vulkan video decode: no", "driver decode ops: none (0x0)", "no queue family advertises VIDEO_DECODE"; with RADV_PERFTEST=video_decode in the environment, "YES" and "H.264, H.265, AV1, VP9". Any Deck triage that consulted it reached the opposite of the truth. Hoisted to the top of `run`, ahead of every early exit — nothing touches Vulkan before it (`main` calls `run` directly). Gates, in the Linux container: fmt, plain `cargo build` (not only --all-targets), `clippy --all-targets -D warnings`, and 185 tests.	2026-08-09 00:10:46 +02:00
enricobuehler	bd86598d97	fix(decky): the client update the plugin offers was never once detected ... The QAM has offered to update the client since 0.24, and on every Deck it has answered "up to date" — including right now, with a client a day out of date. The check asks flatpak for the remote's commit and compares it to the installed one, and it named the app id with no branch: `flatpak remote-info punktfunk-origin io.unom.Punktfunk`. The punktfunk remote publishes `stable` AND `canary`, so that ref is ambiguous and flatpak refuses it — "Multiple branches available" — rather than picking one. One branch INSTALLED does not help; the ambiguity is on the remote. The call failed on every box, every time, and the failure returned `available=False`, which the panel renders as good news. Hence: the plugin appeared to update only itself. Every query now names the ref in full, resolved once by `_flatpak_ref()` off the exported tree (no subprocess — `_client_argv` is on the path of every headless call). That resolution also carries the SCOPE, so a system-wide install is no longer invisible to a check that hardcoded `--user`, and the launcher pins the same `--branch=`, so the client we start is the client we check and update. A check that cannot run now says so instead of reporting up-to-date: the flatpak leg reports `client_error` exactly as the native leg already did. Dressing that failure up as good news is the whole reason this went a week unnoticed. Also: the button no longer promises "+ client" when the client is manual-only and the tap can only print a command. Verified on the Deck (192.168.1.253, canary, user scope) by running both code paths against the real install, minutes apart: pre-fix available=False remote='' post-fix available=True remote=ca010668 (installed e22af40f) and `flatpak {info,remote-info,update}` all accept the `id//branch` form there. 37 backend checks pass, 6 of them new and about exactly this.	2026-08-09 00:08:24 +02:00
enricobuehler	c3ecc29117	feat(pf-capture): the zero-copy path never asked the compositor for buffer headroom ... Wave-2 PW5 stage 2, on the number stage 1 just made visible. `build_dmabuf_buffers` set `SPA_PARAM_BUFFERS_dataType` and stopped there — no `SPA_PARAM_BUFFERS_buffers` at all, so the pool depth the whole zero-copy safety argument rests on was entirely the producer's choice, and we never even expressed a preference. This asks for 8 (min 2, max 16). A **Choice Range**, deliberately, not a fixed count. SPA intersects the consumer's and producer's Buffers params, so a fixed 8 against a producer that can only afford 4 empties the intersection and the link stalls in "negotiating" with no error anywhere — the exact trap that cost this codebase the entire Linux cursor channel once, when a 256^2 cursor-meta max failed to intersect Mutter's fixed 384^2 offer. With a range the producer clamps into it and negotiation still succeeds; the min stays at 2 so nothing that works today stops working. The numbers, and what they are not: 8 buffers is ~133 ms of pool at 60 Hz and ~33 ms at 240 Hz, well past the ~3-4 ms capture-to-fence latency PW3/PW4 measured, with room for a second frame in flight. 16 is a ceiling rather than a request — a 4K 4:4:4 buffer is ~25 MB, so 16 of them is ~400 MB of compositor allocation. These are the values we ASK for; what a producer actually allocates is what stage 1's census line reports, and that line is the one to trust. Scoped to the dmabuf pod only. The mappable and SHM-only builders are untouched: their consumers copy out of the buffer inside `.process`, so pool depth is not part of their correctness argument. A test pins the pod SHAPE — Choice, Range, Int children, values default-first — so a later simplification cannot quietly turn the range back into a number and take the negotiation down with it. Gates green at CI parity; on-glass negotiation on each producer is stage 2's own gate and is reported with the stage-1 census numbers.	2026-08-09 00:01:24 +02:00
enricobuehler	6d550530fe	feat(pf-capture): nothing had ever counted the compositor's buffer pool — the number every zero-copy safety argument rests on ... Wave-2 PW5 stage 1, and the one stage with no risk at all. The zero-copy capture path dups the dmabuf fd, publishes the frame, and hands the SPA buffer straight back to the producer at `.process` return — while the encode thread has not yet imported it, let alone read it. The code says so itself ("content stability across the brief import/encode window relies on the compositor's buffer-pool depth, like any zero-copy capture"). That depth is therefore load-bearing: it is the ONLY thing standing between us and the producer overwriting a buffer mid-read. And it had never been measured. Not logged, not asserted, not even requested — `build_dmabuf_buffers` set `SPA_PARAM_BUFFERS_dataType` and nothing else, so whatever the producer picked is what we got, silently. This adds the `add_buffer`/`remove_buffer` stream callbacks PipeWire has always offered and logs the count once per distinct depth: `pool_depth`, `high_water`, and the latest-frame-only `drained` count beside it. One line per session on a stable pool (`.process` runs at the capture rate — an unconditional log would be 240 lines a second of the same number), a second line if a renegotiation changes the depth. `high_water` is tracked separately from `live` because a renegotiation frees the pool before re-allocating it: any decision keyed on the live count would read that dip as "the pool shrank". `remove` saturates at zero rather than wrapping, so an unmatched remove cannot report `u32::MAX` buffers. Measurement only — no behaviour change, and no consumer of the number yet. PW5's later stages need it (a deeper encode pipeline widens the overwrite window by a full frame period), but the number is worth having regardless of whether those stages ever land: it is the answer to "is our zero-copy capture actually safe on this compositor", and until now the honest answer was "nobody knows". 3 tests pin the once-per-depth logging, the renegotiation dip, and the saturating remove. Gates green at CI parity.	2026-08-09 00:01:08 +02:00
enricobuehler	e22082ac2a	Merge pull request 'No audio over Bluetooth on iOS: .defaultToSpeaker is an override that outranks A2DP' (#126) from worktree-ios-bluetooth-audio-route into main ... Reviewed-on: #126	2026-08-08 21:54:23 +00:00
enricobuehler	4f5ca5f9bc	docs(pf-capture): KWin/RADV was the last untested producer — it has no fence either ... Closes PW4's one remaining gap. The Steam Deck switched to Desktop Mode gives KWin on RADV, the combination none of the earlier legs covered, and it reports no implicit fence like every other: gamescope + NVIDIA (RTX 5070 Ti) NoFence Mutter + NVIDIA (RTX 5070 Ti) NoFence gamescope + RADV (Deck VANGOGH) 300/300 NoFence, mean 23us, p99 <=100us KWin + RADV (Deck desktop) no fence (older build's wording: waited=false) That is every compositor x vendor this fleet has. PW4 retires with no outstanding doubt rather than "probably fine except one box we never tried". Measured with the Deck's OWN already-authorized binary rather than a scratch build, because KWin grants zkde_screencast_unstable_v1 per EXECUTABLE PATH: it resolves /proc/<pid>/exe against a .desktop's Exec= and caches the grant on first connect, so an unregistered path is refused outright and registering one needs a re-login. The fence probe is pre-existing capture-path code, so a build from July answers the outcome question perfectly well — and nothing of the user's was modified to get it. Comment-only; no behaviour change. fmt + pf-capture clippy -D warnings green.	2026-08-08 23:52:54 +02:00
enricobuehler	07f6d6f324	fix(apple): .defaultToSpeaker outranks Bluetooth, so every headset lost the stream ... Field report on 0.25, iOS: "no audio over Bluetooth ... plays through speakers if Mic input is enabled". Both halves are one bug. `micEnabled` and `echoCancel` both default to true (EffectiveSettings.swift), so the DEFAULT iOS session is `.playAndRecord` — and that branch set `.defaultToSpeaker`. That option is not the polite preference it reads as: it is an output OVERRIDE, and it outranks an A2DP route. Wired headphones beat it, Bluetooth does not, so a cable is the one way to test it and get the right answer — which is what the comment sitting on it asserted ("headphones/BT still win"). Every Bluetooth listener on the default settings got the phone's own speaker instead. Turning the mic off was the accidental workaround the reporter found: that path takes `.playback`, which routes to A2DP happily and always did. The earpiece problem `.defaultToSpeaker` was reaching for is real — `.playAndRecord` really does park the built-in output on the receiver. So solve it against the route we were ACTUALLY given rather than pre-emptively: after activation, if the current output is `.builtInReceiver`, override to the speaker; anything external (Bluetooth, wired, CarPlay, AirPlay) is left strictly alone. That override is a property of the current route — iOS drops it whenever the route changes, which is exactly what lets a newly-connected headset win — so it has to be re-applied per route. Hence the route-change observer: without it, dropping Bluetooth mid-stream would hand the game to the earpiece. Registered only for a `.playAndRecord` session (a `.playback` one needs no steering), removed in stop() before the session deactivate, with deinit as a backstop. Deliberately NOT adding `.allowBluetooth`: it would make a headset's mic usable, but buys that by dragging the whole route onto HFP/SCO and collapsing game audio to narrowband. High-quality A2DP output plus the built-in mic is the better trade for a game-streaming client. Verified: builds clean on arm64-apple-ios17.0 (the triple that actually compiles these `#if os(iOS)` blocks — a plain `swift build` is macOS and skips them), arm64-apple-tvos17.0, and macOS; 257 Swift tests pass, 0 failures. On-glass iPhone + Bluetooth listen still owed.	2026-08-08 23:49:38 +02:00
enricobuehler	54666e66da	Merge pull request 'The Apple TV client had no way to show its statistics overlay' (#125) from worktree-tvos-stats-shortcut into main ... Reviewed-on: #125	2026-08-08 21:48:19 +00:00
enricobuehler	5872dfc649	feat(library): a plugin launch kind, so a scanner can publish tiles the host cannot name ... The 2026-08-05 review made `launch.kind = "command"` operator-only, and a reconcile refuses on the FIRST offending entry — so rom-manager, whose every ROM is `<emulator> <args> <rom>`, stopped putting anything in the library at all. Playnite hit the same wall and was rescued with a typed kind the host resolves itself; there is no fixed scheme for "whichever emulator the operator configured, with the core and flags they chose", so that trick does not generalise. So the entry now carries an opaque key and nothing executable, and the host asks the plugin that owns it what to run — at launch time, over the loopback UI port and per-boot secret it already registered. A stolen plugin token stops being command execution: planting an entry is not enough, because the live plugin answers 404 for a key it never published. Nothing executable is persisted or served to a client, and an emulator that moved is picked up on the next launch instead of leaving a dead tile (the same reasoning as `xbox` resolving its AUMID at launch time). The host still SPAWNS it, because only the host can put the process where the stream can see it: on Linux the line is either gamescope's own argv or a spawn carrying the session's compositor env, and the returned child is what session-game-lifetime tracks to know the game exited. A plugin spawning the emulator itself would land it outside both. - library/plugin_launch.rs — the ask: blocking ureq, bounded body, absolute cwd, no control characters, and a log line for every way it can come back empty - library/launch.rs — `plugin_recipe` tried before both per-OS resolvers, plus `launch_is_resolvable` so the async handshake probe never makes the blocking call - native.rs — the session's `resolve_launch` moves onto `spawn_blocking` - plugin-kit — `serveUi({launch})` serves `POST /__launch`; and `SyncError` finally renders its cause, which is why a host refusal with a fully explanatory 403 could reach a plugin's own UI as nothing but "Decode error"	2026-08-08 23:46:05 +02:00