@desklink/host 0.2.0 → 0.3.1

package/docs/PROTOCOL.md

@@ -5,10 +5,15 @@ the user's session starts it and talks to it over an inherited private channel
 the engine never opens a public listener, never runs as root, and never installs
 a service.
 
-This document describes the shared Linux and macOS engine protocol. The macOS
-engine uses the same v3 stdio/WebRTC session path, with native display capture,
-input and clipboard adapters. The protocol contains no application concepts:
-no accounts, no chat, no machine ids, no pane ids.
+This document describes the Linux, macOS, and Windows engine protocol. The
+macOS engine uses the same v3 stdio/WebRTC session path, with native display
+capture, input and clipboard adapters. A Windows build with static libvpx
+(`DESKLINK_VPX_STATIC_DIR`) also serves consumer-fed H.264 encoded sources over
+the shared session path. Native desktop capture, input and clipboard are not
+implemented on Windows, and `session.open` refuses `agent_indicator` with
+`indicator-unavailable`. Without static libvpx, the Windows compile seam
+reports encoding unavailable and refuses `serve`. The protocol contains no
+application concepts: no accounts, no chat, no machine ids, no pane ids.
 
 ## Starting the engine
 
@@ -66,7 +71,7 @@ Request parameters use the engine's own snake_case names (`session_id`,
 Result:
 
 ```jsonc
-{"protocol":3,"engine":"desklink-host/0.2.0","platform":"linux", /* the rest of Capabilities */ }
+{"protocol":3,"engine":"desklink-host/0.3.0","platform":"linux", /* the rest of Capabilities */ }
 ```
 
 The consumer must send `hello` first, and a version the engine does not speak is
@@ -76,8 +81,12 @@ arrives, every other request is refused the same way; `capabilities` and
 
 ## macOS
 
+For engine installation and the macOS resolution opt-out, see the
+[host installation guide](../README.md#macos-preview).
+
 macOS speaks protocol 3 and shares the session lifecycle below. It captures the
-selected display with ScreenCaptureKit, encodes VP9, and uses the same WebRTC
+selected display with ScreenCaptureKit, encodes VP9 (and H.264 through
+VideoToolbox, for a receiver that asks for it), and uses the same WebRTC
 offer, ICE, control-channel, lease, and metrics flow as Linux. Capture currently
 uses one bounded ScreenCaptureKit stream (three-frame queue); the backend may
 supply fewer frames. Audio is not captured.
@@ -108,7 +117,7 @@ session may require fresh consent. The macOS engine requires a VP9-enabled build
 ```jsonc
 {
   "protocol": 3,
-  "engine": "desklink-host/0.2.0",
+  "engine": "desklink-host/0.3.0",
   "platform": "linux",
   "session": {"kind": "wayland"},
   "x11": {"available": true, "size": [2560, 1440]},
@@ -117,9 +126,12 @@ session may require fresh consent. The macOS engine requires a VP9-enabled build
     "backends": ["portal-screencast+pipewire", "x11-root"],
     "formats": ["bgrx", "bgra", "rgbx", "rgba"],
     "cursor": "embedded",
+    "cursor_modes": ["embedded", "hidden"],
+    "cursor_positions": {"x11": true, "portal": "negotiated"},
     "audio": false
   },
-  "encode": {"codecs": ["vp9"], "hardware": false},
+  "encode": {"codecs": ["vp9", "h264"], "hardware": false,
+             "h264": {"encoder": "vaapi", "hardware": true}},
   "input": {
     "mechanism": "inputtino/uinput",
     "pointer": true, "wheel": true, "keyboard": true,
@@ -133,6 +145,32 @@ session may require fresh consent. The macOS engine requires a VP9-enabled build
 }
 ```
 
+`encode` describes what the engine codes from a captured desktop. VP9 (libvpx,
+software; `hardware` describes it) is always there and is the default. `h264`
+appears in `codecs` when an H.264 encoder starts on this machine right now, and
+`encode.h264.encoder` names it: `videotoolbox` on macOS; on Linux `nvenc` or
+`vaapi` when the GPU has an H.264 encoder, else `openh264`, Cisco's prebuilt
+library. `encoder` is `null` when there is none. The answer to the offer picks
+between them (see *Codecs* below). Windows with static libvpx reports VP9 in
+`encode.codecs`, but has no native desktop capture; without static libvpx its
+`encode.codecs` is empty. On Windows, `encoded.codecs` reports H.264 only when
+static libvpx is linked, for consumer-fed sources; it does not mean the engine
+can encode H.264 itself.
+
+openh264 is never part of this package: the engine loads only Cisco's own
+binary, checked against its published SHA-256, from
+`$XDG_CACHE_HOME/desklink/openh264/` (else `~/.cache/desklink/openh264/`). When a
+Linux machine has no hardware H.264 encoder and the library is not there yet,
+the first captured `session.open` downloads it from Cisco
+(`ciscobinary.openh264.org`) before making its offer; that session is offered
+VP9 alone if the download fails. `capabilities` itself never downloads.
+`DESKLINK_OPENH264=off` in the engine's environment disables openh264 (no
+download, no load); `DESKLINK_OPENH264=<path>` loads that file instead, still
+only if its hash is Cisco's. `DESKLINK_H264_ENCODER=<name>` restricts the engine
+to one H.264 encoder (`off` for none), for measuring one backend. Cisco's
+licence asks that this be stated: OpenH264 Video Codec provided by Cisco
+Systems, Inc.
+
 `encoded` lists the codecs this build will carry when the consumer supplies the
 video itself (see *Encoded sources*): a consumer reads it rather than inferring
 support from the engine's version string.
