[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Wontfix. ** Changed in: metacity (Ubuntu) Status: Triaged => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it To manage notifications about this bug go to: https://bugs.launchpad.net/metacity/+bug/486154/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: linux-lts-xenial (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it To manage notifications about this bug go to: https://bugs.launchpad.net/metacity/+bug/486154/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Okay, I submitted bug #1599599 for the same problem on Ubuntu 16.04 Xenial Xerus. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1599599 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it To manage notifications about this bug go to: https://bugs.launchpad.net/metacity/+bug/486154/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
** Also affects: linux-lts-xenial (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it To manage notifications about this bug go to: https://bugs.launchpad.net/metacity/+bug/486154/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Hi all, It is six years later and this exact problem is back with Ubuntu 16.04 Xenial Xerus. I unblacklisted pcspkr and loaded the module, plus the overwhelming multitude of other steps. The "beep" command works and "echo blahblah | wall" also works, "but echo -e '\a'" and "printf '\a'" do nothing, nor does the rubout or other keys in terminal and Gedit. I've never submitted a bug before, but I'll try now and reference this bug so we can benefit from all your hard work. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it To manage notifications about this bug go to: https://bugs.launchpad.net/metacity/+bug/486154/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
I am on Lubuntu 12.04 and beep isn't working for me, so I am not getting notifies on highlights from WeeChat with beep script. I have 1. removed pcspkr from modprobe blacklist 2. modprobed pcspkr 3. rebooted 4. ensured that beep isn't muted in alsamixer 5. I have ran "xset b on" multiple times and have it on my shellrc. What else should I do? I am using urxvt. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it To manage notifications about this bug go to: https://bugs.launchpad.net/metacity/+bug/486154/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
On 04/17/2012 01:57 PM, John Vivirito wrote: > This is a problem again. it was working until last week or so. I > reinstalled than updated and it stopped working, anything i can do to > help with this? Your first step should be to determine if this bug is your problem or not. This bug is specifically about the system bell under the Metacity window manager. If you're using Compiz (or Unity 3D), see bug #769314. But in either case, you're pretty much SOL. Nobody seems to want to even acknowledge that this is a problem, much less think about how to solve it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it To manage notifications about this bug go to: https://bugs.launchpad.net/metacity/+bug/486154/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
This is a problem again. it was working until last week or so. I reinstalled than updated and it stopped working, anything i can do to help with this? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it To manage notifications about this bug go to: https://bugs.launchpad.net/metacity/+bug/486154/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
> the system bell should work in metacity without issue Well, except for the issue that we've spent 18 months and 89 comments discussing: You can't turn off the libcanberra bell handling without patching Metacity. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
In a default natty install, the system bell should work in metacity without issue, i.e a system bell is triggered, and metacity calls libcanberra functions to play the system bell sound event. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Thomas, Pete: Problems with the system bell are subtle and strongly dependent on what exactly you are trying to do. One of these factors is the window manager. This bug is primarily focused on getting the system bell working under Metacity. gconf twiddling *may* be necessary in this case; Pulse Audio commands will do nothing. If you are trying to get the system bell working under Compiz or Unity, please see bug #769314. I would have thought the simple fact that the system bell depends on window manager would be enough to convince people that the whole system needs a re-think, but apparently not. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Pete, thanks for the information. To summarize what I now know There are several separate issues. One is the traditional square-wave beep function. Many people say that it is necessary to: * Un-blacklist the pcspkr kernel module and load it. However, I have just discovered that this module is not needed on a Lenovo ThinkPad X61 for "echo 3 > /proc/acpi/ibm/beep" to work. The latter requires only the thinkpad-acpi module. Orthogonal to that issue is getting terminal and other bells to play in the new way, via X, the window manager and pulseaudio. For the terminal bell to ring, it is still necessary to: * enable "Terminal|Edit|Profile Preferences|General|Terminal bell" * set gconf setting "desktop|gnome|peripherals|keyboard|bell_mode" to "on". Under natty compiz then the gconf setting "apps | metacity | general | audible_bell" makes no difference. Before receiving the tip from Pete Ashdown I was re-enabling the compiz-managed newfangled audible bell by deselecting and selecting System Settings|CompizConfig Settings Manager|General|Audible Bell. This actually enabled the traditional square-wave bell! But now I see that * pactl upload-sample /usr/share/sounds/gnome/default/alerts/glass.ogg bell.ogg suffices to enable the newfangled bell. After logging out and in the bell was still enabled without my having to run xset, but I can imagine it may be necessary to run * xset b on * xset b 100 under some circumstances. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Thomas, I don't think you need to run gconf-editor at all. This is what does it for me on Natty 11.04: /usr/bin/pactl remove-sample bell.ogg /usr/bin/pactl upload-sample /usr/share/sounds/gnome/default/alerts/glass.ogg bell.ogg /usr/bin/xset b on /usr/bin/xset b 100 Plug this into a session startup script. Of course it doesn't fix the problem that changing the sound of the bell via "System -> Preferences -> Sound Preferences" has no effect. I can't understand why this continues to be an issue in Ubuntu. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
I've filed another bug about problems with the system bell in Unity (#769314). Basically those problems are the same as in Compiz discussed here. So let's talk about Compiz problems over there and keep the Metacity discussion here. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
We shouldn't depend on upstream fixing this by removing behavior that upstream regards as a feature. It would be nice if upstream made their feature easier to disable. But we shouldn't wait for them to do that, either, before fixing the problem in Ubuntu. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Addendum. Even after doing what I just described (above, reply #81), I find that after reboot sometimes beeping doesn't work until I switch window managers between metacity and compiz. :/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
To re-enable the terminal bell on my ThinkPad X61 running Ubuntu 10.10 I took the following actions suggested above: * Un-blacklist pcspkr as described above, then either reboot or modprobe pcspkr. * On the terminal window, tick "Edit | Profile Preferences | General | Terminal bell" * Run gconf-editor and at "apps | metacity | general" tick audible_bell. * Run gconf-editor and at "desktop | gnome | peripherals | keyboard" change "bell_mode" from "off" to "on". * Use the alsamixer program to unmute and raise Beep volume to a suitably high level. * Do pactl upload-sample /usr/share/sounds/ubuntu/stereo/bell.ogg bell.ogg Many thanks to the contributors to this bug report! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
I'm the original reporter of this bug thread. I have to say, I'm completely dissatisfied so far. Every proposal has been to effectively kick this downrange and make it someone else's problem, and I'm -particularly- unhappy that this is viewed as a window manager issue! It means the (a) behavior will change for every different window manager, (b) if I'm not running a window manager, like I'm in single-user mode or a server, I don't -get- a bell???, and (c) it seems to imply that a -brand new protocol- must be written and all the WM's and apps much understand that protocol? What??? It's not as if just -reverting- the ill-advised changes that broke the bell literally -years- ago now are getting any developer attention, and now you propose that someone actually has to write something -new- to get this fixed? How likely, exactly, is this likely to happen, given that this issue has now been open for about 18 months now---three entire release cycles, and obviously not going to be fixed for Natty, so that means 4 cycles, minimum, or two years. Kicking it to a WM also has a vey bad precedent---I reported a similar "this just needs to be reverted" ONE-LINE reversion about libwnck literally -6 years- ago and which, after -2 years-, the developer actually agreed -should- be reverted---and then it has sat, for -4 more years-, unreverted. So I can't say that anything whose resolution is "get the metacity developers to revert this" fills me with glee---my experience so far is that even things they agree about take literally years to see any action. (I'm talking about https://bugzilla.gnome.org/show_bug.cgi?id=171804 here.) (Surprisingly, about a month ago, it suddenly had some activity on the bug thread. Maybe it'll get fixed. Maybe. From my outsider's perspective, just looking at that bug thread, it looks like what had to happen is that the original developer simply vanished for years and a couple of people took over in his stead. Is that what's going to have to happen to get the bell fixed, too?) So add me to the grumpy crowd that thinks the original change in behavior was misguided, who think that taking 18 months to get to this point is way, -way- too long, who disagree that the fix is to continue to make this the responsibility of the window manager -at all-, and who wish nobody had ever broken this in the first place---and who cannot FIX the issue ourselves. All we can do is continue to patch around it on every release, because a fix must be committed by those who own this code, and that's not us. ** Bug watch added: GNOME Bug Tracker #171804 https://bugzilla.gnome.org/show_bug.cgi?id=171804 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Two non-reporter comments, including none from metacity developers, over 13 months may be called many things, but I wouldn't call it "being discussed." Let's be honest - upstream is not fixing this bug. Ubuntu is apparently not fixing this bug. Let's stop misleading people into thinking this will be fixed and mark this as "wontfix" or "dontgiveadamn" or whatever Launchpad's equivalent is. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Being discussed in the upstream bug (where it should be applied first), unassigning. ** Changed in: metacity (Ubuntu) Assignee: Canonical Desktop Team (canonical-desktop-team) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
I think until this is fixed in a sensible way upstream, there isn't a safe way to backport fixes to earlier releases. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Thanks for the patches and the discussion on this. Can someone from the Ubuntu Desktop team follow this patch through to the end? ** Changed in: libcanberra (Ubuntu) Status: New => Invalid ** Changed in: metacity (Ubuntu) Assignee: (unassigned) => Canonical Desktop Team (canonical-desktop-team) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/486154 Title: System beep broken in Karmic despite heroic efforts to fix it -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
>Is there something I'm missing that makes having the window managers be responsible for the system bell so attractive? And >regardless, should the discussion continue here or in a new bug for "Coherent handling of the system bell"? I think the latter is important, especially on servers that have audio but no window manager. All too often the response to an intelligently set system-bell is "I hate the system bell! How do I turn it off?!?!?" That isn't the point. There are people (myself included) who need a non-obnoxious system-bell to notify them of activity outside their focus. Does pcspkr only play one waveform? I had more control of my Apple ]['s speaker than I do pcspkr. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Michael and Chris, thanks for taking a look at this. But I still don't understand why the system bell should be tied to the window manager. It seems to me a strange connection that leads to silly bugs like #430203. IMHO, the obvious solution is to let Pulse Audio handle the beep and leave the window managers out of it. Here's my reasoning: - Just getting the basics of the proposed libcanberra solution requires writing new code in libcanberra and compiz. In contrast, the basics are already completely implemented in Pulse Audio; we just need to excise some code from metacity. - The libcanberra solution would require the same code in Metacity and Compiz (and gnome-shell and Unity, presumably). Each would have to be kept consistent with the library. This is not a worry with Pulse Audio. - I don't know how configuration with libcanberra would work, but it would require some sort of coordination for settings to survive changes in window managers. Pulse Audio keeps running though window manager changes. - Pulse Audio is a more obvious place for people with audio bugs to start looking. With Pulse Audio, there is still significant work to be done. Besides patching metacity, Pulse Audio's startup should be altered to make the loading of module-x11-bell optional and to load the appropriate bell sound. Additionally, gnome-volume-control would need it's system bell options rewritten to use Pulse Audio. Is there something I'm missing that makes having the window managers be responsible for the system bell so attractive? And regardless, should the discussion continue here or in a new bug for "Coherent handling of the system bell"? -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
The patch looks sane to me (and I've mentioned as much on the upstream bug), but as you've noted it will need some system-integration work to avoid regressions for the people who want their bell to ding rather than PC bleep. To that end, I brought this up with Luke Yelavich (the main Ubuntu audio guy, TheMuso in #ubuntu-desktop): ... RAOF: As for audio this cycle, well I am not entirely sure. I think rodrigo_ is helping out some, and I am spending a little time on bits and pieces here and there, usually package updates, but thats about as far as I know. RAOF: IMO PC speaker stuff is disabled and should stay that way, and libcanberra is responsible for sound events. So the correct way to proceed would be to teach libcanberra to optionally use the PC speaker, and teach compiz to use libcanberra? I'd say thats probably the best bet. ... It would seem to be fairly easy to patch libcanberra to do this, and probably similarly easy to patch compiz to use libcanberra. Luke (TheMuso on Ubuntu IRC, https://launchpad.net/~themuso has email addresses) would be the person to talk to about this design. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Thanks a lot Robert for looking into this problem and for your patch. I do not feel comfortable enough with the code to judge if that will not have regresions. It would be great if upstream would comment. I noticed that you forward it to the gnome bugzilla (thanks for this). But it looks like upstream is silent on this matter :/ -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
This will load the bell.ogg sample for pulseaudio. My guess is that there is some disconnect between the alert settings in "Sound Preferences" and actually doing the load in gnome. /usr/bin/pactl upload-sample /usr/share/sounds/gnome/default/alerts/glass.ogg bell.ogg -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
On 10/11/2010 11:58 AM, Thomas Troesch wrote: > When I get the system bell, I have no control over the volume, and the > duration parameter 'beeps' twice as long as xset q would indicate. Is > this the same behavior you are getting? I suspect that this may be related to bug #280767. I've noticed similar problems on my systems, but haven't been bothered to work on them. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Thank you all for your incredible effort. I have had success with the instructions in these comments. The system bell is very important for me as well. I have scripts and programs that run when the user is not sitting at the computer or even looking at it, and in a relatively noisy environment. A bell with volume and without lag or rate adjustment is essential for me. When I get the system bell, I have no control over the volume, and the duration parameter 'beeps' twice as long as xset q would indicate. Is this the same behavior you are getting? Karmic cat /proc/version -> Linux version 2.6.31-22-generic (bui...@allspice) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) ) #65-Ubuntu SMP Thu Sep 16 16:21:34 UTC 2010 -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Nic, thanks for figuring out that Pulse Audio was the thing breaking the bell in Compiz. I couldn't believe that I should have to restart Compiz to restore the bell, and you showed that I don't. Armed with this knowledge, I went looking around for where Pulse Audio loads its modules. The X11 ones seem to be loaded in the script '/usr/bin/start-pulseaudio-x11'. The modules and their options are hardcoded (!) here, so I commented out the line mentioning 'module-x11-bell'. Now, the bell beeps appropriately as soon as Compiz starts. (I've not had the problem in bug #398161.) Hooray! But this doesn't help us with Metacity. The problem there is that Metacity itself is catching bell events and playing sounds itself. There's no way to turn this off short of patching Metacity. I've submitted such patches everywhere I can, and nobody seems to care. While I'm here, I want to correct two mistakes I made in my previous post. At that point, I was having problems with my video card and window managers were often crashing, so often both Metacity and Compiz had been run in a session. Now that that's fixed and I can run Compiz from session start, I note: 1) The X bell volume (as reported by 'xset q') is 50. Metacity must have been messing with this. 2) There are NO samples loaded into Pulse Audio. This (not a mis-naming) is why the Pulse Audio bell doesn't work by default. Presumably if you wanted the Pulse Audio bell instead of the PC speaker beep you could leave the loading of module-x11-bell in /usr/bin/start-pulseaudio-x11 and add a line that loads an appropriate sample, given the name bell.ogg. But I haven't tested this, because having gotten things working, I'm not messing them up again! -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Having struggled with this for ages, just thought I'd post the (extremely hacky!) workaround which finally got the system bell working normally for me, in case it's of any help to anyone. This is for Lucid. There were two issues for me: first, the fact that the pcspkr kernel module (when removed from blacklist) loads too early and hence fails to do anything, as Grondr points out above. Second, the window manager's "audible bell" setting (Compiz in my case - I haven't checked, but it may be the same for metacity) appears to be overruled by pulseaudio's attempt to capture system bells and replace them with a sampled sound (using module-x11-bell), such that these settings in gconf-editor, etc., don't actually do anything. For love nor money, I can't stop pulseaudio from doing this, but have at least discovered that the window manager's "audible bell" setting DOES take effect if it is applied AFTER pulseaudio has finished doing its thing. With Compiz, for example, this means that toggling 'General Options' -> 'Audible bell' in CCSM (System -> Preferences -> CompizConfig Settings Manager) off and then back on again restores normal bell behaviour! Doing this manually after every boot is predictably annoying, but fortunately it can be scripted. For simplicity, I've put the workarounds for both bugs into the same executable script, ~/bin/sysbell_hacks, and added it to "Startup Applications" so that it runs as Gnome loads, after login. Here's the script: """ #!/bin/bash # Make sure gnome and pulseaudio have finished loading sleep 30s # pcspkr kernel module insertion bug: remove (if not blacklisted) and reinsert the module sudo modprobe -r pcspkr sudo modprobe pcspkr # window manager setting override hack: toggle the audible_bell flag gconftool-2 --set "/apps/compiz/general/allscreens/options/audible_bell" --type bool "false" sleep 1s gconftool-2 --set "/apps/compiz/general/allscreens/options/audible_bell" --type bool "true" """ As I said... hacky. This works (at least for me...) with compiz, but on the off-chance that something similar is happening with metacity, its users might just try replacing the compiz setting in the script above with "/apps/metacity/general/audible_bell", in both of the gconftool-2 commands. No promises! :) -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
** Changed in: metacity Importance: Unknown => Medium -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
A week ago I wrote about un-blacklisting the module. But even with the pcspkr module loaded (lsmod shows it), most of the time there's no beep, either in or out of X. The pcspkr module seems very flaky in Ubuntu kernels. I've never figured out why; if I build my own kernel, pcspkr works fine, whether it's a module or built in. Thought it was fixed in Lucid because it worked once, but I've never gotten it to work again since then. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Update for Lucid, for which I'm sure everyone has been waiting with bated breath. pcspkr is still blacklisted. See the above comment for details. Metacity behaves the same way as it did in Karmic, trapping all system bell events and using it's own playback capabilities. This is despite the fact that module-x11-bell is loaded by default now. Someone should write a patch for Metacity that would fix that. Oh, wait. Compiz still doesn't handle system bell events, but now Pulse Audio is set up to handle them, so we get nice-sounding bells in Compiz. At least we would, if the Pulse Audio setup weren't completely broken. In two separate ways: 1) Pulse Audio's module-x11-bell respects the X bell volume, which Gnome sets to 0 somewhere in its startup sequence. (Metacity, of course, ignores this setting. If it isn't in GConf, it doesn't exist.) This was presumably done to shut off the PC speaker beep, but this isn't needed anymore. The volume must be turned up before you could hear anything (`xset b on` or `xset b `). 2) As loaded by default, module-x11-bell points to the sample bell.ogg, which doesn't exist! You must either load the sample (`pactl upload-sample /usr/share/sounds/ubuntu/stereo/bell.ogg bell.ogg`) or reload the module with the sample name correctly set (`pactl unload-module ; pactl load-module module-x11-bell display=:0.0 sample=bell-window-system`). Now that it's working, you must realize the Gnome's Sound Preferences dialog, which assumes Metacity is running, no longer adjusts the beep sound. (Curiously, the mute button does work.) But what we REALLY want isn't this high-falutin' boink sound -- we want the PC speaker beep back! When I check previously in the VM, Lucid's Metacity could be patched in the same way Karmic's could. I haven't tried this on my actual machine, as Metacity keeps crashing on me (!?!). But under Compiz, all you should have to do is load the pcspkr module, use `xset b on` to turn up the volume, and unload the module-x11-bell module from Pulse Audio. This turns out not to work -- you also need to start a new instance of Compiz, using `compiz --replace` i.e., for reasons I can't begin to fathom. This all probably warrants a new bug (or 12). But maybe I'll wait for Maverick, which promises to bring us two new window managers and a whole host of ill-considered mis-configurations. I hope you're all as excited about this as I! -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
A lot of the discussion in this bug has to do with metacity and pulse, but for people who don't use gnome, metacity, pulse or any of that stuff, and just want their pcspkr module to beep when asked under lucid, I just posted a blog article: http://shallowsky.com/blog/linux/kernel/pcspkr-lucid.html Basically, I had to un-blacklist it in two places, /etc/modprobe.d/blacklist.conf and by removing the obsolete /etc/modprobe.d/00local that some earlier ubuntu version had put there and upgrades never removed. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
** Changed in: metacity (Ubuntu) Status: Confirmed => Triaged -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
** Changed in: metacity Status: Unknown => New -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
This was probably unspeakably gauche of me, but I removed the -needswork tag until someone can explain to me why we would want metacity mucking about with the audible system bell events. This bug (and system bell events in general) obviously does still need work, but I just don't see what more is desired for the patch to metacity. ** Tags added: patch ** Tags removed: patch-needswork -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Dmitrijs, metacity is categorised as desktop, as indeed is audio in general - I don't see anything here for the foundations team. I've subscribed canonical-desktop-team and unsubscribed canonical- foundations. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Just to confirm my previous assertion, I installed the Lucid beta on a virtual machine. I applied my patch [1], restarted metacity, and unloaded and reloaded Pulse Audio's module-x11-bell [2]. System bells rang the same bell.ogg sound file, but through Pulse Audio. Additionally, I could now set the volume with `xset b`. Thus, using this patch would result in the *exact same* behavior as currently exists, except that Pulse Audio is making the noise instead of metacity. Stopping the behavior, to reenable to PC speaker, is now just a matter of unloading the module. Additionally, there are fringe benefits: 1) No delay while metacity loads the sample the first time it's needed. 2) No rate limiting of playback by metacity. 3) Consistent handling of system bell events between metacity and compiz. Honestly, what more is desired? In several bugs related to this, I have yet to hear a good explanation for why metacity should be handling system bell events. Here's a chance to switch this capability to a more sensible sub-system and solve several bugs or potential bugs all at once. Why are we not jumping all over this? (Sorry to sound shrill, but I'm rather frustrated at this point.) [1] It didn't quite apply cleanly, but it was easy enough to clean up by hand. I wasn't planning on posting a new patch for Lucid, but if it's desired, let me know. [2] I don't know why un- and re-loading the module-x11-bell was necessary, but I suspect that it's related to the fact that the old metacity had been trapping the system bell events. I suspect, but haven't confirmed, that this won't be necessary once the new metacity is installed and X is restarted. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Dmitrijs Ledkovs wrote: > I'm part of Ubuntu Reviewers team. Your patch is good to brute-force > revert the change but what about people who want both options and switch > between the two behavior? As discussed in this long bug report it's not > possible yet due to many issues raised and the patch doesn't bring > configurable behavior. The correct way to allow configuration, IMHO, is to use Pulse Audio's module-x11-bell. It can be turned on and off at will just by loading and unloading that module. module-x11-bell is loaded *by default* in Lucid, so it's ready to be used in all it's configurable glory. But metacity traps system bell events and keeps Pulse Audio from seeing them. This patch would remove this trapping and *allow configuration* through Pulse Audio. It would also ensure that both metacity and compiz use the same system for ringing the bell. It doesn't completely solve the bug, but it gets us significantly closer. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
I'm part of Ubuntu Reviewers team. Your patch is good to brute-force revert the change but what about people who want both options and switch between the two behavior? As discussed in this long bug report it's not possible yet due to many issues raised and the patch doesn't bring configurable behavior. I've subscribed foundations team, hopefully they can work on this. Thank you for making Ubuntu better. This bug sucks indeed. ** Tags added: patch-needswork ** Tags removed: patch -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
** Tags added: patch -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
** Changed in: metacity (Ubuntu) Importance: Undecided => Medium -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Thank you thank you thank you Grondr and Robert for giving some respite to people who are suffering from this horrible bug. This problem is highly annoying to me. The initial reason for neutering the pc speaker was that besides it being "outdated" you had to grovel through 8 miles of innards to get it to be turned off. Unfortunately the solution resulted in no beep at all (so much for the "outdated" idea -- if it was outdated to have the pc speaker beep why didn't they make a configurable alert sound take over for it?). It also means you have to grovel through 8 miles of innards to get it back on again, and even then it's actually a sad string of hacks designed to turn it back on after the bits put in by the bell-killers turn it off. When I first ran into this, I thought it was a resurrection of an xterm bug (in version 242, here: http://invisible-island.net/xterm/xterm.log.html#xterm_243 )that had plagued me in cygwin (which required me to recompile xterm for that platform), but no such luck. By the way, two whole other sets of directions regarding the bell in ubuntu are here http://ubuntuforums.org/showthread.php?t=1377990 and here http://ubuntuforums.org/showthread.php?t=1377990 I've done everything in the Grondr's comment except for patching metacity, and everything in those two forum threads except for the bit about changing the bell sound. What I don't like is that I have to remember to do xset b 100 every time I boot up because even though it's in my .xinitrc it doesn't happen. I've put it in my .profile, but that is a hack, and I still haven't rebooted yet to see if that will be sufficient. I should be able to configure the x bell with respect to x, using its init files. What I have not explored yet, is the probability that the bell is still neutered with respect to the computer's state before X is launched, and regular consoles. Console beeps should work, or at least be configurable in some way. What would be nice is if you could easily set this without having to grovel through all these places, and whatever you did to do it would undo the things that were done to neuter the bell rather than reacting to them. What would be even nicer is if you could set the bell sound, too. It appears that you can, if you dig deep enough, but at this stage I'm still trying to make sure I have the bell turned on in enough places, and I find more places that it is not and more places where my settings are ignored every day. Applications that don't speak to sound mixers should be allowed to produce pc speaker beeps, as should the kernel itself. If we are going to try to intercept that, it should be in a way that ensures it will still work, and make both the interception and what we do with it configurable. Likewise, errors made in gui apps and other apps that can speak to the sound mixer should have a configurable sound. I hope that anyone who is affected by this finds a solution that works for them. Expect to have to wrestle it awhile, and to have a frustrating time going through all these places. I did get my beep to work, I just have to keep turning it back on, and I still worry that there are situations in which the beep is still not happening when it should. If we could find all the places where the bell was neutered and how, maybe we could make a better solution for undoing it or produce patches that either make it configurable or turn it on again. Ubuntu being what it is, maybe gui configuration is the way to go. But whatever we do needs to be compatible with legacy applications. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Robert, I think that you have gone above and beyond at this point. At least at this point, the maintainers can try out your patches and take a good look at them to see if they want to integrate it. The best bug reports are the ones with patches! Thank you for making Ubuntu better! -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
** Branch linked: lp:~rschroll/metacity/system-bell -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
I've created a branch of metacity with the changes from the attached patch, and requested a merge with master, as that seems to be what I was supposed to do (https://wiki.ubuntu.com/SponsorshipProcess). For purposes of cross-referencing, here's the merge request: https://edge.launchpad.net/~rschroll/metacity/system-bell/+merge/18357 I've additionally subscribed ubuntu-main-sponsors to this bug. The wiki page on the sponsorship process was unclear as to whether I was supposed to do this in addition to requesting a merge or not. Given the lack of attention so far, I figured it couldn't hurt. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Since there's been no action from the Ubuntu maintainers on this, I finally got around to reporting this upstream: https://bugzilla.gnome.org/show_bug.cgi?id=607906 Please take a look and add anything that I forgot. ** Bug watch added: GNOME Bug Tracker #607906 https://bugzilla.gnome.org/show_bug.cgi?id=607906 ** Also affects: metacity via https://bugzilla.gnome.org/show_bug.cgi?id=607906 Importance: Unknown Status: Unknown -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
I have flagged down Daniel Chen to take another look at this report, however it is quite low on his priority list and he probably has not looked at it yet. I'll see if I can get someone else to at least mark it as "Triaged". -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Yes, I agree re part 3---safer to leave it in as long as metacity claims responsibility. (But it has no business claiming responsibility---leave that to PulseAudio.) We haven't heard yet about getting this bug punted to the metacity folks, so it may be time take more direct action in letting them know about it... -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
> Confirmed---your patch fixes the issue. Good to hear! > Strictly speaking, I don't think you need part 3 of your patch I this is correct. Part 3 only re-enables the gconf /apps/metacity/general/audible_bell key to turn the bell on and off. Whether metacity *should* have a key to do this, I don't know. But given that it *does* have this key, I think we ought to make it work. Also, I suspect that, without change #3, if this key is set to false when metacity starts, metacity will trap audible bells irrevocably. (I suspect meta_prefs_bell_is_audible() will return False, causing the last argument of XkbChangeEnabledControls() to be 0, which we know will trap the audible bells. But at this point, I don't feel like risking breaking things again to check this hunch.) > I suspect somebody should open a bug upstream, I was going to wait a few days to see if WeatherGod can scare up someone from Ubuntu to comment on this patch. I suspect that we'd get a better reception from the Metacity people if we can show this is desired by the Ubuntu project, rather than just a few random cranky users. But it anyone feels like taking the initiative and posting this to metacity's bug tracker before I do, please be my guest! -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Okay, for anyone who's trying to restore the pre-Karmic behavior of beeping, here's what to do. It will give you old-style motherboard beeps when you hit rubout at an empty shell prompt in gnome-terminal or at an empty password prompt during gdm login; it will make xkbbell work; all rate-limiting of bells will be disabled; and bells will be emitted instantly, and not after a sluggish wait of up to a second. INSTALL PATCH: (a) [sudo] apt-get build-dep metacity (b) apt-get source metacity; cd metacity-2.28.0 (c) Apply the patch or hand-edit src/core/bell.c (d) [sudo] debchange -v 1:2.28.0-0ubuntu1+dontstealbell "Don't steal X bell events." [Note 0] (e) [sudo] debuild -rfakeroot binary; dpkg -i ../*.deb; killall metacity (f) metacity & in any shell on your X server screen [-not- via ssh from somewhere else!] metacity runs as you, not root. FIX DEFAULTS: (a) alsamixer; raise Beep to 100%; unmute. [Apparently unnecessary for motherboard beeping, but if you want anything -else- to beep later using PulseAudio or by playing bell.ogg or whatever, you'll probably have to do this. Safer just to raise it now.] Make sure your Master is also up and unmuted, but it presumably is or you'd never hear anything at all. (b) Edit profile(s) in gnome-terminal and ensure that "Terminal bell" is checked. (c) gconf-editor: desktop -> gnome -> peripherals -> keyboard. Change "bell_mode" from off to on. (d) gconf-editor: apps -> metacity -> general. Change "audible_bell" from off to on. ON EVERY BOOT: (a) [sudo] modprobe pcspkr [put this in rc.local or somesuch] [Note 1] [Note 2] ON EVERY LOGIN OR GDM RESTART: (a) xset b [Note 3] [Note 4] [Note 0] This will keep your private version of this from being overwritten if a newer version is released. Of course, if a newer version is released that fixes this bug, do "debchange -v 1:2.28.0-0ubuntu1" to declare that what's installed is what used to be installed (this won't -actually- change what's installed) and then update (which will then update it). [Note 1] If you want the squarewave bell to come out of line-out and not the motherboard beeper, don't bother doing this. [Note 2] It does -not- work to just comment-out the blacklisting of pcspkr in /etc/modprobe.d/blacklist.conf and reboot; this is because Karmic appears to load this kernel module too early for it to take effect, so you have to wait until the kernel's done loading things and then rmmod it and modprobe it again. Easier (until this bug is fixed) to just leave it blacklisted and just modprobe it in rc.local or in any other init that runs near the end of boot. [Bug #398161] [Note 3] Every time gdm is restarted, -something- does the equivalent of "xset b 0". (I'd really like to find the guilty party.) [Note 4] Note also that, due to -another- bug, "xset b 100" does -not- make the volume 100%---instead, it increases the bell -duration-! So "xset b" is a reasonable compromise: it sets the so-called bell volume to 50% and an acceptable duration. [Bug #280767] P.S. Even once all the actual -bugs- are fixed, I consider the sheer number of places that must be hit to make bells work---e.g., for a rubout at a shell prompt to warn you, or for Emacs to be able to -say- something when you ^G or it gets an error---to be (at least!) a documentation bug, and (really) evidence of poor design. There should not be so many fingers in the pie here. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Oh btw, someone else will to have to verify if the patch is well-formed; I applied it by hand, since I was poking around to verify each piece. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Confirmed---your patch fixes the issue. Now I can migrate to Karmic without going mad. (I'll make a post showing all the extant bugs & what fixes them, since this is but one part of all the bell lossage we've discovered, but this is certainly the most-annoying one and the one that got us started... :) And I -absolutely- agree that it's PulseAudio's job to be screwing around with the bell! It's documented, it's configurable, and it'll work with -all- PA-capable window managers, rather than metacity being a weird special case. Pity that this bug started out (see title bar, etc) with my guess that it was PA and not metacity; oh well. Strictly speaking, I don't think you need part 3 of your patch---I tried tests using the various pieces of it in isolation, and it looks like the bell will be audible even if the #ifdef is replaced by HAVE_XKB_NOPE or some other thing that keeps it commented-out. However, it can't hurt, and it may allow metacity to counteract similar lossage by some other window manager leaving us in a bad state. (Btw, I also made sure that sudo metacity while ssh'ed in from another host no longer stole -its- bell, either.) I'm pretty sure my testing commented out the line in #4, but I can't remember if I also tried diddling the mask correctly instead. Given that every time gdm gets restarted, the X bell volume is set to zero, it's also possible I had it right at some point but never knew it---if I'd forgotten to do xset b. And yes, your #2 is necessary---otherwise, you get the motherboard beep -and- bell.ogg played simultaneously (but the beep is not rate-limited, whereas bell.ogg is). [Or, if you haven't loaded pcspkr yet, you get a squarewave beep out the line-out port, along with bell.ogg). I note also that bell.ogg is still delayed, especially the first one after a long silence. I haven't tried out all the various weirdo permutations I did in my comment #34 (bug-characterization), but since the normal-boot-into-gdm- and-metacity case now works, I'd be very surprised if anything else was broken---things are now working like my pre-9.XX control case. Also, it looks like the "vanishing bell" problem has itself vanished; this was result (d) in my characterization (e.g., "beep" with 10-second delays would tend to emit a beep every -20- seconds). Looks like metacity was responsible for -that- bit of lossage, too. Yay! I suspect somebody should open a bug upstream, directly at metacity's bugtracker, and point them at your patch (and at this entire thread, as motivation for just what a PITA this bit of metacity behavior has been). I'm going to post a step-by-step about how to configure all the moving parts to get bells back as my next post, so somebody searching for it might win (since even with the patch, there's a lot of other stuff that has to get set correctly). -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Wow, that's... exhaustive. I'll see if I can flag someone down for you guys and see if they can help you any further. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
I think I've solved the issue of metacity grabbing audible system bell events. The attached patch contains my changes to metacity (specifically src/core/bell.c). Please give it a try and let me know if it works for you. If not, please let me know. I am a complete novice at dealing with .deb files, so it's very likely that I messed something up and produced an invalid patch. This patch keeps metacity from grabbing system bell events. As a side effect it also solves the issue of metacity rate limiting the system bell events. It does not completely solve this bug. You still need to load (and possibly reload) the pcspkr module and turn the PC speaker on. I developed this patch by reverting bits of bell.c back to the version from jaunty. Here's the reasons for the changes, identified by the old line number referenced in the diff: 1) Near line 52, I removed the #include of canberra-gtk.h, since we will no longer be using libcanberra to make bell noises. 2) Near line 281, a large chunk of code is excised. I believe all of this was for playing the bell.ogg sound through libcanberra, but I'm not entirely sure. 3) Also in that area, code was restored to keep meta_bell_set_audible() from being a no-op. The restores the ability of the gconf key /apps/metacity/general/audible_bell to turn the audible bell on and off. 4) Near line 355, the final argument of a call of XkbChangeEnabledControls() is changed. This is necessary to keep metacity from trapping the audible bell events! As an aside, note that pulse audio's module-x11-bell *can* be used to play the bell.ogg sound in place of the PC speaker beep for system bell events. Since this is much easier to change and configure, I see no reason not to use this in place of the metacity/libcanberra solution for system bell events in future versions. ** Attachment added: "Keep metacity from grabbing audible system bell events." http://launchpadlibrarian.net/37349157/metacity_2.28.0-0ubuntu2.debdiff -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
I can't quite reproduce your it-must-be-metacity results, because when -I- try compiz, I just lose X bells completely. BUT---metacity is -definitely- doing something wacky. Read on. Starting from metacity, xkbbell (and rubout at an empty shell prompt) "work" in the same not-really-working manner as always. (And beep also "works", e.g., I hear it on the MB speaker if pcspkr is loaded and line- out otherwise.) Doing compiz --replace turns out to be a bad idea on my setup---almost all the time, I lose the ability to click on -anything- (including panel objects), I seem to have focus in no window at all (so typein is completely broken), and X logs errors about glibc corruption (double- frees & so forth). I have the logfiles, but that's some different bug I don't want to get distracted by now. (It also doesn't start jockey 'cause it's not automatically looking for drivers, etc.) I have to kill all compiz-related processes (some with -9) to get a window system back, whereupon doing metacity --replace works. (ssh is unaffected; this seems purely some X death, so I can fix things up via ssh from another machine). Going to Preferences -> Appearance -> Extra, on the other hand, does start up compiz without dumping backtraces into my .xsession-errors file. However, having done so, xkbbell (and rubout etc) are silent. beep still works. metacity --replace puts metacity back and gives me the same we-snarfed- your-X-bells behavior as always. Rebooting didn't change this. (I wondered if I'd screwed up some state trying compiz --replace a couple times and getting those assertion failures, etc, so I tried going back to metacity, then rebooting, then enabling compiz via the Prefs panel.) Since I'd been poking around in the metacity source, commenting out a thing or two, I figured that maybe my changes caused it to grab something in X and not let go, hence screwing up compiz. So I reinstalled the virgin package (essentially) via "apt-get source metacity; cd metacity-2.28.0; debuild -rfakeroot binary; cd ..; dpkg -i *.deb; killall metacity" and tried again. No change. I also tried rebooting at that point, just in case. Also no change. As long as I'm in compiz, no X bell. Once in metacity, X bell (as in, it's grabbing X bell events and playing bell.ogg at me). HOWEVER---I have inadvertently found another issue! I was doing most of my development on this in a root shell in Emacs, ssh'ed in from my stable Hoary (!) system (due to be replaced by Karmic as soon as this bug is squashed). In that shell, I typed "metacity" at the prompt. Whoops. It spit out "Window manager warning: Screen 0 on display "localhost:10.0" already has a window manager; try using the --replace option to replace the current window manager." AND KILLED THE X BELL ON THE HOARY MACHINE. I can't get it back. I'll have to boot, or at least restart X, which means the same thing in terms of losing all my state. I'm pissed off. I also tried this on a laptop running Dapper. ssh'ing into the test Karmic system and, as my normal, unprivileged user, trying to run metacity gave me errors, at about 1 Hz until I killed it, saying "Failed to contact configuration server: ..." etc. sudo bash on the same X connection (hence now in a root shell on the Karmic machine) and metacity stole that machine's X bell, too! Note at -at no time- was the machine with the actual X server (e.g., the display hardware) running as root; simply running metacity as root on the target (Karmic) system apparently caused it to say something to my local X server that broke the local bell. Hmm... (Presumably, there are tools that let one capture every X transaction in both directions, like an X version of ethereal, but I haven't looked for them and don't know what they are.) P.S. This bug still claims in its header and window title to be a Pulseaudio bug. I wonder if that's causing metacity people to ignore it. I'm tempted at this point to attempt to open this bug upstream, directly at metacity. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Yes, I had the same behavior with "killall metacity" (which I was using because I was recompiling it with various things commented out). I'll run some compiz tests and make sure I can reproduce your results. I think there -is- some negotiation going on, and I'm not sure what happens if a process asks X to hand it events and then dies or is killed; do the events get black-holed? I'll pull down the sources to those compiz processes if I can find it and take a look as well, though it'll be a superficial look. More in a bit. (Might also be interesting, after switching to compiz and back, to kill the left-behind compiz processes and see if that changes anything.) Together we'll kill this thing. [Possibly even with fire. That comment of yours early on had me in stitches.] -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
> Can you be precise about what you're doing to enable/disable compiz so I can try the same tests? I had been switching between "None" (metacity) and "Normal" (compiz) in the Visual Effects panel of Appearance Preferences. I just figured out that I can also switch by running "compiz --replace" and "metacity --replace". As far as I can tell, these two methods are the same. But to be sure what's going on, perhaps we should use the command line method from here on out. As best I can tell, the difference in running processes is: 1) When I first log in, "metacity" is running as a child of "gnome-session". 2) After I switch to compiz (using the Appearance Preferences), metacity is no longer running. Instead, "/bin/sh /usr/bin/compiz --replace" is running at the top level, with child process "/usr/bin/compiz.real --ignore-desktop-hints --replace --indirect-rendering --replace move resize place decoration animation ccp", which has child "/bin/sh -c /usr/bin/compiz-decorator", which has child "/usr/bin/gtk-window-decorator". (Additionally /usr/share/jockey/jockey-backend was started as a separate process. I don't know if this was related or not.) 3) Switching back to metacity, "metacity --replace" is now running at the top level. "compiz" and "compiz.real" have been killed, though "compiz-decorator" and "gtk-window-decorator" (and "jockey-backend") are still running. Switching to compiz again will apparently use the existing decorator processes rather than starting new ones. So, while compiz seems to have several processes running, the only process unique to metacity is in fact "metacity" I just tried running "killall metacity" (while using metacity, of course). Sure enought, the window title bars disappeared. So did the bell.ogg sound. However, it was NOT replaced by the PC speaker beep! (Instead I got silence.) System bell events were still being generated (as per xkbevd) and the speaker still worked (as per beep). Starting compiz from this state was enough to restore the beep on system bell events. Perhaps there is some sort of negotiation between X and the window managers about what to do with these events? Maybe I should look in compiz's code to see if there's a section where it tells X not to sent system bell events its way. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Aha! You've done -exactly- the debugging I was thinking of asking you to do... :) [More, even, since I didn't realize you could easily try out 9.04; I don't have any 9.04 systems and didn't really want to install one just for testing, though i guess I could. I'd assumed this was broken before then.] The fact that you can make it change by just enabling compiz vs metacity without even logging in or out is actually great news; if it really -is- metacity, that's not a large codebase. Can you be precise about what you're doing to enable/disable compiz so I can try the same tests? Is it just the Visual Effects thing, going from the lowest to the highest "effects" mode? Can you also do something like "ps -elf" or "ps -elf --forest" and diff them to see which processes are running in each case? That's pretty crude, but might give us an idea of where to look. Thanks! -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Grondr, thanks for your exhaustive efforts to describe the many permutations of this bug. I have only one thing to add: On my 9.04 system, the system bell seems to work exactly as it did in previous versions. So I think what changed, changed between 9.04 and 9.10. Perhaps we need to start diff-ing the sources of potential suspects. I still remain fairly convinced that this is a metacity problem. (Of course, I used to be fairly convinced that it was a pulse audio problem, so I won't feel slighted if you don't believe me. :) My reasoning is this: Once I've enabled the PC speaker, I can get the old behavior back by switching to compiz, and then go to bell.ogg by switching back to metacity. As I'm switching via the System | Preferences | Appearance | Visual Effects dialog, I'm not being logged in again and I'm not restarting Gnome. All that's happening (I think) is that metacity is being stopped and compiz is started in its place (and vice versa). So whatever is catching system bell events is being started and stopped with metacity. Maybe it's not within the metacity binary itself, but it seems to be tied tightly with the metacity window manager as a whole. That said, I have no explanation of the behavior you describe. > How do we find an expert? I'll try annoying the people over in #77010. But I'm not holding out much hope that that will help. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Donald, I fear you've mis-understood what this bug is about. We are trying to get the system beep to come out of the PC speaker, which is that speaker on your motherboard that can only play square waves. You probably don't want to use this for your video conferencing, unless you'll be talking to R2D2 :). I'm guessing that you're going to have to figure out how to get your tool to work with Pulse Audio (or figure out how to kill Pulse Audio before launching your application). If you think you've found a problem with Ubuntu, I think you should open a new bug; your problem seems unrelated to this one. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
I'm beginning to wonder if this might be a gtk issue. Or gdm. Or gdk. Does anyone know how to tell which application might have called XkbSelectEvents or XkbChangeEnabledControls? Can I ask X somehow? For the moment, I'm reduced to, e.g., doing "apt-get --dry-run build-dep gdm", noting which packages it wants as dependencies, then doing "apt- get source the-giant-list" and then using "rgrep -i bell-or-beep-or- whatever ." to find likely suspects. Unfortunately, there are quite a lot of references to beeps and bells (gads, I wish people would have decided one way or the other what this is called), and a reference in gtk+2.0-2.18.3/gdk/x11/gdkdisplay-x11.c to XkbSelectEvents with some masks, but all in all, this is a terribly time-consuming way to do a whole bunch of trial and error in an enormous hairball of hacks, kluges, and a decade or more of accreated code. How do we find an expert? -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Oy. I know this is probably going to be an unpopular discovery, but I am no longer sure this is necessarily a metacity bug. The problem is, then, whose bug -is- it? I just spent a couple hours hacking around in the metacity source code doing things like commenting out XkbSelectEvents and XkbChangeEnabledControls calls in core/bell.c's meta_bell_init, and finally going so far as to #undef HAVE_XKB in that file and display.c. I could pretty easily cause backspace on an empty line to emit -nothing- (on either the motherboard speaker or line-out), but I couldn't get the functionality I wanted (namely, the old functionality of X bell on motherboard speaker). [Obviously you have to killall metacity & restart it and/or log out & in to see changes, etc.] Finally it occurred to me to just rename /usr/bin/metacity to a random name, log out, and then log in again. I got an endless spinny cursor because something was trying but failing to start the metacity process, but could still start a terminal window and still got silence on empty- line backspace. [The "beep" command works as always, but that's a completely different mechanism, etc.] I also tried this from a cold- boot, just in case; same behavior. So while it looks like metacity can correctly snarf up X events so you can get -some- sort of bell, something other than metacity is grabbing and/or killing them, since even if metacity isn't running, there's no bell of any sort on an empty line (and presumably xkbbell would also be silent; i didn't test it). Yet this works without X and in an xterm started via xinit (see my giant table), so what's stealing these events? Some other part of gnome? Aargh. But at this point, I don't think I can file a bug against metacity for this, except to cause the metacity developers to maybe point their fingers at the real culprit... P.S. It -is- disturbing that meta_bell_set_audible is a complete no-op (no lines of code), and the comment in bell.h that meta_bell_shutdown is never called also gives me pause---I wonder if -that- is why I was getting different results based on whether xkbbell had -ever- run, since boot (see my giant table again), which smelled of something failing to clean up its state. But the fact that this seems broken even if metacity had never run makes me think it's not metacity's fault (and I suspect the xkbbell stuff is its own state-restoration issue.) -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
I also am affected by this. After lots of playing around I got it to do the horrible system bell, which in my case is better than a nice sounding one, but still. Here's the steps I took to get the workaround: 1) Unblacklist pcspkr in /etc/modprobe.d/blacklist.conf 2) Reboot (or modprobe, whatever) 3) alsamixer, make sure PC Beep isn't muted 4) xset b on 5) xset b 8 (nice and low so it doesn't make my ears bleed) 6) echo -e '\a' (should work) -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Grondr, thank you for your in-depth and exhaustive analysis. It will prove to be very valuable. I have marked this report as "Confirmed" for metacity, and I hope that will help capture the attention of the metacity maintainers. I think you have a much better handle on what is going on than I do, and doubt I would be able to do a proper summary of the issue. If you are willing, could you please update the description above with a summary of: symptoms, diagnosis/causes, and possible work-arounds. Usually, when I revise a description, I set those things as subsections with headers like so: === Symptoms === ... === Diagnosis === === Work-arounds === Bug reports that are nicely formatted like this are more likely to be dealt with by maintainers. I hope this helps get their attention and that they then can resolve this issue for you. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
** Changed in: metacity (Ubuntu) Status: New => Confirmed -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
I've rerun all my tests. I've attached a table and legends for it, since no
doubt it would
otherwise be smashed by the automatic reformatting done by launchpad (is there
any way to
turn that off?).
Note that EVERYTHING works fine in Hoary, Dapper, and Breezy. I did not test
9.04.
But 9.10 has multiple regressions from the behavior in much older releases.
Things that testers/fixers need to keep in mind:
(a) Logging in from usplash/xsplash is DIFFERENT than booting in recovery mode
and doing startx!
I get various diagnostics in my X log and elsewhere doing startx, -and- the
behavior is not
the same---note the recovery-mode section of the attached table and the
presence of --/--
entries there where there are different results via normal boot into GDM.
[Also, I can't
run alsamixer via startx (it says "alsamixer: function snd_ctl_open failed
for default: No
such file or directory" whereas it works fine in a normal boot -or if I run
it in an X-less
shell in recovery mode. So clearly doing startx from recovery-mode is
different than the
normal xsplash->gdm boot. (Also, startx bitches that I've changed my
language and prompts
to rename my homedir the name of one of the directories -inside- it, which
I ignore.)
[And I can't boot in recovery and do "service start gdm" 'cause that
requires a sudo, but
doing it as sudo presumably then runs gdm as root, not me, muddying the
water...]
NOTE ALSO that the VA state ("vanished first bell") is MUCH more common in
all the states
you can get into from startx, as opposed to a normal boot->gdm, where
you're only in that
state before screwing with xkbbell.
(b) You (probably) need to reproduce at least some of this testing on a
desktop, where you can
tell the difference between line-out and the built-in speaker.
(c) See the very first post in this bug for all the other things I had to
enable to get bells in
gnome-terminal to work so this is even possible, e.g., modprobe pcspkr,
alsamixer settings,
maybe xset b, gconf-editor changes, gnome-terminal checkboxes.
(d) Running xkbevd (w/conf file---see "workaround #2" in comment #12) and
killing it again is
NOT THE SAME as never having run it at all during that boot. Note, for
example, the line
in the direct-boot section, test BL, state 3 (gnome/metacity) vs state 5
(g/m w/xkbevd killed)
---{S2/LO,VA} vs {S2/LO} (no VA). Obviously, some state is being kept
around. I tried this
-3 times- to make sure I wasn't hallucinating. Logging out does NOT reset
this state.
(e) Each of BL MO NB RM etc tested starting from REBOOT (but not poweroff).
Don't just log out!
(See point (d) above for why not.)
(f) "beep" (from the "beep" package; not installed by default) and xkbbell are
not interchangeable!
Obvious, but let's be clear here about which is getting called when.
(g) Don't pay all that much attention to my bell-frequency notes; those were
guesses and may be
wrong. I'll redo them if tracking down who is generating a bell is
required and the frequency
can tell us; if it's not important for fixing these bugs, though, there's
no point.
Results, and where I think the blame lies:
(a) METACITY??: interception of X bells, forcing elaborate and unsatisfactory
workarounds.
This is the #1 issue in this bug report and the most annoying. REGRESSION.
(b) METACITY: rate-limiting. Possibly fixed by bug #430203. REGRESSION,
since the old
behavior didn't capture the events & hence couldn't rate-limit if it tried.
(c) KERNEL: un-blacklisting pcspkr insufficient, because then it loads too
early and doesn't
work and must be unloaded and reloaded later by the user. REGRESSION.
This is probably
bug #398161, but it's current Importance: Undecided, Assigned to
Unassigned, so it surely
isn't fixed yet.
(d) KERNEL??: first bell after a pause gets lost in some cases (see table in
attachment). REGRESSION.
In those cases, for example, doing
sleep 10;echo a;beep;sleep 10;echo b;beep;sleep 10;echo c;beep;sleep
10;echo d;beep;sleep 10;echo e;beep
typically beeps ONLY immediately after b and d! a, c, and e are silent!
(Although
in at least one case, I got a little blip around d.) Also, we have these
cases:
sleep 10;beep;beep [abbreviated single bell]
sleep 10;beep;sleep 1;beep [full-length single bell]
[Note this is "beep" and not "xkbbell", though that's worthwhile to test,
too.]
It all makes me think that something is trying to suppress bells (maybe for
rate-limiting?)
and accidentally suppresses the -first- bell in a sequence (until maybe 1s
has passed) and
then "wakes up", when instead it was supposed to be suppressing the -next-
one in the sequence.
It is PARTICULARLY weird that running xkbevd & killing it again does NOT
leave one in the first-
bell-missing state that one is in before running xkbevd at all, AND that
it's
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Robert: Re the rmmod/modprobe fandango I'm doing: I've done a bunch of testing (my next post will detail it), but I'm pretty sure what's going on with rmmod/modprobe is simply a kernel regression---if pcspkr is loaded too early, it doesn't work correctly. So if it's blacklisted, and then loaded by hand by the user once everything is up, that's equivalent to un-blacklisting it, waiting until the system is up, and then doing rmmod/modprobe on it. You didn't see that with the LiveCD because you couldn't un-blacklist it since you're booting off read-only media that specifies the blacklisting. (I don't know how early it can be safely enabled; that'll be some other testing, but that's pretty clearly a kernel regression in my eyes and otherwise unrelated to the rest of the bugs we're tracking down.) This also means that, until the kernel bug is fixed, the easiest thing for people to do is just leave it blacklisted and then put something in rc.local (or equivalent) that modprobes it; that's probably late enough, but I'll find out for sure at some point. Lots of detailed testing on all the other bugs & aspects of this report in my next post, once I finish editing it. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
> 4. In my case the sound coming from the sound card was missing (point 1) > and it works only if you disable compiz so I have to understand why > compiz stops that sound. If I understand correctly, this has nothing to do with the motherboard speaker. In Metacity, you're getting a sound file (bell.ogg) being played back at system bell events, but you're getting nothing at all in Compiz. Is this correct? If so, then the issue (#7 in my numbering above) is that Compiz does not play a sound at system bell events, while Metacity does. Compiz isn't stopping the sound; rather, no sound is being made when you're running Compiz. Issues #1-3 have blocked the motherboard speaker. To reenable it, try running `sudo modprobe pcspkr` and `xset b on`. This should allow beeps under Compiz, though you won't get the bell.ogg sound. IMHO, this illustrates why it's silly for the window manager to be intercepting system bell events. If something must intercept them, let it be Pulse Audio or some other WM-agnostic system. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Quoth Grondr: > Re the rmmod/modprobe fandango: I'm not the only person who needs to > do this. In fact, it would never have occurred to me that it would > even change the behavior if I hadn't seen it mentioned in bug #398161 > (see comments #1 and #2 in this thread, where Philip asked if I'd > tried that workaround). So it's clearly not just me. I've tried a Karmic Live CD on my desktop machine. I get the system beep coming out of the motherboard speaker after a single modprobe pcspkr, whether in X or at a virtual terminal. For obvious reasons, I can't un-blacklist the module, so I can't say whether the behavior would be different if the module was loaded during boot. Did you notice any difference between those two cases, or did you always have the beep come out of your soundcard after the first (and only the first) time pcspkr was loaded? I also haven't noticed any delay or dropping of system bell events (weird thing #1 from post #20) after the first time pcspkr is loaded. My strong suspicion that your problems with pcspkr behaving oddly on the first load is a hardware-related bug. As you point out, it's certainly widespread. But this is the one problem that is not behaving the same for everyone, at least as far as I can tell. -- 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
Re: [Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Some more clarification: 1. Starting from ubuntu version 9.10 the system beep has been replaced from a sound coming from the sound card. 2. If you load the module pcspkr you can ear a sound coming from the pc speaker but the system don't use it (only at the shut down or with the beep command) 3. If you load the module snd_pcsp you can ear a beep coming from the suond card but the system don't use it (only at the shut down or with the beep command) 4. In my case the sound coming from the sound card was missing (point 1) and it works only if you disable compiz so I have to understand why compiz stops that sound. Any suggestion? Grondr ha scritto: > Robert: Thanks for the summary. I'm going to prepare a little table > for the studio audience to try to make things clearer, especially since > you correctly pointed out in comment #27 that there's ambiguity over > whether I'm talking about bell.ogg or the squarewave beep coming out of > line-out (whoops). I can probably get to that within the next 24 hours; > if not, it'll happen maybe Sunday sometime. The idea is to summarize > the motherboard & line-out behavior with and without the rmmod/modprobe > fandango in an X-less console, in bare X (xinit), and in gnome/metacity. > (I'm not going to try compiz unless someone thinks it's necessary; if I > did that, I'd do it from a LiveCD to avoid potentially side-effecting my > current Karmic install.) > > Re the rmmod/modprobe fandango: I'm not the only person who needs to do > this. In fact, it would never have occurred to me that it would even > change the behavior if I hadn't seen it mentioned in bug #398161 (see > comments #1 and #2 in this thread, where Philip asked if I'd tried that > workaround). So it's clearly not just me. However, I hadn't realized > you were testing on a laptop. I think that to really disentangle > things, testers need to try this on a desktop, where you can tell > absolutely where the sound is coming from, given that laptops seem to > route what I'd call line-out directly to their onboard speaker unless > you've got something plugged into the line-out connector---that muddies > the water. On a desktop, my motherboard speaker is independent of > whether I've got anything cabled into line-out, so I can differentiate > conditions that I think you can't. > > On a larger note, this might be a problem with Ubuntu in general on this > issue---if most of the developers working on these subsystems do their > work on laptops, they may not see the issue! Or at least, not all of > it. > > More tomorrow. > > -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Robert: Thanks for the summary. I'm going to prepare a little table for the studio audience to try to make things clearer, especially since you correctly pointed out in comment #27 that there's ambiguity over whether I'm talking about bell.ogg or the squarewave beep coming out of line-out (whoops). I can probably get to that within the next 24 hours; if not, it'll happen maybe Sunday sometime. The idea is to summarize the motherboard & line-out behavior with and without the rmmod/modprobe fandango in an X-less console, in bare X (xinit), and in gnome/metacity. (I'm not going to try compiz unless someone thinks it's necessary; if I did that, I'd do it from a LiveCD to avoid potentially side-effecting my current Karmic install.) Re the rmmod/modprobe fandango: I'm not the only person who needs to do this. In fact, it would never have occurred to me that it would even change the behavior if I hadn't seen it mentioned in bug #398161 (see comments #1 and #2 in this thread, where Philip asked if I'd tried that workaround). So it's clearly not just me. However, I hadn't realized you were testing on a laptop. I think that to really disentangle things, testers need to try this on a desktop, where you can tell absolutely where the sound is coming from, given that laptops seem to route what I'd call line-out directly to their onboard speaker unless you've got something plugged into the line-out connector---that muddies the water. On a desktop, my motherboard speaker is independent of whether I've got anything cabled into line-out, so I can differentiate conditions that I think you can't. On a larger note, this might be a problem with Ubuntu in general on this issue---if most of the developers working on these subsystems do their work on laptops, they may not see the issue! Or at least, not all of it. More tomorrow. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Since we have some new people following this now, and our history of trying to track this down has been long and convoluted, I though it might help for me to summarize my understanding of the current situation. As you read this, please keep in mind that I have no idea what I'm talking about. The following explanations are likely incomplete or incorrect. Please note any corrections you see. Goal: We would like to have the motherboard/PC speaker beep when there is a system bell event. (For example, when there is a backspace on an empty like of a terminal.) Prior to Karmic this was the behavior. In Karmic, there are a number of things that get in the way, leading to a variety of different behaviors. Issue #1 -- The pcspkr kernel module, which allows Linux to make sounds through the PC speaker, is blacklisted by default. This can be changed by commenting out the line 'blacklist pcspkr' in /etc/modprobe.d/blacklist.conf, or by running `sudo modprobe pcspkr`. Everything following will assume that the pcspkr module is loaded. Issue #2 -- The first time the pcspkr module is loaded, beeps are sent out the sound card's line out, instead of being played by the PC speaker. Removing and reloading the module sends the beeps to the speaker. So far, this has only been observed by Grondr. Issue #3 -- Somewhere in the initialization of X or Gnome, the PC speaker volume is set to 0. This can be changed with `xset b on`. Note that, because of bug #280767, you cannot use xset -b to set the volume of the bell. (My guess is that this is an issue in Gnome: if I log into an xterm session, the bell volume is set to 50, whereas it is set at 0 after logging into Gnome. So far, though, we haven't found where this is happening.) Issue #4 -- Metacity is trapping system bell events and using libcanberra to play the sound file /usr/share/sounds/ubuntu/stereo/bell.ogg. This trapping occurs even when the PC speaker has been enabled through solving #1 and #3. (Later, I'll provide what evidence I have that this is indeed Metacity.) So far, the only way to stop this behavior is to remove (or rename) bell.ogg. Unable to play the file, Metacity falls back to ringing the PC speaker. In my opinion, this is the major problem. If Metacity is going to interfere with the system bell events, it should offer some configuration options! Given that Pulse Audio has module-x11-bell, which could play back an audio file for system bell events, I fail to understand why Metacity needs this feature. Issue #5 -- If you would like to restore bell.ogg to be played for system bell events after removing it, you must restore the file, delete ~/.cache/event.sound.cache., and restart your session. Why this Pulse Audio cache file is important here has yet to be explained. Issue #6 -- Metacity limits the playback of sounds for the system bell to 1Hz. See bug #430203. Issue #7 -- Compiz does not do anything to handle system bells. If issues #1 and #3 have not been addressed, system bell events will not produce any sound. If they have, the PC speaker beeps as desired, without any futzing with bell.ogg. Under Compiz, the "Sound Preferences" "Sound Effects" tab still gives options for the alert sound, even though it (apparently) has no way of playing these sounds at system bell events! (IMHO, this is another good reason to remove bell playback from Metacity -- it gives one less thing to try to match in Compiz.) So that's my understanding of the problem. If you are experiencing behavior different from what I've described, please let us know. Note that this bug involves the interaction of the kernel, X, and the window manager, and has two states that could be considered "working" (playback of bell.ogg and playback through the PC speaker). So you must be specific as to what exactly is going on! Appendix: Are you sure it's Metacity and not Pulse Audio? Mostly. I have three lines of evidence that point to this: 1) Attempts to disable the Pulse Audio's trapping of the system bell haven't accomplished anything. module-x11-bell is not loaded. Moving the .so file associated with this doesn't change anything. Removing the bell.ogg sample (via pacmd) doesn't change anything. Daniel notes that this module is only loaded in Lucid. (So debugging this problem six months from now will be even more fun!) 2) bell.ogg isn't played under Compiz as it is under Metacity. The bell repeat is normal under Compiz, while it is slowed under Metacity. 3) The source of Metacity shows code that seems to catch system bell events, use libcanberra to play back an alert sound, and fall back on the PC speaker in case of errors. (See lines 278-324 of http://git.gnome.org/cgit/metacity/tree/src/core/bell.c This isn't quite what's in Karmic, but it looks pretty close. I think.) Depressingly, the code doesn't reveal any obvious options that are checked before doing all of this, so I don't think this is a case where we've just been missing the relevant configurat
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
In reply to Grondr's post from yesterday: > But if you hit rubout at the start of a line in that shell, you'll > hear the bell out your line-out, not from the motherboard speaker. If > you rmmod/modprobe, -then- a rubout there will -not- come out of > line-out and -will- come out of the motherboard. I did not read your previous posts carefully enough. I assumed that when you said a bell coming out of line-out, you meant that bell.ogg was being played. But if I'm reading this correctly, what you actually mean is that you're getting a square-wave sound out of the sound card at first, and then out of the motherboard speaker after the rmmod/modprobe. Is that correct? Unfortunately, I can't test this with my Karmic machine. It's a laptop without a motherboard speaker, so everything comes out of the built-in speakers. If I get a chance, I'll try a Live CD with my desktop to see if I can replicate this behavior. (I've been putting of upgrading it because of bugs like this one.) I still feel that this problem is unconnected with the other issues we're having (but I've been wrong before!). > (b) I think you're right that bug #430203, which I cited as the "slow > bell", did make it into Karmic---I looked at bell.ogg in Audacity and > the entire sample is only 200ms long, and it's got audio for all of > it. But the gnome/metacity bell is still not firing above 1 Hz, so > there's a bug/rate-limiter in there -somewhere-. I've linked #430203 to an upstream bug, where they seem to have solved this. But I so far there's been no action. > WEIRD THING #1: I noticed that, if you're -not- in gnome/metacity > (e.g., either directly in an X-less shell, or in the shell that xinit > gives you), -and- if you've booted with pcspkr -not- blacklisted (so > it's loaded) but have -not- done the rmmod/modprobe fandango (so your > bell is still being intercepted and is coming out of line-out instead > of the motherboard), THE FIRST BELL AFTER AN INACTIVE PERIOD > VANISHES. I cannot reproduce this behavior. > WEIRD THING #2: If you -are- getting the motherboard bell (meaning > you've done the fandango), holding down rubout in an X-less shell > gives you the bell at what seems to be the key-repeat rate, maybe > 10-20Hz. But if you're in X (e.g., via xinit, not gnome/metacity), > holding down rubout gives you a bell that's only running at about > 2Hz. The duty cycle of the X-less bell is close to 100%, but the duty > cycle of the X bell is closer to 30-50%. I do, however, see this. (Okay, it's more like 4Hz for me.) Checking with xkbevd, it seems that the rate of bell events has actually slowed down. I thought this might be an issue of keyboard repeat rate, but xset q shows that to be 25 Hz, which seems about right when deleting characters, for example. I have no idea if this is at all relevant to the other problems. > Obtw, one problem with your workaround #2 is that apparently the X > bells it plays take a while (maybe I can tighten up their duration, > but then an isolated bell is harder to hear). This means that, unlike > the "working" case in older releases, holding down rubout makes it > -really easy- to get -way- ahead of the beeper Yep. Things like this keep the workarounds from rising to the level of solutions. > We're just flailing here---someone who knows the codebase could > probably fix all of these random bugs in short order, Amen. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
[IG: I don't understand your comments re the bell working in metacity -instead of- compiz. If that's true, you're talking about something different than we are. You should also strive to be more precise in your description. For example, when you say "system bell", I'm not sure if you're talking about something coming out of line-out, or out of the motherboard beeper.] So there are actually a number of bugs here (e.g., the rmmod/modprobe fandango etc), but it's looking like the most-annoying one to work around is the stealing of the X bell events. -Assuming- for the moment that it's metacity or libcanberra (because my tests in X but outside of them "worked", for some value of "worked" modulo repetition rates, and because Robert reports that compiz also doesn't appear to be stealing events), then how do we establish this? Does anyone have an easy way of running gnome et al without metacity as a test? How about a potential patch one might make to libcanberra to see if the behavior improves? -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
uhm.. I don't know. I can't understand why a video manager interacts with sounds... some strange dependency? -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Therefore, if indeed the differential is metacity versus compiz, then the problem might be with libcanberra? -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
New information: Using metacity instead of compiz the system beep works!! any suggestions?? -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Thanks! I just put a pointer in your bug back to here, so hopefully people will see both and figure out if we're talking about the same thing. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Same problem in my system. See bug 493127 GM -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Daniel: If this bug is truly independent of PulseAudio, then why does renaming /usr/share/sounds/ubuntu/stereo/bell.ogg change the behavior? If your argument is that libcanberra is looking at that file, then why is it necessary to remove a -PA- cache file to fix the bell after renaming the file back? Are you saying that libcanberra is dependent upon and/or writing to files that appear to be owned by PA? Note that I can repeat all these behaviors from either the 32- or 64-bit LiveCD, using its default settings, which I -assume- means it's using metacity and not compiz. By default, module-x11-bell appears to be commented out, as I said above. So who exactly is stealing X bell events? And how do we -stop- it from doing so? Robert, in response to various items: (a) The reason you don't seem to need the rmmod/modprobe fandango is that you've been confining your experiments to gnome (or metacity, or whatever). Try booting in recovery mode and logging into an X-less shell. Assuming you do -not- have pcspkr blacklisted, then lsmod | grep pcs at that point should show it. But if you hit rubout at the start of a line in that shell, you'll hear the bell out your line-out, not from the motherboard speaker. If you rmmod/modprobe, -then- a rubout there will -not- come out of line-out and -will- come out of the motherboard. Furthermore, if you type xinit (hence getting into X but not gnome/metacity), you get the same behavior (you can also try rebooting and waiting to do the rmmod/modprobe until you xinit if you'd like to reproduce it the same way). Note that the X bell will have a different pitch than the non-X bell, which has a different pitch than the motherboard bell---three pitches in all. But if you do the fandango, you'll get the motherboard bell, whether you're in X or not. [And note -weird- thing below!] (b) I think you're right that bug #430203, which I cited as the "slow bell", did make it into Karmic---I looked at bell.ogg in Audacity and the entire sample is only 200ms long, and it's got audio for all of it. But the gnome/metacity bell is still not firing above 1 Hz, so there's a bug/rate-limiter in there -somewhere-. WEIRD THING #1: I noticed that, if you're -not- in gnome/metacity (e.g., either directly in an X-less shell, or in the shell that xinit gives you), -and- if you've booted with pcspkr -not- blacklisted (so it's loaded) but have -not- done the rmmod/modprobe fandango (so your bell is still being intercepted and is coming out of line-out instead of the motherboard), THE FIRST BELL AFTER AN INACTIVE PERIOD VANISHES. In other words, you're sitting at en empty line in the shell. You hit rubout. You hear NOTHING. You wait a couple seconds. You continue to hear nothing. You hit rubout again. NOW you hear a bell! In fact, I can repeatably cause non-motherboard bell events to VANISH as long as I hit rubout no more frequently than about once every six seconds. If I hit it more frequently than that, the first one after a long gap vanishes, and the rest of them come through. [Note that this might be slightly racy---while I was testing, I managed to hear a bell and then -not- hear one from a rubout less than half a second later, but that's rare.] Note that this obviously-buggy behavior may possibly have influenced my test results, at least---when I was doing prior testing, I didn't hammer on the rubout key or whatever---if I heard no bell the first time, i assumed it was dead, not that I had to try again within six seconds to find out for sure! Sheesh. [I believe that if you're actually in gnome/metacity, the inactive- vanishing-bell bug doesn't manifest---I currently have my line-out connected and I'm doing workaround #2, running xkbevd -bg, and I hit rubout on an empty shell line that had been sitting there for ten minutes. I heard a bloop from line-out and a beep from the motherboard speaker. Note, however, that if it's been more than a few seconds, the bloop is delayed at least a second compared to the motherboard; if it's within a second or two, the start of the bloop is maybe only 300-500ms behind the start of the motherboard beep.] WEIRD THING #2: If you -are- getting the motherboard bell (meaning you've done the fandango), holding down rubout in an X-less shell gives you the bell at what seems to be the key-repeat rate, maybe 10-20Hz. But if you're in X (e.g., via xinit, not gnome/metacity), holding down rubout gives you a bell that's only running at about 2Hz. The duty cycle of the X-less bell is close to 100%, but the duty cycle of the X bell is closer to 30-50%. (They seem to have about the same -duration- when you're just getting one of them at a time, so I guess the X-less bell is interrupting itself when you hold rubout down, possibly so as not to pile up a huge backlog---see below.) By way of comparison, my 5.04 Hoary machine (yes, that old) gets this right, -even in gnome-: holding down rubout gives me a 10-20Hz stream of motherboard be
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
I've marked the Pulse Audio bug as invalid. The bug I feel is in metacity or libcanberra is that there is no (easy) way to disable the system bell played back through the sound card in favor of the PC speaker. (This is point (d) from above.) I don't know whether the problem is in metacity, libcanberra, or both. As best I can tell from src/core/bell.c. metacity isn't checking any settings before it uses libcanberra to play a bell. And libcanberra didn't seem to install any configuration files for me to tweak. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
** Also affects: metacity (Ubuntu) Importance: Undecided Status: New ** Also affects: libcanberra (Ubuntu) Importance: Undecided Status: New ** Changed in: pulseaudio (Ubuntu) Status: Confirmed => Invalid -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
> Now, let's consider whether your window manager uses libcanberra > fully. I know metacity does. Compiz doesn't. Everything I've reported has been using metacity. If I turn on desktop effects (which switches to compiz, if I'm not mistaken), I don't get any system bells at first. If I enable the PC speaker (modprobe pcspkr and xset b on), then I get the expected beeps with the expected repeat rate. So point (d) is not a Pulse Audio issue, as I had claimed. Should it be reported again metacity, libcanberra, or both (or something else)? Separately, there the issue of not having any bell in compiz, but my feeling is that that would be suitably mitigated by addressing (b) [and maybe (a) and (c)]. Thanks for the insight. -- 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
Re: [Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
On Mon, Dec 7, 2009 at 11:58 PM, Robert Schroll wrote: > In fact, it doesn't look to me that module-x11-bell is actually loaded > by PA. I can rename /usr/lib/pulse-0.9.19/modules/module-x11-bell.so, > restart, and still have the system bell intercepted! This confuses me > to no end. We don't actually load module-x11-bell in Karmic at all. In Lucid, we do. Now, let's consider whether your window manager uses libcanberra fully. I know metacity does. Compiz doesn't. -- 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
Re: [Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
On Tue, Dec 8, 2009 at 1:18 AM, Robert Schroll wrote: > back. But the next time it happens, PA survives and rings the PC > speaker itself. I can only assume that pulseaudio is learning, > evolving, and slowly gaining sentience, and we must kill it now. With > fire. No. Delete it from the cache. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
One of the reasons I wanted to disable the PA bell was that it only fires about once a second (as discussed in bug #430203) when, e.g., you hold down the backspace key at a terminal prompt. I prefer the old behavior of the PC speaker of nearly-continuous beeping. When I first implemented workaround #1, I found the old behavior was restored. However, after logging out and back in and re-enabling the beep, I found that it would only beep about once a second. Re-enabling and then disabling the PA bell again didn't change this - the PC speaker would still beep only once a second. Using xkbevd, I could see that bell events were being fired more rapidly that this; it's just that most of them would be ignored. So I tried creating another, shorter audio file (0.1s) and placing it as bell.ogg. After deleting the cache file and restarting, this new sound was played for system bell events. But despite the short file length, it would still only be repeated about once a second. Deleting this file, I got the PC speaker repeating as rapidly as possible. But a log- out/log-in cycle changed that back to a PC speaker beep once a second! Note that this behavior is robust against deleting the cache file. What seems to be happening is that the first time a given file is ripped out from under it, the PA beeper dies and the old beep behavior comes back. But the next time it happens, PA survives and rings the PC speaker itself. I can only assume that pulseaudio is learning, evolving, and slowly gaining sentience, and we must kill it now. With fire. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Grondr wrote: > Robert: I think actually we had exactly the same problem, and your > workaround works for me. I'll explain, 'cause it'll help in debugging > this for real. That seems like a reasonable assessment. I'll point out a few places where our systems differ. These should be signs of things that /don't/ matter, since the main problems are the same. > > First off, I've now gotten to a state where my system bell is coming out > of line-out. It wasn't before. I'm reasonably sure that this was > because of my testing methodology: the first thing I did was to undo > the blacklisting of pcspkr in /etc/modprobe.d/blacklist.conf. Then, > almost all of the time, my testing after a boot started with rmmod > pcspkr; modprobe pcspkr (since apparently it loads at the wrong point > during boot when unblacklisted), and doing -that- kills the system bell > coming out of line-out! So I thought I never got a bell, when instead > I'd killed it. But booting and -not- doing the rmmod/modprobe allowed > that to work. > > (But it is -completely- unclear to me how the reload of pcspkr tells > -PA- to stop emitting its bell!) I haven't seen this issue. If I comment out pcscpkr from the blacklist file, it loads just fine. I don't have do to the rmmod/modprobe fandango. But if I do, it doesn't seems to affect what's happening on line out. > Other problem people may run into: I tried your first workaround and > renamed /usr/share/sounds/ubuntu/stereo/bell.ogg to bell.ogg.KILLED in > the same directory. Whereas before then, I was getting that noise out > of line-out in a gnome terminal, the noise vanished when I did that. > (And I had not yet done the rmmod/modprobe, so it was expected that I > heard nothing from line-out and nothing from the motherboard speaker.) > I then immediately renamed bell.ogg.KILL to bell.ogg and my sound was > STILL GONE! [...] > Running tdbtool on the new file was very different: only 5 keys, all in > en_US.UTF-8, one of which was bell-window-system, and pointing at > bell.ogg. So clearly that cache file managed to get itself corrupted > when I renamed the .ogg. (Did you not run into this problem, or did you > solve it a different way?) I thought I had managed to rename bell.ogg back and forth a few times without any problems, but now that I've tested it again, I see that it behaves the same way you describe. To restore the line out bell, I have to make sure bell.ogg exists, delete the cache file, and log out and back in. Incidentally, this has revealed an oddity in how workaround #1 works after several logins, but I'll save that for another post. > Interestingly, btw, "xset q" is currently showing my bell percentage as > 0, but I still get a motherboard beep. Not that "xset b 100" would help > ---due to another bug (mentioned in the report on X which I opened last > week, pointed to above, which points out that it's at least 4.5 years > old!), "xset percentage pitch duration" is being wrongly interpreted as > "xset duration pitch duration". *sigh*... But at least things are > somewhat working. After `xset b on`, I find `xset -q` reports a bell percentage of 50. > So this shows that there are a whole bunch of bugs floating around that all need squashing: > (a) Unblacklisting pcspkr should just work, dammit, without having to > rmmod/modprobe it. This is working for me, so I'm guessing it's an issue with your setup or hardware. I would suggest that we ignore this issue for now, or split it out into a separate bug. > (b) -Something- is stubbornly doing "xset b 0" that I can't find. > That's not the default in other releases. WTF? That's yet -another- > thing that makes reenabling the bell annoying. (Though see above--maybe > something -else- is ignoring the bell volume, which might be the whole > damned reason users were complaining so much that the bell got killed!) But blacklisting pcspkr takes care of this problem, doesn't it? I see no reason why the bell volume must also be set to 0. > (c) Too many separate parts of gnome and PA all have various bells > and alerts turned down, and they're scattered all over the UI. The whole > thing's a mess. (alsamixer's Bell control; gconf's bell_mode at least; > that xset b 0 if that's even doing anything at all; who knows what else > I'm forgetting. I know that users complained about an annoying system > bell, but the -right- way to have fixed the whole issue would have been > to have made that -softer- by default, not smash it in half a dozen > unrelated places.) I haven't gone around re-enabling the bell in a bunch of places. But my system was upgraded from Jaunty, so maybe I inherited settings from there that kept the bell active. On the other hand, some of those settings you were tweaking may be legacy settings that don't actually do anything now. (But I don't feel like going through and trying each one to find out for sure!) > (d) PA should give a way for users to tell it to -stop- intercepting > the X bell! Us
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Robert: I think actually we had exactly the same problem, and your workaround works for me. I'll explain, 'cause it'll help in debugging this for real. First off, I've now gotten to a state where my system bell is coming out of line-out. It wasn't before. I'm reasonably sure that this was because of my testing methodology: the first thing I did was to undo the blacklisting of pcspkr in /etc/modprobe.d/blacklist.conf. Then, almost all of the time, my testing after a boot started with rmmod pcspkr; modprobe pcspkr (since apparently it loads at the wrong point during boot when unblacklisted), and doing -that- kills the system bell coming out of line-out! So I thought I never got a bell, when instead I'd killed it. But booting and -not- doing the rmmod/modprobe allowed that to work. (But it is -completely- unclear to me how the reload of pcspkr tells -PA- to stop emitting its bell!) While discovering this just now, I also discovered that -something- had recently muted my Main in alsamixer! And -something- had caused the Mute button in System -> Preferences -> Sound -> Output volume to be muted! I -know- for a fact I did not touch either one. I suspect they get reset somewhere else in the window system when I was running as root or a test account and something leaked in some direction. I'm pretty damned tired of the amount of behind-my-back futzing around Ubuntu's currently doing to system sounds. I'm pretty sure this didn't screw up my test results, though, since I've been pretty careful to review my alsamixer settings almost every time, just in case. (I discovered this when, as part of testing line-out, I couldn't even play music through it.) Other problem people may run into: I tried your first workaround and renamed /usr/share/sounds/ubuntu/stereo/bell.ogg to bell.ogg.KILLED in the same directory. Whereas before then, I was getting that noise out of line-out in a gnome terminal, the noise vanished when I did that. (And I had not yet done the rmmod/modprobe, so it was expected that I heard nothing from line-out and nothing from the motherboard speaker.) I then immediately renamed bell.ogg.KILL to bell.ogg and my sound was STILL GONE! I tried logging in and out; I tried rebooting. Nothing. Uh oh... The non-pc-speaker bell sound had seemed to have gotten itself permanently killed---really annoying, since then I -couldn't- get a bell except through the pc speaker, so if I ever changed my mind about this, I'd have been stuck. (And I might well have to change my mind several months from now when the machine might wind up getting placed too far away to hear its internal bell.) I figured that the lack of bell.org being around got cached -somewhere- in pulseaudio and I needed to clear that cache. My suspicion was ~/.cache/event-sound-cache.tdb.d19e9db8691a26d6165e5be74ac83637.x86_64 -pc-linux-gnu, since that's one of several files that a "find / -mmin -120 -ls" showed had changed recently. I tried renaming it by suffixing .OLD to it. Creating new gnome-terminals didn't bring back my PA bell, but logging out and in again recreated the file. The new and old files are quite different: Running tdbtool on the old one and saying "keys" shows a whole bunch of sound names with either "C.stereo" or "en_us.UTF-8.stereo" in their names, so I fear maybe a locale issue while I was running as root at some point. Doing "dump" shows that ubuntu.bell-window-system.C.stereo points at ...K/usr/share//sounds/ubuntu/stereo/bell.ogg (yes, two slashes), whereas ubuntu.bell-window-system.en_US.UTF-8.stereo points at ...K. Only some of each of the .C/en_US entries have filenames and it's not consistent. There were 46 keys total. Running tdbtool on the new file was very different: only 5 keys, all in en_US.UTF-8, one of which was bell-window-system, and pointing at bell.ogg. So clearly that cache file managed to get itself corrupted when I renamed the .ogg. (Did you not run into this problem, or did you solve it a different way?) Your workaround #2 also works for me---after creating the relevant file and having done the rmmod/modprobe beforehand, I get -both- the PA bell.ogg sound -and- the internal speaker for X bell events. (I'd notice a mention of xkbevd when I was reading about xkbbeep, but hadn't tried it 'cause I'd figured that the X bell events were just getting lost. Oops.) Interestingly, btw, "xset q" is currently showing my bell percentage as 0, but I still get a motherboard beep. Not that "xset b 100" would help ---due to another bug (mentioned in the report on X which I opened last week, pointed to above, which points out that it's at least 4.5 years old!), "xset percentage pitch duration" is being wrongly interpreted as "xset duration pitch duration". *sigh*... But at least things are somewhat working. So this shows that there are a whole bunch of bugs floating around that all need squashing: (a) Unblacklisting pcspkr should just work, dammit, without having to rmmod/modprobe it. (b)
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
I've found two work-arounds. Let me know if either works for you. Workaround #1 Whatever is trapping system bell events tries to play the file /usr/share/sounds/ubuntu/stereo/bell.ogg. If I rename this file, it falls back to the using the system bell. So long as the PC speaker is enabled (`sudo modprobe pcspkr` and `xset b on`), it now beeps when I expect it. Workaround #2 xkbevd is a daemon that can execute specific commands on given X events. If I create the file ~/.xkb/xkbevd.cf with the contents 'Bell() shell "beep"' and run `xkbevd`, beep will be executed (making a beep) every time there's a system bell event. With this, I get both the PC speaker beep and the bell.ogg sound. But if I didn't have my speakers connected, this wouldn't matter. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
We seem to be having slightly different problems - I am getting a sound out of my speakers when I would expect a system beep. What I'm trying to do is go back to the ugly PC speaker beep that I know and love. I was guessing that the sound was being produced by pulse audio, and it seems that module-x11-bell is the one that would do this. But since this module isn't loaded, it must be something else. Nonetheless, I suspect that we're both looking for the same solution. Something is grabbing events headed for the system beep. We just need to figure out what this something is and how to disable it. I wonder, in the cases where you can get the beep, is pulse audio running? If so, are the same modules loaded as usual? (You can get a list of the loaded modules with `pactl list`, though that also gives a bunch of other info as well.) -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Oh, right, so some quick research indicates the .tdb files in ~/.pulse are Trivial Database Files. Installing the tdbtools package (bug #557819 already complains about their total lack of documentation) lets you run tdbtool on 'em and use commands like "keys" and "dump", although the values of the keys are just strings of binary. I can diff 'em to see if configurations differ, but knowing what the binary means might require a trip to the source code. pulseaudio --dump-conf and --dump-modules seem promising, although it's annoying that the latter dumps all -available- modules but not (apparently) what it's currently -using- (even with -v). Apparently, though, what you want is "pacmd"; then type list-modules (etc) in its read-eval-print loop; it takes "help" (but not "?"). info & dump may also be useful. So these might yield some useful debugging info. I note that pacmd's list-modules claims I don't have module-x11-loaded, which makes sense since it's commented-out in default.pa. Of course, the -real- question is, does PA even matter? Is it what's intercepting the system bell under X, or can something else get in the way? -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Robert: It looks like the reason module-x11-bell isn't loaded by default is because it's commented out in /etc/pulse/default.pa (along with the load-sample mentioning it near the top of that file). Presumably, uncommenting and restarting pulse (or just rebooting) would load it. But of course, unless pulse can know to beep the -system- beeper (I don't know if it can), this doesn't necessarily help me (or you). Though if loading that -still- means that xkbbeep (etc) don't produce any output on an audio-out jack (or wherever pulse is trying to route high-quality sound), then it would mean that gnome/metacity/pulse is just throwing away the event entirely, which it could well be doing ---at one point in my testing, I tried hooking a speaker up to my line- out, and even though mplayer can certainly play music out that, I never heard the bell come out of that. (And then I unhooked it, so most of my testing hasn't had anything connected there.) -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
I now think that Gnome, Metacity, or Pulseaudio are implicated. The hardware and X itself are probably not. Details: I think I've managed to pry this bug quite a bit farther open, but it's not quite there yet. In particular, I -can- get the system bell to work under bare X as any user. And I can get it to work under the normal window manager, but only as root, and I haven't been able to reproduce the setup, despite installing from the 9.10 image onto a spare disk and starting over. (Note also that for a while I thought this was an X bug and opened bug #489855, which will give you my entire X configuration; I'll go back and amend that shortly.) Here's what I've done: First, I realized I could simplify the situation by booting my original installation in recovery mode, logging in as myself, and doing "xinit". Assuming I've done the rmmod/modprobe pcspkr step (since it's already out of my blacklist but that's required to work around some sort of ordering bug), then if I rubout on an empty line in the xterm I get from xinit, I -do- get the system beep! It also works, of course, if I call xkbbeep. So clearly X itself is capable of beeping the system bell in Karmic, if it's not interfered with. (Also, xset does change the bell pitch and duration---but the longstanding bug where the first arg [supposedly volume] is incorrectly -also- interpreted as duration is still with us---looks like "xset b vol pitch dur" is interpreted as "xset b dur pitch dur".) My next move was to exit out of the xterm and do "startx" instead. In the resulting gnome/metacity/pulseaudio interface (e.g., what I'd get if I'd just done a normal boot), none of the X beeping worked. Note that I -can- still exercise the hardware beeper either by calling "beep" with no args (which produces a different-sounding beep) or by doing "echo foo | wall" (which produces yet a -third- different beep---that one, I think, is the true default hardware beep which matches what the machine's BIOS produces on boot). So I logged out of the gnome and then did "sudo bash". (Yes, this still left my homedir pointing at my default user directory, which I hadn't been thinking about too carefully. More on that below.) I tried "xinit" as root and that xterm also worked correctly. I exited the xterm and tried "startx", which was the very first time root had run gnome. And -that- UI -does- work---if I start a gnome-terminal, rubout at an empty line beeps, xkbbeep beeps, and ^G in Emacs beeps. Could this be some sort of permissions problem? (It continues to work after rebooting---as long as my window system is running as root, things work. Yuck.) Note: I'd run both "gconf-editor" -and- "sudo gconf-editor", both while logged in as me, while trying to debug this over the last few days, and I suspect that the latter may therefore have been altering root's settings. (I'd been under the impression that gconf-editor required privileges, but I suspect not.) I have, however, since run gconf-editor as both myself and as root and used the "find" command to find everything that matches the string "bell" in its name or setting, and stepped through them all with lots of downarrows. I believe that both users' settings are the same in this regard. Also note: Every time I startx as root, "xset q" reports my bell percentage as 50%. Every time I startx as myself (or just boot the machine normally and let it start it), my bell percentage is 0 and I have to reset it. What's changing this? Why only for me and not root? Another note: Every time I startx as myself (but not as root), I get a notification claiming "You have logged in in a new language. You can automatically update the names of some standard folders..." etc. I assume this is because my locale is set differently? Presumably the normal system startup sets it one way but booting into recovery mode, logging in, and doing startx does something else? I've never answered the question---just left the window sitting there until I log out or reboot, since I didn't want to side-effect anything. I haven't compared environment variables between the two, etc. I then did "adduser test" (since myself and root were the only two users on the machine) and tried to get -that- user to work. The first thing I discovered (after putting the user in the "audio" and "plugdev" groups so alsamixer could work) was that that user started with its master volume control both down and muted---WTF? Its bell was also down and muted. I fixed both. However, I am unable to get that user's bell to work under gnome (though it does with in a bare xinit). Oddly, -that- user also won't beep if I do "echo foo | wall"! (In fact, I was ssh'ed into the machine in a shell that had just been sitting there for hours, and when I typed "echo foo | wall" as the test user, the ssh'd-in machine's bell beeped, but the local bell did not. That's different behavior from either myself or the root user---both of them will beep the system beeper if
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
I'm having the same problem on a Presario 2100 running 32-bit Karmic. Running `modprobe pcspkr` enables beeping from the ttys, but Pulse Audio continues to handle the system bell for X. Please let me know if you need more hardware info from me, but this really looks like a software issue to me. One further solution that doesn't work: Several guides suggest that one can get Pulse Audio to handle the system bell by loading the 'module-x11-bell' module (using `pactl load-module`). However, I don't seem to have this module loaded by default -- it doesn't show up in `pactl list`. FWIW, I can load this module, getting it to show up in `pactl list`, and then unload it, but this doesn't change anything about the system bell. ** Changed in: ubuntu Status: New => Confirmed -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Btw, these tests under X that I'm doing---I'm doing them typing directly on the machine's actual keyboard and using its actual display. Don't get confused by my comments about ssh'ing in from elsewhere---I'm making sure to run the tests directly on the machine's actual I/O hardware so I can't get faked out by some unknown weirdness with X forwarding or something like that; all of the X traffic is on localhost. -- 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
[Bug 486154] Re: System beep broken in Karmic despite heroic efforts to fix it
Ah, and my comment above about reboot---I just tried "shutdown -r 3"
from the LiveCD, and -that- beeped the speaker! "echo foo | wall" also
beeps.
I rebooted the normal 64-bit system and noticed that "echo foo | wall"
didn't beep the system bell. (Although I was also ssh'ed in from
elsewhere and -that- machine's bell beeped when wall emitted the
message.) If I did the rmmod/modprobe trick, -then- "echo foo | wall"
beeped both bells (the system bell of the machine running Karmic, and
the system bell of the other machine that was ssh'ed into it).
So clearly the rmmod/modprobe workaround -is- doing something. But not
enough---still no bell in single-user mode, even if X has never run, or
in X, from Emacs, or bash, etc. --BUT---:
I've discovered that if I do rmmod/modprobe on a fresh boot (now back to
experimenting on my normal 64-bit boot, not the LiveCD), no beep, If I
do "echo foo | wall", that beeps, though only -after- the rmmod/modprobe
(it won't beep if I do it on a freshly-booted system that has only
loaded pcspkr once). And -THEN-, rubout at bash beeps, as does ^g in
Emacs, BUT ONLY outside of X. This works whether I've booted single-
user or if I've done C-A-F1 to get a non-X shell and logged into that.
I've also tried "service gdm stop; service gdm start" and that hasn't
helped. (I figured the wall is obviously initializing -something-, but
restarting gdm after that doesn't help.) I made sure to do "xset b 100"
before these tests, since every time gdm comes up, it's apparently
setting the bell volume to zero ("xset q" reads bell volume 0% unless I
reset it)---where is gdm doing this?
So I'm obviously starting to pry this problem open a bit---I can get
beeping outside of X (both via rubout at an empty bash command prompt,
or in an X-less Emacs) iff and only if I (a) rmmod/modprobe pcspkr, and
then -after- that, do something that causes beeping (like "echo foo |
wall'; haven't retried doing something like "shutdown -r 3; shutdown -c"
but I'm betting that would work too). But inside of X, still no dice,
even after I can get beeping reestablished outside of X, so I'm not all
the way there yet.
--
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
