Re: [linux-usb-devel] [RFC] HID bus design overview.

["Adam Kropelin" <akropel1@rochester.rr.com>]

Jiri Kosina wrote:
> On Wed, 4 Apr 2007, Adam Kropelin wrote:
>> On Apcupsd we've recently introduced a libusb-based driver that does
>> all HID parsing in userspace. Not only does that free us from
>> hiddev, it also frees us from the umpteen other proprietary HID
>> interfaces across various platforms. Although the hiddev-based
>> driver is still the default for Linux platforms, I plan to change
>> that in the next major release and thus begin migrating folks off of
>> hiddev.
>
> Great. Do you use libusb to obtain raw hid events?

We do, along with libusbhid from *BSD to handle report descriptor 
parsing and report field extraction/insertion.

> Could you by any
> chance look at current implementation of hidraw (it's in -mm or I can
> send it to you as a separate patch) and check whether you have any
> comments on this?

I pulled down 2.6.21-rc5-mm4 and took a look at hidraw. I like the 
simplicity of it for sure. One feature that seems to be missing is the 
ability to force an input report to be fetched via a control transfer. 
Several APC UPSes have the unfortunate tendency to change report values 
without sending an interrupt report to notify you, so you have to poll 
them occasionally. Also, how does one fetch string descriptors via 
hidraw?

> It would be good if you could use hidraw rather
> than reading raw usb data through libusb.

I have to admit I don't see much value in switching Apcupsd to hidraw 
rather than libusb. (I see lots of value switching it away from hiddev, 
though :) We need a HID engine in userspace to handle descriptor parsing 
with any non-hiddev solution. Plus, APC UPSes tend to have buggy HID 
implementations that require a bit of care to communicate with properly. 
Having an "intelligent" kernel layer in the middle tends to just get in 
the way (see the truncated report handling patch for hid-core I just 
sent).
But honestly, the deal-breaker is that with libusb I can hit Linux, all 
the *BSDs, Darwin, Solaris, and even Windows with a single userspace 
driver. That's just too valuable to ignore.

--Adam