Я новичок в libusb и USB в целом, поэтому я не уверен, что это правильно, но после просмотра вывода USB-сниффера, такого как USBlyzer и подправляя несколько вещей, я придумываю следующие пункты протокола:
usb_claim_interface
Когда я запросил интерфейс (usb_claim_interface
) и затем отменил свое приложение, я был в неработоспособном состоянии при последующих запусках. Я пробовал различные сбросы (usb_reset
и usb_resetep
), но я все еще не мог получить правильное использование из usb_control_msg
.
SetReport / GetReport
USBlyzer
показал, что соответствующие пакеты, где Get Descriptor
, Select Configuration
, Set Report
и Get Report
. Get Descriptor
и Select Configuration
явно связаны с usb_get_descriptor
и usb_set_configuration
соответственно.
Некоторые Get Report
пакеты содержали Feature Id
, а другие Input Id
. Я смог сопоставить их с usb_control_msg
со следующими параметрами, ( libusb.c помог
я понял это):
requesttype = USB_ENDPOINT_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE
value = 0x01 (for GetReport)
index = id | (0x03 << 8) (for FeatureId)
Пакеты
Set Report
также используются Feature Id
, но Output Id
. Из рассмотрения деталей выяснилось, что Input Id
соответствует (0x01 << 8) и <code>Output Id соответствует (0x02 << 8). Таким образом, чтобы получить <code>Set Report, я позвонил usb_control_msg
с этими настроенными параметрами:
requesttype = USB_ENDPOINT_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE
value = 0x09 (for SetReport)
index = id | (0x03 << 8) (for FeatureId)
Возможно, это не самый правильный способ сделать все это, и я, безусловно, был бы признателен за более глубокое понимание того, что происходит с различными функциями API . Но это позволило моему хосту захватить все соответствующие данные с устройства.