@@ -168,12 +206,13 @@ trigger a capture request.
   "permissions": ["view","control","clipboard"],
   "max_width": 3840, "max_height": 2160, // encode box (default); never upscales
   "bitrate_kbps": 0,                    // 0 (default): sized to the encoded surface
-  "max_fps": 30,
+  "max_fps": 60,
   "ice_servers": [{"urls":["stun:..."],"username":null,"credential":null}],
   "restore_token": null,                // from a previous session.restoreToken
   "ttl_seconds": 3600,                 // session lease; default 3600
   "loopback_tcp": false,               // also offer ICE over TCP on 127.0.0.1; default false
-  "agent_indicator": false             // local input feedback; default false (phone control)
+  "agent_indicator": false,            // local input feedback; default false (phone control)
+  "local_frames": true                 // keep frames for session.frame; default true
 }}
 ```
 
@@ -201,7 +240,7 @@ clipboard action and never infers them from a source, a peer or an SDP.
 `control` without a working input backend is refused at `session.open` with
 `error.code = "input-unavailable"` — the consumer must ask for `view` explicitly instead.
 
-`max_fps` defaults to 30 and is bounded to 1–60. It caps the encoded frame
+`max_fps` defaults to 60 and is bounded to 1–60. It caps the encoded frame
 rate and X11 capture loop; portal capture offers it as the preferred PipeWire
 frame rate, and macOS sets its ScreenCaptureKit stream minimum frame interval.
 A source may still supply fewer frames.
@@ -211,11 +250,19 @@ sets it for control sessions, never for view-only or human phone control. It
 adds an eased pointer halo, click ripple, and typing pulse. On Wayland it uses
 a click-through layer-shell surface with an edge glow; its bounded area is
 masked before capture/diff (pixels behind the effect can remain briefly stale).
-On bare X11 it replaces the pointer sprite instead, which XGetImage excludes:
+On bare X11 it replaces the pointer sprite instead, which the X11 grab excludes:
 there is no edge glow on that path. macOS uses a nonactivating, click-through
 window excluded by the ScreenCaptureKit content filter. Closing the session
 fades and removes the indicator.
 
+`local_frames` keeps the latest pre-encode frame and its tile hashes for
+`session.frame` and `session.frame.changed` (see "Latest frame over the local
+protocol"). A consumer that only streams sets it to `false`: each captured
+frame is then converted once, for the encoder, no frame is kept, no
+`session.frame.changed` is emitted, and `session.frame` is refused with
+`error.code = "operation"`. The WebSocket bridge sets it to `false` unless its
+host listens to engine events, because neither travels past the socket.
+
 `session.open` is where the capture request happens, which is where the user's
 consent appears. It is not implicit and it is not retried silently.
 
@@ -243,6 +290,36 @@ the SDP and candidates to the client and brings back the answer.
 
 A candidate that arrives before the remote description is buffered, not dropped.
 
+#### Codecs
+
+For a captured desktop the offer's video section lists VP9 (payload type 98)
+and, when `capabilities.encode.codecs` has `h264` and the encoded surface is
+within H.264 level 5.2 (at most 36864 16x16 macroblocks, e.g. 4096x2304 — a
+5K surface is offered VP9 alone), H.264 after it (payload type
+102, `packetization-mode=1`, Constrained Baseline, `profile-level-id=42e034`
+with `level-asymmetry-allowed=1`). The engine codes whichever of the two the
+answer lists first. A receiver that applies the offer as it comes answers in
+the offer's order and gets VP9, as before; a receiver that wants H.264 puts it
+first — with `setCodecPreferences` before `createAnswer`, or by moving its
+payload type to the front of the offer's `m=video` line before applying it.
+The iOS receiver in `@desklink/client` does the latter, because iOS decodes
+H.264 in hardware and VP9 in software; the web and Android receivers keep VP9.
+The choice is made by the first answer and kept for the session, ICE restarts
+included; the encoder starts after that answer, so the first frame sent is
+already in the chosen codec. H.264 is coded at the full encoded size throughout
+(no half-size motion), with an IDR carrying its SPS and PPS only for the first
+frame and on a receiver's request. An `encoded` source offers H.264 alone, as
+described under *Encoded sources*.
+
+The offer negotiates the `playout-delay` RTP header extension
+(`http://www.webrtc.org/experiments/rtp-hdrext/playout-delay`), and every video
+packet asks for a playout delay of 0: a receiver that honours it shows each
+frame when it is decoded instead of buffering frames to smooth playback. A
+receiver may decline the extension in its answer; its packets then carry no
+playout delay and it buffers as usual. The iOS receiver in
+`@desklink/react-native` declines it, because `RTCView` draws a frame only when
+its timestamp is new and zero-delay frames all carry the same one.
+
 A client whose ICE connection goes `disconnected` may restart ICE on the same
 peer connection instead of opening a new session: it sends
 `session.restart_ice` with the session's id and generation, and the engine
