At Thu, 12 Nov 2009 11:42:24 +0100 (CET), Jaroslav Kysela wrote: > > On Tue, 3 Nov 2009, Jaroslav Kysela wrote: > > >>> I don't see a problem. If you find the behaviour too risky, we can limit > >>> the register/unregister calls in time. Like one register call in one > >>> second. > >> > >> Oh no, that'd be very strange behavior as an mixer element. > > > > I recoded patch to delay the detach only to get consistent and abuse prone > > behaviour: > > > > http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=ba9c08c61338f298df34445715287beeca94b024 > > http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=0633c8e977b7708ea122392d87cc15ca448fc5d5 > > > > The HDA beep output is muted immediately, of course. > > Any chance to get my HDA beep updates merged to linux-next tree? > > [ALSA] hda_intel: Digital PC Beep - change behaviour for input layer > [ALSA] hda_intel: Digital PC Beep - delay input device unregistration > [ALSA] hda: beep - add missing cancel_delayed_work > > Reasons for merge: > > - it's tested > - it's compatible with all kernels (including ones without > the future input layer modifications) > - the code is more structured which can help us to rebind > "on request" input registration to another logic later > - Beep mute switch now disables the tone generator on the off request - > it might be considered as bug in the previous beep code Well, as mentioned, the only thing I'm really concerned is that the registration/free is done so easily via a mixer switch. A mixer switch is very often and carelessly changed by a joe user, intentionally or unintentionally. Thus, doing registration/free that can involve with the the other layer in that level is somewhat weird. IOW, I'm fine with an additional implementation for the dynamic beep on/off. But, the mixer interface doesn't look like the best interface to me. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel