frederik
/
xserver
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

render: Unwrap early on the animated cursor BlockHandler 

The loop above the previous call may end up triggering other
handlers attaching to the same function slot, so unwrapping
the handler after that could leave the just attached handler
in a dangling but not unset state.

This issue was most visible on the XO, where destroying a
window with an animated cursor set and running  would trigger
this inconsistent state, never calling the miSpriteBlockHandler
again after the animated cursor is unset.

Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This commit is contained in:
Carlos Garnacho 2012-12-19 18:42:39 +01:00 committed by Peter Hutterer
parent 0fbd779a82
commit df746a7341
1 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
render/animcur.c
View File

@ -143,6 +143,8 @@ AnimCurScreenBlockHandler(ScreenPtr pScreen,
Bool activeDevice = FALSE;
CARD32 now = 0, soonest = ~0; /* earliest time to wakeup again */
Unwrap(as, pScreen, BlockHandler);
for (dev = inputInfo.devices; dev; dev = dev->next) {
if (IsPointerDevice(dev) && pScreen == dev->spriteInfo->anim.pScreen) {
if (!activeDevice) {
@ -180,7 +182,6 @@ AnimCurScreenBlockHandler(ScreenPtr pScreen,
if (activeDevice)
AdjustWaitForDelay(pTimeout, soonest - now);
Unwrap(as, pScreen, BlockHandler);
(*pScreen->BlockHandler) (pScreen, pTimeout, pReadmask);
if (activeDevice)
Wrap(as, pScreen, BlockHandler, AnimCurScreenBlockHandler);