Feasibility: can yoke's goal be built?

USB selection update: the current product uses two Radxa ZERO 3E hardware boxes and targets USB 2 first. See the agreed USB design. Earlier NanoPi/VirtualHere and USB3 recommendations in this dated study are not the selected design.

Status: cold review, 2026-09-24, from four live-web research lanes plus local benchmarks. This is the canonical verdict; HARDWARE.md holds the market detail, COMPRESSION.md the codec trade-offs, and ../design/EDGE-DEVICES.md the endpoint design built on this.

Flags: V verified against a primary source or measured; I inferred or computed; ⚠ bench-unverified (see AGENTS.md).

The goal

A fully decentralized, point-to-point, reconfigurable mesh of HDMI and USB bridge devices over a switched IP network. The network baseline is switched 10GbE (user, 2026-09-24). Endpoint hardware should be as small as possible. The first concrete link is a closet gaming PC (RTX 5090, 4K120) to a desk monitor plus USB peripherals, at competitive- gaming latency.

Verdict: possible. Two specific combinations are not.

Impossible: bit-exact 4K 4:4:4 at 60 Hz or above over 10G (physics), and decrypting or compressing HDCP content without a license (law). Not yet sold: a 4K120 endpoint over 10G that is near-transparent. Everything else is engineering and money.

Settled concern (2026-09-24)

An earlier session concluded the goal was not possible. That conclusion conflated "no one sells it" with "cannot be built", assumed 25G uncompressed as the only 4K120 route, and missed GPU-side DSC (below). Rejected on the evidence in this document; re-raise only with new evidence.

The arithmetic

10GbE carries 10.0 Gb/s at the MAC. After Ethernet, IP, UDP, and RTP overhead the usable payload is ≈9.4 Gb/s at 1500 MTU, ≈9.9 Gb/s at 9000 MTU (I). Plan on ≤ ~9 Gb/s sustained for headroom.

Active-pixel rates (3840×2160 = 8.29 Mpx):

So on 10G, 4K 4:4:4 at 60 Hz or above needs compression (4K30 4:4:4 8-bit, 5.97 Gb/s, fits uncompressed). 4K120 4:4:4 needs 2.7:1 (8-bit) to 3.3:1 (10-bit). DSC at 8 bpp is 3:1 on 8-bit RGB, which is VESA's visually-lossless design point, and 3.75:1 on 10-bit, which is beyond it (I).

For comparison, uncompressed 1080p120 4:4:4 8-bit (5.97 Gb/s) and 1440p120 4:2:2 8-bit (7.08 Gb/s) fit 10G bit-exact.

The 4K120 routes, ranked

Route A: DSC passthrough (the key finding)

The GPU already compresses with VESA DSC when the sink advertises DSC and the mode doesn't fit the link. If an endpoint can pick that bpp and carry the compressed stream without decoding it, no codec is needed. NVIDIA's open kernel modules (the Blackwell display classes inherit the same code) show:

• Uncompressed is always tried first; DSC engages only when the advertised link can't carry the mode (V, nvhdmipkt_C671.c).
• DisplayPort: bpp = min(link bandwidth ÷ pixel clock, sink maximum bpp from DPCD 0x067–0x068) (V, nvt_dsc_pps.c, dp_deviceimpl.cpp). A synthesized sink advertising max 8 bpp plus a link too slow for uncompressed 4K120 forces 8 bpp ≈ 7.96 Gb/s (I). NVIDIA's DP MST path already falls back to 8 bpp (V).
• HDMI: the GPU takes the lowest FRL rate where the minimum bpp fits, then the highest bpp that fits there. 4K120 at 8 bpp doesn't fit 3 lanes × 3G, so it steps to 3 × 6G and lands on 12 bpp ≈ 11.9 Gb/s, over 10G (code V, arithmetic I). Only native 4:2:0 DSC fits. So route A is DisplayPort-only for 4:4:4.
• The Linux bpp override needs the sink's DSC_All_bpp and does not help a Windows gaming PC (V).

Receivers that hand over the compressed stream instead of decoding it:

Blockers, in order: (1) Lontium NDA firmware: whether DPCD max-bpp and the DSC path are configurable; (2) a desk-side transmitter that re-emits a DSC stream to a DSC-capable monitor (or decodes it); (3) the pixel clock must be locked across the link; (4) the Windows driver's DSC policy is inferred from shared open code, not observed ⚠. No one has been found carrying DSC over Ethernet (V, negative search), so this is novel work.

