Files
punktfunk/docs-site/content/docs/windows-host.md
T
enricobuehler 5e106c51cf
apple / swift (push) Successful in 56s
ci / rust (push) Successful in 1m15s
ci / web (push) Successful in 39s
windows-host / package (push) Failing after 2m30s
ci / docs-site (push) Successful in 59s
android / android (push) Successful in 3m16s
deb / build-publish (push) Successful in 2m37s
decky / build-publish (push) Successful in 23s
docker / build-push (--build-arg FEDORA_VERSION=44, ci, ci/fedora-rpm.Dockerfile, punktfunk-fedora44-rpm) (push) Successful in 4s
docker / build-push (., web/Dockerfile, punktfunk-web) (push) Successful in 4s
docker / build-push (ci, ci/fedora-rpm.Dockerfile, punktfunk-fedora-rpm) (push) Successful in 4s
ci / bench (push) Successful in 4m40s
docker / build-push (docs-site, docs-site/Dockerfile, punktfunk-docs) (push) Successful in 46s
docker / build-push (ci, ci/rust-ci.Dockerfile, punktfunk-rust-ci) (push) Successful in 2m22s
rpm / build-publish (bazzite, punktfunk-fedora-rpm) (push) Successful in 8m25s
docker / deploy-docs (push) Successful in 22s
rpm / build-publish (fedora-44, punktfunk-fedora44-rpm) (push) Successful in 8m23s
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

4.9 KiB

title, description
title description
Windows Host Run the punktfunk streaming host on a Windows PC with an NVIDIA GPU.

Status: implemented and shipping — NVIDIA-only, x64-only. punktfunk is Linux-first, but it also runs as a native Windows host: a signed installer registers a LocalSystem service that streams your Windows desktop or games to any punktfunk or Moonlight client, at the client's exact resolution via a virtual display — including HDR10 (10-bit BT.2020 PQ) when your Windows desktop is in HDR mode. It's newer and less battle-tested than the Linux host, and it is built specifically around NVIDIA hardware. (The Linux host is 8-bit only — HDR there is blocked upstream.)

This page is about the Windows host (streaming from a Windows PC). To stream to a Windows PC, see the Windows client.

Requirements

  • Windows 10/11, x64. ARM64 is not supported — both NVENC and the virtual-display driver are x64-only.
  • An NVIDIA GPU + driver. The host encodes with NVENC (nvEncodeAPI64.dll); there is no other encoder backend on Windows.
  • (Optional) ViGEmBus for virtual gamepads — a manual prerequisite for now (releases).

Install

Download the signed punktfunk-host-setup-<ver>.exe from the package registry and run it — it installs the host into C:\Program Files\punktfunk, optionally installs the bundled SudoVDA virtual-display driver, and registers + starts the service. Full steps (including the silent install and the CLI punktfunk-host service install path) are in Running as a Service → Windows; packaging internals live in packaging/windows.

The installer also sets up the web management console (status, paired devices, the PIN pairing flow): it bundles the console plus its own Node runtime and runs it as the PunktfunkWeb service on http://<this-PC>:3000, starting at boot. During setup you choose the console login password (pre-filled with a secure random default and shown again on the final page); change it later in %ProgramData%\punktfunk\web-password. Open the console from any browser on the LAN and log in — no extra install, and the host's management API stays loopback-only behind it.

How it works

The host installs a LocalSystem SCM service that runs from Session 0 and launches a worker into the interactive session (CreateProcessAsUserW). That lets it capture the secure desktop (UAC prompts, the lock screen) and keep streaming across reboots with nobody logged in — the same model Sunshine and Apollo use. Service registration, firewall rules, and the supervisor all live in punktfunk-host service install; the installer just lays the exe down and calls it elevated.

One core, Windows backends

Most of punktfunk is platform-agnostic. punktfunk-core (protocol, FEC, crypto, session, transport, the C ABI), the QUIC control plane, the GameStream wire logic, the management API, and the per-frame pipeline orchestration are all shared with the Linux host. The Windows host is a set of #[cfg(windows)] backends behind the same traits the Linux host uses:

Subsystem Linux backend Windows backend
Capture xdg ScreenCast portal → PipeWire (dmabuf) Windows.Graphics.Capture (+ Desktop Duplication for the secure desktop) → D3D11 texture; FP16/10-bit when the desktop is HDR
Virtual display KWin / Mutter / Sway / gamescope SudoVDA signed IDD — create a WxH@Hz monitor per session, capture it, tear it down
Encode ffmpeg-next NVENC (CUDA hwframes) NVENC with a D3D11 device (--features nvenc); HEVC Main10 / BT.2020 PQ for HDR
Input — mouse/keyboard libei / wlr protocols SendInput (Win32 VK + absolute mouse)
Input — gamepads uinput Xbox 360 pad + rumble ViGEm virtual pad + rumble back-channel
Audio capture PipeWire sink-monitor WASAPI loopback
Virtual mic PipeWire Audio/Source WASAPI virtual mic

The virtual display uses SudoVDA (the Sunshine Virtual Display Adapter) — a pre-built, signed Indirect Display Driver — so there is no kernel driver to author or WHQL-sign. The installer bundles and stages it; if it's absent, the host falls back to capturing an existing monitor (losing the per-client native-resolution output).

Limitations

  • NVIDIA-only. NVENC is the only encoder backend — there is no AMD / Intel / software encode path on Windows.
  • x64-only. No ARM64 build (no ARM64 NVIDIA driver, and SudoVDA is x64-only).
  • Newer than the Linux host. The Linux host is the most battle-tested path; the Windows host is more recent, with the virtual-mic and gamepad backends the youngest pieces.