enricobuehler 6fdf7d1511 feat: client-selectable compositor (protocol → host → client → C ABI → mgmt → web)
A client can now request which compositor backend the host drives its virtual
output on (gamescope/KWin/Mutter/wlroots). The host honors the request if that
backend is available, else falls back to auto-detect and reports the resolved
choice back — wire-compatible both directions (no ABI bump).

Protocol (punktfunk-core):
- New CompositorPref (config.rs): Auto|Kwin|Wlroots|Mutter|Gamescope with
  u8/name mappings. Appended as one optional byte to Hello (client preference)
  and Welcome (host's resolved choice). Both decoders already tolerate trailing
  bytes, so old↔new interop is preserved — ABI_VERSION stays 2. Round-trip +
  back-compat (truncated-message) tests.
- C ABI: punktfunk_connect_ex(compositor) + PUNKTFUNK_COMPOSITOR_* constants;
  punktfunk_connect delegates with AUTO, so the existing symbol is unchanged.
  NativeClient::connect / worker_main thread the preference through.

Host:
- vdisplay::available() enumerates usable backends via cheap, side-effect-free
  probes (KWin zkde global, gamescope binary+version, GNOME/Sway env), plus
  Compositor id/label/as_pref/from_pref/all helpers.
- m3 handshake resolves the preference to a concrete backend during the
  handshake (pick_compositor pure + resolved logging), reports it in Welcome,
  and threads it into virtual_stream (replacing the unconditional detect()).
- mgmt GET /v1/compositors lists every backend with availability + the
  auto-detected default (OpenAPI regenerated).

Client:
- punktfunk-client-rs --compositor NAME; logs the host's resolved choice from
  the Welcome ("session offer … compositor=…").

Web console:
- Host page gains a Compositors card (availability + default badges) via the
  codegen'd useListCompositors hook; en/de strings added.

Also fixes a pre-existing, env-dependent test-isolation bug:
mgmt::tests::paired_clients_list_and_unpair seeded the real
~/.config/punktfunk/paired.json (AppState::new loads it), so a real
GameStream-paired client leaked into body[0] on a dev box — now cleared first.

Live-validated against headless KWin: --compositor kwin honored, --compositor
mutter falls back to kwin (available=[kwin, gamescope]), resolved choice
round-trips to the client. Tests: +6 (wire/back-compat, resolution precedence,
endpoint); workspace green, clippy/fmt clean, C ABI harness PASS at abi_version=2,
web typecheck + build clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-10 22:45:41 +02:00

punktfunk

A ground-up low-latency desktop streaming stack, built Linux-first, with a shared Rust protocol core and native clients per platform.

punktfunk is a placeholder codename. The bet: ship a Linux virtual-display streaming host that speaks the existing Moonlight protocol (every Moonlight/Artemis client works day one), then break the ~1 Gbps FEC wall with a GF(2¹⁶) Leopard-RS transport as a negotiated extension. See docs/implementation-plan.md.

Status

Milestone State
M1 — punktfunk-core + C ABI done & tested (FEC, packetization, crypto, session, punktfunk_core.h)
M0 — pipeline spike (wlroots→PipeWire→NVENC→file→punktfunk-core) done & verified on NVIDIA (RTX 5070 Ti / driver 595)
M2 — P1 host → stock Moonlight 🟡 capture+encode landed in M0; pairing/RTSP/vdisplay pending
M3 — measurement harness 🟡 tools/loss-harness runs; latency-probe scaffolded
M4 — P2 transport + Rust client 🟡 GF(2¹⁶) core done; punktfunk-client-rs scaffolded
M5 — Apple client 🟡 macOS first light: HEVC on glass + input over punktfunk/1 (clients/apple)

punktfunk-core is complete and verified: it builds and its full test suite (FEC recovery, loopback round-trip under loss, property tests, and a C ABI harness) passes on macOS/aarch64. M0 is done: punktfunk-host captures a headless wlroots output via the ScreenCast portal + PipeWire, encodes it with NVENC, writes a playable H.265 file, and round-trips every access unit through a punktfunk_core host→client session (see docs/linux-setup.md). M2 is in flight: the GameStream control plane (gamestream/) and the management REST API (mgmt.rs, OpenAPI spec in docs/api/) are implemented; the remaining Linux host backends (KWin/Mutter virtual displays, libei input) are #[cfg(target_os = "linux")] seams — defined and compiling, implementations pending.

Layout

crates/
  punktfunk-core/        protocol · FEC · pacing · crypto — the C ABI (lib + cdylib + staticlib)
  punktfunk-host/        Linux host: vdisplay · capture · encode · inject · gamestream · mgmt
  punktfunk-client-rs/   reference client (M4): VAAPI decode + wgpu present
clients/{apple,android}/   native client scaffolds (import punktfunk_core.h)
include/punktfunk_core.h       cbindgen-generated C header (checked in)
tools/{latency-probe,loss-harness}/   measurement (plan §10)
docs/implementation-plan.md

Build & test

cargo build --workspace          # green on Linux and macOS
cargo test  --workspace          # unit + loopback + proptest + C ABI harness
cargo clippy --workspace --all-targets

cargo run -p loss-harness        # FEC loss-resilience sweep (no network needed)
bash crates/punktfunk-core/tests/c/run.sh   # standalone C-ABI link+round-trip proof

The C header regenerates from crates/punktfunk-core/src/abi.rs on every build (cbindgen via build.rs) into include/punktfunk_core.h.

Design invariants

  • One core, linked everywhere. Protocol/FEC/crypto/pacing live in punktfunk-core exactly once, exposed over a stable, versioned C ABI (punktfunk_abi_version(), PunktfunkConfig carries its own struct_size).
  • No async on the hot path. The per-frame pipeline uses native threads only; tokio/quinn are gated behind the off-by-default quic feature (control plane only).
  • FEC is the wall-breaker. GF(2⁸) (≤255 shards/block) for Moonlight compat; GF(2¹⁶) (≤65535 shards/block, SIMD, O(n log n)) to push past ~1 Gbps.

License

MIT OR Apache-2.0.

S
Description
next gen game streaming - built using rust, back compatible with game stream clients, and supporting virtual displays for kde/kwin, gnome and gamescope.
Readme 16 MiB
v0.2.1 Latest
2026-06-28 12:51:55 +00:00
Languages
Rust 72%
Swift 12.3%
TypeScript 4.1%
Kotlin 3.2%
Shell 3.2%
Other 5.1%