[libhid-discuss] libhid use case question

[Stefan Kost]

Hi Charles,

Charles Lepple wrote:
> On Apr 3, 2007, at 3:42 AM, Stefan Kost wrote:
> 
>> I currently work on a wrapper lib around hid-devices
>> (/dev/input/eventX), lirc-devices, midi devices, ... - stuff that has
>> buttonas and controls basically. I want to use it to bind ardware
>> controllers to my application ui. I discover devices via HA right now.
> 
> not sure what "HA" is, with respect to hotplug or input events...
That should have been "HAL" (Hardware Abstraction Layer".
> 
>> For the hid-devices I started to work on the implementation when I
>> discovered libhid. Unfortunately I could not really see what it
>> offers. I need to query the device capabillities (how many controls
>> and which type they are) as well as open and read from them. Is that
>> waht the lib offers?
> 
> You can get to this information through the MGE hidparser component of
> libhid. However, you mentioned /dev/input/event*, and libhid operates
> one level lower than that. When you open a device in libhid, it
> eventually needs to be disconnected from the Linux kernel usbhid driver
> so that we can read the HID report descriptor (which is the collection
> of data that describes what buttons and features a HID-class device has).
> 
> libhid was originally written for HID UPSes that do not have
> /dev/input/event* nodes, and at the time it was started, the
> /dev/hiddev* API was not complete enough to expose all of the different
> HID collections. It also requires you to poll the device from userspace,
> which is probably not as efficient as letting the kernel manage polling
> as it does when the usbhid driver is attached to your devices.
> 
> --Charles Lepple
> 
Thanks for the explanation. I am making good progress with the evdev stuff. So I
will continue using this.

Stefan