Starting with the configure checks, to detect if libusb 1.0 if available, and
otherwise fall back to the libusb 0.1 backend

The port to libusb 1.0 is now complete for usbhid-ups. Other USB drivers
(bcmxcp_usb, blazer_usb, nutdrv_atcl_usb, richcomm_usb, riello_usb,
tripplite_usb, nutdrv_qx) have still to be addressed

The port to libusb 1.0 is complete, at least from a build perspective. This now
needs to be tested with devices

The port to libusb 1.0 is complete, at least from a build perspective. This now
needs to be tested with devices

The port to libusb 1.0 is complete, at least from a build perspective. This now
needs to be tested with devices

NUT internal header "libusb.h" was renamed, since it collides with the libusb
1.0 header, which has the same name. A few occurences of reference and
documentation were however missing

libusb 1.0 provide its own routine for detaching kernel driver

The port to libusb 1.0 is complete, at least from a build perspective. This now
needs to be tested with devices

The port to libusb 1.0 is complete, at least from a build perspective. This now
needs to be tested with devices

The port to libusb 1.0 is complete, at least from a build perspective. This now
needs to be tested with devices

usb_strerror was not remapped for libusb 0.1 implementation

The port to libusb 1.0 is complete, at least from a build perspective. This now
needs to be tested with devices

The port to libusb 1.0 is complete, at least from a build perspective. This now
needs to be tested with devices

A few symbols from libusb 1.0 were wrongly used directly, instead of being
looked up and loaded at init time

libusb 1.0 has its own set of return codes, and error interface. Rework the
common HID core (shared between usbhid-ups and mge-shut) so that error handling
can work with both, and using either libusb 0.1 or 1.0 for usbhid-ups

bus publication was wrongly listing both the bus and the portname, instead of
the bus only. This may have caused some issue when trying to match the port

For libusb 0.1 implementation, we had to workaround a libusb API goofs, by
wrapping the base function usb_control_msg(), and casting the variables to the
right type. This is not needed for libusb 1.0 implementation, but was wrongly
left in the code (reported by Charles Lepple)

libusb 1.0 has introduced a new function (libusb_set_auto_detach_kernel_driver),
beside from the explicit kernel driver detachment request
(libusb_detach_kernel_driver). However, the former is not available on all
systems. As an example, FreeBSD 10.1-10.3 does not have this. The detachment and
interface claiming has been reworked to handle this case (reported by Charles
Lepple)

Reference: #300

Following the recent modification for the kernel driver detachment, and the
related functions availability depending on the platforms, nutdrv_atcl_usb and
richcomm_usb were using the wrong macro for libusb_set_auto_detach_kernel_driver
and were missing the libusb 1.0 code for explicit kernel driver detachment

Reference: #300

usb_set_altinterface allows to force the USB code to call
`libusb_set_interface_alt_setting (0, 0)` (equivalent to
`libusb_set_altinterface(0)` in libusb 0.1), as was done in NUT 2.7.2 and
earlier. However, the libusb 1.0 implementation was still missing the related
code

Reference: #300

With the port to libusb 1.0, a sanity check was done on the available number of
USB devices to try. This however caused a behavior regression, since the only
device that NUT may have access to can be the only UPS connected. In this case,
the driver may exit upon trying to reconnect if the device is transiently not
available

Reference: #300

libusb 1.0 returns on success, the number of bytes actually transferred or
otherwise an error code, except for interrupt transfers, where the actual
transfer size is stored in a separate variable. The libusb 1.0 implementation in
NUT thus needed to be fixed to behave the same way than the libusb 0.1
implementation

Reference: #300

Per <http://libusb.sf.net/api-1.0/group__dev.html#ga8163100afdf933fabed0db7fa81c89d1>,
the handle is only populated when the return code is 0.

This fixes a crash during device detection where more than one HID UPS is
available, and the driver needs to skip the first one.

Reference: #300

Signed-off-by: Arnaud Quette <ArnaudQuette@Eaton.com>

