On Fri, Jun 22, 2012 at 11:11 AM, Alan Ott <a...@signal11.us> wrote: > On 06/16/2012 12:51 PM, Nathan Hjelm wrote: >> The only reason to use libusb under hidapi on Linux is the lack of >> an HID API. Its not really a good thing. > > I disagree. Linux has hidraw, which is its native HID interface from > userspace. > > The original reason for a libusb-based HIDAPI implementation on Linux > was that when HIDAPI was started, hidraw had some limitations which > needed to be fixed in the kernel, the largest of which was lack of > handling of feature reports. These issues have since been fixed (as of > kernel 2.6.39). Since getting new kernel code to end users can take > quite a bit of time (roughly 2-3 month kernel release cycles, where new > code gets queued for the next (not current) cycle, plus distros which > are often on a 6-month or longer release cycle and often will ship one > revision behind the latest kernel, and users which are often not using > the latest distros), I decided to make a libusb-based implementation of > HIDAPI to fill the gap. This worked well with a few caveats. Currently > there are advantages to using the hidraw implementation and there are > advantages to using the libusb implementation which are outlined in the > HIDAPI README and in linux/README. Further, the libusb-based > implementation is useful now for FreeBSD as well.
Last time I sent the news about libusb/libusbx in the NetBSD mailing list and it generated quite some interests. One of the issue is again the driver detaching problem since libusb/libusbx rely on ugen driver under BSDs. One potential solution is to teach uhid the ugen ioctls but that is quite some big work. http://mail-index.netbsd.org/current-users/2012/05/30/msg020285.html The other solution is to detach uhid with a custom kernel configuration that has a pre-defined ugen entry but unfortunately it requires a rebuild of the NetBSD kernel. http://mail-index.netbsd.org/current-users/2012/05/31/msg020306.html >> I would argue that if hidapi wants hotplug support they will need to >> implement it themselves for one simple reason: HID is not restricted to >> just usb. Bluetooth support is tricky. > > Hotplug would have to come from libudev on Linux. > >> On OSX it isn't thread safe (you can't access a device from >> more than one thread) so I wouldn't recommend accessing >> IOBluetooth with a generic interface. > > I don't know about IOBluetooth, but HIDAPI on Mac is perfectly > threadsafe. If you find a threading issue, it's a bug. > >> Besides, it is trivial to add hotplug support for most device >> classes under OSX. I can't speak for other platforms. > > The API for hotplug in IOHIDManager is pretty good, and easy to use. > Linux isn't bad either (libudev for both back-ends). One day I need to > get motivated and get hotplug into all the HIDAPI implementations. Windows is not that bad either. I think libusb-pbatard's hp branch has some codes already. -- Xiaofan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
