Keith Packard <[email protected]> writes:

> xf86Rotate, it was delaying unwrapping the BlockHandler until after
> calling xf86RotateRedisplay. If there was a software cursor on the
> screen, the redisplay operation would cause cursor to be removed from
> the frame buffer and the misprite block handler to be inserted into
> the block handler chain with the misprite screen private saved block
> handler now set to xf86RotateBlockHandler.
>
> When xf86RotateRedisplay returned, xf86RotateBlockHandler would then
> set screen->BlockHandler to its saved value, call down and then reset
> screen->BlockHandler to xf86RotateBlockHandler. miSpriteBlockHandler
> would never be called after that, which meant that the software cursor
> will now disappear from the screen whenever rendering overlapped and
> would only reappear when the cursor was moved.
>
> To correct this, all that is needed is to move the restoration of
> screen->BlockHandler to the top of xf86RotateBlockHandler, before the
> call to xf86RotateRedisplay.
>
> I've also added to this patch a check to see if the rotate block
> handler is still required and only re-insert itself if that is the
> case.
>
> There's also an enormous comment added to scrnintstr.h which details
> the required conventions for screen function wrapping.

I'm uncomfortable with you mashing these 3 changes together,
particularly the reinsertion change in what was supposed to be just a
bugfix commit.  It didn't take much grepping for me to find more code
that wasn't rewrapping the blockhandler according to these rules:

hw/xfree86/common/xf86VGAarbiterPriv.h:#define SCREEN_EPILOG(x,y) pScreen->x = 
y;

static void
VGAarbiterBlockHandler(ScreenPtr pScreen,
                       void *pTimeout, void *pReadmask)
{
    SCREEN_PROLOG(BlockHandler);
    VGAGet(pScreen);
    pScreen->BlockHandler(pScreen, pTimeout, pReadmask);
    VGAPut();
    SCREEN_EPILOG(BlockHandler, VGAarbiterBlockHandler);
}

Attachment: pgpyjrsV5zShh.pgp
Description: PGP signature

_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to