On Tue, 2009-07-21 at 12:14 +0200, Maarten Maathuis wrote:
> > +/* If slot for this index is taken, find an empty slot */
> > +if (pExaScr->access[index].pixmap) {
> > + for (index = EXA_NUM_PREPARE_INDICES - 1; index >= 0; index--)
> > + if (!pExaScr->access[index].pixmap)
> + /* If slot for this index is taken, find an empty slot */
> + if (pExaScr->access[index].pixmap) {
> + for (index = EXA_NUM_PREPARE_INDICES - 1; index >= 0; index--)
> + if (!pExaScr->access[index].pixmap)
> break;
> + }
Maybe add a note in the headerfil
[ Please quote what you're referring to ]
On Sun, 2009-07-19 at 12:25 +0200, Maarten Maathuis wrote:
> That would suggest creating a GC that completely bypasses exa.
I'm not sure that would really be a problem, but anyway it turns out
this doesn't work because GetScratchGC() may return a pre-all
Maarten Maathuis wrote:
> That would suggest creating a GC that completely bypasses exa.
>
> The proper solution seems like adding more indices or at least
> detecting that the indices are being used.
>
> I'll write a patch as soon as my system is in order again.
>
> Maarten.
>
>
Seems o.k. her
That would suggest creating a GC that completely bypasses exa.
The proper solution seems like adding more indices or at least
detecting that the indices are being used.
I'll write a patch as soon as my system is in order again.
Maarten.
___
xorg mailin
Michel Dänzer wrote:
> On Sat, 2009-07-18 at 15:25 +0200, Maarten Maathuis wrote:
>
>> I'm trying to get my system in order again, but i'll certainly have a
>> look once i go trough the tons of updates and everything else that
>> needs doing.
>>
>> So someone is using scratch GC and not finishi
On Sat, 2009-07-18 at 15:25 +0200, Maarten Maathuis wrote:
> I'm trying to get my system in order again, but i'll certainly have a
> look once i go trough the tons of updates and everything else that
> needs doing.
>
> So someone is using scratch GC and not finishing or preparing access
> properl
Maarten Maathuis wrote:
> I'm trying to get my system in order again, but i'll certainly have a
> look once i go trough the tons of updates and everything else that
> needs doing.
>
> So someone is using scratch GC and not finishing or preparing access properly?
>
> I'm wondering why it becomes unb
I'm trying to get my system in order again, but i'll certainly have a
look once i go trough the tons of updates and everything else that
needs doing.
So someone is using scratch GC and not finishing or preparing access properly?
I'm wondering why it becomes unbalanced.
Maarten.
_
On Sat, 2009-07-18 at 09:23 +0200, Maarten Maathuis wrote:
> Hmm, that is really funny.
>
> I just got home again and you are one of many who has reported these warnings.
>
> You are sure a mesa update was the thing to fix it?
Maarten, the Prepare/FinishAccess tracking code you added to EXA brea
Maarten Maathuis wrote:
> Hmm, that is really funny.
>
> I just got home again and you are one of many who has reported these warnings.
>
> You are sure a mesa update was the thing to fix it?
>
> Maarten.
>
>
From what I remember I compiled drm, and mesa(.tar.balls)
before compiling anything e
Hmm, that is really funny.
I just got home again and you are one of many who has reported these warnings.
You are sure a mesa update was the thing to fix it?
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman
> EXA bug: Calling FinishAccess on pixmap 0xaf06d008 with index 1 while
> it should have been (nil).
> EXA bug: Calling FinishAccess on pixmap 0xaf06d008 with index 1 while
> it should have been (nil).
> EXA bug: Calling FinishAccess on pixmap 0xaf06d008 with index 1 while
> it should
index 1 while
it should have been (nil).
EXA bug: Calling FinishAccess on pixmap 0xaf06d008 with index 1 while
it should have been (nil).
EXA bug: Calling FinishAccess on pixmap 0xaf06d008 with index 1 while
it should have been (nil).
EXA bug: Calling FinishAccess on pixmap 0xaf06d008 with index 1
14 matches
Mail list logo
