After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 322032 - permanent visual bell hangs metacity
permanent visual bell hangs metacity
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
2.12.x
Other Linux
: High major
: 2.14.x
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks:
 
 
Reported: 2005-11-21 13:48 UTC by Stanislav Brabec
Modified: 2006-01-20 22:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Don't respond to visual bells more than once per second (1.64 KB, patch)
2006-01-09 23:03 UTC, Elijah Newren
needs-work Details | Review
Add parentheses, move code to display.c, replace static var with entry in MetaDisplay (2.46 KB, patch)
2006-01-12 06:13 UTC, Elijah Newren
committed Details | Review

Description Stanislav Brabec 2005-11-21 13:48:20 UTC
Distribution/Version: SuSE Linux 10.0 + supplementary GNOME 2.12.1

How to reproduce:
1. Set single window visual bell
2. while : ; do echo -en '\007' ; done

Actual behavior:
metacity stops responding

Related: bug 170006
Comment 1 Elijah Newren 2006-01-09 23:03:40 UTC
Created attachment 57073 [details] [review]
Don't respond to visual bells more than once per second

Wow, that was really annoying.  I had to run a couple different killall's after sshing in from my laptop to recover.

Anyway, also fixes bug 170006 since the rate limiting isn't specific to the flashing type.
Comment 2 Havoc Pennington 2006-01-10 02:59:13 UTC
Comment on attachment 57073 [details] [review]
Don't respond to visual bells more than once per second

If inserting parens around time1/time2 in the time_is_before macro, should probably do it for all occurrences of time1/time2 in the macro.

I think the static variable feels ugly, and also wouldn't we want to rate limit audible bell too? I would think the last bell time should go in the display object, and we should filter out the bell event completely (don't handle it either audible or visible)
Comment 3 Elijah Newren 2006-01-10 17:52:26 UTC
Perhaps I'm being dense, but I don't see what you mean by filtering out the audible bell since we I don't see where we handle it.  It does look like we're instructing XKB to turn the audible bell off when we turn the visible bell on, but isn't that the limit of what we do.  Wasn't helped by the fact that I had a hard time finding documentation for XKB functions...have any helpful pointers?

Adding extra parens in the macro and moving to display all seem fine.  I'm just not sure what you want or mean in regards to the audible bell.
Comment 4 Havoc Pennington 2006-01-11 02:41:10 UTC
I thought we did do the audible bell, in order to get a better sound than the PC speaker beep. I guess I was thinking of some patch or bug and not actual code.
Comment 5 Elijah Newren 2006-01-11 02:47:28 UTC
Ah, ok, makes more sense now.  And now that you put it in those terms, a quick bugzilla query makes me think that you probably had bug 315859 in mind...sound right?
Comment 6 Elijah Newren 2006-01-12 06:13:28 UTC
Created attachment 57193 [details] [review]
Add parentheses, move code to display.c, replace static var with entry in MetaDisplay

I think this covers everything you suggested.  Did I miss anything?