Hyprland support

[alchemy]

Hyprland support, plus WFD negotiation fixes that affect every backend

Adds a Hyprland backend for VirtualOutput so --extend works there, and
fixes a set of protocol bugs found while getting it working against real
hardware. Verified end to end against an LG webOS TV (OLED55B9PLA): extended
desktop, picture, working mouse and keyboard.

Please read the second section even if you don't care about Hyprland — the
negotiation fixes are in crates/rtsp and crates/daemon and change
behaviour for Sway users too.

---

1. Hyprland backend

crates/external gains a hyprland module behind the unchanged VirtualOutput
API; mod sway is untouched. Backend is detected at runtime.

• Output creation via hyprctl output create headless, configured with
  hyprctl eval 'hl.monitor{...}'. hyprctl keyword monitor cannot be used:
  since Hyprland's Lua config (0.55+) it prints an error to stdout and still
  exits 0, so the first attempt silently left the output at Hyprland's default
  resolution with no failure anywhere. There is now a post-check that the
  requested mode actually landed, because a clean exit status doesn't mean it did.
• Portal output selection through a one-shot custom_picker_binary override in
  ~/.config/hypr/xdph.conf, armed for exactly one request and then removed.
  An existing custom_picker_binary is preserved and chained as the fallback.
• position = "auto" rather than a hardcoded offset — the Sway backend's
  pos 1920 0 is wrong on any primary output that isn't exactly 1920 wide.

Creation is transactional: a guard unwinds the output and the portal config in
reverse if any later step fails.

2. WFD negotiation fixes — these affect Sway too

M4 selected nothing. select_video_formats echoed the sink's entire
advertised bitmap back as the source's M4 wfd_video_formats. M4 is a
selection: the spec requires exactly one bit set across CEA/VESA/HH, naming
the single format the source will send. Echoing the bitmap says "I might send
any of these" and leaves the sink to guess the geometry of what arrives.

The parameter was being parsed at the wrong offsets. wfd_video_formats is
<native> <preferred-display-mode-supported> followed by comma-separated codec
entries of eleven fields. A real LG sink sends:

40 00 01 10 000194FF 155575DF 00000555 00 0000 0000 1F none none

The leading 40 is the native mode, not a codec tag — so matching a "40 "
prefix as "H.264 SVC" found the right codec by coincidence. The H.265 check read
field 3 as a codec mask and tested bit 4; field 3 is the H.264 level, and
4.2 encodes as 10, so every level-4.2 sink was reported HEVC-capable.
Extend mode forced H.264 and masked it — mirror mode would have sent an HEVC
stream on the strength of a misread level. The daemon repeated the mistake as
a substring test (formats.contains("02"), which also matches a CEA bitmap of
00000200, a latency field, or a max-hres of 0200).

Replaced with a real parser, the CEA table from spec Table 5-13, and a selector
that walks every advertised entry and picks the best progressive mode the
pipeline can produce. Profile and level are chosen, not taken as the lowest
advertised bit — a sink offering 3.1/4.0/4.2 would otherwise be told 3.1
alongside a 1080p selection, and 3.1 caps at 3600 macroblocks per frame against
1080p's 8160. Entries lacking constrained baseline are rejected, since that is
the only profile the encoder emits.

The selection is then honoured: carried on the daemon, driving the stream
config, with videoscale and width/height caps so a mode below the virtual
output's size is produced rather than merely announced.

No 4K. Classic WFD's resolution tables have no 4K entries, so extend mode is
1080p and the CLI help says so. The TV above advertises CEA=0x000194FF, whose
best progressive entry is 1920x1080p30 — sending 3840x2160 produced a spinner
with everything green locally.

3. An idle virtual output produces no frames

Worth calling out because it is not obvious and looks like a working session.

wlroots compositors emit a screencopy frame only when an output is damaged,
and a freshly created output with no windows and nothing moving never is.
Measured at pipewiresrc: one frame at startup, then 30+ seconds of complete
silence. Audio keeps flowing through the same muxer the whole time, so state
reaches Streaming, keepalives run, bytes move on the wire — and the sink has
no video stream to lock onto.

