punktfunk/docs-site/content/docs/sway.md at worktree-shield-select-back-quit

Hyprland and wlroots both hardcoded portal `CursorMode::Metadata` whenever the
session had negotiated the cursor channel, and never asked the backend what it
supports. That is not a soft failure: xdg-desktop-portal's FRONTEND validates the
requested mode against the backend's `AvailableCursorModes` and fails the call
with `"Unavailable cursor mode %x"` before the backend ever sees it.

So a cursor-forward session (desktop mouse mode) died at `select_sources`,
surfacing as "pipeline build failed" and a black client, with
`unavailable cursor mode 4` in the portal log. Field report 2026-08-14.

MEASURED on .21 the same day, and it is worse than the report suggested: against
a LIVE Hyprland 0.56.2 with xdg-desktop-portal-hyprland 1.4.1 and
xdg-desktop-portal 1.22.1 — all current — `AvailableCursorModes` reads **3**
(Hidden|Embedded) on both the backend impl interface and the frontend. xdph does
not offer the metadata cursor at all, so this broke EVERY cursor-forward session
on current Hyprland, not merely on old installs. Updating the portal would not
have helped. xdpw is the same from the other end: its screencast.c refuses
METADATA outright.

pf-capture's own portal path has always negotiated (`choose_cursor_mode`); this
restates that ladder in pf-vdisplay, which may not depend on pf-capture. The
downgrade is graceful rather than merely survivable: with the portal on Embedded
no `SPA_META_Cursor` arrives, so the host feeds the cursor channel nothing and a
cursor-forward client draws nothing of its own — one pointer, not two.

`PUNKTFUNK_PORTAL_CURSOR_MODE=auto|hidden|embedded|metadata` pins the preference
for a backend that advertises a mode it implements badly, which negotiation
cannot detect. It is a preference only: pins run the same ladder, so no value can
re-create the refused request.

The module is declared unconditionally so its ladder tests run on every CI leg
rather than only the one that compiles `mod hyprland` — including a Linux-only
test pinning our bit values against ashpd's enum, verified non-vacuous by
planting a wrong discriminant (ashpd answers 4 for Metadata, the number in the
report). The regression test uses 3, the bitfield measured on glass. Linux: 225
tests pass, clippy --all-targets -D warnings clean.

2026-08-14 10:27:14 +02:00

5.5 KiB

Raw Permalink Blame History

title, description

title	description
Sway / wlroots	Configure a Punktfunk host on sway.

Sway can host: the host adds a per-client headless output at the client's exact mode with swaymsg create_output and captures it through the xdg-desktop-portal-wlr (xdpw) ScreenCast portal, injecting input via the wlroots virtual pointer/keyboard protocols.

Despite the backend's name, this path is sway specifically. Everything it does for video — creating the headless output, setting its mode, listing your monitors — goes through sway's IPC (swaymsg), so a wlroots compositor without that IPC (River, dwl, …) cannot host: the session fails straight away with swaymsg get_outputs (is the host inside the sway session env — SWAYSOCK?). Input would be fine there — it uses the wlroots virtual pointer/keyboard protocols, which those compositors do have — but with no video there is no stream.

On Hyprland? It's a separate first-class backend (its own hyprctl IPC and xdph portal) — see Hyprland. This page is for sway.

This is not a primary target. It works and is validated live on sway 1.11 (zero-copy), but it sees far less testing than the KDE and GNOME paths — expect rougher edges. If you have a choice, KDE or GNOME are the better-exercised desktops.

This page assumes the package is already installed — see Arch, Ubuntu, or Fedora.

New here? Read Security & Safe Use first — a streaming host is remote control of the machine, so keep it on a trusted LAN or VPN and require pairing.

host.env

The host auto-detects a wlroots session, so the starter ~/.config/punktfunk/host.env is one line:

PUNKTFUNK_VIDEO_SOURCE=virtual
# GPU zero-copy capture→encode is ON by default; auto-falls back to CPU. Set PUNKTFUNK_ZEROCOPY=0 to force CPU.

To force the backend (CI/testing — note that pinning turns live-session auto-detection off, so the host stops following session switches):

PUNKTFUNK_COMPOSITOR=wlroots      # aliases: sway, wlr
PUNKTFUNK_INPUT_BACKEND=wlr

See Configuration for the full reference.

How it works

Video — the host adds a headless output at the client's exact mode with swaymsg create_output. This uses sway's IPC specifically, and so does everything else on the video side (mode setting, monitor listing). (Hyprland is driven by its own backend, not this one.)
Capture — it captures that output through the xdg-desktop-portal-wlr (xdpw) ScreenCast portal. The host writes a managed chooser config so the output pick is automatic — no interactive picker dialog to answer.
Input — mouse and keyboard are injected via the wlroots virtual pointer and virtual keyboard protocols.

For how long the virtual output lives, and extend-vs-exclusive topology, see Virtual displays.

Requirements

A running sway session — its IPC socket (SWAYSOCK) is what the whole video path runs on. You don't have to export it: the host finds the live sway instance itself on every connect, so a systemd --user host works even though it never inherited your login shell's environment. On Hyprland, use the Hyprland backend instead.
xdg-desktop-portal-wlr (xdpw) installed and running — the host captures through its ScreenCast portal. Without it there is no video.
ScreenCast routed to xdpw — only if another portal backend (gtk, gnome) is installed alongside it. xdg-desktop-portal picks one implementation per interface, and if it hands ScreenCast to the wrong backend the host steers an xdpw chooser nobody is reading. Pin it for your session by creating ~/.config/xdg-desktop-portal/sway-portals.conf:
```
[preferred]
default=gtk
org.freedesktop.impl.portal.ScreenCast=wlr
```
Then systemctl --user restart xdg-desktop-portal. On a box with only xdpw installed there is nothing to choose between, so you can skip this.

Troubleshooting: black client + "unsupported cursor mode requested"

A black client with pipeline build failed in the host log and dbus: unsupported cursor mode requested, cancelling from xdpw is one failure, not two.

xdpw refuses the ScreenCast metadata cursor mode and cancels the cast, and the portal spec makes that fatal rather than a fallback. Hosts before this release asked for it whenever the client drew the pointer itself (desktop mouse mode), so those sessions never produced a frame. Hosts from this release check what xdpw advertises first and use an embedded cursor instead, so the session streams.

On an older host, switch the client to game mouse mode — it stops asking for the metadata cursor and the stream comes up. The same failure on Hyprland reads unavailable cursor mode 4; see Hyprland.

Start the host

With the backend selected, start the host from inside your Sway session:

systemctl --user enable --now punktfunk-host
journalctl --user -u punktfunk-host -f

This unit runs the secure native-only host. To also serve stock Moonlight clients, GameStream compat is opt-in (PUNKTFUNK_GAMESTREAM=1 in host.env, trusted LANs only) — see What the unit starts.

Bring up the console and pair

Enable the web console, read its login password, and arm PIN pairing — see The Web Console. Then connect a client.

5.5 KiB Raw Permalink Blame History