System bell broken under X in Karmic

Bug #489855 reported by Grondr
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
xserver-xorg-video-nv (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Binary package hint: xorg

As far as I can determine, the system bell (e.g., built-in motherboard beeper) is completely broken in Karmic under X. Non-X beeping does work after extensive workarounds; please see bug #486154 for my hardware & software versions, what I did to enable the bell to work outside of X, and how I'm testing it. (For instance, I"m not just relynig on gnome---^G in Emacs doesn't work, either.)

However, nothing I've been able to do has made the bell work -in- X, and I'm assuming that this is either an X bug per se, or a Pulseaudio bug (simply because so many other audio issues seem to implicate PA). [Note that, as a test, I booted an AMD64 LiveCD and purged PA; this didn't help despite all my other workarounds, so if it's PA, I need a more-complete way to get rid of it.] For all I know, it's a Metacity bug. But I have no idea how to effectively figure out where to point the finger, and the common element seems to be X.

This is absolutely a regression. The same hardware works in, for example, 6.06, which predates the physical motherboard by years. This is also a completely blocker for my use of Karmic; I absolutely need the bell to function. (And workarounds like "use speakers" are no workarounds for me, and don't work anyway---the bell isn't coming out of those, either.)

Revision history for this message
Bryce Harrington (bryce) wrote :

Hi grondr,

Thanks for including the attached files. Could you also include your /var/log/Xorg.0.log (or Xorg.0.log.old) from after reproducing the issue?

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: needs-xorglog
tags: added: needs-lspci-vvnn
Changed in xorg (Ubuntu):
status: New → Incomplete
Revision history for this message
Grondr (grondr) wrote :

Sure thing. I'm attaching two slightly-different X logs (I don't know why the older one is talking about evdev but the newer one isn't). They're both from the amd64 LiveCD. I'd purged PulseAudio at some point and had been restarting X after various changes to see if anything happened; I don't know if both of these are from after nuking PA, but one certainly is, and I can always boot a fresh LiveCD and give you that if you want. The third attachment is lspci -vvnn run as root.

Please let me know if there is any other information you'd find useful, or if there are any further debugging steps I can take. I'm stymied. Thanks!

Revision history for this message
Grondr (grondr) wrote :
Revision history for this message
Grondr (grondr) wrote :
Revision history for this message
Grondr (grondr) wrote :
Revision history for this message
Grondr (grondr) wrote :

Just for yucks, here's the Xorg.log from the same LiveCD, freshly booted. (System bell doesn't work there, either, of course.)

Bryce Harrington (bryce)
affects: xorg (Ubuntu) → xserver-xorg-video-nv (Ubuntu)
Revision history for this message
Grondr (grondr) wrote :

[If you're happy with the data I attached, can someone please mark this as something other than "Incomplete" so it won't vanish? Thanks.]

I now think that this bug might not implicate X, or it might be a bad interaction where X's bell event is being mishandled by gnome/metacity/pulseaudio. Please see bug #486154, comment #8, for details.

(Note that that comment points out that I am still seeing what I believe to be a very longstanding bug in which "xset b volume pitch duration" is being incorrectly processed as "xset b duration pitch duration"; should I open a new bug on this? I note bug #280767, opened a year ago, reports this, and it even got action last week, but that action was to say that this behavior isn't an X bug with no other explanation. Is xset not part of X? Or it considered a kernel bug or something? I still run 5.04 (!) on one of my machines and the bug is -at least- that old, which makes it over 4.5 years old!)

Revision history for this message
Bryce Harrington (bryce) wrote :

Thank you for reporting this issue about xserver-xorg-video-nv. Starting
with Lucid, Ubuntu is transitioning to using the -nouveau video driver
by default instead of -nv. The reason for this change is because
upstream development for the -nv driver has been quite slow. We are
quite pleased with the upstream development speed for -nouveau, and hope
this will translate into swifter bug fixes as well.

Because of this, I'm closing this bug report at this time. I'm marking
it wontfix because what you describe is probably a valid issue, but we
do not have further plans to work on it in Ubuntu. If you would still like
to see this issue investigated, I would encourage you to file it
upstream at http://bugs.freedesktop.org/.

Changed in xserver-xorg-video-nv (Ubuntu):
status: Incomplete → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.