Patch that "fixes" compositor-x11

[Bill Spitzak]

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