Description of problem: When trying to install Fedora Core 5 Test 3 the installer uses the VESA driver instead of the nvidia driver for the E-VGA 7600GT PCI-Express card with device id 0092. During install Fedora showed that an nvidia unknown device 0092. What complicates this is that the VESA driver in FC5t3 does not work(corrupt screen) so installation does not work even with the VESA driver. The VESA and the nv driver worked with this video card on FC4. Version-Release number of selected component (if applicable): Whatever the installer uses for Fedora Core 5 Test 3 How reproducible: Install using an E-VGA 7600GT PCI-Express card Steps to Reproduce: 1. Install E-VGA 7600GT PCI-Express Video card 2. Try to install fedora 3. Actual results: Use the and configure the nv driver for the 7600GT during installation. I am sure that the nv driver works on the card because I manually setup X on the previous FC4 to use the nv driver and it worked just fine. Expected results: Additional info: Information from /etc/sysconfig/hwconf... class: VIDEO bus: PCI detached: 0 driver: nvidia desc: "nVidia Corporation: Unknown device 0092" vendorId: 10de deviceId: 0092 subVendorId: 0000 subDeviceId: 0000 pciType: 1 pcidom: 0 pcibus: 5 pcidev: 0 pcifn: 0
Forgot processor specs: AMD 4000+ and installing using FC5t3 x86_64 DVD
This card is already listed in nv.xinf in FC5test3, so on a fresh OS install, or when running "system-config-display --reconfig", the "nv" driver will automatically get used for this hardware: alias pcivideo:v000010DEd00000092sv*sd*bc*sc*i* nv If this does not happen, it is a bug in kudzu or something else.
I think the nv driver is what is actually causing the corrupted display. After an upgrade from FC4 to FC5t3 using the vnc method, The vesa driver is what was configured. The vesa driver worked. I manually changed it to use the nv driver and it showed the screen corruption like during the anaconda install. Interstingly I tried running system-config-display --reconfig and it gave a traceback. I then did a verify on the system-config-display rpm and it was missing some files mysteriously. I removed the RPM and installed it from scratch but I still get the traceback. I want to see if the nv driver is configured automatically by running that but I can't seem to find what RPM is supposed to provide the rhpxl.monitor python module. I image that when I do figure out how to get past the traceback and it configures the nv driver, the screen might be garbled like when I manually configure X to use the nv driver. Would the traceback on system-config-display explain why the vesa driver was configured after the upgrade(maybe a fallback driver)? [root@localhost static]# system-config-display --reconfig Traceback (most recent call last): File "/usr/share/system-config-display/xconf.py", line 32, in ? import rhpxl.monitor ImportError: No module named rhpxl.monitor [root@localhost static]# rpm --verify system-config-display-1.0.36-1 missing /usr/share/system-config-display/dpiDialog.pyc missing /usr/share/system-config-display/monitorDialog.pyc missing /usr/share/system-config-display/screenSizePreview.pyc missing /usr/share/system-config-display/videocardDialog.pyc missing /usr/share/system-config-display/xConfigDialog.pyc missing /usr/share/system-config-display/xconf.pyc *** I fixed the missing problem by reinstalling system-config-display.
I found the rhpxl rpm package(duh). After installing that the display was configured for the nv driver and it worked! So it looks like FC5 should force the rhpxl package when upgrading. The monitor frequencies were way off though because my SyncMaster 770TFT was not listed(even though it was for FC4 or FC3 I think. I set them to what my monitor manual specified and now I can even use higher resolutions. I have a feeling this whole thing is because of monitor refresh rates being way off or something with the anaconda installer. FYI, the nvidia installer auto-detected the correct refresh rates using DCC when I installed it on FC4. It would be nice if the system-config-display had an option to autodetect the monitor refresh using DCC.
(In reply to comment #4) > I found the rhpxl rpm package(duh). After installing that the display was > configured for the nv driver and it worked! So it looks like FC5 should force > the rhpxl package when upgrading. The package used to be rhpl, and changed to rhpxl at some point. Perhaps the packages that depended on rhpl for that didn't get updated to depend on rhpxl. Either way, 'tis a kudzu and/or system-config-display and/or pyxf86config and/or something else bug it would seem. I've CC'd some other developers who maintain or have contributed to the various X config tool bits. This is something that should probably be fixed for FC5 as a Blocker likely. > The monitor frequencies were way off though because my SyncMaster 770TFT was not > listed(even though it was for FC4 or FC3 I think. I set them to what my monitor > manual specified and now I can even use higher resolutions. I have a feeling > this whole thing is because of monitor refresh rates being way off or something > with the anaconda installer. That's not related to the bug initially reported here however. If you are experiencing any other issues, please file individual bug reports for each issue against the correct component. If you're not sure, make a best guess to which component might be at fault and we can reassign if necessary. > FYI, the nvidia installer auto-detected the correct refresh rates using DCC > when I installed it on FC4. Unfortunately that's not too useful info however, as Nvidia's proprietary source code is not available. > It would be nice if the system-config-display had an option to autodetect > the monitor refresh using DCC. ddcprobe is used for monitor autodetection during install or X configuration. If a display is not probeable with ddcprobe for any reason, then the config tool/installer will be unable to detect the display at all and it will have to be manually specified. At runtime however, the X server and drivers use native DDC probing if the monitor details are not specified in the config file already. DDC support varies from driver to driver, and chip to chip, as well as other factors. As long as DDC is being used in any form, the display will return it's Horizontal and Vertical frequency ranges to the tool doing the probing (be it ddcprobe or the X server/driver, etc.) and assuming nothing blocks or interferes with the signal (such as a KVM, a buggy driver, a buggy monitor, etc.), the mode list is then pruned to remove modes that are outside of display's advertised ranges. Then, generally speaking, for the configured resolution, the best mode with the highest refresh rate is used which is compatible with the display's H/V frequency range. If that isn't happening, then either DDC is not being used, or there is a bug in the tool (ddcprobe for example) or the driver (ie: nv). If it can be narrowed down to being the video driver, then a bug should be filed in X.Org bugzilla so that Nvidia fixes it in a future "nv" driver update. Hope this helps.
>> I found the rhpxl rpm package(duh). After installing that the display was >> configured for the nv driver and it worked! So it looks like FC5 should force >> the rhpxl package when upgrading. > >The package used to be rhpl, and changed to rhpxl at some point. Perhaps >the packages that depended on rhpl for that didn't get updated to depend on >rhpxl. Either way, 'tis a kudzu and/or system-config-display and/or >pyxf86config and/or something else bug it would seem. It didn't so much change as broke apart into two smaller packages, since rhpl has become a bit of a dumping ground for random python blobs. Regardless, this part is definately a system-config-display bug in that its requires have not been changed.
Chris went ahead and made the change here
For the record this was a 7800GT not a 7600GT.
device ID 0092 is the important part