Bug 115346 - config returns invalid configuration
config returns invalid configuration
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: XFree86 (Show other bugs)
1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-10 18:59 EST by Thoralf Will
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-03-09 14:25:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Thoralf Will 2004-02-10 18:59:02 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)
Gecko/20040113

Description of problem:
this also applies to the graphical installation of fedora

When using a TFT-display (Acer 1721) connected via DVI on a Matrox
G550 the configuration fails, the xserver starts in an invalid
frequency/resolution.

So I tried to do it manually.
The monitor has a hsync-range of 30-83kHz and a vsync-range of 55-75Hz
according to Acer, the program sets 30-83Khz and 60-75Hz according to
the config-file (/etc/X11/XF86Config). Resolution is set to the
recommended 1280x1024, color depth is set to 24. When trying to start
X the Xserver starts in an invalid resolution/frequency. I'm not that
familiar, so I simply connected an additional CRT-monitor to the
vga-connector to get to know if it can get to work. The CRT returned a
message telling me something of 32kHZ, invalid frequency. The
xfree-logfile is filled with messages telling me that he cannot find
any matching modes for several resolutions, including 1280x1024.

Even setting the resolution by hand fails when trying to start the
xserver.

I gave it another try and started the Fedora installation in graphics
mode again, when the installer starts x my TFT is claiming that there
is no valid input anymore - and shutting down. So once again I added
my CRT to see what's going on - and got an extremely flickering
picture, dunno which resolution but the frequency was incredibly low
for my taste, something like 50hz or even interlaced maybe.
Interesting to add is that the installer detected the TFT right as an
Acer 1721.

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


How reproducible:
Always

Steps to Reproduce:
1. add Acer 1721 to DVI input at Matrox G550
2. start Fedora installation or redhat-config-xfree86
3. see it failing
    

Actual Results:  no working xserver/no graphical installation possible

Expected Results:  well, a working xserver/graphical installation
process ;)

Additional info:
Comment 1 Thoralf Will 2004-02-11 15:43:54 EST
bug-source found: mga-driver is bugged, it works with the driver
provided by matrox. if interested i can provide additional
information. in general the provided (fedore)mga-driver is completely
unusable in the mentioned combination (tft/crt).
Comment 2 Mike A. Harris 2004-02-11 17:09:26 EST
Open source licensed patches to the XFree86 mga driver are more
than welcome.  If you or anyone else is aware of a fix for this
problem, I'd be happy to review it for potential inclusion in a
future release.  We do not however ship binary only drivers, so
Matrox's provided driver is unacceptable and unuseable to us.

Please attach your XFree86 server log, config file and
/var/log/messages also as individual uncompressed file attachments
using the file attach feature below.
Comment 3 Thoralf Will 2004-02-11 17:37:02 EST
I used the Matrox-drivers. They are also available as source but with
an gpl-incompatible license, reditribution explicitely forbidden. :(
(http://www.matrox.com/mga/support/drivers/files/lnx_30.cfm)

I will add the logs tomorrow. There are still some minor problems with
the DVI-connector but in general it's at least working at all.
Comment 4 Mike A. Harris 2004-02-11 18:17:16 EST
Which makes that source code 100% useless to Red Hat and the rest
of the open source community.  Also, the specifications for the
G450 and G550 were never made public, not even under NDA.

If the Matrox G550 no longer works properly in open source drivers,
and there is no longer any upstream maintainer maintaining the open
source driver, then it is effectively "unsupported".  If that is
the case, and no simple solution presents itself, I will probably
end up redirecting this hardware to the "vesa" driver and disabling
support in the mga driver for non-functioning hardware.  If none
of the hardware works anymore, it might be best to just remove
the driver.

Bottom line really is that we ship drivers that XFree86 supports
by default, and many of them are supplied by us to users as-is.  Our
ability to directly support the drivers is limited, and so the more
broken drivers become, the more unuseable they are to us in our
products.  A point gets reached where we will consider the hardware
unsupported if it has no active upstream maintainer(s).

We simply don't have the manpower nor the technical documentation
to 100% support all video hardware.  The vendors have to have
some responsibility in this area if they want to have their hardware
work out of the box in our OS.

That said, I'll await your logs, and I will do an investigation
for this issue in the future.  Perhaps we will get lucky and
there is a fix available somewhere that is legally open source.
Comment 5 Thoralf Will 2004-03-09 06:55:54 EST
Sorry for the delay. As it seems XFree is overwriting the logs with
each start. Since I've given up trying to get the G550 working (I need
to work, not to much time to play around with it) and use nvidia's
FX5200 now I don't have the logs anymore.

I'll suggest to mark the driver as deprecated or unsupported.
Comment 6 Mike A. Harris 2004-03-09 14:25:30 EST
When the X server starts, it rotates the previous log to be named
XFree86.$DISPLAY.log.old, so that you can access the previous log
once you start the X server up.  Alternately the X server log can
be obtained by booting into runlevel 3 after bootup after a crash.

I'll mark this issue 'WONTFIX' for now, as we do not have the
hardware to reproduce, and there is insufficient information in the
report to be able to try and deduce the problem from logs and
configs.

If the problem returns in the future, and anyone is able to
provide a log file and config file, feel free to reopen the report
for tracking.  Also recommended is to file a bug report upstream
to XFree86.org.

Thanks for the update.


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