These functions are used in a lot of existing downstream code
and the deprecation makes -Werror builds fail.
It seems reasonable to keep these functions supported at least until a
major API overhaul.
Closes#990Closes#1236
The behavior of libusb_set_option was not matching the documentation
when the log level was set in the environment. This has been fixed but a
regression test is needed to ensure the behavior does not deviate. This
commit adds a set of unit tests to cover some of the functionality of
libusb_set_option.
Closes#1245
Signed-off-by: Nathan Hjelm <hjelmn@google.com>
[Xiaofan: Add Windows setenv/unsetenv wrappers]
Signed-off-by: Xiaofan Chen <xiaofanc@gmail.com>
[Tormod: Fix test_no_discovery() build on Linux, add msvc build]
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
This commit updates the actual semantics of:
libusb_set_option(_, LIBUSB_OPTION_LOG_LEVEL, _)
to match the documentation. The documentation states that if the
LIBUSB_DEBUG environment variable is set then that level overrides the
value set by libusb_set_option.
Signed-off-by: Nathan Hjelm <hjelmn@google.com>
Do not show an uninitialized Max LUN value if the pipe stalled.
As suggested by the code comment (but not the old code), set a default
zero value only on pipe stall. On other errors simply error out.
References #1181Closes#1239
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Only keep it for Cygwin.
Clang doesn't support this option, and it seems only needed for
Cygwin since MinGW predefines e.g. the _WIN32 macro anyway.
From GCC documentation: -mwin32 This option is available for Cygwin
and MinGW targets. It specifies that the typical Microsoft Windows
predefined macros are to be set in the pre-processor, but does not
influence the choice of runtime library/startup code.
References #1192
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Several API changes targeted for 1.0.27
New API functions:
- libusb_init_context
- libusb_get_max_alt_packet_size
- libusb_get_interface_association_descriptors
- libusb_get_active_interface_association_descriptors
- libusb_free_interface_association_descriptors
- libusb_get_platform_descriptor
- libusb_free_platform_descriptor
(and their associated structures)
New option LIBUSB_OPTION_WINUSB_RAW_IO
NetBSD bus/address changes (not strictly part of API)
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
NetBSD's udi_bus/udi_addr values in struct usb_device_info start from 0.
However, libusb's bus_number/device_address in struct libusb_device use
0 to represent a missing value and the libusb API states that a value of
0 returned by libusb_get_bus_number() or libusb_get_device_address()
means "not available" so applications may refuse to match on zero
values.
Adjust between the two worlds by adding an offset of 1.
Closes#1230
Add support for enabling or disabling the WinUSB RAW_IO pipe policy for
a given endpoint, which is documented here:
https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/winusb-functions-for-pipe-policy-modification
This is necessary to increase performance. Without this option the
WinUSB backend will only queue one inbound operation at a time, even if
the libusb async API is used to submit multiple transfers.
For real-time sampling devices with high sample rates and small buffers,
the use of RAW_IO combined with queued async transfers is essential to
maintaining the necessary throughput and avoiding lost samples or buffer
overruns.
Examples of devices affected include Cypress FX2 based logic analyzers
accessed using Sigrok, and the HackRF software defined radio.
The new option must be set by calling libusb_set_option with the arguments:
libusb_set_option(ctx, LIBUSB_OPTION_WINUSB_RAW_IO, dev_handle,
endpoint_address, enable, max_transfer_size_ptr)
where the types of the variadic arguments are:
libusb_device_handle *dev_handle;
unsigned int endpoint_address;
unsigned int enable;
unsigned int *max_transfer_size_ptr;
The dev_handle and endpoint_address parameters must identify a valid IN
endpoint on an open device. If enable is nonzero, RAW_IO is enabled,
otherwise it is disabled. Unless max_transfer_size_ptr is NULL, then on
a successful call to enable RAW_IO, the pointer destination will be
written with the MAXIMUM_TRANSFER_SIZE value for the endpoint.
Whilst RAW_IO is enabled for an endpoint, all transfers on that endpoint
must meet the following two requirements:
- The buffer length must be a multiple of the maximum endpoint packet size.
- The length must be less than or equal to the MAXIMUM_TRANSFER_SIZE value.
This option should not be changed when any transfer is in progress on
the specified endpoint.
This option only affects the WinUSB backend. On other backends it is
ignored and returns LIBUSB_ERROR_NOT_SUPPORTED, without modifying the
value pointed to by max_transfer_size_ptr.
A great deal of credit is due to Petteri Aimonen and Patrick Stewart for
previous work, and to everyone else who participated in discussions.
Fixes#490Closes#1208
This commit updates all test and example code to use the newer
libusb_init_context() function instead of libusb_init().
Signed-off-by: Nathan Hjelm <hjelmn@google.com>
[Tormod: Update umockdev.c as well]
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
The new initialization function addresses some shortcomings of the
libusb_set_option() interface. Namely, it allows setting the
no-enumeration option (and others) on only the contexts where it is
requested. The old initialization function (libusb_init()) is deprecated
and will be removed in a future release. For now it translates to a call
to libusb_init_context() with no options specified.
Closes#1026
Signed-off-by: Nathan Hjelm <hjelmn@google.com>
[Tormod: Doxygen description of libusb_init_option structure]
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
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>
