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

From: Adam Kropelin
Date: Thu Apr 05 2007 - 10:09:29 EST


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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/