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. 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. Jaroslav ----- Jaroslav Kysela <perex@xxxxxxxx> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