@@ -278,8 +355,9 @@ always does.
 
 `disconnected` is ICE losing the path: the picture is frozen but the session
 is alive, and a client should show reconnecting and may restart ICE (above)
-rather than open a new session. `failed` is terminal: the engine revokes and
-closes the session, and only a new `session.open` recovers it.
+rather than open a new session. `failed` is terminal: the engine revokes the
+session with code `transport` and closes it, and only a new `session.open`
+recovers it.
 
 While its control channel is open the engine also sends a heartbeat twice a
 second, `{"kind":"ping"}`. It lets a client notice a stalled path within
@@ -310,10 +388,26 @@ picker; restoration is silent only where the backend supports it. Cancellation
 is an error, not a reason to retry or bypass consent.
 
 ```jsonc
-{"event":"session.revoked","params":{"sessionId":"…","reason":"…"}}
+{"event":"session.revoked","params":{"sessionId":"…","reason":"…",
+  "code":"transport"}}                // transport|lease|error
 ```
 
 The session ended on the engine's side; there is nothing further to drain.
+`reason` is prose for people; `code` is what a client acts on:
+
+| `code` | Meaning | A client should |
+|---|---|---|
+| `transport` | The path to the client's peer was lost (ICE `failed`, or the track refused a frame) | open a new session with fresh authority; the desktop is still available |
+| `lease` | The session's `ttl_seconds` ran out | end; the grant is spent |
+| `error` | The engine could not keep serving it, such as an encoder refusing a frame | end and report |
+
+A session the consumer closes or replaces (`session.close`, a new
+`session.open`, the consumer leaving) sends no `session.revoked`: the consumer
+asked for it, and signaling sees `session.state` with `capture` `ended`. Only
+its control channel is told, with code `closed` (below).
+
+A code a client does not know is terminal. Engines before this field sent no
+`code`; treat its absence as terminal too.
 
 Metrics are a request, not a notification:
 
