Description of problem:
During installation the Monitor's vertical and horizontal syncs were not
detected and could not run the graphical install. After install I ran redhat-
config-xfree86 and it still could not find the vertical and horizontal syncs.
It ran dcc probe and reported none for all four values. My monitor is a dell
LCD 1600X. I could not solve the problem in either cases other wise because it
did not let me select my monitor settings manually.
Version-Release number of selected component (if applicable):
I can reporduce it everytime.
Steps to Reproduce:
1. Try installing it on dell inspiron 8000 notebook with 15 inch LCD screen and
ati video card.
2. Also can reproduce when Phoebe beta is installed by running redhat-config-
all four values are reported back as "none"
HorizSync: 31.5 -90.0
VertRefresh: 59.0 - 85.0
LCDs can't really be DDC probed. What were the errors when you tried to pick
manually? Was is just not in the list?
jrmizell: please try redhat-config-xfree86-0.7.1-4 out of Rawhide and see if
that fixes the problem. That version made some Inspiron 4000's work for the
first time, so maybe it will work for you too. (See bug #80402).
Changed the summary to something more descriptive
tried the redhat-config-xfree86 from rawhide and it did not work. It trys a
dcc probe even though it is a LCD screen and still does not get any values for
it. IT does not give me a list to try and pick from. The only list avalible is
in the anaconda installer. After running redhat-config-xfree86 from the beta
and from rawhide you get a screen that says it could not read the xfree86
configuration file or it is corrupt. Then try to do the detection which fails
with the message I gave before describing the actual results. Then gives you
options to try again or cancel.
Just for correctness...
Some LCD's can be DDC probed, but most can't.
I have the same problem with the graphical installer of Phoebe 8.0.92 & 8.0.93,
this is on a Dell Inspiron 8000 w/ ATI Rage 128 Mobilty M4 & 15 inch screen.
The text installer created a XF86Config file which contained the following:
Modes "1024x768" "800x600" "640x480"
None of these modes seem to work with this release of XFree86 (but they did on
Red Hat Linux 8.0)
When I change it to:
Modes "1600x1200" "1280x1024"
Modes "1600x1200" "1280x1024"
I can at least use XFree86 using the r128 driver and DRI Acceleration. I would
recommend that whichever tool (possibly redhat-config-xfree86) generates this
config file has a modes line that looks like:
Modes "1600x1200" "1280x1024" "1024x768" "800x600" "640x480"
That way at least it will have some modes in there that do work. Tracking down
why resolutions <= 1024x768 don't work could be filed as a new bug.
Ok, I think I'm starting to get an understanding of what's happening. When
r-c-xfree86 runs and generates a file from scratch, it does the following things:
1) probes the video card and monitor
2) does some algorithms to figure out what modes this card/monitor combo can
3) generates the file
4) starts the X server with this baseline file.
What is happening is that the monitor can't be probed, so the detection code
reverts back to a generic monitor. Unfortunately, this causes step 2 to
determine that the monitor can't do anything above 1024x768. Since it seems
that this mointor can't do anything <= 1024x768, it causes steps 3 and 4 to fail.
This problem occurs on my laptop, whose screen cannot be probed. However, since
my screen can do <= 1024x768, falling back to the lower resolution isn't such a
bad thing. In your case it causes the tool to not work.
Unfortunately, I'm not sure what I can do about it. Ultimately, we need a
better way to detect LCDs as that would solve everything. Given where we are in
the release cycle, I'm not comfortable with making the kinds of changes
neccessary to address this. It also doesn't help that I don't have access to an
Inspiron 8000 to test with.
Here's one workaround that you might try.
1) Move your existing /etc/X11/XF86Config file out of the way
2) Run 'redhat-config-xfree86 --set-hsync='31.5-90.0' --set-vsync='59.0-85.0'
3) See if an /etc/X11/XF86Config file was created
4) See if that file works.
Any luck with the workaround?
msw: can you try testing the latest tree on your Inspiron? I'm curious to see
if the latest r128 driver allows this screen to do lower resolutions. Also msw,
do you know which screen you have? It looks like there are three possible
screens for this laptop:
From Dell's website:
15 inch UltraSharpTM UXGA+ TFT active-matrix display with 1600 x 1200 resolution
15 inch Ultra XGA TFT active-matrix display with 1600 x 1200 resolution
15 inch Super XGA+ TFT active-matrix display with 1400 x 1050 resolution
I can't find anything on their website about the other possible resolutions that
these screens can handle.
msw's test on his laptop did not work.
When redhat-config-xfree86 can't probe a monitor, it tries to use 800x600.
After talking with msw, I'm going to transfer this bug to XFree86 since I
believe that the real problem is that the r128 driver isn't allowing the screen
to do 800x600, which it should be able to do.
I found a temporary work a round until the xfree86 detection method is fixed.
Just use the Vesa card settings to get X up and running. Here is an example:
VESA driver (generic)'--set-videoram='0'
I'm adding this comment on behalf of Tim Garlick <email@example.com>
who discovered this same problem after doing a fresh install of RHL9.
He was running RHL7.1 (he thinks) before with no problems.
We just now downloaded the -10 packages from Rawhide and tried again with no avail.
He is running the "vesa" driver as a workaround.
I have been reporting this problem to m harris for a year without any
resolution. The only two things that I have found to work is to use the vesa
driver and not have a faster display or get the beta driver from:
The r128 driver sucks.
Has anyone tried the lastest XFree86 from rawhide (4.3.0-15 right now)?
* Wed May 28 2003 Mike A. Harris <firstname.lastname@example.org> 4.3.0-13
- Updated to XFree86-4.3.0-xf-4_3-branch to pick up the latest fixes from the
stable XFree86 4.3.0 branch
Any word if this is fixed with the severn beta?
This looks like this might have gotten fixed for the upcoming 4.4.0
Yep, it seems to be fixed now.
Please upgrade to Fedora Core 2 or later, and if this issue turns
out to still be reproduceable, please file a bug report in the
X.Org bugzilla located at http://bugs.freedesktop.org in the
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.