wiki:libusb-1.0
Last modified 3 years ago Last modified on 06/03/12 21:26:26

libusb-1.0

libusb-1.0 is an almost-rewrite of the previous stable branch, libusb-0.1. It is a lightweight library that can be efficiently integrated into applications of any kind, with several new features.

libusb-1.0 development is being lead by Peter Stuge. Contributions encouraged!

Status

The library is complete. New releases will primarily be for bug-fixes. Internal cleanups/improvements and new features (API additions, but not modifications) will be implemented in libusb-1.1?.

Download

Documentation

doxygen comments are present in the source and the generated HTML documentation can be browsed online.

Feedback is appreciated.

Development

Development happens in a git repository: git://git.libusb.org/libusb.git (gitweb interface)

For those not familiar with git, here are the git commands you can use retrieve and compile libusb-1.0:

git clone git://git.libusb.org/libusb.git ; retrieve development branch (this only needs to be done once)
git pull                                  ; keep in sync with the remote tree

On Windows, if you don't want to use git on the command line, you can use TortoiseGit to access and keep in sync with the git repository.
Note that before you can install TortoiseGit you need to install MSysGit and make sure that, during the installation of MSysGit, when prompted to adjust the PATH environment, you select "Run Git from the Windows Command Prompt" (2nd option). Also, in the general settings of TortoiseGit, the MSysGit path must point to the MSysGit bin directory (eg: C:Program Files (x86)Gitin").

Contributions encouraged - please either email patches to the libusb-devel mailing list, or publish your git tree somewhere and email a pull request to the mailing list.

Portability

libusb-1.0 includes a platform abstraction layer allowing for cross-platform compatibility. Linux, Darwin (Mac OS X), Windows, OpenBSD and NetBSD are supported in the latest release.

FreeBSD 8 and above include a FreeBSD-specific reimplementation of the libusb-1.0 API, so your applications will probably work there too. The source code for this library can be found here.

If you are interested in porting to other platforms, the PORTING file tells you where to start. We are more than happy to help out here, please write to the mailing list with your questions and feedback.

Backwards compatibility

libusb-1.0 is not backwards compatible with libusb-0.1 - all function names are different, etc. However, libusb-1.0 is designed to be happily installable alongside libusb-0.1 (even in the default configuration) so the lack of backwards compatibility is not really a problem - users can have both libusb versions present on the same system without conflict.

That said, there is a libusb-compat-0.1 compatibility layer. This is a "wrapper" which converts libusb-0.1 function calls to their 1.0 equivalents. For more info, see libusb-compat-0.1.

Mailing list

The libusb-devel mailing list exists for both users of the library, plus developers interested in contributing to the library itself.


Comparison to other USB libraries

libusb-0.1

libusb-0.1 is the very popular predecessor of this project.

Advantages compared to libusb-1.0

  • Portable to a larger number of operating systems
  • Widespread adoption

Disadvantages compared to libusb-1.0

  • Does not provide isochronous endpoint I/O
  • Does not provide asynchronous I/O
  • Not being developed further

OpenUSB

OpenUSB is a fork of a never-released development branch of libusb, confusingly also named libusb-1.0.

Advantages compared to libusb-1.0

  • OpenUSB is working on Solaris whereas libusb-1.0 does not support Solaris now. Take note: both libusb-1.0 and OpenUSB have support of Linux and Mac OS X.
  • Support hotplug (using HAL and DBUS under Linux)

Disadvantages compared to libusb-1.0

  • Does not expose pollable file descriptors (and it would not be realistic to offer this functionality without a lot of rework)
  • Creates a number of internal threads for each process that uses it
  • In Daniel Drake's opinion, more complex than it needs to be (largely due to the complexity of threading)
  • No work is being done yet for Windows support