Files
punktfunk/docs-site/content/docs/roadmap.md
T
enricobuehlerandClaude Opus 5 d383161723
ci / rust (push) Failing after 2m31s
ci / docs-site (push) Successful in 1m22s
ci / web (push) Successful in 1m48s
docker / builders (--build-arg FEDORA_VERSION=44, ci/fedora-rpm.Dockerfile, punktfunk-fedora44-rpm, -f44) (push) Successful in 1m1s
ci / rust-arm64 (push) Successful in 2m2s
docker / builders (ci/android-ci.Dockerfile, punktfunk-android-ci) (push) Successful in 11s
docker / builders (ci/arch-ci.Dockerfile, punktfunk-arch-ci) (push) Successful in 9s
docker / builders (ci/fedora-rpm.Dockerfile, punktfunk-fedora-rpm) (push) Successful in 9s
docker / builders (ci/rust-ci-noble.Dockerfile, punktfunk-rust-ci-noble) (push) Successful in 9s
docker / builders (ci/rust-ci.Dockerfile, punktfunk-rust-ci) (push) Successful in 9s
docker / builders-arm64cross (push) Successful in 20s
docker / apps (., web/Dockerfile, punktfunk-web) (push) Canceled after 36s
docker / apps (docs-site, docs-site/Dockerfile, punktfunk-docs) (push) Canceled after 36s
docker / deploy-docs (push) Canceled after 0s
docs: the docs catch up with five releases of shipped work
~1150 feat/fix commits landed since v0.19 and the docs drifted badly. This is a
full sweep of every page against the code as shipped: ~280 verified corrections,
nine new pages, and one deletion.

The worst of what was wrong: the quickstart's five-minute path could not work
(`serve` never started the web console, so step 3 had no PIN to read); every
packaged Linux host runs `serve --gamestream` while security.md told readers to
leave GameStream off; HDR was documented as Windows-only; `PUNKTFUNK_SECURE_DDA`
was documented as a working knob that nothing reads; `PUNKTFUNK_INPUT_BACKEND`
listed a `uinput` value that does not exist and named libei for KDE instead of
kwin; README linked three pages deleted on 2026-07-05; and the rpm-ostree update
command pointed at a script no package installs.

Completeness: about half of what shipped since v0.19 had no page at all. New:
support-matrix (what works where, from 217 verified capability cells), input
(mouse/touch/pen — and the in-stream chords, so the docs finally say how to get
your mouse back), client-settings, profiles-and-links, game-library, clipboard,
wake-on-lan, hdr, uninstall. Updating existed but had zero inbound links.

status.md is gone: its facts moved into the support matrix, its shell stays as a
redirect so the public URL does not 404. roadmap.md is themes now, not a feature
checklist — checkboxes are what rotted.

Debian is no longer claimed. The .deb's Depends resolve against Ubuntu images,
nothing in CI builds or tests Debian, and Debian 12 is below the glibc 2.39
floor. The `debian` in the repo URL is the package format.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-31 17:37:06 +02:00

99 lines
6.4 KiB
Markdown

