I've been fighting with the radeon driver in the new Fedora Core 6 release and the same hardware I had back in bug 7243. The symptoms this time: In the X log file where the radeon driver is printing all the info about video modes, it claims the 1920x1080 mode info results in 66.6 Khz vertical and 59.9 Hz horizontal. Those numbers would be swell if they matched the signal actually fed to the monitor, unfortunately the monitor tells me (when it is able to work) that the signal it is getting is 68K vertical and 61 horizontal. The symtoms I see are the monitor blanking then unblanking then blanking, etc. This goes on for a while and it either decides to cutoff completely, or if I'm lucky, decides to stay on (but if I power off the monitor and come back later, it will probably start the cutting on and off again). I notice a Windows box connected to the same monitor, running off the same DDC info provided to a radeon card produces a signal that the monitor claims is 66k vertical and 59 horizontal and is rock solid - no flickering on and off. All the details of which versions of drivers and X log files and wot-not no doubt need to be attached to this bug, but I can't do that till I get home later today. Just thought I'd go ahead and get this in the system and maybe someone might recognize the problem. Also if anyone can tell me how the heck to defeat all the wonderful new fully self configuring stuff and make it go back to just using the mode line I provide, that could be helpful as well since I might be able to manually configure it to work (I don't think any mode I could manually generate could do any more harm than constant turning on and off that I get now anyway :-). The mode line reported in the log file is identical to the mode line I provided manually with the older versions of X in previous fedora releases (just copied from the info that showed up in the log, but wasn't applied automagically like it is now), and I may have seen the signal cutout once every few months, but not constantly like now, so something different is happening to the numbers in this new driver by the time they generate an actual signal on the DVI port.
Perhaps this is all part of the saga recorded in bug 2859. I guess I need to figure out how to build the source rpms from fedora 6 to try out some of the patches... It sure would be nice to have Option "UseTheModeLineLuke" to let me manually plug in different values.
Created attachment 7557 [details] Here's the minimal xorg.conf file with everything automatically deduced Other than the mouse definition I have to add to get draglock working on my trackball, this xorg.conf is the same as the minimal one that FC6 generated on install.
Created attachment 7558 [details] Here's the Xorg.0.log file that xorg.conf file generates. The most interesting line in this file is the one that says: (**) RADEON(0): *Driver mode "1920x1080": 138.5 MHz (scaled from 0.0 MHz), 66.6 kHz, 59.9 Hz If the signal was actually that frequency, the monitor would have no problems, but the onscreen display info menu for the monitor says it is getting a 1920x1080 signal with H. Frequency 68KHz and V. Frequency 61Hz (I may have gotten those backwards in my previous test :-).
For what it is worth, here are all the xorg rpms installed on the system (looks like it is version 7.1): xorg-x11-fonts-base-7.1-2 xorg-x11-drv-trident-1.2.1-3.fc6 xorg-x11-drv-nv-1.2.0-4.fc6 xorg-x11-server-sdk-1.1.1-47.fc6 xorg-x11-xbitmaps-1.0.1-4.1 xorg-x11-xinit-1.0.2-12.fc6 xorg-x11-drv-mouse-1.1.1-1.1 xorg-x11-drv-microtouch-1.1.0-1.1 xorg-x11-drv-joystick-1.1.0-1.1 xorg-x11-drv-ati-6.6.2-4.fc6 xorg-x11-utils-7.1-2.fc6 xorg-x11-drv-palmax-1.1.0-1.1 xorg-x11-drv-aiptek-1.0.1-2 xorg-x11-drv-vmmouse-12.4.0-2.1 xorg-x11-drv-s3virge-1.9.1-2.1 xorg-x11-xtrans-devel-1.0.1-1.1.fc6 xorg-x11-proto-devel-7.1-9.fc6 xorg-x11-fonts-ISO8859-1-100dpi-7.1-2 xorg-x11-drv-acecad-1.1.0-2.1 xorg-x11-drv-s3-0.4.1-2.1 xorg-x11-xkb-utils-1.0.2-2.1 xorg-x11-drv-evdev-1.1.2-2.1 xorg-x11-drv-ur98-1.1.0-1.1 xorg-x11-fonts-ISO8859-1-75dpi-7.1-2 xorg-x11-drv-siliconmotion-1.4.1-2.1 xorg-x11-drv-summa-1.1.0-1.1 xorg-x11-drv-magellan-1.1.0-1.1 xorg-x11-drv-dummy-0.2.0-2.1 xorg-x11-drv-fbdev-0.3.0-2 xorg-x11-drv-vmware-10.13.0-2.1 xorg-x11-xfs-1.0.2-3.1 xorg-x11-drv-vesa-1.2.1-4 xorg-x11-twm-1.0.1-3.1 xorg-x11-apps-7.1-3.fc6 xorg-x11-fonts-truetype-7.1-2 xorg-x11-drv-penmount-1.1.0-2.1 xorg-x11-drv-digitaledge-1.1.0-1.1 xorg-x11-drv-vga-4.1.0-2.1 xorg-x11-drv-i810-1.6.5-9.fc6 xorg-x11-xtrans-devel-1.0.1-1.1.fc6 xorg-x11-server-utils-7.1-4.fc6 xorg-x11-server-Xorg-1.1.1-47.fc6 xorg-x11-fonts-75dpi-7.1-2 xorg-x11-drv-spaceorb-1.1.0-1.1 xorg-x11-drv-elographics-1.1.0-1.1 xorg-x11-drv-mutouch-1.1.0-2 xorg-x11-drv-voodoo-1.1.0-3.1 xorg-x11-drv-citron-2.2.0-1.1 xorg-x11-server-Xvfb-1.1.1-47.fc6 xorg-x11-xauth-1.0.1-2.1 xorg-x11-font-utils-7.1-2 xorg-x11-drv-void-1.1.0-3.1 xorg-x11-drv-dynapro-1.1.0-2 xorg-x11-xdm-1.0.5-5.fc6 xorg-x11-fonts-misc-7.1-2 xorg-x11-drv-sis-0.9.1-7 xorg-x11-drv-ast-0.81.0-3 xorg-x11-drv-tdfx-1.2.1-3.1 xorg-x11-drv-calcomp-1.1.0-1.1 xorg-x11-drv-elo2300-1.1.0-1.1 xorg-x11-util-macros-1.0.2-4.fc6 xorg-x11-xsm-1.0.2-4.fc6 xorg-x11-drv-dmc-1.1.0-2 xorg-x11-fonts-Type1-7.1-2 xorg-x11-drv-via-0.2.1-7 xorg-x11-drv-jamstudio-1.1.0-1.1 xorg-x11-drivers-7.1-3 xorg-x11-drv-mga-1.4.2-1.fc6 xorg-x11-fonts-100dpi-7.1-2 xorg-x11-drv-cirrus-1.1.0-2.fc6 xorg-x11-drv-hyperpen-1.1.0-2 xorg-x11-resutils-7.1-2.fc6 xorg-x11-xfs-utils-1.0.2-3.1 xorg-x11-drv-sisusb-0.8.1-4.1 xorg-x11-drv-magictouch-1.0.0.5-2.1 xorg-x11-docs-1.2-4.fc6 xorg-x11-filesystem-7.1-2.fc6 xorg-x11-drv-keyboard-1.1.0-2.1 xorg-x11-drv-fpit-1.1.0-1.1 xorg-x11-drv-savage-2.1.1-5.fc6 xorg-x11-server-Xnest-1.1.1-47.fc6
Created attachment 7566 [details] log from working version of X This gets weirder and weirder. I have now installed SUSE 10.1 to compare the X behavior with Fedora Core 6 (suse has X11 version 6.9.0). The monitor reports the same 68K and 61Hz frequencies under SUSE as it does under Fedora, yet for some reason (this is with all the same hardware), the display seems rock solid under SUSE, so I'm including the SUSE log file in the hope that someone will see something different that explains the behavior under FC6. I do have to specify the modeline manually with SUSE, but I'm giving it the same info from what the monitor claims it wants.
I've now tried Windows XP and reinstalled FC5 on this box and noticed that Windows does have an occasional flicker on and off problem even though the monitor reports it running at the 66KHz, 59Hz that X claims to be trying for (but actually exceeds). The problem is not excessive on Windows, and often doesn't appear at all. On FC5 I haven't yet seen a flicker (though I did occasionally encounter one when I previously had FC5 installed). The monitor reports the same 68KHz, 61Hz numbers for FC5 that both suse and FC6 report. I really have no idea why FC6 is so unusably unstable and everyone else either has no problem at all, or only an occasional flicker, but since these are all on the exact same hardware, there is clearly something the FC6 software is doing that makes it lots worse. I'm now contemplating an intense code review comparing the 7.0 and 7.1 radeon drivers :-).
Created attachment 7604 [details] log from i686 version of Fedora Core 6 Yikes! This is starting to seem like it might be a x86_64 compiler problem or a 64 bit code problem in the 7.1 radeon driver. I have now installed the i686 version of Fedora Core 6, and I haven't yet noticed a single flickering on/off of the display when running i686. (Or perhaps I've just been lucky so far tonight :-).
Since this is potentially something like a x86_64 compiler or build problem, I have also added a fedora bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213170
Since adding the i686 version, I have observed one incident of flickering, but it stabalized with the picture on fairly quickly, so the problem isn't entirely gone on i686, but so far, still seems better than x86_64 with same source base. I don't supposed there is some kernel tracing code I can activate somehow to record the actual transactions with the radeon card registers to compare FC5 to FC6?
I've now had a chance to use the FC6 i686 installation for a more extended period of time, and I begin to suspect that the i686 has as big a problem with flickering on and off as the x86_64, so the initial apparent improvement may just have been random chance.
I have noticed that the flickering could be triggered almost all the time by running an opengl app (previewing 3d screensavers, running neverputt, etc), so I thought maybe 3d had something to do with the problem. I finally contrived a Modules section in xorg.conf that left out glx and dri, but when I let dpms turn off the monitor, the flickering was back when I tried to turn it back on. Just continuting to gather data. I'd like to run with my own modeline, but that seems to be impossible. Even when I tried the PanelSize option of the radeon driver, the fedora server manufactured its own modeline instead of using mine (and the one it manufactured didn't have reduced blanking, so it was wayyy out of range for the monitor).
More news: I installed the (livna) fglrx driver on FC6 i686 and after fighting with it for a while (had to manually run ldconfig to get the ati version of mesa at the front of the search list), I get three things for the first time: 1. Good 3d performance, 2. No screen flickering, 3. It is willing to take my hand crafted modeline (to run at a slightly lower than 60HZ refresh rate). All the things that trigger flickering with the radeon driver (letting dpms power saver kick in, running 3d apps) have (so far - knock on wood) not triggered any screen flickering. I also noted that even before I installed my modeline, the refresh rate my monitor was reporting was lower than the rate the radeon driver runs the monitor at (presumably using the same EDID info, but apparently not coming to the same conclusions). The fglrx driver was reporting 59HZ instead of 61HZ.
Created attachment 7792 [details] My working xorg.conf file Pant, pant, wheeze.... At long last, I uncovered the key to forcing the smartass radeon driver to use my modeline to run with reduced blanking at 58 HZ. I am using it now, and so far, I have been able to induce some minor flickering by doing things like running a fullscreen preview of the "Lattice" screensaver. but mostly the display remain fairly stable (and the flickering stops when I turn off the preview). Neverputt or glxgears don't seem to trigger the flickering, and turning off the screen via dpms doesn't wind up with flickering either. The only way to force it to use my mode line? Adding a module section with all the modules mentioned in the X log file is the first step. That allows me to turn the "ddc" Load entry into a subsection where I can specify the options to make it stop inventing its own mode info. Then I have to make sure I provide HorizSync and VertRefresh info in the monitor section so as to convince X my modeline isn't out of range. Then I have to add the ReducedBlanking monitor option to make X stop protecting me from myself. Then it finally uses my mode line. Where did I get my modeline? The "cvt.c" program in the X server source rpm has an option to generate a reduced blanking mode, but it is also a know-it-all butt-head smartass and refuses to do reduced blanking for anything other than 60HZ, so I had to smack it around some and rebuild it so all it does is print a warning, but is still willing to spit out the modeline. The source code is the only way to deduce this stuff. My monitor now claims to be running at Horiz 64KHz, Vert 58Hz. Possibly, I can finally use Fedora Core 6 without switching to an nvidia card (and running into as many problems with it as I have had with ati :-).
For the full story of my adventures in getting X to do my bidding, see: http://home.att.net/~Tom.Horsley/easy-linux.html where I document the whole sequence of events (and rant a bit :-). One of the rants is probably a useful suggestion (perhaps even planned already for next release?): Now that X contains the source for the "cvt" program, why not provide a new way to specify ModeLine data (the way everyone always wanted it to work :-), a section where you can tell it width and height, refresh rate, and the reduced blanking flag, and it just computes the mode line data for you.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Here's an interesting data point: I just installed fedora core 7 test 4 on the machine I've had all these screen blanking problems with, and so far, while running fc7, the screen blanking has not appeared (of course, it may just be waiting to get my hopes up before it crushes them :-). fc7 comes with xorg 7.1 (I think) and the ati driver rpm is labeled xorg-x11-drv-ati-6.6.3-2.fc7.
Nope, fc7t4 does not work better after all. Used it extensively for most of the day and the screen flickering did manifest again, so it was just trying to jack up my hopes to watch them fall from a higher place :-).
Can you try with the latest driver from ati git or release 6.7.192 or newer? I think this should be resolved.
closing
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.