On Thu, Mar 08, 2012 at 12:48:24PM +0100, Stéphane Chatty wrote: > > Le 8 mars 2012 à 12:30, Henrik Rydberg a écrit : > > > > The device-driver matching is done in the kernel, but driver (aka > > module) loading is done from userland. The crux is to be able to tell > > userland what driver to load for a certain device. In this case, it > > means giving more information to userland via the device/modalias > > construct. Or at least, that is the question. :-) > > > > Oook, I understand. The current solution used by distros is to load > the hid module statically, but then we don't want to do it for every > new kind of device-specific module, right? Is this your point? Yes, half of it. The other half is the observation that the problem of device-driver assignment we face for hid devices seems to originate in the definition of what a hid device is, i.e., the hid device identifier. If the identifier was more detailed and one could construct a new hid device dynamically from the reports, the problem would go away. Consequentually, a more detailed identifier would solve the module-loading problem as well. The major concern I have is if this is feasible from a compatibility point of view. > 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. Henrik -- 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
