On Mon, 2 Apr 2007, Dmitry Torokhov wrote:
> > static void my_driver_hid_report(struct hid_device *hid, u8 *data,
> > int size)
> > {
> > if (special_processing_needed(data)) {
> > do_special_processing(...);
> > input_event(field->hidinput->input, XXX, YYY, ZZZ);
> > ...
> > } else
> > hid_input_report(hid, data, size);
> > }
> >
> Well, this of course is most flexible, however I think that for most
> drivers hooking into parsed data would be much easier. That means that
> we need to allow defining 2 hooks - one for raw data and another for
> parsed reports and let drivers decice which one they want to use.
I agree. I am aware of devices for which just inspecting the parsed data
would be OK (some keyboards with usage mappings which are not defined by
HUT, for example), but also of devices which require special handling on
the report level - Robert Marquardt pointed me in a private mail to a few
devices which are broken par-excellence, and for which handling on report
level would be convenient.
Also, handling on report level would be nice to have so that we could hook
a hidraw driver to it.
Li, would this be OK by you?
Thanks,
--
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
