Guys, I've been thinking about the KDE problem some more. I was playing with KDE a few weeks ago (I never even install it on my own systems which is why I never see this bug) and was able to make some observations about the bug.
#1 The errors are really in the framebuffer. They can be captured in a screen shot and they do not disappear simply by moving the windows around etc. You actually have to cause a repaint to clear up the corrupted area. This means it is NOT related to the MEMMODE/Watermark problems that we see from time to time. Those are just FIFO underruns that cause corruption on the screen but not in the framebuffer. #2 It happened during a few different resolutions. I didn't do a formal test of all of the modes but some modes that should not have been bandwidth limited were impacted. Also, it only happens on KDE... if it were bandwidth etc. we would see it all the time. #3 The only place I could make it happen on a regular basis was when changing focus between windows with a konqueror(sp?) open. The title bar for the window that lost focus would get blitted with a new pixmap and would result in a corrupted title bar. Causing the same title bar to get repainted on a little by little basis (by partially occluding and exposing it) would make it repaint correctly. So I am pretty sure that the pixmap is fine, but the blit is fetching incorrect data. #3 Dirk Narrowed it down to these Xaa functions: > On my system, any one of the three options > Option "XaaNoOffscreenPixmaps" > Option "XaaNoPixmapCache" > Option "XaaNoScreenToScreenCopy" Looks like whenever offscreen pixmaps are used and those get used by the blitter the problem will show up. This is where my knowledge of X runs out. I need some help. When X stores a pixmap in offscreen memory what is the pitch of that pixmap? Does it keep the same framebuffer pitch? Does Xaa break this blit into single scanlines? I was thinking that perhaps the fact that our pitch != width causes a problem with doing multi-scanline blits from offscreen pixmap caches. And perhaps something about the way KDE is using the pixmaps makes this more likely to happen. Any thoughts? Dirk, If you are up for some more testing try this: Run at 1024x768. In this mode the framebuffer pitch == width. This is the only mode that has this property. If the problem goes away as a result then that helps narrow the search. -Matt _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
