At Mon, 16 Nov 2009 10:20:08 +0100 (CET), Jaroslav Kysela wrote: > > On Thu, 12 Nov 2009, Takashi Iwai wrote: > > > At Thu, 12 Nov 2009 12:44:17 +0100 (CET), > > Jaroslav Kysela wrote: > >> > >> On Thu, 12 Nov 2009, Takashi Iwai wrote: > >> > >>> At Thu, 12 Nov 2009 12:24:27 +0100 (CET), > >>> Jaroslav Kysela wrote: > >>>> > >>>> On Thu, 12 Nov 2009, Takashi Iwai wrote: > >>>> > >>>>> At Thu, 12 Nov 2009 12:06:57 +0100 (CET), > >>>>> Jaroslav Kysela wrote: > >>>>>> > >>>>>> On Thu, 12 Nov 2009, Takashi Iwai wrote: > >>>>>> > >>>>>>> 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. > >>>>>> > >>>>>> I would prefer something which is comfortable for user. The module > >>>>>> parameter or sysfs file is not a good way to explain users how they can > >>>>>> change the beep behaviour. > >>>>> > >>>>> A module parameter would be easy enough for most users who really care > >>>>> things like beep :) > >>>> > >>>> Nope. You expect that all users knows how to change module parameters. I'm > >>>> sorry, but I'm lazy to explain in bugzilla many times, how to change the > >>>> kernel module parameter (it's enough to explain model= for HDA). But 'turn > >>>> off "Beep" in alsamixer or any ALSA-aware mixer app' is quite shorther and > >>>> intuitive. > >>> > >>> But because of this "easy-to-use", the switch can be soo easily > >>> changed unintentionally. So, we are speaking roughly the same thing > >>> of both good and bad sides. > >>> > >>> And here I'm more concerned about the bad side than the good side. > >> > >> Ok, take another look: > >> > >> If you have an USB input device (mouse for example), how you can force the > >> user to not plug in / plug out the device to USB port? > > > > This is a different issue. It's the physical connection, and the system > > explicitly allows the hotplugging. > > > > Or, a different aspect: suppose you don't want to use USB mouse but > > only PS/2 mouse. How would you suggest? You blame kernel or X that > > it doesn't provide the one-click solution to suppress the USB mouse? > > > >> With my latest > >> change postponing the input device unregistration, the code is quite > >> robust and even keyboard repeat should not make much hassle, because the > >> input device will not be quickly unregistered in this case. > > > > I see it but still I'm not convinced by this dynamic registration. > > The input layer registration is escalated to sysfs, which is parsed by > > udev, whatever... It's no more only the thing inside the kernel. > > Almost all users won't touch the control switch after initial setup. But, the problem is that it can happen even unintentionally so easily. Nevertheless... > I added module parameter beep_mode to snd-hda-intel which allows to > specify all three modes (always unregistered, always registered, dynamic). > Default is "always registered" as in previous implementation. > > ALSA: hda - add beep_mode module parameter > http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=cffb566ba294a2593f932b7b7b12fb386ac161f4 > > It's a compromise to allow selection of accepted behaviour from user. > > other HDA beep patches: > > [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 > > Please, add these four patches to your tree. OK, looks like a good compromise. I applied all patches, and added a description to ALSA-Configuration.txt. Thanks! Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
