Revise libusb-1.0 usage in Windows branch

[jimklimov]

The NUT for Windows effort up to 2.6.5-7 branch abandoned several years ago did not consider the not-yet-existing libusb-1.0 codebase, but included some changes for the libusb-0.1 codebase.

While preparing the Windows-2.8.0-1 branch, I tried to apply changes that happened in libusb0.c to libusb1.c as well, but there may be things I've missed or misunderstood (APIs do differ).

It would be beneficial if someone better versed in libusb APIs went over those changes (comparing Windows branch to master), preferably both files for good measure, so we are more confident that it should actually work.

(Per small-scale testing at the time of this codebase update, linking with libusb-compat did function enough to discover the device and get initial data from the driver, although device-closing crashed when stopping it and I am not sure that run-time measurement/status updates did happen)

UPDATE: This situation also compromises use of libmodbus with RTU USB support, as it was not coded to accept libusb-0.1 API. PR #2778 should allow to explicitly prefer libusb-1.0 by using configure --with-modbus+usb (but the result may be flaky or not, per this issue).

[jimklimov]

Currently, both libusb-0.1-compat and libusb-1.0 builds misbehave in regard to data collection: effectively just the data points from device discovery (vendor, model...) are populated. Even status is not (remains "OB" by default, lacking other info). These builds claim I/O errors with interrupt processing mode, and nearly no data is collected with polling mode.

Maybe snatching the device from "kernel" should be done differently (Windows does represent the "USB HID Battery" and probably holds the critical resources).

Have yet to try with original libusb-win32 project the branch was built against.

[jimklimov]

FWIW, data collected there also complains about resource descriptor length which is miniscule and may be technically behind seeing no data (why - is another matter):

   2.272043     [D2] Checking device (0463/FFFF) (001/009)
   2.557041     [D2] - VendorID: 0463
   2.558664     [D2] - ProductID: ffff
   2.559767     [D2] - Manufacturer: EATON
   2.560962     [D2] - Product: Ellipse ECO
   2.562178     [D2] - Serial Number: 000000000
   2.563512     [D2] - Bus: 001
   2.564361     [D2] - Device: 009
   2.565317     [D2] - Device release number: 0100
   2.567701     [D2] Trying to match device
   2.568923     [D2] match_function_subdriver (non-SHUT mode): matching a device...
   2.571537     [D3] match_function_regex: matching a device...
   2.573576     [D2] Device matches
   2.574590     [D3] nut_usb_set_altinterface: skipped usb_set_altinterface(udev, 0)
   2.576772     [D3] HID descriptor, method 1: (9 bytes) => 09 21 10 01 00 01 22 3a 21
   2.578968     [D3] HID descriptor length (method 1) 8506
   2.580436     [D4] i=0, extra[i]=09, extra[i+1]=21
   2.581727     [D3] HID descriptor, method 2: (9 bytes) => 09 21 10 10 21 01 22 8d 03
   2.584775     [D3] HID descriptor length (method 2) 909
   2.586205     [D2] Warning: two different HID descriptors retrieved (Reportlen = 8506 vs. 909)
   2.588906     [D2] HID descriptor length 909
   2.590065     [D2] Warning: report descriptor too short (expected 909, got 33)
   2.592100     [D2] Report Descriptor size = 33
   2.593289     [D3] Report Descriptor: (33 bytes) => 06 84 00 09 04 a1 01 09 01 15 00 25 ff 75
   2.595711     [D3]  08 95 05 81 00 09 03 15 00 25 ff 75 08 95 0c b2 02 01 c0
   2.597697     HIDParse: LogMax is less than LogMin. Vendor HID report descriptor may be incorrect; interpreting LogMax -1 as 255 in ReportID: 0x00
   2.602894     HIDParse: LogMax is less than LogMin. Vendor HID report descriptor may be incorrect; interpreting LogMax -1 as 255 in ReportID: 0x00
   2.606896     Using subdriver: MGE HID 1.46
   2.608013     [D1] 2 HID objects found
   2.609011     [D4] Entering libusb_get_report
   2.610226     libusb_get_report: Input/output error
   2.611582     [D1] Can't retrieve Report 00: Input/output error [The operation completed successfully. ]

[jimklimov]

Seems to be a NUT for Windows-specific (or Windows builds of libusb-1.0 codebase specific, e.g. kernel detachment) problem.

