Expand description
USB HID keyboard handler.
Wraps usbip::hid::UsbHidKeyboardHandler rather than replacing it: the crate’s key-down /
key-up state machine on the interrupt IN endpoint is exactly right, and reimplementing it
would be a second copy to keep in step. Everything on endpoint 0 is handled here
instead, for two reasons.
1. LED output reports. A host tells a keyboard about Caps/Num/Scroll Lock with a class
SET_REPORT on the control endpoint (the device has no OUT endpoint). The crate’s handler
never sees it, which is why usb_keyboard_led_status was a declared event with no emit site
for its entire existence — advertised to the model, unable to fire. This intercepts it and
reports the LED byte on a channel; mod.rs turns that into the event.
2. The crate panics on anything else. UsbHidKeyboardHandler::handle_urb ends its
control arm with unimplemented!("hid request {:?}", setup), and handle_urb is called from
a tokio worker inside the USB/IP session task. A host issuing GET_PROTOCOL, GET_IDLE, a
GET_REPORT, or the very SET_REPORT above would take the connection down with a panic
rather than get an answer — and SET_REPORT is not exotic: pressing Caps Lock sends one.
Unknown control requests are answered empty here, because returning an error aborts the
USB/IP session for the whole device and a host probing an optional request must not
disconnect the keyboard.
Structs§
- LedState
- The LED byte a host writes with
SET_REPORT, decoded (HID Usage Tables, LED page). - NetGet
Keyboard Handler - A virtual USB HID keyboard that also reports LED changes.