On Windows 10, when a USB composite device is using usbccgp to manage
the parent device, there can be problems when an application tries to
claim multiple interfaces for a WINSBX-enabled subfunction. For example,
a common scenario is that an application is able to claim the first
interface of a given child function, but not the others.
This commit attempts to resolve this issue by making use of
(potentially) available interface association descriptors (IADs).
Within set_composite_interface(), which is normally called for the first
interface of a composite child function (Some MI_XX device, where XX is
the first interface), the set of IADs for the current configuration is
retrieved and, if the current interface matches the 'bFirstInterface'
for one of the returned IADs then the API backend, sub_api is also set
up for the other 'associated' interfaces. Subsequent calls to
libusb_claim_interface for any of these 'associated' interfaces will get
properly routed to winusbx_claim_interface.
Two fields have been added to winusb_device_priv.usb_interface:
num_associated_interfaces
first_associated_interface
These are made use of by winusbx_claim_interface() to decide whether
Initialize() or GetAssociatedInterface() function calls are needed, as
well as within winusbx_close() to perform proper cleanup for groups of
associated functions.
About composite functions in Windows (by Maciej T. Nowak):
(1) Non-composite device: Single device is created with all interfaces
grouped (associated) together. WinUSB_Initialize gives access to first
interface and WinUSB_GetAssociatedInteface can be used to get access to
remaining interfaces.
(2) Composite device without IAD is presented by set of devices each
containing single interface. As they are separate devices, separate
WinUSB_Initialize calls are required to gain access to each interface.
As there are no more interfaces in each device,
WinUSB_GetAssociatedInterface has no use in this case. In other words:
Each interface is grouped (associated) with itself.
(3) When we add IAD to a composite device, interfaces specified in each
IAD are grouped (associated) into single devices where WinUSB_Initialize
is required to open the first interface in each association and
WinUSB_GetAssociatedInterface for the remaining interfaces in each
group. Effectively this case is a mix of (1) and (2).
Closes#965
Signed-off-by: Ryan Metcalfe <ryan.metcalfe@novanta.com>
[Tormod: Removed redundant is_associated_interface member]
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Point out that only because NetBSD's #define's for USB speeds happen to
match the corresponding libusb enum values, it's OK to assign struct
usb_device_info's udi_speed field to the struct libusb_devices's speed
field.
References #1230
Allows statically linking vc++ runtime dependencies inside libusb-1.0
Windows libraries.
'Release' and 'Debug' configurations produce /MD compiled binaries while
the new 'Release-MT' and 'Debug-MT" configurations produce /MT compiled
binaries.
The /MT flag causes the application to include the multithread, static
version of the vc++ run-time library, whereas the default flag /MD will
cause the vc++ run-time library to be dynamically linked run-time. Using
/MT thus builds a standalone libusb DLL that doesn't require a vc++
runtime DLL to be shipped along with it.
For the official description of /MT see:
https://docs.microsoft.com/en-us/cpp/build/reference/md-mt-ld-use-run-time-libraryCloses#1188
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 #1110Closes#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>
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 #1128Closes#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 #1175Closes#1191
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 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 #1039Closes#1183
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
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
Follow-up to 561dbda, a check of GCC atomic builtins needs to be done
first.
I'm no autoconf guru, but using this:
0df485c285/configure.ac (L469)
as inspiration, I created a pre-check before calling AC_SEARCH_LIBS(...)
Fixes#1135Closes#1139
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>
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#1110Closes#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#1105Closes#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#1100Closes#1101
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
