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=cffb566ba294a2...
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