[PATCHv2 1/2] DRI2: Track DRI2 drawables as resources, not privates

Pierre Willenbrock pierre at pirsoft.dnsalias.org
Fri Apr 23 06:01:33 PDT 2010


Michel Dänzer schrieb:
> On Fre, 2010-04-09 at 14:18 -0400, Kristian Høgsberg wrote: 
>> The main motivation here is to have the resource system clean up the
>> DRI2 drawable automatically so glx doesn't have to.  Right now, the
>> glx drawable resource must be destroyed before the X drawable, so that
>> calling DRI2DestroyDrawable doesn't crash.  By making the DRI2
>> drawable a resource, GLX doesn't have to worry about that and the
>> resource destruction order becomes irrelevant.
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=26394
>>
>> Signed-off-by: Kristian Høgsberg <krh at bitplanet.net>
> 
> There's a problem with this change (and potentially in DRI2SwapEvent()
> even before it): at least the pixmaps backing redirected windows still
> have ->drawable.id == 0. This can result in weird behaviour with a GLX
> compositing manager, e.g. when running the same app twice in a row: the
> second window will show a static snapshot of the first one, because the
> compositing manager gets the DRI2 front buffer from the first, since
> destroyed window.

I had this happen inside the same instance of a few apps, if the pixmap
dimensions match. The second window just shows a duplicate of the first
windows, changing whenever the first window changes(until the second
window is resized).

> The patch below fixes that symptom, but I'm not sure it's correct. Right
> now I'm getting memory corruption when logging out or just restarting
> compiz, but then again people seem to be reporting such symptoms against
> server-1.8-branch anyway.

I tested this patch with xserver running in valgrind, and could not find
any new memory problems. (There is just an old issue of use in
miSpriteDeviceCursorCleanup after free in FreeAllResources of a Picture.)

Testing used a full session including kdm login and logout, and a forced
restart of kwin(in glx compositing mode, of course). Xserver
regeneration is not used here.

Regards,
  Pierre


More information about the xorg-devel mailing list