Actually I am running classic with no effects already and I am having
this bug.
That explains why nothing happened when I ran ccsm and turned the
detector on/off. There was no program to kill/restart.
Unless the x11_compositor_handle_event() is the *last* thing called
before it does the epoll, I think there could be a problem. If it does a
composite afterwards that will do some xcb calls and perhaps make the fd
non-ready even though events are ready. However my explanation still
requires there to be bugs in xcb as it obviously eventually calls
x11_compositor_handle_event and that still only reads one of the events
even though it calls xcb_wait.
Can you find out if my "fix" of printing to a terminal on the same
screen also works on your system?
Ander Conselvan de Oliveira wrote:
On 06/08/2012 09:22 AM, Bill Spitzak wrote:
On 06/07/2012 02:33 AM, Ander Conselvan de Oliveira wrote:
I looked at Christophe's machine that has the same problem. He was also
running Ubuntu 11.04 on classic mode. It looks like the problem might be
in compiz with this particular configuration. When I disabled the
"detection" extension on ccsm, compiz restarted and weston started to
run fine. The problem returned after a log out/log in cycle. The
extension was disable and turning it back on fixed the problem again. So
it seems the reset caused by ccsm that actually fixed the issues. Since
the problem seems to be in compiz, I stopped debugging.
I tried a few things called "detection" on ccsm, but none of them made
compiz restart as far as I can tell, and none of them make any
difference for me.
The extension I disabled dealt with blacklisting know bad drivers or PCI
ids. Christophe's locale is fr_FR, so maybe the name is different for you.
I suspect there is a problem: xcb_poll can return true even if the fd is
not ready, because there are events already read into the internal
queue. However it should read *all* pending events once it decides to
read one, so it should not produce the slowness, just latency.
I think compositor-x11 needs to call xcb_poll just before it calls epoll
with a non-zero timeout. I'm going to check if this fixes it.
I don't think that would make any difference. The way the event loop
works, x11_compositor_handle_event() is called even if there is nothing
to read on the fd, exactly because of the internal queue. This logic is
in the libwayland-server (c.f. wayland/src/event-loop.c). The event
source for the xcb connection should be on the check_list for the
post_dispatch_check.
Anyway, what drove me to the conclusion that this is compiz related is
the fact that the problem won't happen when running in Ubuntu Classic
mode with no effects. Killing compiz also made the Weston window
responsive again. Christophe also had a cpu/memory/etc indicator on his
panel and it would slow down when moving the pointer over Weston's window.
I won't have access to Christophe's machine again and I can't reproduce
the problem on my machine (even though I'm running Ubuntu 11.04, it
doesn't happen here, not even in Ubuntu Classic mode) so I can't debug
this any further.
Cheers,
Ander
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
