[PATCH] xf86RandR12: Don't call ConstrainCursorHarder() if panning is enabled
Panning is at odds with CRTC cursor confinement. This disables CRTC cursor
confinement as long as panning is enabled.
Fixes regression introduced in 56c90e29f04727c903bd0f084d23bf44eb1a0a11.
Signed-off-by: Rui Matos
---
hw/xfree86/modes/xf86RandR12.c | 37 +++--
1 files changed, 35 insertions(+), 2 deletions(-)
v3: Although this approach isn't semantically equivalent to the previous since
it completely disables CRTC cursor confinement while panning is enabled I
prefer it because it's shorter, cleaner and contained in a single file.
Anyway, panning still keeps working as it did, though not benefiting from
CRTC cursor confinement as it could. But, people using panning (are there
any?) surely know what they're doing.
diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
index 57b3b0e..426d8f4 100644
--- a/hw/xfree86/modes/xf86RandR12.c
+++ b/hw/xfree86/modes/xf86RandR12.c
@@ -60,6 +60,9 @@ typedef struct _xf86RandR12Info {
* See https://bugs.freedesktop.org/show_bug.cgi?id=21554
*/
xf86EnterVTProc *orig_EnterVT;
+
+Bool panning;
+ConstrainCursorHarderProcPtr orig_ConstrainCursorHarder;
} XF86RandRInfoRec, *XF86RandRInfoPtr;
#ifdef RANDR_12_INTERFACE
@@ -74,6 +77,9 @@ static DevPrivateKey xf86RandR12Key;
#define XF86RANDRINFO(p) ((XF86RandRInfoPtr) \
dixLookupPrivate(&(p)->devPrivates, xf86RandR12Key))
+#define PANNING_ENABLED(crtc) \
+((crtc)->panningTotalArea.x2 > (crtc)->panningTotalArea.x1 || \
+ (crtc)->panningTotalArea.y2 > (crtc)->panningTotalArea.y1)
static int
xf86RandR12ModeRefresh (DisplayModePtr mode)
@@ -687,6 +693,7 @@ xf86RandR12ScreenSetSize (ScreenPtr pScreen,
xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(pScrn);
WindowPtr pRoot = pScreen->root;
PixmapPtr pScrnPix;
+Boolpanning = FALSE;
Bool ret = FALSE;
int c;
@@ -708,8 +715,7 @@ xf86RandR12ScreenSetSize (ScreenPtr pScreen,
/* Update panning information */
for (c = 0; c < config->num_crtc; c++) {
xf86CrtcPtr crtc = config->crtc[c];
- if (crtc->panningTotalArea.x2 > crtc->panningTotalArea.x1 ||
- crtc->panningTotalArea.y2 > crtc->panningTotalArea.y1) {
+ if (PANNING_ENABLED (crtc)) {
if (crtc->panningTotalArea.x2 > crtc->panningTrackingArea.x1)
crtc->panningTotalArea.x2 += width - pScreen->width;
if (crtc->panningTotalArea.y2 > crtc->panningTrackingArea.y1)
@@ -720,9 +726,12 @@ xf86RandR12ScreenSetSize (ScreenPtrpScreen,
crtc->panningTrackingArea.y2 += height - pScreen->height;
xf86RandR13VerifyPanningArea (crtc, width, height);
xf86RandR13Pan (crtc, randrp->pointerX, randrp->pointerY);
+panning = TRUE;
}
}
+randrp->panning = panning;
+
pScrnPix = (*pScreen->GetScreenPixmap)(pScreen);
pScreen->width = pScrnPix->drawable.width = width;
pScreen->height = pScrnPix->drawable.height = height;
@@ -925,6 +934,7 @@ xf86RandR12CloseScreen (ScreenPtr pScreen)
randrp = XF86RANDRINFO(pScreen);
#if RANDR_12_INTERFACE
xf86Screens[pScreen->myNum]->EnterVT = randrp->orig_EnterVT;
+pScreen->ConstrainCursorHarder = randrp->orig_ConstrainCursorHarder;
#endif
free(randrp);
@@ -1226,6 +1236,7 @@ xf86RandR12CrtcSet (ScreenPtr pScreen,
}
xf86RandR13VerifyPanningArea (crtc, pScreen->width,
pScreen->height);
xf86RandR13Pan (crtc, randrp->pointerX, randrp->pointerY);
+randrp->panning = PANNING_ENABLED (crtc);
/*
* Save the last successful setting for EnterVT
*/
@@ -1650,6 +1661,7 @@ xf86RandR13SetPanning (ScreenPtr pScreen,
{
XF86RandRInfoPtr randrp = XF86RANDRINFO(pScreen);
xf86CrtcPtrcrtc = randr_crtc->devPrivate;
+BoololdPanning = randrp->panning;
BoxRec oldTotalArea;
BoxRec oldTrackingArea;
INT16 oldBorder[4];
@@ -1671,12 +1683,14 @@ xf86RandR13SetPanning (ScreenPtr pScreen,
if (xf86RandR13VerifyPanningArea (crtc, pScreen->width, pScreen->height)) {
xf86RandR13Pan (crtc, randrp->pointerX, randrp->pointerY);
+randrp->panning = PANNING_ENABLED (crtc);
return TRUE;
} else {
/* Restore old settings */
memcpy (&crtc->panningTotalArea,&oldTotalArea,sizeof(BoxRec));
memcpy (&crtc->panningTrackingArea, &oldTrackingArea, sizeof(BoxRec));
memcpy (crtc->panningBorder, oldBorder, 4*sizeof(INT16));
+randrp->panning = oldPanning;
return FALSE;
}
}
@@ -1761,6 +1775,21 @@ xf86RandR12EnterVT (int screen_index, int flags)
return RRGetInfo (pScreen, TRUE); /* force
Re: [PATCH v2][xdm] Implement ConsoleKit support.
On 07/22/11 12:49 PM, Julien Cristau wrote: > Is ck relevant to anything !linux? We have it on Solaris, I think because gdm made us. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2][xdm] Implement ConsoleKit support.
On Mon, Jun 27, 2011 at 21:04:25 +0200, Cyril Brulebois wrote:
> +static int openCKSession(struct verify_info *verify, struct display *d)
> +{
> +int ret;
> +DBusError error;
> +char *remote_host_name = "";
> +dbus_bool_t is_local;
> +char *display_name = "";
> +char *display_device = "";
> +char devtmp[16];
> +
> +if (!use_consolekit)
> + return 1;
> +
> +is_local = d->displayType.location == Local;
> +if (d->peerlen > 0 && d->peer)
> + remote_host_name = d->peer;
> +if (d->name)
> + display_name = d->name;
> +/* how can we get the corresponding tty at best...? */
> +if (d->windowPath) {
> + display_device = strchr(d->windowPath, ':');
> + if (display_device && display_device[1])
> + display_device++;
> + else
> + display_device = d->windowPath;
> + snprintf(devtmp, sizeof(devtmp), "/dev/tty%s", display_device);
Is ck relevant to anything !linux? If so, that path is probably wrong.
I'm not quite sure what ck users would do with that information, though,
and a quick codesearch doesn't really help. So maybe we should just not
set that…
> + display_device = devtmp;
> +}
> +
> +connector = ck_connector_new();
> +if (!connector) {
> + LogOutOfMem("ck_connector");
> + return 0;
> +}
> +
> +dbus_error_init(&error);
> +ret = ck_connector_open_session_with_parameters(
> + connector, &error,
> + "unix-user", &verify->uid,
> + "x11-display", &display_name,
> + "x11-display-device", &display_device,
> + "remote-host-name", &remote_host_name,
> + "is-local", &is_local,
> + NULL);
> +if (!ret) {
> + if (dbus_error_is_set(&error)) {
> + LogError("Dbus error: %s\n", error.message);
> + dbus_error_free(&error);
> + } else {
> + LogError("ConsoleKit error\n");
> + }
> + LogError("console-kit-daemon not running?\n");
> + ck_connector_unref(connector);
> + connector = NULL;
> + return 0;
Is "ck-daemon isn't running" a good reason to prevent the user from
logging in? (Why?)
> +}
> +
> +verify->userEnviron = setEnv(verify->userEnviron,
> + "XDG_SESSION_COOKIE", (char
> *)ck_connector_get_cookie(connector));
> +return 1;
> +}
> +
Cheers,
Julien
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] composite: Inhibit window background paint with manual subwindow redirection
On Thu, 2011-07-21 at 00:24 +0300, Ville Syrjälä wrote: > > I did actually have to see it live to figure out what was going on ... > > but once I saw it, and thought about it a bit, I was able to avoid > > digging out the debugger. > > > > What's going on is that for a window with a non-None background, the > > copying between the parent pixmap and the composite pixmap that we do > > isn't sufficient - all that copying is doing is making sure that things > > _look_ right initially - it doesn't actually suppress expose event > > generation and the background painting that happens during expose event > > generation. > > The pointless expose events were supposed to be eliminated by another > patch set [1]. At least my test app [2] manages to redirect/unredirect > non-None windows w/o generating unnecessary expose events. Hmm, OK, I had those patches applied, but figured that the expose events were being generated by some other path than Map/Unmap. It turns out that they were being generated because my test Mutter code wasn't ordering things correctly. With that fixed, I can't reproduce any flickering with Evince. It redirects and unredirects seamlessly when I pop up a menu. (This is with GTK+-3, but there shouldn't be any difference from GTK+-2 in this regard.) So, I'm not sure what was happening in your testing but I'm pretty happy with how things are working for me! - Owen ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
