Changes between Version 10 and Version 11 of FAQ

Timestamp:

01/27/11 17:49:57 (2 years ago)

Author:

stuge

Comment:

--

FAQ

@@ -16 +16 @@
 It is important to remember that USB devices are never driverless, rather quite the opposite. Multiple kernel drivers are always involved: USB stack with USB core, USB hub drivers, maybe a composite class driver, and then ultimately a class- or device-specific driver. This is true for every operating system, and also when using libusb.
 
-On Windows it is trivial to program HID class devices directly, because the HID class-specific driver in Windows exposes a simple file-like API. For some applications this can be sufficient, but it is a tradeoff which means that some features of USB can not be used by the device. For instance, the HID class only allows interrupt endpoints and the format of communication over the endpoints is specified in the HID class as reports, so all data must be encapsulated.
+On Windows it is trivial to program HID class devices directly, because the HID class-specific driver in Windows exposes a simple file-like API. For some applications this can be sufficient, but it is a tradeoff which means that some features of USB can not be used by the device. For instance, the HID class only allows interrupt endpoints, and the format of communication over the endpoints is specified in the HID class as reports, so all data must be encapsulated.
 
 Besides the USB protocol restrictions, using the HID class is much more inconvenient on systems other than Windows. On other systems, the HID class driver does not offer a similar simple generic API so it is not accessible from libusb. On Linux however, libusb does provide the ability temporarily replace the HID driver (which might require setting up udev rules if running as non root), so that generic access can be achieved in a transparent manner.