@@ -323,17 +417,158 @@ Metrics are a request, not a notification:
 
 ```jsonc
 {"id":7,"result":{"captured_frames":812,"dropped_frames":3,"encoded_frames":809,
-  "encoded_bytes":12345678,"key_frames":1,"refined_frames":37,
+  "encoded_bytes":12345678,"key_frames":1,"refined_frames":37,"halved_frames":0,"motion_frames":770,
   "encode_micros":7390000,"target_kbps":16430,"input_applied":44,"input_rejected":0,
-  "fed_frames":0,"input_forwarded":0}}
+  "fed_frames":0,"input_forwarded":0,"codec":"vp9","encoder":"libvpx",
+  "capture_micros":14100000,"convert_micros":3200000,
+  "queue_micros":410000,"send_micros":180000}}
 ```
 
 `dropped_frames` counts frames superseded by a newer one before they were coded;
-the newest frame is always coded. `refined_frames` counts refinement passes: a
+the newest frame is always coded. That includes frames that arrived while a
+large one (a key frame, a refinement) was still crossing the link: the stream
+runs at most about 60 ms of its rate target ahead of it, so frames never queue
+behind a burst. `refined_frames` counts refinement passes: a
 desktop that stops changing is coded once more at a fine quantizer, so it reads
-sharp. Key frames are sent only for the first frame and when the receiver asks
-(RTCP PLI or FIR). `target_kbps` is the current rate target after any back-off
-for loss the receiver reported.
+sharp. `halved_frames` counts motion frames coded at half width and height: when
+full-size frames that change much of the picture take longer to code than a
+frame interval while a newer frame is already waiting, several frames in a row,
+motion is coded at half size until the desktop stops or its changes shrink to
+small ones that code in time; the refinement pass is always full size. Key
+frames are sent only for the first frame, when the receiver asks (RTCP PLI or
+FIR), and when the coded size changes that way, so a receiver never has to scale
+references across a size change. `target_kbps` is the current rate target after
+any back-off: for a standing queue on the path, measured from the receiver's
+transport-wide congestion feedback (RTP `transport-cc`), and for the loss
+its receiver reports carry. `codec` is what frames go out in
+(`vp9` or `h264`) and `encoder` what codes them (`libvpx`, `videotoolbox`,
+`nvenc`, `vaapi` or `openh264`); both are empty for an encoded source.
+
+Per-stage timings (the L0 lab harness reads these, and every later lane cites
+them). Each is a cumulative microsecond counter; divide by the frame count
+named beside it for the per-frame mean:
+
+- `capture_micros` / `captured_frames`: grabbing a frame and converting it on
+  the capture thread (on X11: an MIT-SHM grab, falling back to socket
+  `GetImage` where the server lacks MIT-SHM, plus the downscale to I420), over
+  forwarded (changed) frames only — unchanged polls are excluded.
+- `convert_micros` / `captured_frames`: tile hashing and damage computation on
+  the capture thread, after the grab; the hash branch runs only with
+  `local_frames` on.
+- `queue_micros` / `motion_frames`: how long a freshly captured frame waited
+  between the capture handoff and the start of its encode. Refinement,
+  keepalive and receiver-requested re-encodes re-code a picture that was
+  already sent; they queue nothing and stay out of this mean.
+- `send_micros` / `encoded_frames`: packetizing a frame and handing it to the
+  transport.
+- `encode_micros` / `encoded_frames`: the encoder alone.
+
+`capture + convert` per captured frame plus `queue` per motion-coded frame and
+`encode + send` per encoded frame reconciles against engine-side wall time per
+frame within measurement noise; a stage that will not reconcile is a stage
+whose accounting is wrong.
+
+## Cursor-free capture
+
+`session.open` accepts `cursor: "hidden"` (default `"embedded"`). Existing
+callers keep their capture behavior. Linux hidden capture requires portal
+**Metadata** so cursor positions remain available while cursor pixels are
+omitted. A portal without Metadata returns the typed
+`cursor_positions_unavailable` refusal. Successful open returns
+`cursor: {"mode":"metadata"|"hidden"|"embedded"|"unavailable",
+"positions":true|false}`; `mode` names the portal mode accepted by the portal,
+not just the requested option.
+
+Linux capabilities advertise `capture.cursor_modes: ["embedded","hidden"]`
+and `capture.cursor_positions: {"x11":true,"portal":"negotiated"}`. Portal
+support is resolved at open: hidden capture requires Metadata and an observed
+SPA cursor metadata buffer. A portal that offers only Hidden refuses open with
+`cursor_positions_unavailable`; accepted hidden sessions report `positions:true`.
+Metadata-mode buffers that contain no new cursor data do not fabricate a move
+or a visibility change.
+
+Hidden sessions with positions emit local protocol events independently of
+pixel damage, including on a still X11 desktop:
+
+```json
+{"event":"session.cursor","params":{"sessionId":"…","x":400,"y":300,"visible":true,"timestamp_us":123456}}
+```
+
+`x,y` name the pointer hotspot in the selected source's coordinates
+(`geometry.source`), before video scaling, without the desktop origin added.
+Portal buffer coordinates are mapped to that geometry. `visible` is false
+outside the source or when SPA supplies an invisible cursor bitmap.
+`timestamp_us` is a monotonic engine-process clock in microseconds, sampled
+when the capture thread observes the pointer. The same clock stamps
+`session.frame.changed` and `session.frame` metadata, so local recording
+consumers can compare cursor samples to frame handoff times. These are not
+wall-clock or RTP timestamps. SPA cursor updates accompany PipeWire buffers;
+X11 pointer queries run at the session frame cap even with no pixel damage.
+Repeated identical positions/visibility are suppressed.
+
+X11 root GetImage/MIT-SHM never contains the server cursor and this engine
+never composites it, including for existing embedded-default callers. Its
+open reply therefore reports `mode:"hidden"`; positions are enabled only by
+an explicit `cursor:"hidden"`. macOS and Windows refuse hidden capture with
+`cursor-unavailable` in this build. Consumer-fed encoded sources refuse it too:
+the engine cannot remove pixels the consumer already encoded. Unknown cursor
+options are `malformed`.
+
+`@desklink/host` exposes `openSession({permissions:['view'], cursor:'hidden'})`
+and typed `session.cursor` events through `onEvent`/`drainEvents`. The client
+capture request also accepts `cursor`, and AXI accepts `start --cursor hidden`.
+
+## Point on the host desktop
+
+A local consumer can guide the person without taking control of their pointer
+or keyboard. `session.point` requires `view`, not `control`, and is independent
+of `agent_indicator`. It draws one blue ring centered at `x,y`, with an optional
+label. A new point replaces the previous one and restarts its timer.
+
+```jsonc
+{"id":30,"method":"session.point","params":{"session_id":"…","x":400,"y":300,"label":"Here","timeout_ms":3000}}
+{"id":30,"result":{"shown":true}}
+{"id":31,"method":"session.point","params":{"session_id":"…","clear":true}}
+{"id":31,"result":{"shown":false}}
+```
+
+Coordinates are integers in the **selected desktop's original pixels**, top-left
+origin, before video scaling (`geometry.source`, not `geometry.encoded`). On X11
+this is the root screen; on macOS it is the selected display, with native pixels
+converted to display points. Both coordinates must be within its bounds. The
+ring may clip at an edge; its label stays inside the display. `timeout_ms`
+defaults to 3000 and must be an integer from 1 to 120000. Labels are at most 96
+printable ASCII bytes, including spaces; other labels are refused rather than
+rendered incorrectly by the X server's core font. A clear request has no
+coordinates, label or timeout, and is idempotent. Invalid requests do not alter
+an existing marker. Replies acknowledge submission to the local overlay helper,
+not that a person has seen it. Timeout hides it; clear, session replacement,
+lease expiry, close and consumer disconnection remove and reap the helper.
+
+X11 uses an override-redirect, shaped window with an empty input shape. It never
+warps the pointer, changes the cursor, requests focus or injects events. macOS
+reuses the nonactivating, mouse-transparent indicator window in a separate
+helper. **Point cues intentionally appear in local frames and outgoing video**:
+the person and observer can see the same cue. They are separate from the
+capture-excluded input activity indicator. Consumers reading frame differences
+should allow for the point's appearance/disappearance.
+
+Wayland portal sessions use a wlr-layer-shell overlay with no keyboard
+interactivity and an empty input region. The selected monitor is matched by its
+portal origin against compositor logical output geometry (xdg-output); with one
+output, no origin is needed. Points map from the selected source to that output.
+An ambiguous or missing selected output returns `indicator-unavailable`.
+Compositors without layer-shell return `point_unsupported` with reason
+`layer_shell_unavailable` (including GNOME Mutter). Consumer-fed encoded sources return `operation`
+because they have no host desktop overlay target. Other refusals are `permission`, `session`,
+`coordinates`, `malformed`, and `indicator-unavailable` (including unavailable
+X Shape support). Unknown fields are refused. No control-channel or remote
+bridge forwarding is added; the consumer chooses when to request a local cue.
+
+`@desklink/host` exposes `EngineClient.point(sessionId, {x, y, label?, timeoutMs?})`
+and `EngineClient.point(sessionId, {clear: true})`. `@desklink/axi` exposes
+`desklink-axi point 400,300 --label "Here" --timeout 3000` and
+`desklink-axi point --clear`, including for a session started without `--control`.
 
 ## Input and clipboard: the session's control channel
 
