Bug 8790

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