[libhid-discuss] cross-platform capabilities?

[Charles Lepple]

Xiaofan Chen wrote:
> On 4/5/07, Charles Lepple <clepple at ghz.cc> wrote:
>
>> Short answer: if libusb can access the device without interference from
>> any kernel HID drivers (e.g. FreeBSD after unloading or de-configuring
>> uhid; Linux after detaching the kernel usbhid driver, or OS X if nothing
>> else is using the native HID API), then libhid should be able to access
>> the device.
>>
>> Specifically, in OS X, there is no way to claim exclusive control over
>> the
>> device if the kernel HID module has already claimed it. (You can write a
>> custom stub driver with higher precedence than the kernel driver.)
>
> Why not use the native Mac OS X HID and use it as backend for
> libhid and get rid of the libusb dependency.

No objections from me. I just don't have the time to write and test the code.

This has been discussed before; see the list archives.

> Eg: pk2 (http://home.pacbell.net/theposts/picmicro/) is using libusb
> to support PICkit 2. Later people have replaced the libusb based
> USB code with native HID API and it is much usable now.
>
>> FreeBSD 6.2 seems to have the ugen driver compiled into the kernel, so
>> you
>> need to remove that from GENERIC and rebuild.
>
> I think you mean "uhid" and not or "ugen"?

You're right, I meant "uhid".

> To me it is still not convenient.
> By the way, libusb under FreeBSD (as well as the USB stack)
> is not as mature as under Linux. Maybe it is better to use the native
> uhid or ugen API.

The limitations that I have seen are due to different interpretations of
interrupt requests. Linux usbfs submits one URB per libusb
usb_interrupt_read/write request, and *BSD ugen seems to set up a
recurring transfer (and libusb reads the buffer that is filled by those
transfers).

This is fine as long as the libusb client program reads the buffer fast
enough, but it does not allow you to submit interrupt requests at a slower
rate than the descriptor specifies in *BSD.

>> At the moment, there is no Win32 backend, but you might have some luck
>> with libusb-win32 and libhid.
>
> That will be a problem. By default Windows will claim the HID device.
> It is possible to unbind the hid driver and use libusb-win32 device
> driver instead but this is not so convenient. If we use the libusb-win32
> filter driver, the system will hang since the HID driver is not detached.
>
> It seems to me the best is to use the native Windows HID API.

As with the OS X approach, the only major hurdle is the time necessary to
write the code (both for the infrastructure to select between the
different backends, and for the non-libusb access methods).

-- 
Charles Lepple
clepple at ghz.cc