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

[Li Yu <raise.sail@gmail.com>]

Dmitry Torokhov wrote:
> On Thursday 29 March 2007 23:06, Li Yu wrote:
>   
>> Dmitry Torokhov wrote:
>>     
>>> On 3/28/07, Jiri Kosina <jkosina@suse.cz> wrote:
>>>       
>>>> The crucial thing here is that all reports but the ones that the driver
>>>> registered to will be processed in a standard way by the generic hid bus
>>>> layer, and those reports that the driver registered to will be
>>>> ignored by
>>>> the layer, and passed for processing to the driver.
>>>>
>>>>         
>>> I don't think it is a good idea to register driver for specific
>>> usages/reports. Quite often you want to adjust processing of a report
>>> for a specific device. What if there are 2 devices that need such
>>> quirks? How will you do hotplug and module loading? Emit new uevent
>>> for every report? Also, what about users and Kconfig? "Driver for
>>> usage 0x000012345. Say Y if your hardware does not wotk correctly with
>>> defautl handler for this usage and require special processing"???
>>>
>>> Just register based on VID/PID and provide standard
>>> hid_default_input_event() to drivers so they would call it for reports
>>> they don't need to do special processing on.
>>>
>>>       
>>     I think the shadow driver can not share inputdev with the related
>> fundamental driver, so here are two input devices for one hid_device,
>> how we should process both? It seem we have three choices:
>>
>> 1. Shadow | Fundamental means
>>
>>     I think this is Jiri said. Fundamental driver handle all common
>> input events, and Shadow driver handle anther specific input events,
>> this imply user space process need monitor both input devices at same
>> time, I do not think this is good idea.
>>
>> 2. Shadow & Fundamental means
>>
>>     Let Fundamental driver and Shadow driver work at same time! but
>> shadow also handle specific input event. So, the user may get twice
>> input events! For example, the keyboard input in console.
>> Also, I do not like this.
>>
>> 3. Shadow ^ Fundamental means
>>
>>     Let Shadow driver handle every thing, and fundamental device silent,
>> even unregister it. I think this is best choice between them, this means
>> have a bit of complex.
>>
>>     
>
>
> 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);
> }
>
> That is pretty much it. Your driver is not a shadow driver, it is
> regular driver on HID bus that just happens to use generic hander
> for standard events.
>
>   

I think I can understand your words. but I need confirm:

Before specific driver register this device, the
fundamental/standard/common(select one by your mind:) driver had already
attach on it likely. At this case, we should detach this hid_device from
its working driver, let this hid_device attach with our new specific
driver. then new driver will handle all input event later, so the your
words is same with the third choice in fact, is it right? if so, the
actual behavior is same with former HID simple interface.

Good luck.

- Li Yu