Bug 80402 - redhat-config-xfree86 is dirtier than zebra
redhat-config-xfree86 is dirtier than zebra
Status: CLOSED RAWHIDE
Product: Red Hat Public Beta
Classification: Retired
Component: redhat-config-xfree86 (Show other bugs)
phoebe
All Linux
medium Severity high
: ---
: ---
Assigned To: Brent Fox
:
Depends On:
Blocks: 79579
  Show dependency treegraph
 
Reported: 2002-12-25 17:33 EST by Tom "spot" Callaway
Modified: 2008-05-01 11:38 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-09 22:27:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom "spot" Callaway 2002-12-25 17:33:43 EST
Description of problem:

redhat-config-xfree86 was completely unable to configure X on my Dell Inspiron 4000.

01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M3 AGP 2x
(rev 02)

As a point of reference, this tool has NEVER been able to configure X on my
laptop during the entire tenure of its existence, where Xconfigurator never had
a problem. The lack of a TUI mode for this tool, combined with anaconda's
failure in Phoebe (Bug #80401) to configure X left me with no way to get X
running. This situation is generally unacceptable to the end user.

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

0.6.9-2

How reproducible:

Always

Steps to Reproduce:
1. run redhat-config-xfree86
2. watch it try to configure X, and repeatedly fail.

    
Actual results:

No way (short of manually hacking the XF86Config file) to get X running on my
laptop.

Expected results:

Working X configuration, working X.

Additional info:

IMHO, this tool is the worst in the redhat-config-* suite. Whoever wants to take
responsibility for it should take a good hard look at it from a usability
perspective, given that there are situations where its "magic" simply fails.
Using Xconfigurator (or adding an equivalent TUI mode) as a fallback option if
the "magic" autodetection fails would be an adequate solution to this issue.
Comment 1 Brent Fox 2003-01-06 01:25:37 EST
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.
Comment 2 Tom "spot" Callaway 2003-01-06 09:43:45 EST
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.
Comment 3 Brent Fox 2003-01-06 12:03:40 EST
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.

Comment 4 Mike A. Harris 2003-01-07 08:37:41 EST
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.
Comment 5 Tom "spot" Callaway 2003-01-09 22:27:20 EST
redhat-config-xfree86-0.7.1-3 out of rawhide correctly detects and probes X on
my laptop. :)
Comment 6 John 2003-01-17 15:25:34 EST
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?)
Comment 7 Brent Fox 2003-01-17 15:52:27 EST
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.
Comment 8 Mike A. Harris 2003-01-18 05:12:11 EST
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.

Comment 9 John 2003-01-18 11:39:02 EST
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!

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