Hyprland streaming worked for exactly one session, and the cursor was never on the streamed head — six bugs, all ours #240

Merged

enricobuehler merged 6 commits from worktree-capture-bgra-dmabuf-pod into main 2026-08-14 22:07:21 +00:00

Conversation 0 Commits 6 Files Changed 18

+1487 -221

6 Commits

Author	SHA1	Message	Date
enricobuehler	2832b5d0f6	fix(host): the park schedule read a missing cursor overlay as a lost pointer, but an Embedded portal never sends one ... Field report, working Hyprland stream: the pointer jumps to the screen centre once a second for ~10 s at the start of every session, fighting every mouse movement, then settles. That is `park_pointer`'s schedule running its full cap. Parking exists for a good reason — a pointer-locked client sends only RELATIVE deltas, so nothing would ever move the seat pointer onto a freshly created virtual output — and past its two unconditional attempts it keeps going only while a host-composite session STILL has no live cursor overlay. "No overlay ⇒ the pointer has not reached the streamed output" is sound on Mutter, which suppresses `SPA_META_Cursor` while the pointer is off the recorded view. It is meaningless on the whole wlr family: xdph and xdpw advertise `AvailableCursorModes = 3` (Hidden|Embedded), so a session that asks for metadata is served EMBEDDED — the compositor paints the pointer into the frames and sends no cursor metadata, ever, wherever the pointer is. The heuristic was reading noise and warping the user's pointer over it. Distinct from — and complementary to — 5a5397ca, which fixed WHERE the warp landed (the wlr virtual pointer was bound to the operator's head, so the park drove a screen nobody was streaming). That one makes the park work; this one stops it repeating on evidence that does not exist. Both are needed: with only 5a5397ca the pointer would be re-centred on the *streamed* output once a second instead, which is the field report's symptom exactly. The same fact broke a second thing next to it. `metadata_composite` had the host plan a metadata cursor composite on a backend that can never deliver metadata: the stream logged "host-composite active but the capture has no live cursor overlay" for its whole life and drew no host pointer, which is why an earlier session on this box looked cursorless. Under Embedded the compositor's burnt-in pointer IS the cursor, and the host must not plan a composite at all. So surface what the portal actually negotiated instead of inferring it: `portal_cursor::negotiate` now returns our own `Mode` (re-exported as `pf_vdisplay::PortalCursorMode`), the hyprland/wlroots portal threads carry it back beside the fd and node id — alongside, not instead of, the `closed_tx` teardown handshake and inside the same `HANDSHAKE_BUDGET` bound — and the backends, plus the monitor mirror that delegates to them, report it per session as `VirtualDisplay::last_portal_cursor_mode`. `None` is the default and what every non-portal backend reports (KWin `zkde_screencast`, Mutter `RecordVirtual`, gamescope, Windows all get the mode they ask for), so nothing about the GNOME behaviour this was built for changes. The host settles both consequences from that one fact in `settle_portal_cursor`, at bring-up and again after every capture-loss rebuild (the retarget arm has to recompute `metadata_composite` from the compositor alone, because it runs before the rebuild to set `hw_cursor`). `plan.cursor_blend` is deliberately left alone: it is resolved before any display exists, and pre-judging it would mean re-asserting what the wlr portals advertise — the exact hardcode `portal_cursor` exists to have deleted. It costs a colour conversion, not correctness. Also cuts the park RETRY for a client that steers the seat pointer itself. The doc claimed a desktop-model client "overrides it with its first absolute move, so the jump is invisible in practice" — one park at bring-up is, a repeat is not: such a client sends absolute positions, the very same event the park synthesizes, only aimed where the user is actually pointing. It keeps the single bring-up park, so the session's first click cannot land on whatever monitor the seat pointer was left on, and loses the retry that fights the user. A cold EIS connection swallows the client's own moves too, and those keep coming. On the reported session this is 2 parks in the first second instead of 11 over ten, and no phantom composite. Verified: `cargo fmt --all --check`; `scripts/xcheck.sh linux clippy` and `windows clippy`; `cargo clippy -p punktfunk-host -p pf-vdisplay -p pf-inject --all-targets --locked -- -D warnings` and `cargo test` for the three, run for Linux in the ci/rust-ci.Dockerfile image (this crate does not build on macOS at all — opus, zerocopy and the Linux-only vdisplay entry points are cfg'd out there, so the container is the only way to compile it). pf-vdisplay 231 tests, pf-inject 130+7, and both new tests pass. punktfunk-host's suite has two pre-existing failures under that emulated container — `gamestream::stream::tests::sender_delivers_ batches` (EINTR on a socket recv) and one of the two `mgmt` local-summary tests, which share process-global session state — and the SAME two fail on this branch's parent without this commit; each passes in isolation. Not verified on glass: the .138 Hyprland box is read-only and in use.	2026-08-14 23:56:36 +02:00
enricobuehler	6863f8141a	fix(input): the wlr injector aimed absolute motion at the operator's head, never the streamed one ... `WlrootsInjector::open` created its virtual pointer with `globals.output` — whatever `wl_output` the registry roundtrip had bound, which was `state.output.is_none()`, i.e. the FIRST one advertised. Registry globals arrive in creation order, so "first" is the compositor's oldest output: the operator's physical head, never the per-session headless one the client is looking at. The wlr protocol maps `motion_absolute` onto the output the pointer was CREATED with ("if the output argument is set, the compositor should map the input device to the requested output"), so every absolute sample from every session drove a screen nobody was streaming. On the EXTEND backends — Hyprland and wlroots/sway, where the streamed head sits beside the operator's — that is the field report "no cursor was visible in the session", and it is also why `park_pointer`'s opening warp put the seat cursor on the operator's desktop once a second instead of on the stream. Not a startup race, though it looks like one. The host journal on the Hyprland box shows BOTH orderings across sessions of the same build — the injector opening 3.7 s before the headless output in one, 24 ms after it in another — and the bug in both, because "first advertised" is the oldest global either way. `hyprctl monitors` on that box: `HDMI-A-1` (ID 0) at +0+0, `PF-87756-3` (ID 1) at +1920+0. ID 0 is always first. Three parts. 1. pf-vdisplay carries the head's compositor name out on `VirtualOutput::output_name`, the Linux counterpart of what `win_capture` already carries on Windows. Set by hyprland and wlroots (the two EXTEND backends) and by the monitor mirror; `None` on KWin/Mutter (they inject through libei, which selects by region) and gamescope (it owns its whole seat). Threaded through the registry pool so a keep-alive reuse answers with the same name a fresh create would — no poolable backend sets it today, and this is so that stops being a silent trap the day one does. 2. The host publishes it at capture bring-up, `pf_inject::set_stream_output`, in the same place and shape as the Windows arm's existing `set_stream_target`. 3. The wlr injector binds EVERY `wl_output` at v4 (for the `name` event), matches the published name, and re-creates its virtual pointer bound to that output whenever the target changes — releasing any held button on the old device first, because nothing else would and a virtual pointer destroyed mid-press leaves the host with a stuck button. Matching is by NAME, with NO fallback, and the absence of the fallback is the fix: the old "first output" behaviour WAS the fallback. Size could not stand in for it either — `MouseMoveAbs`'s extent is the client's letterboxed video rect in its own window, not the streamed mode, so no size ladder can identify the head. An unresolved target binds NO output, which maps absolute coordinates over the whole layout: on a single-output compositor that is identical to binding that output, and on a multi-head one it at least keeps the streamed head reachable, unlike a pin to the wrong one. `inject` now also READS the Wayland socket. It only ever called `dispatch_pending`, which is documented to "not perform reads on the Wayland socket", so the queue held nothing but what `open`'s roundtrips put there. Without this the retarget above would have been dead in exactly the sessions that need it most — the injector could never learn about a `wl_output` created after it opened — and, separately, everything the compositor sent had been piling up unread in the socket buffer for the host's lifetime, including the protocol errors the comment there claimed to be surfacing. Concurrency, stated plainly: ONE slot per process. The injector is host-lifetime (in fact there are two `InjectorService`s — the native plane's and one per GameStream control listener) and `InputEvent` is an 18-byte `#[repr(C)]` ABI struct with no session field, so with parallel sessions (up to `max_concurrent`, default 4) the LAST capture bring-up wins for everyone's absolute input. That is the same trade `stream_target` already documents on Windows, and it is strictly better than what it replaces, where every session aimed at a head NO session was streaming. Making injection genuinely session-aware is the real fix and a much larger one — it needs source-tagged input events through both control planes. `set_absolute_anchor`'s warning is amended rather than quietly violated: it still must not be called from a session path, and it now says which mechanism took the per-session trade, why that is a separate slot (this one is the operator's host-wide capture pin, recomputed from policy whenever the console writes it — which would wipe a per-session value), and where the trade is written down. Gates: `cargo clippy --all-targets -p pf-inject -- -D warnings`, `cargo build -p pf-inject` and `cargo test -p pf-inject` (137 tests, incl. 3 new) on x86_64-unknown-linux-gnu in `punktfunk-rust-ci`; `cargo check -p punktfunk-host` likewise; `scripts/xcheck.sh linux clippy` plus 230 `pf-vdisplay` tests; `cargo fmt --all --check`. The two new `wlr` tests pin the regression directly — an unknown target must bind NOTHING rather than fall back to the first advertised output. Not verified here: no on-glass run. The box at .138 is in live use and read-only to me, so the change is unproven against a real Hyprland seat. Two smaller things also rest on reading rather than observation — that Hyprland's `hyprctl` monitor name is byte-identical to its `wl_output.name` (the protocol says the name is "the same for all clients", and xdph already resolves our `hyprctl`-minted name to the same output for screencast, which is field-proven), and the exact on-screen arithmetic of the "moves to mid-screen then jumps back" symptom, which does not follow from the protocol's normalize-by-extent mapping and would need Hyprland's own source to pin down.	2026-08-14 23:56:36 +02:00
enricobuehler	cf4c12ea52	fix(vdisplay): a per-cast tokio runtime orphaned ashpd's process-global connection after one cast ... THE reason the first stream of a host process worked and every later one was black. Not xdph, not the compositor, not the formats — ours, and a lifetime mistake. ashpd caches its D-Bus connection process-globally: static SESSION: OnceLock<zbus::Connection> // ashpd 0.13.13, src/proxy.rs:27 The first `Screencast::new()` in the process creates that connection, and zbus spawns its background reader as a task on whichever tokio runtime is current at that moment. Both wlr backends built their OWN multi-thread runtime per cast and dropped it at teardown — so the first cast created the cached connection on a runtime that was then destroyed with it, and the OnceLock went on handing the same executor-less connection to every later `Screencast::new()`, which awaited a reply nothing was alive to read. Measured 2026-08-14 (Hyprland 0.55.4, xdph 1.3.12): first cast of a host process streamed, every cast after it hung, and the surviving cast thread sat in futex_do_wait inside runtime shutdown. The discriminator that pins it on us: a freshly spawned process completed the identical handshake against the identical xdph, repeatedly, while the long-lived host completed none — with xdph itself idle at 28 ms of CPU, so it was never the one wedged. Teardown was already correct by then: the log shows `hyprland headless output removed` in the right order. One shared runtime (`portal_rt`), built once, never dropped, `block_on(&self)` from every cast thread. It outlives the cached connection because it must. Also bound `Screencast::new()` itself, not just the handshake after it: with the connection orphaned that call is exactly where the thread hung, so the earlier bound started one step too late and the failure still surfaced as the caller's generic 20 s timeout. Verified: cargo fmt --all --check, scripts/xcheck.sh linux clippy (-D warnings), cargo test -p pf-vdisplay 122 passed. Not verified: on-glass.	2026-08-14 23:56:36 +02:00
enricobuehler	5e5d6904d3	fix(vdisplay): a hung portal handshake leaked its thread, and one leak poisoned every later cast ... MEASURED 2026-08-14 on the Hyprland box, with the ordered-teardown fix already in place. The first cast of a host process streamed: hyprland headless output ready … output=PF-44694-1 w=5120 h=1440 hz=240 pipewire stream state old=Paused new=Streaming and every cast after it timed out in select_and_cast. The host had NINE live `punktfunk-hypr-cast` threads and 28 tokio workers at that point. `select_sources`/`start` await a D-Bus reply that a wedged portal never sends. That await cannot be cancelled by the `stop` flag, because the flag is only read by the park loop further down — a thread stuck in the handshake never reaches it. So every timed-out attempt left a thread parked forever on a half-created portal session, holding this process's shared D-Bus connection, and from the first hang onwards every later request from the SAME process hung too. The discriminator that proves it is the process, not the portal: a freshly spawned process (`punktfunk-host spike --source portal`, driven through the same custom picker) completed the identical handshake against the very same xdph — repeatedly — while the long-lived host could not complete any. xdph itself was idle, 28 ms of CPU since start, so it was not spinning. Bound the handshake at 15 s, under select_and_cast's 20 s wait so the failure is reported by the thread that owns it, with a reason, and — the point — so that thread EXITS instead of leaking. Same change in the wlroots/sway backend: xdpw carries the identical unbounded node-id spin (screencast.c), so it can wedge the same way. Verified: cargo fmt --all --check, scripts/xcheck.sh linux clippy (-D warnings), cargo test -p pf-vdisplay 122 passed. Not verified: on-glass — needs the box.	2026-08-14 23:56:36 +02:00
enricobuehler	9ce347e4c0	fix(vdisplay): we removed the captured output before closing the cast, and xdph spun on the wreckage ... Only the FIRST stream after a portal start ever worked on Hyprland; every one after it died in `select_and_cast` with create virtual output: timed out waiting for the ScreenCast portal on PF-… The mitigation on `worktree-capture-bgra-dmabuf-pod` chased the symptom. This is the mechanism, read out of xdph 1.3.12's source and the box's own journal. WE YANK THE OUTPUT OUT FROM UNDER A LIVE CAST. `Keepalive` drops `StopGuard` then `OutputGuard`, and `StopGuard::drop` only SET an atomic and returned. The portal thread noticed 200 ms later and merely dropped its zbus connection. So `hyprctl output remove` ran — synchronously, microseconds later — on an output xdph was still capturing, every single teardown. Nothing closed the session either. xdph destroys one on exactly one event, an explicit `org.freedesktop.impl.portal.Session.Close` (`Session.cpp:37`); it has no peer-vanished watcher. The frontend does (`xdg-desktop-portal.c:230` `peer_died_cb` → `close_sessions_for_sender`), but only once our bus name goes away — after the poll, asynchronously, on a GTask thread. Long after the output is gone. Proof from the box: xdph's toplevel lock stayed at 2 for 4.5 minutes after our stream ended and its output was removed, and that session's `Session destroyed` never came. XDPH THEN SPINS AT 100% CPU, FOREVER. Handed that wreckage, `startSharing` falls into `Screencopy.cpp:307-313` while (pSession->sharingData.nodeID == SPA_ID_INVALID) { int ret = pw_loop_iterate(g_pPortalManager->m_sPipewire.loop, 0); — timeout 0, i.e. NON-blocking, i.e. an unbounded hot spin on xdph's only event-loop thread, inside the `Start` handler, holding its `m_mEventLock`. From there it answers no D-Bus, no Wayland, no PipeWire, ever again. MEASURED: the wedged instance's unit reported `Consumed 3min 51.971s CPU time over 23min 41.092s wall clock`, and there were 232.70 s of wall clock between its last log flush and its restart — 231.971 s of CPU against 232.70 s of wall, one core pinned solid for precisely the wedged interval. Everything after that is queueing. Our next handshake gets nothing, times out at 20 s, and `SelectionFile` deletes the per-session selection file on its way out; if xdph is restarted mid-queue it finally runs the picker for that stale request and reads an empty file — the `SHAREDATA returned selection -1` in the log. THE FIX IS THE ORDER. `StopGuard::drop` now signals and then WAITS for the portal thread to have closed the ScreenCast session, and only then does `OutputGuard` remove the output. The close is answered synchronously by the frontend (`xdp-session.c:217` `handle_close` → `xdp_dbus_impl_session_call_close_sync`), so when it returns xdph has already run `destroyStream`. The output we remove next is one nobody is capturing. Bounded at 3 s on each side — an already-wedged portal must not be able to wedge our teardown with it — and the park poll drops to 20 ms now that teardown waits on it. wlroots gets the same change, and NOT on an assumption of symmetry: xdpw was read to confirm both preconditions. `src/core/session.c` gives its session object exactly one method, `Close`; and `src/screencast/screencast.c:599-605` is the identical unbounded `while (cast->node_id == SPA_ID_INVALID)` spin — xdph's copy is that code. sway's `output unplug` yanks a captured output exactly the way Hyprland's `output remove` did. Not observed on glass; no sway box. THE PICKER LINE WAS ALSO MALFORMED, AND IS A RED HERRING FOR THE STALL. xdph splits the picker's line on the first `/` into flags and selection (`ScreencopyShared.cpp:86-87`) and we never sent one. `find_first_of` then returns npos, so FLAGS became the whole payload — and SEL became the whole payload too, purely because `npos + 1` wraps to 0, which is why the output name still parsed and why this hid. What did not hide is the flag loop walking `screen:<name>` one character at a time (`unknown flag from share-picker: s`, `c`, `e`, …) and setting `allowToken` on the `r` of `sc*r*een`, so xdph answered every Start with a `restore_data` + `persist_mode: 2` we never asked for. The reference picker prints the separator unconditionally (`hyprland-share-picker/main.cpp:133-136`), so empty flags are a bare leading `/`. Fixed to `[SELECTION]/screen:<NAME>`. It is NOT what stalled anything: the sessions that streamed fine logged the identical flag spam and the identical restore token, so it never discriminated. The format moves to `portal_picker.rs`, declared unconditionally like `portal_config` and `portal_cursor`, with xdph's parser transcribed into the tests — including the npos arithmetic. A wire format with no schema and no error report is invisible from the string alone: the old line's one assertion passed the entire time it was wrong. Those tests now run on every platform's CI rather than only the leg that compiles `mod hyprland`. Verified: cargo fmt --all --check, scripts/xcheck.sh linux clippy AND windows clippy (-D warnings), cargo test -p pf-vdisplay 122 passed (5 new). Not verified: on-glass behaviour — the box is in use for live testing and read-only to me. Upstream bugs worth filing, both wlr-family: the unbounded node-id spin (hyprwm/xdg-desktop-portal-hyprland Screencopy.cpp:307, emersion/xdg-desktop-portal-wlr screencast.c:599) should be bounded and fail the request rather than pinning a core forever; and xdph's picker parse should reject a line with no `/` instead of reading the whole selection as flags.	2026-08-14 23:56:36 +02:00
enricobuehler	dea6395772	fix(capture): xdph offers BGRA on its dmabuf pod, and we offered BGRx, so the link never negotiated ... A Hyprland/sway client went black with no error of ours: PipeWire failed the link itself with pw.link: (73.0.0 -> 81.0.0) negotiating -> error no more input formats (-22) Measured on Hyprland 0.55.4 + xdph 1.3.12 by dumping both EnumFormat pods from the PipeWire DAEMON (`PIPEWIRE_DEBUG=*:1,pw.link:5` — the pods are not in our own process's log, which is why this hid for so long): ours BGRx only | 12 NVIDIA tiled + 0 (LINEAR) | MANDATORY xdph BGRA only | the same 12 + MOD_INVALID | MANDATORY|DONT_FIXATE xdph BGRA or BGRx, no modifier | (the SHM pod) The modifiers intersect perfectly. Only the fourcc never does, which is exactly why the failure reads as a GPU/modifier problem and is not one — the host's own message ("the compositor never accepted the dmabuf-only offer (EGL->CUDA GPU import)") points at the GPU, and our advert line prints only the first 6 of 13 modifiers so LINEAR is invisible. Both misled a full session of debugging. Since our offer is dmabuf-only, xdph's mixed SHM pod could not rescue it. Offer a BGRA dmabuf pod beside the BGRx one. BGRA and BGRx are the same 32-bit layout, the alpha byte is ignored all the way to the encoder (`vk_util` maps both to B8G8R8A8_UNORM, VAAPI both to Pixel::BGRA), and the import is driven by the NEGOTIATED format's fourcc, so an AR24 frame imports as AR24. Vendor-neutral by construction: the two modifier lists are enumerated PER FOURCC (`XR24` and `AR24` asked separately), because EGL and libva answer per format and nothing entitles us to assume a driver importing one imports the other. On the VAAPI passthrough path there is no importer, so both lists are LINEAR (plus the PyroWave Vulkan set when armed) — AMD and Intel get the BGRA pod on the same terms as NVIDIA rather than an NVIDIA-shaped guess. The BGRA pod is listed AFTER BGRx, so a producer offering both still lands on the pre-existing path — first compatible consumer pod wins, so this is purely additive. Both pods are now guarded on a non-empty list (`build_dmabuf_format` indexes `modifiers[0]`). Also name `linear_offered` and both counts in the advert log, so the truncated `sample` can no longer be misread as the whole offer.	2026-08-14 23:56:35 +02:00