13 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	c817e4bec0	fix(pf-vdisplay): a CAPPED compositor refuses /proc/exe — NixOS+KDE still undetectable ... v0.27.0 resolved the nixpkgs wrapper decoration (`.kwin_wayland-w`) through `/proc/<pid>/exe`. On the box that fix was written for, the kernel refuses that link. Reading `/proc/<pid>/exe` is not gated on owning the process: `cap_ptrace_access_check` requires the reader's effective set to be a superset of the target's PERMITTED set. NixOS's own Plasma module ships `security.wrappers.kwin_wayland = { capabilities = "cap_sys_nice+ep"; }`, and our host must stay uncapped — a capability is precisely what makes it unidentifiable to KWin (#136). So the two traps compose: the name NEEDS `exe` because nixpkgs wrapped the binary, and `exe` is DENIED because NixOS capped it. `detect_active_session` went back to `ActiveKind::None`, and every connect died `no usable compositor` with `wayland="-"` — the identical signature to the bug #158 fixed, which is why a box worked around with a decoy process broke again when the decoy went away. `match_name` now falls through to `argv[0]` (`/proc/<pid>/cmdline`) when `exe` is unreadable. It reads correctly for the same reason `ps` does: make-wrapper's wrapper `exec -a "$0"`s the hidden binary, so `argv[0]` survives the decoration `comm` does not. It is consulted LAST and never overrides a readable `exe` — it is the process's own claim about itself, and a same-uid process can set it to anything; the worst a spoof achieves is aiming detection at a backend that then fails its own availability probe. MEASURED (Linux 6.x, same-uid reader, target holding cap_sys_nice), for a file capability and for the ambient form `security.wrappers` actually uses — identically: /proc/<pid> owner ✅ real uid (so the uid filter upstream was never the problem) comm ✅ readable (decorated + truncated, unusable alone) exe ❌ EACCES cmdline (argv[0]) ✅ readable End-to-end against a LIVE capped, `.kwin_wayland-wrapped` process, old resolver vs new, both extracted verbatim from their own sources: v0.27.0 answers `.kwin_wayland-w` (no match) in both capped scenarios and `kwin_wayland` uncapped; the fixed one answers `kwin_wayland` in all three. Also reached by the same rung: gamescope carries `cap_sys_nice` on a number of distros, so a wrapped-and-capped gamescope was equally invisible to the foreign-gamescope probe. Tests are fixture-driven (a temp dir with `comm`/`exe`/`cmdline`), for the reason #158 documented: a renamed `/bin/sleep` stand-in dies instantly on multi-call coreutils and reads exactly like the resolver being broken. 11 tests extracted verbatim and executed on Linux as a non-root user — 0 failures. `cargo fmt --check` and `scripts/xcheck.sh linux clippy` (`--all-targets`) clean. Refs #158, #136.	2026-08-10 23:23:59 +02:00
enricobuehler	147bc82130	chore(release): bump workspace version to 0.27.0 ... 87 commits since v0.26.0. The number is forced rather than chosen: the C ABI moves 17 -> 18, and `scripts/ci/pf-version.sh` already reports PF_BASE=0.27.0. Fills in what `docs/releases/v0.27.0.md` and the `## v0.27.0 — in development` CHANGELOG section deferred to the bump -- the lead-in, the TL;DR, "Before you update", the version table and the commit count -- and merges in the work that landed without notes: the Windows Xbox HID pad, the Apple console-UI batch, and the v0.26.0 field repairs. Everything already accumulated on main is kept as written. Version table, all re-derived at HEAD rather than read off the diff: * wire 2 (unchanged), C ABI 17 -> 18 (ADDED symbol, not widened) * crate dirs 26 -> 27 (`punktfunk-encode-worker`), 39 members * gamescope `+pfhdr4` -> `+pfhdr5` (6 patches -> 7, the PipeWire UAF), pkgrel resets to 1 * driver proto 6, gamepad channel 3, plugin index 1, SDK 0.1.4, plugin-kit 0.4.0 -- all unchanged * `api/openapi.json` stays 0.25.0: it moves only on an API EDIT, and the last one (`6cffe29b`) predates the v0.26.0 tag. It is not a mechanical per-release bump. ⚠ `crates/pf-driver-proto` is NO LONGER byte-identical to the previous release -- it was through both v0.25.0 and v0.26.0, and the last two CHANGELOGs told packagers so. Three additive `device_type`s. Called out explicitly so a packager who has been skipping it stops. The Play whatsnew names the one real Android change (the OLED palette is Eclipse now; display name only, the stored `oled` id is unchanged so saved choices carry over) and is otherwise explicit that the release is host-side. `docs-site/.../running-as-a-service.md` claimed "0.26.0-2 revoked it everywhere". No such version exists -- the Arch registry goes 0.26.0-1 straight to 0.27.0 canaries -- and the corrected 0.26.0 packages shipped under the SAME version string, which is exactly why a machine that installed an early one was never offered the fix. Reworded to say that, since it is the reason this release matters to those users. Gates, all green on this commit: * `cargo fmt --all --check` clean * `cargo metadata --locked` resolves * `Cargo.lock` diff versions-only -- 72/72 changed lines, 36 crates * Play gate's own python3 arithmetic: 400/500 CHARACTERS, not byte-identical to any other release (`wc -c` misleads -- `•` is 3 bytes) * notes voice check: 1 hit, reviewed and kept -- `getcap /usr/bin/punktfunk-host` is a command the reader runs, the same class as the `usermod` line v0.26.0's notes carried * `docs-site` builds NOT DONE: no tag yet.	2026-08-10 20:51:45 +02:00
enricobuehler	1befa8a2c4	docs(nix): bring the Nix docs in line with the module, and fix a stale claim they shared ... There are three places Nix is documented — the public docs-site, packaging/nix/ README.md, and packaging/README.md — plus the changelog. All had drifted. STALE CLAIM, and not only for Nix. install.md said the plugin runner's "user unit ships **disabled** — enable it once you have" something to run. That is true only of Arch and source installs: the deb postinst and RPM %post both `systemctl --global enable punktfunk-scripting.service`, and the Bazzite sysext bakes in a default.target.wants symlink (build-sysext.sh:113). bazzite.md carried the same claim about its own image. Both corrected, per channel, with the reason the default flipped — the library scanners are plugins, so a host without the runner can come up with an empty library — and the `mask`-not-`disable` opt-out the sysext's own comment documents. docs-site: * install.md NixOS — `desktopSession` in the example and explained, the runner no longer needs enabling, and the host/console line says what autoStart does. * running-as-a-service.md — "Restart the host with your desktop" documented the drop-in for packaged installs only; NixOS gets its one-liner beside it. * bazzite.md — the runner is started for you, not "isn't started". packaging/nix/README.md: * option tables gain `desktopSession`, `gamescopeHdr`, `gamescopePackage`, and the `punktfunk` group next to `input` (both are required — the udev rule chgrp's the vhci nodes and fails outright if the group was never created). * "what the module configures" gains the security.wrappers entry, and a note on why the capability sits on the encode worker and never on the host: a wrapper raises it into the ambient set, which lands it in the permitted set and fails KWin's /proc/<pid>/exe readlink identically to a file capability. * the appliance snippet no longer tells you to put pkgs.gamescope on PATH — gamescopeHdr does that with the patched build, and desktopSession is called out as the thing to leave off there. * a caveat recording that `nix flake check` does not check the module, and the two rules for editing module-check.nix (assertions stay pure Nix; assert list-valued unit fields on the lists, not the rendered text). packaging/README.md: the flake ships five packages, not "host + client". CHANGELOG.md v0.27.0: a NixOS section covering the comm/session-detection fix, the module changes including the scripting default flip as an explicit behaviour change, and the flake-check gap — plus the documentation bullets above.	2026-08-10 20:24:21 +02:00
enricobuehler	f26d21125d	docs: the capability moves to the encode worker, and the host must never be given one ... Rewrites the "GPU scheduling priority" section around the split: punktfunk-encode-worker carries cap_sys_nice=ep, punktfunk-host carries nothing on any channel, ever. The KWin identification mechanism is spelled out in plain words and the failure line is quoted verbatim ("KWin does not expose zkde_screencast_unstable_v1 to this client") so someone searching for their symptom lands on the explanation. The warning names all three ways an operator would reach for the capability — hand setcap, a systemd AmbientCapabilities= line, a NixOS security.wrappers entry — because all three put it in the same permitted set and all three cost KDE desktop streaming. That is the failure mode that made this worth documenting: it looks exactly like a missing .desktop and survives reinstalling both ends. configuration.md gains PUNKTFUNK_ENCODE_WORKER (path, or `off` to force the in-process encoder) and re-describes PYROWAVE_QUEUE_PRIORITY as an intent forwarded to whichever process does the encode. kde.md gains one line on the troubleshooting bullet someone actually lands on: getcap on the host must print nothing. The published 0.26.0 notes are deliberately untouched — they are the record of what shipped. The flipped phrasing lives in v0.27.0's notes instead; v0.26.0.md:37 ("a system privilege that turns out to stop KDE recognising the host at all") is the line that goes stale when this ships.	2026-08-09 12:51:01 +02:00
enricobuehler	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