Created attachment 47350 [details] Output of 'lspci -vv' After upgrading to newer Xorg and Intel driver, I have experienced persistent graphics corruption that corrupts some font glyphs and sometimes other pixmaps. The problem occurs _at least_ with Debian kernel "2.6.38-5" and grsec-enhanced vanilla 3.6.38.7. This effect occurs most often within web-pages rendered by Firefox, but also with gnome-terminal and very rarely within Gtk+2 widgets (at least). I have bisected the problem to xf86-video-intel driver commit ID cc930a37612341a1f2457adb339523c215879d82 : http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=cc930a37612341a1f2457adb339523c215879d82 However, based on the changeset I would venture that the real problem is probably somewhere else, and reverting simply just masks the problem. Reverthing the commit seems to "fix" the corruption problem completely. I am running Debian testing (wheezy), with following Xorg packages: ii xorg 1:7.6+6 X.Org X Window System ii xorg-dev 1:7.6+6 the X.Org X Window System development libraries ii xorg-docs-core 1:1.6-1 Core documentation for the X.org X Window System ii xorg-sgml-doctools 1:1.7-1 Common tools for building X.Org SGML documentation ii xserver-xorg 1:7.6+6 the X.Org X server ii xserver-xorg-core 2:1.10.1-2 Xorg X server - core server ii xserver-xorg-dev 2:1.10.1-2 Xorg X server - development files ii xserver-xorg-input-evdev 1:2.6.0-2+b1 X.Org X server -- evdev input driver ii xserver-xorg-input-kbd 1:1.6.0-1+b1 X.Org X server -- keyboard input driver ii xserver-xorg-input-mouse 1:1.7.0-2+b1 X.Org X server -- mouse input driver ii xserver-xorg-video-intel 2:2.15.0-3 X.Org X server -- Intel i8xx, i9xx display driver Graphics device is an integrated Intel: 00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 10)
Created attachment 47351 [details] Screenshot of the glyph corruption
Created attachment 47377 [details] Xorg startup logfile
The same problem still persists with latest GIT of xf86-video-intel ( afdb8aa89a88c62ccd5e26a3ed9adb70fec310a8), without SNA enabled. With SNA enabled, I haven't seen this problem, but unfortunately enabling SNA causes other problems (visible redrawing/flickering with xterm/rxvt and window moving (WindowMaker 0.92 as WM), etc) Kernels tested: 2.6.39.4 and 3.0.3 X.Org X Server 1.10.4 Xorg packages are latest available in Debian Testing, but using xf86-video-intel built from GIT repo source. As before, reverting the commit mentioned in first comment "fixes" the corruption problem. Please advise if you require any other information I have not provided yet.
Created attachment 50977 [details] Google Maps graphical corruption Screenshot of the pixmap(?) corruption that occurs when using Google Maps with Firefox 7.0. Corruption does not occur with SNA enabled.
WindowMaker shouldn't be unusual in this regard. Can you describe the flicker more? Is it simply vrefresh tearing or is it always the same part of the screen flickering (such as the bottom third, or below the cursor) independent of the contents being updated? Running with --enable-sna --enable-debug=full is likely to slow down the system and hide the flicker, and is unlikely to tell me anything since you are not doing anything unusual. So back to describing the flicker. :)
Well, I am no expert, but moving windows looks as the drawing of the window outline is shown without vsync (I do not use "opaque move", so only the outline is visible when moving). Xterm and rxvt window updates (when text is scrolled) on the other hand, look as if the window is first cleared (to black) and then text being repainted. I'd suspect this also has something to do with vsync, but ... *shrug*. :) Some other software also exhibit similar issues, but those two are the most prominent and especially the terminal "flickering" is very annoying. I am using a CRT monitor, if that has any relevance (shouldn't).
Just adding this: it's as if there was no page flipping / double buffering performed (not that I have any idea if there should be :) ) Also, the drawing operations generally seem somehow "sluggish", though I don't know how to elaborate more on that. It could be just a placebo effect caused by the flicker/redraw visibility.
Ok, you are just describing how rendering is done in a non-composited desktop, that is all individual operations are done immediately onto the front buffer and so you can see windows that are repainted multiple times. The only difference introduced by SNA in this regard is that it rate-limits it updates. Can you perceive a difference with...? diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c index 8a7cec2..5b6584e 100644 --- a/src/sna/sna_accel.c +++ b/src/sna/sna_accel.c @@ -3216,7 +3216,7 @@ static Bool sna_accel_do_flush(struct sna *sna) /* Then periodic updates at 25Hz.*/ to.it_interval.tv_sec = 0; - to.it_interval.tv_nsec = 40 * 1000 * 1000; + to.it_interval.tv_nsec = 10 * 1000 * 1000; timerfd_settime(sna->timer[FLUSH_TIMER], 0, &to, NULL); sna->timer_active |= 1 << FLUSH_TIMER;
How bizarre, I feel the same when switching back to UXA. ;-)
Heh .. Well, I'm not seeing much of difference with the patch applied. I also tried reducing the value even more, but with no perceivable consequences. Though I have to say, that part of the biggest problem is probably rxvt itself. With xterm and rxvt-unicode there is almost no "update flicker", I suppose they handle redrawing differently or use client-side double buffering. I assume you are not interested in the original problem, aka the glyph + pixmap corruption with SNA disabled? :) If so, it is understandable, of course.
It worries me that I don't understand how the original issue occurs (it's not one of the known tiling issues), but ignorance is bliss if I have a path to a perfect future...
Yeah. I think I'll just dump rxvt for urxvt and bear with the window movement etc. flicker for now. I also tested changing the sna_accel_do_flush() timer values to something ridiculously low, (to.it_value.tv_nsec = 1 * 1000 * 1000; and to.it_interval.tv_nsec = 1 * 1000 * 1000;) and this seems to improve things visually a bit. But I wonder if this may have some unwanted side-effects?
I've pushed a tree to remove some of the optimisations to see if they are the cause of the corruption: http://cgit.freedesktop.org/~ickle/xf86-video-intel #glyph-cache-bug Can you please try this branch to see if does the trick? Rough guide to testing: $ git clone git://people.freedesktop.org/~ickle/xf86-video-intel $ cd xf86-video-intel $ git checkout origin/glyph-cache-bug $ ./autogen.sh --prefix=/usr $ make $ sudo make install # restart X
*** This bug has been marked as a duplicate of bug 36326 ***
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.