Same NUT commit built and executed on Linux extracts a lot of data from the same UPS, without any hassle regarding descriptor lengths (both ways of calculation yield same result, and as much gets returned from the call):

# ./drivers/usbhid-ups -s eaton -x vendorid="0463" -x productid="FFFF" -x user=root -DDDDDDD -x port=auto -d3
...
   0.067204     [D2] Checking device 5 of 9 (0463/FFFF)
   0.491073     [D2] - VendorID: 0463
   0.491090     [D2] - ProductID: ffff
   0.491095     [D2] - Manufacturer: EATON
   0.491097     [D2] - Product: Ellipse ECO
   0.491100     [D2] - Serial Number: 000000000
   0.491104     [D2] - Bus: 003
   0.491106     [D2] - Device: unknown
   0.491109     [D2] - Device release number: 0100
   0.491113     [D2] Trying to match device
   0.491117     [D2] match_function_subdriver (non-SHUT mode): matching a device...
   0.491122     [D3] match_function_regex: matching a device...
   0.491139     [D2] Device matches
   0.491142     [D2] Reading first configuration descriptor
   0.491187     [D3] libusb_kernel_driver_active() returned 1 (driver active)
   0.491192     [D2] successfully set kernel driver auto-detach flag
   0.491393     [D2] Claimed interface 0 successfully
   0.491401     [D3] nut_usb_set_altinterface: skipped libusb_set_interface_alt_setting(udev, 0, 0)
   0.557076     [D3] HID descriptor, method 1: (9 bytes) => 09 21 10 10 21 01 22 8d 03
   0.557093     [D3] HID descriptor length (method 1) 909
   0.557098     [D4] i=0, extra[i]=09, extra[i+1]=21
   0.557102     [D3] HID descriptor, method 2: (9 bytes) => 09 21 10 10 21 01 22 8d 03
   0.557108     [D3] HID descriptor length (method 2) 909
   0.557111     [D2] HID descriptor length 909

   3.736092     [D2] Report Descriptor size = 909
   3.736107     [D3] Report Descriptor: (909 bytes) => 05 84 09 04 a1 01 09 10 a1 00 09 12 a1 00
   3.736113     [D3]  09 5a 85 20 75 08 95 01 15 00 26 ff 00 65 00 55 00 b1 82 c0 09 14 a1 00 09
   3.736117     [D3]  02 a1 02 06 ff ff 09 74 85 03 b1 83 09 74 81 83 09 75 b1 83 09 75 81 83 c0
   3.736121     [D3]  c0 c0 05 84 09 1e a1 84 09 43 85 0d 75 10 27 ff ff 00 00 66 21 d1 55 07 b1
   3.736125     [D3]  83 09 42 75 08 26 ff 00 66 01 f0 55 00 b1 83 09 40 85 12 67 21 d1 f0 00 55
   3.736128     [D3]  07 b1 82 09 1f 85 0b 65 00 55 00 b1 03 c0 06 ff ff 09 1c a1 00 09 1e a1 81
   3.736133     [D3]  09 98 85 18 75 10 27 ff ff 00 00 b1 83 09 1f 85 17 75 08 26 ff 00 b1 03 c0
   3.736137     [D3]  09 1e a1 82 09 98 85 18 75 10 27 ff ff 00 00 b1 83 09 1f 85 17 75 08 26 ff
   3.736141     [D3]  00 b1 03 c0 09 1e a1 83 09 98 85 18 75 10 27 ff ff 00 00 b1 83 09 1f 85 17
   3.736144     [D3]  75 08 26 ff 00 b1 03 c0 09 1e a1 84 09 98 85 18 75 10 27 ff ff 00 00 b1 83
   3.736148     [D3]  09 1f 85 17 75 08 26 ff 00 b1 03 c0 09 1e a1 85 09 98 85 18 75 10 27 ff ff
   3.736151     [D3]  00 00 b1 83 09 1f 85 17 75 08 26 ff 00 b1 03 c0 c0 05 84 09 18 a1 00 09 20
   3.736154     [D3]  a1 81 09 43 85 11 66 21 d1 55 07 b1 82 09 1f 85 0b 65 00 55 00 b1 03 09 21
   3.736158     [D3]  b1 03 09 02 a1 02 09 6c 85 0c b1 03 c0 c0 09 20 a1 82 06 ff ff 09 85 85 0f
   3.736161     [D3]  b1 03 05 84 09 1f 85 0b b1 03 09 21 b1 03 09 02 a1 02 09 60 85 02 b1 83 09
   3.736165     [D3]  60 81 83 09 6c 85 19 b1 02 09 6b 85 02 b1 83 09 6b 81 83 c0 c0 09 20 a1 83
   3.736169     [D3]  06 ff ff 09 85 85 0f b1 03 05 84 09 1f 85 0b b1 03 09 21 b1 03 09 02 a1 02
   3.736173     [D3]  09 60 85 02 b1 83 09 60 81 83 09 6c 85 16 b1 02 09 6b 85 02 b1 83 09 6b 81
   3.736176     [D3]  83 c0 c0 09 19 85 0b b1 03 c0 09 16 a1 00 06 ff ff 09 14 a1 00 05 84 09 02
   3.736179     [D3]  a1 02 09 62 85 03 b1 83 09 62 81 83 c0 c0 09 1c a1 00 09 54 85 13 75 10 27
   3.736183     [D3]  ff ff 00 00 67 21 d1 f0 00 55 07 b1 82 09 53 85 14 75 08 26 ff 00 b1 82 09
   3.736186     [D3]  1d 85 0b 65 00 55 00 b1 03 09 02 a1 02 06 ff ff 09 4a 85 03 b1 83 09 4a 81
   3.736191     [D3]  83 c0 05 84 09 30 85 0e 67 21 d1 f0 00 55 07 b1 83 c0 09 17 85 0b 65 00 55
   3.736194     [D3]  00 b1 03 06 ff ff 09 16 a1 00 05 84 09 02 a1 02 06 ff ff 09 76 85 03 b1 83
   3.736198     [D3]  09 76 81 83 c0 c0 c0 05 84 09 24 a1 00 09 5a 85 1f b1 82 05 85 09 8d 85 0c
   3.736202     [D3]  b1 03 09 2c b1 03 06 ff ff 09 95 85 15 b1 03 05 84 09 57 85 09 75 20 15 ff
   3.736205     [D3]  27 ff ff ff 7f 66 01 10 b1 82 09 56 85 0a b1 82 05 85 09 83 85 0c 75 08 15
   3.736209     [D3]  00 26 ff 00 65 00 b1 03 05 84 09 1f 85 0b 65 00 b1 03 05 85 09 67 85 0c 65
   3.736213     [D3]  00 b1 03 09 89 85 10 65 00 b1 03 05 84 09 fd b1 03 06 ff ff 09 f0 b1 03 05
   3.736217     [D3]  84 09 fe b1 03 09 ff b1 03 06 ff ff 09 f1 b1 03 05 84 09 35 85 07 65 00 b1
   3.736221     [D3]  83 09 25 85 0b 65 00 b1 03 09 02 a1 02 05 85 09 d0 85 01 75 01 25 01 b1 83
   3.736225     [D3]  09 d0 81 83 09 42 b1 83 09 42 81 83 09 44 b1 83 09 44 81 83 05 84 09 73 b1
   3.736229     [D3]  83 09 73 81 83 05 85 09 45 b1 83 09 45 81 83 05 84 09 61 b1 83 09 61 81 83
   3.736232     [D3]  09 62 b1 83 09 62 81 83 05 85 09 4b b1 83 09 4b 81 83 05 84 09 65 75 08 26
   3.736235     [D3]  ff 00 b1 83 09 65 81 83 09 69 b1 83 09 69 81 83 c0 05 85 09 66 85 06 65 00
   3.736239     [D3]  b1 83 09 66 81 83 09 29 85 08 b1 83 06 ff ff 09 4d 85 22 b1 82 05 85 09 68
   3.736242     [D3]  85 06 75 20 27 ff ff ff 7f 66 01 10 b1 83 09 68 81 83 c0 c0
   3.736304     Using subdriver: MGE HID 1.46
   3.736307     [D1] 94 HID objects found

This level of detail also allows to dismiss issue #1625 ;)

[jimklimov]

Looking at https://github.com/libusb/libusb/wiki/Windows#known-restrictions maybe my problems seeing device data stem from not installing libusb-win32 right (or libusbK at all) on the testbed. There should be a kernel level driver to access the device so Windows HID battery support does not preempt a NUT driver, probably.

See also https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/supported-usb-classes