in dual head config a row of pixels is drawn on the wrong monitor

[Peter Maydell]

Binary package hint: xserver-xorg-video-intel

I have a gutsy system using the xserver-xorg-video-intel driver and xrandr1.2 to do a dual-head configuration with a single desktop spanning both monitors. Sometimes when I start up the system a single partial line of pixels is drawn on the wrong monitor. That is, for about half to two-thirds of a single line of pixels starting from the right of the screen, the pixels that should be drawn on the external monitor are drawn on the internal laptop display, and vice-versa. (You can tell this because if you move windows around on one monitor the corrupted line on the other monitor changes colour to match what ought to be drawn in the corrupted line on the first monitor.)

I'll attach my xorg.conf. I enable the desktop-spanning with:
   xrandr --output VGA --preferred
   xrandr --output VGA --left-of LVDS

(for some bizarre reason it doesn't seem to be possible to do that in xorg.conf itself.)

[Peter Maydell (pmaydell)]

It's been suggested that my Xorg.0.log might be useful too.

[Kyle McMartin (kyle)]

Hi, if I build a intel driver from git tip for you, will you be able to test it?

Thanks,
 Kyle

[Peter Maydell (pmaydell)]

Yes, with the caveat that unfortunately I'm going away on Monday (and not taking my external monitor with me!) so I'm only going to be in a position to test this weekend.

[Peter Maydell (pmaydell)]

Interestingly, I can't currently reproduce this. (At the moment I have xserver-xorg-video-intel 2:2.1.1-0ubuntu5 installed.) Dunno whether that means it's been fixed by some change in the driver or if the bug has just gone into hiding (it was always intermittent)...

[Bryce Harrington (bryce)]

Here's a deb from Oct 4th that I did of git head; might be worth testing.

http://people.ubuntu.com/~bryce/Testing/intel/xserver-xorg-video-intel_2.1.1~git20071004-0ubuntu1_i386.deb

[Peter Maydell (pmaydell)]

OK, I'll have a look at that, but I'm afraid it won't be until the end of November (which is when I'll be reunited with the external monitor).

[Jamie Lokier (jamie-shareable)]

See also bug #150769 which is probably the same.

I see similar corruption consistently when using an external monitor 1680x1050. There is no need for suspend/resume. Merely dragging a window round will produce it. With my laptop screen I never see it, at 1280x1024.

It is easily reproduced in my setup: it's there from the start, or it's not (with the right older driver).

The artifact looks suspiciously like problems in a 2d acceleration op such as block copy/fill. It is not a problem displaying the framebuffer contents, because it can be drawn over with the correct pixels, so it's definitely a drawing problem of some kind. It's not 3d related: I'm not using any 3d acceleration - no Compiz, etc.

This bug was fixed in an older version of the Intel X.Org driver, and got fixed around 2.0.0. The Feisty version of the Intel driver on burtonini.com worked well. But the bug seems to have reappeared in Gutsy's version for quite some time. Unfortunately I forget when exactly it reappeared, as I assumed it would be so obvious that it would get fixed quickly, but it hasn't been fixed for several Intel driver updates in Gutsy.

Because it was fixed for a while, I suspect this is a known fixed bug in X.Org's version which got lost during some code merging accident.

[Jamie Lokier (jamie-shareable)]

Bryce's git head package _does_ appear to fix the problem of the row of pixels. I haven't changed X config at all. There are a number of changes in Xorg.0.log, especially around DRI and video card memory usage, however it looks like DRI is still enabled with the new package.

I've been using Bryce's package for a little while now, and the screen looks fine on both monitors.

As a bonus, playing video with Totem/gstreamer/Xine looks ok again. (It's unwatchable with the Gutsy driver). I haven't gotten around to reporting that bug... maybe I won't have to, if the git head package gets into mainstream.

[Jamie Lokier (jamie-shareable)]

Added bonus: suspend/resume in dual head mode worked! That doesn't work too often. Things must be getting better. No display corruption, not even a row, after resume. (Not that I ever noticed resume having anything to do with the corrupt row, but some have).

(Of course a little alert box saying "Sleep failed" popped up despite sleep succeeding :-) But it often does this... not an X driver bug).

[Peter Clifton (pcjc2)]

As a bonus, playing video with Totem/gstreamer/Xine looks ok again. (It's unwatchable with the Gutsy driver). I haven't gotten around to reporting that bug... maybe I won't have to, if the git head package gets into mainstream.

Please do report the bug, there is no way the git driver will get released in gutsy-updates, but we might (if we can identify the bug / cause / fix) be able to update with the relevant fix. (Similarly, we'll need to figure this out for whatever fixes the line of pixels issue). As nothing leaps out either time that line of pixels problem has been "fixed", there is a danger that its still hiding there, or its cause is very subtle.

If anyone feels like hacking away on this, they might like to checkout the git repository for the driver and git bisect to find exactly which commit(s) fix the issue(s). We could possibly bisect remotely, but its a little tedious.. will be far quicker to explain to someone how to do it than to keep sending new packages to test.

[Jamie Lokier (jamie-shareable)]

I'm not going to do the git bisect, because last time I hacked on this driver it took me a couple of days just to get a suitable compilation environment + fix the bugs which prevented git head from compiling :/ I don't have that kind of time any more.

Since this is marked as a duplicate of bug #91966 (even though this one's subject fits and that one's doesn't), further comments from me will go there to avoid duplication.

I agree about the subtleness. See bug #91966: 3d broke with the package that fixes the corruption. The 3d breakage may be preventing the cause of corruption, without that bug being fixed. There are lots of other dubious looking messages in Xorg.0.log which suggest they might just be masking this (and other!) problems.

[Eitan Isaacson (eeejay)]

I mentioned in a post on bug #91966 that this is the changeset that made all the trouble:
a4f1a7872f6f959bb4bc6568face710bee3589de
It's from the git repo pulled from: git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel
I'd also say that the changeset above deals with a lot of memory stuff, it's hard to understand.

[Jamie Lokier (jamie-shareable)]

Please see my comment on bug #91966 which is about that changeset.

[Jamie Lokier (jamie-shareable)]

"Playing video with Totem/gstreamer/Xine looks ok again. (It's unwatchable with the Gutsy driver)" appears to have been reported already as #32963, although my symptoms are a little different, they are quite similar. Thanks.