Age | Commit message (Collapse) | Author | Files | Lines |
|
Fix the comment at the end of handle_iso_completion, we don't stop on urbs /
iso pkts with less data then requested, and this is a good thing since this
is a normal condition for iso transfers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Remove a useless check then set of status because:
1. The check is always true; and
2. The new value status gets set to never gets used
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
During testing of my usbredir code I hit a scenario where my libusb app
was seeing EXDEV as status in the transfer's iso_packet_desc
This happened because we don't translate linux negative errno errors
stored in iso pkts status to libusb transfer status codes at all! So this
patch adds translation for this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
During testing of my usbredir code I hit a case where EOVERFLOW was not handled
in handle_control_completion. Instead of just fixing this one case I've audited
(and fixed where necessary) all handle_foo_completion functions to know about
all errors documented in linux/Documentation/usb/error-codes.txt.
Note that for handle_iso_completion this patch actually removes the handling
of some codes, since these can never occur on an iso urb (they can only
occur on the iso packets included in the urb, see the next patch in this
series). Also in case an unknown status is encountered on an iso urb, this
patch actually sets the urb's status to ERROR, rather then leaving it at
completed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
As stated in the documentation for libusb_cancel_transfer,
LIBUSB_ERROR_NOT_FOUND is an expected return value for
libusb_cancel_transfer (under certain circumstances) printing
an error each time this happens therefor is undesirable.
More so because under Linux IOCTL_USBFS_DISCARDURB sets errno
to EINVAL when the kernel could not find the urb in the kernels
urbs in flight list. Which means that the urb has already completed
at the host controller level, but it has not necessarily already
been reaped. IOW under Linux libusb_cancel_transfer may yield a
result of LIBUSB_ERROR_NOT_FOUND *before* the transfer's callback
has been called! So there is no way for an application to avoid
calling libusb_cancel_transfer on already completed transfers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
If we fail to cancel the last urb of a multi-urb transfer because it
has already completed (errno == EINVAL on DISCARD_URB), then the entire
transfer has already completed, so returning NOT_FOUND is consistent with what
the documentation for libusb_cancel_transfer says.
But if we've successfully cancelled the last urb, and then another urb
fails with errno == EINVAL, this means that we've still cancelled the
transfer, as it has only *partially* completed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Some protocols which use USB require an extra zero length data packet
to signal end-of-transfer on bulk endpoints, if the last data packet
is exactly wMaxPacketSize bytes long.
This flag allows applications to inform libusb about this requirement,
so that libusb can handle the issue transparently.
At the moment the new flag is only supported on Linux, and submitting
a transfer with the flag set returns an error at submit time on other
systems. Hopefully implementations will soon follow for other systems.
References #6.
|
|
|
|
The old check_flag_bulk_continuation() tested for one specific running
kernel version. The new kernel_version_ge() instead allows to test the
running kernel version against major, minor and sublevel parameters.
|
|
LIBUSB_ENDPOINT_OUT is the value of the direction bit, which is 0 for
OUT transfers, so the previous condition could never evaluate to true.
|
|
Fixes #128.
|
|
When libusb was built with timerfd support but used on a system
without timerfd support the library would hang indefinitely on
completion of the first transfer, since timerfd functions were
being called unconditionally and the error returned when timerfd
was not being used caused a confused internal state.
Many thanks to Ivo Smits for looking into the issue, proposing
an initial solution, and helping with testing! Fixes #73.
|
|
* libusb\libusb-1.0.rc(21): Could not find the file LIBUSB_RC.
* only shows up first time after opening workspace.
* shows up on either build or clean.
* not actually due to rc.exe, but prior to it.
* probably an IDE bug.
* does not show up when running an exported makefile.
Signed-off-by: Michael Plante <michael.plante@gmail.com>
|
|
* tests conducted using a Renesas PCIE USB 3.0 controller and driver and
a mass storage USB 3.0 confirm that USB_NODE_CONNECTION_INFORMATION_EX
uses (undocumented) value 3 for SuperSpeed
|
|
This helps on Mac OS X where an old glibtoolize is included in the
system and newer, manually installed, versions provide libtoolize.
See also http://marc.info/?m=132490560131894
|
|
This is intended to reduce confusion with the much more significant
lsusb utility which is part of the usbutils package.
|
|
|
|
|
|
|
|
|
|
Use OSAtomicIncrement32Barrier() and OSAtomicDecrement32Barrier()
in darwin_init() and darwin_exit() to be thread safe.
|
|
|
|
* indexes were outgrowing the unref_list array before realloc,
resulting in out of bound access and crash.
|
|
* this ensures that libusb dependent applications only need
to link with libusb on Windows
* (copied from Pete's msvc08 mods to msvc6 by Michael)
|
|
Signed-off-by: Michael Plante <michael.plante@gmail.com>
|
|
|
|
On MSVC6 bitwise OR promotes to int, causing the warning.
|
|
* usbi_dbg encloses all references to guid_to_string
* MinGW/cygwin warn about an unused function, so the #if
squelches this warning
* MSVC6 uses a variadic function form of usbi_dbg instead
of a macro, so the compiler still "sees" guid_to_string
and it therefore needs to always be defined for MSVC6,
even if it's only a stub.
* So we define it if usbi_dbg is used OR if MSVC6 is used.
Signed-off-by: Michael Plante <michael.plante@gmail.com>
|
|
* issue reported by Elmi
Signed-off-by: Michael Plante <michael.plante@gmail.com>
|
|
* unlike later iterations of Visual Studio, MSVC6 does not accept
blank parameters on macro calls [eg. CALL(a, ,b)]
* blank params were used with the DLL_DECLARE and DLL_LOAD macros
* issue reported by Elmi
|
|
* MBCS (which is different from UTF-8) only makes sense if
supporting Windows 95/98, which we don't
* (try to match Pete's vcproj changes in MSVC6)
|
|
Signed-off-by: Michael Plante <michael.plante@gmail.com>
|
|
|
|
Since commit 40327cd134718475f6cec8935b856d4fdff2099c it is neccessary
to explicitly include -lobjc not only when linking libusb itself, but
also for programs linking statically against libusb. References #63.
See also http://marc.info/?m=132505900202378
|
|
Previous _LDFLAGS included both the freshly built libusb in ../libusb
and -lusb-1.0, where libtool would usually resolve the latter to an
already-installed libusb library in the system. The extra reference
to a second libusb library resulted in failure to build examples on
Mac OS X in some cases, and is plain wrong.
See also the thread at http://marc.info/?m=132637593623667
|
|
Not every make supports recursive variable expansion so some automake
versions complain about non-POSIX variable names ever since commit
70bec4a9f8ec28d36c731011fa24d37c74ad3523 which added support for
silent-rules in our rule to compile the Windows .rc file.
This commit removes the recursive variables and instead uses the
simple and generic GEN message and associated variable.
|
|
Declare the usbi_log_v() function before using it.
|
|
The call to pthread_setname_np() makes it easy to identify the
background thread in the Xcode debugger and in crash reports.
|
|
|
|
|
|
|
|
Fixes #121.
|
|
References #121.
|
|
References #121.
|
|
sync.c: In function `libusb_control_transfer':
sync.c:122: warning: enumeration value `LIBUSB_TRANSFER_OVERFLOW' not
handled in switch
Fixes #120.
|
|
* pointed out by Travis Robinson and Xiaofan Chen
* similar to a change advised by Alan Stern for the Linux kernel:
http://marc.info/?m=122790204410765
|
|
* issue reported by René Haunstrup in http://marc.info/?m=130503019227814
|
|
* Windows 8, NEC/Renesas, TI, Fresco Logic, Etron, VIA, ASMedia
(some of which untested!)
* includes workaround for NEC/Renesas USB 3.0 root hubs
|
|
|
|
|