9 Commits

Include renames

Author	SHA1	Message	Date
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	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	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	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	e044f68500	fix(ci/arch): v0.25.0 shipped a host no Arch box can install, and nothing could tell ... Arch moved FFmpeg 8 -> 9 (every libav soname +1) hours before the release. PR #108 fixed the real bug — packaging/arch/PKGBUILD now binds punktfunk-host to the sonames it actually linked, so pacman refuses an upgrade instead of bricking the install — and re-keyed ci/arch-ci.Dockerfile so the builder would carry FFmpeg 9. The tag was pushed four minutes later. arch.yml and docker.yml have no `needs:` between them, and arch.yml deliberately runs no -Syu ("the image's snapshot IS the build environment"), so the release build pulled the still-FFmpeg-8 `:latest` and published punktfunk-host 0.25.0-1 depends: libavcodec.so=62-64, libavutil.so=60-64, libavfilter.so=11-64, libavdevice.so=62-64, libswscale.so=9-64 against a world that had moved to 63/61/12/63/10. It fails safely — pacman refuses, nothing bricks — but it fails broadly: pacman prepares one transaction, so an unsatisfiable dependency of OURS stopped affected users' entire `pacman -Syu`. Nothing in the pipeline could have caught it. The existing assert proves the dep is VERSIONED; it cannot prove the version EXISTS. So two guards, plus the lever to repair a release that has already shipped: * Preflight parity — compare the builder's libav `provides` against the live repos and `-Syu` the container if they differ. The image is a cache and may lag; on this one axis it may not. Syncs into a throwaway --dbpath so the container never sits in the partial-upgrade state a bare `pacman -Sy` leaves. * Publish gate — resolve every built package with `pacman -U --print` against a PRISTINE --dbpath. Empty db means "nothing is installed", so every dependency must come from the repos exactly as on a user's box. Resolving against the builder's own installed set is what would hide this: a stale ffmpeg satisfies a stale bound. gamescope stays best-effort (dropped from the upload with a warning, never fatal). * workflow_dispatch(release_tag, pkgrel) — a published release cannot be repaired by re-running its tag: pkgrel would stay 1, which is invisible to a box that already recorded the broken build, and the workflow file at the tag can never carry inputs added after it. Dispatched from main it takes the WORKFLOW from main and the SOURCE from the tag, publishes to the stable repo at a higher pkgrel, and replaces the release-page assets (prune_release_assets: upsert replaces by NAME, and a rebuild's filenames differ, so the superseded package would otherwise stay one click away). Verified on a real ffmpeg-9 box (.21, CachyOS) rather than reasoned about: the gate rejects the published 0.25.0-1 host with the user-visible error verbatim, and passes client, web, scripting and gamescope — 0 false positives across all five artifacts. The parity snippet reads today's `provides` correctly (`-Si --dbpath` on an empty db works; pacman does not wrap fields when piped). Version logic exercised on all four paths: rebuild -> 0.25.0-2 stable, tag push and canary unchanged, pkgrel=1 refused. Ships as punktfunk-host 0.25.0-2. README gains the pacman error and what to do about it; CHANGELOG says plainly that 0.25.0's Arch packages were wrong.	2026-08-08 10:34:11 +02:00
enricobuehler	fa2bcd9dbb	docs(release): the last three PRs — FFmpeg 9, the Arch soname trap, and the Linux buffer ceiling that was defeating A/V sync	2026-08-08 02:43:46 +02:00
enricobuehler	cacfe04a93	docs(release): the commit count catches up with main (327 -> 395)	2026-08-08 01:41:09 +02:00
enricobuehler	959d3eb604	docs(release): A/V sync takes a TL;DR slot, and the old audio claim was wrong ... main moved another 62 commits (a8a4b11f -> fca9f42c), taking 0.25.0 to 391 since v0.24.0. Five PRs: decode aliasing (#102), A/V sync (#101), gyro correctness (#99), web console sweep (#100), Apple ATS (#103). THE CORRECTION THAT MATTERED. The notes carried "Audio that falls behind the picture pulls itself back … Android was worst, with no correction at all", describing the jitter ring's buffer-shedding as if it were sync. It never was. The host has stamped `pts_ns` on every audio datagram since long before v0.24.0 and EVERY CLIENT DECODED IT AND NEVER READ IT — verified in the v0.24.0 tree (`crates/punktfunk-host/src/native/audio.rs:162` stamps it; the client audio paths ignore it). Lip-sync was an emergent property of buffer depth, and it got WORSE as video got faster, which is why shaving milliseconds off the audio budget had never helped. That bullet is rewritten to say what is actually true, and A/V sync takes a TL;DR slot. It displaces the settings-BOM bullet, which was the weakest of the six as a HEADLINE: conditional (only if the file was ever saved by PowerShell), partly duplicated by the Windows non-C: entry, and it survives verbatim in Fixed. A/V sync affects every user, every session, every client, with sound on — and unlike most of this release it shipped broken in EVERY release we have ever made. GYRO NEEDS AN UPGRADE NOTE, so it got one. The pipeline was wrong end to end and is now measured against a real controller, which MOVES AIM SENSITIVITY: a pad presented as a DualShock 4 reported gyro 40x fast (host-side), and a PlayStation pad on Android reported ~30% short (client-side). At 40x nobody could have compensated — gyro aim was unusable, not miscalibrated — but the Android ~1.4x change is exactly the size a real person tunes around, so `## Before you update` names it specifically. DELIBERATELY NOT PROMOTED. The decode-aliasing program (#102) reads like a catastrophe — H.264 decoding into a surface it predicted from on 297 of every 300 access units of every stream we emit, on both rungs — but it NEVER SHIPPED: `git ls-tree v0.24.0 crates/` has no pf-vkdecode/pf-dxvadec/pf-vaadec/pf-bitstream. It is a ship-blocker that was cleared, and writing "your picture was subtly wrong" would be false for every reader. It contributes one clause to the decode entry (every path is now checked frame-by-frame against a reference decoder; Windows + Intel AV1 routes through Direct3D) and a full section in the changelog. Same reasoning already applied to #96 and the rav1d abort. Changelog gains the A/V sync mechanism (including that video is the master and continuity outranks sync — the ring refuses a sync request that would break audio on a jittery link) and the aliasing section, with the four independent reasons four gates missed it: a structurally-blind conformance vector, a test that had encoded the bug AS CORRECT, a vacuous assertion that could not fail, and the fact that it streamed clean on glass. gpu_parity is 11 legs, not the 9 an earlier note claimed. Verified after the merge: lock diff versions-only 35/35, `cargo metadata --locked` resolves (39 members), `cargo fmt --all --check` clean in both workspaces, notes body 0 internal-vocabulary hits, Play notes 497/500 by android.yml's own gate. Wire 2, C ABI 17, no new capability bits in this range.	2026-08-08 01:36:53 +02:00
enricobuehler	4c587ef531	docs(release): split the technical half into CHANGELOG.md, and lead with a TL;DR ... main went from 35ba64ca to a8a4b11f while this branch sat open — 190 more commits, taking 0.25.0 to 327 since v0.24.0 and making it the largest release so far. That scale is what forced the restructure. THE SPLIT. Through v0.24.0 the engineering detail lived in an `## Under the hood (for developers)` section at the bottom of the notes. It had grown to 21 dense bullets sitting under the user-facing half — the exact burying the voice rules exist to prevent, and it would only have got worse here. So: * `CHANGELOG.md` at the repo root is now the technical half, newest release first. It opens with a version table that lists every protocol number INCLUDING the unchanged ones, because "did the driver protocol move?" is the question an embedder most often needs answered and "no" is a real answer. Then breaking changes, capability bits, wire planes, env vars, and the rest. * `docs/releases/vX.Y.Z.md` keeps a short `## For developers` pointer and otherwise contains no internal names at all. * The link targets the file AT THE TAG, not at main. A release's notes are frozen; a main link would silently start describing a later release. * README.md and TEMPLATE.md now document this as the ritual rather than leaving it a one-off, including a new rule 7 requiring the TL;DR. The notes are SHORTER than before the merge — 83 lines against 108 — while covering three times as much. That is the point. TL;DR, six bullets: FFmpeg gone from the desktop clients; AV1 at 4K shipping half of every frame; HDR/10-bit leaving half the encoder idle; Windows hosts minting their own audio devices; the controller sweep; and settings silently resetting. The last bullet points at `## Before you update` rather than restating it. WHAT I DELIBERATELY DID NOT PROMOTE. #96 (HEVC DPB) and the rav1d half of #97 are ship-blockers for the NEW decode stack, not live field bugs — verified, `git ls-tree v0.24.0 -- crates/` has none of pf-vkdecode/pf-bitstream/pf-dxvadec/ pf-vaadec and `dpb_limit` did not exist at the tag. Nobody on a released build has ever hit them. They are in Fixed and in the changelog, not the TL;DR, which is reserved for things a reader is living with today. (A memory note claiming shipped 0.24.x clients carry the HEVC bug was wrong and has been corrected — it was about to drive a release decision.) Also kept out of user-facing Fixed: the plugin-UI empty panel (fixes the origin split from earlier in THIS release, so it folds into that change — but its 47993 firewall consequence IS in `## Before you update`, because an upgraded host keeps a 47992-only rule and every plugin interface goes blank), and the pad-audio WASAPI path fix (repairs a Windows build break in never-shipped code). HONESTY CARRIED FORWARD rather than smoothed. The notes say plainly that the Android overlay change did not make the stream faster, that nothing is recoverable from the Windows non-C: settings loss, that Deck HDR still needs Steam's own display setting, and that VB-CABLE should be left installed. The changelog's verification section says the FFmpeg-deletion milestone never executed on a GPU, pf-vaadec has never decoded a frame anywhere, openh264 has never run on glass, and controller audio has never touched a real DualSense. Play's "What's new" refreshed and re-fitted: swapped the TV-profiles line for the safe-area/notch fix, which is visible to every modern phone user. First draft came out at 525 chars; trimmed to 497/500, verified with android.yml's gate logic. Re-verified after the merge (Cargo.lock conflicted — took main's and regenerated the bump): lock diff versions-only 35/35 against origin/main, `cargo metadata --locked` resolves (39 members; fec-rs, pf-driver-proto, usbip-sim and the newly vendored cros-codecs keep their own versions), `cargo fmt --all --check` clean in both workspaces, doc lazy-continuation scanner 0 hits over 579 files, notes body 0 internal-vocabulary hits above `## For developers`. Wire 2. C ABI 14 -> 17 (15 rumble floor, 16 pad audio, 17 session end reason). Driver protocol 6 and gamepad channel 3 untouched. host_caps is down to its last free bit (0x80) and video_caps has been full since 0.23.0 — both now stated in the changelog rather than left to be rediscovered.	2026-08-07 20:24:08 +02:00