16 Commits

Author	SHA1	Message	Date
enricobuehler	125a51d81d	feat(windows-installer): move driver + web install into the host exe (ASCII root fix) ... Port the three install-time PowerShell *files* (install-pf-vdisplay.ps1, install-gamepad-drivers.ps1, web-setup.ps1) into punktfunk-host.exe subcommands: `driver install [--gamepad] --dir <stage>` and `web setup --app-dir <app> [--password-file <f>]` (windows/install.rs). Why: PowerShell 5.1 reads a BOM-less .ps1 FILE in the machine ANSI codepage, so a stray non-ASCII byte mis-decodes and aborts on a non-English box - exactly how the pf-vdisplay driver install silently failed. A compiled subcommand drives the same external tools (certutil/pnputil/nefconc/schtasks/netsh/icacls) as fixed string literals, with no file-codepage surface. (The .iss's INLINE -Command PowerShell is a command-line string, not a file read, so it's unaffected and stays.) - windows/install.rs: faithful port - cert trust, gated nefconc node create + pnputil for pf-vdisplay; pnputil per-inf for gamepads; web-password ACL, the PunktfunkWeb task (generated UTF-16 XML), firewall rule, start. Best-effort (a hiccup warns, never aborts). - punktfunk-host.iss [Run]: call the exe instead of `powershell -File`; drop the web-setup.ps1 staging + WebSetup define; WebSetupParams emits --app-dir/--password-file. - pack-host-installer.ps1: stop copying the three install scripts into the stages. - delete the three .ps1 files. The `mod install;` + dispatch arms in main.rs landed in the preceding docs commit (swept up by a concurrent commit); this commit adds the module + installer wiring. CI-compile-validated via windows-host; the install path is on-glass-validated on the next canary install (the test box is offline). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 16:43:18 +00:00
enricobuehler	a9cca82fb8	chore(windows): clean up build/packaging - drop vendored driver binaries + the LLVM-21 pin ... Now that the drivers build from source in CI, remove the dead checked-in binaries and the toolchain cruft they left behind: - Delete packaging/windows/{pf-vdisplay,gamepad-drivers}/ (the prebuilt .dll/.inf/.cat/.cer). pack-host-installer.ps1 builds + signs all three drivers from the drivers/ workspace and nothing reads the vendored dirs anymore; stage-pf-vdisplay.ps1's -VendorDir is now a mandatory build-output path, not a vendored default. - Drop the LLVM-21 pin. The vendored bindgen 0.71->0.72 bump (the shipping pack already builds green on the runner-default clang 22) retired the bindgen-0.71 layout-test overflow that needed LLVM 21.1.2, so windows-drivers.yml + provision-windows-wdk.ps1 no longer install/point at C:\llvm-21 (~898 MB off a fresh provision) - both driver builds now use one toolchain (clang 22 + bindgen 0.72). - pack -SkipBuild on the gamepad build (build-pf-vdisplay.ps1 already builds the whole workspace), build-web.ps1 reaps a stale node too, deploy-dev.ps1 nefconc path + comments. - Reword the vendored-driver references (build scripts, .iss, READMEs, the vite web-bundle comment) to the build-from-source reality. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 16:16:46 +00:00
enricobuehler	92e68024f1	fix(windows-installer): build the gamepad drivers from source in CI too ... Fold the pf-dualsense (DualSense / DualShock 4) and pf-xusb (Xbox 360 / XInput) UMDF drivers into the in-tree drivers workspace (their source had stale ../../crates/wdk-* path-deps from before the wdk vendoring reorg and could no longer build at all) and build them from source per release, exactly like pf-vdisplay - same anti-stale reasoning. One `cargo build --release` now builds all three drivers against the vendored wdk-sys (incl. the bindgen 0.72 pin), and build-gamepad-drivers.ps1 signs pf_dualsense + pf_xusb (clear FORCE_INTEGRITY -> sign dll -> stampinf -> Inf2Cat -> sign cat) with one shared cert + .cer, matching the layout install-gamepad-drivers.ps1 expects. pack-host-installer.ps1 builds + stages them instead of the retired checked-in binaries. Validated on the runner: the whole workspace (pf-vdisplay + pf-dualsense + pf-xusb) builds with CARGO_TARGET_DIR=C:\t set, and build-gamepad-drivers.ps1 produces signed pf_dualsense.{dll,inf,cat} + pf_xusb.{dll,inf,cat} + the .cer. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 15:08:40 +00:00
enricobuehler	bdfab8e0d5	fix(windows-installer): build pf-vdisplay from source in CI; ASCII scripts; upgrade-safe web console ... The pf-vdisplay virtual-display driver shipped as a checked-in PREBUILT binary that went stale - two field failures on a fresh install (live-repro'd on a German-locale Dell laptop): * Bug A (every box): a repo-wide rename edited the vendored pf_vdisplay.inf but never re-signed pf_vdisplay.cat, so the catalog stopped covering the INF -> `pnputil /add-driver` fails SPAPI_E_FILE_HASH_NOT_IN_CATALOG -> driver never installs -> every session dies "pf-vdisplay driver interface not found". * the prebuilt binary also predated IOCTL_SET_RENDER_ADAPTER (added to the driver source after the vendor freeze) that the host needs to pin the IDD render GPU on hybrid/Optimus boxes. Fix: build the driver FROM SOURCE every release (build-pf-vdisplay.ps1, wired into pack-host-installer.ps1) so .dll/.inf/.cat are always in lockstep and current driver features ship. The runner's clang 22 made the driver's pinned bindgen 0.71 emit opaque structs (157 layout-assert errors), so bump the vendored wdk-sys/wdk-build bindgen 0.71 -> 0.72 (+ lock). The build self-signs the driver per build (installer trusts the bundled .cer); a stable DRIVER_CERT_PFX_B64 secret can override. * Bug B (non-English boxes): the installer runs install-pf-vdisplay.ps1 etc. via powershell.exe (5.1), which reads a BOM-less script in the ANSI codepage - an em-dash's trailing 0x94 byte becomes a curly quote on German Windows-1252 and the script aborts "unterminated string", so the driver never installed (the gamepad script survived only because it was already ASCII). Scrub every installer-run .ps1/.cmd to ASCII + add a CI gate that fails on any non-ASCII so it can't regress. * Bug C (upgrades): nothing stopped the OLD web console before re-registering its task, so a stale server kept :3000 (the new one restart-looped on EADDRINUSE) and served a broken old bundle (500 on /login). Stop + reap it (runtime-agnostic, by the :3000 listener owner) in web-setup.ps1 and in the .iss before the file copy + on uninstall. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 14:33:34 +00:00
enricobuehler	d01a8fd17a	feat(host): HDR Vulkan layer so Vulkan games get HDR on the virtual display ... NVIDIA/AMD Vulkan ICDs refuse to *advertise* an HDR color space for a surface on an IddCx indirect/virtual display, so Vulkan games (Doom: The Dark Ages, id Tech, Indiana Jones, …) report "device does not support HDR" — even though Windows HDR, DWM compose, and the client PQ stream all work, and the ICD happily *accepts + presents* a forced HDR swapchain there. The whole gap is enumeration; the community (Apollo/Sunshine/VDD) wrote this off as kernel-side / unfixable. Add VK_LAYER_PUNKTFUNK_hdr_inject (packaging/windows/pf-vkhdr-layer/): a standalone cdylib Vulkan implicit layer that appends {A2B10G10R10, HDR10_ST2084} + {RGBA16F, scRGB} to vkGetPhysicalDeviceSurfaceFormats[2]KHR (no need to hook vkCreateSwapchainKHR — the ICD doesn't validate the color space there). Self-gated on the surface monitor's actual advanced-color state (DisplayConfig GET_ADVANCED_COLOR_INFO), so it is a complete no-op on SDR sessions and real monitors (dedup). Always-on (registry-discovered) so it works regardless of how a game is launched — env-scoping silently fails for already-running Steam. Escape hatches: DISABLE_PF_VKHDR, PF_VKHDR_EXCLUDE, and a built-in kernel-anti- cheat denylist. The installer builds/signs/stages it and registers it under HKLM64\SOFTWARE\Khronos\Vulkan\ImplicitLayers (opt-out "Install the HDR Vulkan layer" task); windows-host CI fmt+clippy-gates it (msvc-only FFI). Live-validated on the RTX box: Doom: The Dark Ages enables HDR over the pf-vdisplay virtual display. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 11:33:20 +00:00
enricobuehler	6b3cbce120	wip: host latency/GPU-contention notes + Windows packaging tweaks ... Pre-existing working-tree changes committed to the branch on request: the gpu-contention investigation doc, host-latency-plan additions, and small pack-host-installer / stage-pf-vdisplay packaging-script edits. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 06:53:09 +00: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	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	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	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	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