On Fri, 2008-11-28 at 17:49 +0100, Matthias Hopf wrote:
> + if (crtc->funcs->pan &&
> + memcmp (mode, &saved_mode, sizeof(saved_mode)) == 0 &&
> + saved_rotation == rotation) {
> + crtc->funcs->pan (crtc, crtc->x, crtc->y);
> + ret = TRUE;
> + goto done;
> + }
I think this also need to check for transformation changes? And output
property changes?
> +/**
> + * Pans the screen, does not change the mode
> + */
Should we call the low-level operation 'set_origin' instead of 'pan'?
> + int pointerX;
> + int pointerY;
I'd prefer to not shadow the pointer position inside RandR; is there
some way we can use the DIX pointer position here?
We should also start to consider how MPX plays with panning.
> +static Bool
> +xf86RandR13SetPanning (ScreenPtr pScreen,
> + RRCrtcPtr randr_crtc,
> + BoxPtr totalArea,
> + BoxPtr trackingArea,
> + INT16 *border)
> +{
> + XF86RandRInfoPtr randrp = XF86RANDRINFO(pScreen);
> + xf86CrtcPtr crtc = randr_crtc->devPrivate;
> + int ret;
> +
> + if (crtc->version < 2)
> + return FALSE;
> + if (totalArea)
> + memcpy (&crtc->panningTotalArea, totalArea, sizeof(BoxRec));
> + if (trackingArea)
> + memcpy (&crtc->panningTrackingArea, trackingArea, sizeof(BoxRec));
> + if (border)
> + memcpy (crtc->panningBorder, border, 4*sizeof(INT16));
> + ret = xf86RandR13VerifyPanningArea (crtc, pScreen->width,
> pScreen->height);
> + xf86RandR13Pan (crtc, randrp->pointerX, randrp->pointerY);
Probably need to verify before setting -- protocol requests should
either succeed or fail without side effects. It looks to me like we
smash the old settings before checking the requested data. That would
mean that VerifyPanningArea would take the three rectangles as separate
arguments instead of pulling them from the crtc.
--
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
