I've recently got myself an HP Presario r3004 notebook, with an AMD64 processor and an nVidia Geforce4 440 Go 64M video card. I'd missed the fact, now apparently well-known, that the VESA VBE didn't have a mode for 1280x800 (the 16:10 LCD resolution), and that the nv driver would corrupt the video modes such that you coulnd't switch back to text mode: the text mode would be garbled, and there was no known way to recover from that, other than a reboot. Switching back to the nv-started graphics mode still worked. After some investigation, I found out that, having an external monitor connected to the system, even if turned off, the problem would not occur: text mode would work just fine. After that, even if you disconnected the monitor, everything would keep working, until the next reboot. I also found out that Fn-F4, the hotkey (only visible to the BIOS) used to switch between internal, external, both or none displays when using VESA video modes, had no effect when the external monitor was not connected. Actually, *almost* no effect, as you'll see below. The information that follows applies to the case of not having an external monitor connected, and not ever having had one since the last reboot. As it turns out, if you press this hotkey after a reboot *before* the nv driver ever starts, the corruption problem does not occur any more, until you reboot. If you start the nv driver without having pressed this key, stop X, then blindly start X with the vesa driver, the graphics mode will be garbled as well, but pressing Fn-F4 while in this garbled graphics mode, and then switching to text mode (either by terminating X or by pressing Ctrl-Alt-F1), the problem is fixed as well. The problem is not fixed, however, by pressing Fn-F4 while in a graphics mode started by the nv driver, nor is it fixed by pressing Fn-F4 in text mode after the nv driver started. It has to be either before nv ever starts, or in a vesa graphics mode. From then on, one can use the nv driver as many times as wanted, without video mode corruption. I've talked to Mike Harris, and he says this might be a bug in the BIOS, that fails to initialize the video card completely, but also in the nv driver, that doesn't completely initialize it either. Fn-F4 would actually take the final initialization step (probing for an external monitor?). I don't quite see why, then, Fn-F4 wouldn't fix the problem from a corrupted text mode, but would from a corrupted graphics mode. Not that I know a lot about video modes and video cards, mind you :-) I hope this information helps figuring out what could possibly be wrong.
Mike had suggested me to post differences between Xorg.0.log before and after fixing the problem. The only line that changes is the one that contains the log file name and the timestamp. The log file after the problem is fixed contains an additional line, however, that says: @@ -488,6 +488,7 @@ (II) NV(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) NV(0): I2C device "DDC:ddc2" removed. (II) NV(0): ... none found +(--) NV(0): CRTC 1 is currently programmed for DFP (**) NV(0): Forcing display type to DFP as specified (**) NV(0): Forcing CRTCNumber 1 as specified (II) NV(0): Using DFP on CRTC 1 Yes, my config file specifically chooses display #1 and says it's a DFP. The complete config file is available from the web page in the URL: field.
I too observe this problem with my HP Pavilion zv5000z (HP produces similar machines with several different names and model numbers). If I do a "modprobe rivafb" before starting X, the problem is eliminated. In fact, the modprobe can recover from the problem after it has happened. I just did: 1) startx; text consoles are now scrambled 2) shut down X 3) modprobe rivafb; text console becomes unscrambled 4) startx 5) shut down x The differences between the two /var/log/Xorg.0.log files: -(II) PCI: stages = 0x03, oldVal1 = 0x80010004, mode1Res1 = 0x80000000 +(II) PCI: stages = 0x03, oldVal1 = 0x800000fc, mode1Res1 = 0x80000000 +(WW) Open APM failed (/dev/apm_bios) (No such file or directory) +(II) Mouse0: ps2EnableDataReporting: succeeded
This seems to have been fixed in Fedora Core 3's update of X to what they call 6.8.2-1. I presume that the fix came from upstream (xorg). Thanks!
Also fixed in xserver-xorg 6.8.2.dfsg.1-0pre1v1 for Debian, which are the packages that are supposed to go into experimental. X Window System Version 6.8.2 (Debian 6.8.2.dfsg.1-0pre1v1 20050623145528 david@squee.verizon.net) Release Date: 9 February 2005
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.