<div dir="ltr">I can't reproduce this bug on my system. Just did what you said, <div>dump a large file to the xterm console directly, and then send</div><div>expose to it repeatedly.  Everything seems work fine.</div><div>
<br></div><div>Could you send a full xorg.0.log to the list? And if possible, a photo</div><div>of the corrupted screen may be also helpful here.</div><div><br></div><div>Thanks,</div><div>Zhigang Gong.</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sat, Dec 14, 2013 at 11:35 PM, Wolfgang Draxinger <span dir="ltr"><<a href="mailto:wdraxinger.maillist@draxit.de" target="_blank">wdraxinger.maillist@draxit.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I submitted the same report to the xorg-devel maillist and was kindly<br>
asked to submit this to the glamor maillist as well.<br>
<div><div class="h5"><br>
I'm running a system of the following configuration<br>
<br>
lspci output on the graphics controller:<br>
<br>
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series<br>
Chipset Integrated Graphics Controller (rev 07)<br>
<br>
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset<br>
Integrated Graphics Controller (rev 07)<br>
<br>
extracted from Xorg.log<br>
<br>
X.Org X Server 1.14.3 - Release Date: 2013-09-12<br>
<br>
X Protocol Version 11, Revision 0<br>
Build Operating System: Linux 3.11.0-gentoo x86_64 Gentoo<br>
Current Operating System: Linux narfi 3.11.0-gentoo #2 \<br>
 SMP PREEMPT Sat Sep 14 14:51:00 CEST 2013 x86_64<br>
Kernel command line: quiet root=/dev/sda2 \<br>
 BOOT_IMAGE=/kernel-3.11.0-gentoo<br>
Build Date: 08 November 2013  01:42:15AM<br>
<br>
(II) LoadModule: "intel"<br>
(II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so<br>
(II) Module intel: vendor="X.Org Foundation"<br>
     compiled for 1.14.3, module version = 2.21.15<br>
     Module class: X.Org Video Driver<br>
     ABI class: X.Org Video Driver, version 14.1<br>
<br>
libXft version is 2.3.1<br>
<br>
Now for my observation: When I build the video driver with glamor<br>
support I notice that ocassionally glyphs rendered with Xft become<br>
corrupted. It's not looking like random bitnoise, but that while Xft is<br>
rendering to the pixel buffer, or while the pixel buffer is drawn to<br>
the framebuffer the configuration of the buffer changes. The pixels<br>
clearly come from a Xft rendering (the colors they have match those<br>
found in the pixel values of the neighboring characters).<br>
<br>
A foolproof way to trigger this was to have a full screen xterm and<br>
dump it full of random characters (I have to admit I never tried what<br>
happens if it were all the same character). And then you'd make the<br>
xterm redraw (for example by repeatingly sending it expose events).<br>
Then you'd see characters "flicker" between rendered corrupted and<br>
intact. I didn't quantify it, but it looked like there was a certain<br>
distance between characters being corrupted which was very regular. It<br>
however never hit the same spots between each redraw but you could<br>
clearly see some regularity and clustering. This was as if there was<br>
some beating between the amount of characters drawn and the frequency<br>
the corruption happens plus some undetermined offset due to noise<br>
(other things drawn, timing differences in the scheduler, who knows).<br>
<br>
When I first noticed that I had a lot of suspicions on the<br>
cause (software and hardware problems and so on). I used the usual<br>
divide and conquer methods to narrow down the problem to glamor.<br>
<br>
Given my long time experience with OpenGL (and having exploited several<br>
undefined things in particular implementations for various hacks) this<br>
makes sense. To me it looks like a race condition between the code that<br>
fills a pixel buffer (area) reserved for a glyph and the code that<br>
brings it to the screen later. Most likely there is a synchronization<br>
point missing somewhere in the command stream.<br>
<br>
So if this is a race condition between an image object (PBO or texture)<br>
being used for drawing and the same object being allocated, filled with<br>
data or freed up, I can see two possible scenarios:<br>
<br>
- The buffer is used for draw before fully prepared and having its<br>
  drawing parameters set.<br>
<br>
Or<br>
<br>
- while the drawing progress happens the contents of the buffer or<br>
  its associated drawing parameters are altered too early.<br>
<br>
Of course it could be a combination of both. Right now I'm running a<br>
glamor-less build and have no screenshots. But I could rebuild the<br>
drivers with glamor (hoping the problem didn't magically vanish) and<br>
provide screenshots if required.<br>
<br>
So far I've seen the problem only happening for Xft, but I didn't look<br>
at other XRender based stuff. It may be, that those are affected as<br>
well. However I can rule out core drawing routines and regular OpenGL<br>
operations from being affected.<br>
<br>
I'm wondering if this is a problem isolated to the video-intel driver<br>
or if this is located in the shared glamor code.<br>
<br>
Given the fact that parts of glamor code may end up in Wayland based<br>
rendering backend and that text is the most important information on a<br>
computer screen I think that this problem deserves some attention.<br>
<br>
<br>
Regards<br>
<br>
Wolfgang<br>
_______________________________________________<br>
</div></div>Glamor mailing list<br>
<a href="mailto:Glamor@lists.freedesktop.org">Glamor@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/glamor" target="_blank">http://lists.freedesktop.org/mailman/listinfo/glamor</a><br>
</blockquote></div><br></div>