summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChase Douglas <chase.douglas@canonical.com>2011-04-15 15:29:57 -0400
committerPeter Hutterer <peter.hutterer@who-t.net>2011-04-18 14:06:38 +1000
commit27d04237d60ba0bcd0dafa30f9fd076e80e4d2f6 (patch)
tree52c7c89123a0f641a248e7c247edecc12dd9982e
parentae226ae5c90b9c6724e1f1cd44e6d223641e59fa (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> (cherry picked from commit bdc9c7cf9767bda77c690cb4211f6f6cb4567748)
-rw-r--r--tools/syndaemon.c8
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;
}