Home | History | Annotate | only in /external/libusb-compat
Up to higher level directory
NameDateSize
aclocal.m420-Jun-201438.6K
AUTHORS20-Jun-201431
ChangeLog20-Jun-20148.7K
compile20-Jun-20143.6K
config.guess20-Jun-201444.4K
config.h20-Jun-20142.3K
config.h.in20-Jun-20141.9K
config.sub20-Jun-201432.9K
configure20-Jun-2014395K
configure.ac20-Jun-20141.9K
COPYING20-Jun-201425.8K
depcomp20-Jun-201417.4K
examples/20-Jun-2014
INSTALL20-Jun-20149.2K
install-sh20-Jun-201413.3K
libusb/20-Jun-2014
libusb-compat.xcodeproj/20-Jun-2014
libusb-config.in20-Jun-20141.3K
libusb.pc.in20-Jun-2014268
LICENSE20-Jun-20142.2K
ltmain.sh20-Jun-2014239.4K
m4/20-Jun-2014
MacConfigExternalDebug.xcconfig20-Jun-2014615
MacConfigExternalRelease.xcconfig20-Jun-2014854
Makefile.am20-Jun-2014462
Makefile.in20-Jun-201422.6K
missing20-Jun-201410.9K
NEWS20-Jun-2014725
README20-Jun-20142K

README

      1 libusb-compat-0.1
      2 =================
      3 
      4 A compatibility layer allowing applications written for libusb-0.1 to work
      5 with libusb-1.0. libusb-compat-0.1 attempts to look, feel, smell and walk
      6 like libusb-0.1.
      7 
      8 Do not attempt to install libusb-0.1 and libusb-compat-0.1 on the same system.
      9 
     10 Known quirks/differences from libusb-0.1:
     11  1. usb_resetep(), a previously deprecated function, is implemented as
     12     equivalent to calling usb_clear_halt().
     13  2. libusb-0.1 allowed you to open a device which you did not have permission
     14     to do anything useful with (all I/O requests would immediately fail).
     15     libusb-compat-0.1 does not allow you to open such devices. You can still
     16     read descriptor info without opening a device.
     17  3. usb_device's "num_children" attribute is hardcoded to 0, and "children"
     18     is hardcoded to NULL. Do you need this information in your software? Let
     19     us know on the mailing list, and we'll add it.
     20  4. Some libusb-0.1 users may have implemented I/O cancellation by running
     21     transfers in their own threads and simply killing the thread when they
     22     don't want to do the transfer any more. This is bad programming practice
     23     for obvious reasons, and this lack of functionality was one of the primary
     24     drivers for libusb-1.0 development. With libusb-1.0 or libusb-compat-0.1
     25     backed by libusb-1.0, forcefully killing threads in this way is likely
     26     to cause all libusb I/O to halt. Instead, port your application to use
     27     libusb-1.0's asynchronous transfer API, which supports transfer
     28     cancellation.
     29  5. Error codes returned on certain events may not exactly match the error
     30     codes returned by libusb-0.1. Patches accepted to bring us closer to the
     31     behaviour of libusb-0.1 on Linux.
     32 
     33 libusb homepage:
     34 http://libusb.sourceforge.net
     35 
     36 Use the mailing list for questions, comments, etc:
     37 https://sourceforge.net/mailarchive/forum.php?forum_name=libusb-devel
     38 
     39 - Daniel Drake <dsd (a] gentoo.org>
     40 (use the mailing list rather than mailing developers directly)
     41 
     42