Messages in this thread | | | Date | Fri, 30 Mar 2007 12:13:17 -0400 | From | "Dmitry Torokhov" <> | Subject | Re: [linux-usb-devel] [RFC] HID bus design overview. |
| |
On 3/30/07, Li Yu <raise.sail@gmail.com> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |