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

On 3/30/07, Li Yu <[email protected]> wrote:
> 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.
>

I was thinking that as we write customized drivers we would add them
(manually or automatically) to the HID blacklist so that generic
driver would not bind to such devices. Then, as your driver loads it
would parse reports and construct input device structure in the same
fashion that it processes the reports - if it is an "interesting"
report/usage it will handle setup itself; otherwise just call generic
setup function shared with the generic HID driver. This way there is
only one input device and there is no storm of add/remove events as we
loking for the proper driver to bind to the device.

Does this make sense?

This would not quite work for (potentially out of tree) HID drivers
brought in after compiling generic HID driver but that should be a
very rate occurance and we still can manually bind such drivers via
sysfs bind/unbind and new_id manipulations.

-- 
Dmitry