On 05/11/2009 05:53 PM, Jiri Slaby wrote: > On 05/11/2009 05:51 PM, Jiri Kosina wrote: >>> So I think, in this particular case, it is OK to have the conditional >>> line in there. >> >> Actually this should be the case at least for >> >> - all drivers which implement only force feedback features >> - all drivers which only add additional key mappings > > Yeah, this is correct point and it looks very scary. Let me think about it. Hmm, if we could do something like plugins, which would just add some functionality without unbinding a device form a generic driver, it would be good. Plugins would be the same as drivers, except ll_driver won't be stopped and generic would still drive the device. It means plugins can't have report_fixup defined. We would need to introduce hid_disconnect, call it on register_driver, do the additional mapping, mask out FF connect bit or whatever other operation the plugin needs. This would be performed the same way as it is currently, except plugin probe won't call parse and hw_start, but only connect with proper flags. This will cover most of current drivers and hence we might eliminate almost all blacklisted entries (except the ones for drivers with report_fixup). Caveats: * events come even when stopped: drop (or hold) events until inputs are connected again * complexity: added complexity, slowdown in initialization and handling * "start-stop-start" on bootup: each bootup will start with generic, disconnect inputs (a plugin came), connect inputs by a plugin * plugins removal: we need to go through stop-start again * anything I don't see? Ideas, comments, improvements? -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
