[Bug 28383] Cloned screens with different res/refresh cause problems with mesa demos since new dri2 vsync.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28383

--- Comment #2 from Mario Kleiner <mario.kleiner at tuebingen.mpg.de> 2010-06-09 06:45:36 PDT ---
Created an attachment (id=36178)
 View: https://bugs.freedesktop.org/attachment.cgi?id=36178
 Review: https://bugs.freedesktop.org/review?bug=28383&attachment=36178

Testpatch for dualhead hang when moving windows.

This quick & dirty patch disables the pPriv->last_swap_target mechanism for
implementing arbitrary swap_intervals for glXSwapBuffers with the DRI2 swap &
sync bits. Any swap interval > 0 is effectively treated as a swap interval of 1
(=vsync'ed swap). A zero swap_interval means immediate swap.

This should avoid hangs of windows (no longer updating) when they are moved
from a crtc with a higher refresh rate (e.g., 60 Hz) to a crtc with a lower
refresh rate (e.g., 50 Hz).

Assumed reason for the hang is that crtc's with different refresh rate will
differ / drift apart in their vblank counts after some time has passed. For
each drawable, the x-server keeps track of the last vblank count for which a
bufferswap was scheduled for a drawable in pPriv->last_swap_target. In
successive glXSwapBuffers() calls, this value is used as baseline for
scheduling the swap to satisfy the chosen pPriv->swap_interval. If a window
moves between crtc's, pPriv->last_swap_target is not updated prior to swap to
take the difference in vblank counts between old and new crtc into account.
Therefore a swap is scheduled far in the future, which causes the window to
hang for many seconds or minutes.

This quick & dirty patch forces swap at next vblank if swap_interval is > 0,
ignoring the stale last_swap_target value.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.