This site is a joint effort with David
Merrill and Olaf Matthes.
as part of our [hidio] project.
As part of the USB specification, devices report the polling interval to the host computer using the `bInterval' value. For `low-speed' and `full-speed' devices, this value is interpreted as milliseconds. For `high-speed' devices, new in USB 2.0, this value is interpreted as 2^(bInterval-1) units, where the units are defined as 125 microseconds. The operating system is then supposed to poll that device for new data at a rate set by that interval. While the vast majority of HIDs run in `high-speed', some older USB microcontrollers only support `low-speed' mode. This could dramatically affect the performance of an instrument built using such a microcontroller.
Most USB mice have a bInterval of 10ms. While it is possible to get input reports more frequently, we believe that it would not be perceptable nor would it affect performance in a substantial way, except in cases where there is a direct haptic feedback loop. In certain specialized circumstances, such as accurately measuring human response times or implementing a PID loop, it could be useful to set the interval to a smaller time. We are currently exploring whether it is effective to set `bInterval' to very low values when using output reports. This could allow the processing of haptic feedback to happen on the host computer rather than on the embedded microcontroller in haptic HIDs. The USB bus or device hardware does not enforce the `bInterval' polling time, instead it seems to be a suggested value. For example, with the Linux kernel, it is possible to override bInterval and poll devices faster, up to every millisecond (see HOWTO: Increase USB Mouse Polling Interval. Since the underlying operating system layer is based on polling, we decided that there was little advantage to implementing more complicated methods of getting the data from the operating system and use a fixed poll time of 5ms. This was demonstrated by some testing that is discussed later.
Many modern gamepads have an input element known as a `hatswitch' or `point-of-view hat'. In USB HID way of representing a hatswitch is to have each direction be a number, such as: 0=up, 1=right, 2=down, 3=left. If the hatswitch has more directions, then the sequence will contain more numbers: 0=up, 1=up-right, 2=right, 3=right-down, 4=left-down, etc. Even though all other USB HID elements have only positive values, a hatswitch in its null state is represented with a value of -1. In the Linux input scheme, hatswitches are represented as as absolute axes. For instance, a hatswitch that can be pushed left or right, with an `at rest' position in the center will register: left: -1, center: 0, right: 1. Since hatswitches physically behave like axes, it makes sense to treat them as axes. On the other platforms, we converted the USB HID values to this representation using the USB HID button values as directions on a compass, with the `Logical Max' value defining how many points on the compass there are. This is then converted to cartesian values, using only -1, 0 and 1 as values.
While this event scheme makes the handling the events much easier to understand, it could make it more difficult to use very specialized devices like simulation controllers, for example, `golf club', `rowing machine', `magic carpet', or `sailing' simulators as specified by USB HID. We have no access to such devices, so we have not tested them, and therefore cannot accurately assess the problems involved. From our experience, these devices are not common. We welcome feedback from those who do have access to such devices.
$Id: usbhid.html,v 1.5 2007-06-16 16:15:22 hans Exp $