Home

Welcome to the libusb-compat-0.1 wiki!

There are several libusb-0.1 API implementations:

libusb-0.1 is the original libusb implementation and it is no longer supported. Take note Debian and Ubuntu still ship with libusb-0.1 and not libusb-compat. You have to go to them for support if you encountered issues.

libusb-compat-0.1 is a compatibility library which provides the libusb-0.1 API. New projects should try to use libusb-1.0 API and not libusb-0.1 API. But if libusb-0.1 API needs to be used, then you can use libusb-compat-0.1. Please take note of the known quirks/differences from the legacy libusb-0.1.

libusb-win32 is a Windows-only implementation of the libusb-0.1 API plus some Windows only extension APIs. It is in a bug-fix-only maintenance mode. New projects are strongly recommended to use libusb Windows backend and not libusb-win32.

FreeBSD ships their own implementation of the libusb-0.1 API (along with libusb-1.0 API) as part of their system libraries.

Known quirks/differences from libusb-0.1:

1. usb_resetep(), a previously deprecated function, is implemented as equivalent to calling usb_clear_halt().
2. libusb-0.1 allowed you to open a device which you did not have permission to do anything useful with (all I/O requests would immediately fail). libusb-compat-0.1 does not allow you to open such devices. You can still read descriptor info without opening a device.
3. usb_device's "num_children" attribute is hardcoded to 0, and "children" is hardcoded to NULL. Do you need this information in your software? Let us know on the mailing list, and we'll add it.
4. Some libusb-0.1 users may have implemented I/O cancellation by running transfers in their own threads and simply killing the thread when they don't want to do the transfer any more. This is bad programming practice for obvious reasons, and this lack of functionality was one of the primary drivers for libusb-1.0 development. With libusb-1.0 or libusb-compat-0.1 backed by libusb-1.0, forcefully killing threads in this way is likely to cause all libusb I/O to halt. Instead, port your application to use libusb-1.0's asynchronous transfer API, which supports transfer cancellation.
5. Error codes returned on certain events may not exactly match the error codes returned by libusb-0.1. Patches accepted to bring us closer to the behaviour of libusb-0.1 on Linux.
6. The internal structure of usb_dev_handle is different from libusb-0.1. Of course, since this is a purely internal structure, that shouldn't cause any problems. In reality, some libusb-0.1 users make assumptions about what is inside (bad programming practice) and those assumptions are no longer true, resulting in broken software.
7. libusb-1.0 and libusb-0.1-compat may be slower in listing the devices under Linux compared to libusb-0.1. Please refer to ticket https://github.com/libusb/libusb/issues/237. libusb 0.1 finds devices through devtmpfs by scanning /dev/bus/usb. These device nodes are likely to show up quite soon after the device is enumerated. libusb 1.0 listens for uevents from the kernel through a netlink socket. There are quite a few uevents that the kernel sends out while setting up a new device, only one of which tells libusb that a new device has arrived. This also happens in a dedicated thread, so there may be scheduling latencies at play. One potential workaround is to build libusb with netlink and not udev.