Re: [patch 1/1] pc-speaker: add SND_SILENT

[Stas Sergeev]

Hi.

Dmitry Torokhov wrote:
> > I think I'd better try to code up the grabbing capability in
> > the input layer, since Dmitry didn't seem to object to that.
> I was pondering over implications of "grabbing" events over the
> weekend and I am not entirely happy with it either. The problem with
> grabbing is that your driver does not have any knowledge of how the
> events would be processed if left untouched. Right now you assume that
> all bells are handled by pcspkr but we could really have alternative
> bell implementations. For example we could have "visual" bell that
> could flash framebuffer or a bell that is routed through ALSA, etc,
> etc. All these alternative bells would not disrupt operation of your
> snd_pcsp module but it still would disable the bell because it does
> not know better.
Why not? I can check dev.id.bustype and dev.phys to find out what
exactly resources it allocates. This all is present in "struct input_dev"
AFAICS. And since they are here, I don't agree using the input subsystem
on that layer is completely wrong.
Well, I can also add the hack to snd-pcsp to always reprogram PIT
chan 2 to proper mode in an inthandler to make it tolerant to whatever
pcspkr does. But this is quite an evil hack, and an unnecessary code
pollution which I'd like to avoid.
Adding a dummy input driver, as per Bodo Eggert, doesn't look very good
to me either. If nothing else then at least because it won't be called
pcspkr, so the confusion is still unavoidable.

Adding a few ALSA guys to CC, who used to help with the snd-pcsp in
the past.

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