@@ -373,7 +608,7 @@ The engine answers on the same channel, and sends two things unprompted:
 {"kind":"ack","seq":44}
 {"kind":"rejected","seq":44,"code":"coordinates","message":"(9000,4) is outside the 1280x720 surface"}
 {"kind":"clipboard","request":"…","text":"…","truncated":false}   // an empty "text" with "error" when the read failed
-{"kind":"revoked","reason":"…"}
+{"kind":"revoked","reason":"…","code":"closed"}  // closed, or a session.revoked code
 ```
 
 Refusal codes: `permission`, `session`, `input-replay`, `coordinates`,
@@ -494,9 +729,12 @@ is the consumer's to carry.
 
 `session.frame` and `session.wait_frame` are refused with `error.code =
 "operation"` — there is no lossless frame to read — and `captured_frames`,
-`refined_frames` and `target_kbps` stay at zero while `fed_frames` counts what
-the consumer handed over and `encoded_frames`, `encoded_bytes`, `key_frames`
-and `encode_micros` describe what was packetized and sent.
+`refined_frames`, `halved_frames`, `motion_frames`, `target_kbps`, `capture_micros`,
+`convert_micros`, `queue_micros` and `send_micros` stay at zero while
+`fed_frames` counts what the consumer handed over and `encoded_frames`,
+`encoded_bytes`, `key_frames` and `encode_micros` describe what was packetized
+and sent — on this path `encode_micros` covers packetizing and sending too,
+because packetization is the only stage the engine itself runs.
 
 ## Latest frame over the local protocol
 
@@ -516,7 +754,8 @@ of stillness. When both are supplied, both conditions must hold.
 Each changed capture emits a local `session.frame.changed` event with `sessionId`,
 `seq` and `damage`, allowing a co-located consumer to track animation across
 observations. Neither the event nor this file-writing method is forwarded by
-the remote WebSocket bridge.
+the remote WebSocket bridge. A session opened with `local_frames: false` keeps
+no frame: both are refused with `error.code = "operation"` (see `session.open`).
 
 ```json
 {"id":20,"method":"session.frame","params":{"session_id":"…","since":7,"path":"/run/user/1000/frame.raw"}}
