On Fri, Apr 15, 2011 at 03:29:57PM -0400, Chase Douglas wrote: > 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 <[email protected]> > --- > I'm offering this up as a work around for whatever real bug exists. It > probably should not be committed upstream though. > > tools/syndaemon.c | 8 ++++++++ > 1 files changed, 8 insertions(+), 0 deletions(-) > > diff --git a/tools/syndaemon.c b/tools/syndaemon.c > index 0309fb5..1c799c6 100644 > --- a/tools/syndaemon.c > +++ b/tools/syndaemon.c > @@ -415,6 +415,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; > } > -- > 1.7.4.1 fair call, though I'd appreciate it if you could figure out why the events are sent on the record connection (and if that is indeed a bug or just unhandled behaviour on the syndaemon side).
pushed, thank you. Cheers, Peter _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
