This issue is not a new one, but obviously hasn't been solved until now. 
I'm referring to some almost a year old messages on this list:
"Fwd: Re: i810 and i810e display corruption problem!", July 2001
http://www.xfree86.org/pipermail/xpert/2001-July/010054.html
http://www.xfree86.org/pipermail/xpert/2001-July/010072.html

Matthew J. Sottek <[EMAIL PROTECTED]> wrote:
 > Can someone provide a list or pointer to all the XFree86
 > options to turn off XAA hooks. Then maybe one of these guys
 > can narrow it down via trial and error.
Dr. Andrew C. Aitchison <[EMAIL PROTECTED]> provided the list.

Since I am one of "these guys", i.e. I have this nasty problem, and 
after having confirmed with Matthew J. Sottek that the question is still 
open, I did this narrowing-down. Also, I tried to put together all the 
information on this bug that I've found in search of a fix. I hope it 
might prove useful in finding the bug. Since I am no expert in this area 
I have to hand over here. Now the facts:

On my system, any one of the three options
Option       "XaaNoOffscreenPixmaps"
Option       "XaaNoPixmapCache"
Option       "XaaNoScreenToScreenCopy"
prevents the display from corrupting. By the way, it's REALLY difficult 
to find three things if you're sure you're looking for only one. 
Question to the experts: Which one costs least performance?

To be sure there aren't any XAA options I don't know of, here the ones 
that don't prevent corruption:
Option       "XaaNoColor8x8PatternFillRect"
Option       "XaaNoColor8x8PatternFillTrap"
Option       "XaaNoCPUToScreenColorExpandFill"
Option       "XaaNoDashedBresenhamLine"
Option       "XaaNoDashedTwoPointLine"
Option       "XaaNoImageWriteRect"
Option       "XaaNoMono8x8PatternFillRect"
Option       "XaaNoMono8x8PatternFillTrap"
Option       "XaaNoScanlineCPUToScreenColorExpandFill"
Option       "XaaNoScanlineImageWriteRect"
Option       "XaaNoScreenToScreenColorExpandFill"
Option       "XaaNoSolidBresenhamLine"
Option       "XaaNoSolidFillRect"
Option       "XaaNoSolidFillTrap"
Option       "XaaNoSolidHorVertLine"
Option       "XaaNoSolidTwoPointLine"
Option       "XaaNoWriteBitmap"
Option       "XaaNoWritePixmap"

Switching from 16bpp to 24bpp is said to cure the problem, too (Laurent 
Montel <[EMAIL PROTECTED]> ). I couldn't really verify this, 
because X doesn't let me have 1280x1024@85Hz in 24bpp depth, probably 
due to some dacspeed default in the i810 driver. At 75Hz it works, 
though. I didn't want to fiddle with this, but Intel says explicitly 
that i810 supports these 85Hz-settings at this depth. Is there something 
wrong with the defaults here?

The bug obviously affects only KDE. Robknapp <[EMAIL PROTECTED]> states 
more exactly that it only affects KDE applications, regardless of the 
windowmanager in use.

If someone wishes to see what the bug looks like, here you are, 
decreasing severity:

http://users.du.se/~mda/kdeprobs.png
http://sigma.cte.lu/~fweis/Stripes/cte-stripes.png
http://david.acz.org/kde-bug.jpg

I myself have seen things worse than the first one, and read reports 
stating KDE became unusable after an hour or so. The severity seems to 
be very different from case to case. While others obviously don't have 
to do very much to see the bug, I can best provoke it by viewing lots of 
graphic web pages with konqueror, but it isn't very predictable. Looks 
like some running out of memory, but that may only be the look. Works 
with viewing one page after the other in one konqueror or with opening 
one konqueror for each page, the latter method seems a bit faster.

It is also not at all clear with which versions the bug was introduced. 
I first saw this bug just recently after installing SuSE 7.3 (XFree 
4.1.0, KDE 2.2.1), not having had it with 7.1 (KDE 2.0.1, XFree 4.0.2). 
Someone with the same hardware (i810,  Celeron 466) saw it already with 
SuSE 7.0 (Graham Mullis <[EMAIL PROTECTED]> ). 
Again, someone with an i815-equipped machine had the problem only after 
updating from SuSE 7.3 with (obviously upgraded) KDE 3.0.0 to 8.0 (XFree 
4.2.0, KDE 3.0.0) ( <[EMAIL PROTECTED]> ). And the bug also comes with 
all distributions. Whatever this all means. Maybe the bug itself has 
been there all the time in XFree 4, but gets only triggered under 
certain circumstances. But this also assures me I'm not bugging with old 
stuff.

Something I noticed, maybe a clue, maybe not: dragging a KDE window 
seems to have a very high priority nowadays, it even prevents a 
ksysguard load monitor from being updated. This doesn't happen with KDE 
2.0.1, where I didn't have the problems in queston. But this doesn't fit 
together with Graham Mullis' report about SuSE 7.0.

KDE has several bug reports about the screen corruption, all marked done 
claiming it to be an XFree bug. Bug numbers:
42087
41475
37150
34704
28411
26854
19145

And finally the KDE guys that know definitely this is an XFree bug, 
taken from the above bug reports (perhaps they know more, sometimes they 
write more, but I won't quote that ;-) ):
Stephan Binner <binner at kde.org>
John Firebaugh <jfirebaugh at kde.org>
Cristian Tibirna <tibirna at kde.org>
Rik Hemsley <rik at kde.org>
Ralf Nolden <nolden at kde.org>
Laurent Montel <lmontel at mandrakesoft.com>

After having done all this work, I hope someone will be interested 
enough to take up the case at this point.

Dirk






_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Reply via email to