Since LIBUSB_VERSION is always non-empty ('none', if libusb is not found), testing for non-emptiness will always fail and libusb 0.1/libusb-compat checks will always be performed.
So, test instead that it is not 'none'.

…mpat

Libusb 0.1/libusb-compat can be found with both pkg-config and with its own libusb-config, but, regardless of how we found it, we need to use the same AC_DEFINE'd variable to signal its presence.

…acro

Since libusb 1.0 can happily coexist with libusb 0.1/libusb-compat, rework our NUT_CHECK_LIBUSB macro so that, if both are available, libusb 1.0 precedence can be overridden passing to `configure` appropriate values for `--with-usb-includes` and `--with-usb-libs` (i.e. libusb 0.1/libusb-compat-only settings).

Document the possibility to override the auto-detection choice

Signed-off-by: Arnaud Quette <ArnaudQuette@Eaton.com>

Switch to look-before-you-leap (LBYL) approach to calling
libusb_set_auto_detach_kernel_driver(), since FreeBSD (11.0 and 11.1; probably
others) requires root privileges to attempt the kernel driver detach (even if
no detach operation is needed).

Remove a few "magic numbers" from USB/HID-related calls.

Closes: #499

Closes: #300

Notable commits from master:

 * Documentation
 * statepath environment variables (#473 / #507)
 * nut-scanner (issue #500 / pull #502)
 * Fix one parallel build problem (#418)
 * Compute output load if not provided (#484)

Closes: #509

Make NUT_CHECK_LIBUSB macro aware of those libusb 0.1 implementations named in their pkg-config files as 'libusb-0.1', instead of just 'libusb' (e.g. on FreeBSD).

… device

…vice

…ning

libusb 1.0:
- a device list allocated with libusb_get_device_list() must be deallocated with a call to libusb_free_device_list(),
- ditto for the config descriptor.

libusb 0.1 and 1.0:
- release (commented-out) interfaces when done with them,
- remove unnecessary goto's after calls to fatal*() functions,
- nutscanner: also close the USB device handle (and libusb_exit() for libusb 1.0) on errors.

Although at that point of usb_device_open(), both the local (handle) and the global (udev) device handles point to the same thing, prefer the local one to make things clearer.

- libusb 0.1 (when not shared with libusb 1.0): prefer our xstrdup() function -- on errors, it'll automatically call fatal*(),
- libusb 1.0 (and nutscanner): don't use our x{malloc,strdup,...}() functions, so that we can free the list of devices (and close the device and call libusb_exit() in nutscanner) before exiting.

…rs or when done with it

… descriptor

From our old libusb.c, libusb1.c inherited a for loop that iterates over the interface descriptor in order to try and find the HID descriptor among its 'extra' bytes.
Unluckily, it uses the same var (i) that's now used, at the same time, for the iteration through the device list, in which it happens to be nested.
Since this obviously spells disaster, make these vars unique (and add a bit of debugging info).

… 750 ms to allow more time for UPS response

(cherry picked from commit 5cea18c --@clepple)

Closes: #543
Closes: #542

…ields

…fields

…is time

…is time - also the values registered with comm_driver structure

…is time - reformatted

Libusb 1.0+0.1 debug

…o libusb-1.0+0.1

…om master

…ibusb 0.1 and 1.0"

… subtypes (reapply to libusb-1.0 branch)

…k_libusb.m4

…w manipulate "LIBS" not "LIBUSB_LIBS"

…UT_MODE

…T_USB_VARIANTS as well

…uild, report the Configured NUT_SSL_VARIANT

…uild, report the Configured NUT_USB_VARIANT

…s are decremented when configuration failed

…s for SSL+USB are planned same as executed

…s for SSL+USB are planned same as executed - and handle explicit NUT_USB_VARIANTS=no

…0.1 and 1.0" if we build with QX_USB at all (no required headers are in context otherwise)

… longer global var name (AUT => BCMXCP_AUTHCMD)

…bus_ctx (nee ctx)

… of log, and if non-zero BUILDSTODO remained unaccounted

…usb-1.0+0.1 branch]