enricobuehler
0eedfb3c1f
apple / swift (push) Failing after 0s
apple / screenshots (push) Has been skipped
windows-drivers-provision / provision (push) Successful in 13s
windows-drivers / probe-and-proto (push) Successful in 17s
windows-drivers / driver-build (push) Successful in 1m10s
android / android (push) Successful in 3m19s
ci / web (push) Successful in 39s
ci / docs-site (push) Successful in 53s
windows-host / package (push) Successful in 6m6s
ci / bench (push) Successful in 5m9s
ci / rust (push) Successful in 11m12s
decky / build-publish (push) Successful in 11s
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 21s
docker / build-push (ci, ci/fedora-rpm.Dockerfile, punktfunk-fedora-rpm) (push) Successful in 3s
docker / build-push (ci, ci/rust-ci.Dockerfile, punktfunk-rust-ci) (push) Successful in 4s
docker / build-push (docs-site, docs-site/Dockerfile, punktfunk-docs) (push) Successful in 43s
deb / build-publish (push) Successful in 7m31s
rpm / build-publish (bazzite, punktfunk-fedora-rpm) (push) Successful in 9m14s
rpm / build-publish (fedora-44, punktfunk-fedora44-rpm) (push) Successful in 9m12s
release / apple (push) Failing after 1s
docker / deploy-docs (push) Successful in 19s
flatpak / build-publish (push) Successful in 4m43s
Drop the "Linux-first" framing across the README and docs site in favor of first-class Linux AND Windows hosts, and surface the Windows IDD-push virtual-display path as a distinct differentiator (punktfunk's own indirect display driver the host pushes frames into — a real virtual display, no physical monitor or dummy plug, even on the secure desktop). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
72 lines
3.6 KiB
Markdown
72 lines
3.6 KiB
Markdown
---
|
|
title: How It Works
|
|
description: The ideas behind punktfunk — per-client virtual displays, the two protocols, and trust.
|
|
---
|
|
|
|
You don't need to know any of this to use punktfunk, but it helps to understand what's happening
|
|
when you connect.
|
|
|
|
## A virtual display, sized to your device
|
|
|
|
When a client connects, the host asks your desktop to create a **new virtual display** at exactly the
|
|
client's resolution and refresh rate, captures that display, and streams it. The virtual display is
|
|
real to your desktop — apps can be moved onto it, games open on it — but it isn't tied to any physical
|
|
monitor. When the client disconnects, the virtual display goes away.
|
|
|
|
That's why a 1080p60 laptop and a 1440p120 desktop can stream from the same host **at the same time**,
|
|
each at its own mode — they each get their own virtual display.
|
|
|
|
How the virtual display is created depends on your host:
|
|
|
|
| Host | How |
|
|
|---|---|
|
|
| **GNOME** (Mutter) | A virtual monitor via the screen-cast API |
|
|
| **KDE Plasma** (KWin) | A virtual output via KWin's screencast |
|
|
| **Bazzite / Steam** (gamescope) | A nested gamescope session launched at the client's mode |
|
|
| **Sway** (wlroots) | A headless output added to the running session |
|
|
| **Windows** | A virtual-display driver — including punktfunk's own **indirect display driver** the host pushes frames straight into — a real virtual display, no physical monitor, even on the secure desktop |
|
|
|
|
That last one is the distinctive part on Windows: rather than only capturing an existing screen,
|
|
punktfunk has **its own indirect display driver (IDD)**, and the host can push finished frames
|
|
**straight into the driver**. You get the same on-the-fly virtual display the Linux compositors give
|
|
you — at the client's exact mode, with no physical monitor or dummy HDMI dongle, and even on the
|
|
secure desktop (UAC / lock screen). That tight, push-based integration is unusual among Windows
|
|
streaming hosts.
|
|
|
|
## From screen to GPU to wire
|
|
|
|
Captured frames never touch the CPU on their way to the encoder. They go straight from the
|
|
compositor to the GPU's NVENC hardware encoder (HEVC/H.264/AV1) and out to the network — a **zero-copy
|
|
GPU path** that keeps latency low even at high resolutions and frame rates.
|
|
|
|
## Two protocols
|
|
|
|
punktfunk speaks two protocols over the same host:
|
|
|
|
- **GameStream** — the protocol Moonlight uses. Any [Moonlight](/docs/moonlight) client connects with
|
|
no special software. This is the most compatible way in.
|
|
- **punktfunk/1 (native)** — a purpose-built protocol with a QUIC control channel and a UDP data
|
|
channel hardened with forward error correction and encryption. It's lower-latency and more resilient
|
|
on imperfect networks, and it's what the [native clients](/docs/clients) (Apple, Linux, Windows,
|
|
Android) use.
|
|
|
|
Both run from a single host process, so you don't choose up front — Moonlight clients use GameStream,
|
|
the native clients use punktfunk/1.
|
|
|
|
## Pairing and trust
|
|
|
|
The first time a device connects, you pair it: the host shows a short **PIN**, you type it into the
|
|
client, and the two remember each other. After that the device reconnects automatically on a pinned
|
|
cryptographic identity — no PIN, no account, no cloud. See [Pairing & Trust](/docs/pairing).
|
|
|
|
## Finding hosts
|
|
|
|
Hosts advertise themselves on your local network, so clients can **discover** them automatically
|
|
instead of needing an IP address. The native clients and Moonlight both list hosts they find on the
|
|
LAN.
|
|
|
|
## Multiple devices at once
|
|
|
|
A host can stream to several clients simultaneously — your laptop and your TV both viewing (and
|
|
controlling) the desktop, each at its own resolution. See [Multiple devices](/docs/configuration#multiple-devices).
|