Bug 182217 - Fedora install does not detect Nvidia 7600GT card to use nv driver
Fedora install does not detect Nvidia 7600GT card to use nv driver
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: system-config-display (Show other bugs)
5
All Linux
medium Severity high
: ---
: ---
Assigned To: Søren Sandmann Pedersen
:
Depends On:
Blocks: FC5Blocker
  Show dependency treegraph
 
Reported: 2006-02-20 22:04 EST by Adam Gibson
Modified: 2014-06-18 05:08 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-22 15:38:19 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 Adam Gibson 2006-02-20 22:04:31 EST
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
Comment 1 Adam Gibson 2006-02-20 22:48:44 EST
Forgot processor specs:
AMD 4000+

and installing using FC5t3 x86_64 DVD
Comment 2 Mike A. Harris 2006-02-21 22:15:48 EST
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.
Comment 3 Adam Gibson 2006-02-21 23:12:29 EST
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.
Comment 4 Adam Gibson 2006-02-21 23:37:35 EST
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.

Comment 5 Mike A. Harris 2006-02-21 23:58:24 EST
(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.

Comment 6 Chris Lumens 2006-02-22 10:07:37 EST
>> 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.
Comment 7 Jeremy Katz 2006-02-22 15:38:19 EST
Chris went ahead and made the change here
Comment 8 Adam Gibson 2006-02-24 14:09:39 EST
For the record this was a 7800GT not a 7600GT.
Comment 9 Mike A. Harris 2006-02-24 14:38:45 EST
device ID 0092 is the important part

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