On 01/21/2011 11:14 AM, Jiri Kosina wrote:
On Fri, 21 Jan 2011, Alan Ott wrote:
Well, what I really want is the Usage Page and Usage of the device. For some
background, I maintain a library called hidapi[1] for accessing HID devices in
a cross platform way. There are currently four backends, Linux-hidraw,
Linux-libusb, Mac OS, and Windows.
I've recently received requests for supporting composite HID devices. Since a
composite device will show up as multiple devices with the same VID/PID, one
needs a way to differentiate between its different interfaces. On Windows and
Mac, the platform HID libraries support getting the Usage Page and Usage of
each interface. On Linux/libusb I can request the HID report descriptor and
parse it myself, but I have to claim the interface to do it, and to do that, I
have to detach the kernel driver. Needless to say, detaching the kernel driver
is not good, especially when the library is supposed to be just scanning for
devices.
For these reasons, it would be really convenient to get the report descriptor
from sysfs.
In this case, you can still get the report descriptor from hidraw (which
is parallel to any other HID-bus based kernel driver). Woudl that suit
your needs?
Not exactly, because not all HID devices have a hidraw interface
(because some are blacklisted). These devices are still accessible
through libusb. Plus, getting it from hidraw involves having permissions
to open the device[1]. Maybe that's less of a limitation, but since I
can get everything else from sysfs (vid/pid, strings, device version),
it seemed to make sense to me to have the hid report descriptor in the
same place.
Again, if I'm completely wrong about how I should be going about this,
just let me know.
Alan.
[1] Last year, I suggested adding some interfaces to hidraw to get
things like the serial number, and it was suggested to me on
linux-usb[2] that I use sysfs (through libudev) instead. I extrapolated
that the proper paradigm was to use sysfs to get information about the
device, and to use the device node itself to actually communicate with
the device. I could be wrong again.
[2] I didn't realize at the time that I really should have asked on
linux-input instead of linux-usb.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html