From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Description of problem:
Xconfigurator (as well as other X configuration tools) cannot properly detect
or set up X on this machine. I have an XF86Config-4 that works, but it only
works after Xconfigurator has been run (unsucessfully). My question, more
important than fixing the problem with Xconfigurator, is what does
Xconfigurator do that makes the XF86Config-4 work after having run it? I've
heard it sets up symlinks, but I want to ask because the group I'm working
with (on cluster installation software) is interested in being able to set up
X across many machines by cloning the X setup on the head machine.
Version-Release number of selected component (if applicable): 4.9.39-1 tested
Steps to Reproduce:
1. Install RedHat
2. Watch X configuration fail
4. Try Xconfigurator
5. Watch it fail
6. Install working XF86Config-4
7. Start X with gdm/xdm/startx/whatever and enjoy X
Actual Results: X wasn't set up correctly by step 5, but worked after step 6.
Expected Results: Xconfigurator should set it up properly, but I want to know
what Xconfigurator does to make my XF86Config-4 work after it's been run.
I can provide the XF86Config-4 if you want...
Xconfigurator probes hardware to determine various configuration settings,
and eventually writes out the XF86Config and XF86Config-4 files. The former
file is for XFree86 3.3.6, and the latter is for XFree86 4.x. In addition,
Xconfigurator sets up the symbolic link to the correct X server. In the
case of XFree86 4.x, it points the symlink to the XFree86 executable, and
in the case of a 3.3.6 server, it points the symlink to the specific X server
being used (since 3.3.6 has many X servers whereas 4.x only has one server).
Xconfigurator by default chooses the X server based on the data provided
in the "Cards" database. This data indicates which server is the prefered
server based on both customer feedback, testing, and available support
data from upstream. In general, we default to the 4.x server for all
hardware unless a particular piece of hardware does not work at all, or
works quite poorly with 4.x, but 3.3.6 works much better. In that case
we default the X server to the 3.3.6 one.
Of course, the "default" is intended to be the best one to use in the
general case for most users, and is based on feedback, etc. It is impossible
to have a default work for everyone with every piece of hardware out there
of course, so we allow users to override the default. Sometimes there is
sometimes fringe hardware or hardware combinations. You can use the
--preferxf3 and --preferxf4 options to force a given server. The
Xconfigurator manpage lists the full options available.
I can't hazard a guess as to what the problem is that you are specifically
experiencing however without more information. I don't know what a
Portege 4005 is for example. I would need to know the exact video hardware
in your machine, which can be obtained via the command: lspci -vn
and also "lspci -v". Please include both.
Also attach your X server log and working config file, as well as the
nonworking one that Xconfigurator spits out (if any). Once I've gotten
all of this information, I may be able to determine what the problem is.
Also, make sure that you are running all of the updates that have been
released for RHL 7.2 first.
There has been no activity in this bug report since it was filed, and
the requested information that is required for minimal investigation has
not been supplied, so I am unable to troubleshoot/debug or begin to
guess what the problem could have been.
Closing bug WONTFIX for the time being, as there isn't any way to
proceed with the supplied information. If the problem is still a
concern, please reopen the bug report and supply the requested