Re: [linux-usb-devel] [RFC] HID bus design overview.

[Jiri Kosina]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/