libusbx/libusb/libusb.h:153: warning: no matching file member found for
libusb_cpu_to_le16()Possible candidates:
static uint16_t libusb_cpu_to_le16(const uint16_t x)
Thanks to Serhat Sevki Dincer for the bug report
http://sourceforge.net/mailarchive/message.php?msg_id=31719691
Since the buffer pointer will later be casted to ``struct
libusb_control_setup *'', it should point to memory aligned to at least
2 bytes boundary as that's the strictest requirement of the struct fields.
Also, use a (void *) casting trick to convince the compiler the cast is
safe, to fix warnings such as:
/usr/local/include/libusb-1.0/libusb.h: In function 'libusb_control_transfer_get_setup':
/usr/local/include/libusb-1.0/libusb.h:1435:9: error: cast increases required alignment of target type [-Werror=cast-align]
/usr/local/include/libusb-1.0/libusb.h: In function 'libusb_fill_control_setup':
/usr/local/include/libusb-1.0/libusb.h:1464:39: error: cast increases required alignment of target type [-Werror=cast-align]
/usr/local/include/libusb-1.0/libusb.h: In function 'libusb_fill_control_transfer':
/usr/local/include/libusb-1.0/libusb.h:1509:39: error: cast increases required alignment of target type [-Werror=cast-align]
cc1: all warnings being treated as errors
This actually can lead to failure to build from the sources for certain
projects which use -Werror=cast-align on ARM.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When libusb_hotplug_register_callback gets called with the
LIBUSB_HOTPLUG_ENUMERATE flag, there may still be hotplug events pending
in the hotplug pipe, waiting for dispatching from libusb_handle_events.
This means that the user callback can be called twice for arrival of the
same device, once from libusb_hotplug_register_callback, since the device
is already part of the usb_devs list, and once from libusb_handle_events
when it reads the event from the hotplug pipe.
This could be fixed by adding a mechanism to pause hotplug handling, then
drain the hotplug pipe (ie by calling libusb_handle_events from
libusb_hotplug_register_callback), before iterating over the usb_devs list,
and then un-pausing hotplug handling afterwards, doing this however requires
a lot of hairy code, which will be prone to dead-locking.
OTOH it is quite simple for user applications which care about this to detect
this and ignore the 2nd call, so lets simply document this may happen and
be done with it.
Note that this is also the solution which ie libudev has choosen, there is
no way with libudev to get a device-list + listen for device arrival / removal
without running into the same problem.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add auto-detach-kernel-driver functionality, and a
libusb_set_auto_detach_kernel_driver() function.
Note that I went with a libusb_set_auto_detach_kernel_driver() function,
rather then with a libusb_enable_auto_detach_kernel_driver(), so that apps
can also disable it again. This is necessary to handle 2 corner cases:
1) When an app wants to do a libusb_set_configuration after claiming 1 or
more interfaces, it needs to first release the interface(s), and in this
case libusb_release_interface() should *not* (re-)attach the kernel driver
2) Some usb classes use multiple interfaces for one function, ie usb-audio
devices do this. In this case attaching the driver will fail until all
interfaces are released, so the app should first release all interfaces, and
only then (re-)attach the kernel driver.
auto-detach-kernel-driver functionality is still useful for these apps, since
doing libusb_detach_kernel_driver() followed by libusb_claim_interface() in
2 separate calls is inherently racy, but they need to be able to disable the
auto-detach functionality before releasing interfaces to be able to properly
handle the 2 described corner cases.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This patch adds the much requested libusb_strerror() function, taking into
account all issues people raised wrt previous attempts.
Criteria / Decisions underlying this implementation:
- Must support translated messages
- Must not use gettext as that does not work well in combination with Windows
(when building with Visual C, or for Windows CE)
- API compatible with FreeBSD and various patched libusb-s floating around
- KISS:
- Do not add any (other) library dependencies
- Do not try to deal with message encodings (iconv), simply always return UTF-8
making encoding the problem of the application using libusb_strerror.
- Defaults to English, so apps which don't want translated messages,
don't need to do anything special
- Defaults to English (with pure ASCII messages), so apps which don't
call libusb_setlocale() don't need to worry about encoding
This new function replaces the now deprecated libusb_get_port_path function,
as that is the only function operating on a libusb_device which also takes
a libusb_context, which is rather inconsistent.
Note we will keep libusb_get_port_path around in the 1.0.x for the forseeable
future for ABI compatibility reasons, but it should not be used in any new
code.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The internal API is changing as follows:
- Adding two new functions. usbi_connect_device, and usbi_disconnect_device.
Backends must call these functions to add them to the context's device list
at one of two places: initial enumeration (done at init), and on device
attach and removal. These functions need to be called once per context.
- Backends that support hotplug should not provide a get_device_list funtion.
This function is now deprecated and will likely be removed once all backends
support hotplug.
The external API is changing as follows:
- Two new functions have been added to register and deregister callbacks for
hotplug notification: libusb_hotplug_register_callback(),
libusb_hotplug_deregister_callback(). Hotplug callbacks are called by
libusb_handle_events(). Details of the new API can be found in libusb.h.
- A new capability check has been added to check for hotplug support. See
LIBUSB_CAP_HAS_HOTPLUG.
Aa suggested by Xiaofan add new example has been added to show how to use
the new external hotplug API. See examples/hotplugtest.c.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The comment refers to the non-existing libusb_device_ref and
libusb_device_unref functions, this should be libusb_ref_device resp.
libusb_unref_device.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* Also remove Linux special case from xusb sample.
* Note that LIBUSBX_API_VERSION is incremented as a result of
libusb_has_capability() returning nonzero rather than 1 when
a capability is supported.
* A LIBUSB_CAP_HAS_HOTPLUG is also added, though it is currently
not implemented on any platform
* Closes#102
* fxload sample provenance
* No need for <sys/types.h> in samples as already in libusb.h
* Don't bother about sscanf_s in xusb
* Use HAVE_### and rely on config.h where possible
* Formal inclusion of <winsock.h> in libusb.h for WinCE and WDK
* Cleanup of Windows' config.h
* Avoid ENAMETOOLONG and ENOTEMPTY conflict between errno.h and winsock.h for WinCE
* Additional newlines & braces cleanup
* Remove obsolete tags
* Use QUIET = yes to make issues more prominent
* Fix code display for LIBUSBX_API_VERSION and missing parameter
documentation for libusb_get_port_path()
* Most of the above suggested by Ludovic Rousseau
* This macro can be used to detect if the version of libusbx being
compiled against has a specific API feature, as well as to detect
whether compilation occurs against libusb or libusbx.
Note that for the code 0 which means success resp. completed we have an
overlap in the codes. This is not a problem since normally one would not
call libusb_error_name on success / normal completion.
* IMPORTANT: This update fixes a typo in the API where MaxPower was being
used instead of bMaxPower, with the latter being what is actually in
the specs.
* As a result, applications that were using MaxPower need to be updated
for bMaxPower.
* If you must maintain compatibility with libusb or older versions of
libusbx, you may also want to either use a #define or copy/paste
struct libusb_config_descriptor from libusb.h under a new name, and
then use a cast on calls that require it. For more info, see the
1.0.13 release notes in the NEWS file.
* Also update copyright notice
* The LOG_LEVEL_ enums, that were moved to the public API
in 933a319469 may conflict
with applications/headers that also define their own
LOG_LEVEL_ values internally.
* As a matter of fact, as per Trac #31, this produces a
conflict with libusb-compat, as it defines its own levels.
* Adds libusb_get_port_number, libusb_get_parent and libusb_get_port_path
* Linux implementation provided by Alan Stern, OS X by Nathan Hjelm
* Unsupported for *BSD platforms
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.
Until we have i18ned error messages we can at least offer easy
translation from numeric error code to the error code's name.
[hansg: switch() on enum to get a compiler warning if a case is missing]
[hansg: Better return value when called with an unknown error code]
[hansg: Fix DEFAULT_VISIBILITY in definition to compile on all platforms]
Since it is currently not planned to change the filename of the libusb
library between libusb-1.0 versions at least on Windows systems it's
important to have a capability API.
Currently there exists only one capability; LIBUSB_CAP_HAS_CAPABILITY,
which tests support for the libusb_has_capability() API.
The sync API had a race where it would check a condition to know if it
needed to call a libusb_handle_events() function. However, the check
was done outside of the lock that is held while the condition is set,
so another thread could completely serve whatever was needed to make
the condition true between it being checked and the event handler being
called. This situation would be detected after a libusb-internal timeout
of 60 seconds, after which the transfer would be completed without
error, but with significant delay.
Original patch at http://marc.info/?l=libusb-devel&m=127252114815709
Changes by Hans de Goede:
- Renamed the "race-proof" functions from libusb_handle_events*_check()
to libusb_handle_events*_completed()
- Drop r = 0 setting in libusb_handle_events_timeout_completed()
(to make both completed checking cases identical flow wise)
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
[stuge: Simplify libusb_handle_events_timeout() change with a goto]
[pbatard: Fix _handle_events_timeout() and _completed() definitions]
* adds the MSVC support files used by MSVC6, VS2005 and WDK
* also adds missing defines required by MS compilers in libusb.h
* also anticipatory sets .gitattributes for CRLF handling
* also adds manually maintained .def file for import lib generation
References #57.
Under Windows, a variety of compilers and configurations are available,
meaning that the manner of parameter passing (e.g. registers vs stack)
can vary.
Match the Windows API calling convention and document this appropriately.
This calling convention will be used regardless of the configuration of
the user's development platform.
The only user-level complication is that all functions used as libusb
callbacks must use the same calling convention as libusb. The
LIBUSB_CALL macro is provided to make this easy.
Signed-off-by: Michael Plante <michael.plante@gmail.com>
Signed-off-by: Pete Batard <pbatard@gmail.com>
[dsd: slight change of strategy, add documentation]
This header doesn't exist on windows.
For libusb, determine at configure-time if the header is available.
For libusb.h, use gcc predefined macros to only include the header
on platforms that need it.
