[PATCH 2/4] present: don't vblank abort pending flip during window destruction

[Frank Binns]

On 26/04/14 00:39, Keith Packard wrote:
> Frank Binns <frank.binns at imgtec.com> writes:
>
>> As part of present's window destroy function, any vblanks associated with
>> the destroyed window are aborted and destroyed. However, this can include
>> a pending flip. This means that when the corresponding flip event is
>> finally processed it gets ignored. As a result, any deferred unflip is
>> never performed and, more importantly, the now idle pixmap is never
>> destroyed. This results in a leak between server resets.
>>
>> Fix this by preventing any pending flip, associated with the window being
>> destroyed, from being aborted and destroyed during window destruction.
> Yeah, we can't do that -- the whole point of the present_abort_vblank is
> to make sure everything associated with that vblank is gone before the
> serve resets. We don't have any guarantee that the notify will be
> received before the server has reset.
>
> So, what we need to do is to have present_abort_vblank do all of the
> related clean up, including setting the window pixmaps and freeing the
> pixmap so that it doesn't get leaked. We can assume that the driver will
> hold a reference to any data structures related to the scanout until
> it's actually freed and not do that up in DIX as well.
>

present_flip_destroy() suggests that there can be a pending flip at
screen close time. In this case, an unflip is scheduled to be done once
the flip event comes through. However, without this patch the event
gets ignored, due to present_abort_vblank() being called on the
pending flip, meaning that the unflip is never performed.

Interestingly, there is a comment in present_flip_destroy() that says
"XXX this needs to be synchronous for server reset". Presumably
this is related to the need to wait for the pending flip event to come
through so that the unflip can be performed. We achieve this in the
PVR video driver by having our own close screen function that waits
for any pending events to come through.

 From what you've said, this is the wrong approach. However, how
do we then perform the unflip given that we need to wait for the
pending flip to complete before it can be done?