Red Hat Bugzilla – Bug 115346
config returns invalid configuration
Last modified: 2007-11-30 17:10:36 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:
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).
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.
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.
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.
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.
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.