On Fri, 30 Mar 2007, Dmitry Torokhov wrote: > There should be one device and your driver should simply do: > static void my_driver_hid_event(struct hid_device *hid, struct hid_field > *field, > struct hid_usage *usage, __s32 value) > { > if (special_processing_needed(usage)) { > do_special_processing(...); > input_event(field->hidinput->input, XXX, YYY, ZZZ); > ... > > } else > hidinput_hid_event(hid, field, usage, value); > }
Hi, in fact I am not entirely sure that the specialized drivers hooked to the HID bus should be passed individual fields/usages by the generic HID driver. That would imply that generic HID layer would have to parse the received report using information retrieved from the report descriptor of the device. But this is in some way in contrary to one of the features this effort should be heading to, isn't it? We want to provide means how to bypass possible errors in HID descriptor of the device (or do any other possible quirky handling) - we want to be able to allow for completely different interpretation of fields than the generic HID parser would do, right? So I guess the above should rather be 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); } Such driver will register itself onto a HID bus. Both USB and BT transports could provide VID and PID which could then be easily matched against by the bus code to easily check whether processing by specialized driver is needed or handling by (existing) generic HID layer is enough. As an added value, hooking the hidraw code to this architecture would then be rather a trivial task. 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/