diff options
| author | Chase Douglas <chase.douglas@canonical.com> | 2011-04-15 15:29:57 -0400 |
|---|---|---|
| committer | Peter Hutterer <peter.hutterer@who-t.net> | 2011-04-18 13:58:03 +1000 |
| commit | bdc9c7cf9767bda77c690cb4211f6f6cb4567748 (patch) | |
| tree | 798109481218c6eac60c39ad9575c895d28bc89c | |
| parent | fe05c60fee1f8fc24cc6cc2af7027d897607af2a (diff) | |
Drain XRecord connection of any events after handling replies
If the X server sends an event to the XRecord connection the event
will never be handled. This will cause the event queue to fill up in
Xlib and lead to syndaemon running away at 100% cpu usage.
This change drains any events from the connection. It's not a fix for
the underlying bug in the server or Xlib, but it does paper over the
issue for now.
https://bugs.launchpad.net/bugs/754470
http://bugs.freedesktop.org/show_bug.cgi?id=31921
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
| -rw-r--r-- | tools/syndaemon.c | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/tools/syndaemon.c b/tools/syndaemon.c index 9779935..47e0e6a 100644 --- a/tools/syndaemon.c +++ b/tools/syndaemon.c @@ -421,6 +421,14 @@ void record_main_loop(Display* display, double idle_time) { XRecordProcessReplies(dpy_data); + /* If there are any events left over, they are in error. Drain them + * from the connection queue so we don't get stuck. */ + while (XEventsQueued(dpy_data, QueuedAlready) > 0) { + XEvent event; + XNextEvent(dpy_data, &event); + fprintf(stderr, "bad event received, major opcode %d\n", event.type); + } + if (!ignore_modifier_keys && cbres.key_event) { disable_event = 1; } |