Patch that "fixes" compositor-x11

[Ander Conselvan de Oliveira]

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