---
title: "Roadmap"
description: "Where Punktfunk is heading — the themes being worked on now, what comes after them, and what is deliberately not planned."
---
This page is about **intent**, not inventory. It says what the project is pushing on and why, in
themes rather than checkboxes, because a checklist of forty features is stale the week it is written.
Three other pages answer the questions people usually bring to a roadmap, and they answer them
better:
- **"Does it do X on my machine?"** — the [Support matrix](/docs/support-matrix). Every cell there
was read out of the code that makes the decision. It is the arbiter: where this page and the
matrix disagree, the matrix is right.
- **"What changed recently?"** — the [release notes](https://git.unom.io/unom/punktfunk/releases),
per version.
- **"How finished is this?"** — [How finished each part is](/docs/support-matrix#how-finished-each-part-is).
**Nothing on this page is shipped unless it says so.** Recently shipped work — pen and stylus input,
mirroring one of the host's real monitors, a stream that ends when the game does, settings profiles
and `punktfunk://` links, the `punktfunk` command line, HDR on gamescope hosts, and update checks
with one-click host updating — is described in the release notes for 0.19 through 0.22.3, and its
present-day behaviour is in the matrix.
## Working on now
**Windows host hardening.** The Windows host is the newest large surface in the project and gets the
most attention. Two strands: on-glass validation of the AMD (AMF) and Intel (QSV) encode paths,
which are CI-green but far less exercised than NVENC; and capture-stall attribution — the host now
carries dedicated instrumentation that says *which* link went quiet when a stream stutters — the
content that stopped being drawn, or the display path that stopped presenting it — so field reports
stop being guesswork.
**Latency under load.** The remaining wins are no longer in the encoder. They are in when a frame is
handed to the display: client-side presentation phase control, keeping a decoded frame from waiting
out a refresh interval it did not need to, and holding the frame rate when the link degrades rather
than de-escalating and staying degraded. The next structural lever is **sub-frame pipelining**
overlapping encode and transmit inside a single frame via a direct slice path — which matters most
at high resolutions.
**Finishing the clipboard.** Text crosses today from a Windows, macOS or Android client to a host
whose operator turned the feature on, with images on the first two. Two pieces are genuinely
unfinished: the **Linux client's** side of the bridge is a stub, so a Linux client offers and
applies nothing; and **file transfer** has a wire format and a host-side policy but no client that
offers files, so a copied file never crosses. See [Clipboard](/docs/clipboard).
**Console parity with the apps.** The web console still cannot run a speed test or set a bitrate —
it shows the bitrate a live session is using and stops there, while the client apps can measure the
link and act on the result.
**Closing the unverified cells.** The matrix's [What is not
verified](/docs/support-matrix#what-is-not-verified) list is a work list, not a disclaimer: a
Hyprland virtual output on real display hardware, client-drawn cursors on sway/wlroots and Hyprland,
gamescope headless capture on the proprietary NVIDIA driver, touch input from a Windows client. Most
are settled by a single session log on the right machine.
## Next
**Reach beyond the LAN.** Today a client and host have to be on the same network. The intent is NAT
traversal (ICE/STUN/TURN) with a self-hostable relay for when no direct path can be punched, plus
QUIC connection migration so a client roams between Wi-Fi and cellular without dropping the session.
The control plane is already QUIC over UDP, so this is mostly signalling and relay rather than a
protocol change.
**A host that knows who is connecting.** Two related pieces. *Per-user sessions*: a connecting
client picks an identity — an Apple TV profile, say — which maps to a real account on the host, and
that person lands in their own desktop, signed in, without touching the machine. And *gamescope
multi-user isolation*: per-session input and audio, so concurrent clients are fully independent
desktops rather than several views of one (the shared-desktop case already works).
**The rest of remote work.** Multi-monitor streaming (the host's several outputs as separate client
windows), virtual-webcam redirection (the client's camera appears as a webcam on the host, so video
calls run on the remote machine), and peer-approved pairing (approve a new device from an
already-paired device's own app, rather than only from the web console). Each is a new side plane
over the QUIC channel that already exists.
**Picture and sound frontier.** End-to-end variable refresh — the host rendering at a variable rate
and the client presenting with tearing control instead of a fixed cadence (the Apple client already
varies its own display link; the host half does not exist). True glass-to-glass latency measured
capture-to-present rather than capture-to-receipt. And object-based spatial audio: capturing game
audio objects on native Windows is blocked by a closed renderer API, but Proton already routes them
through Wine's `ISpatialAudioClient`, where the dynamic objects and their positions are currently
discarded — finishing that, and tunnelling objects plus positions to the client, would give
head-tracked remote spatial audio that no streaming stack does today.
## Not planned, or blocked upstream
- **HDR on Mutter, KWin and wlroots virtual displays.** Those compositors' virtual-monitor
screencasts are SDR-only upstream, through the GNOME 51 development branch. The host is ready the
moment that changes. gamescope's virtual output and the GNOME 50+ real-monitor mirror are the two
Linux routes that do carry HDR today — see [HDR](/docs/hdr) and the
[matrix](/docs/support-matrix#input-cursor-and-hdr).
- **Hosting on macOS, iOS, tvOS or Android.** Client-only platforms by construction: every host
entry point fails at compile time. There is no setting that changes this.
- **4:4:4 on AMD and Intel encoders.** A limitation of those encode blocks, not a gap in Punktfunk.
- **DualSense voice-coil haptics.** Scoped and shelved — it rides the controller's USB audio
interface and has near-zero game support on Linux. Rumble, adaptive triggers and the lightbar
already work.