Two causes, and either fix alone leaves the symptom:

• Re-applying the output's own monitor configuration makes Hyprland repaint it.
  Measured: video began flowing 1.1s after the call, having not started at all
  in the six seconds before. The nudge reads the live configuration and
  re-applies exactly that, so it doesn't clobber layout or scaling.
• imagefreeze allow-replace=true is-live=true then re-pushes the most recent
  frame at the negotiated rate, so the stream doesn't fall quiet again when the
  desktop stops changing. It cannot help alone — it has nothing to repeat until
  a first frame exists.

compositor and videorate were measured first; neither repeats, both being
input-driven. A live black base layer under compositor does work and was
rejected at 19.6s CPU per 10s wall at 1080p30 against 1.7s without — roughly
two cores burned continuously to solve a start-up problem. livesync and
fallbackswitch would also work but live in gst-plugins-rs, which isn't
installed by default and would become a new requirement for every user.

The nudge is Hyprland-only. Sway almost certainly has the same damage
behaviour and is not addressed here; I have no Sway system to test on. Happy to
add an equivalent if you can point at the right call.

4. Robustness and smaller fixes

• Abrupt termination. Drop doesn't run on SIGKILL, so the headless
  output, the portal config block and the virtual audio sink could all leak.
  Each now leaves a breadcrumb carrying the owning pid; the next run checks
  /proc liveness and clears only genuinely stale resources. SIGINT/SIGTERM
  are installed before the session starts, not after discovery, so a signal
  during startup tears down exactly as much as exists.
• Reverse RTSP. Miracast has the sink open the TCP connection, and the
  source still drives the M1–M16 exchange. A packet capture showed the TV
  connecting, waiting exactly 10s in silence, then sending RST — the server was
  reactive and never spoke first. The listener binds the local P2P address
  rather than 0.0.0.0, so it isn't reachable from the wider LAN, and rejects
  peers outside the P2P group.
• --json emits one JSON object per line on stdout with logs routed to
  stderr, so stdout stays parseable. Events are emitted from
  start_negotiated_stream, the path every real session takes — previously
  StreamingStarted never fired and a consumer saw negotiated then nothing
  forever while media flowed.
• --interface replaces the hardcoded wlan0, which matches almost no
  current system.

5. Host prerequisites (documented in the README)

Both fail silently — the sink simply never connects:

• Port 7236/tcp must be reachable for the sink's return connection. Note
  that systemctl is-active ufw reporting inactive does not mean its rules
  are unloaded; that cost several debugging rounds here.
• Strict reverse-path filtering (rp_filter=1) drops P2P packets before any
  firewall rule sees them. nstat -az | grep IPReversePathFilter is the tell.

Testing

• 33 test binaries green; clippy clean; each commit builds independently.
• New coverage for the WFD parser, level sufficiency, multi-entry selection and
  profile rejection. Four existing tests asserted the H.265 misdetection or the
  removed 0000000000000017 mask — that mask never meant anything, and the
  reasons are recorded at each site rather than the tests being deleted.
• Hardware: LG webOS TV OLED55B9PLA. Repeated sessions with packet captures,
  pipewiresrc frame counts and interface byte counters.
• Every CLI flag and value in the README diff was checked against the built
  binary.

Known limitations

• HDCP not implemented. This TV advertises HDCP2.1 port=53002 but does not
  require it; a sink that enforces it will fail.
• Reconnect cooldown. Sinks generally need 30–60s before accepting a new
  session; rapid reconnects fail reliably.
• Sink-side scaling. This TV renders the 1080p stream 1:1 on its 4K panel
  (a quarter of the screen) with its own full-screen toggle. It reports
  preferred-display-mode-supported = 00, so the source cannot request a
  display mode — I believe this is webOS UI behaviour rather than something WFD
  gives us a lever for, but I'd welcome correction.
• Two concurrent sessions still contend over xdph.conf; there is
  containment but no session lock.
• Sway is untested by me — the negotiation changes affect it and I'd
  appreciate a check.