Xorg.0.log is always a good start - it lets me identify hardware and software, and highlight any obvious errors. xrandr --verbose will be useful, as would a screen capture of the final setup. That screen capture will help determine if everything is being drawn as intended. As always, please look at installing xf86-video-intel from git so that you are ready to test any patches that might be required.

Created attachment 88825 [details]
Xorg.0.log (Intel with 2 screens)

Sure I'll provide informations.

Here is my XOrg.0.log where Intel-Chipset is used.

Created attachment 88826 [details]
Xorg.8.log (NVidia as 3rd screen)

Here is my XOrg.8.log where NVidia-Chipset is used by using bumblebee. This should be 3rd screen. Maybe not worth for you.

Created attachment 88827 [details]
konsole-outputs with xrandr --verbose

Here you see how I try to get 3rd screen running. And there is 'xrandr --verbose'.

"please look at installing xf86-video-intel" Do you mean I should drop intel-driver-package and compile intel-driver myself?

Thank you for your quick answer.
cu Floh

With the exception that Xorg.0.log hints at a GPU hang (please also attach dmesg, and if necessary /sys/class/drm/card0/error), everything looks to be in order.

So checking whether a screen capture show anything painted on the 3-wide desktop will be useful.

Building a temporary install of xf86-video-intel (or xserver-xorg-video-intel) is quite simple:
$ apt-get build-dep xserver-xorg-video-intel
$ git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-intel
$ cd xf86-video-intel
$ ./autogen.sh --prefix=/usr
$ make && sudo make install

The driver will be restored to distribution version upon the next package update (or package reinstall).

Created attachment 88832 [details]
"Screenshot"

I dunno how I should make screen capture. I made screenshot which looks fine but 3rd screen shows different than screenshot. See attachment where I shot an image of my monitors.

Left screen is VIRTUAL1 which is broken as you can see in image.

cu Floh

Both methods of capturing the image are important, as they are captured at different stages of the pipeline. If the screenshot is good, but the photograph is bad, we know that the error occurs between reading back the framebuffer and copying it to the discrete card.

Can you please run intel-virtual-output with -f -d and attach its output from during the bad rendering?

What will also be useful to test is enabling/disabling kwin desktop effects (effectively turning on/off compositing with its own damage tracking and framebuffer hijacking). My testing was with (and without) gnome-shell.

Created attachment 88843 [details]
KDE4 crash report

I did as you said in Comment 5 (git clone, compile, make&makeinstall) and then rebooted. Unfortunatelly -d -f didn't work as espected:
>>>
f.erfurth@Precision-M6600:~$ sudo optirun -c yuv true
f.erfurth@Precision-M6600:~$ intel-virtual-output -d -f > i-v-o.txt
Unable to connect to "-f".
f.erfurth@Precision-M6600:~$ intel-virtual-output -f > i-v-o.txt
^Cf.erfurth@Precision-M6600:~$ cat i-v-o.txt
f.erfurth@Precision-M6600:~$ 
<<<

As you see... i-v-o.txt is empty. :/ I tried moving around any window in third screen but still no output.
With -d I only got error 'Unable to connect to "-f"'. Maybe wrong parameters? Or am I missing somewhat?

