de232ec2f7
apple / swift (push) Successful in 1m0s
ci / rust (push) Successful in 1m18s
ci / web (push) Successful in 43s
ci / docs-site (push) Successful in 1m4s
android / android (push) Successful in 3m26s
deb / build-publish (push) Successful in 2m37s
apple / screenshots (push) Successful in 5m9s
decky / build-publish (push) Successful in 14s
docker / build-push (--build-arg FEDORA_VERSION=44, ci, ci/fedora-rpm.Dockerfile, punktfunk-fedora44-rpm) (push) Successful in 5s
docker / build-push (., web/Dockerfile, punktfunk-web) (push) Successful in 25s
docker / build-push (ci, ci/fedora-rpm.Dockerfile, punktfunk-fedora-rpm) (push) Successful in 4s
windows-host / package (push) Successful in 6m51s
docker / build-push (ci, ci/rust-ci.Dockerfile, punktfunk-rust-ci) (push) Successful in 4s
ci / bench (push) Successful in 4m35s
docker / build-push (docs-site, docs-site/Dockerfile, punktfunk-docs) (push) Successful in 47s
rpm / build-publish (fedora-44, punktfunk-fedora44-rpm) (push) Successful in 9m3s
rpm / build-publish (bazzite, punktfunk-fedora-rpm) (push) Successful in 9m8s
docker / deploy-docs (push) Successful in 19s
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>
79 lines
4.9 KiB
Markdown
79 lines
4.9 KiB
Markdown
---
|
|
title: "Windows Host"
|
|
description: "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](/docs/clients#windows-desktop-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](https://github.com/nefarius/ViGEmBus/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](/docs/running-as-a-service#windows); packaging internals live in
|
|
[`packaging/windows`](https://git.unom.io/unom/punktfunk/src/branch/main/packaging/windows/README.md).
|
|
|
|
The installer also sets up the **web management console** (status, paired devices, the PIN pairing
|
|
flow): it bundles the console plus its own bun 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](https://github.com/VirtualDrivers)** (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.
|