64 Commits

Author	SHA1	Message	Date
enricobuehler	e2c9bfd3d9	feat(windows): pf-vdisplay IDD-push — HDR + pipelined zero-copy capture ... HDR (display-driven, matching the WGC path): - CTA-861.3 HDR EDID (BT.2020 primaries + HDR Static Metadata block) so Windows offers "Use HDR" on the virtual display. The host FOLLOWS the display's live advanced-color state, recreating the shared ring at the matching format (FP16 in HDR / BGRA in SDR) on a toggle — no freeze. - Always emit Main10/BT.2020-PQ Rgb10a2 while the display is HDR; the client auto-detects PQ from the HEVC VUI (clients under-report VIDEO_CAP_10BIT). Generic HDR10 mastering SEI on every IDR. - Generation-tagged `latest` (gen<<40|seq<<8|slot) + driver `is_stale` re-attach kill the toggle-time garbage frame and any stale-ring read. Perf: - Pipeline the encode loop (Capturer::pipeline_depth; IDD-push = 2): submit N+1 before polling N so the convert/copy on the 3D engine overlaps the NVENC encode of N on the ASIC. PUNKTFUNK_IDD_DEPTH overrides (1 = synchronous). - Rotating host output ring (OUT_RING) so the in-flight encode and the next convert never touch the same texture. - HDR converts directly from the keyed-mutex slot's SRV into the output ring (drops the redundant slot->fp16 scratch copy); SDR copies the BGRA slot in. The slot mutex is held only across the convert/copy, not the encode. RING_LEN 3->6 for publish headroom. - Capture-health diagnostic: new_fps vs repeat_fps under PUNKTFUNK_PERF (a low new_fps at a high send rate means the source isn't compositing, not an encode stall). Validated live on the RTX box: 5120x1440@240 HDR streams; driver composes ~180 new fps, encode 240 fps @ ~4.3 ms p50. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-24 00:39:28 +02:00
enricobuehler	c5dab484df	feat(windows): bundle pf-vdisplay in the host installer; drop SudoVDA ... Switch the Inno Setup installer's virtual-display driver from the vendored SudoVDA C++ binary to our own all-Rust pf-vdisplay (validated streaming at 5120x1440@240). - packaging/windows/pf-vdisplay/: vendored SIGNED driver (pf_vdisplay.dll/inf/cat + punktfunk-driver.cer, the same cert the gamepad drivers ship), built from vdisplay-driver/ via deploy-dev.ps1. - install-pf-vdisplay.ps1 / stage-pf-vdisplay.ps1: mirror the SudoVDA scripts - trust cert -> gated ROOT\pf_vdisplay node via nefconc (NEVER devgen) -> pnputil /add-driver /install. Idempotent, best-effort (never aborts the install). - punktfunk-host.iss + pack-host-installer.ps1: install the pf-vdisplay bundle under the existing installdriver task. - Removed the vendored SudoVDA driver + install-sudovda.ps1 + stage-sudovda.ps1. - README + windows-host.yml: SudoVDA -> pf-vdisplay. The host's vdisplay/sudovda.rs backend is unchanged - it drives whichever driver provides the {e5bcc234} interface, now pf-vdisplay. Live installer build/test on the runner is the remaining step. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-24 00:39:28 +02:00
enricobuehler	e27abc065e	feat(windows): pf-vdisplay CLEAR_ALL — reap orphaned virtual monitors on startup ... The "5-6 stale monitors that never tear down" failure (also seen with SudoVDA): an orphan from a crashed/killed previous host lingers because the driver watchdog is kept reset by a still-pinging new session, so it never fires for the orphan. - Driver (pf-vdisplay control.rs): new IOCTL_CLEAR_ALL (0x804) -> tear down every monitor. A pf-vdisplay extension; SudoVDA returns invalid for it (ignored), so the host can issue it unconditionally. - Host (vdisplay/sudovda.rs): send IOCTL_CLEAR_ALL once on startup (best-effort) to reap orphans before creating ours; and surface a failing keepalive PING (the old `let _ =` swallowed it, masking a lost control handle). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-24 00:36:21 +02:00
enricobuehler	d39da4bc06	feat(windows): pf-vdisplay — all-Rust IddCx virtual display (replaces SudoVDA) ... P1 done: a pure-Rust UMDF2 IddCx driver, drop-in compatible with the host's existing vdisplay/sudovda.rs control plane (the {e5bcc234} interface + the SudoVDA IOCTL ABI), so the host drives it unchanged. Validated streaming on glass at 5120x1440@240 — steady 240 fps, ~2.4 ms encode, clean teardown, full parity with SudoVDA. - Vendored wdf-umdf-sys / wdf-umdf bindgen crates (MIT, from virtual-display-rs) + the SDK-version build.rs fix that resolves the IddCxStub lib path by the WDK version actually containing um\x64\iddcx, not the max base SDK. - pf-vdisplay crate: entry/callbacks/context/control/monitor/edid/ swap_chain_processor. Our OWN 128-byte EDID (manufacturer PNK, product punktfunk — no SudoVDA bytes), a real swap-chain drain (faithful vdd port, required so DWM keeps compositing), the SudoVDA-compatible IOCTL control plane (ADD/REMOVE/PING/GET_WATCHDOG/GET_VERSION/SET_RENDER_ADAPTER) + a watchdog that tears down orphaned monitors when the host stops pinging. - deploy-dev.ps1: stage + sign + stampinf (date.time DriverVer) + Inf2Cat + install, codifying the "bump DriverVer or pnputil keeps the old binary" gotcha. - docs/windows-virtual-display-rust-port.md: investigation, the on-glass validation, and the two traps that cost time (Session-0 measurement + accumulated device-state needing a reboot). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-24 00:36:21 +02:00
enricobuehler	de232ec2f7	fix(web): bundle deps into the server (noExternals) — kill the 47k-file install ... The Windows installer ballooned to 154 MB and installed forever because the node-server bundle externalized the WHOLE @unom/ui dependency tree (payload, lexical, date-fns, prismjs…) to .output/server/node_modules — 47,567 files / 730 MB copied into Program Files. Set Nitro `noExternals: true` so every dependency is bundled + tree-shaken into the server output: .output drops to ~75 files / 10 MB, and the bare external imports (srvx, seroval…) bun couldn't resolve at runtime are gone — so the console runs on bun (no node, no node_modules), which is the issue we previously worked around with node. Windows installer now ships bun.exe + the ~75-file .output (was node.exe + a node_modules forest) and runs `bun .output\server\index.mjs`: - windows-host.yml: fetch a pinned portable bun (build tool AND shipped runtime); drop the node fetch + the .output/server install; smoke-boot under the bundled bun. - pack-host-installer.ps1 / punktfunk-host.iss: -NodeExe -> -BunExe; stage {app}\bun\bun.exe. - web-run.cmd / build-web.ps1: run/restart on bun; docs updated. Net win everywhere: the Linux .deb shrinks (node still runs the self-contained output), and the docker web image — which already ran `bun run .output/server/index.mjs` with only .output copied — is fixed (the externals had no node_modules to resolve at runtime). Validated locally: noExternals build = 75 files / 10 MB; node AND bun both serve /login (200) + static assets (200) + gate /api (401). (A true single binary via `bun build --compile` is blocked for now: Nitro serves public assets from an import.meta-relative path `--compile` doesn't embed (/$bunfs/public); the 75-file payload is the clean result.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-22 21:19:32 +02:00
enricobuehler	58f4dccc02	fix(windows-host): ISCC [Code] — don't put {tmp} inside a Pascal comment ... ISCC aborted compiling the installer at the web-console [Code] section: a comment `{ ... {tmp} is auto-cleaned. }` — Pascal `{ }` comments don't nest, so the `}` in `{tmp}` closed the comment early and `is auto-cleaned. }` parsed as code ("Identifier expected"). Reword to drop the brace. (All other {app}/{tmp} uses are `;` line-comments or code strings, which are fine.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-22 20:21:41 +02:00
enricobuehler	5e106c51cf	feat(windows-host): bundle + auto-run the web console in the installer ... The Windows host installer shipped only the host exe + SudoVDA driver + FFmpeg, so a fresh install had no web management console — required for basically every user (status, paired devices, the PIN pairing flow). The console was only ever set up by hand on the dev box (build-web.ps1 + a hand-made PunktfunkWeb task whose web-run.cmd wasn't even committed). Bundle it into the same installer, mirroring the proven Linux punktfunk-web deploy. - windows-host.yml builds the Nitro node-server console (bun, deb.yml's shape) + fetches a pinned portable Node, smoke-boots it under node (/login == 200) to gate the build, and hands web/.output + node.exe to the pack script. - pack-host-installer.ps1 gains -WebDir/-NodeExe and stages the .output tree, node, and the two new scripts into the non-WOW64-redirected build area. - punktfunk-host.iss lays the payload into {app}\web\.output + {app}\node\node.exe, adds a wizard page for the console login password pre-filled with a crypto-random default (shown on the finish page; kept on upgrade), and runs web-setup.ps1. - web-setup.ps1 writes the ACL'd %ProgramData%\punktfunk\web-password (Administrators + SYSTEM), registers the PunktfunkWeb scheduled task (boot, SYSTEM, restart-on-failure -> web-run.cmd -> node on :3000), opens inbound TCP 3000, and starts it. web-run.cmd sources the host's mgmt-token + the password and runs the bundled node. - The console proxies the host's loopback mgmt API with the host's own %ProgramData%\punktfunk\mgmt-token (no host-code change). Uninstall removes the task + firewall rule. Validated locally: bun build -> node-server bundle, node boot serves /login (200) and gates /api (401). The Windows-only bits (ISCC compile, scheduled task, password page, firewall) validate on the Windows runner CI + on-glass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-22 19:28:47 +02:00
enricobuehler	b0c82333d2	feat(gamepad): pure-user-mode Windows DualShock 4 + Xbox 360 (drop ViGEm) + installer + multi-pad ... Windows virtual gamepads now have zero external dependencies - ViGEmBus is removed. - DualShock 4: Windows UMDF backend (inject/dualshock4_windows.rs + dualshock4_proto.rs), reusing the DualSense SwDeviceCreate game-detection identity fix. The one UMDF driver serves the DS5 or DS4 identity/descriptor/features/strings per a device_type byte the host stamps into shared memory. Driver also gains IOCTL_HID_GET_STRING and a 41-byte calibration feature. - Xbox 360: a new UMDF2 XUSB companion driver (packaging/windows/xusb-driver/) that registers GUID_DEVINTERFACE_XUSB and answers the buffered XInput IOCTLs from a shared section, so classic XInputGetState/SetState work with no kernel bus driver. inject/gamepad_windows.rs is rewritten to drive it and the vigem-client dependency is removed. Xbox One folds to the 360 XInput path. - Installer: vendor + pnputil-install the three UMDF drivers (packaging/windows/gamepad-drivers/ + install-gamepad-drivers.ps1, wired into pack-host-installer.ps1 + punktfunk-host.iss). - Multi-pad: the host stamps each pad index into the device Location (pszDeviceLocation); the driver reads it via WdfDeviceAllocAndQueryProperty to map its own *-shm-<index>, with UmdfHostProcessSharing=ProcessSharingDisabled giving each pad its own host (per-pad statics). Validated live on the Windows host: Cyberpunk native DualSense detection, DS4 identity + descriptor, XInputGetState + rumble round-trip, two pads -> two distinct XInput slots, and a full installer build. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-22 16:35:03 +02:00
enricobuehler	72eeedc4da	feat(windows): AMD (AMF) + Intel (QSV) hardware encode on the Windows host ... The Windows host was NVIDIA-only (NVENC) with an openh264 software fallback. Add AMD AMF and Intel QSV via libavcodec — the Windows analogue of the Linux VAAPI backend — so one installer serves all three GPU vendors. - encode/ffmpeg_win.rs: new WinVendor{Amf,Qsv} encoder. System-memory NV12/P010 readback (default, robust) + opt-in zero-copy D3D11 (PUNKTFUNK_ZEROCOPY: shares the capturer's ID3D11Device; AMF takes AV_PIX_FMT_D3D11, QSV derives a QSV frames ctx and maps) with a system fallback for the format-group mismatch the capturer's video-processor fallback can produce. HDR Main10 (P010 + BT.2020/PQ VUI; an Rgb10a2->P010 swscale covers the shader fallback). - encode.rs: Codec::amf_name/qsv_name; open_video + windows_resolved_backend() resolve PUNKTFUNK_ENCODER=auto|nvenc|amf|qsv|sw via a DXGI adapter VendorId probe. - capture/dxgi.rs: gpu_mode mirrors the resolved backend (D3D11 NV12/P010 for AMF/QSV). - gamestream/serverinfo.rs: GPU-aware codec advertisement (windows_codec_support; AV1 gated to RDNA3+/Arc, like the VAAPI path). - Cargo.toml: amf-qsv feature (optional ffmpeg-next in the windows target block). - CI/installer: windows-host.yml sets FFMPEG_DIR + builds --features nvenc,amf-qsv; the Inno installer bundles the FFmpeg DLLs; host.env default nvenc -> auto. CI-green target; AMF/QSV not yet on-glass validated (no AMD/Intel Windows box in the lab) — NVENC stays live-validated. An adversarial-review pass caught + fixed real FFI bugs (AV_PIX_FMT_P010 is a macro -> P010LE; windows-rs 0.62 GetImmediateContext/ GetDesc1 return Result; AV_HWFRAME_MAP_* is a bindgen enum with no BitOr). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-22 10:31:54 +00:00
enricobuehler	01dc0b616c	refactor(windows): trim the inert IOCTL channel from the DualSense driver ... The host<->driver channel is the shared-memory section (hidclass blocks the device stack and UMDF has no control device), so the first-attempt in-driver IOCTL channel never fired. Remove it: the custom device interface, IOCTL_PFDS_SET_INPUT/GET_OUTPUT, the output queue, and the on_set_input/complete_one_read/deliver_output helpers. The driver keeps the HID handshake, the 8ms read timer fed from the shared section, and on_output_report publishing the game's 0x02 to the section. Rebuilt + reloaded + the channel still verifies both directions live on the RTX box. Also list `pf_dualsense` as a second hardware id (alongside `root\pf_dualsense`) so the host's SwDeviceCreate'd software device binds the same driver as a devgen one. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-21 21:34:00 +00:00
enricobuehler	aa159df33f	feat(windows): Rust UMDF virtual DualSense driver + shared-memory host channel ... A self-authored UMDF2 HID minidriver (packaging/windows/dualsense-driver) that presents a virtual Sony DualSense (VID 054C/PID 0CE6) on Windows — adaptive triggers / lightbar / rumble that ViGEm structurally cannot deliver. Validated live on an RTX box (Win11 25H2, Secure Boot ON): the self-signed driver loads, Steam recognizes it as a genuine DualSense, and a game's 0x02 output report reaches the driver. The host<->driver channel is a named shared-memory section (Global\pfds-shm-<idx>) the host creates and the driver maps from its timer: input report 0x01 host->driver, output report 0x02 driver->host — input and output proven both directions live. This bypasses hidclass, which gates both a custom device interface and custom IOCTLs on the HID node, and UMDF has no control device. Built in Rust on microsoft/windows-drivers-rs. The load wall was the PE FORCE_INTEGRITY bit that wdk-build sets via /INTEGRITYCHECK (forces a CI-trusted page-hash signature a self-signed cert cannot satisfy) — cleared post-build. See packaging/windows/dualsense-driver/README.md for the build/sign/install recipe. Deferred: SwDeviceCreate per-session device lifecycle; removing the inert in-driver IOCTL-channel code; full on-glass session test. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-21 20:36:39 +00:00
enricobuehler	0205c7b8d6	ci(release): split canary/stable tracks + unified Gitea Releases ... A push to main publishes canary builds to canary channels (fast iteration, unchanged); a single vX.Y.Z tag releases every platform at one version to the stable channels and attaches all artifacts (.deb/.rpm/.msix/.apk/.aab/.dmg + flatpak/decky/host-installer) to one Gitea Release. Collapses the host-v*/win-v*/host-win-v* tag namespaces into v* — the channel split makes the version-shadow bug structurally impossible (canary and stable are separate repos, never a shared version line). - scripts/ci/gitea-release.{sh,ps1}: one idempotent release helper (create-or-fetch + delete-before-upload), replacing 3 copy-pasted inline blocks and fixing their latent 409-on-reupload bug; prerelease flag auto-derived from the tag (an -rc tag won't shadow "Latest") - channels: apt canary/stable distributions; rpm *-canary/base groups; flatpak canary/stable OSTree branches + a 2nd .Canary.flatpakref; generic-registry canary/ vs latest/ aliases; Play internal/alpha; Apple TestFlight vs notarized DMG - android versionName threaded through gradle (versionCode stays run_number); Apple canary = TestFlight-only (no DMG/tvOS); canary base bumped to 0.3.0 - docs: new docs-site channels.md (subscribe table + cut-a-release runbook + box migration), refreshed ci.md workflow table + packaging READMEs Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-21 17:26:38 +00:00
enricobuehler	54b75c9be4	feat(host): GameStream/Moonlight compat is now opt-in (--gamestream) — secure native-only by default ... Follows the security audit (#5/#9): the GameStream-compat plane carries inherent on-path weaknesses that can't be fixed on the wire without breaking stock Moonlight — its pairing runs over plain HTTP (#9, MITM-able during the pairing window) and its legacy control encryption can reuse GCM nonces (#5, a passive eavesdropper can recover/forge input). The native punktfunk/1 plane (SPAKE2 PIN pairing + per-direction AEAD nonces) has neither. So flip the default to secure-by-default: - `serve` → native punktfunk/1 plane + management API ONLY (no GameStream surface). - `serve --gamestream` → ALSO the GameStream/Moonlight-compat planes (nvhttp pairing, RTSP, ENet control, _nvstream mDNS). Opt-in, logged with a trusted-LAN caveat. `--moonlight` is an alias. - The native plane is now ALWAYS on in `serve` (`--native` is a kept-for-compat no-op); the unified GameStream+native host is `serve --gamestream`. `gamestream::serve` gates the GameStream spawns (nvhttp/rtsp/control/mdns) on the flag; the native plane + mgmt + native-pairing handle always run. To avoid silently regressing validated Moonlight deployments, the explicit deployment configs PRESERVE Moonlight via `--gamestream` (each documents dropping it for a secure native-only host): the Linux systemd unit, the Steam Deck installer, and the Windows service default (DEFAULT_HOST_CMD). The bare `serve` default (new/manual use) is secure. Docs swept to match (host-cli, moonlight, quickstart, install, packaging READMEs, CLAUDE.md, README, …): Moonlight setup now instructs `--gamestream`; native/console refs use bare `serve`. OpenAPI regenerated (a stale "run `serve --native`" string). fmt + clippy clean; 94 host tests green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-21 10:19:40 +00:00
enricobuehler	f85d51b9f9	feat(steamdeck): one-command host install + docs (build-on-device) ... SteamOS is immutable read-only Arch, and the Deck is AMD (VAAPI) — so none of the checked-in packaging (arch/sysext is NVENC-first + client-oriented, deb/rpm are soname-mismatched) actually installs a working host on a Steam Deck. The proven path (distrobox-built native binary + systemd-run units) was 100% manual. Make it one command. - scripts/steamdeck/install.sh — idempotent installer: ensure the pf2 Debian-trixie distrobox + toolchain → build host (+web console) → write config (generated web login password) → raise UDP buffers to 32 MB + udev + input group (sudo, skipped gracefully if unavailable) → install + start punktfunk-host / punktfunk-web systemd USER services with linger. Flags: --open (accept unpaired clients), --no-web, --src=DIR. Builds on-device so a rebuild always matches the running SteamOS (no prebuilt-binary fragility across OS updates); VAAPI on the Deck's AMD GPU. - scripts/steamdeck/update.sh — rebuild from current source + restart (config/pairings persist). - scripts/steamdeck/README.md — deep reference (why on-device, what's installed, gotchas). - docs-site: new "Steam Deck (Host)" guide + sidebar entry; install.md splits Arch from the Steam Deck host path; packaging/arch/README points Deck-host users here and corrects the stale "NVENC-only" note (VAAPI host encode landed). Live-validated on the Deck: installer runs clean, both services come up, host listens (QUIC :9777 + mgmt :47990), web serves (302→login); on a client connect it takes over the Game-Mode gamescope session at the client's mode, captures via PipeWire, and VAAPI-encodes (hevc_vaapi) — full pipeline confirmed in the host journal. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-20 22:20:00 +00:00
enricobuehler	6922e1c467	feat(host): VAAPI codec probe + AMD/Intel packaging + neutral logs (Phase 3) ... Polish for AMD/Intel support: - GameStream serverinfo advertises only codecs the GPU can ACTUALLY encode on the VAAPI backend (probed once by opening a tiny encoder per codec). AV1 encode is narrow (Intel Arc/Xe2+, AMD RDNA3+/RDNA4) and an old iGPU may lack HEVC, so a Moonlight client never negotiates a codec the encoder can't open. NVENC/Windows keep the Moonlight-validated static mask. Validated on a Radeon 780M: h264/h265/av1 all probe true -> mask unchanged (65793). - Packaging: Recommends mesa-va-drivers + intel-media-va-driver (deb) / mesa-va-drivers + intel-media-driver (rpm) so the auto-selected VAAPI backend works out of the box on AMD/Intel; NVIDIA boxes can --no-install-recommends. (Fedora note: stock mesa-va-drivers disables HEVC/AV1 -- needs the freeworld variant from RPM Fusion.) - De-NVIDIA-fy the user-facing encoder log/context strings ("open NVENC" -> "open video encoder") now that VAAPI is a first-class backend. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-20 10:41:37 +00:00
enricobuehler	53aade0279	docs(packaging/windows): note the host is x64-only (no ARM64) ... The host is NVIDIA/NVENC + SudoVDA coupled; Windows ARM64 has neither an NVIDIA driver nor an ARM64 SudoVDA, so an ARM64 host would install but couldn't encode or make a virtual display. Document the deliberate x64-only scope so it doesn't get re-litigated. ARM64 stays client-only. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-19 13:23:30 +00:00
enricobuehler	24ee05a4d0	fix(packaging/windows): dodge WOW64 redirection — run ISCC on copies under C:\t ... Root cause of the persistent ISCC "path not found": ISCC.exe is 32-bit, and the self-hosted runner runs as SYSTEM, so the checkout lives under C:\Windows\System32\config\systemprofile\.cache\... . WOW64 file-system redirection rewrites a 32-bit process's System32 reads to SysWOW64 (where nothing exists), so ISCC died opening the .iss before it even printed its version line. (The smoke-test diagnostic compiled fine precisely because it lived at C:\t\out.) Fix: copy every file ISCC reads (the .iss + host.env.example + README.md) into the non-redirected build dir C:\t\out and compile from there; BinDir, StageDir, and OutputDir already live under C:\t. Removed the now-spent smoke diagnostic. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-19 12:27:19 +00:00
enricobuehler	d59de1553f	fix(packaging/windows): make the .iss pure ASCII (ISCC encoding failure) ... The smoke-test diagnostic proved Inno itself is healthy (a trivial ASCII script compiled), while the real .iss died before the "Compiler engine version" line — i.e. at script open, not during compile. The difference: the real .iss was UTF-8 with non-ASCII chars (→, —) in comments, which ISCC 6.4+ rejects without a UTF-8 BOM (and the German-locale runner misreads). Replace them with ASCII (->, -). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-19 12:22:00 +00:00
enricobuehler	e905801567	diag(packaging/windows): isolate the ISCC "path not found" failure ... All [Files] sources are validated-present yet ISCC still errors before any "Compiling" output (no line number) — so it's startup/[Setup]-internal, not a source path. Add an explicit [Languages] (compiler:Default.isl) to rule out the auto-added default language, and on ISCC failure dump the Inno install dir + run a trivial [Setup]-only smoke script to tell "Inno broken" from "my script". Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-19 12:13:29 +00:00
enricobuehler	43e0be4cf4	fix(packaging/windows): pass installer source files as validated absolute defines ... The {#SourcePath} relative-traversal for host.env.example/README kept tripping ISCC ("path not found", error 2) regardless of the separator, so drop it: compute the two paths absolutely in pack-host-installer.ps1, Test-Path them (clear PS error if missing), and pass /DHostEnv + /DReadme. The .iss [Files] now reference the absolute defines — no {#SourcePath}, no ..\.. traversal. Also prints "source ok" for each so a future failure is unambiguous. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-19 11:44:30 +00:00
enricobuehler	822fde1e89	fix(rpm): derive the libcuda link stub from source (fixes undefined cu* symbols) ... The Fedora RPM build linked punktfunk-host against a synthesized libcuda stub with a FROZEN symbol list baked into ci/fedora-rpm.Dockerfile. The priority- stream work added cuCtxGetStreamPriorityRange / cuStreamCreateWithPriority / cuStreamSynchronize / cuMemcpy2DAsync_v2, which weren't in that list, so the link failed with "undefined symbol". build-rpm.sh now regenerates /usr/lib64/libcuda.so.1 from every cu* symbol the host source references (grep of crates/punktfunk-host/src), before rpmbuild — so a new cu* call can never silently break the link again. Self-maintaining and needs no builder-image rebuild (it supersedes the Dockerfile's frozen stub). Verified the 23 extracted symbols compile and cover the 4 that were undefined. Also fix the bogus %changelog weekday (Sun -> Mon, Jun 15 2026 is a Monday) that rpmbuild warned on. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-19 08:29:16 +00:00
enricobuehler	7dad881d98	fix(packaging/windows): add '\' after {#SourcePath} in the .iss [Files] ... ISPP's {#SourcePath} has no trailing backslash, so {#SourcePath}..\..\scripts resolved to ...\packaging\windows..\..\scripts (invalid component "windows..") -> ISCC error 2 "path not found". Add the explicit separator (a double backslash is harmless on Windows if a future ISPP ever adds the trailing one). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-19 07:36:01 +00:00
enricobuehler	68744d5743	fix(packaging/windows): vendor SudoVDA driver (no upstream release) + real nefcon URL ... The first CI run failed only on the SudoVDA download: SudoMaker/SudoVDA has no releases (source-only repo; Apollo embeds the driver in its installer), so there was nothing to fetch. Vendor the prebuilt SIGNED driver in-repo instead. - packaging/windows/sudovda/: SudoVDA.inf/.cat/.dll + sudovda.cer (derived from the .cat signer CN=sudovda@su.mk), pulled from the dev-box driver store. v1.10.9.289, Class=Display, HWID Root\SudoMaker\SudoVDA, MIT/CC0. - fetch-sudovda.ps1 -> stage-sudovda.ps1: stage the vendored driver + fetch nefcon from its real pinned release (v1.17.40, sha256 812bae7e…, x64/nefconc.exe). - pack-host-installer.ps1: call stage-sudovda.ps1; README updated with the driver-refresh recipe. The rest of the pipeline already passed on the first run (host built --features nvenc via the llvm-dlltool import lib; ISCC + signtool found; signed with the real CN=unom cert). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-19 07:22:52 +00:00
enricobuehler	16d3b7767e	feat(packaging): signed Inno Setup installer for the Windows host + CI ... MSIX (the client's format) can't install the host's LocalSystem secure-desktop service or the SudoVDA kernel driver, so the host ships as a signed Inno Setup setup.exe that runs elevated and delegates to the existing idempotent `punktfunk-host service install`. - packaging/windows/punktfunk-host.iss: lay exe into Program Files, optional SudoVDA driver task, run service install/start; [Code] stops+waits the service before file copy on upgrade; uninstall runs service uninstall. - pack-host-installer.ps1: cert (reuses MSIX_CERT_PFX_B64 / self-signed CN=unom), sign inner exe + setup.exe, fetch/stage SudoVDA, run ISCC, export public .cer. - fetch-sudovda.ps1 / install-sudovda.ps1: pinned SudoVDA + nefcon download, cert import, gated device-node create (no phantom dup), pnputil install (warn-not-abort). - nvenc/: synthesize nvencodeapi.lib via llvm-dlltool from a 2-export .def so --features nvenc links with no GPU/SDK at build time. - .gitea/workflows/windows-host.yml: build (nvenc) -> clippy -> ISCC -> sign -> publish setup.exe + .cer to the generic registry pkg punktfunk-host-windows. Tag host-win-v* -> X.Y.Z (+ latest/ alias); main push -> rolling 0.2.<run>. - setup-windows-runner.ps1: provision Inno Setup; docs: installer instructions. SudoVDA/nefcon release URLs+SHA-256s in fetch-sudovda.ps1 are placeholders (baseline v0.2.1) — fetch warns + prints the computed hash until pinned. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-18 23:05:20 +00:00
enricobuehler	f1032a7a23	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
enricobuehler	d9d495a53e	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
enricobuehler	9c8fa9340c	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
enricobuehler	25c8dd58c7	fix(flatpak): drop the Windows client from the workspace for the offline build ... The lock prune (a5b99b2) 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
enricobuehler	a5b99b2928	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 (64b1679) for the Steam Deck. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-17 07:43:11 +00:00
enricobuehler	1f0dc87658	feat(rpm): enable gpgcheck=1 — packages are signed + verified ... The signing rollout is confirmed end to end: the latest published RPM (0.2.0-0.ci1089) carries a header GPG signature (added by `rpm --addsign`) and passed the in-CI `rpmkeys --checksig` self-verify before publishing (a bad/unsigned build fails that gate and never reaches the registry). So flip every .repo snippet from gpgcheck=0 to gpgcheck=1 and add the package-signing public key (served from the generic registry, committed at packaging/rpm/RPM-GPG-KEY-punktfunk) to gpgkey= alongside the Gitea metadata key — dnf/rpm-ostree imports both. Covers rpm/README, packaging/README, the bootc Containerfile, and the docs-site bazzite/fedora-kde install pages; rpm/README's signing section reframed from "dormant/enabling" to active (+ key-rotation notes). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-15 15:23:57 +00:00
enricobuehler	59bcfa1a12	fix(ci): rpm signing uses rpm's default signer; flatpak installs node before checkout ... Two CI fixes: - rpm signing (2nd bug): overriding %__gpg_sign_cmd via --define reached gpg with %{__plaintext_filename}/%{__signature_filename} UNEXPANDED ("No such file or directory"). Stop overriding it — use rpm's default signer (which expands those correctly) and just set _gpg_name; a passphrase-less key + loopback in gpg.conf makes gpg sign headless. (Requires a passphrase-less signing key, as the runbook's %no-protection key is.) - flatpak: the job runs in fedora:43 which has no node, so actions/checkout (a JS action) failed with "node: not found". Install nodejs in a plain `run:` step (shell, no node needed) before checkout. Also scope the heavy flatpak-builder run to client/core/manifest changes (+ tags) so it stops rebuilding on every unrelated docs/host push (tag pushes still build — paths filters only branch pushes). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-15 13:54:43 +00:00
enricobuehler	0f17b6f864	fix(rpm): sign-rpms.sh — %{__gpg} is already the gpg binary, drop the literal gpg ... The first signed CI run failed at the Sign step: `%{__gpg} gpg ...` expands to `<gpgpath> gpg ...`, so gpg got a spurious `gpg` filename arg ("no command supplied", options "not considered"). Dropped the literal `gpg` → `%{__gpg} --batch ...`. Validated locally: the corrected invocation parses as a sign command (fails only with "No secret key", which is present in CI). The checksig gate did its job — nothing published, installs stayed safe. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-15 13:39:00 +00:00
enricobuehler	067f592615	feat(rpm): add the package-signing public key (activates the dormant signing) ... The dedicated EdDSA signing key (AF245C506F4E4763, "punktfunk packages <packages@unom.io>") whose private half is now the RPM_GPG_PRIVATE_KEY CI secret. Committing the public half so clients can fetch it (raw URL) for gpgcheck=1. This push triggers a rpm.yml run that signs 0.2.0~ciN via packaging/rpm/sign-rpms.sh (no longer a no-op); the gpgcheck=1 flip follows once that signed build is confirmed published. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-15 13:01:24 +00:00
enricobuehler	1fd4c97139	feat(rpm): wire per-package GPG signing (dormant until a key secret is set) ... The audit's signing recommendation, scoped to RPM (apt's signed Release metadata already covers .debs; bootc cosign deferred). packaging/rpm/sign-rpms.sh GPG-signs dist/*.rpm and self-verifies (rpmkeys --checksig), run from rpm.yml between build + publish. Safe to ship: the step is a NO-OP (exit 0, unsigned as today) until RPM_GPG_PRIVATE_KEY is set as a CI secret — so it can't break current CI, and when enabled a bad macro fails loudly via the in-step checksig rather than shipping bad signatures. rpm/README gains the one-time enablement runbook (generate a dedicated passphrase-less key, add the secret, publish the public key, flip gpgcheck=1 only after a signed build lands) and notes step-ca is for TLS, not OpenPGP (it can't sign RPMs). Also fixes the rpm/README version staleness the doc review caught: rolling is 0.2.0-0.ciN (outranks the stray 0.1.1, no pin needed), host releases use host-v* not the client's v*. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-15 10:46:27 +00:00
enricobuehler	9e015304ee	docs(dist): end-user install front door + serve/pairing/firewall accuracy fixes ... Make the host docs match the real distribution path and the actual CLI. Reviewed by a multi-agent pass (6 editors against one verified fact sheet + an accuracy reviewer); its findings (a wrong client-Recommends claim, a native-concurrency overstatement) folded in. - Install front door: new README "Install (host)" method-picker + docs-site/install.md (+ nav), routing each distro to its package registry; source build demoted to a fallback. - Registry-first install: ubuntu-gnome/ubuntu-kde now lead with the apt registry (not a cargo build); bazzite leads with the Gitea RPM registry (was COPR/source). Source builds moved to an appendix. - CLI accuracy: serve --native arms pairing from the web console (NOT --allow-pairing, which with --require-pairing/--max-concurrent is m3-host-only); --open disables mandatory pairing. host-cli/configuration/pairing/quickstart/troubleshooting corrected; mgmt API documented as always HTTPS+token. Native host serves one session at a time (extras queue) — not multi. - Firewall: real ports documented (native UDP 9777 + the ephemeral data port caveat + GameStream ports) for Debian + Arch (ufw + nftables), not just Bazzite. - Sync/accuracy: punktfunk-client (GTK4) presented as a shipping client (not "roadmap"), punktfunk-client-rs as the headless tool; host Recommends punktfunk-web only (not the client); COPR chroots f43/44; bootc header says Gitea registry not COPR. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-15 10:43:12 +00:00
enricobuehler	837b6fabb1	feat(dist): aarch64 honesty, Debian KWin-unit parity, cargo-audit CVE scan (P1/P2) ... - spec: narrow ExclusiveArch to x86_64 — no aarch64 build is produced/published (NVENC is desktop-NVIDIA), so claiming aarch64 advertised an arch we never ship. - build-deb.sh: ship punktfunk-kde-session.service (ExecStart repointed to the packaged run-headless-kde.sh) + host.env.kde, matching the RPM/Arch — the deb README's "mirrors the Fedora RPM" claim now holds. - audit.yml: weekly + Cargo.lock-change `cargo audit` over the network-facing crypto dep tree (RustSec advisories); ignore unfixables via .cargo/audit.toml. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-15 10:34:32 +00:00
enricobuehler	fe9921cc1c	fix(dist): kill the version-shadow + add build provenance (P0) ... The stale code a default install/upgrade got was a TAG LEAK: deb.yml/rpm.yml shared `tags: ['v*']` with the Apple-client release.yml, so the v0.1.0/v0.1.1 tags cut to ship the macOS app ALSO published host packages versioned 0.1.1 — which outranks every rolling 0.0.1~ciN / 0.0.1-0.ciN build in both registries (dpkg/rpm version compares confirm), so `apt install`/`rpm-ostree install` silently fetched ~99-commits-stale code while the READMEs claimed auto-tracking. Two fixes: - Decouple host publishing from Apple `v*` tags: deb.yml/rpm.yml now trigger on `host-v*` only, so a client tag can never poison the host channel again. - Bump the rolling base 0.0.1 -> 0.2.0 (deb `0.2.0~ciN`, rpm `0.2.0-0.ciN`): sits ABOVE the stray 0.1.1 yet BELOW a future 0.2.0 tag, and still climbs monotonically by run number — so `apt upgrade`/`rpm-ostree upgrade` genuinely move forward. Spec default + build scripts + PKGBUILD pkgver bumped to match. Build provenance (so a stale/shadowed host is detectable): build.rs stamps PUNKTFUNK_BUILD_VERSION (set by CI = the full package version, e.g. 0.2.0~ci120.g802e98d; falls back to the crate version for a plain `cargo build`) into the binary via rustc-env. Surfaced in `punktfunk-host --version`, the startup log, and the mgmt /health + /host `version` field (was a hardcoded CARGO_PKG_VERSION). Deliberately env-driven, not git-derived — the RPM builds from a git-archive tarball with no .git. Version computed BEFORE the build in deb.yml; the spec %build exports it from %{version}-%{release} (and gains --locked for reproducibility parity with the .deb path). Validated: plain build reports 0.0.1, env-stamped build reports 0.2.0~ci999.gdeadbee. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-15 10:30:21 +00:00
enricobuehler	802e98d3a3	feat(packaging): bundle the web console into the RPM / Arch / bootc host packages ... The punktfunk-web management console (pairing + status) shipped only via apt. Extend it to the other HOST packaging methods, mirroring the Debian punktfunk-web .deb (flatpak is the client, correctly excluded): - rpm/punktfunk.spec: new noarch `punktfunk-web` subpackage (the .output bundle + a /usr/bin/punktfunk-web-server node launcher + both systemd --user units + web-init.sh + web.env.example), gated behind `%bcond_with web`. OFF by default because building the Nitro/Node SSR bundle needs `bun`, which a plain rpmbuild / COPR mock chroot lacks. Host package weak-Recommends punktfunk-web. - ci/fedora-rpm.Dockerfile: install bun (+ unzip) so the CI builder can build the console. - rpm.yml: build `PF_WITH_WEB=1` (Prep bootstraps bun to stay green pre-image-rebuild); the publish loop already globs the new noarch rpm into the registry. build-rpm.sh: `--with web` when PF_WITH_WEB=1. - bootc/Containerfile: install from the Gitea RPM registry (which carries punktfunk-web) instead of COPR — `dnf5 install punktfunk punktfunk-web`. - arch/PKGBUILD: opt-in `punktfunk-web` split member (PF_WITH_WEB=1 appends it + bun) so a default makepkg still builds host+client with no JS tooling — matching the spec's bcond. - docs: packaging/README, rpm/README, copr/README (the no-bun caveat), bazzite/README (Path B rewritten COPR→Gitea registry), arch/README — enable + journal-password steps. Reviewed across methods by an adversarial multi-agent pass (rpm/ci/arch/bootc/consistency lenses, each blocking finding 3x-verified); fixed the two it confirmed real — the Arch bun-mandatory regression (now opt-in) and the stale COPR wording in bazzite Path B. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-15 09:56:58 +00:00
enricobuehler	df005e2963	feat(packaging/web): bundle the web console into the apt install (punktfunk-web) ... Every user needs the console for pairing, so ship it via apt, auto-wired to the host — no manual bun/env setup. New punktfunk-web .deb (Architecture: all, Depends: nodejs >= 20 — runs the node-server build under apt-native node, no bundled bun): - packaging/debian/build-web-deb.sh: stages web/.output (server + public) + a /usr/bin/punktfunk-web-server wrapper (node) + the systemd --user units + the web.env template + docs. Refuses a bun bundle (Bun.serve) as a wrong-preset guard. - scripts/punktfunk-web.service: --user unit on :3000, EnvironmentFile sources the host's ~/.config/punktfunk/mgmt-token (the shared bearer) + the generated web-password; sets PUNKTFUNK_MGMT_URL=https://127.0.0.1:47990 + NODE_TLS_REJECT_UNAUTHORIZED=0 (loopback self-signed cert). Restart=on-failure rides out the host-writes-token-first ordering. - scripts/punktfunk-web-init.service + web-init.sh: --user one-shot that generates the login password (a .deb postinst runs as root → wrong $HOME) and surfaces it to the journal. - build-deb.sh: punktfunk-host now Recommends punktfunk-web (apt pulls it by default; headless boxes opt out with --no-install-recommends). - deb.yml: build the web console + smoke-boot it under node (gate the .deb on a real /login 200) + build-web-deb.sh; the publish loop globs it automatically. - web/{.env.example,web.env.example}: document the auto-wiring vs a manual deploy. End state: `apt install punktfunk-host` pulls punktfunk-web; enable both --user services; the console logs in (password from the journal) and proxies the host's HTTPS mgmt API with the shared token — zero hand-edited env. Local .deb build + node smoke-boot verified. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-15 08:50:40 +00:00
enricobuehler	8534959021	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
enricobuehler	8956bc14de	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
enricobuehler	f869b434ba	fix(host): input follows session per-connect + restore-guard on desktop switch ... Two fixes from live Bazzite testing of the managed-Gaming + mid-stream work: 1. Input now FOLLOWS the active session. The host-lifetime injector was pinned to the first backend it opened and only reopened on an inject FAILURE — but with Feature A keeping the managed gamescope warm, its EIS socket stays alive, so a switch to the KDE desktop + reconnect kept injecting into the idle gamescope (input silently dead on KDE). injector_service_thread now compares the resolved input backend (default_backend() ← PUNKTFUNK_INPUT_BACKEND, set per connect by apply_input_env, and on a mid-stream switch) each event and reopens when it changes. Fixes input on a Gaming->Desktop reconnect AND Feature B's mid-stream input re-route, with no plumbing. 2. Debounced TV-restore no longer yanks you back to gaming. do_restore_tv_session now checks detect_active_session(): if a desktop session is active (the user switched), it tears down the idle managed gamescope but does NOT restart the gaming autologin. Observed live: the restore fired and restarted gamescope-session-plus@ogui-steam while the client was already on the KDE desktop. Also: document PUNKTFUNK_SESSION_WATCH (Feature B opt-in) in the Bazzite host.env and correct the managed-default description. Compiles, clippy/fmt clean, 78 tests. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 23:14:36 +00:00
enricobuehler	c25706b355	feat(host/gamescope): managed-default Gaming with debounced TV-restore ... Feature A: in Gaming Mode, default to a host-managed gamescope at the CLIENT's mode (tear the TV's autologin down on connect) instead of attaching to the running TV session — so the client receives ITS resolution (capture == encode == client mode, fixing the InitializeEncoder size mismatch the attach path hit), not the TV's 4K. Reliability is the debounce: restore_managed_session() now SCHEDULES the TV restore RESTORE_DEBOUNCE (5s) after the last disconnect via a host-lifetime worker, instead of restoring immediately per-disconnect. A reconnect inside the window cancels the pending restore and reuses the still-warm managed session (create_managed_session clears PENDING_RESTORE at the top) — so a quick reconnect (e.g. a controller hiccup) never triggers a gamescope stop/relaunch, which is the per-connect churn that leaked NVIDIA GPU context on F44 (the black-screen reconnect). - vdisplay/gamescope.rs: PENDING_RESTORE + RESTORE_DEBOUNCE; schedule_restore_tv_session (debounced), do_restore_tv_session (the actual restore, worker-driven), start_restore_worker (100ms tick, RAII keepalive handle). create_managed_session cancels the pending restore + reuse path unchanged. - vdisplay.rs: apply_input_env flips gamescope to managed-DEFAULT; PUNKTFUNK_GAMESCOPE_ATTACH (or an explicit _NODE) opts back to attach for couch-on-TV; _MANAGED forces managed. restore_managed_session schedules; new start_restore_worker wrapper. - m3.rs serve(): hold the restore worker for the host lifetime. - bazzite host.env: document managed-default + the ATTACH opt-out. Compiles, clippy-clean, 78 host tests pass. F44 single stop/start leak to be verified live on the box. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 22:34:33 +00:00
enricobuehler	66c2bee183	feat(packaging/bazzite): one-shot KDE Desktop-mode setup for the host ... The session-aware selector drives a KWin virtual output at the client's resolution when the Bazzite box is in KDE Desktop Mode — validated live. But a normal KDE login withholds two things the headless host needs: 1. KWIN_WAYLAND_NO_PERMISSION_CHECKS=1 — so KWin exposes the privileged zkde_screencast virtual-output protocol to an external client. 2. the kde-authorized RemoteDesktop grant — so libei input auto-approves instead of popping a dialog a headless host can't answer. Add packaging/bazzite/kde-desktop-setup.sh (idempotent, no root): writes the environment.d KWIN drop-in and seeds the grant DB (shipped at /usr/share/punktfunk/headless/kde-authorized) into ~/.local/share/flatpak/db/, restarting the portal chain. Ship it via the RPM at /usr/share/punktfunk/bazzite/ and document it in the Bazzite README (new §6.5). Gaming Mode needs none of this (auto-attach). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 22:26:21 +00:00
enricobuehler	6f77574876	feat(host/vdisplay): per-connect active-session backend selection ... Bazzite/SteamOS boxes flip between Steam Gaming Mode (gamescope) and a KDE/GNOME desktop. The host statically read PUNKTFUNK_COMPOSITOR / XDG_CURRENT_DESKTOP once, so switching to Desktop Mode failed the stream, and the gamescope managed-session path stopped+relaunched the autologin per connect — leaking GPU context on F44 (reconnect → black screen). Replace the static read with a runtime probe of the live session and route each connect to the right backend, churn-free: - vdisplay::detect_active_session() probes /proc for the running compositor of our uid (gamescope|kwin_wayland|gnome-shell|sway, desktop outranks a leftover gamescope) + scans the runtime dir for the live wayland-* socket. Returns an ActiveKind + the SessionEnv (WAYLAND_DISPLAY/XDG_RUNTIME_DIR/DBUS/ XDG_CURRENT_DESKTOP) that targets it. - apply_session_env() writes that into the process env per connect (host serves one session at a time), so every backend (capture + input) opens against the live session; apply_input_env() points input at the matching backend and selects gamescope ATTACH (no managed restart) unless PUNKTFUNK_GAMESCOPE_MANAGED. - resolve_compositor() (native path) auto-detects + applies; explicit PUNKTFUNK_COMPOSITOR still wins (legacy/CI/forcing). detect() is now active-aware for the GameStream/mgmt callers too. - Bazzite host.env drops the static gamescope force; documents auto-detection + the optional overrides. Result: Desktop Mode → KWin/Mutter virtual output at the client's mode (churn-free, the reliable path); Gaming Mode → attach to the running gamescope (no SIGSEGV/GPU leak on reconnect). Compiles + clippy-clean; 78 host tests pass. Live validation on the Bazzite box pending (box offline). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 21:41:51 +00:00
enricobuehler	ee7984beb0	feat(packaging/arch): split package — add punktfunk-client for the Deck ... The Decky plugin (b3f98a5) launches `punktfunk-client`, but the Arch package only shipped the host, so the Deck had nothing to launch. Convert the PKGBUILD to a split package (pkgbase=punktfunk → punktfunk-host + punktfunk-client), mirroring the rpm subpackages and the two deb build scripts: - punktfunk-host: unchanged artifact set + NVENC/compositor optdepends. - punktfunk-client: the GTK4 binary + io.unom.Punktfunk.desktop + the hidraw udev rule + the 32MB recv-buffer sysctl; depends gtk4/libadwaita/sdl3/ffmpeg/pipewire/ opus; optdepends libva-mesa-driver (VAAPI decode on the Deck's AMD APU, software fallback otherwise). New punktfunk-client.install scriptlet. - build-sysext.sh now derives the package name from the file, so it wraps either the host OR the client into a systemd-sysext .raw — on a Deck you wrap the client. - README: split-package usage + a "Steam Deck (the client)" section tying the sysext to the Decky plugin (client is on PATH → plugin launches `punktfunk-client --connect host:port`). Clarified the VAAPI gap is host-ENCODE only; the client DECODES via VAAPI on the Deck today, so streaming to a Deck works now. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 13:09:10 +00:00
enricobuehler	c548155dd9	feat(packaging/arch): Arch + SteamOS install target (PKGBUILD + sysext) ... Add packaging/arch: a PKGBUILD mirroring the rpm/deb artifact set (binary, udev rule, 32MB sysctl, systemd USER units with ExecStart rewritten, headless helpers, env templates, openapi), a pacman .install scriptlet, a systemd-sysext builder for immutable SteamOS, and a README. Builds the working tree via PF_SRCDIR (CI/dev) or a git tag (AUR). Arch's stock ffmpeg already ships NVENC, so deps collapse to ~10 packages with nvidia-utils/compositors as optdepends (never hard-depend on the driver, same invariant as rpm/deb). SteamOS delivery is a **systemd-sysext** (overlays /usr read-only from writable /var/lib/extensions/, survives A/B OS updates, no steamos-readonly disable) — pacman/distrobox/flatpak are all unsuitable for a host that needs uinput/uhid, the host PipeWire socket, the GPU node, and to spawn a compositor. KNOWN GAP, documented prominently: encode is NVENC-only (src/encode/linux.rs has no VAAPI backend), so this works on Arch+NVIDIA (and bazzite-deck-nvidia) but an AMD Steam Deck installs yet cannot encode until a hevc_vaapi backend is written — a code change, not packaging. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 11:43:48 +00:00
enricobuehler	9f92dc505b	fix(client/pkg): ship 32MB UDP recv-buffer sysctl with the Linux client ... The client asks the kernel for a 32 MB SO_RCVBUF, but the kernel silently clamps it to net.core.rmem_max — whose default is far too small. A too-small recv buffer is the dominant client-side wall above ~1 Gbps. Measured live (Fedora host -> two clients, real 2.5G LAN, GSO off): a client capped at 4 MB rmem_max dropped 31.6% of a 2 Gbps stream at the receiver, while a 32 MB client delivered the same 2 Gbps at 0.0% loss. The host already shipped this tuning; the client packages didn't (the RPM's %post even referenced the host-only file), so a client-only install streamed lossy at high bitrate. Add scripts/99-punktfunk-client-net.conf (rmem/wmem = 32 MB, distinct filename so host+client can coexist) and ship+apply it from both the .deb (build-client-deb.sh) and the RPM client subpackage (install, %files client, %post client). For reference the full ladder (punktfunk speed-test): 0% loss to 1.5 Gbps on a 4 MB client; 31.6% at 2 Gbps on 4 MB vs 0% at 2 Gbps on 32 MB. iperf3 put the raw link at ~2.35 Gbps TCP / ~2.4 Gbps UDP, so the stack now tracks the wire given a big enough recv buffer. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 08:45:19 +00:00
enricobuehler	c2ae40ef9e	feat(net/mac): default-on recvmsg_x batched Mac recv + GSO host + longer probe ... The Mac/iOS client's wall around ~380 Mbps on a 2.5 G path is the receive drain, not the transport: a loopback speed-test pushes 380/600/1000 Mbps at 0.0% loss, but Darwin has no recvmmsg(2), so the macOS client was doing one recv() syscall per packet — ~40-90k syscalls/s on one core. When the recv loop can't drain fast enough the kernel socket buffer backs up and drops, which the client sees as a sustained stream stalling/freezing in the 300-400 Mbps range (and an immediate "session ended" when a 500 Mbps+ first keyframe bursts in). - core/transport: flip recvmsg_x (the batched Darwin recv, ~30x fewer syscalls) from opt-in to default ON, opt-out via PUNKTFUNK_RECVMSG_X=0. Keeps the auto-fallback to the scalar loop on any unexpected syscall error. The Apple CI swift-test loopback now exercises this path by default. - packaging/kde host.env: enable PUNKTFUNK_GSO=1 — UDP segmentation offload on the host send path (one sendmsg per ~64 packets), the dominant lever above ~1 Gbps. Already wired (send_sealed -> send_gso) with sendmmsg auto-fallback. - apple SpeedTestSheet: lengthen the bandwidth probe 2 s -> 5 s so the measured number stops swinging wildly (50 vs 900 Mbps on the same link) — long enough for steady-state send + recv drain to settle. Matches host MAX_PROBE_MS. - host capture: PUNKTFUNK_SYNTH_NOISE synthetic high-entropy source for reproducible throughput testing of the encode->FEC->send->recv path. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 00:35:26 +00:00
enricobuehler	5bc257f1ae	fix(headless/kde): virtual Punktfunk speaker + restart host with the session ... Audio: a headless host has no speakers, and on a LAN with AirPlay devices PipeWire picks a random HomePod as default — so desktop audio (which the host captures from the default sink's monitor) went to a HomePod over AirPlay instead of to the client, and there was no "Punktfunk" output to select. Ship a `punktfunk-sink.conf` (a `support.null-audio-sink` adapter — NOT the non-existent module-null-sink, which makes pipewire refuse to start) with high priority.session so it's the default; run-headless-kde.sh installs it and restarts pipewire once on first install. The host then captures its monitor and streams it. (Disable AirPlay sinks out of band: `dnf remove pipewire-config-raop`.) Input: the host's libei portal D-Bus connection goes stale when the compositor session restarts the portal under it, and the in-process reopen loop can't recover it (EIS setup keeps timing out) — only a full restart does. Add PartOf=punktfunk-kde-session.service so the host restarts with the session. Both verified live on the Fedora 44 KDE box. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 23:30:36 +00:00