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
