A Linux receiver

[nbkdoesntknowcoding]

The idea

The receiver is a Tauri app: a Rust backend owning the WebSocket, and a TypeScript frontend decoding H.264 with WebCodecs onto a canvas. Tauri targets Linux, and the Rust half already compiles on non-Windows — it builds and its 53 tests pass on macOS today, because the Windows-specific parts are behind cfg with fallbacks.

So the distance to a Linux receiver is smaller than it looks. A spare Linux laptop is a second monitor nobody is using.

What is genuinely portable

• The wire protocol, its parser and the golden vectors
• Discovery, pairing, the session loop, the reconnect logic
• The whole frontend, including the timing meters and the HUD — WebCodecs is in WebKitGTK and Chromium alike

What is not, and needs doing

• link.rs identifies the adapter carrying the stream via GetAdaptersAddresses. Linux needs a netlink or /sys/class/net equivalent to report the same thing: interface kind, wired or not, link speed. There is already a non-Windows stub returning None — that is the seam.
• Input injection in the reverse direction (Mac controlling this machine) uses Windows SendInput. On Linux that is uinput under X11, and considerably more awkward under Wayland, where synthetic input is deliberately restricted. Scoping the first version to receive-only, with no reverse control, is a completely reasonable first PR and avoids that entirely.
• Screen capture for the reverse direction uses DXGI Desktop Duplication. The Linux equivalent is PipeWire and the portal, which is its own project.
• Fullscreen, window state and the tray, all Tauri-level but not free.
• Packaging. AppImage or Flatpak, and CI to build it.

A sensible first cut

Receive-only. Discover a Mac, pair, show the stream fullscreen, HUD included. No reverse sharing, no input forwarding. That is a genuinely useful application on its own — it turns any Linux machine into a second display for a Mac — and it needs almost no new protocol work.

Everything else can follow, or not.

Worth knowing before starting

• WebKitGTK's WebCodecs support varies by version. Establish which decoders actually work before building around them — and note the finding recorded in the README, that Chrome's hardware H.264 decoder measured 22× worse than software on the same stream. Do not assume hardware decode is the fast path; measure it, and the receiver already has the instrumentation to do so.
• The protocol has golden vectors shared by both existing implementations. A third implementation should be tested against the same bytes, never against the others.