On 06/08/2012 10:26 PM, Bill Spitzak wrote:
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.
Ok, so we're dealing with different problems.
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?
I don't have any problems on my system, so running it here wouldn't
change anything. Also, I no longer have access to the system with the
problem with compiz.
Cheers,
Ander
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
