-
Notifications
You must be signed in to change notification settings - Fork 397
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Native BSD backend using uhid #608
Comments
Duplicate of #543 ? |
I don't believe so. There's more BSDs than just FreeBSD. And #543 is about the |
For those who potentially want to start implementing this but don't know where to start (from HIDAPI POV) - here is an example me adding an experimental WinRT backend: https://github.com/libusb/hidapi/compare/winrt |
I don't believe a native port for DragonFly is feasible unless they fix their UHID ioctl situation. It doesn't appear to support getting any information about the device behind the UHID device such as the USB device information. The other 3 still appear to be viable. |
I am not so sure if there is any interest to have the uhid backend for FreeBSD as the existing libusb backedn works fine (libusb is part of FreeBSD now, and it is using FreeBSD's own libusb implementation with BSD license). So you can arguably call it native for FreeBD as well. hidraw backend seems to be more interesting for FreeBSD. But I agree that it will be good to have uhid backend for NetBSD and OpenBSD, if it is possible. HIDAPI libusb backend for NetBSD/OpenBSD require rebuilding the kernel last time I checked, so it is not really that useful. |
Further research reveals a problem with the current |
Instead of linking against |
Actually |
I have done a fair amount of work on a NetBSD port via Is there even an API in |
Excuse me for confusion, I really meant
This is an interesting problem. HIDAPI doesn't support "device-per-report" abstraction as it assumes that a single device may support multiple reports (that's why a report ID is explicitly passed as part of data payload). To support the
I don't see any better way. |
I am considering an approach that opens all the |
I believe opening all devices at once would be overkill, if even possible (what about exclusive/shared access, read/write permissions, etc.?). Lookup table - yes, plus lazy device opening, only if/when needed. |
Well, we have to do that anyway to properly enumerate devices, don't we? I only intended this to be done during an initial search for all the |
Ok. I am beginning to think a |
Nevertheless thanks for great investigation. I'll keep this ticket open for now. Maybe there will be more findings/details. |
Don't fret. I at least did learn that |
That should do it for the majority of the work. I thought I might as well put my research into actual code. |
I also looked into making a native one for OpenBSD but despite having similar APIs to NetBSD there is no apparent way to connect the Without the ability to explore the device relationships like this I cannot see a way to workaround the All that said I believe a port to FreeBSD is still possible due to how advanced its |
@Youw Does the libusb backend on FreeBSD have to completely disable the HID kernel driver to work? I was considering that in some niche situations it may be good to have the option to use the native kernel interface since devices in some cases will expose multiple HID interfaces. |
No. That is the beauty of FreeBSD USB stack. It exposes ugen driver along with uhid for generic USB HID devices, so that you can use libusb backend out of box. Unfortunately Hans Petter Selasky passed away recently. If not I would ask him to explain how it works. |
I see. How unfortunate. I think I will just work on OpenBSD backend and consider |
Having a uhid backend for OpenBSD will be great. Thanks. As you mentioned, it will still be much better than libusb backend. In fact I consider HIDAPI libusb backend not so useful (in fact kind of useless) for NetBSD/OpenBSD users. |
I was curious about the pragmatics of supporting various BSDs. There seems to be a fairly common API for HID over USB on most common BSDs called
usbhid
which is intended to be used with theuhid
kernel driver for generic HID devices. Support for this is likely a necessity because several BSD ports oflibusb
cannot be used with USB devices already reserved by a kernel driver.I'm too unfamiliar with HID myself to work on this at present, but is there anyone else willing to put in the effort to add this as a
hidapi
backend?The text was updated successfully, but these errors were encountered: