This is a relaunch of https://bugs.freedesktop.org/show_bug.cgi?id=76271 . Ubuntu 13.10, Intel video driver and i-v-o from Git (ef178f7). One of my two external screens is not repainted and does not even show the cursor. In "perf top", heavy usage is shown for nvidia_drv.so and [drm] when running glxgears: 35.94% [drm] [k] drm_clflush_page 9.90% nvidia_drv.so [.] 0x000000000007f0a4 8.88% [kernel] [k] mutex_spin_on_owner 4.39% [kernel] [k] __sg_page_iter_next.part.9 3.00% i965_dri.so [.] 0x0000000000032a36 2.40% [kernel] [k] __sg_page_iter_next 2.14% [kernel] [k] mspin_lock 2.04% intel_drv.so [.] memcpy_from_tiled_x__swizzle_9_ 0.87% [kernel] [k] __ticket_spin_lock 0.87% perf [.] 0x000000000004bb42 0.81% libxul.so [.] 0x00000000018f56ee 0.62% Xorg [.] 0x000000000013d3b8 0.59% libdrm_intel.so.1.0.0 [.] 0x00000000000066a2 0.58% libdricore9.2.1.so.1.0.0 [.] 0x0000000000149852 0.52% [i915] [k] ivybridge_irq_handler 0.50% [drm] [k] drm_clflush_sg No heavy lag anymore. Things to check: - Stock video driver (I think this works, but will re-check) - Setting Option "AllowSHMPixmaps" "true" in /etc/bumblebee/xorg.conf.nvidia (will check) - Attach debug output from i-v-o - ?
Which kernel is that? (Where is all that clflush coming from?!) Can you capture the i-v-o debug log (change the #if 0 in virtual.c and run with -f)?
Also xrandr -d :0 and xrandr -d: 8
Linux vpl-thinkpad10-13 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Created attachment 98468 [details] Log with Option "AllowSHMPixmaps" "true" in /etc/bumblebee/xorg.conf.nvidia Had to kill i-v-o using kill -9
Created attachment 98469 [details] "Normal" i-v-o log One of the external displays is not repainted
Created attachment 98470 [details] xrandr output for both displays in one file ( xrandr; xrandr -d :8 ) > xrandr.log
I've reinstalled stock drivers (Ubuntu 13.10) using apt-get install xserver-xorg-video-all Xorg.0.log now shows SNA compiled: xserver-xorg-video-intel 2:2.99.904-0ubuntu2.1 (Robert Hooker <sarvatt@ubuntu.com>) The issue persists. On the other hand, the "stable" version of i-v-o, ecc20fb, still works without fail on the stock drivers.
The "stable" version of i-v-o also works with the most recent drivers: intel(0): SNA compiled from 2.99.911-132-gef178f7
The issue is that the nvidia driver still doesn't like the commands to disable CRTCs and update the panning area.
This should fix up the errors with enabling ShmPixmaps in the nvidia driver: commit a93d2d4f910dc66fe7114a4f44bf8098e3f7ae7a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon May 5 13:03:14 2014 +0100 intel-virtual-output: Check for errors whilst creating ShmPixmaps Creating a ShmPixmap may cause an asynchronous BadAccess error, so wrap the construction with XSync and check for an error before proceeding. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> References: https://bugs.freedesktop.org/show_bug.cgi?id=78293 commit 5279ebf56449a9b9edd28ff23e9c8a20af792795 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon May 5 13:06:11 2014 +0100 intel-virtual-output: Mark ShmPixmap destinations as writeable In order to prevent a subsequent BadAccess when we try to use it as a ShmPixmap, we need to mark the segment as writeable. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> References: https://bugs.freedesktop.org/show_bug.cgi?id=78293 Still puzzling over why everything fails when setting the CRTCs though. Could you please update and attach another failing log? (Minor debug changes)
Ping for an updated debug log.
Aha! commit c5bad6daaaa60fa8970eaf4a1ce485cd4c72c2fd Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed May 7 07:53:11 2014 +0100 intel-virtual-output: Disable remote CRTC using the remote Display! Reported-by: Kirill Müller <mail@kirill-mueller.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78293 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> That should be the fix.
Sorry for the delay. I've upgraded my test system to Ubuntu 14.04, and optirun stopped working. Fixed by installing nvidia-319-updates-uvm (which also pulls the driver), but now gnome-shell crashes when I start or end i-v-o. But that's another issue, I guess. As for the CRTCs, in my setup now the contents of the second display are replicated on the third display, even if it is set as rotated. Which logs would you be interested in? Didn't test with the SHM setting yet.
Update: gnome-shell segfaults, even when using the "stable" version of i-v-o mentioned earlier. Which nvidia drivers can you recommend? nvidia-current doesn't seem to work (anymore) on 14.04.
I installed 331, not 319. Now trying to remove the -uvm module.
That sounds like panning is broken again. In the rotated configuration, a quick xrandr -d :0, xrandr -d :8 should suffice to confirm the same symptoms as before. After that a debug log will help to check for new X11 errors.
Oh, yes, I know mutter has a nasty bug(s) in its randr handling.
Hi Kirill, could you paste the xrandr -d :0 and -d :8 of the failing configuration?
Created attachment 98930 [details] xrandr output ( xrandr; xrandr -d :8 ) > xrandr.log After running i-v-o, gnome-shell crashes. After automatic restart, adjusted displays by rotating the third; still, contents of second display are replicated to the third. ad01e1c8700caeaf0288 after make clean && make && sudo make install && reboot .
Right, the bad panning is back. Can you please try: diff --git a/tools/virtual.c b/tools/virtual.c index d792957..8175944 100644 --- a/tools/virtual.c +++ b/tools/virtual.c @@ -457,7 +457,7 @@ static int disable_crtc(Display *dpy, XRRScreenResources *res, RRCrtc crtc) if (XRRSetCrtcConfig(dpy, res, crtc, CurrentTime, 0, 0, None, RR_Rotate_0, NULL, 0) != Success) return 0; - if (XRRSetPanning(dpy, res, crtc, memset(&panning, 0, sizeof(panning))) != Success) { + if (0 && XRRSetPanning(dpy, res, crtc, memset(&panning, 0, sizeof(panning))) != Success) { DBG(("%s failed to clear panning on CRTC:%ld\n", DisplayString(dpy), (long)crtc)); if (EXTRA_DBG) { XRRCrtcInfo *c;
Created attachment 98931 [details] [review] Disable panning after CRTC off Attached rather than pasted in case the paste mangled the lines.
Thanks. I need to reboot and find time, that's why it sometimes takes a while. Please let me know if you might need further information so I can collect it in one sweep.
Hmm, I only have a single screen I can conveniently attach to the nvidia card. That doesn't seem to suffer the panning failure when I switch it on/off, rotate it, and move it around. Will see if I can grab another screen to attach.
In case it is significant, I am using [ 390.189] (II) NVIDIA dlloader X Driver 331.67 Fri Apr 4 11:24:40 PDT 2014 [ 390.190] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
Found an old monitor. root@ivybridge:~# xrandr -d :0 Screen 0: minimum 8 x 8, current 4864 x 1280, maximum 32767 x 32767 LVDS1 disconnected (normal left inverted right x axis y axis) VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) HDMI3 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP3 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm 1920x1080 60.0*+ 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 720x400 70.1 VIRTUAL1 disconnected (normal left inverted right x axis y axis) VIRTUAL2 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 0mm x 0mm 1920x1080 60.0* 1280x1024 75.0 60.0 1152x864 75.0 VIRTUAL2.642-1024x768 75.0 1024x768 60.0 800x600 75.0 60.3 640x480 75.0 VIRTUAL2.647-640x480 59.9 VIRTUAL3 connected 1024x1280+3840+0 right (normal left inverted right x axis y axis) 0mm x 0mm 1280x1024 60.0* 75.0 VIRTUAL2.642-1024x768 75.0 VIRTUAL3.649-1024x768 72.0 VIRTUAL3.650-1024x768 70.1 1024x768 60.0 800x600 75.0 60.3 VIRTUAL3.651-800x600 72.2 VIRTUAL3.652-800x600 56.2 640x480 75.0 VIRTUAL3.653-640x480 72.8 VIRTUAL2.647-640x480 59.9 VIRTUAL3.654-640x400 70.1 VIRTUAL3.655-640x360 70.0 VIRTUAL4 disconnected (normal left inverted right x axis y axis) VIRTUAL5 disconnected (normal left inverted right x axis y axis) root@ivybridge:~# xrandr -d :8 Screen 0: minimum 8 x 8, current 2944 x 1280, maximum 16384 x 16384 DVI-I-0 disconnected primary (normal left inverted right x axis y axis) VGA-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm 1920x1080 60.0*+ 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.0 60.0 800x600 75.0 60.3 640x480 75.0 59.9 DVI-I-1 connected 1024x1280+1920+0 right (normal left inverted right x axis y axis) 376mm x 301mm 1280x1024 60.0*+ 75.0 1024x768 75.0 72.0 70.1 60.0 800x600 75.0 72.2 60.3 56.2 640x480 75.0 72.8 59.9 640x400 70.1 640x360 70.0 HDMI-0 disconnected (normal left inverted right x axis y axis) Not seeing the panning issue at all.
Great you found a third monitor. I can share some details of my test system, let me know if you need more: - Lenovo T430 - nvidia-331-uvm package installed (some problems with nvidia-331-updates-uvm made me uninstall it) - Intel driver and i-v-o from Git - Ubuntu GNOME 14.04 - Third display rotated I will try again next week. I really appreciate your efforts, I have to make sure multi-monitor support works well before upgrading my production system to 14.04.
Marly, if you can help with testing by installing form xf86-video-intel.git and apply diff --git a/tools/virtual.c b/tools/virtual.c index d107617..fd42ece 100644 --- a/tools/virtual.c +++ b/tools/virtual.c @@ -65,7 +65,7 @@ #include <fcntl.h> #include <assert.h> -#if 0 +#if 1 #define DBG(x) printf x #define EXTRA_DBG 1 #else to generate the debug output from i-v-o, that would be very useful.
Now, aclocal-1.13 is missing on my Ubuntu 14.04 system, it offers aclocal-1.14 . ~/xf86-video-intel$ make CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /home/muelleki/xf86-video-intel/missing aclocal-1.13 -I m4 /home/muelleki/xf86-video-intel/missing: line 81: aclocal-1.13: command not found WARNING: 'aclocal-1.13' is missing on your system. You should only need it if you modified 'acinclude.m4' or 'configure.ac' or m4 files included by 'configure.ac'. The 'aclocal' program is part of the GNU Automake package: <http://www.gnu.org/software/automake> It also requires GNU Autoconf, GNU m4 and Perl in order to run: <http://www.gnu.org/software/autoconf> <http://www.gnu.org/software/m4/> <http://www.perl.org/> make: *** [aclocal.m4] Error 127 ~ aclocal-1.13 No command 'aclocal-1.13' found, did you mean: Command 'aclocal-1.14' from package 'automake' (main) Command 'aclocal-1.11' from package 'automake1.11' (main) Command 'aclocal-1.10' from package 'automake1.10' (main) aclocal-1.13: command not found # apt-get install automake Reading package lists... Done Building dependency tree Reading state information... Done automake is already the newest version. automake set to manually installed. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
I was able to fool it by saying /usr/bin# ln -s aclocal-1.14 aclocal-1.13 /usr/bin# ln -s automake-1.14 automake-1.13 Not nice, though.
After another round of make clean && make -j4 && sudo make install everything looks peachy now. There is again a heavy lag on the external displays, the lag is not as heavy on the primary display. For example, it is noticeable when typing at a very quick speed in gedit. Shall I open a new issue?
Please, let's tackle that drm_cflush_page() issue separately, i.e. the lag. I think that is a kernel bug fixed in recent kernels. Can you double check that everything is fine but just too slow? In particular, rearranging the screens (modulo mutter blowing up sporadically when it tries to dereference a NULL pointer - not my bug! ;-)?
I've tried some combinations of arrangement and rotation of both external displays, including a few really weird ones. All of them worked as expected. Since you mentioned the mutter bug -- I'm experiencing crashes when starting and terminating i-v-o. Could you give a hint on how to avoid it -- is there a bugfix in some PPA, or a configuration to avoid the bug? This is still a showstopper for me. I'm using gnome-shell, don't know if this is the same. Thanks a lot for your efforts. Keep up the good work!
...on the most recent Git tip as of now, 00d9396f6bf0bbbdfca7c .
Yes, gnome-shell uses mutter. The bug is https://github.com/GNOME/mutter/blob/master/src/backends/x11/meta-monitor-manager-xrandr.c#L522 does not handle the case with no modes i.e. it tries to dereference a NULL pointer. Filed as https://bugzilla.gnome.org/show_bug.cgi?id=730551 Please do let me know if performance is subpar, or if any other issues arise. Thanks.
Please excuse my ignorance -- but do you see any chance to work around this bug in mutter in i-v-o and/or the Intel driver?
Not sure. The problem is if I leave a fake mode in there, gnome-shell will try to extend the desktop to it, which is also undesirable.
Actually, how about: diff --git a/tools/virtual.c b/tools/virtual.c index 8f707b7..956fabb 100644 --- a/tools/virtual.c +++ b/tools/virtual.c @@ -927,6 +927,10 @@ static RROutput claim_virtual(struct display *display, char *output_name, int nc XRRDeleteOutputMode(dpy, rr_output, id); XRRDestroyMode(dpy, id); + /* And hide it again */ + res = XRRGetScreenResources(dpy, display->root); + if (res == NULL) + XRRFreeScreenResources(res); out: XUngrabServer(dpy);
I think this should hid the connected + 0 modes from gnome-shell: commit 8d1e9afb60a61bf490a282a16db1c15a9ad7d077 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu May 22 12:34:05 2014 +0100 intel-virtual-output: Probe after claiming virtual output Rerun a detection cycle after claiming the virtual output so that it is hidden again. References: https://bugs.freedesktop.org/show_bug.cgi?id=78293 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Sweet! Works for me, ready for Trusty now. Again, thanks a lot for your efforts and your quick response, very much appreciated!
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.