device.open() fails on linux x86_64 with hid4java 0.7.0

[codespotx]

Describe the bug
With latest version 0.7.0 device.open() fails for FIDO device.
This problem does not happen with version 0.6.0.
Version 0.7.0 is OK on windows 10 (before 1903)

To Reproduce
With Ubuntu 20.04.2 with x86_64 architecture.
Plug in a FIDO key (use Yubikey or Solo or add vendorId to code).
With attached project call mvn compile exec:java results in RuntimeException: device open failed

hid-test.zip

Expected behavior
execution without error (will show "send" and "recv" message hex dump).

Additional context
Window 10 1903 "hides" fido devices. see also node-hid/node-hid#312
On Linux reading of usagePage and usage fails, as HACK a vendor white list is used (Solo, Yubikey).

[tresf]

I'm experiencing this as well, Ubuntu 20.04, hid4java 0.7.0. A workaround is to force the library to use libusb instead.

HidApi.useLibUsbVariant = true;

At a glance it appears the value of HidDeviceInfoStructure.path being sent to HidApi.open(this.path); (and thus hidApiLibrary.hid_open_path(...) is the device path, e.g. /dev/hidraw0 instead of 003:009:00). Perhaps this is normal when using libhidapi-hidraw.so instead of libhidapi-libusb.so, but if that's the case, was the old version somehow using the wrong lib or is the path somehow being calculated incorrectly now?

[tresf]

I've confirmed, on Linux, 0.7.0 ships with two copies of libhidapi-libusb.so, one named libhidapi.so, the other named libhidap.so. The files are identical and both contain ELF symbols which bind to libusb (Confirmed using readelf -Ws, both versions have libusb_ bindings.). This is why switching to HidApi.useLibUsbVariant = true; on the develop branch fixes the aforementioned issue for me, it restores the broken behavior of 0.7.0, albeit unobviously.

[gary-rowe]

New libraries on develop should fix this. Need confirmation though.