Add support for libusb-compat-0.1

[infinity-computers-dot-net]

A package called libusb-compat-0.1 exists to provide a "shim" allowing libusb-1.0 to fulfil a dependancy on libusb-0.1.

Maybe change the binding to look for libusb-compat-0.1 first, and bind to that in preference to the others? This would allow the library to target libusb-1.0 on systems lacking libusb-0.1.

[soemraws]

I'm using the package libusb-compat myself, and it simply provides a library called libusb-0.1.so, while libusb itself provides libusb-1.0.so. Is there another platform that creates libusb-compat-0.1.so?

[infinity-computers-dot-net]

Fair point. I guess I didn't understand exactly how libusb-compat-0.1 operated. So I guess I just install libusb-compat-0.1 and libusb1.0, and it will just work transparently without any need to change the code?

[soemraws]

That is exactly what it looks like. Do you have an example where this is not the case? I will separately have a more in-depth look at libusb-compat.

[sebasmonia]

I am but a newbie to not only Common Lisp but also USB, so maybe this is all wrong...

I'm migrating a Python script someone wrote to control some keyboard features and the original code detaches, sends a control message, and re-attaches to kernel.

It seems libusb 1.0 exposes a function to enable auto-detaching from the kernel libusb_set_auto_detach_kernel_driver, which is not part of libusb 0.1. In libusb 1.0 there's also a counterpart function to re-attach (which I guess the PyUSB library is using)

Right now in this package, by targeting 0.1, there's a function to detach from the kernel (usb_detach_kernel_driver_np) but no function to re-attach so the only option is to call usb-reset in the cffi side.

I have no clue how different the behaviour is using reset vs auto-detach vs detach/attach manually, maybe this is all irrelevant 🙃