libusb-1.0 enters beta

I’ve been making good progress on libusb-1.0, which has now entered beta. Features over libusb-0.1 include:

  1. Asynchronous transfer capabilities (in addition to the synchronous style presented by v0.1)
  2. Support for transfers to isochronous endpoints
  3. Significantly faster bulk transfer performance for large transfers (several kilobytes or more)
  4. Detailed API documentation
  5. Power saving: on systems running recent Linux kernels, libusb-1.0 does not wake up all the USB devices plugged into the system during device enumeration
  6. Greatly reduced CPU usage while waiting for results of bulk/interrupt transfers (libusb-0.1 was waking up every 1ms)
  7. Thread safety

Backwards compatibility

As noted on the homepage, libusb-1.0 is entirely incompatible with libusb-0.1. However, it is designed to install in parallel, in the same way that you can have GTK+ 1.2 and GTK+ 2.x installed on the same system and in use at the same time.

I have also produced a compatibility layer which replaces libusb-0.1. libusb-compat-0.1 looks and smells exactly the same as libusb-0.1 (same library name, API, header file, etc) but internally it just converts libusb-0.1 calls to libusb-1.0.

This means that existing libusb-0.1 applications can take advantage of some of the new libusb-1.0 hotness mentioned above: improved bulk I/O performance, decreased CPU usage, power saving. These improvements appear without any modification to the original application, provided that the user has uninstalled libusb-0.1, and installed libusb-1.0 plus libusb-compat-0.1.


I’m hoping this release will result in:

  • More testing and adoption
  • API review and feedback
  • Ports to other operating systems. Only Linux is supported at the moment, but the library is structured internally for other ports to be written, and the internal API is documented in the source.

Further API changes may happen as a result of the above. This is not a finished product.

Source download

6 thoughts on “libusb-1.0 enters beta

  1. davidz

    Suppose I write a program that uses libraries libfoo and libbar. Suppose both libfoo and libbar wants to use libuse-1.0. What happens when libbar is unloaded and it calls libusb_exit()? This is a theoretical example; for example Nautilus and the gio/gvfs stack loads a bunch of plug-ins. And more than one plug-in might want to use libusb (for example different volume monitors; one for handling gphoto2 usb cameras, one for MTP usb devices).

    Typically libraries provides a context object (e.g. LibUsbContext *libusb_init() or similar) and use this throughout the API. Under some circumstances you can get away with this. But since you have things like libusb_set_debug() it doesn’t look like you can get away with it; this call would affect all users of libusb in the process space; which (typically) is not desired (even though it’s probably not a big deal since it’s just debugging.. just trying to make a point).

    Either way, it would probably make sense to at least document if your library is usable in such situations. Ideally it would be.

  2. Daniel Drake Post author

    Hi David, thanks for the feedback.

    Sounds like a sensible change to make. It should not have too much impact on the API: the session context could be stored inside the devices and handles and automatically inferred internally, so only a few function interfaces would need modifications. For convenience the user could also pass a NULL context, which would indicate the first initialized context, or something like that. I’ll think more about the details then raise it on the mailing list.

    For reference, could you give an example of an existing library that does this well?

  3. Jeff

    Hi Daniel,

    First off, thanks for taking up this project! A fresh start seems sorely needed.

    I am brand new to USB development, so I’ve been trying to figure out the best way to start playing with it, and libusb seemed like a good start (as opposed to kernel tinkering).

    Unfortunately with libusb-0.1, documentation and examples are very, VERY weak. While I understand that writing a device driver is going to be device-specific, it simply doesn’t cut it for an API to not even explain its function parameters. I found it fairly frustrating trying to find any useful information, and this coming from a young (read Internet savvy), professional engineer and general code hacker.

    By contrast, your documentation ( looks fantastic so far! Couple that with some great example code (maybe there are and I haven’t found them yet?), and your adoption rate will be huge.

    I have a couple ideas for possible example code (maybe they’re not feasible – as I said, I’m just starting with this stuff):

    – A “debug console”, intended for toying with USB devices, enumerating the bus and allowing you to select a device to connect to, trying to read/write it’s endpoints, etc.

    – An example using a device that everybody is likely to have available, such as a mouse (HID) or USB thumb drive. It wouldn’t necessarily have to properly operate the device, but just perform some simple probing to show how to use the libusb-1.0 library.

    I’d be willing to help in development of these examples, but I admit my C skills are so-so and my time limited.

    Thanks again!

  4. Pingback: dsd’s weblog » Blog Archive » libusb-0.9.1 released

Comments are closed.