USB/IP and video adapters
This page describes adapters already in the code. The USB product is the two-box ZERO 3E hardware design. The Linux USB/IP adapter below is one part of its development, not the product wiring diagram.
A driver translates a saved pairing into a specific endpoint action. The agent configures the backend; it never carries or inspects its media payload. Select a backend that understands the producer’s media description and the consumer’s role.
Available adapters
| Driver | Role | What it does | What active establishes |
|---|---|---|---|
sim |
Producer and consumer | Scriptable in-memory behavior for offline development | The simulated attachment completed |
jap |
HDMI producer and consumer | Advertises a producer channel or selects a Just Add Power decoder channel | The configured channel was confirmed |
igmp |
HDMI consumer | Holds multicast group membership for an external renderer | Membership was joined |
stream |
HDMI consumer | Supervises an external GStreamer receiver process | The worker is running |
usbip |
USB producer and consumer | Exports local devices or imports remote devices into Linux | Backend export/import checks passed |
active is backend-specific evidence. None of these adapters independently
proves a working physical display or a successful USB application.
Hardware API assumptions and device compatibility still need bench tests.
HDMI
Use the repository’s producer and consumer configs as starting points for the JAP adapter. The stream consumer example supervises an external receiver. It requires the GStreamer tools and device/display permissions described in the media reference.
The IGMP reference manages membership only. Provide a separate renderer; joining a multicast group does not decode video.
USB/IP
The USB/IP consumer example imports exported devices into the consumer host’s Linux USB stack. It requires Linux USB/IP tooling, kernel support, and narrowly scoped device privileges. The Linux kernel carries the USB payload.
A physical USB output that presents the imported device to a separate computer is required by the selected hardware design. Its device/gadget bridge is unimplemented. The computer-side Yoke box remains part of the product even though that firmware work is unfinished. YWP/1 stores a route per consumer and has no distributed source-owner transaction. USB/IP refuses simultaneous device attachment, and the reference driver reconciles its locally owned imports. Plan a single consumer for each exported device.
ADR 0014 records import ownership and recovery limits.
IR and proposed hardware
There is no IR routing driver. The ESP32 firmware reference implements an updater, not IR learning, routing, or emission.
The endpoint roadmap preserves earlier video and USB3 research. The USB hardware design records the selected ZERO 3E platform and USB 2 first scope. Candidate backends named in that roadmap are not implemented simply because they appear in a design table. The project status is the concise capability map.
Add a backend
Read the architecture and the contributor guide. Keep device I/O in the driver, report explicit attachment evidence, and cover failure and teardown with deterministic scripted transcripts.