Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 139216 - xorg picks wrong modeline for lcd monitor
Summary: xorg picks wrong modeline for lcd monitor
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact:
Depends On:
Blocks: FC5Target
TreeView+ depends on / blocked
Reported: 2004-11-14 04:57 UTC by Parrish Myers
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-05-17 05:40:06 UTC

Attachments (Terms of Use)

Description Parrish Myers 2004-11-14 04:57:25 UTC
Description of problem:

when booting fc3 the screen goes blank when xorg starts.

Version-Release number of selected component (if applicable):


I have an HP Pavilion ze4315us laptop.  I have so far determined that
the video card, which is a radeon igp320, is correctly identified. 
Yet the monitor is not.  When the Xorg server starts it apparently
passes up the 1024x768 resolution (the natural size for the laptop
lcd) size claiming the HorizSync and VertRefresh are out of range and
then the screen goes black.  I haven't found a modeline that works
yet... but apparently this new xserver gets it wrong for my laptop.

Comment 1 Randy Poser 2004-11-17 16:35:34 UTC
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.

Comment 2 Michal Bejger 2004-11-20 19:03:51 UTC
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. 

Comment 3 Trevin Beattie 2005-01-18 02:28:46 UTC
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
( to an 'Option "Use
ModeLine"', but when I try to set this, the radeon driver spits back
"Option "UseModeline" is not used".

Comment 4 Mike A. Harris 2005-02-11 22:06:25 UTC
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?

Comment 5 Parrish Myers 2005-02-11 23:45:05 UTC
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.

Comment 6 Trevin Beattie 2005-02-12 01:38:55 UTC
# 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.

Comment 7 Mike A. Harris 2005-04-15 12:26:03 UTC
>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 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.

Comment 8 Mike A. Harris 2005-05-17 05:40:06 UTC
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

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

Note You need to log in before you can comment on or make changes to this bug.