[PATCH 3/3] exa: properly wrap Create/DestroyPixmap in ExaCheckPolyArc and fix GC (un)wrapping.

Maarten Maathuis madman2003 at gmail.com
Thu Nov 12 11:30:44 PST 2009

2009/11/12 Michel Dänzer <michel at daenzer.net>:
> On Sat, 2009-11-07 at 13:32 +0100, Maarten Maathuis wrote:
>> - Fix the system that is required for it to actually work.
>> - The comment near the new macros explains the problem that existed before.
> I'm not sure it really explains why we need two levels of wrapping.

The 2nd level is needed is because you want to do something more than
usual wrapping.
The DestroyPixmap example is a nice one. If i use single wrapping i
loose fbDestroyPixmap which is unacceptable, because the chain has to
be like this: exaDestroyPixmapWithFinish->damageDestroyPixmap->exaDestroyPixmap->(w)fbDestroyPixmap,
with single wrapping this would be
which is a loop.

An alternative idea would be to put fallback checks/flags in all
acceleration functions, createpixmap, etc and do the right thing
And stop unwrapping gc ops altogether.

>> - Why it didn't cause issues before i don't know.
>> - We cannot unwrap the GC funcs, because they do prepare/finish access too.
>> - Protect against setting CreatePixmap twice (which would break swapping) in GC
>>   functions.
> Would it be feasible to make a general - not specific to PolyArc -
> solution, in case other fb hooks use / start using temporary pixmaps?

Yes, it can be extended, and as long as it concerns scratch pixmaps it
should be fine. It could even be made specific just for scratch

> --
> Earthling Michel Dänzer           |                http://www.vmware.com
> Libre software enthusiast         |          Debian, X and DRI developer

More information about the xorg-devel mailing list