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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
