Blame README

Packit 51230c
libusb-compat-0.1
Packit 51230c
=================
Packit 51230c
Packit 51230c
A compatibility layer allowing applications written for libusb-0.1 to work
Packit 51230c
with libusb-1.0. libusb-compat-0.1 attempts to look, feel, smell and walk
Packit 51230c
like libusb-0.1.
Packit 51230c
Packit 51230c
Do not attempt to install libusb-0.1 and libusb-compat-0.1 on the same system.
Packit 51230c
Packit 51230c
Known quirks/differences from libusb-0.1:
Packit 51230c
 1. usb_resetep(), a previously deprecated function, is implemented as
Packit 51230c
    equivalent to calling usb_clear_halt().
Packit 51230c
 2. libusb-0.1 allowed you to open a device which you did not have permission
Packit 51230c
    to do anything useful with (all I/O requests would immediately fail).
Packit 51230c
    libusb-compat-0.1 does not allow you to open such devices. You can still
Packit 51230c
    read descriptor info without opening a device.
Packit 51230c
 3. usb_device's "num_children" attribute is hardcoded to 0, and "children"
Packit 51230c
    is hardcoded to NULL. Do you need this information in your software? Let
Packit 51230c
    us know on the mailing list, and we'll add it.
Packit 51230c
 4. Some libusb-0.1 users may have implemented I/O cancellation by running
Packit 51230c
    transfers in their own threads and simply killing the thread when they
Packit 51230c
    don't want to do the transfer any more. This is bad programming practice
Packit 51230c
    for obvious reasons, and this lack of functionality was one of the primary
Packit 51230c
    drivers for libusb-1.0 development. With libusb-1.0 or libusb-compat-0.1
Packit 51230c
    backed by libusb-1.0, forcefully killing threads in this way is likely
Packit 51230c
    to cause all libusb I/O to halt. Instead, port your application to use
Packit 51230c
    libusb-1.0's asynchronous transfer API, which supports transfer
Packit 51230c
    cancellation.
Packit 51230c
 5. Error codes returned on certain events may not exactly match the error
Packit 51230c
    codes returned by libusb-0.1. Patches accepted to bring us closer to the
Packit 51230c
    behaviour of libusb-0.1 on Linux.
Packit 51230c
 6. The internal structure of usb_dev_handle is different from libusb-0.1. Of
Packit 51230c
    course, since this is a purely internal structure, that shouldn't cause
Packit 51230c
    any problems. In reality, some libusb-0.1 users make assumptions about what
Packit 51230c
    is inside (bad programming practice) and those assumptions are no longer
Packit 51230c
    true, resulting in broken software.
Packit 51230c
Packit 51230c
libusb homepage:
Packit 51230c
http://libusb.org/
Packit 51230c
Packit 51230c
Use the mailing list for questions, comments, etc:
Packit 51230c
https://sourceforge.net/mailarchive/forum.php?forum_name=libusb-devel
Packit 51230c
Packit 51230c
- Peter Stuge <peter@stuge.se>
Packit 51230c
(use the mailing list rather than mailing developers directly)
Packit 51230c