Libusbx is released under version 2.1 of the GNU Lesser General Public License (LGPL).
You can, as long as you don't modify its source code.
If you modify the source, then you must make any changes you applied to libusbx public, and grant others the right to use these changes in their own applications, under the LGPL v2.1 license terms.
Please read the libusbx Troubleshooting page and use the mailing list for support.
You have to subscribe to the mailing list in order to post.
Yes you can! The standard solution is to use udev rules. Here are some links to udev related websites.
- udev homepage
- Debian's udev overview
- Writing udev rules
- Proper place to ask questions about udev rules
No. Libusbx only provides an API for writing software on the host. Of course, if the device also acts as a USB host then libusbx could still be useful, but only for the host part of the device.
Yes, libusbx 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.
Libusbx will not do this part for you, but you can find a limited example of how to read a data block through Mass Storage using libusbx in the mass_storage test from the xusb.c sample of the the libusbx distribution.
Absolutely, as long as the underlying OS supports USB 3.0 too.
What should I do if I find that my device works well when plugged on an USB 2.0 port but not on an USB 3.0 one?
With USB 3.0 being fairly new, some systems are still catching up.
For instance, USB 3.0 support for Windows 7 and earlier is very dependent on individual drivers (not provided by Microsoft), since only Windows 8 has an official USB 3.0 stack from Microsoft.
For Linux, the xHCI driver is also not as mature as the other host controller driver.
And for Mac OS X, xHCI support has only been introduced recently with Mac OS X Mountain Lion, so USB 3.0 support may not be that mature either.
Still we will try to help sort issues related to USB 3.0 usage if we can, but before you contact us, please make sure you test with the latest USB 3.0 drivers available from your xHCI provider on Windows, or on Linux, with the latest kernel, as the xHCI driver is constantly being updated there.
As opposed to libusb, libusbx does try to support USB HID devices where possible, as we understand there exists many generic USB HID devices out there one may want to have easy access to.
On Linux, you will need to detach the kernel HID driver in order to use libusbx to communicate with the device. But the libusbx API can do this for you, and if you have the relevant udev rule, you should be able to do that without reuring root privileges.
On Mac OS X. you must install a codeless kext kernel driver and then reboot before you can communicate with the device. This may change once a native HID backend is written for Mac OS X.
On Windows, the native Windows HID driver is supported by libusbx. There are some limitations with regards to accessing HID mice and keyboards, as they are system reserved, as well as getting a direct read of HID report descriptors, but apart from that, you should be able to access an HID device just like any other USB device.
If you want, you can also use the HIDAPI library, by Signal 11 Software, which is also cross-platform. It uses native HID API under Windows and Mac OS X and it can use libusbx/libusb or hidraw as the backend under Linux.
No. Windows RT is locked by Microsoft, which means that users cannot install the applications or library of their choice. Because of that Windows RT cannot be supported by libusbx.
No.
Since it's based on Linux, it should. But you find an issue on Android, you are welcome to contact the mailing list.
