PSAS might want to look at using the new libusb 1.0 for host-side
sensor software.  It looks fairly nice from the description, and I've
chatted with Daniel Drake about his improvements.  I think he would be
willing to work with us to add improvements or help if we get stuck.

Sarah Sharp

---------- Forwarded message ----------
From: Daniel Drake <>
Date: Sat, 13 Dec 2008 21:53:03 +0000
Subject: [Libusb-devel] libusb-1.0.0 released!

I'm happy to announce the release of libusb-1.0.0.
Source download link:

Although this release is an almost-rewrite, this new library hopes to
build on the success of the previous version, libusb-0.1, which was
developed by Johannes Erdfelt and others. libusb-0.1 has enjoyed
tremendous success (over 150,000 source downloads of the latest release)
and is used in many applications.

libusb-1.0 has has been in development and testing for several months.
Many thanks to everyone who has tested, sent feedback, and provided patches.

Features, improvements and notes:
- Support for isochronous endpoints. Iso endpoints are present on
  devices such as webcams, which libusb-0.1 was unable to work with.
- Asynchronous device I/O. You can now perform I/O to any endpoint type
  in asynchronous matter - allowing a single thread to be performing I/O
  with multiple endpoints on multiple devices. This is a very flexible
  interface which allows for many application designs that were not
  possible with libusb-0.1, as well as the possibility of cancelling
  transfers and so on.
- A simpler, synchronous interface is also offered, in the style of
- Lightweight. libusb is compact, with very few dependencies  (only libc
  and pthread). It does not create any internal library threads and is
  designed with efficiency in mind.
- Thread safety: libusb-1.0 is thread safe. You can operate it from
  multiple threads. Certain well-documented considerations apply in the
  more advanced scenarios.
- Main loop integration. libusb's asynchronous I/O model fits nicely
  into applications that revolve around the idea of polling file
  descriptors in a main loop. It also works nicely with applications
  built around other models.
- Power saving. libusb-0.1 wakes up all of the suspended USB devices
  attached to the system every time you start an application based on
  libusb-0.1. On sufficiently modern Linux kernels, this no longer
  happens with libusb-1.0.
- Reduced CPU usage. libusb-0.1 polls active bulk transfers every
  millisecond, resulting in high CPU wakeups and utilisation. libusb-1.0
  relies on a wakeup mechanism, where the library does not become active
  unless events are happening. This also improves power usage, and the
  more precise wakeup times result in a performance improvement as high
  as 20% in some applications.
- Improved bulk performance. For transfers of more than 16kb, libusb-1.0
  allows the kernel to queue larger proportions of the requested
  transfer (often all of it) at the hardware level. This results in a
  substantial performance gain for applications that perform these large
- Documentation. libusb-1.0 features detailed API documentation at

Porting your application:
- libusb-1.0 is not backwards compatible with libusb-0.1 - *everything*
  in the API has a different name, and the library has a different name
- libusb-1.0 can be installed on the same system as libusb-0.1 without
  conflict. It has been designed in this way. It does not cause problems
  to have both installed. It is also no problem for multiple
  applications to be running, some using 0.1 and others using 1.0.
- A compatibility layer, libusb-compat-0.1, is offered as a replacement
  for libusb-0.1. It allows libusb-0.1 programs to use the libusb-1.0
  library despite the API incompatibilities (it is a wrapper). This is
  optional; you can alternatively stay with libusb-0.1, or you can have
  a system with no libusb-0.1 implementation at all. See
- Straightforward porting your application from libusb-0.1 to
  libusb-1.0's synchronous API is quite easy, as that aspect of the API
  is quite similar to the great work that it built upon.
- Porting your application to benefit from the asynchronous API requires
  more thought, because asynchronous design in any context is something
  that must be carried out carefully.

And some final caveats:
- Imperfections in the library are documented at
- libusb-0.1 was partially portable to non-Linux systems. So far, I have
  been unable to drum up any code from non-Linux OS developers, so
  libusb-1.0 is Linux only. I am still keen on working with other OS
  developers on this, please get in contact. There will be challenges,
  and we may need to make changes - I will help you, and we will figure
  it out.

Future plans:
- libusb-1.1 is planned to feature some internal improvements, hotplug
  device notifications, better materials for beginners (documentation
  and examples), and more! There will be no API changes, only additions.
- If we need to make API changes, then those will be deferred until
  libusb-2.0. There are currently no plans for that release.
- I won't be doing any more libusb-0.1 releases, unless some critical
  security issues turn up.

Questions, bug reports and constructive criticisms are welcome on this
mailing list
( Please do
not mail developers directly.



Changes since libusb-0.9.4 (the previous beta release):

Daniel Drake (5):
      SourceForge website upload system changed
      Improvements to multi-threaded I/O system
      Fix double free in descriptor parsing error path
      Linux: fix reading of active configuration
      v1.0.0 release

Mikhail Gusarov (1):
      EOL-whitespace fixes

SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at;208669438;13503038;i?
Libusb-devel mailing list

psas-avionics mailing list

Reply via email to