Messages in this thread | | | Date | Fri, 02 May 2008 16:07:09 +0200 | From | Takashi Iwai <> | Subject | Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree |
| |
At Wed, 30 Apr 2008 21:45:59 +0400, Stas Sergeev wrote: > > Hello. > > Takashi Iwai wrote: > >> I was trying this in the past. > >> This never worked out very well. > > Why? > 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. > > >> I disliked the dependancies. > >> Either snd-pcsp was loading pcspkr, > >> or there had to be the global variable > >> to prevent the concurrent access, and > >> that hurts modularity. > > But you anyway enable the input pcspkr feature in your snd-pcsp code. > > So, basically you depend on (or build on) it. > If they are separate, then "rmmod pcspkr" > should disable the beeps.
But, they are *not* seperate right now. snd-pcsp contains pcspkr functionality.
> 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.
And this won't work in most cases. People don't want to replace the existing pcspkr driver with snd-pcsp. They don't want to load the sound subsystem on their systems just because of beep.
> >>> What we'd need is a hook on > >>> pcspkr.c that adds a dynamic check whether snd-pcsp (or any ohter) > >>> is running. > >> How? > > What you need is a way to check whether input pcspkr can be usable or > > not. You can add a function pointer, for example. > Could you please clarify? > - Should snd-pcsp then forcibly select > pcspkr.c to compile? > - What exactly function pointer, and > where to add?
If you compare pcspkr.c and pcsp_input.c, it's found that the only essential difference is the additional check at the head of the event handler:
if (atomic_read(&pcsp_chip.timer_active) || !pcsp_chip.pcspkr) return 0;
If this can be added dynamically to input pcspkr.c, no big point to have duped codes.
> >> And also, with snd-pcsp you have a > >> mixer control to disable the beeps, > >> which I find sometimes even more > >> usefull than the pcm sound itself. :) > > Yes, that seems useful. > 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.
Distros usually make input-pcspkr as built-in, not as module. So, snd-pcsp is practically unusable on standard kernels of major distros as is, unfortunately...
Takashi
| |