Bill Soudan writes:
 > 
 > On Wed, 25 Sep 2002, Sottek, Matthew J wrote:
 > 
 > > No, blits from the Framebuffer to the Framebuffer would be correct.
 > > Blits from the pixmap cache to the framebuffer that are only 1 line
 > > would also be correct.
 > 
 > I've posted a few example pics of the corruption I see:
 > 
 > http://www.soudan.net/~bills/snapshot1.png - konq window w/ corrupted 
 >   menubar
 > http://www.soudan.net/~bills/snapshot2.png - gimp blown up version of 
 >   corruption
 > 
 > The corrupted regions are 14x22, with the exception of the one above
 > 'hours'.  Each region is a well-formed horizontal gradient (!).
 > 
 > If the pitch was off while blitting from pixmap cache to framebuffer,
 > wouldn't the corruption just be garbage?  And a width of 14 seems like a
 > really odd size for a blit to me.
 > 
 > Maybe the problem then isn't with the blit from the pixmap cache to the
 > framebuffer, but it's that the pixmap cache itself is getting corrupted?
 > Jeff's memory management patch is looking fairly attractive.
 > 

The XAA code uses ScreenToScreenCopy to create a background pixmap
in offscreen memory out of the elemantary tile. In KDE the backgrounds
of the menu bars are created this way. When a menu bar needs to be
redrawn XAA simply copies a portion from this offscreen pixmap into
the framebuffer.

Now the problem: The i810 blit engine seems to be broken in that
it cannot copy a portion of the framebuffer right to the right of
itself if the width of this area is in a certain range.

I found that out by trial and error as Intel appearantly doesn't
provide errata sheets. I've attempted to make a fix for this which 
I will soon commit to CVS. I don't know it it catches all cases 
however the KDE desktop on my test machine appears to be uncorrupted 
now.
Your milage may vary.

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

Reply via email to