|Version 5 (modified by pbatard, 2 years ago) (diff)|
Frequently Asked Questions
There is a separate page for libwdi-specific FAQs.
- Can libusb be used inside a USB device that runs Linux?
- Can I use libusb to open a file on a USB storage device?
- Can I create a driverless device using HID class?
Can libusb be used inside a USB device that runs Linux?
No, libusb provides a API for writing software on the host. Of course, if the device also acts as a USB host then libusb could still be useful, but only for the host part of the device.
Can I use libusb to open a file on a USB storage device?
Yes, libusb can be used for low-level communication with USB Mass Storage Class devices. But in order to access a file on such a device you must first implement Mass Storage Class, SCSI and the particular filesystem used on the device, most commonly FAT32. No, we can not do this for you. Please study existing open source implementations to learn about this, one minimal implementation exists in libpayload from the coreboot project, or simply mount the storage device if you just want to read the file. For an example of how to read a data block through Mass Storage using libusb, you can also have a look at the mass_storage test from the xusb.c sample, in the examples/ directory from the libusb-pbatard branch.
Can I create a driverless device using HID class?
Yes, sortof, but the device will only be really easy to access on Microsoft Windows.
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 most features of USB can not be used by the device, since the HID class only allows interrupt endpoints and since the format of communication over the endpoints is specified in the HID class as reports.
Besides the USB protocol restrictions, using the HID class is much more inconvenient on systems other than Windows. For what is probably historical reasons, the generic file-like API exposed by the Windows HID class-specific driver is unique. On other systems, the HID class driver does not offer the same simple API.
If the broadest platform compatiblity is important (this may be why you look toward libusb in the first place) then a much more neutral alternative is to use the Vendor Specific device class (0xff). This requires that a kernel driver is installed on Windows, but two generic USB drivers exist (libusb0.sys from the libusb-win32 project, see #49, and WinUSB.sys from Microsoft) which can be used as-is, and the installation process can be automated completely using libwdi.
On the other systems supported by libusb there is no need for interaction with kernel drivers at all when using the Vendor Specific device class. Both Linux and Mac OS X come with a generic USB driver built-in, which libusb uses automatically.