This look pretty nice!


On Sun, Dec 14, 2008 at 06:22:49PM -0800, Sarah A Sharp wrote:
> Greetings,
> 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 <>
> To:
> Date: Sat, 13 Dec 2008 21:53:03 +0000
> Subject: [Libusb-devel] libusb-1.0.0 released!
> Hi,
> I'm happy to announce the release of libusb-1.0.0.
> Homepage:
> 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
>   libusb-0.1.
> - 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
>   transfers.
> - 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
>   too.
> - 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.
> Thanks!
> Daniel
> ---
> 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
> _______________________________________________
> Libusb-devel mailing list
> _______________________________________________
> psas-avionics mailing list

Attachment: signature.asc
Description: Digital signature

psas-avionics mailing list

Reply via email to