Messages in this thread | | | Date | Wed, 30 Apr 2008 21:45:59 +0400 | From | Stas Sergeev <> | Subject | Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree |
| |
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. 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.
>>> 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?
>> 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.
| |