diff options
| author | Yavor Goulishev <yavor@google.com> | 2011-05-23 11:58:06 -0700 |
|---|---|---|
| committer | Yavor Goulishev <yavor@google.com> | 2011-05-23 11:58:06 -0700 |
| commit | e9a683104ef3f40d38459c0ca62a2d46f20b0714 (patch) | |
| tree | 1ef8522d89d3e24c69ed6253e657211a0faa6564 /README | |
| parent | 88d2245b9a11a11134b39d9d0e54b5c2dba8aeef (diff) | |
| download | libusb-compat-e9a683104ef3f40d38459c0ca62a2d46f20b0714.tar.gz | |
Moving the libusb-compat source from jumper to external.android-sdk-tools_r12android-sdk-adt_r12
Change-Id: Icd5631b38c4b1a16ae0f715d32c1e1d4ba82c435
Diffstat (limited to 'README')
| -rw-r--r-- | README | 41 |
1 files changed, 41 insertions, 0 deletions
@@ -0,0 +1,41 @@ +libusb-compat-0.1 +================= + +A compatibility layer allowing applications written for libusb-0.1 to work +with libusb-1.0. libusb-compat-0.1 attempts to look, feel, smell and walk +like libusb-0.1. + +Do not attempt to install libusb-0.1 and libusb-compat-0.1 on the same system. + +Known quirks/differences from libusb-0.1: + 1. usb_resetep(), a previously deprecated function, is implemented as + equivalent to calling usb_clear_halt(). + 2. libusb-0.1 allowed you to open a device which you did not have permission + to do anything useful with (all I/O requests would immediately fail). + libusb-compat-0.1 does not allow you to open such devices. You can still + read descriptor info without opening a device. + 3. usb_device's "num_children" attribute is hardcoded to 0, and "children" + is hardcoded to NULL. Do you need this information in your software? Let + us know on the mailing list, and we'll add it. + 4. Some libusb-0.1 users may have implemented I/O cancellation by running + transfers in their own threads and simply killing the thread when they + don't want to do the transfer any more. This is bad programming practice + for obvious reasons, and this lack of functionality was one of the primary + drivers for libusb-1.0 development. With libusb-1.0 or libusb-compat-0.1 + backed by libusb-1.0, forcefully killing threads in this way is likely + to cause all libusb I/O to halt. Instead, port your application to use + libusb-1.0's asynchronous transfer API, which supports transfer + cancellation. + 5. Error codes returned on certain events may not exactly match the error + codes returned by libusb-0.1. Patches accepted to bring us closer to the + behaviour of libusb-0.1 on Linux. + +libusb homepage: +http://libusb.sourceforge.net + +Use the mailing list for questions, comments, etc: +https://sourceforge.net/mailarchive/forum.php?forum_name=libusb-devel + +- Daniel Drake <dsd@gentoo.org> +(use the mailing list rather than mailing developers directly) + |