From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934649AbYEBOH1 (ORCPT ); Fri, 2 May 2008 10:07:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760550AbYEBOHN (ORCPT ); Fri, 2 May 2008 10:07:13 -0400 Received: from mail.suse.de ([195.135.220.2]:42745 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760743AbYEBOHL (ORCPT ); Fri, 2 May 2008 10:07:11 -0400 Date: Fri, 02 May 2008 16:07:09 +0200 Message-ID: From: Takashi Iwai To: Stas Sergeev Cc: Linux kernel , Dmitry Torokhov Subject: Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree In-Reply-To: <4818B057.4080803@aknet.ru> References: <12094266793898@kroah.org> <4816A888.9000802@aknet.ru> <20080429045849.GA6348@suse.de> <481776EA.5010200@aknet.ru> <4818B057.4080803@aknet.ru> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 MULE XEmacs/21.5 (beta28) (fuki) (+CVS-20070806) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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