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

Jiri Kosina
2007-03-31T22:44:21Z

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