I've edited the description to try to give a better overview of our current understanding of the various problems in this bug. Please add anything I left out.
Also, I nominated this for Lucid because, hey, why not? ** Description changed: - In a fully up-to-date AMD64 Karmic on an MSI MS-7511 aka a K9N2G Neo-FD motherboard - (2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux): + Between Jaunty and Karmic, a number of changes were made to keep the PC + speaker from beeping. As part of this, system bell events are now + captured by metacity, which uses libcanberra to play a sound. For users + without speakers, this fails to be useful. The current setup makes + restoring the old behavior extremely difficult. - I -know- my hardware works, but I cannot get the motherboard-based - system beep to work at all. I also know that lots of effort was - expended in Karmic to silence the motherboard beep, but it went - overboard---it is now apparently broken completely, and some of us need - it. (This machine almost never has any speakers plugged into it---I - depend absolutely on the onboard system beep to work, so don't waste - your breath if your advice is to "just" use the audio-out jack and - externally-powered speakers---this is absolutely a regression!) + The absolute show stopper is that metacity traps audible system bell + events. This behavior is, as best we can tell, not configurable. The + attached patch keeps metacity from capturing system bell events. It + also removes the sound playback capability. As Lucid will be using + pulse audio's module-x11-bell to play sounds for system bell events, it + is not necessary for this capability to be in metacity. Additionally, + this removes the discrepancy between metacity's and compiz's handling of + system bell events. - My test cases: both in and outside of X (e.g., booted normally, or - booted directly into single-user mode): echo -e '\a' in bash, or echo - -n '\007' in tcsh, or ^G in Emacs, or Rubout at an empty line in gnome- - terminal and/or the X-less shell. Nothing. + There are several other difficulties in enabling the system bell: + 1) Even if it is taken out of the blacklist, the pcspkr module may not load properly. Another modprobe may be necessary to get it loaded. See bug #398161. + 2) Something in Gnome's startup does the equivalent of `xset b off`, so `xset b on` must be run on every login. (Note that bug #280767 keeps you from setting the bell volume with xset.) + 3) A number of settings in gnome-terminal and gconf may keep the shell from sounding system bell events. - I -know- this hardware works: - (a) Tried booting from a 6.06 LiveCD. All of the above tests work just fine. - (b) Installed "beep" with synaptic. Beep itself works (showing that my hardware is good -and- that the kernel can talk to it), although apparently event0 isn't where my internal speaker is---I have to use beep -e /dev/input/by-path/platform-pcspkr-event-spkr and -then- the command beeps. (That's actually a symlink to event5 for some reason on this motherboard. - - Here are all the things I did to try to fix this; what's left? (This is - not necessarily the exact order I tried things in, and there were - multiple logouts and/or reboots to make sure old values weren't cached - and that new values were sticking.) - - Commented-out the blacklisting of pcskpr in - /etc/modprobe.d/blacklist.conf and did modprobe pcspkr. lsmod shows - pcspkr there, and a reboot shows it still there. - - Went into alsamixer, raised Beep to 100%, and unmuted it. - - Made sure that "Terminal bell" in the profile for my gnome-terminal is - checked. (Also tried unchecking it, from a report elsewhere that claimed - the checkbox worked backwards from appearances.) - - Did xset q and noticed that the bell percent was 0. Did xset b 100 and - now it's at 100. - - Tried xset b 100 1000 100 to change the default pitch from 400 to 1000; - no effect. - - Did sudo gconf-editor and drilled down to desktop -> gnome -> - peripherals -> keyboard and changed bell_mode from off to on. - - (Jeez, how many different places did they stab at to try kill the bell?) - - I've also read through about a dozen threads on launchpad where people - were complaining about how to turn the bell -off-, as well as - http://ubuntuforums.org/tags.php?tag=bell. - - I'm suspicious that beep required an explicit path because event0 wasn't - the bell---could this lead to any of these symptoms? - - It's obvious (since it doesn't work in single-user mode either) that X - or Gnome or gnome-terminal aren't implicated, but I'd tried all of those - before just trying single-user. And, of course, the 6.06 LiveCD shows - this is absolutely a regression---if a 3.5-year-old release works just - fine on this 1-year-old hardware, I'd expect the current one to do so as - well. - - Alternatively---is there any way of forcing "beep -e /dev/...." to be - called in all instances when the system would otherwise be trying to use - the system bell, e.g., when backspacing to empty lines, when echo or - Emacs want to emit ^G, etc etc? That would be a gross kluge, but at - least it would leave me with a bell that worked in most of the cases I - care about... + Comments #28, #34, and #50 give more detailed summaries of the various + problems. -- System beep broken in Karmic despite heroic efforts to fix it https://bugs.launchpad.net/bugs/486154 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
