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