10 Commits

Author	SHA1	Message	Date
enricobuehler	00cf51d610	refactor: rename pf-vdisplay-proto -> pf-driver-proto (it spans all drivers) ... The shared host<->driver ABI crate already contains more than the virtual display: the IDD-push frame ring + control plane AND the gamepad shared-memory layouts (XusbShm / PadShm). "pf-vdisplay-proto" was a misnomer — the name now represents all the drivers it serves. Mechanical rename, no behavior change: - git mv crates/pf-vdisplay-proto -> crates/pf-driver-proto (package name + path-deps in the host crate and the driver workspace). - pf_vdisplay_proto -> pf_driver_proto across host + driver Rust, both Cargo.lock files, the workspace members, the CI path triggers (windows-drivers.yml), and the docs/INF comments. The runtime Global\pfvd-* shared-object names are a SEPARATE contract and are deliberately untouched (host<->driver name matching). - The pf-vdisplay DRIVER crate + its INF service name (Root\pf_vdisplay, UmdfService=pf_vdisplay, pf_vdisplay.dll) are unchanged — only the full `pf_vdisplay_proto` token was replaced, never the `pf_vdisplay` driver name. Linux-verified: cargo test -p pf-driver-proto (const size-asserts compile) + cargo clippy -p punktfunk-host -D warnings clean; Cargo.lock regenerated. The driver-workspace side (path-dep + imports + its Cargo.lock) is Windows-CI-gated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 05:38:21 +00:00
enricobuehler	e119aa50e9	feat(windows-packaging): dev-iteration scripts — reset + redeploy pf-vdisplay driver ... Today's manual driver recovery (wedged under ADD/REMOVE churn → ERROR_NOT_FOUND) and the manual host-stop/install/host-start dance around drivers/deploy-dev.ps1 are now two scripts: * reset-pf-vdisplay.ps1 — recover a wedged driver: stop host → pnputil /remove-device the ghost "Generic Monitor (punktfunk)" nodes → Disable+Enable the adapter (Restart-PnpDevice doesn't exist on the box PS) → start host. No reboot (the box boots to Proxmox). -Verify probes to confirm ADD recovered. * redeploy-pf-vdisplay.ps1 — one-shot dev redeploy wrapping deploy-dev.ps1 with the host stop/start (the running host holds the driver DLL) + a post-install adapter reload (pnputil updates the store but the live device keeps the old binary). Both standalone (don't touch deploy-dev.ps1). README gains a "Dev iteration on the test box" section. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 20:48:32 +00:00
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	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	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	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	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	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