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?
> This is still not answered. If INPUT_DEVICE_ID_MATCH_BUS
> is there, then I don't see the argument that the input
> layer is not designed for the like things.

Yes, you are right. INPUT_DEVICE_ID_MATCH_BUS will not likely
benefit anyone. It is highly unlikely that we would have a handler
for devices on specific bus or for devices made only by one vendor.
When I mentioned userspace I was talk ing about exporting bus,
product, vendor and version values to userspace which might be
still benefitial. Although as we move along to sysfsifying the
kernel bus information can be traced through sysfs instead.

> 
> > You just do not want to implement proper access control for the
> > hardware, that's it.
> Depends on an answer to the question above, whether using
> input is the proper way or not.
> 

Consider this: pcspkr is broken at the moment as it does not
handle several simultaneous events well. If you fix it do behave
properly with SND_TONE and SND_BELL arriving at the same time
then adding hooks to the speaker code for snd-pcsp should be
pretty easy. See?

--
Dmitry