24 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	bbbcf321e5	Merge origin/main into worktree-native-decode-m0 ... main moved 93 commits while this branch ran. Two conflicts, both where main's new work sat next to M10's excision: packaging/flatpak/io.unom.Punktfunk.yml — main added the vendored gamescope WSI layer (the only route to HDR on a Deck) and, before it, a vulkan-headers module. Took both: this branch predates them and deletes neither. But the headers module's stated consumer was pf-ffvk's bindgen over FFmpeg's hwcontext_vulkan.h, and M10 deleted pf-ffvk — so it now reads as dead weight to the next person. It is not: the WSI layer IS a Vulkan layer, compiles against those headers, and builds after it, so module order is the dependency. Rewrote the rationale to say so, including why dropping it would be expensive to discover — flatpak.yml has no pull_request: trigger, so a manifest break reaches main invisibly and a tag then ships no Linux flatpak. Also recorded that the native decoder needs nothing from there: pf-vkdecode reaches Vulkan through ash, which is pure Rust bindings, no bindgen, no C headers. crates/pf-console-ui/src/screens/settings.rs — main restructured the gamepad settings into TABS, which removed the per-row section headers; this branch had left Some("Video") untouched from the merge base and added the pre-M10 decoder migration next to it. Git could not tell those apart. Took main's structure (no header, its deliberate change) with this branch's migration layered on: a stored `vulkan`, `vaapi` or `d3d11va` names no preset in the tabbed list and would render as "—", then silently rewrite the user's preference on the next save. Gates on the merged tree, Linux container: fmt clean; cargo check --workspace --all-targets clean; clippy --workspace --all-targets -D warnings clean; tests green across pf-vkdecode (187), pf-client-core (163), pf-console-ui (58) and punktfunk-host (447 of 448 — the one failure is the pre-existing gamestream::stream::tests::sender_delivers_batches, a UDP-loopback EINTR under qemu that fails identically on a pristine HEAD).	2026-08-07 10:50:32 +02:00
enricobuehler	5c05246098	feat: M10 — FFmpeg is gone from the client ... cargo tree -p punktfunk-client-session finds no ffmpeg. The host still does, which is the whole point: pf-encode keeps libavcodec unconditionally and no host workflow, packaging script or licence file was touched. Deleted: crates/pf-ffvk, video_vulkan.rs, video_vaapi.rs, video_libav.rs, the libavcodec half of video_d3d11.rs, the av_log machinery, ffmpeg::codec::Id as the decoder's vocabulary (the quic CODEC_* wire constants now serve, which is why the evidence table was keyed on them), DecodedImage::VkFrame and ::Dmabuf, the presenter's AVVkFrame lane, and the ffmpeg-fallback feature with everything behind it. DrmFrameGuard collapses from an enum to a newtype, which removes an unsafe impl Send. Roughly 25,000 lines. Then the CI, packaging, licensing and docs work the plan's §6 lists: the Windows workflows lose FFMPEG_DIR, PF_FFVK_VULKAN_INCLUDE and their PATH prepend; the MSIX loses its DLL wildcard; the client .deb stops emitting libav sonames on its own because depends come from dpkg-shlibdeps; arch, flatpak and nix drop the dependency; and the README's "FFmpeg 7 or 8" contract narrows to the host. Three defects reached users' machines in the first cut, and none was in the deletion itself. All three desktop Settings UIs offer vulkan, vaapi and d3d11va as stored decoder values, so those strings sit in shipped settings files today. Refusing them by name — which is the correct rule for a stale pin — would have bricked every upgraded client whose owner ever touched that dropdown. They now migrate onto the native rung for the same hardware family, at decoder construction AND at each dialog's lookup, because a legacy value that matches no preset displays as "Automatic" and silently rewrites the user's preference on the next save. M9's evidence filter was deleted on the argument that with no libavcodec twin below, barring an unproven rung removes hardware decode rather than moving down one rung. That is true on Windows and false on Linux for Intel and every unknown vendor id, where prefer_vulkan_first is false and the order is native-vaapi → native-vk: a rung that has decoded nothing anywhere sitting above one that is 250/250 on three drivers. Every Intel Linux desktop would have moved from libavcodec VAAPI, shipping for years, onto pf-vaadec by default — and a rung that constructs and then produces wrong pixels leaves only by the error-streak demotion, which this codebase already documents as not tripping on the B580's strobing. The filter is restored as a narrow, pure, testable rule: an unproven rung yields to a proven one, and to nothing else. Windows deliberately passes no rung below, because that vendor family is the one with a measured wrong-pixel report against Vulkan decode, and trading no evidence for evidence of corruption is the wrong direction. And the notices still said FFmpeg was bundled. The root file is what both desktop clients include_str! and what the MSIX ships, three lines under the new card saying no FFmpeg is bundled; Apple's Acknowledgements said it too, on iOS, tvOS and macOS. The generator now emits four per-client files scoped by transitive closure — 0 FFmpeg mentions in each, verified — while the root file keeps it for the host. That also ends the standing false attribution of ffmpeg-next, GTK4, windows-rs and the NVENC SDK to an iPhone. Windows has no reachable box, so it was compiled instead: a cross clippy at -D warnings on x86_64 and aarch64-pc-windows-msvc with the C toolchain stubbed so build scripts run without linking. That gate immediately caught an include_str! path one directory too deep, which nothing else could have. Gates: container clippy -D warnings, 160 tests, workspace check, both Windows targets clean, client ffmpeg count 0 and host 2. The four decode crates are untouched, so the hardware rungs' 250/250 stands. ⚠ Owed and unrun: no GPU has executed any of this milestone. M8's on-glass software check, M7's D3D11 and VAAPI AV1 hardware legs, and M9's field bake all still want hardware, and the bake window and criteria remain the user's.	2026-08-07 08:58:47 +02:00
enricobuehler	25b08916b6	fix(flatpak): the WSI layer module builds again — vkroots was declared twice ... The flatpak has not built since 35ba64ca. Every push to main fails at "Build the flatpak", before a single build command runs: cp: cannot overwrite non-directory '.../build/gamescope-wsi-layer-1/subprojects/vkroots/.git' with directory '.../git/https_github.com_Joshua-Ashton_vkroots.git' Error: module gamescope-wsi-layer: Child process exited with code 1 vkroots was declared twice. flatpak-builder clones git sources WITH SUBMODULES by default, and `subprojects/vkroots` is a real gamescope submodule — `git ls-tree 8c676c39 subprojects/` shows it as mode 160000 at 5106d8a0, which is byte-for-byte the commit the explicit source pinned. So the submodule checkout already produced the right tree and left `subprojects/vkroots/.git` as a gitlink FILE; the second, redundant source then tried to copy the bare mirror onto that path as a DIRECTORY, and cp refused. Source extraction died there — `buildsystem: simple` and the hand-applied glm/stb patch_directory copies were never reached, so neither is at fault. Removing the redundant source is therefore a no-op on the resulting tree: the submodule supplies that exact rev. glm and stb are NOT submodules — `subprojects/ glm.wrap` and `stb.wrap` are plain blobs at that rev — so nothing else populates them and their explicit sources have to stay. That asymmetry is the whole trap, and it is now written down in the manifest next to the sources, along with the disable-submodules escape hatch for anyone who later needs to pin a subproject away from the gamescope rev. Why this reached main: flatpak.yml has no `pull_request:` trigger — only `push` on main with path filters, `tags: ['v*']`, and workflow_dispatch. PR #64's checks were green because the flatpak was never built on the PR; run 15775 was the first time this module had ever been built in CI. Adding a PR trigger (or a manifest lint) is the durable follow-up, deliberately not bundled here. This blocks the release, not just main. flatpak.yml runs on `tags: ['v*']`, and the failing step gates the bundle export, the generic-registry publish, the OSTree push to flatpak.unom.io and the release-asset attach — all of which stay skipped. A v0.25.0 tag cut today would ship with NO Linux/Steam Deck flatpak at all, on the release whose headline Linux change is Deck HDR working out of the box. NOT VALIDATED LOCALLY: this cannot be built on macOS. The reasoning is confirmed against the upstream tree (the ls-tree above) but the green run is still owed — dispatch flatpak.yml on this branch before merging.	2026-08-06 00:49:25 +02:00
enricobuehler	5f71aeb024	feat(flatpak): vendor the gamescope WSI layer so Deck HDR works on a plain install ... HDR on a Deck needed a manual second step nobody took: flatpak install --user flathub org.freedesktop.Platform.VulkanLayer.gamescope//25.08 documented only in a comment in this file. Build the layer ourselves instead, so a plain `flatpak install` is all it takes. The layer is genuinely required, not legacy. Measured on SteamOS 3.8.16 (gamescope 3.16.23.4): the gamescope-0 socket advertises gamescope_swapchain_factory_v2 but NOT wp_color_manager_v1, with HDR both off and on — so Mesa's Wayland WSI has no colour-management protocol to negotiate HDR10 through, and this layer is the only thing that can append the ST.2084 surface formats. Removing the extension gives zero [Gamescope WSI] lines and hdr10_format=None. Vendored rather than declared via add-extensions autodownload: the extension is 94 MB of whole-gamescope for one 4 MB .so, its layer JSON hardcodes a /usr library_path that an app-scoped extension mounted under /app would not satisfy, and it would make flathub a hard install-time dependency of an app we self-host on flatpak.unom.io. enable_gamescope=false skips subdir('src') and every compositor dependency, so only protocol/ and layer/ build. buildsystem is simple rather than meson because glm and stb ship no meson.build of their own - the wraps' patch_directory supplies it, and without that copy configure dies with "Subproject exists but has no meson.build file". meson generates the layer JSON from prefix+libdir, so it self-writes library_path=/app/lib/... into /app/share/vulkan/implicit_layer.d, which XDG_DATA_DIRS already covers. VK_ADD_IMPLICIT_LAYER_PATH is therefore dropped - keeping it would also risk double-loading two same-named layers for anyone who still has the flathub extension installed. Pinned to the same gamescope rev as packaging/gamescope/PKGBUILD so the client's layer and the host's punktfunk-gamescope come from one tree. Verified on a Deck OLED: builds offline (--wrap-mode=nodownload) in org.gnome.Sdk//50, and the resulting .so drives the Deck's system gamescope to "hdr formats exposed to client: true" with hdr10_format=Some(A2B10G10R10_UNORM_PACK32, HDR10_ST2084_EXT). Still user-side, and not fixable in packaging: gamescope's hdr_enabled convar (Steam's HDR display setting) must be on.	2026-08-06 00:15:16 +02:00
enricobuehler	e1adc5d6d7	fix(flatpak): export GAMESCOPE_WAYLAND_DISPLAY so the Deck actually gets HDR ... The gamescope WSI layer decides whether to engage from one signal: isRunningUnderGamescope() reads $GAMESCOPE_WAYLAND_DISPLAY and nothing else. flatpak does not forward host env into the sandbox, so it arrived unset and the layer's CreateInstance early-returned before creating a GamescopeInstance — no gamescope surface, so the HDR10/ST.2084 formats were never appended and the surface stayed SDR. The layer still loads and still logs its generic bits in that state, so it reads as working. It is not: the three settings already here (layer search path, ENABLE_GAMESCOPE_WSI, the socket bind) all sit downstream of this gate and buy nothing without it. Measured on a Deck OLED (Galileo, SteamOS 3.8.16), client --browse, reading "swapchain config": unset -> no [Gamescope WSI] Surface state block, None set, hdr_enabled=0 -> server hdr output enabled: false, None set, hdr_enabled=1 -> hdr formats exposed to client: true, Some(A2B10G10R10_UNORM_PACK32, HDR10_ST2084_EXT) Matches the field report of "HDR->SDR" in the stats overlay on a correct HDR host. DXVK_HDR was ruled out by measurement. The remaining gate (gamescope's hdr_enabled convar = Steam's HDR display setting) is a user-side step, not a packaging one.	2026-08-05 23:59:45 +02:00
enricobuehlerandClaude Opus 5	cec3955872	feat(client/linux): the app icon reaches About — and the launcher, which never had it either ... Adding the icon to the About dialog turned out to be one line and a missing install: the icon existed, but only the flatpak ever shipped it. The deb, rpm, arch and nix entries all carried `Icon=video-display` — a stock monitor glyph — so on every non-flatpak install the launcher, the taskbar and the window switcher have been showing a generic icon this whole time. About would have shown the same nothing. So the icon moves out of `packaging/flatpak/` into `packaging/linux/icons/hicolor/` beside the tray icons, which is where a shared asset belongs, and all five packagings install it to the same hicolor path. The desktop entry names the app's own icon, and `AboutDialog` names the app id — one identity resolved through the icon theme rather than a path anyone has to keep in step. A `PUNKTFUNK_SHOT_SCENE=about` scene comes along so the dialog is capturable like every other surface; that is how the icon above was verified to actually resolve rather than silently falling back. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:38:53 +02:00
enricobuehlerandClaude Opus 5	bf98102714	feat(packaging): ship punktfunk everywhere, and deprecate the session's stray pairing flag ... The rest of C1. A CLI that only exists in a dev tree is not a door anyone can use, so it now builds and installs in deb, rpm, arch, nix, flatpak and MSIX alongside the client and the session. On Windows it gets its own `AppListEntry="none"` application with the alias `punktfunk.exe` — a command, not a Start-menu tile — which is what the Playnite importer will shell to for `punktfunk library <host> --json`. `punktfunk-session --pair` prints a deprecation notice and forwards. Pairing is a trust ceremony and belongs to the brain, fronted by `punktfunk pair` or a shell; a renderer owning one is precisely the mixing of concerns this split exists to undo. It keeps working for a release, because someone's provisioning script is calling it today. Decky's invocations are untouched and verified still working (`--list-hosts` JSON shape unchanged, `--reachable` exit codes unchanged): those flags are a frozen compat contract until Decky migrates to the verbs at its own pace. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 01:16:17 +02:00
enricobuehlerandClaude Opus 5	6cf5d4ab87	feat(client/linux): punktfunk:// links open the GTK client ... D1's activation half (design/client-deep-links.md §4.1). The client already had a `--connect` CLI, but nothing claimed the scheme, so nothing outside a terminal could start a stream: no browser prompt, no xdg-open, no double-clickable shortcut. The `.desktop` entries gain `MimeType=x-scheme-handler/punktfunk;` and `Exec=… %u`, and the rpm scriptlet joins deb and arch in running `update-desktop-database` — an entry nothing indexes claims nothing. (nix substitutes the Exec line by prefix, so `%u` survives; flatpak's exported entry is renamed to the app id by the standard mechanism.) In the app, `HANDLES_OPEN` plus a positional-URL argv is the whole mechanism, and the second half is the interesting one: argv stays withheld from GApplication as before EXCEPT when it carries a URL, and then GIO's own single-instance forwarding delivers it to the running window over D-Bus. Clicking a link with Punktfunk already open reuses that window instead of racing a second instance, and we wrote no IPC to get it. A URL that lands during a cold start (before the model exists) is parked rather than dropped — silently losing a link is the one outcome that would make the feature untrustworthy. Routing is four lines of translation, because the decisions are the brain's: parse, resolve the host, resolve the profile, refuse. A link that resolves becomes exactly the message a card click raises — the same wake, trust gate, and error surfaces — so there is no second connect path to keep in sync. A link to a host we don't know, or know but never pinned, opens the ordinary PIN ceremony seeded with what the link claimed, which is how "a URL may never pair or trust on its own" stays true while still being useful. Never preempting a live session is checked here, since only this layer knows one is running. Verified on .21 under Xvfb against hand-authored stores: `connect/Bound%20Box?launch=` resolved the host by name, carried the launch id through the trust gate, and spawned the session; `punktfunk://pair/1234` and an unknown `profile=` both refused before any dial. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 21:37:10 +02:00
enricobuehlerandClaude Opus 5	aff169e131	build(flatpak): make the manifest architecture-generic ... Two things were x86-specific, both now expressed properly instead of hardcoded: * PKG_CONFIG_PATH carries the runtime's multiarch directory. flatpak-builder does NOT shell-expand `env` values, so ${FLATPAK_ARCH} would be taken literally — a build-options.arch override supplies the aarch64 string and inherits the rest. * The prebuilt Skia archive is per-target and pinned by sha256. Two `type: file` sources discriminated by only-arches now share one dest-filename, so SKIA_BINARIES_URL stays a single literal path. Upstream publishes the aarch64 archive under the same skia commit hash and the same resolved-feature key, so the two stay in lockstep on a skia-safe bump. build-flatpak.sh gains ARCH (default: this machine's), passes --arch to both flatpak-builder and build-bundle, and arch-suffixes the bundle name so an x86_64 and an aarch64 build can coexist in dist/ instead of the second silently overwriting the first. CI composes its own published filename, so nothing downstream changes. The aarch64 Skia sha256 was verified by downloading the published archive, not taken from the API. No aarch64 flatpak has been built — flatpak-builder builds in a sandbox for the target arch, which needs an arm64 machine. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 14:32:45 +02:00
enricobuehlerandClaude Fable 5	a1e79a0d69	fix(flatpak): bind gamescope's Wayland socket for Deck Game-Mode HDR ... The Vulkan-layer env vars alone left hdr10_format=None on a Deck OLED: the FROG gamescope WSI layer loads but must open a Wayland connection to gamescope's private socket ($GAMESCOPE_WAYLAND_DISPLAY = gamescope-0) to negotiate HDR10 via the gamescope_swapchain protocol. The Deck runs games as X11 clients, so --socket=wayland binds nothing and that socket never enters the sandbox → the layer silently can't reach the compositor → PQ tone-mapped to SDR, badge dark. Bind xdg-run/gamescope-0 (as chiaki-ng does); with the layer path + ENABLE_GAMESCOPE_WSI + the socket, the surface offers HDR10 and the presenter's existing HDR10 swapchain path engages — no client code change. Harmless off-Deck (the layer no-ops with no gamescope socket to bind). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-11 03:07:50 +02:00
enricobuehlerandClaude Fable 5	35d97ae6ac	feat(windows): parallel virtual displays — proto v3 ring binding, manager slot map, group topology (W0–W3) ... design/windows-parallel-virtual-displays.md (display-management Stage 7 / §6.6): N simultaneously-live pf-vdisplay monitors, one sealed ring each, every idd-push-security invariant preserved per-ring. - proto v3: SharedHeader._pad → target_id — the ring NAMES its monitor, host-stamped before the magic; the driver publisher refuses a cross-bound ring via the shared, unit-tested frame::check_attach (new DRV_STATUS_BIND_FAIL — the gamepad pad_index validation applied to frames, invariant #10); the host's wait_for_attach surfaces the refusal loudly and self-checks its own stamp. - manager: the one-monitor MgrState becomes a slot map keyed by the client's identity slot (0 = anonymous/GameStream); per-slot reconnect + dead-WUDFHost preempts, slot-scoped begin_idd_setup (a different identity is an admission question, never a preempt), ONE device-level watchdog pinger, per-slot /display/state + /display/release. - group topology: isolate_displays_ccd takes the managed target SET (a sibling slot is never deactivated); SavedConfig + the DDC/PnP axes move to the group record (first-in captures, last-out restores); desktop layout via CCD source origins from the pure layout::arrange (auto-row default, manual pins win), re-applied on create + reconfigure. - admission: the Windows separate→reject override now sits behind the PUNKTFUNK_WIN_SEPARATE=1 validation hatch (the wedge it guarded is structurally gone — a second identity gets its own monitor + ring; default flips in W5 after soak); max_displays and NVENC session-unit budgets decline an unaffordable display AT admission; kick_dwm_compose is process-globally throttled and per-display — cursor jump + 35 ms dwell (a sub-tick jump composes nothing; DWM reads dirties from current state at the next vsync tick). On-glass on the RTX box: V1/V2/V4/V5/V6/V9 green — two paired clients on two monitors streaming ~60 fps each with zero mismatches and zero bind failures, churn-hammer clean (no 0x80070490), per-ring mode-change recreate leaves the sibling untouched, typed budget rejection, fault-injected cross-bind refused loudly with the sibling undisturbed. V7: WUDFHost-kill shared fate is clean; in-process device recovery is a known follow-up (the retired-never-closed control handles block the adapter cycle — reset-pf-vdisplay.ps1 recovers). DWM composes two IDD monitors concurrently at 60 fps — the plan's load-bearing unknown, answered yes. Also carries the client-HDR EDID forwarding that shared this working tree (Hello::display_hdr → AddRequest luminance tail → the monitor's CTA-861.3 HDR block, PUNKTFUNK_CLIENT_PEAK_NITS hatch) and the Deck client fixes (40 ms rumble keep-alive with 1-LSB jitter, HDR self-diagnosing presenter warn, flatpak HDR env). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-11 01:06:44 +02:00
enricobuehlerandClaude Fable 5	ef39050dbc	docs: repo-wide housekeeping — sync README & docs with the code as shipped ... Six parallel audits swept the root docs, docs-site, every per-directory README, and the packaging docs; every claim below was verified against the source before editing. - README: Layout gains the six missing crates (pf-client-core, pf-presenter, pf-console-ui, pf-ffvk, pf-driver-proto, punktfunk-tray), clients/session, api/ and ci/; Linux/Windows client rows reflect the shell + Vulkan-session split and the Vulkan Video -> VAAPI/D3D11VA -> software decode chains; the "every client over a C ABI" claim is corrected (Rust clients link the core directly); tiered stats overlay + console shell noted; Apple row mentions AV1. - CONTRIBUTING: drop the dead CLAUDE.md link (deliberately untracked); point at the README's build/invariants sections. SECURITY: 0.9.0. - host-cli/pairing: --allow-pairing/--require-pairing are no-op legacy names — pairing is required by default, --allow-tofu is the real flag; document --data-port and --idle-timeout-ms. - configuration: document PUNKTFUNK_RECOVER_SESSION_CMD (session-crash recovery hook), PUNKTFUNK_MDNS, PUNKTFUNK_DATA_PORT. - virtual-displays/gnome: GNOME per-client scaling shipped (host- persisted) — flip the ❌ to ✅ and describe how it works. - stats: new "Detail levels" section (Off/Compact/Normal/Detailed + per-platform cycle gestures); retire the GTK hand-off note. - clients/install-client/status/roadmap: decode chains, Windows client validation narrowed to HDR-only pending, adaptive bitrate, console shell, Apple AV1, Windows host vendor list. - Sub-READMEs: clients/linux rewritten for the re-architecture; session Windows decode rung + d3d11va knob; Windows tiered overlay; Android minSdk 28; decky file table; host zerocopy/ path; scripts port 47992 and steamos-host.md; pf-dualsense source path. - packaging: canary version bases are tag-derived (<next-minor> via pf-version.sh/.ps1), codecs-extra not ffmpeg-full, document the pinned offline-Skia tarball + SKIA_BINARIES_URL and vulkan-headers. - Convert 15 dangling design/*.md links to the punktfunk-planning prose convention (those docs live in the private planning repo). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 09:13:42 +02:00
enricobuehlerandClaude Fable 5	4c99b78366	fix(flatpak): prune pf-client-core's windows-rs git dep from the sandbox manifest — offline build broken since a69a83b5 ... The flatpak's offline cargo build has failed on every run since the D3D11VA push: pf-client-core now declares the same git-pinned `windows` dependency as the Windows client (cfg(windows)-gated, never compiled on Linux), and `cargo --offline` needs every DECLARED dependency's source just to build the unit graph — but windows-rs is deliberately not vendored into cargo-sources.json (flatpak-builder would full-clone the multi-GB repo; the reason prune-windows-lock.py exists). Removing the workspace member alone no longer covers it. New packaging/flatpak/prune-windows-toml.py (dependency-free, like its lock sibling) strips windows-rs git entries from a manifest in place — single- or multi-line — and the flatpak manifest runs it on crates/pf-client-core/Cargo.toml right after the existing clients/windows member sed. Registry deps in the same cfg(windows) table (wasapi, sdl3) are kept; they vendor normally. Verified in a scratch worktree with both prunes applied: the TOML stays valid and `cargo metadata` resolves ZERO windows-rs packages and zero git-source declarations — nothing left for --offline to fetch. End-to-end proof is the flatpak CI run on this push. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-09 12:52:26 +02:00
enricobuehlerandClaude Opus 4.8	0052a6ae30	fix(packaging): vulkan-headers build dep + ship punktfunk-session across desktop packages ... The re-architecture split the Linux client into two binaries (shell + Vulkan session streamer) and added the pf-ffvk crate, whose build.rs runs bindgen over FFmpeg's libavutil/hwcontext_vulkan.h (#include <vulkan/vulkan.h>). Two release regressions fell out of that on the desktop-package legs: 1. Missing build dep. The Arch build (archlinux:base-devel + its own pacman list) fatal-errored at `vulkan/vulkan.h file not found`. Add the Vulkan dev headers wherever the client compiles from a self-managed dep set: arch (PKGBUILD makedepends + arch.yml), rpm (spec BuildRequires + rpm.yml + fedora image), deb.yml (belt-and-suspenders; the rust-ci image already bakes libvulkan-dev), and the screenshots job. The flatpak builds offline against the GNOME SDK, so install Vulkan-Headers into /app as a pinned module and point pf-ffvk's bindgen at it via PF_FFVK_VULKAN_INCLUDE. 2. Only the shell shipped. arch/deb/rpm built and installed just punktfunk-client; the shell execs its sibling punktfunk-session for a connect, so desktop streaming would break exactly as Decky's did. Build and install BOTH binaries in all three, and declare the runtime Vulkan loader the session binary dlopens (vulkan-icd-loader / vulkan-loader / libvulkan1 — not a DT_NEEDED, so shlibdeps/auto-requires can't see it). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-07 23:41:10 +02:00
enricobuehlerandClaude Opus 4.8	b2451e6aea	fix(flatpak): ship punktfunk-session so Decky streaming survives the two-binary split ... The re-architected Linux client is now two binaries: the punktfunk-client shell execs its sibling punktfunk-session (ash/Vulkan presenter + Skia console UI) for --connect/--browse. The Decky plugin's stream and browse paths launch the shell with exactly those flags, but the flatpak built and installed only the shell, so streaming and the gamepad library from the Deck failed at exec with "punktfunk-session: No such file" (pair/wake/library still worked — the shell handles them in-process). Build and install both binaries. The session binary pulls in Skia (skia-safe), whose build script downloads a prebuilt libskia — dead in the offline sandbox — so point skia-bindings at a pinned, vendored archive via SKIA_BINARIES_URL=file:// (read directly, no curl); the tarball rides along as a sha256-pinned flatpak source. Widen the flatpak CI path filters to the session binary's crates (linux-session, pf-presenter, pf-console-ui, pf-client-core) and fix the moved library.rs path in the Decky error-classifier comment. All other plugin↔client contracts (flags, pairing/library output, config files, env vars, exit codes, the 47990 mgmt port) already match — no changes needed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-07 23:14:08 +02:00
enricobuehlerandClaude Opus 4.8	c9ed49b4c2	fix(flatpak): drop --socket=pipewire (unknown to the builder) — keep the xdg-run bind ... The v0.7.2 flatpak build failed: `error: Unknown socket type pipewire` — this flatpak-builder toolchain (and the Deck's flatpak 1.16 override CLI) don't accept --socket=pipewire. --filesystem=xdg-run/pipewire-0 binds the same native socket and is the portable form already validated on-Deck (pipewire-0 appears in the sandbox, client audio node registers, no pw-connect error). Keep only that + --socket=pulseaudio. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-04 09:20:52 +00:00
enricobuehlerandClaude Opus 4.8	d1af6304c7	fix(flatpak): expose native PipeWire socket so client audio works ... The Linux client speaks the native PipeWire protocol (audio.rs `pw connect`), but the manifest granted only --socket=pulseaudio, so the sandbox had just `pulse/native` and no `pipewire-0`. Playback + mic both died with "pw connect (is PipeWire running in this session?)" — reproduced live on a Steam Deck in Gaming Mode (no client audio node ever appeared). Add --socket=pipewire (canonical) + --filesystem=xdg-run/pipewire-0 (portable bind of the same socket). Validated on-Deck via a `flatpak override --filesystem=xdg-run/pipewire-0`: pipewire-0 then appears in the sandbox and the client registers its "punktfunk-client" PipeWire node with no pw-connect error. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-04 08:59:11 +00:00
enricobuehlerandClaude Opus 4.8	8b87274958	fix(flatpak): pass stable branch to build-bundle (matches --default-branch) ... The CI added --default-branch=stable, so the repo ref is app/io.unom.Punktfunk/x86_64/stable. build-bundle defaults to `master` when no branch is given → "Refspec app/io.unom.Punktfunk/x86_64/master not found". Pass `stable` explicitly in both flatpak.yml and the local build-flatpak.sh. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-18 21:48:17 +00:00
enricobuehlerandClaude Opus 4.8	c358b510e5	feat(flatpak): host a signed OSTree repo at flatpak.unom.io for flatpak update ... The CI only shipped a single-file .flatpak bundle, which has no remote — users couldn't `flatpak update`. Keep the bundle (Decky fallback) but also sign the OSTree repo flatpak-builder already produces and publish it to a shared, reusable unom-wide remote. - flatpak.yml: pin --default-branch=stable; import the signing key and build-update-repo --gpg-sign; generate unom.flatpakrepo + the app .flatpakref + index.html; rsync the repo to unom-1 and bring up a static Caddy container. The step no-ops until FLATPAK_GPG_PRIVATE_KEY/DEPLOY_* exist (build stays green). - packaging/flatpak/server/: compose.production.yml + Caddyfile (static file server on :3230, mirrors docker.yml deploy-docs). - unom-flatpak.gpg: committed public signing key (base64 -> GPGKey= in the descriptors). - README: hosted repo is now the recommended install; documents the one-time infra (edge Caddy vhost, infra port 3230, DNS, the GPG secret). Edge Caddy vhost + infra port allowlist + the secret are applied out-of-band. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-18 21:07:27 +00:00
enricobuehlerandClaude Opus 4.8	2f2147b093	refactor: drop milestone names + consolidate clients; loss-recovery & rumble fixes ... Two bodies of work in one commit (the rename moved files the fixes also touched). Naming/structure cleanup (pre-launch): - Host modules m3.rs->punktfunk1.rs, m0.rs->spike.rs; CLI m3-host->punktfunk1-host, m0->spike; bare `punktfunk-host` now prints help. Types M3Options/M3Source-> Punktfunk1Options/Punktfunk1Source. - Clients consolidated out of crates/ into clients/: punktfunk-client-rs-> clients/probe (crate punktfunk-probe), client-linux->clients/linux, client-windows->clients/windows, punktfunk-android->clients/android/native (crate punktfunk-client-android; kept [lib] name=punktfunk_android so the JNI contract is unchanged). crates/ now holds only core + host. - Milestone codes M0-M4 purged from code/CLI/CLAUDE.md/README/docs/docs-site, kept only in docs/implementation-plan.md. docs/m2-plan.md-> docs/gamestream-host-plan.md. CI/gradle/flatpak paths updated. Client loss-recovery (video froze and never recovered after a brief drop): - Export punktfunk_connection_frames_dropped through the C ABI (the core already tracked it for the client keyframe-recovery loop; it was never reachable from the ABI clients). Regenerated punktfunk_core.h. - Apple (StreamPump + Stage2Pipeline) and Android (decode.rs) now poll frames_dropped and request a keyframe when it climbs -- the same loss-driven recovery Linux/Windows already had. Under infinite GOP the decoder silently conceals reference-missing frames, so the decode-error trigger rarely fires. Apple rumble robustness (worked then went spotty -- DualSense + Xbox): - Add CHHapticEngine stopped/reset handlers (rebuild on app background / audio interruption / server reset) and drop the permanent `broken` latch on a transient drive failure; latch only when the controller truly has no haptics. - Surface swallowed SDL set_rumble errors on Linux/Windows + diagnostic logging. Verified: cargo build/clippy/fmt --workspace, C-ABI harness, header drift. Not runnable on this box (verify in CI): Gitea workflows, gradle/Android, flatpak, Swift/decky. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-18 21:05:58 +00:00
enricobuehlerandClaude Opus 4.8	81664c0234	fix(flatpak): drop the Windows client from the workspace for the offline build ... The lock prune (4df35bd) stopped flatpak-builder full-cloning windows-rs (disk-fill), but exposed the next layer: `cargo --offline --locked -p punktfunk-client-linux` resolves the WHOLE workspace, so it still tried to load the now-un-vendored windows-rs source for the punktfunk-client-windows member (its windows-rs git deps are cfg(windows)-gated, but cargo resolves all targets regardless) and failed: "can't checkout ... you are in the offline mode". Drop the Windows client from the workspace members inside the sandbox build (sed on the copied Cargo.toml — the flatpak never compiles it) and remove --locked (the lock no longer matches the reduced member set; --offline still pins every crate to the vendored cargo-sources.json, so the build stays reproducible). android stays — it has no git deps. Verified locally: removing the member, `cargo build -p punktfunk-client-linux --offline` Finishes with zero windows-rs involvement; manifest YAML still valid. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-17 08:12:21 +00:00
enricobuehlerandClaude Opus 4.8	4df35bd026	fix(flatpak): prune microsoft/windows-rs git crates before vendoring ... The flatpak CI was failing at "Downloading sources" with "No space left on device": flatpak-cargo-generator walks the whole workspace Cargo.lock and emits a `type: git` source for the windows-rs crates (windows + windows-reactor + ~12 sub-crates, pinned by punktfunk-client-windows), and flatpak-builder then FULL-clones that multi-GB repo — for a bundle that only ever compiles `-p punktfunk-client-linux` and never touches a windows-* crate. New packaging/flatpak/prune-windows-lock.py writes a copy of Cargo.lock with the windows-rs git packages stripped (matches on the `source =` line, so a crate that merely lists a windows dependency is kept; dependency-free so it also runs on the Deck's stock python). Both the CI and build-flatpak.sh feed that pruned lock to the generator. The committed Cargo.lock is untouched — cargo --offline only needs vendored sources for the crates it actually builds, and the windows-rs crates are not in the Linux client's dependency closure. Verified locally: 14 crates pruned (507 -> 493 packages), zero windows-rs `source =` lines remain, output parses as TOML, all Linux-client deps (gtk4/ffmpeg-sys-next/sdl3/pipewire) intact. This unblocks the flatpak build carrying the VAAPI green-screen fix (a89b19a) for the Steam Deck. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-17 07:43:11 +00:00
enricobuehlerandClaude Opus 4.8	7d7b5c8611	fix(ci/flatpak): cargo-sources generator needs python3-tomlkit, not toml ... flatpak-cargo-generator.py (master) imports `tomlkit` + `aiohttp`; the workflow installed `python3-toml`, so the "Generate offline cargo sources" step would fail with ModuleNotFoundError. Install python3-tomlkit instead, and correct the same note in build-flatpak.sh. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-15 01:47:09 +02:00
enricobuehlerandClaude Opus 4.8	5faf754b7f	feat(packaging/flatpak,decky): Steam Deck client flatpak + plugin deploy + CI ... Ship the punktfunk Linux client to the Steam Deck as a Flatpak — the only viable SteamOS install path, since /usr is read-only and lacks libadwaita/SDL3 — and publish both it and the Decky plugin through Gitea. Built and validated live on a Steam Deck (SteamOS 3.7): bundle installs user-scope, all libs resolve, libavcodec resolves to the codecs-extra HEVC build, devices=all for DualSense hidraw. packaging/flatpak (new): - io.unom.Punktfunk.yml on GNOME 50 / freedesktop-sdk 25.08. rust-stable//25.08 (rustc 1.96 — the GTK4 chain needs >=1.92; the EOL GNOME-48/24.08 rust-stable at 1.89 could not build it) + llvm20 (libclang for bindgen in ffmpeg-sys-next/sdl3-sys). HEVC libavcodec comes from the runtime's auto codecs-extra extension point (no app-side codec declaration). Bundled SDL3 3.4.10 (matches sdl3-sys 0.6.6+SDL-3.4.10). finish-args: wayland/fallback-x11, --device=all (GPU/VAAPI + evdev + hidraw — flatpak cannot bind /dev/hidrawN char devices via --filesystem), pulseaudio, network, ~/.config/punktfunk. - metainfo.xml, desktop, square SVG icon, build-flatpak.sh (offline cargo-sources; on-Deck org.flatpak.Builder or CI), README. clients/decky: - add LICENSE (MIT), fix package.json license (BSD-3-Clause -> Apache-2.0 OR MIT), add scripts/{package.sh,deploy.sh} (the plugins dir is root-owned: stage to /tmp, sudo install, restart plugin_loader), align the launcher fallback to the real flatpak app id io.unom.Punktfunk, rewrite the install section. .gitea/workflows: - flatpak.yml: privileged Fedora container builds the bundle and publishes to the Gitea generic registry (+ release attachment on tags). - decky.yml: pnpm build -> store-layout zip -> registry (stable latest/ URL for Decky "install from URL"). docs: packaging/README + packaging/flatpak/README. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-15 01:43:35 +02:00