Removing codec IP also removes the D-PHY bandwidth problem the previous 25G design had: ~8 Gb/s fits a 4-lane 2.5G D-PHY (I). A 3-lane 2.5G connector (7.5 Gb/s) does not, so a board with 3-lane connectors needs two of them (dual-port DSI) ⚠.

Route D: the commodity path, measured

SVT-JPEG-XS on a Core Ultra 9 285K (lane benchmark, V): 4K 4:2:2 10-bit at 4 bpp encodes at 167 fps on 8 P-cores and decodes at 246 fps; measured per-frame latency when paced at 120 fps is 5.8 ms encode and 4.3 ms decode. Four P-cores fail 120 fps. The recommended small box (Minisforum MS-A2, 16 Zen5 cores) was not benchmarked (I). Consumer HDMI 2.1 capture cards deliver MJPEG at 4K120; raw 4K120 needs a pro card (Yuan SC750N1-L or DeckLink 8K Pro G2). Stage budget: capture ≥1 frame (8.3 ms) + repack 1–2 + encode 3–6 + serialize (overlappable) + decode 2.4–4.3 + present 0–8.3 ms ⇒ ~15–32 ms added (~15 only with slice streaming and a VRR display; ~20–32 typical). Workable for desktop use; fails "feels like a cable" for competitive gaming.

USB

USB 3 over a switched network exists, but no product is at once driverless, controllerless, API-re-pairable, and multi-switch:

The mesh-able path is software: a real USB host at the device end plus VirtualHere (Linux server → Windows client; documented attach/detach API). USB3 DisplayLink over any USB-over-IP is unproven (only a USB2 DisplayLink display has been shown working, V). Details in HARDWARE.md §USB.

HDCP: pass-through, not a repeater

HDCP encrypts the pixel data on the link; the source and the sink authenticate over HDMI's DDC channel and share the session key. A bridge that forwards the ciphertext unchanged and tunnels the DDC handshake verbatim is invisible to both: the source authenticates the real display, and the bridge never decrypts. This is how HDMI extenders, fiber HDMI cables, and HDBaseT carry protected content. It is permitted for yoke-designed endpoints by ADR 0011.

What it can't do: ciphertext is effectively random, so it cannot be compressed, and every encoding step (DSC, JPEG XS, chroma subsampling) needs decrypted pixels. The bridge carries every encrypted bit at full rate. With blanking regenerated identically at the far end, the payload is roughly the active-pixel rate:

The bridge owns the EDID it presents, so it can steer a source into a format that fits (e.g., advertise 4K60 only at 4:2:0); EDID carries no HDCP information, so this is not a protection downgrade.

Engineering requirements:

• Raw link capture. Merchant HDMI receiver chips (including Lontium) are HDCP endpoints that decrypt with licensed keys or output black, so they cannot supply ciphertext. Capture TMDS in FPGA transceivers (feasible for HDMI 2.0-class links); HDMI 2.1 FRL would also need its link layer implemented.
• Identical timing, clock-locked. The HDCP keystream is indexed by frame and pixel position, so the far end must reproduce the source's exact timing. HDCP 2.x uses AES counter mode: a lost packet corrupts only its own pixels, but losing frame sync blanks the screen until the source re-authenticates.
• Real-time handshake tunnel. HDCP 2.x over HDMI is message-based (write/read message buffers plus a status register at DDC address 0x74), so a local DDC proxy that forwards writes and mirrors the far sink's replies fits its timeouts. The locality check allows 20 ms round trip on HDMI; a switched LAN is ~0.3 ms. HDCP 1.4's register- mirrored link check (Ri' every 128 frames) is more timing-sensitive ⚠.
• Strictly one sink per session. The source authenticates one display; a second display on the same ciphertext cannot decrypt it. One-to-many protected distribution needs a licensed repeater.

Legal reading, not a legal opinion: a relay that never decrypts is not circumvention (that is what HDCP strippers do), and the HDCP license binds licensees implementing HDCP functions, which a pass-through does not. Extenders in this class are sold widely. A commercial product needs this reviewed, plus HDMI Adopter status.

Licensed repeaters (terminate as a certified sink, protect the IP hop with HDCP 2.x IIA, re-originate downstream) are only needed to decrypt, compress, or fan out. HDCP has no per-unit royalty, only an annual adopter fee, but hand-rolled repeater HDCP must pass robustness and compliance testing (Aug 2026 research). yoke drives purchased repeaters and never participates (ADR 0004).

What earlier docs got wrong (corrected here)

Earlier research documents (Aug 2026 lanes, build plan, FPGA cost, 4K120 floor, platform pick) were removed from the tree on 2026-09-24; retrieve them with git show 4e28967:<path>.