[PATCH] DRI2: fixup handling of last_swap_target

[Jesse Barnes]

On Mon, 8 Mar 2010 20:13:21 +0100
Mario Kleiner <mario.kleiner at tuebingen.mpg.de> wrote:
> The glxgears.c of mesa only does draw -> glXSwapBuffers -> draw ->  
> glXSwapBuffers -> ...
> It doesn't use any of the new api's, so the only way it can block is  
> probably via the DRI2ThrottleClient call when requesting a "new"  
> backbuffer.
> 
> I see at least one problematic thing. In the xserver's dri2.c file in  
> DRI2SwapBuffers(), the pPriv->swapsPending++ statement is *after* the  
> call into the ddx's I830DRI2ScheduleSwap() function, instead of  
> *before* it. If a swap completes inside the ddx, it will call  
> DRI2SwapComplete() which will do a pPriv->swapsPending-- before it  
> was incremented to mark a swap as pending. That is, if swapsPending  
> was zero before, it will now wrap around to 0xffffffff. This will  
> happen if the fallback_blit path inside the ddx is used, e.g., if the  
> drawable is not visible (yet).

Or if composited; it may be offscreen.

> 
> Not sure if this by itself is sufficient for the hang, because the  
> call to pPriv->swapsPending++ after return from I830DRI2ScheduleSwap  
> () should fix this, but if something else goes wrong and an error  
> path is taken or an event not delivered, then swapsPending could get  
> stuck at 0xffffffff or a similar high number, which would trigger  
> DRI2ThrottleClient and block the client connection without ever  
> waking it up again, as clients are only woken up if a swap completes,  
> which can't happen if no swap is pending. -> hang in _XReply on the  
> client side.
> 
> So we should probable move pPriv->swapsPending++ before the call to...
> 
>      ret = (*ds->ScheduleSwap)(client, pDraw, pDestBuffer, pSrcBuffer,
>                                swap_target, divisor, remainder, func,  
> data);
> 
> ... in DRI2SwapBuffers() and probably add a pPriv->swapsPending--  
> into the error handling path directly after the call to ds- 
>  >ScheduleSwap.

Yep, that's the safer thing to do.  Florian, can you give that a try
and see if it helps your situation?

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center