Unfortunatelly I cannot send you dmesg and /sys/class/drm/card0/error because I rebooted my machine in the meanwhile. But its known issue which is already reported by someone else (Sorry I don't remember where...). Sometimes display is freezed for several seconds, but continued working then without problems.
Of course I can provide you dmesg/error file if display freezes again if you'd like to see this.

Not sure if this is important for you:
When I call `intel-virtual-output -f` I a crash-report-dialog appears. Please see attachment. Crash doesn't happens everytime but... the funny thing is... KDE4 is running well. Maybe KDE4 crashed on Display :8? Or its just any library.

cu Floh

(In reply to comment #10)
> Created attachment 88843 [details]
> KDE4 crash report
> 
> I did as you said in Comment 5 (git clone, compile, make&makeinstall) and
> then rebooted. Unfortunatelly -d -f didn't work as espected:
> >>>
> f.erfurth@Precision-M6600:~$ sudo optirun -c yuv true
> f.erfurth@Precision-M6600:~$ intel-virtual-output -d -f > i-v-o.txt
> Unable to connect to "-f".
> f.erfurth@Precision-M6600:~$ intel-virtual-output -f > i-v-o.txt
> ^Cf.erfurth@Precision-M6600:~$ cat i-v-o.txt
> f.erfurth@Precision-M6600:~$ 
> <<<
> 
> As you see... i-v-o.txt is empty. :/ I tried moving around any window in
> third screen but still no output.
> With -d I only got error 'Unable to connect to "-f"'. Maybe wrong
> parameters? Or am I missing somewhat?

Silly me. -f -v (-f == stay in foreground and don't detach, -v == verbose).

> Unfortunatelly I cannot send you dmesg and /sys/class/drm/card0/error
> because I rebooted my machine in the meanwhile. But its known issue which is
> already reported by someone else (Sorry I don't remember where...).
> Sometimes display is freezed for several seconds, but continued working then
> without problems.
> Of course I can provide you dmesg/error file if display freezes again if
> you'd like to see this.
> 
> Not sure if this is important for you:
> When I call `intel-virtual-output -f` I a crash-report-dialog appears.
> Please see attachment. Crash doesn't happens everytime but... the funny
> thing is... KDE4 is running well. Maybe KDE4 crashed on Display :8? Or its
> just any library.

No idea. Seems unrelated.

(In reply to comment #11)
> (In reply to comment #10)
> > With -d I only got error 'Unable to connect to "-f"'. Maybe wrong
> > parameters? Or am I missing somewhat?
> 
> Silly me. -f -v (-f == stay in foreground and don't detach, -v == verbose).
Um... still not working. :)

f.erfurth@Precision-M6600:~$ intel-virtual-output -f -v > i-v-o.txt
intel-virtual-output: invalid option -- 'v'

I took a look into source:
        while ((i = getopt(argc, argv, "abd:fhS")) != -1) {
                switch (i) {
                case 'd':
                        src_name = optarg;
                        break;
                case 'f':
                        daemonize = 0;
                        break;
                case 'b':
                        bumblebee = 1;
                        break;
                case 'a':
                        all = 1;
                        break;
                case 'S':
                        singleton = 0;
                        break;
                case 'h':
                default:
                        usage(argv[0]);
                        exit(0);
                }
        }

So... no verbose. D'uh!

> > Not sure if this is important for you:
> > When I call `intel-virtual-output -f` I a crash-report-dialog appears.
> > Please see attachment. Crash doesn't happens everytime but... the funny
> > thing is... KDE4 is running well. Maybe KDE4 crashed on Display :8? Or its
> > just any library.
> 
> No idea. Seems unrelated.

I thought so.

cu Floh

Eventually I will remember! It is a #if 0 at the top of virtual.c to enable debug information.

diff --git a/tools/virtual.c b/tools/virtual.c
index 160d6a1..4878abb 100644
--- a/tools/virtual.c
+++ b/tools/virtual.c
@@ -66,7 +66,7 @@
 #include <fcntl.h>
 #include <assert.h>
 
-#if 0
+#if 1
 #define DBG(x) printf x
 #else
 #define DBG(x)


And intel-virtual-output -f to see the debug.

Created attachment 88885 [details]
intel-virtual-output output

Ok... debug enabled and retried. I moved around a window in 3rd screen while running. I hope the attachment gives you valuable informations.

Hmm, do you mind applying this patch and attaching the new debug (can be from just the startup once it has connected to bumblebee)?

diff --git a/tools/virtual.c b/tools/virtual.c
index 160d6a1..226f86d 100644
--- a/tools/virtual.c
+++ b/tools/virtual.c
@@ -1456,15 +1456,23 @@ static int record_mouse(struct context *ctx)
 
 static int bad_visual(Visual *visual, int depth)
 {
+       DBG(("%s? depth=%d, visual: bits_per_rgb=%d, red_mask=%08x, green_mask=%08x, blue_mask=%08\n",
+            __func__, depth,
+            visual->bits_per_rgb,
+            visual->red_mask,
+            visual->green_mask,
+            visual->blue_mask));
        switch (depth) {
-       case 16: return (visual->bits_per_rgb != 6 ||
-                        visual->red_mask != 0x1f << 11 ||
-                        visual->green_mask != 0x3f << 5 ||
-                        visual->blue_mask != 0x1f << 0);
-       case 24: return (visual->bits_per_rgb != 8 ||
-                        visual->red_mask != 0xff << 16 ||
-                        visual->green_mask != 0xff << 8 ||
-                        visual->blue_mask != 0xff << 0);
+       case 16: return (visual->bits_per_rgb != 6          ||
+                        visual->red_mask     != 0x1f << 11 ||
+                        visual->green_mask   != 0x3f << 5  ||
+                        visual->blue_mask    != 0x1f << 0);
+
+       case 24: return (visual->bits_per_rgb != 8          ||
+                        visual->red_mask     != 0xff << 16 ||
+                        visual->green_mask   != 0xff << 8  ||
+                        visual->blue_mask    != 0xff << 0);
+
        default: return 0;
        }
 }

So the issue appears to be that the bumblebee xserver is not reporting the SHMCompletionEvents that we use to track when it has finished rendering and is render for an update.

I've pushed a patch just in case we are missing a poll() wakeup:

commit e0075ccee2e7bbe46ecbf717817d468cc9248cc4
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Nov 8 12:46:08 2013 +0000

    intel-virtual-output: Check for pending events before skipping draw
    
    Make sure we check if the destination display has caught up before
    skipping a frame.
    
But I don't think so.

And

commit 969b064f74e0058a49afa17287184005d1e11402
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Nov 8 12:54:01 2013 +0000

    intel-virtual-output: Perform an explicit sync
    
    If we fail to track rendering using ShmCompletionEvents and begin to
    drop frames, insert an explicit XSync.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

commit 83c33a1f436c947ab3d9289a9c57d92f964e9541
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Nov 8 13:00:11 2013 +0000

    intel-virtual-output: Disable event tracking after a failure
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>


should prevent it falling behind in future. Please do attach the latest debug.

Created attachment 88891 [details]
intel-virtual-output output #2

Ok, I pulled and recompiled and tried again. No improvement yet. (Do I have to restart bumblebee? I think not.)

Created attachment 88892 [details]
dmesg after freeze

Because you asked earlier Just had freeze (this happens even without running intel-virtual-output). As I said its already reported so its offtopic here:
https://bugs.freedesktop.org/show_bug.cgi?id=70151

cu Floh

Ok, that GPU hang is likely bug 70151. I've pushed another attempt to fix both problems you've encountered with i-v-o, please retest and a new debug log would be useful. Thanks.

Created attachment 88894 [details]
intel-virtual-output output #3

Oh well... there is improvement! Great! :)

Now windows are drawn on 3rd screen. But... after moving around window update stopped working on 3rd screen.

When update is stoppend then display have following behaviours:
- no window updates (same problem like before)
- I had 2 mouse cursors then!
  - One mouse is stuck within 3rd screen, I mean this cursor is moving around but cannot leave 3rd screen. This has a crossarrow (move-cursor).
  - The other one can be moved freely but is not displayed in 3rd screen.

Hopefully the debug in attachment helps you.
cu Floh

The debug log looks happy - it continues to update the mouse and copy data across. It is truncated, so maybe i-v-o died? Otherwise I can not see any reason why it suddenly stops.

(In reply to comment #22)
> The debug log looks happy - it continues to update the mouse and copy data
> across. It is truncated, so maybe i-v-o died? Otherwise I can not see any
> reason why it suddenly stops.

You're right. I retried and watches output-file with 'tail -f'. After screen updates stopped on 3rd screen, intel-virtual-output doesn't write output anymore. Seems it freezes as you said it died.

I made a video about mouse behaviour which I tried to explain in last comment:
https://www.dropbox.com/s/cdr2u4erb6pf3dz/20131108_153847.mp4

That's impossible! The cursor position is always in absolute coordinates, and so always has a fixed offset....  I guess there is an active pointer grab on the remote X server -- very bizarre.

One minor change wrt to cursor handling:

commit abf1a16914d993cc150005879375d4bb17fdccf3
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Nov 8 17:09:35 2013 +0000

    intel-virtual-output: Only track the most recent visibility status of the cursor
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Can you try running intel-virtual-output under gdb or valgrind (will need to use -f) and see if that catches anything?

Sure I can run with gdb (already installed) but my monitors are at office. So I'll report back at monday.

Oh well... I tried with gdb and then with valgrind. In both case intel-virtual-output stops writing outputs and then nothing happens.

So no crash so I couldn't do backtrace in gdb. *sigh* Do you have idea how to debug?

cu Floh

Oh... I noticed which could make a hint for you. The last output is always the same:
":8-DP-0 is damaged, last SHM serial: 237, now 236"

I tried 3 times and last line is always like:
":8-DP-0 is damaged, last SHM serial: XXX, now YYY"

Where XXX and YYY differs everytime. So the next line must be:
":8-DP-0 get_src(0,0)x(1920,1080)"

...but its not coming. Does this hint help you? I hope so.
cu Floh

Ah, obvious in hindsight!

commit 3e81a9cbd68344450a6e82130edfef21dd04ec43
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Nov 11 10:47:24 2013 +0000

    intel-virtual-output: Avoid the infinite loop around XPending
    
    XPending() reports if there are any events pending and does not perform
    any dequeuing itself - ergo for a remote display while (XPending()) ;
    becomes an infinite loop should there be an event pending.
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=71345
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Please run with that and see if that is the last issue resolved, thanks.

(In reply to comment #28)
> Ah, obvious in hindsight!
> 
> commit 3e81a9cbd68344450a6e82130edfef21dd04ec43
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Mon Nov 11 10:47:24 2013 +0000

Hi, thank you for update, but there is a compile error:
f.erfurth@Precision-M6600:~/temp/triplehead/xf86-video-intel/tools$ make
  CC       virtual.o
virtual.c: In function ‘init_image’:
virtual.c:669:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable]
  int ret;
      ^
virtual.c: In function ‘display_flush_cursor’:
virtual.c:1140:21: error: ‘c’ undeclared (first use in this function)
       DisplayString(c->dst.dpy), x, y, display->cursor_visible));
                     ^
virtual.c:70:23: note: in definition of macro ‘DBG’
 #define DBG(x) printf x
                       ^
virtual.c:1140:21: note: each undeclared identifier is reported only once for each function it appears in
       DisplayString(c->dst.dpy), x, y, display->cursor_visible));
                     ^
virtual.c:70:23: note: in definition of macro ‘DBG’
 #define DBG(x) printf x
                       ^
virtual.c: In function ‘bad_visual’:
virtual.c:1470:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘long unsigned int’ [-Wformat=]
  DBG(("%s? depth=%d, visual: class=%d, bits_per_rgb=%d, red_mask=%08x, green_mask=%08x, blue_mask=%08x\n",
  ^
virtual.c:1470:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 7 has type ‘long unsigned int’ [-Wformat=]
virtual.c:1470:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 8 has type ‘long unsigned int’ [-Wformat=]
virtual.c: In function ‘context_enable_timer’:
virtual.c:355:6: warning: ignoring return value of ‘read’, declared with attribute warn_unused_result [-Wunused-result]
  read(ctx->timer, &count, sizeof(count));
      ^
make: *** [virtual.o] Fehler 1


Please take a look at line 1140, there is an undefined variable c.
Thanx Floh

Offending line fixed.

(In reply to comment #30)
> Offending line fixed.

Thank you. Seems it works...!!! :)

I'd suggest we wait till tomorrow and I'll report here if 3rd Screen works without issue.

A question... 3rd screen is somehow laggy but still workable. Is there a possible way to improve the performance? Shall I open a new bug-ticket about lags on 3rd screen?

cu Floh

As for the lag, I can do my best to demonstrate that it is not the fault of the intel driver or intel-virtual-output... I think if we add timestamps to the debug, we should be reasonably confident where the rate-limiting step is. (For -intel there are kernel patches to enable userptr would help somewhat, as would a very recent kernel, 3.12 or 3.13.)

So if I understand you properly, kernel is to be "blamed" about the issue about lag (or nvidia linuxdriver)?

I see... I'm on Kernel 3.11.0 so I'll wait till Ubuntu releases 3.12.x-Kernelpackage or better 3.13.x-Kernelpackage. Are there patch suggested by intel included in kernel 3.12/3.13?

Thank you for your information.
cu Floh

(In reply to comment #33)
> So if I understand you properly, kernel is to be "blamed" about the issue
> about lag (or nvidia linuxdriver)?

There are a couple of patches in later kernels that should improve latency here (in i915.ko). The userptr patch would be less significant for you, but would still help somewhat.
 
> I see... I'm on Kernel 3.11.0 so I'll wait till Ubuntu releases
> 3.12.x-Kernelpackage or better 3.13.x-Kernelpackage. Are there patch
> suggested by intel included in kernel 3.12/3.13?

I'm never certain, the bits that I touched in the last 3 months will be in 3.13. That time lag between when I submit a patch and when it shows up means I lose all track of what actually is in distributions.

A simple way to check for ubuntu is the ppa:mainline http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-experimental/

However, none of this will help very much if the ratelimiting step is the pixel transfer to the nvidia display...

Hi Chris,
thank you for your detailed information.

I think this bug is solved. But I noticed that if my laptop starts screensaver, then 2 displays (intel) is running well while 3rd display (nvidia over virtual1) is displaying static picture of screensaver.

Shall I open a new bug or is this one sufficient?
cu Floh

That sounds different. Lets start afresh, can you file a new bug with a debug log? What I will be looking for is whether we get the damage events etc.