Bug 139216

This sounds very similar to an issue I was seeing.  I have a 14 inch 
LCD attached to a Via Mini-ITX M motherboard with a CLE266 chipset.  
In FC1 and FC2, X used the vesa driver and all was well. In FC3, it 
wanted to use the via unichrome driver.  X fails to start.  The log 
file says HorizSync is out of range for all modes... and tells me the 
range for the monitor is 31.5 to ZERO!  The interesting thing is that 
it works about one time in 20 with the unichrome driver.

I've switched to the vesa driver for now, and everything works again.

My problem is somewhat similar; I have Toshiba m30-852 (nVidia 
GeForce FX 5200 64MB -- the card and screen, 1280x800 is recognised). 
 First of all, the 1280x800 is not present in the drop-down list. 
After manually adding modeline to /usr/share/rhpl/extramodes there is 
no way to force xorg to addapt the desired resolution. 

I have a similar problem with my ATI Radeon 9700 Pro after switching
my monitor from a CRT screen to a digital LCD (ViewSonic VP191s).  The
ModeLines shown in Xorg.0.log do not at all match the ModeLines I
specified in xorg.conf; X uses the same sync values for all
resolutions!  I can only get three resolutions to work: 1280x1024
(native), 1152x864, and 512x410 (go figure), and on the latter two the
LCD's Info panel shows the actual resolution is 1280x1022.  If I try
1024x768 or 800x600, the screen goes into vertical rolls and the LCD
complains "Out Of Range".

When I boot MS-Windows, the ATI display driver will show 1152x864,
1024x768, and 800x600 with no problems, and in all modes the LCD's
Info dialog shows their proper respective resolutions.  (That's how I
was able to come up with suitable timing values for the ModeLines).

I've seen reference in some of the documentation
(http://www.x.org/X11R6.8.1/doc/chips4.html) to an 'Option "Use
ModeLine"', but when I try to set this, the radeon driver spits back
"Option "UseModeline" is not used".

UseModeline is not a valid "radeon" driver option.  You're looking
at documentation for a different driver, and I don't see any
reference to "UseModeline" on the chips webpage URL you've provided.

"Modeline" is the correct config file option, and it is generic.

What does "ddcprobe" report for your display?

I can correct my origional bug submit somewhat...

The x server or the configuration scripts (I don't know which) picks
"ati" as the driver for my graphics card IGP320.  I believe that is
right, but the driver can't seem to pick a Modeline that works for the
LCD monitor and xorg exits.  If I instead change the driver to 'vesa'
everything works.  My LCD can only handle 1024x768 (well)... I believe
I also pick 24bit? colors.

By the way... I have found that all distributions based on this
release of xorg exhibit the same behavior.  I think the ones I tried
are: ubuntu, suse, fedora.

# ddcprobe 

Videocard DDC probe results
Description:  ATI Technologies Inc. R300
Memory (MB):  128

Monitor DDC probe results
ID: VSCb916
Name: VP191s
Horizontal Sync (kHZ): 30-82
Vertical Sync (HZ)  : 50-85
Width (mm): 380
Height(mm): 300
#

By the way, since my previous post I have downloaded and tried ATI's
fglrx driver (6.8.0-8.8.25-1), and their driver does respect the
ModeLine options in xorg.conf.  Unfortunately, it also locks up my
whole system.

>By the way... I have found that all distributions based on this
>release of xorg exhibit the same behavior.  I think the ones I tried
>are: ubuntu, suse, fedora.

Please update to the newest Fedora Core 3 xorg-x11 update, and if the problem
still persists, you may want to try xorg-x11 from rawhide, which contains
some additional fixes.  If the problem still persists in rawhide, please
file a bug report in X.org bugzilla, as this does not sound like a Fedora
Core specific issue from the above comment.

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.

Thanks in advance.

Setting status to NEEDINFO, awaiting results of testing feedback, and/or
upstream bug report URL for tracking.

It's been 3 months since the original reporter has commented on this
bug report, and we have not had the results of ddcprobe supplied, nor
any further additional information that would be useful in diagnosis.

Additionally, it's been 1 month since my last request in comment #7
to report the problem to X.Org and nobody has supplied any URL for
us to track.

Most of the "me too" comments from others here are definitely
similar bug reports, but each of these issues are very likely
driver specific issues, or config specific issues, and the 
solution for one of the problems almost certainly wont solve
anyone elses problems.  Roughly translated - each person is
having a different problem unrelated to each other, but with
similar symptoms for their own hardware, each of which will
require different solutions -> different bugs.  Each bug should
be in it's own bug report ideally, as we're only tracking the
original bug report here.

For us to diagnose it further internally, we would require direct
on-desk physical access to the hardware to reproduce and debug
locally any issues, however we do not have this hardware.  At this
point, we require people who can reproduce this to directly
troubleshoot it and provide the information we need, or there's nothing
we can do about it.  Alternatively, you must report the bug to X.Org
directly like I requested in comment #7, and hopefully another X
developer has the identical hardware and can reproduce it and diagnose
directly.

Closing WONTFIX, as the problem requires hardware we do not have
to diagnose.