Last modified 4 years ago Last modified on 01/14/12 21:47:32

Frequently Asked Questions

  1. Can I run Linux libusb applications without root root privilege?
  2. Can libusb be used inside a USB device that runs Linux?
  3. Can I use libusb to open a file on a USB storage device?
  4. Can I create a "driverless" device using HID class?

Can I run Linux libusb applications without root root privilege?

Yes you can! Under Linux, the standard solution for this problem is to use udev rules. Here are some links to udev related websites.

  1. udev homepage [BROKEN]
  2. Debian's udev overview:
  3. Writing udev rules:
  4. Proper place to ask questions about udev rules:

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.


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, but you can find a limited example of how to read a data block through Mass Storage using libusb in the mass_storage test from the xusb.c sample of the the libusb-pbatard branch. You are however encouraged to study existing open source implementations to learn more about this, such as the minimal implementation form libpayload of the coreboot project, or you can simply mount the storage device if you just want to read the file.

Can I create a "driverless" device using HID class?

Yes, sortof, but the device will only be really easy to access on Microsoft Windows. On Linux you must detach the kernel driver, which libusb has an API for, but this API can require elevated system privileges depending on system configuration. On Mac OS X you must install a codeless kext kernel driver and then reboot, before you can communicate with the device.

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 possible 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 more inconvenient on systems other than Windows. On other systems, the HID class driver does not offer a similar 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.

If the broadest platform compatibility 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 3 generic USB drivers exist (WinUSB.sys from Microsoft, libusb0.sys from the libusb-win32 project, see #49, and libusbK.sys from the project of the same name) which can be used as-is, and the installation process can be automated 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 and transparently for devices and interfaces specifying Vendor Specific device class.

If you require direct communication with a HID class device we recommend using the library HIDAPI by Signal 11 Software, which is also cross-platform.