The pf-vdisplay driver now advertises HDR/FP16 and the full glass-to-glass HDR path works end-to-end — validated LIVE: the Mac client connected to the .173 host WITH HDR (display_hdr=true, FP16 ring -> NVENC P010). The STEP-3 assumption that FP16 needs a higher UmdfExtensions was WRONG: IddCx0102 + CAN_PROCESS_FP16 + the *2 DDIs works (the oracle proved it; confirmed on-glass IddCxAdapterInitAsync -> 0x0 WITH the FP16 cap set). Driver-only change — the host FP16-ring -> NVENC-P010 path and the HDR EDID were already in place. - adapter.rs: caps.Flags = IDDCX_ADAPTER_FLAGS_CAN_PROCESS_FP16. - entry.rs: register the 6 *2/HDR callbacks (ParseMonitorDescription2, MonitorQueryTargetModes2, AdapterCommitModes2, AdapterQueryTargetInfo, MonitorSetDefaultHdrMetaData, MonitorSetGammaRamp) ALONGSIDE the v1 set (matching the oracle — CAN_PROCESS_FP16 OBLIGATES the *2 DDIs or the framework rejects the adapter at init; STEP 3 rejected FP16 only because they weren't registered). - callbacks.rs: parse_monitor_description2 + monitor_query_modes2 now fill IDDCX_MONITOR_MODE2 / IDDCX_TARGET_MODE2 with BitsPerComponent (8|10 bpc RGB); query_target_info already reports IDDCX_TARGET_CAPS_HIGH_COLOR_SPACE; set_default_hdr_metadata + set_gamma_ramp accept (the gamma one is mandatory under FP16). - monitor.rs: wire_bits() (Rgb 8|10, no YCbCr) + target_mode2(). - EDID + INF UNCHANGED (the EDID already carries the CTA-861.3 BT.2020 + ST.2084/PQ block; the INF stays UmdfExtensions=IddCx0102). Built via the ultracode flow (STEP-7 map workflow -> agent-implement -> box build [driver green] -> deploy -> on-glass HDR). OPERATIONAL NOTE: do NOT Disable/Enable the IddCx devnode to reload it — that leaves the adapter STOPPED in the persisted WUDFHost process (ADAPTER OnceLock survives), so monitor-create then fails with 0xc00002b6 (INDIRECT_DISPLAY_DEVICE_STOPPED). Kill the pf_vdisplay WUDFHost process (or reboot) for a clean adapter re-init. This completes the pf-vdisplay rewrite STEP 0-7, all on-glass validated (loads, adapter inits, monitor appears, swap-chain drain, IDD-push frames at ~235fps, and HDR). Remaining: STEP 8 (unsafe- reduction + delete the old vdisplay-driver tree + the vendored SudoVDA driver + unbundle from the installer = the SudoVDA drop). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Windows host packaging — signed Inno Setup installer
A one-file, signed setup.exe for the punktfunk streaming host on Windows, published to Gitea's
generic package registry (punktfunk-host-windows) by .gitea/workflows/windows-host.yml.
x64 only (no ARM64)
Unlike the client (which ships x64 + ARM64 MSIX), the host is x64-only by design. It is coupled to
an NVIDIA GPU (NVENC, via nvEncodeAPI64.dll from the driver) and the pf-vdisplay virtual-display
driver — neither exists on Windows ARM64 (no ARM64 NVIDIA driver; the driver builds x64-only). An
ARM64 host would install but couldn't encode or create a virtual display, so we don't build one.
Revisit if NVIDIA-ARM Windows PCs ever ship.
Why not MSIX (like the client)
The host installs a LocalSystem SCM service that CreateProcessAsUserW's from Session 0 into the
interactive session for secure-desktop (UAC / lock screen) capture, adds firewall rules, and depends
on the pf-vdisplay UMDF/IDD virtual-display driver. MSIX's sandbox can install neither a SYSTEM
service of this kind nor a driver. So the host ships as a classic elevated installer.
The installer is deliberately thin: the real install logic — SCM registration, firewall rules, the
default host.env, and the SYSTEM→interactive-session supervisor — already lives in
punktfunk-host service install (crates/punktfunk-host/src/service.rs). The installer just lays the
exe into C:\Program Files\punktfunk\ and calls that subcommand, elevated.
What the installer does
- Installs
punktfunk-host.exe(+host.env.example, this README) to{app}(C:\Program Files\punktfunk). - Optional task Install the pf-vdisplay virtual display driver — imports the driver's self-signed
cert (machine
Root+TrustedPublisher), creates theroot\pf_vdisplaydevice node (only if absent, via nefconc — never devgen —install-pf-vdisplay.ps1), and stages the driver withpnputil /add-driver /install. Best-effort: a driver failure warns but never aborts the install (the host degrades to a physical display without it). - Runs
punktfunk-host service install(idempotent; writes a defaulthost.envonly if absent, so user config survives upgrades) and, by the Start service now task,service start. - Web management console (bundled when packed with
-WebDir/-BunExe, which the CI always is): lays down the built self-contained.outputserver (NitronoExternals— deps bundled + tree-shaken, ~75 files, nonode_modules) + a portable bun, prompts for a console login password (pre-filled with a secure random default, shown again on the final page; kept on upgrade), thenweb-setup.ps1writes the ACL'd%ProgramData%\punktfunk\web-password, registers thePunktfunkWebscheduled task (boot, SYSTEM, restart-on-failure →web-run.cmd→bunon:3000), opens TCP 3000, and starts it. It proxies the host's loopback mgmt API with the host's own%ProgramData%\punktfunk\mgmt-token. - Upgrade: stops a running
PunktfunkHostservice and waits forSTOPPEDbefore replacing files (otherwise the locked exe / respawning supervisor would block the copy), then re-points the service; the existing console password is kept (the wizard page is skipped). - Uninstall (Add/Remove Programs): runs
service uninstall(stop + delete service + remove firewall rules) and removes thePunktfunkWebtask + its firewall rule. The pf-vdisplay driver and the%ProgramData%\punktfunkconfig (incl.web-password) are intentionally left in place.
Silent install: punktfunk-host-setup-<ver>.exe /VERYSILENT (omit the driver with
/MERGETASKS="!installdriver"). A silent fresh install uses the generated random console password —
read it from %ProgramData%\punktfunk\web-password.
Prerequisites on the target box
- A GPU for hardware encode: an NVIDIA GPU + driver (NVENC), or an AMD/Intel GPU (AMF/QSV) — the
exe is built
--features nvenc,amf-qsv. Software H.264 is the GPU-less fallback. - Virtual gamepads need no prerequisite. The DualSense / DualShock 4 / Xbox 360 (XUSB) UMDF drivers
are bundled in the installer (the Install the virtual gamepad drivers task) and
pnputil-installed. ViGEmBus is no longer used.
Files here
| File | Role |
|---|---|
punktfunk-host.iss |
Inno Setup script (the installer definition). |
pack-host-installer.ps1 |
Orchestrator: cert + sign, stage the driver + FFmpeg + web console (.output + bun) bundles, run ISCC, sign setup.exe, emit registry paths. |
stage-pf-vdisplay.ps1 |
Stage the vendored pf-vdisplay driver + fetch/verify the pinned nefcon release into the bundle. |
install-pf-vdisplay.ps1 |
Runs at install time (elevated): trust cert → gated device-node create (nefconc) → pnputil install. |
../../scripts/windows/web-run.cmd |
The PunktfunkWeb task action: loads the mgmt token + login password env, runs the bundled bun on the Nitro server (:3000). |
../../scripts/windows/web-setup.ps1 |
Install-time (elevated): write the ACL'd console password, register the PunktfunkWeb task + firewall rule, start it. |
pf-vdisplay/ |
Vendored signed pf-vdisplay driver: pf_vdisplay.inf / pf_vdisplay.cat / pf_vdisplay.dll / punktfunk-driver.cer. Built from vdisplay-driver/. |
vdisplay-driver/ |
The all-Rust IddCx driver source (pf-vdisplay crate + vendored wdf-umdf* bindings) + deploy-dev.ps1 (build/sign/install for dev). |
nvenc/nvenc.def, nvenc/gen-nvenc-importlib.ps1 |
Synthesise nvencodeapi.lib for the --features nvenc link (llvm-dlltool / lib.exe). |
Vendored driver: pf-vdisplay is our all-Rust IddCx virtual display (UMDF2), built from
packaging/windows/vdisplay-driver/. It replaced the vendored SudoVDA C++ driver — full story indocs/windows-virtual-display-rust-port.md. The signed output (pf_vdisplay.dll/.inf/.cat+punktfunk-driver.cer; signerpunktfunk-ds-test— the same cert the gamepad drivers ship, Class=Display, HWIDroot\pf_vdisplay) is checked in underpf-vdisplay/. To refresh it after a driver-source change, rebuild + re-sign withvdisplay-driver/deploy-dev.ps1and copy the stagedpf_vdisplay.{dll,inf,cat}over the vendored copies. nefcon (the device-node tool — the install creates the node with it, neverdevgen, which leaves persistent phantom devices) is fetched + SHA-256-verified from its pinned release instage-pf-vdisplay.ps1.
Build locally (Windows, MSVC + Windows SDK + Inno Setup)
# 1. import lib for the nvenc link
pwsh -File packaging\windows\nvenc\gen-nvenc-importlib.ps1 -OutDir C:\t\nvenc
$env:PUNKTFUNK_NVENC_LIB_DIR = 'C:\t\nvenc'
# 2. build the host
cargo build --release -p punktfunk-host --features nvenc
# 3. pack (self-signed unless MSIX_CERT_PFX_B64/MSIX_CERT_PASSWORD are set; -NoDriver to skip pf-vdisplay)
pwsh -File packaging\windows\pack-host-installer.ps1 -Version 0.0.0-dev -TargetDir C:\t\release -OutDir C:\t\out
Release
Push a vX.Y.Z tag — one tag releases every platform (see
Release Channels). The workflow builds, signs, and
publishes punktfunk-host-setup-X.Y.Z.exe + the public .cer, refreshes the stable latest/
alias, and attaches the installer to the unified Gitea Release. Main pushes publish rolling
0.3.<run> canary builds to the canary/ alias.