The protocol field in the interface descriptor as well determines it is a mouse or a keyboard. The sub-class value in the interface descriptor can be either 1 to indicate the device supports the boot protocol, or zero to indicate the device only supports the report protocol. The class value that identifies a HID device in the interface descriptors is 3. Keep in mind that interface descriptors cannot be manually requested, and must be acquired along with the configuration and endpoint descriptors. HID devices have class/sub-class values of both zeroes in their device descriptors, and instead have the class/sub-class values valid in their interface descriptors. For simplicity's sake, this article will discuss the boot protocol only, for now at least. The boot protocol is much simpler, and follows standard structures for mice and keyboards. Report protocols are based on the concept of "items," and their structures are defined in report descriptors. Reports generally have two types, depending on the protocol type. USB HID devices communicate using interrupt transfers, as they don't always transfer data, but when they do, they require very fast response from the software as well as the data transferred is normally small. This protocol of course depends on the standard USB framework. When the host sends a report to the device, it normally contains commands for configuring the device, such as setting LEDs on a keyboard, for example.
When a device sends a report to the host, it normally contains status change information, such as a keypress, mouse movement, etc. A report is a data structure that is sent to the host from the device, or can also be sent from the host to the device. USB HID devices are mainly based on two protocols: the report protocol and the boot protocol.
0 kommentar(er)
