| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Fixed #1203
Signed-off-by: Nathan Hjelm <hjelmn@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The header docs state its possible to set a default log level before
calling libusb_init(), and that this log level will be used for all
contexts created after (to quote):
"Note that libusb_set_option(NULL, ...) is special, and adds
an option to a list of default options for new contexts."
This updates the logic inside libusb_init() to ensure this
behaviour is followed.
Fixes #1207
Signed-off-by: Francis Hart <francis@kuvacode.com>
Signed-off-by: Nathan Hjelm <hjelmn@google.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The __func__ macro is defined by the C99 standard (but not C++99/03).
The default C compiler in msvc implements C89, plus Microsoft extensions,
some of which are part of C99.
It appears that both vs2013 and vs2015 don't define __func__.
Closes #1170
|
|
|
|
|
|
|
|
|
|
| |
Also remove comment about possible endpoint halt, which seems not
correct, as discussed in issue #1110.
References #1110
Closes #1117
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Historically Mac OS X always cleared the data toggle on the host side. For
consistency, libusb has been calling ClearPipeStallBothEnds to also clear the
device side toggle. Newer versions of the IOUSBLib do not clear the host side
toggle so there is no need to make this call. Additionally, some buggy devices
may fail to correctly implement clearing the data toggle.
Signed-off-by: Nathan Hjelm <hjelmn@google.com>
[Tormod: Return result from AbortPipe]
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
libusb_set_option uses variable arguments and therefore cannot use
__stdcall.
In practice, this does not get exported anyway. Verified under MinGW's
objdump tool with 32 and 64-bit combinations.
Closes #1197
Signed-off-by: Rosen Penev <rosenp@gmail.com>
|
|
|
|
|
|
|
|
| |
Only leave a debug message.
Fixes #1215
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
| |
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to Ilya Averyanov for initial version.
This test detects issues like #1124.
Adaptation to Windows threads is on the wishlist (#1128).
References #1124
References #1128
Closes #1189
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the windows HID backend is used for interrupt or bulk transfers on
USB-HID compliant devices which don't use HID report IDs, the current
code properly adds a zero prefix byte for report ID 0x00 before an OUT
transfer, and properly strips the leading zero prefix byte from buffers
received by IN transfers. Length of transmitted data is increased by +1
accordingly to account for the extra prefix byte.
However, on transfer completion the length of sent or received data is
not adjusted back again by one. This leads to misreporting of effective
transfer length for both OUT and IN transfers, reporting one byte too
much. It also causes a memcpy for IN transfers which copies one byte of
data too much into the client provided target buffer
transfer_priv->hid_dest, appending an extra zero byte at the end and
thereby writing one byte past the size of the client target buffer. This
could lead to memory corruption or a access violation if the client
application is unlucky.
This commit fixes the problem by detecting this type of HID transfers
and adjusting the effective length of the transfer down one byte.
The fix has been successfully tested with a Griffin PowerMate USB-HID
device that doesn't support report IDs, performing interrupt transfers
from/to the device.
Closes #1217
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some (non USB-compliant) devices the interface number doesn't match
its index in the list of interfaces in the configuration descriptor. For
robustness and consistency across platforms, find the descriptor by
iterating over the list to match the bInterfaceNumber.
References #1093
References #1039
References #1175
Closes #1191
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
|
|
| |
Fixup of commit 1a08aa8.
Closes #1200
|
|
|
|
| |
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows we use UNREFERENCED_PARAMETER for UNUSED (commit 521105f).
UNREFERENCED_PARAMETER evaluates to {(ctx) = (ctx);} which errors out:
error: lvalue required as left operand of assignment.
in the cases where ctx is NULL.
Closes #1152
[Tormod: Add ctx reference to avoid unused variable warnings]
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
WINAPI evaluates to __stdcall, which does not work with variadic
functions. MSVC and MinGW implicitly demote this to __cdecl (clang does
too and also warns about it). Instead of having this implicit, make it
explicit.
Closes #1160
Signed-off-by: Rosen Penev <rosenp@gmail.com>
|
|
|
|
|
|
|
|
|
| |
The device structure is not always valid at this point.
Fixes #1179
Closes #1186
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
|
|
|
| |
Closes #1187
Reviewed-by: Dmitry Zakablukov <dimaz@passware.com>
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The config descriptor was not released in some (rare) cases:
- Darwin: never released in case GetPipeProperties failed
- Windows: not released for some non-USB compliant descriptors
Follow-up of commit f5275f9a and commit aa1d76cd
References #1093
References #1039
Closes #1183
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
|
| |
Fixes #501
Closes #1057
|
|
|
|
| |
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
| |
Closes #1115
|
|
|
|
| |
Closes #1114
|
|
|
|
| |
Closes #1113
|
|
|
|
| |
Closes #1111
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor common settings into .props files. Enables building full
PlatformToolset, Platform, Configuration matrix easily.
Also update the appveyor file. Technically we no longer need different
images (could just have a single vs2022 image which is executed multiple
times in parallel, or so)
Closes #1116
|
|
|
|
|
|
| |
References #1067
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Follow-up to 561dbda, a check of GCC atomic builtins needs to be done
first.
I'm no autoconf guru, but using this:
https://github.com/mesa3d/mesa/blob/0df485c285b73c34ba9062f0c27e55c3c702930d/configure.ac#L469
as inspiration, I created a pre-check before calling AC_SEARCH_LIBS(...)
Fixes #1135
Closes #1139
|
|
|
|
|
|
| |
Create links to:
- libusb_set_option()
- LIBUSB_OPTION_NO_DEVICE_DISCOVERY
|
|
|
|
| |
Signed-off-by: Ludovic Rousseau <ludovic.rousseau@free.fr>
|
|
|
|
|
|
|
| |
Under MSYS2, the windows usbi_get_monotonic_time interferes with the
static inline function under libusbi.h
Closes #1151
|
|
|
|
| |
Closes #1155
|
|
|
|
|
|
| |
Closes #1109
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removed the logic in configure.ac (for Darwin only) that detected if the
clock_gettime() function exists. Instead, just use the preprocessor to
introspect the macOS SDK version and deployment target and call
clock_gettime() if they are new enough.
Also replaced the fallback code for older macOS with
mach_absolute_time() and gettimeofday(), which are simplier because they
do not need setup and teardown carefully balanced and their usage is in
one place instead of spread in multiple places in the file.
Closes #1080
|
|
|
|
|
|
|
|
|
| |
libusb only uses pkg-config macros in configure to check for umockdev. Since
this is only required for testing it makes sense to protect the usage of these
macros to only be used when pkg-config is installed. This will be the case for
maintainers and testers.
Signed-off-by: Nathan Hjelm <hjelmn@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The cleanup function darwin_cleanup_devices was intented to be called only once
at program exit. When the initialization/finalization code was changed to
destroy the cached device list on last exit this function should have been
modified to require a lock on darwin_cached_devices_lock. This commit updates
cleanup to protect the cached device list with the cached devices mutex and
updates darwin_init to print out an error and return if a reference leak is
detected.
Also using this opportunity to correct the naming of the mutex. Changed
darwin_cached_devices_lock to darwin_cached_devices_mutex. Also cleaning the
initialization code up a bit. Removing the context pointer from the hotplug
thread as it is not used for anything but logging.
Fixes #1124
Signed-off-by: Nathan Hjelm <hjelmn@google.com>
|
|
|
|
|
|
|
|
|
|
| |
This commit resolve the ordering of 'exit' dependencies as was started for 'init' in https://github.com/libusb/libusb/commit/0846456f3a9fda8ff5469d9d0b9700837ff16f04
(Relates to https://github.com/xloem/libusb/pull/5)
Closes #1126
Signed-off-by: Nathan Hjelm <hjelmn@google.com>
|
|
|
|
| |
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The behaviour of libusb_cancel_transfer is different on Darwin:
- Cancellation cancels all transfers on the same endpoint.
- A ClearFeature(ENDPOINT_HALT) request is sent after cancellation.
This documents both differences and their implications.
Fixes #1110
Closes #1121
|
|
|
|
|
|
|
|
|
|
|
|
| |
The darwin event thread (in contrast to other OS implementations) tries
to log to the context that created it. However, this context is only
guaranteed to be valid until the thread has started. It may be that
another context is the last one to be destroyed, causing the event
thread to log using an already destroyed context.
Fix this by only passing on ctx where it is acceptable.
Fixes #1108
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Silence "nonstandard extension used : zero-sized array in struct/union"
(C4200) warning caused by use of ZERO_SIZED_ARRAY in structures defined
in libusb.h when compiling with msvc.
A libusb user including the header from a c++ file is more likely to be
annoyed by the warning because it is activated at level 2 as opposed to
being included from a C file, where it's not activated until level 4.
(on msvc, level 4 is the last step before -Wall).
This causes problems when you also enable -Werror for your own source,
since the libusb header just gets merged into the compilation unit.
9>hotplugtest.c
9>C:\src\libusb\libusb\libusb.h(786,11): error C2220: the following warning is treated as an error
9>C:\src\libusb\libusb\libusb.h(786,11): error C2220: uint8_t dev_capability_data[ZERO_SIZED_ARRAY];
9>C:\src\libusb\libusb\libusb.h(786,11): error C2220: ^
9>C:\src\libusb\libusb\libusb.h(786,11): warning C4200: nonstandard extension used: zero-sized array in struct/union
9>C:\src\libusb\libusb\libusb.h(786,11): warning C4200: uint8_t dev_capability_data[ZERO_SIZED_ARRAY];
9>C:\src\libusb\libusb\libusb.h(786,11): warning C4200: ^
9>C:\src\libusb\libusb\libusb.h(811,47): warning C4200: nonstandard extension used: zero-sized array in struct/union
5>C:\src\libusb\libusb\libusb.h(811,47): warning C4200: struct libusb_bos_dev_capability_descriptor *dev_capability[ZERO_SIZED_ARRAY];
5>C:\src\libusb\libusb\libusb.h(811,47): warning C4200: ^
9>C:\src\libusb\libusb\libusb.h(1284,38): warning C4200: nonstandard extension used: zero-sized array in struct/union
9>C:\src\libusb\libusb\libusb.h(1284,38): warning C4200: struct libusb_iso_packet_descriptor iso_packet_desc[ZERO_SIZED_ARRAY];
9>C:\src\libusb\libusb\libusb.h(1284,38): warning C4200: ^
9>Done building project "hotplugtest.vcxproj" -- FAILED.
Closes #1112
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows, unlike other platforms, the isochronous packet actual_length
value is not set on completion of OUT transfers. However, our API
requires the user to check this value for isochronous transfers instead
of the transfer actual_length, if the transferred length is of interest.
The usbd Length field is not used for isochronous OUT transfers:
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/usb/ns-usb-_usbd_iso_packet_descriptor
To make it consistent with other platforms, just return the requested
length.
Fixes #1105
Closes #1107
Tested-by: Xiaofan Chen <xiaofanc@gmail.com>
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
We cannot use the CHECK_WINUSBX_AVAILABLE macro since it
may return with the wrong error type/value.
Fixes #1100
Closes #1101
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
|
|
| |
Closes #1102
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
| |
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
|
|
|
|
| |
On non-macOS platforms, ResetDevice() does nothing so we use the "old" way of
calling re-enumerate. If the device is captured, we have to re-enumerate, then
re-capture, re-authorize, and finally restore the state.
Closes #1088
|
|
|
|
|
|
|
|
|
|
|
| |
TARGET_OS_OSX is not defined when building with the clang 8 provided by
Xcode 8.2.1 on 10.11.5 (unless the Xcode project is used).
If it is not defined we'll just assume we have a "OSX" target.
Closes #1097
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
The WinUSB isochronous transfer implementation always assumed HighSpeed
microframes.
https://github.com/libusb/libusb/issues/747#issuecomment-649491619
References #747
References #749
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Put back missing CHECK_WINUSBX_AVAILABLE macro.
The subapi is generally set in the backend functions themselves, using
the macro CHECK_WINUSBX_AVAILABLE. However, this macro was (likely
inadvertently) removed from winusbx_copy_transfer_data() in commit
9c28ad2 causing the subapi in this function to always be SUB_API_NOTSET.
This results in the error:
libusb: debug [winusbx_copy_transfer_data] unsupported API call for 'copy_transfer_data' (unrecognized device driver)
https://github.com/libusb/libusb/issues/747#issuecomment-649619615
References #749
Closes #1095
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a behaviour change in libusb 1.0.25 which triggers issues when
the API is misused. This caused for instance gutenprint to crash, see
https://bugzilla.redhat.com/show_bug.cgi?id=2055504
This seems to affect several applications "out in the wild".
For now, work around this by installing an implicit default. But, change
the code to log an error in case this "feature" is being used.
This will allow some grace time for developers to fix their
applications, before we at a later point revert to the stricter
behaviour.
Fixes #1089
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A HID composite device with three interfaces (e.g. keyboard and touch
screen built into one), with all three interfaces referencing their own
names in the interface descriptor, was reported to have an iProduct
string equal to the name of the last interface instead of the actual
product name (e.g. "TOUCH" repeated twice instead of "PRODUCT" and
"TOUCH").
This behavior differ from what for instance Microsoft USB Device Viewer
will report for the same device. This fix will make them report the same
thing.
Use HidD_GetIndexedString() instead of HidD_GetProductString(), as the
latter would otherwise return the name of the interface instead of the
iProduct string whenever the iInterface member of the
USB_INTERFACE_DESCRIPTOR structure for the interface is nonzero (see
Remarks section in the Microsoft documentation of the HID API routines).
Closes #1091
|