When running Redhat 7.1, I've noticed the following strange behavior on my RAGE 128 RF. I believe that it is all related: 1) Scrolling in KWrite (QT), Emacs (xt) and Abiword (GTK), all ficker black when the text is scrolled quickly. 2) When logging out of KDE2, instead of the normal shaded stipple, the entire screen turns black, with the exception of the dialogue box in the middle. 3) As menus are flipped through, they leave black underneath them. They are eventually repainted, but it is very distracting. There are only certain types of surfaces that turn black when passed over. Whitespace in Konqueror turns black (empty space on the webpage), but text fields (such as the one I am typing in...) remain a sane color. (in this case, white) This is VERY annoying, and makes the otherwise polished desktop look flakey. It is almost as if the surface underneath were intiallized to black, instead of the proper color. This problem disappears if: 1) I disable DRI. 2) I use Option "UseCCEfor2D" Neither of these are acceptable. (I need 3d, and I can't handle the slowness of the CCE) If you need more experients or something for me to try, just drop me a line. I've attached my lspci, dmesg, & a picture of the blackness. The screen shot was taken with ksnapshot. Note, on the original screen, there is a window where the blackness in the snapshot is. Phil
Created attachment 16946 [details] My lspci
Created attachment 16947 [details] dmesg for the system
Created attachment 16948 [details] XFree86 log file
Created attachment 16949 [details] snapshot of the black strangeness..
Cool! I see some of it too on Rage 128 _PF_. My blackness, however, manages to recover extremely quickly. I just see some flickering in certain areas. For example, KDE's time set tool flickers in the area of clock. I also see this in your dmesg: [drm:r128_do_wait_for_fifo] *ERROR* r128_do_wait_for_fifo failed! This is still unresolved, see bug 26999. Maybe it's time to update r128 driver from 20001215 to something newer? I suggest that you use 16 bpp color depth instead of 24/32. It might cure a lot of problems, you won't see a difference, you'll enjoy much faster 3d-acceleration, and you'll see the above messages much less often.
I've flipped to using 16-bit color, and things are faster, but the problem still remains.
Bug was misfiled against XFree86-Servers-3.3.6, reassigning to XFree86-4.0.3.
I have reproduced this problem on an ATI AIW r128p 32M (AIW 128 Pro) AGP. That is the black splotches as well as the fifo errors. The fifo errors are kernel bugs in DRM, not XFree86, and may or may not have to do with the black splotches.
I've traced things down a little further, and I think I've found another clue to the puzzle. It appears that the "XClearWindow(xparms.d, xparms.w);" call causes a significant amount of flicker. XClearWindows is supposed to clear that window to the background color. I don't know all that much about X, but I would imagine that most of the widgets/windows use this when they are redrawing themselves. I've attached a very hacked version of x11perf which shows the problem clearly. This program should simply open a window and clear it white 1000 times. It is easy to see a band of black as this tries to clear the screen white. I'm not quite sure where the "XClearWindow" call is handled in the Xserver, or I would investigate more.
Created attachment 17546 [details] XClearWindow flicker testcase
Created attachment 17547 [details] X11perf header file.. Required for above test case.
The do_wait_for_fifo and do_wait_for_idle errors reported on r128 cards when doing DRI are fixed in our latest Rawhide kernel on rawhide.redhat.com. This fix has been tested and confirmed. Please give it a shot and let me know if it fixes at least that problem for you. It works for me.
I will be out of town next week. I am going to try the new kernel before that.. If I can't, I try a week from now. --Phil
I've check it out... The 2.4.3-5 kernel on rawhide does NOT fix the problem.
I have the same problems: screen flicker with black bands... it wasn't there for redhat 7.0 and i ahve installed all updates to the os (including kernel, etc.). nice little demo by ezolt.dec.com - shows the problem clearly. i hope this gets sorted out soon, becuase it is driving me crazy and i am wishing i hadn't upgraded! mj-
oh, and furthermore, my machine (laptop) is using the ATI|Rage Mobility M3 AGP 2x graphics card. mj-
This bug is fixed for me by the XFree86 4.1 rpms in rawhide.
Created attachment 21806 [details] XFree86.9.log log file
XFree86 4.1 rpms installed from rawhide on RH7.1 (with all updates) on a machine with a ATI|Rage Mobility M3 AGP 2x, does not work at all - i.e. will not allow the X server to start (see attached log file above ). any ideas? had to switch back to XFree86-4.0.3-5 rpms. thanks,\ mj-
Hmm, looks like the XFree86 rpm has been broken since I installed it; my libbitmap.a doesn't have those undefined symbols. The one that works for me is XFree86-4.1.0-0.0.1. Just to verify, do the undefined symbols also show up with nm -u /usr/X11R6/lib/modules/fonts/libbitmap.a ? I also have an M3 laptop (the Dell C600); thus my interest. But I'm on the compiler team, not OS, so I can't really do anything about the problem for you. I expect the undefined symbols will be fixed in the next rawhide release, though.
know where i can get the XFree86-4.1.0-0.0.1 rpms? tried nm -u /usr/X11R6/lib/modules/fonts/libbitmap.a, but no symbols listed as per the errors in the above XF86 log file. This is regardless of the XFree86 version (the one that works, and the one that doesn't). i attached the output of the above command (the same for both versions) in libbitmap.a.4.1.0-0.5.9.txt have noticed that /usr/X11R6/lib/modules/fonts/libbitmap.a lives in the XFree86-xfs-4.0.3-5.i386.rpm for 4.0.3-5, but in the XFree86-4.1.0-0.5.9.i386.rpm for 4.1.0-0.5.9 any further help appreciated... mj- i also attach a XF86.4.0.3-5.log that works, but gives the black flickering stuff mentioned above.
Created attachment 21848 [details] output of nm ....
Created attachment 21849 [details] log file for working, but flickering XFree86.4.0.3-5
Does objdump -h show any of the .rodata.* sections mentioned in the bad log?
yes, they're there. don't know what to make of this though. mj-
Created attachment 21851 [details] output of objdump...on 4.1.0-0.5.9
Well, that's almost certainly the problem, then. Sounds like whoever built the RPM was passing -fdata-sections to gcc, and the XFree86 module loader can't deal. The solution is to not use that flag. Mike, care to push out a new rpm? In the meantime, I notice that rpmfind.net still has the 0.0.1 rpms that I've been using with no problems.
thanks - 0.0.1 rpms work fine.... and solve the problem for the moment. mj-
ezolt: Do you still see this problem with XFree86 4.1.0-3 as released with Red Hat Linux 7.2? If you could test it, and update the report, I'd appreciate it. If the problem still exists, I can then dig deeper into it, otherwise if it is solved, I'd like to close the report now. Thanks.
This problem seems long since fixed in 4.1.0, the current release of X for both 7.1 and 7.2 is 4.1.0-15.