Do you have any traceback info?  

I don't have that exact laptop, but my Compaq Presario 1700T laptop at home has
a Rage Mobility P/M AGP 2x (rev 64), which sounds similar although not
identical.  redhat-config-xfree86 works ok on that laptop.

Also, can you try redhat-config-xfree86-0.7.1-1 out of Rawhide and see how that
goes?  I recently took ownership of this package and I am trying to give it more
attention than it has received in the past.  The code has changed a lot since
0.6.9-2.

There's not time to add a TUI mode for GinGin, but I'd like to do that for the
next release.

Is there time to reinclude Xconfigurator? The guts of that application (hwdata,
kudzu) are still present, it should work with little effort. That way, if
redhat-config-xfree86 is not successful, it could print a little message for the
user like "I was not able to configure X Windows. You may want to try using
Xconfigurator to manually configure X Windows."

I'll get a more specific debug tonight, and I'll try the new package.

I really don't want to include Xconfigurator again.  The right answer is to fix
redhat-config-xfree86.  Although Xconfigurator has a text interface, it had
plenty of open bugs against it when it was decommissioned.  We don't have the
resources to maintain two X tools since we can barely maintain one.  Bringing it
back now would be a nightmare.

I assure you, Xconfigurator is totally, completely, irrevocably removed
from Red Hat Linux, and will not return, ever.

As Brent says, redhat-config-xfree86 is what we ship now, and we want
bug reports for things that do not work.

If anyone adds Xconfigurator, I'll make sure an rpm -e Xconfigurator is
executed from within the X server binary at startup.

redhat-config-xfree86-0.7.1-3 out of rawhide correctly detects and probes X on
my laptop. :)

I've got a new Sony VAIO R505G laptop, and even the latest Rawhide
redhat-config-xfree86 is unable to autodetect the LCD display.  (I've been able
to use the generic laptop 1024x768 option, though.)

(Also, ddcprobe does not return the monitor type.)

For cases where the monitor type is not autodetected, I'd be very happy if the
installer queried for the monitor type as soon as possible.

(Since ddc doesn't work, how can LCD monitor type be determined?  Is it
impossible, or is something just waiting to get implemented?)

jsk29: some LCD's cannot be probed with ddcprobe, usually ones with laptops. 
Most flatpanel monitors these days can be probed, like my Dell 1702FP at home,
but laptop screens must do something different at the hardware level.

Apparently X has some way of probing these kinds of monitors, but this probing
is not (as far as I know) made available to programs other than X via an API. 
We are investigating ways to try to go about this, whether that's parsing the
output of the X.log when starting X fails (this logfile usually contains the
probing information) or whether it means pulling the actual probing code out of
X itself.  I can't promise that we'll have this fixed for the next release, but
we're definately aware of the problem.

The general methods for probing LCD's in no particular order are:

1) DDC probe
2) BIOS calls
3) BIOS snooping
4) ACPI info

The only one that is very reliable is DDC, however DDC is not implemented
on a large number of LCD panels, which sucks.  Furthermore, the other 3
methods are rather extremely hardware dependant and not very reliable.

Windows has a bit of an advantage here, because a laptop comes with driver
disks, .INF files, etc. specifically designed for that laptop / LCD, which
inform Windows of what it needs to know, in addition to the various
probing techniques.  We unfortunately (the open source community) do not
enjoy these luxuries yet.

Thanks for the rundown Mike, that was very useful.  If I can be of any help
learning how to identify the VAIO R505G displays, let me know.

I had figured that the preinstalled drivers were giving Windows an unnatural
advantage.  Hopefully someday Sony will decide to Red Hat certify all of their
laptop hardware. :)

Thanks again!