Re: [PATCH 4/5] HID: autoload hid-multitouch as needed

[Jiri Kosina]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/