On Thu, 8 Mar 2012, Stéphane Chatty wrote: > >> I had the feeling that the current hid code was somehow trying to be > >> universal, thus making the point moot, and figured that we would > >> need to reintegrate hid-multitouch into hid-core at some > >> point. You're suggesting another, more distributed option, in which > >> new categories of HID devices appear from time to time and are > >> handled in new modules, right? Sounds interesting to me, I'd like to > >> hear what the original designers of the hid module think of it. > > > > Me too. Reading through the module code, it really seems to put > > userland in charge, only providing sufficient information to be able > > to load the right modules. If this was fully possible in hid, at least > > one of the special blacklists would disappear. One would also be able > > to split the current hid-input into several different drivers, for > > instance, gaining some clarity in addition to memory savings. > > This would be a radical change from the current hid code that tends to > restrict "true hid" to a limited range of HID usages and to reject the > rest (cf the IS_INPUT_APPLICATION that caused us some difficulties three > years ago). But this definitely would make sense to me. Jiri, Dmitry, > what do you think? Frankly, I'd personally love IS_INPUT_APPLICATION() to die, it's just horribly ugly and doesn't scale with rapidly growing number of HID devices appearing every day (with multitouch definitely being the most active group). So restructuring a HID core in a way that makes the whole process much more generic and offloads the responsibility into modaliases seems like a proper way to go for me. I'll be thinking about it a little bit more in the upcoming days, other ideas are of course very welcome. Thanks everybody for initiating this discussion, -- Jiri Kosina SUSE Labs -- 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