@@ -616,7 +855,8 @@ anything to show.
 
 - It does not decide *who* the user is. It trusts the consumer's local
   permission decision and enforces the resulting scope; there is no second
-  account, token or pairing ceremony.
+  account, token or pairing ceremony. For consumer integration, see the
+  [BYOKit guidance](../../../README.md#why-desklink-exists).
 - It does not open ports, register a service, install udev rules, join groups or
   raise capabilities. Kernel input access is a separate, explicit, guided step
   (`desklink-host setup-input` reports what is missing; it does not change it).

package/engine/Cargo.lock

@@ -307,6 +307,16 @@ version = "1.12.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "fc652a48c352aef3ea3aed32080501cf3ef6ed5da78602a020c991775b0aff04"
 
+[[package]]
+name = "bzip2-rs"
+version = "0.1.2"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "beeb59e7e4c811ab37cc73680c798c7a5da77fc9989c62b09138e31ee740f735"
+dependencies = [
+ "crc32fast",
+ "tinyvec",
+]
+
 [[package]]
 name = "cc"
 version = "1.4.7"
@@ -449,6 +459,15 @@ dependencies = [
  "rustc_version",
 ]
 
+[[package]]
+name = "crc32fast"
+version = "1.5.2"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "01a7799fd6b852db0e61728dde9a204c423b44d689dbd432522543614b490e78"
+dependencies = [
+ "cfg-if",
+]
+
 [[package]]
 name = "crossbeam-utils"
 version = "0.8.23"
@@ -517,7 +536,7 @@ checksum = "7cd812cc2bc1d69d4764bd80df88b4317eaef9e773c75226407d9bc0876b211c"
 
 [[package]]
 name = "desklink-host"
-version = "0.2.0"
+version = "0.3.1"
 dependencies = [
  "anyhow",
  "ashpd",
@@ -525,8 +544,8 @@ dependencies = [
  "base64 0.22.1",
  "block2",
  "bytes",
+ "bzip2-rs",
  "cc",
- "futures-util",
  "libc",
  "log",
  "objc2-core-foundation",
@@ -534,13 +553,18 @@ dependencies = [
  "objc2-core-media",
  "objc2-foundation",
  "objc2-screen-capture-kit",
+ "openh264-sys2",
  "pipewire",
  "rand 0.8.8",
  "rtc",
  "serde",
  "serde_json",
+ "sha2",
  "tokio",
+ "wayland-client",
+ "wayland-protocols",
  "webrtc",
+ "windows-sys 0.61.2",
  "wl-clipboard-rs",
  "x11rb",
  "xkbcommon",
@@ -1430,6 +1454,16 @@ version = "1.21.4"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "9f7c3e4beb33f85d45ae3e3a1792185706c8e16d043238c593331cc7cd313b50"
 
+[[package]]
+name = "openh264-sys2"
+version = "0.9.8"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "6ada29a4cadc13d4d326737af87c13e224210d7d99fe47594e9f3f9b0102fd70"
+dependencies = [
+ "libloading",
+ "sha2",
+]
+
 [[package]]
 name = "ordered-stream"
 version = "0.2.0"
@@ -2239,6 +2273,17 @@ dependencies = [
  "digest",
 ]
 
+[[package]]
+name = "sha2"
+version = "0.10.9"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "a7507d819769d01a365ab707794a4084392c824f54a7a6a7862f8c3d0892b283"
+dependencies = [
+ "cfg-if",
+ "cpufeatures 0.2.17",
+ "digest",
+]
+
 [[package]]
 name = "shlex"
 version = "1.3.0"

package/engine/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "desklink-host"
-version = "0.2.0"
+version = "0.3.1"
 edition = "2021"
 rust-version = "1.97.1"
 license = "Apache-2.0"
@@ -16,10 +16,9 @@ serde = { version = "1", features = ["derive"] }
 serde_json = "1"
 base64 = "0.22"
 
-[target.'cfg(target_os = "linux")'.dependencies]
+[target.'cfg(any(target_os = "linux", target_os = "macos", target_os = "windows"))'.dependencies]
 anyhow = "1"
 tokio = { version = "1", features = ["rt-multi-thread", "macros", "io-util", "io-std", "sync", "time", "signal"] }
-futures-util = "0.3"
 libc = "0.2"
 bytes = "1"
 webrtc = { version = "0.21", default-features = false, features = ["runtime-tokio", "crypto-ring"] }
@@ -27,22 +26,28 @@ rtc = { version = "0.21", default-features = false, features = ["crypto-ring"] }
 log = "0.4"
 async-trait = "0.1"
 rand = "0.8"
+
+[target.'cfg(target_os = "linux")'.dependencies]
 ashpd = { version = "0.11", default-features = false, features = ["tokio"] }
 pipewire = { version = "0.10", features = ["v0_3_44"] }
 xkbcommon = "0.8"
-x11rb = { version = "0.14", default-features = false, features = ["allow-unsafe-code", "xtest"] }
+x11rb = { version = "0.14", default-features = false, features = ["allow-unsafe-code", "xtest", "shm", "damage"] }
 wl-clipboard-rs = "0.9"
+# H.264 fallback: Cisco's prebuilt openh264, loaded at runtime (never built
+# from source), fetched once as bzip2 and checked against a pinned sha256.
+openh264-sys2 = { version = "0.9.8", default-features = false, features = ["libloading"] }
+sha2 = "0.10"
+bzip2-rs = "0.1.2"
+
+[target.'cfg(target_os = "linux")'.dev-dependencies]
+# The Wayland stamp example only; already in the tree through wl-clipboard-rs.
+wayland-client = "0.31"
+wayland-protocols = { version = "0.32", features = ["client"] }
+
+[target.'cfg(target_os = "windows")'.dependencies]
+windows-sys = "0.61.2"
 
 [target.'cfg(target_os = "macos")'.dependencies]
-anyhow = "1"
-async-trait = "0.1"
-bytes = "1"
-libc = "0.2"
-log = "0.4"
-rand = "0.8"
-rtc = { version = "0.21", default-features = false, features = ["crypto-ring"] }
-tokio = { version = "1", features = ["rt-multi-thread", "macros", "io-util", "io-std", "sync", "time", "signal"] }
-webrtc = { version = "0.21", default-features = false, features = ["runtime-tokio", "crypto-ring"] }
 objc2-screen-capture-kit = { version = "0.3.2", features = ["SCStream", "SCShareableContent", "SCError", "SCScreenshotManager", "block2", "dispatch2", "objc2-core-media", "objc2-core-graphics"] }
 objc2-foundation = { version = "0.3.2", features = ["NSArray", "NSError", "NSString"] }
 objc2-core-media = "0.3.2"