Created attachment 95746 [details] Picture of the displays in question I have a lenovo T430 (see attached dmesg, etc.) with 'optimus'. I wish to attach two external monitors. Helpfully, these are wired to the nvidia chip, and as such I am using intel-virtual-output to drive these screens. However, it appears there's something funny with the randr proxy. When I enable one screen, everything works as expected. When I enable two screens, they are tied together in strange ways: 1) Rotation of one virtual screen affects the other virtual screen 2) The virtual screens are always a 'clone', and when I would expect there to be 'extended' desktop, the (same) view on both monitors pans to follow my cursor. Please see attachments.
Created attachment 95747 [details] Screenshot showing the framebuffer arrangement
Created attachment 95748 [details] dmesg kernel buffer
Created attachment 95749 [details] xrandr -d :8
Created attachment 95750 [details] xrandr -d :0
Created attachment 95751 [details] Output from intel-virtual-output when initally run
Created attachment 95752 [details] Output from intel-virtual-output when subsequently run
Created attachment 95753 [details] full logs from intel-virtual-output
Created attachment 95755 [details] intel-virtual-output log that coincides with typescript (gzipped)
Created attachment 95756 [details] commands that go along with the log (apologies for the escape sequences)
Created attachment 95758 [details] xrandr -d :8 after typescript
Created attachment 95759 [details] xrandr -d :0 after typescript
Created attachment 95762 [details] Picture of the displays after typescript
Video of strange behavior: http://1drv.ms/1dWILaG
What's odd here is that we try to explicitly disable panning when copying the modes across. How about if we disable the remote outputs upon startup instead? diff --git a/tools/virtual.c b/tools/virtual.c index 8b8d511..2e94365 100644 --- a/tools/virtual.c +++ b/tools/virtual.c @@ -510,7 +510,18 @@ static int clone_update_modes__randr(struct clone *clone) } } - clone->dst.rr_crtc = from_info->crtc; + /* Disable the remote output */ + if (from_info->crtc) { + XRRPanning panning; + + DBG(("%s(%s-%s): disabling active CRTC\n", __func__, + DisplayString(clone->dst.dpy), clone->dst.name)); + XRRSetCrtcConfig(clone->dst.dpy, from_res, from_info->crtc, CurrentTime, + 0, 0, None, RR_Rotate_0, NULL, 0); + XRRSetPanning(dst->dpy, res, from_info->crtc, memset(&panning, 0, sizeof(panning))); + } + + clone->dst.rr_crtc = 0; /* Clear all current UserModes on the output, including any active ones */ if (to_info->crtc) {
Slightly safer: diff --git a/tools/virtual.c b/tools/virtual.c index 8b8d511..2d18aa4 100644 --- a/tools/virtual.c +++ b/tools/virtual.c @@ -510,7 +510,18 @@ static int clone_update_modes__randr(struct clone *clone) } } - clone->dst.rr_crtc = from_info->crtc; + /* Disable the remote output */ + if (from_info->crtc != clone->dst.rr_crtc) { + XRRPanning panning; + + DBG(("%s(%s-%s): disabling active CRTC\n", __func__, + DisplayString(clone->dst.dpy), clone->dst.name)); + XRRSetCrtcConfig(clone->dst.dpy, from_res, from_info->crtc, CurrentTime, + 0, 0, None, RR_Rotate_0, NULL, 0); + XRRSetPanning(dst->dpy, res, from_info->crtc, memset(&panning, 0, sizeof(panning))); + + clone->dst.rr_crtc = 0; + } /* Clear all current UserModes on the output, including any active ones */ if (to_info->crtc) {
Created attachment 95782 [details] [review] Disable remotes at startup Third time lucky; now it compiles.
Hmm, this looks to be a bug in how -nvidia handles SetPanning. Once again we need to find a workaround.
(In reply to comment #17) > Hmm, this looks to be a bug in how -nvidia handles SetPanning. Once again we > need to find a workaround. Would it help, then, to duplicate this setup but with nouveau?
Created attachment 95783 [details] [review] More DBG Please apply this patch to query the panning modes after we setup the remote CRTC, and then update the debug log.
Created attachment 95784 [details] [review] More DBG Compiles now.
Created attachment 95786 [details] [review] Mo I am having a bad day.
Created attachment 95804 [details] intel-virtual-output log as of f47f19
Created attachment 95805 [details] typescript (apologies for escape sequences)
SetPanning is broken. :(
Any luck with: diff --git a/tools/virtual.c b/tools/virtual.c index 0dfd308..64d345a 100644 --- a/tools/virtual.c +++ b/tools/virtual.c @@ -941,6 +941,20 @@ static int clone_init_xfer(struct clone *clone) return 0; } +static XRRPanning *set_panning(XRRPanning *p, struct output *o) +{ + memset(p, 0, sizeof(*p)); + + p->timestamp = CurrentTime; + + p->track_left = p->left = o->x; + p->track_top = p->top = o->y; + p->track_width = p->width = mode_width(&p->mode, p->rotation); + p->track_height = p->height = mode_height(&p->mode, p->rotation); + + return p; +} + static void clone_update(struct clone *clone) { if (!clone->rr_update) @@ -1254,7 +1268,7 @@ err: if (ret) goto err; - ret = XRRSetPanning(dst->dpy, res, rr_crtc, memset(&panning, 0, sizeof(panning))); + ret = XRRSetPanning(dst->dpy, res, rr_crtc, set_panning(&panning, dst)); DBG(("%s-%s: XRRSetPanning %s\n", DisplayString(dst->dpy), dst->name, ret ? "failed" : "success")); (void)ret;
Created attachment 95808 [details] [review] Set explicit panning area
Or perhaps: diff --git a/tools/virtual.c b/tools/virtual.c index 0dfd308..9233879 100644 --- a/tools/virtual.c +++ b/tools/virtual.c @@ -1247,6 +1247,10 @@ err: dst->x, dst->y, dst->mode.width, dst->mode.height, dst->rotation, (long)rr_crtc, dst->mode.id)); + ret = XRRSetPanning(dst->dpy, res, rr_crtc, memset(&panning, 0, sizeof(panning))); + DBG(("%s-%s: XRRSetPanning %s\n", DisplayString(dst->dpy), dst->name, ret ? "failed" : "success")); + (void)ret; + ret = XRRSetCrtcConfig(dst->dpy, res, rr_crtc, CurrentTime, dst->x, dst->y, dst->mode.id, dst->rotation, &dst->rr_output, 1); @@ -1254,10 +1258,6 @@ err: if (ret) goto err; - ret = XRRSetPanning(dst->dpy, res, rr_crtc, memset(&panning, 0, sizeof(panning))); - DBG(("%s-%s: XRRSetPanning %s\n", DisplayString(dst->dpy), dst->name, ret ? "failed" : "success")); - (void)ret; - if (EXTRA_DBG) { XRRCrtcInfo *c; XRRPanning *p;
I was able to get this to behave properly by interacting directly through the :8 display as follows: xrandr -d :8 --output DP-1 --panning 0x0+0+0 xrandr -d :8 --output DP-2 --panning 0x0+0+0 At this point, the mouse cursor did not cause panning, but the displays were still showing the same area of the framebuffer. xrandr -d :8 --output DP-2 --left-of DP-1 And everything is as it should be. $ xrandr -d :8 Screen 0: minimum 8 x 8, current 3000 x 1920, maximum 16384 x 16384 VGA-0 disconnected primary (normal left inverted right x axis y axis) LVDS-0 disconnected (normal left inverted right x axis y axis) DP-0 disconnected (normal left inverted right x axis y axis) DP-1 connected 1080x1920+1920+0 left (normal left inverted right x axis y axis) 477mm x 268mm 1920x1080 60.0*+ 1680x1050 60.0 1600x900 60.0 1280x1024 75.0 60.0 1280x800 59.8 1280x720 60.0 1024x768 75.0 60.0 800x600 75.0 60.3 640x480 75.0 59.9 DP-2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm 1920x1080 60.0*+ 1680x1050 60.0 1600x900 60.0 1280x1024 75.0 60.0 1280x800 59.8 1280x720 60.0 1024x768 75.0 60.0 800x600 75.0 60.3 640x480 75.0 59.9 DP-3 disconnected (normal left inverted right x axis y axis) DP-4 disconnected (normal left inverted right x axis y axis) DP-5 disconnected (normal left inverted right x axis y axis)
commit a55bbe3b598616ef4464e50cb9364c8cdf0b513a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Mar 14 15:47:20 2014 +0000 intel-virtual-output: Disable panning before setting mode on CRTC For whatever reason, presumably to do with the switch between CRTCs, we need to disable the panning before setting the mode in order for our desired CRTC position to take effect. Reported-by: Jeff Katz <bugzilla@kraln.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76146 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(In reply to comment #27) This patch yields behavior consistent with what I would expect, including odd offsets and rotations (set with arandr).
I think this would have hidden the problem, as it would have prevented the CRTC switching in your setup sequence: commit 8cc1f005c69786243ac69f6505087071787e6f87 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Mar 14 15:55:41 2014 +0000 intel-virtual-output: Iterate over remote outputs in the same order as listed If we walk the output lists in the same order as they are listed by RandR, we are more likely to hit favourable priority sorting. E.g. the user is likely to setup the outputs in the same order as listed, meaning fewer CRTC transitions etc. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
*** Bug 76270 has been marked as a duplicate of this bug. ***
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.