When changing the screen resolution of a VIRTUAL output that is cloned by intel-virtual-output using GNOME's display settings dialog to a smaller resolution, the panning of the discrete output is not changed. This results in the cloned display panning when moving the cursor to the edge. xrandr output with disconnected outputs and resolutions removed, intially: $ DISPLAY=:0 xrandr Screen 0: minimum 320 x 200, current 3280 x 1050, maximum 32767 x 32767 LVDS1 connected primary 1600x900+1680+104 (normal left inverted right x axis y axis) 309mm x 174mm VIRTUAL4 connected 1680x1050+0+0 0mm x 0mm $ DISPLAY=:8 xrandr Screen 0: minimum 8 x 8, current 1680 x 1050, maximum 16384 x 16384 DP-1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 433mm x 271mm Same, but after changing the resolution of the VIRTUAL output using GNOME's display settings dialog: $ DISPLAY=:0 xrandr Screen 0: minimum 320 x 200, current 3040 x 1004, maximum 32767 x 32767 LVDS1 connected primary 1600x900+1440+104 (normal left inverted right x axis y axis) 309mm x 174mm VIRTUAL4 connected 1440x900+0+0 0mm x 0mm $ DISPLAY=:8 xrandr Screen 0: minimum 8 x 8, current 1680 x 1050, maximum 16384 x 16384 DP-1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 430mm x 270mm panning 1680x1050+0+0
Can you please try: diff --git a/tools/virtual.c b/tools/virtual.c index 160d6a1..7957e58 100644 --- a/tools/virtual.c +++ b/tools/virtual.c @@ -1029,6 +1029,7 @@ err: XRRSetCrtcConfig(dst->dpy, res, rr_crtc, CurrentTime, dst->x, dst->y, dst->mode.id, dst->rotation, &dst->rr_output, 1); + XRRSetPanning(dst->dpy, res, rr_crtc, NULL); dst->rr_crtc = rr_crtc; } XUngrabServer(display->dpy);
Better: diff --git a/tools/virtual.c b/tools/virtual.c index 48fe347..c794bf3 100644 --- a/tools/virtual.c +++ b/tools/virtual.c @@ -954,6 +954,7 @@ static void context_update(struct context *ctx) struct output *src = &clone->src; struct output *dst = &clone->dst; XRROutputInfo *o; + XRRPanningInfo panning; struct clone *set; RRCrtc rr_crtc; @@ -1033,6 +1034,7 @@ err: XRRSetCrtcConfig(dst->dpy, res, rr_crtc, CurrentTime, dst->x, dst->y, dst->mode.id, dst->rotation, &dst->rr_output, 1); + XRRSetPanning(dst->dpy, res, rr_crtc, memset(&panning, 0, sizeof(panning))); dst->rr_crtc = rr_crtc; } XUngrabServer(display->dpy);
I tried that, but with s/XRRPanningInfo/XRRPanning/. It doesn't seem to help. (Side note: I'm only getting bugzilla's e-mails now - not sure why)
It would be useful to confirm if we have RandR 1.3: diff --git a/tools/virtual.c b/tools/virtual.c index a37838a..b8f933e 100644 --- a/tools/virtual.c +++ b/tools/virtual.c @@ -1854,6 +1854,7 @@ static void display_init_randr_hpd(struct display *display) if (!XRRQueryVersion(display->dpy, &major, &minor)) return; + printf("%s - randr version %d.%d\n", __func__, DisplayString(display->dpy), major, minor); if (major > 1 || (major == 1 && minor >= 2)) XRRSelectInput(display->dpy, display->root, RROutputChangeNotifyMask); }
Passing all zero to SetPanning should have the desired effect of passing xf86RandR13VerifyPanningArea() and returning false from PANNING_ENABLED(), and so disabling panning for the CRTC. I'm not sure how panning was ever enabled in the first place, but given RandR 1.3 that should be enough to turn if off again.
Ho hum, nvidia don't use xf86RandR13SetPanning and implement RandR directly in their driver so it seems.
Spotted that xrandr always turns off all displays and resizes the screen. That appears to be the missing ingredient.
commit 20e318c292a4e1336093dfbc77cb44d099c80050 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Nov 10 10:28:01 2013 +0000 intel-virtual-output: Manually adjust screen size When we modify the outputs and end up with a different screen size, we need to actually tell the display to resize with an explicit XRRSetScreenSize. Reported-by: Jethro Beekman <freedesktop-bugs@jbeekman.nl> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71441 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It doesn't apply cleanly, but ignoring the change in clone_paint, that seems to work. Thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.