Mainly because I was not able to
come up with the good hooks for the
pcspkr driver, and those I tried,
were not applied.
There was a lengthy thread about that.
Now I can't find its beginning and its
end, but some is here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0603.2/3096.html
I also think you were CCed, but maybe
not.
If they are separate, then "rmmod pcspkr"
should disable the beeps. I don't want
to fuzzy that logic up to something like
- Check if snd-pcsp is loaded
- Use alsamixer to disable beeps, if
it is.
- Use rmmod pcspkr if it is not.
I think there should be always a single
way for the user to disable the beeps.
Now he can choose it by chosing the driver.
Could you please clarify?
- Should snd-pcsp then forcibly select
pcspkr.c to compile?
- What exactly function pointer, and
where to add?
Yes, but problematic when they are separate.
I was trying to add an input event to shut
up pcspkr.c, but that was rejected. Everything
else will introduce the dependancy. The
dependancy will block rmmod, obfuscating the
logic of disabling the beeps.
Just for the record, what problems do you
see with the current solution, where only
one driver drives the device? That looks
rather logical to me. And I also can remember
the complains about pcspkr driver being in
an input drivers section. Some people had
problems finding it there and were asking
to move it to sound menu.
--
