On Fri, Jun 22, 2012 at 10:45 AM, Alan Ott <a...@signal11.us> wrote:
> On 06/16/2012 09:24 AM, Xiaofan Chen wrote:
>> On Sat, Jun 16, 2012 at 9:19 PM, Xiaofan Chen <xiaof...@gmail.com> wrote:
>>> On Sat, Jun 16, 2012 at 7:39 AM, Nathan Hjelm <hje...@me.com> wrote:
>>>> Since I expect a majority of libusb's users are looking for portability
>>>> so all of HID device users should be directed to use hidapi.
>>> Actually hidapi can benefit from the libusb's HID backend as well.
>>> You can see that HIDAPI has a libusb-1.0 API based backend.
>>> https://github.com/signal11/hidapi/tree/master/libusb
>>>
>>> Right now it is only for Linux and FreeBSD. But if there is
>>> a native HID backend for libusbx under Mac OS X, the above
>>> libusb backend for HIDAPI can be extended to Mac OS X as well.
>>>
>>> You may ask why that could be beneficial? The native HID backend
>>> (HIDAPI under Mac OS X and Windows, and the hidraw backend
>>> for Linux even though hidraw is not the default for HIDAPI Linux)
>>> may have the side benefits of supporting Bluetooth. But in the future
>>> libusbx will have new features like Hotplug and Cross-platform event
>>> handling, that could actually benefit HIDAPI a lot provided libusbx
>>> supports HID on the platforms.
>
> I don't really understand this statement. HIDAPI currently uses
> IOHIDManager on Mac, which is the native API for HID device access on Mac.
>
> What you're suggesting is that libusb/mac add support for opening HID
> devices using IOHIDManager, so that then HIDAPI can use libusb/mac to
> open these devices (which will use IOHIDManager), instead of using
> IOHIDManager directly, which it already does?
I am saying that you could have two backend for HIDAPI for each
platform, one is the native HID API on the platform (benefits:
bluetooth support). The other backend is libusb (USB only,
but potential future benefits: cross-platform hotplug support
and cross-platform event handling support as outlined in
libusbx roadmap) provided libusb supports HID device for
the platform.
http://sourceforge.net/apps/trac/libusbx/roadmap
I guess this is a moot point and the potential benefits are
only potential now.
I will recommend people to use HIDAPI for new cross-platform
HID project. On the other hand, there are many existing
libusb-1.0 API based program for generic USB HID device
under Linux, if there is a need to port the existing program to
Windows, then probably they can stick to use the libusb-1.0 API,
just need to use libusbx-1.0.12 or later which supports generic
HID device under Windows.
>> BTW, it seems to me this uhid may be more suitable for
>> HIDAPI than hidraw in the future as the native backend.
>> http://permalink.gmane.org/gmane.linux.kernel.input/25430
>>
>> It sounds a bit like the native HID API under Windows.
>
> I think uhid is a method to insert HID events and traffic into the HID
> subsystem of the kernel from a userspace program, for processing as
> though these events were coming from hardware. The example uhid program
> creates mouse events from keyboard input.
>
> hidraw is the native HID library on Linux for sending and receiving raw
> data, and it works for USB and Bluetooth.
Thanks for the explanation. I was thinking that uhid can do similar
things as hidraw too but maybe I am not correct.
--
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
