Re: [patch] add input_enable_device()

[Dmitry Torokhov <dtor_core@ameritech.net>]

--- 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