[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <045101c7778b$e45406e0$84163e05@kroptech.com>
Date: Thu, 5 Apr 2007 10:08:31 -0400
From: "Adam Kropelin" <akropel1@...hester.rr.com>
To: "Jiri Kosina" <jkosina@...e.cz>
Cc: "Li Yu" <raise.sail@...il.com>, <yanghong@...ss.com.cn>,
"linux-usb-devel" <linux-usb-devel@...ts.sourceforge.net>,
<hongzhiyi@...ss.com.cn>, "Marcel Holtmann" <marcel@...tmann.org>,
"Dmitry Torokhov" <dmitry.torokhov@...il.com>,
"LKML" <linux-kernel@...r.kernel.org>
Subject: Re: [linux-usb-devel] [RFC] HID bus design overview.
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists