![]() | |||||||||||
Messages in this thread |
--- Stas Sergeev <stsp@aknet.ru> wrote: > Dmitry Torokhov wrote: > >> Why does it have the INPUT_DEVICE_ID_MATCH_BUS after all? > > For userspace benefits. > How exactly does the userspace benefit from the > INPUT_DEVICE_ID_MATCH_BUS thing? > And, by the way, why doesn't the input have the > capability of disabling/enabling the device? > What for? If you do not want to get events form a device do not read it. Or do not compile/load the driver. You can do a lot of things from userspace. Your problem is that you want to one piece of kernel to take over another kernel piece instead of making it work together. With your enable/disable scheme what happens where there is 3rd module that wants to do stuff with speaker? Does it also disable snd-pcsp? > > While you are fine with > > disabling beeps while music is playing otherpeoplr might still want > > to hear them. > The only possibility to do this, was to have the grabbing > capability *in input layer*, which you already rejected too. > With this, it was possible to have such a behaviour run-time > configurable, but now my best bet would be to resort to the > Kconfig games, making a note for users that the uinput is now > an only possibility to route the terminal beeps to the snd-pcsp. > You just do not want to implement proper access control for the hardware, that's it. -- 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/ | ||||||||||
| Last update: 2006-05-18 06:34 [from the cache] ©2003-2008 | |||||||||||