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
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
