From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: I have a nvidia graphics card with the nvidia drivers installed. Every time a new kernel comes out (from Redhat), I install it, then reboot single user and rebuild the nvidia driver. I can then "init 5" and the system goes into it's normal graphical mode. On the next boot, the system will do it's graphical boot using the nvidia driver. However, it will revert the configurtion to a vesa driver before bringing up the login screen. The solution is simple, login as root, mv xorg.conf.backup xorg.conf, and restart X. There is nothing wrong with the driver or the configuration. What's frustrating is that there is no message that the system reverted the graphics configuration or why. One would assume that this is a failsafe for a bad configuration, but there should be some indication that corrective action was taken. I don't even know if this is really an xorg bug. I could not find what module was changing the configuration file (kudzu?). Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Install nvidia drivers 2.Install new kernel, reboot to single user (or 3) and rebuild nvidia drivers 3.Reboot Actual Results: On step 3, the system starts booting using the nvidia drivers, but reverts to a vesa driver before bring up the login screen. Expected Results: The system should have continued using the nvidia drivers. Additional info: This has been happening in FC4 ever since I installed it (many months ago).
The xorg-x11 packaging does not control what driver gets assigned for a given card, nor what happens on a kernel update. I'm not exactly sure what causes this change to happen, but I believe it is intentional. I'm reassigning the bug to the kudzu component as it is generally responsible for hardware detection, however it might be gdm failsafing, or some other issue. It is definitely not the X server doing this however.
This is definitly kudzu. I've reproduced it by simply running kudzu from the command line. Every time it is run it changes the xorg.conf file and ignores it when I change it back. There should be a way to tell kudzu not to overwrite a configured file, eh?
kudzu reads the PCI ID from the video hardware, then looks it up in the pcitable database. If it doesn't find an entry for the card, it assumes it is not supported, and the vesa driver is the driver that is used for unsupported hardware in _all_ cases. I don't know the kudzu code much, but I believe that it compares the autodetected driver (in this case vesa) with the driver that the X server is configured to use. If it finds a difference, it assumes you have a new video card plugged in, and offers to change it to use the new driver. kudzu has no knowledge of Nvidia's driver, and the hardware database does not ever map to the nvidia proprietary driver (and never will). When the kernel is updated, if you don't rebuild nvidia's kernel driver portion, you end up with nonworking video. As such, to prevent that problem, having the video driver changed to the one the OS defaults to is done, to give the highest chance of having working video out of the box, and after kernel updates. The only solution to this, is to either disable kudzu because it is doing this intentionally, or to stop it from detecting video hardware, and thus leaving your driver assignment alone. If we were to stop it from doing this, then we would end up getting hundreds of bug reports from nvidia proprietary driver users, who upgrade their kernel and end up with X no longer starting. There is good news however. Starting with Fedora Core 5, each driver package contains it's own driver mapping files now, and there is no longer a central database. As such, all you have to do to avoid this problem, is to use the livna.org Nvidia rpm packages with Fedora Core 5, and ensure that the livna people have updated their nvidia packages to have an nvidia.xinf file. That should inform kudzu to use the "nvidia" driver for that hardware, instead of the vesa driver. However, that solution is only for FC5. For FC4, there isn't a solution other than described above.
Reopening... the issue here is that it *shouldn't* be triggering if no hardware has actually changed.
Ah, I wasn't sure how it detected wether or not the hardware changed. I assumed it just compared the currently used driver to the one it currently detected.
Right. The hardware didn't change, the right driver was already installed (either manually or via a add-on yum repository), and yet kudzu is (silently) changing the configuration. The kicker is that the system has gotten half way through the graphical boot working just fine, and then falls back to low res at the last minute. It just looks unprofessional for it to get it right and then second guess itself. Is it possible to notice that X is already running correctly (assuming graphical boot)? If you are running a non-traditional display (say HDTV over component), then falling back to VESA may mean you have no display at all. Vesa isn't guarenteed to be a safe configuration. Besides, 640x480 display mode is often un-usable. There is already a fall back method (to text mode) if X won't start. This is never any worse than reverting to VESA (for novel display configurations). If nothing else, I REALLY wish there was a log messages somewhere telling me why the configuration changed. Having it "automagically" undo my configuration is so... Windows :-)
what I would like to see is for there to be a way to run kudzu while limiting the scope of its config changes. sort of an "don't touch X" option in /etc/sysconfig/kudzu or the like. and yes, I wholeheartedly agree kudzu needs to log when it does make changes to config files instead of just silently messing up your working system. btw, this problem seems to get fixed if you run system-config-display after installing the nvidia drivers (even if you don't actually change any of the config options). as for the problems endemic to nvidia with kernel upgrades, that seems to me to be a result of kernel-module rpm dependencies issues. I know Axel Thimm is working with the people from Smart to figure out how to make it so that when you upgrade kernels you also get all of the modules with it. breaking kudzu's hardware-change detection to overcome a problem with rpms (or clueless users) seems like adding a new problem, not solving the first. -alan
An added note on all this. I recently upgraded the kernel and forgot to boot single user to install the nvidia drivers. kudzu failed to update the configuration. I got the "X server failed to start" text dialog. So, not only is it changing the configuration when it shouldn't, it fails to change it when it should. Comment #3 was saying the the change was to prevent this kind of problem, but it isn't actually working. FYI
I believe this is fixed in rawhide kudzu-1.2.45-1 or later.