forked from hjelmn/libusb-compat-0.1
-
Notifications
You must be signed in to change notification settings - Fork 40
/
README
50 lines (43 loc) · 2.43 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
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.
6. The internal structure of usb_dev_handle is different from libusb-0.1. Of
course, since this is a purely internal structure, that shouldn't cause
any problems. In reality, some libusb-0.1 users make assumptions about what
is inside (bad programming practice) and those assumptions are no longer
true, resulting in broken software.
libusb homepage:
http://libusb.info/
Use the mailing list for questions, comments, etc:
http://mailing-list.libusb.info
- Hans de Goede <[email protected]>
- Xiaofan Chen <[email protected]>
- Ludovic Rousseau <[email protected]>
- Nathan Hjelm <[email protected]>
- Chris Dickens <[email protected]>
(Please use the mailing list rather than mailing developers directly)