Re: [linux-usb-devel] [DOC] The documentation for HID Simple Driver Interface 0.5.0

Jiri Kosina
2007-03-05T22:13:15Z

On Mon, 5 Mar 2007, Li Yu wrote:

> Under standard HID device driver development means, we need to write
> one interrupt handler for each new HID device to report event to input
> subsystem. However, although the most of they can not merge into
> mainstream kernel tree, they have only some extended keys, e.g. many
> remote controllers. I think it seem break a fly on the wheel, which
> write one new interrupt handler for this reason.

This paragraph I don't seem to understand. Either the device is claimed by
hid-input (*), and then when the device is behaving more-or-less
correctly, hid-input handles the usages sent in reports and maps them
properly to input events. New mapping can be quite trivially added to
hid-input.

If the HID device is not claimed by hid-input, then userspace can access
the hid events through hiddev and perform any actions that are needed.

Could you please elaborate a little bit more why your approach using
"simple HID interface" is better than for example hiddev+uinput, done
completely in userspace?

In addition to that, as I stated in some previous e-mail, I am currently
working on new 'hidraw' interface, which will provide more flexibility to
userland applications willing to operate on raw HID data, than they
currently have with hiddev.

(*) OK, I would tend to agree that the algorithm which decides whether the
given device will be claimed by hid-input driver could be improved to be
more HID-specification and HUT compliant. I have this in my TODO, but I
guess it doesn't matter too much here.

Thanks,

--
Jiri Kosina