Change the default backend on Linux to HIDRAW

[jonasmalacofilho]

While there are tradeoffs to using either the backend, HIDRAW is thought to be superior to LibUSB except in a very few cases.^1

Thus, only build the HIDRAW backend by default, and name the resulting module hid. This effectively makes the old --without-libusb switch the default behavior.

Additionally, add a --with-libusb switch for the LibUSB backend to be built as well. In that case, and to avoid breaking exiting code that already dynamically picks its preferred backend, the resulting module names are kept the same as before – hid for LibUSB and hidraw for HIDRAW – and LibUSB will be used by default when simply importing hid.

[prusnak]

I am wondering whether we should try to ship hidraw module at all (when building with libusb). It seems very confusing. Maybe shipping just the hid module is enough (backed by either hidraw or libusb)?

[jonasmalacofilho]

I think it is still useful to keep hidraw around even if libusb has been included in the build.

This is particularly relevant when cython-hidapi is installed globally (e.g. Linux distros), where different downstream projects may have different requirements.

P.S. While ArchLinux already uses --without-libusb, that's not the norm in Linux distros.

[jonasmalacofilho]

@prusnak, have you given this any more thought?

[jonasmalacofilho]

Actually, I changed my mind and agree that it would be better to only ship one module (by default, hidraw): besides making things simpler and clearer, I think we want downstreams and Linux users to benefit from the switch to hidraw.

And this PR (in its current state) would probably have failed at that: most Linux distros might have used --with-libusb just to keep that backend around, which would have the side-effect of changing the default back to it.

I'll make the changes in a bit...

[bearsh]

I have no strong opinion which backend should be the preferred one as long as both backends are available by the pypi package as one of my applications relies on libusb related feature. so maybe other downstreams have a similar requirement which would break application for them...

[prusnak]

one of my applications relies on libusb related feature.

Can you be more specific? What libusb related feature you need which is not provided by hidraw backend?

[bearsh]

one of my applications relies on libusb related feature.

Can you be more specific? What libusb related feature you need which is not provided by hidraw backend?

Well it's not that it is not available but different. it's the path entry in enumerate(). With the one from the libusb backend, its possible to locate the physical port which is AFAIK not easily possible with the hidraw backend (I'm happy to be proven wrong :smile: )

Furthermore, although not in my application, it not possible to to interact with a keyboard/mouse/joystick...

[jonasmalacofilho]

[...] as long as both backends are available by the pypi package [...]

Both backends would still be available through the PyPI package, just not simultaneously in any one environment.

And (admittedly from a quick search) it seems that --instal-option=--with-libusb still works when specified in a requirements.txt file, instead of as an argument to pip install.

Well it's not that it is not available but different. it's the path entry in enumerate(). With the one from the libusb backend, its possible to locate the physical port which is AFAIK not easily possible with the hidraw backend

That information is also available through udev. In Python you can query the ancestors of a hidraw device, and their corresponding attributes, with pyudev.

Another way is to manually follow the symlink in /sys/class/hidraw/<device> up to the parent USB device, and get the port numbers that way.

Furthermore, although not in my application, it not possible to to interact with a keyboard/mouse/joystick...

That doesn't seem to be the case on Linux: both with simple and with fancy/configurable mice I get hidraw nodes that I can open and read, as long as I have the correct permissions. My keyboard also has a hidraw node (but I haven't tested that one).

Using libhidapi-libusb would also unbind the input driver and make the device useless as an actual keyboard/mouse/joystick (for that period libhidapi-libusb is attached).

As a side note, ArchLinux has been building cython-hidapi using --without-libusb --with-system-hidapi for a while now, and I don't think there has been any bug report due to the removed libusb backend.

[mcuee]

This PR seems to be a good idea. In fact hidapi project now prefers hidraw backend to libusb backend for Linux.

Reference:

• https://github.com/libusb/hidapi/issues/493#issuecomment-1396827655

[mcuee]

By the way, from hidapi project point of view, you can treat hidapi-libusb and hidapi-hidraw as two different libraries under Linux. So technically you can provide two backends. But I think it is better to promote the hidraw backend for Linux users, as hidraw is getting matured and libusb backend has quite some limitations (not for Bluetooth device, etc).

Reference discussion: one potential limitation of hidapi libusb backend.

• https://github.com/libusb/hidapi/issues/274

[prusnak]

Closing this in favor of https://github.com/trezor/cython-hidapi/pull/162