[PATCH 3/3] exa: handle pixmap create/destroy in lower layers
Maarten Maathuis
madman2003 at gmail.com
Sat Nov 14 11:29:02 PST 2009
2009/11/14 Maarten Maathuis <madman2003 at gmail.com>:
> 2009/11/14 Michel Dänzer <michel at daenzer.net>:
>> On Fri, 2009-11-13 at 21:49 +0100, Maarten Maathuis wrote:
>>> - Pixmaps that are created during a fallback are automatically prepared access.
>>> - During the fallback accelerated ops are blocked to prevent new/scratch gc's
>>> from triggering accelerated ops on mapped pixmaps.
>>> - A few cases of incorrect wrapping (on the top level pointer instead of
>>> between damage and (w)fb) have been removed.
>>
>> Could add 'fixes http://bugs.freedesktop.org/show_bug.cgi?id=25078' to
>> the description.
>>
>
> That bug (because it's not GXcopy) seems to trigger another issue in
> miPolyArc, which seems unrelated to exa. The code in question is
> non-trivial however (it happens after miComputeArcs).
>
This bug occurs in the fTricky path and it doesn't crash on pixmap
access, but on some invalid arc pointer.
>>
>>> diff --git a/exa/exa_accel.c b/exa/exa_accel.c
>>> index 7e2dd70..eaeebe8 100644
>>> --- a/exa/exa_accel.c
>>> +++ b/exa/exa_accel.c
>>> @@ -1073,14 +1090,16 @@ exaFillRegionTiled (DrawablePtr pDrawable, RegionPtr pRegion, PixmapPtr pTile,
>>> * FillRegionSolid, saving numerous copies.
>>> */
>>> if (tileWidth == 1 && tileHeight == 1)
>>> - return exaFillRegionSolid(pDrawable, pRegion,
>>> + if (exaFillRegionSolid(pDrawable, pRegion,
>>> exaGetPixmapFirstPixel (pTile), planemask,
>>> - alu, clientClipType);
>>> + alu, clientClipType))
>>> + return TRUE;
>>
>> This part looks unrelated to the rest of the changes, please revert it
>> or move it to a separate patch with justification.
>>
>> With that fixed,
>>
>> Acked-by: Michel Dänzer <michel at daenzer.net>
>>
>>
>> --
>> Earthling Michel Dänzer | http://www.vmware.com
>> Libre software enthusiast | Debian, X and DRI developer
>>
>>
>>
>>
>
More information about the xorg-devel
mailing list