On Mon, 2 Apr 2007, Dmitry Torokhov wrote:

quoted text
> > 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
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/