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 MUCH more common
in startx-from-recovery-mode (where most configurations show the behavior)
compared to normal
boot-into-gdm (where it only shows up on a machine that -has not- run
xkbbell since boot).
NOTE that this is probably NOT a metacity bug, since my testing from a
recovery-mode boot
showed that the vanishing bells happen even if X has never run.
I doubt that the metacity maintainers are reading this bug; I'm considering
opening a bug there
and pointing them at this so at least (a) above might get addressed. If
someone else does so
first, post here so we know.
[All of the text above, plus a table of resutls & testing conditions,
attached.]
** Attachment added: "bug-characterization"
http://launchpadlibrarian.net/36854205/bug-characterization
--
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
Desktop Bugs, which is subscribed to metacity in ubuntu.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
