Device classes¶
Ready-made, reusable USB device classes - each an Interface
or Function subclass built only on the public device API,
and each added the one way anything is added: dev.add(CLASS(...)), which returns the
class's data-plane handle. Only the user-facing entry points are shown; see
Device Classes for usage.
HID - Human Interface Device¶
The generic HID interface plus ready-made Report-descriptor builders.
hid
¶
HID (class 0x03) - generic device class (USB HID 1.11).
A generic HID function: hand it any Report descriptor and it presents a proper HID interface - keyboard, mouse, consumer control, or a vendor-defined raw device. It speaks the full HID 1.11 request set over EP0 (GET/SET_REPORT, GET/SET_IDLE, GET/SET_PROTOCOL) plus the required interrupt IN and an optional interrupt OUT for Output reports (HID 1.11 Sec.4.4, Sec.7.2, Appendix G).
Quick start::
from usbip.classes.device import hid
iface = hid.HID(hid.mouse_report_descriptor(),
subclass=hid.SUBCLASS_BOOT,
protocol=hid.PROTOCOL_MOUSE)
dev.add(iface)
iface.send_report(bytes([0, 5, 0, 0])) # buttons, dx, dy, wheel
Subclassing still works::
class Keyboard(hid.HID):
report_descriptor = hid.keyboard_report_descriptor()
HID
¶
HID(report_descriptor=None, *, subclass=None, protocol=None, in_ep=129, in_mps=64, in_interval=10, out_ep=None, out_mps=64, out_interval=10, country=0, bcd_hid=273, get_report=None, set_report=None, on_output=None)
Bases: Interface
A generic HID interface. Pass a report descriptor (or set the class attribute) and, optionally, callbacks for Get/Set_Report and Output reports.
Source code in usbip/classes/device/hid.py
extra_descriptors
¶
on_control
¶
Source code in usbip/classes/device/hid.py
on_out
¶
keyboard_report_descriptor
¶
Boot-protocol keyboard: 8-byte Input report (modifier bitmap, reserved byte, six key codes) + 1-byte Output report (Num/Caps/Scroll Lock + Compose/Kana LEDs).
Source code in usbip/classes/device/hid.py
mouse_report_descriptor
¶
Boot-compatible mouse: 4-byte report = [buttons, dx, dy, wheel].
Source code in usbip/classes/device/hid.py
consumer_report_descriptor
¶
Consumer control: 1-byte report, 8 media-key bits (play/next/prev/stop/ mute/vol+/vol-/eject).
Source code in usbip/classes/device/hid.py
vendor_report_descriptor
¶
A vendor-defined raw HID device: in_size-byte Input report + out_size-byte
Output report on a vendor usage page. Round-trips bytes via interrupt IN/OUT
and Get/Set_Report; no OS HID consumer claims it.
Source code in usbip/classes/device/hid.py
CDC-ACM - Virtual serial port¶
dev.add(CDCACM(...)) attaches a port and returns it; transmit with the port's write().
cdc_acm
¶
CDC-ACM (virtual serial port) - device class (Communications + Data interfaces).
The class implements the CDC protocol; the app supplies callbacks for the events it cares about (port opened/closed, line coding changed, bytes received) and uses the port's write() to transmit. Mirrors the C library's src/classes/device/cdc_acm.c - protocol handling lives here, not in the example. Built only on the public device API.
CDCACM
¶
Bases: Function
A CDC-ACM serial port: a two-interface function (Communications + Data) bound by a CDC Union functional descriptor. Mirrors the C cdc_acm function.
The pair must reach the host as ONE function or no COM port forms on Windows, so
the function is named either by the device-descriptor triple (when it is alone on
the device) or by an IAD (on a USBDevice.set_composite() device, where the
triple is pinned to EF/02/01). Linux pairs the interfaces from the Union
functional descriptor and needs neither.
dev.add(CDCACM(...)) returns the Data interface - the port you write to; the
callbacks receive that same object as port, and name labels it (iInterface /
IAD iFunction). Mirrors C cdc_acm_add(), which returns a cdc_port *.
Source code in usbip/classes/device/cdc_acm.py
comm
instance-attribute
¶
MSC - Mass storage (SCSI / Bulk-Only Transport)¶
The disk is backed by an application-supplied block store (see the FileStore in
examples/msc_device.py); the class itself does no filesystem access. Pass a list of
stores for a multi-LUN disk - one logical unit each, each its own drive on the host.
msc
¶
Mass Storage Class - device class: Bulk-Only Transport + SCSI (SBC/MMC).
The class is generic: it runs the BOT state machine (CBW -> data -> CSW) and a SCSI command set, delegating block I/O to a duck-typed store:
store.num_blocks -> int
store.block_size -> int
store.read(lba, count) -> bytes
store.write(lba, count, data) -> None
Hand it several stores and the interface carries several logical units - one
pair of bulk pipes, one command at a time, but a separate medium behind each LUN
(Linux gives every unit its own /dev/sd*, Windows its own drive letter). A store
may also carry medium, read_only, product or serial attributes, which
override for that unit alone what the interface was built with.
No store ships with the class - no filesystem access happens here; the
application supplies one (see examples/device/msc_device.py for FileStore, an
image-file backend). The app also supplies an on_command(text) callback for
human-readable logging. Per USB MSC BOT 1.0 and SCSI SPC/SBC.
MSC
¶
MSC(stores, *, read_only=False, medium=MEDIUM_DISK, ufi=False, on_command=None, vendor='USB-IP', product=None, revision='0001', serial='0123456789ABCDEF', name=None)
Bases: Interface
stores is one block store, or a list of them - one logical unit each.
medium is "disk" (the default), "cdrom" or "floppy", and with several
units it is the default a store can override with a medium attribute of
its own (as it can read_only, product and serial). ufi declares
the UFI command set (bInterfaceSubClass 0x04, SFF-8070i) instead of SCSI
transparent (0x06) - the subclass a real USB floppy drive reports, and
what makes Windows show the drive as a floppy rather than a removable
disk. It describes the interface, so it covers every unit. The transport
stays Bulk-Only either way; UFI-over-CBI is not offered. The UFI commands
themselves (FORMAT UNIT, READ/WRITE(12), VERIFY, SEEK, REZERO UNIT) are
answered whatever the subclass, as they are legal SCSI too.
Source code in usbip/classes/device/msc.py
Lun
¶
One logical unit: its store, how it presents itself, and its own sense data.
Each presentation attribute is taken from the store when it carries one and from the interface otherwise, so a device can mix media - a disk beside its install CD - without a second interface. Sense is per unit, as SCSI requires: a failure on one LUN must not answer another LUN's REQUEST SENSE.
Source code in usbip/classes/device/msc.py
MTP - Media Transfer Protocol¶
dev.add(MTP(...)) attaches one or more storages, each an application-supplied backend (see the
FilesystemStore in examples/mtp_device.py).
mtp
¶
USB MTP (Media Transfer Protocol) v1.1 - device class.
Exports a host directory tree as an MTP storage: Windows Explorer, libmtp (mtp-detect/mtp-files) and gphoto2 can browse it, download files, and - unless read-only - upload and delete. MTP is layered on PTP: it rides the Still Image interface (class 0x06 / sub 0x01 / proto 0x01) and a bulk container protocol (command -> optional data -> response), with an interrupt IN endpoint for events. Everything is bulk/interrupt, so no USB/IP wire support is needed.
With winusb=True (the default) the function advertises the Microsoft OS "MTP"
Compatible ID, which makes Windows bind its MTP/WPD driver with no INF.
Mirrors the C classes/device/mtp.c. The MTP protocol and object model live here;
the actual storage is a pluggable backend so no filesystem access happens in
this class - dev.add(MTP(store)) takes the application's own store, e.g. the
FilesystemStore in examples/device/mtp_device.py.
MTP
¶
MTP(store, *, name='USBIP MTP', manufacturer='USB over IP', serial=None, winusb=True, on_event=None)
Bases: Interface
An MTP interface backed by store - an application-supplied storage backend
(the example's FilesystemStore) or an already-built :class:MtpStorage. With
winusb=True (default) the function advertises the Microsoft OS "MTP" Compatible ID
so Windows binds its MTP driver automatically.
Source code in usbip/classes/device/mtp.py
storage
instance-attribute
¶
serial
instance-attribute
¶
adjust_for_speed
¶
on_out
¶
Source code in usbip/classes/device/mtp.py
UAC - USB Audio Class 1.0¶
dev.add(UAC(...)) attaches a speaker + microphone audio interface.
uac
¶
USB Audio Class 1.0 (UAC1) - device class: speaker + microphone.
Mirrors the C classes/device/uac.c. Presents an AudioControl interface (a USB->Speaker playback chain and a Microphone->USB capture chain, each with a master mute+volume Feature Unit) plus two AudioStreaming interfaces: a stereo speaker over an isochronous OUT endpoint and a mono microphone over an isochronous IN endpoint, both 48 kHz / 16-bit PCM. The microphone streams a built-in 440 Hz synthetic tone (or app-supplied frames); the speaker is a sink that meters the level and hands the PCM to the app.
Descriptor layout follows the UAC1 spec and the kernel UAC1 gadget
(drivers/usb/gadget/function/f_uac1.c). Use dev.add(UAC(...)).
UAC
¶
Bases: Function
A UAC1 audio device: AudioControl + AudioStreaming (out/in) interfaces, bound by the AudioControl interface's collection - no IAD, no device triple (UAC1 predates the IAD). Mirrors the C uac function.
dev.add(UAC(...)) returns the AudioControl interface, with .speaker /
.microphone attached for convenience.
Source code in usbip/classes/device/uac.py
UVC - USB Video Class (webcam)¶
dev.add(UVC(...)) attaches a camera (YUYV and/or MJPEG).
uvc
¶
USB Video Class (webcam) - device class: isochronous streaming.
Mirrors the C classes/device/uvc.c. Presents a VideoControl + VideoStreaming
interface pair (grouped by an IAD), advertising YUY2 and/or MJPEG at one
resolution, runs Probe/Commit negotiation, and streams UVC payloads over an
isochronous IN endpoint. The frame source is the built-in animated color-bar
generator unless a source callback is supplied.
Descriptor layout follows the kernel UVC gadget (drivers/usb/gadget/legacy/
webcam.c) and uapi/linux/usb/video.h. Use dev.add(UVC(...)).
UVC
¶
Bases: Function
A UVC camera: a composite function (VideoControl + VideoStreaming) grouped by an Interface Association Descriptor. The IAD and the 0xEF/0x02/0x01 device triple are emitted by the Function machinery (opt-in), not hand-rolled by the interfaces.
dev.add(UVC(...)) returns the VideoStreaming interface (the streaming endpoint
owner).
Source code in usbip/classes/device/uvc.py
DFU - Device Firmware Upgrade¶
dev.add(DFU(...)) attaches a DFU target table.
dfu
¶
USB DFU (Device Firmware Upgrade), DFU 1.1 - device class.
Presents a DFU-mode device (bInterfaceProtocol 0x02, already in dfuIDLE) that dfu-util can UPLOAD from and DOWNLOAD to. One alternate setting per target. The class makes NO assumption about what backs a target - a file, a flash part, whatever: each target is an application-supplied object exposing a small linear-byte-store protocol (see examples/device/dfu_device.py for a file backend). DFU is entirely EP0 control transfers, so this needs no USB/IP transport support.
A target object must provide
name str, the iInterface label (dfu-util -l)
i_string int, the string index (set for you when added)
length int, bytes currently stored (read by the class)
write(off, data) store bytes at byte offset off (raise IndexError if full)
read(off, size) -> bytes up to size bytes at off (b"" at/after the end)
begin_download() a fresh download is starting (discard the old image)
finish_download() the download finished (commit/flush)
With winusb=True (the default) the function advertises WinUSB, so Windows
auto-binds the WinUSB driver and dfu-util works without Zadig.
Mirrors the C classes/device/dfu.c. Use dev.add(DFU(targets=[...])).
DFU
¶
DFU(targets, transfer_size=1024, attributes=ATTR_DEFAULT, detach_timeout=1000, winusb=True, on_event=None)
Bases: Interface
A DFU interface, one alternate setting per target. targets is a list of
app-supplied target objects (see the module docstring for the protocol; the
example provides a file backend). With winusb=True (default) the function
advertises WinUSB so dfu-util works on Windows without Zadig.
Source code in usbip/classes/device/dfu.py
descriptor_block
¶
Source code in usbip/classes/device/dfu.py
set_alt
¶
on_control
¶
Source code in usbip/classes/device/dfu.py
DFUError
¶
Bases: Exception
Raised by a target's write()/read() to report a specific DFU bStatus code: the class catches it, enters dfuERROR, and returns that status on GETSTATUS. A plain IndexError from write() is the simple case and maps to errADDRESS.
Source code in usbip/classes/device/dfu.py
Bluetooth - HCI transport¶
dev.add(Bluetooth(...)) attaches a USB Bluetooth controller transport.
bluetooth
¶
USB Bluetooth (class 0xE0/0x01/0x01) - device-side HCI transport.
Mirrors the C classes/device/bluetooth.c. This is a minimal transport, nothing more: it ferries HCI commands (EP0 class control OUT), HCI events (interrupt IN) and ACL data (bulk OUT/IN) between the USB host and a controller the application supplies. No HCI logic lives here - the class never inspects a command or synthesizes an event.
This follows the Bluetooth USB Transport Layer (Core spec Vol 4 Part B): - device class 0xE0 / subclass 0x01 (RF) / protocol 0x01 (Bluetooth) - interface 0: interrupt-IN (events) + bulk-OUT (ACL out) + bulk-IN (ACL in) - interface 1: SCO isochronous (6 alt settings) - descriptor-only / no-op
Use dev.add(Bluetooth(on_command=..., on_acl=...)).
Bluetooth
¶
Bases: Function
A Bluetooth dongle (HCI transport): the HCI interface plus (for Windows' bthusb) the SCO isochronous interface. The two interfaces are bound by the device class 0xE0/0x01/0x01, not an IAD. Mirrors the C bluetooth function.
dev.add(Bluetooth(...)) sets the device class to 0xE0/0x01/0x01 and returns the
BluetoothInterface: call send_event/send_acl to push toward the host, and
wire on_command/on_acl to your controller.
Source code in usbip/classes/device/bluetooth.py
BluetoothInterface
¶
Bases: Interface
Interface 0 - the HCI/ACL transport.
The host sends HCI commands on EP0 (class control OUT) and ACL on the bulk
OUT endpoint; the controller sends HCI events on the interrupt IN and ACL on
the bulk IN. Wire on_command/on_acl to a controller and call
send_event/send_acl to push toward the host.
Source code in usbip/classes/device/bluetooth.py
event_in
class-attribute
instance-attribute
¶
on_control
¶
An HCI command arrives as a class control OUT (bmRequestType 0x20).
on_out
¶
ACL OUT. The host may split one PDU across 64-byte URBs, so reassemble by the 2-byte little-endian data length in the ACL header (offset 2).
Source code in usbip/classes/device/bluetooth.py
on_reset
¶
A host (re)attached - drop any half-assembled ACL so it can't bleed into the new session (the endpoint queues are flushed by the core).