Hi,
On 19 December 2014 at 15:02, Pekka Paalanen wrote:
> On Fri, 19 Dec 2014 08:08:33 -0600
> Derek Foreman wrote:
>> On 19/12/14 06:40 AM, Pekka Paalanen wrote:
>> > There is some fancy input scheduling going on with the repaint loop, so
>> > that input events would be sent as a burst to the c
On Fri, 19 Dec 2014 08:08:33 -0600
Derek Foreman wrote:
> On 19/12/14 06:40 AM, Pekka Paalanen wrote:
> > On Fri, 12 Dec 2014 14:29:42 -0600
> > Derek Foreman wrote:
> >
> >> I just noticed that the follow patch *exactly* undoes commit 22ba60e
> >>
> >> Is there any other reason that commit was
On 19/12/14 06:40 AM, Pekka Paalanen wrote:
> On Fri, 12 Dec 2014 14:29:42 -0600
> Derek Foreman wrote:
>
>> I just noticed that the follow patch *exactly* undoes commit 22ba60e
>>
>> Is there any other reason that commit was necessary, or was it intended
>> to be cosmetic?
>
> No, I don't think
On Fri, 12 Dec 2014 14:29:42 -0600
Derek Foreman wrote:
> I just noticed that the follow patch *exactly* undoes commit 22ba60e
>
> Is there any other reason that commit was necessary, or was it intended
> to be cosmetic?
No, I don't think it was meant to be cosmetic.
There is some fancy input
I just noticed that the follow patch *exactly* undoes commit 22ba60e
Is there any other reason that commit was necessary, or was it intended
to be cosmetic?
On 12/12/14 02:12 PM, Derek Foreman wrote:
> While it conceptually makes sense to put the x11 event handler
> in the compositor "input" loop
While it conceptually makes sense to put the x11 event handler
in the compositor "input" loop, the input loop is actually
dispatched in the middle of the frame repaint. When the
X11 event results in closing the compositor, this can cause
the current output to be destroyed just prior to trying to
p
