|
nVidia Summary
Commands
Hotkey switching between laptop and projector This may mean that the Fn+F3 key can work: Besides TwinView, mobile NVIDIA chips also have the capacity to react to an LCD/CRT hotkey event, toggling between each of the connected display devices and each possible combination of the connected display devices (from nVidia's readme). This functionality is not compatible with TwinView -- if you enable TwinView in your X config file, then the NVIDIA X driver will ignore LCD/CRT hotkey events. Now, that would be a bonus. See the nVidia's readme for details. A possible complication: The video overlay only works on the first display device on which you started X. For example, if you start X on the internal LCD, run a video application that uses the video overlay (uses the "Video Overlay" adaptor advertised through the XV extension), and then hotkey switch to add a second display device, the video will not appear on the second display device. To work around this, you can either configure the video application to use the "Video Blitter" adaptor advertised through the XV extension (this is always available), or hotkey switch to the display device on which you want to use the video overlay before starting X.Also try defining two independent screens (xinerama style) -- see app-r of nVidia's readme. Which AGP? On kernel 2.6.12, xorg 6.8.2.dfsg.1-5, and nvidia-kernel-source 1.0.7174-4, I added Option "NvAgp" "1"to /etc/X11/xorg.conf (xorg.conf.nvidia), and got this in /var/log/Xorg.0.log, When I run glxgears I get 1289.800 FPS -- as good as using the Linux ali-agp module, which won't unload and likely won't suspend. The values mean the following: Option "NvAgp" "0" ... disables AGP supportI've generally been loading ali-agp on boot, in which case it is used instead of nVidia's nvAgp. I used to get this in /var/log/XFree86.0.log: (**) NVIDIA(0): Use of AGPGART requestedWhen I ran glxgears I get excellent results: 63 frames in 5.0 seconds = 12.600 FPSUsing nvAgp used to result in glxgears values around 1,175 FPS -- ten times less (not thoroughly tested). It may be that on my ALi1541 chipset, NVIDIA drivers used to disable AGP, but that they no longer do, or that I simply didn't test correctly. Anyway, the internal AGP is working fine now. In fact, the nvidia kernel now suspends! I get "FATAL: Module nvidia is in use", but suspend and resume work without problems.
Specs
Installation history 10 April 2004 Discovered that I can use the Debian packages for the nVidia
drivers now, starting with 5328: just install nvidia-kernel-source nvidia-kernel-commonThis installs /usr/src/nvidia-kernel-source.tar.gz which untars to /usr/src/modules. When compiling the kernel, issue make-kpkg clean kernel_image modules_imageto include the modules in /usr/src/modules -- that simple! Or compile the modules on their own against the current kernel tree. This will generate a deb for each module; install it. Finally, just install nvidia-glxThis last step connects the glx driver to the kernel driver just installed. The instructions recommend, Create a "video" group, and add to it any users who you want to be able toI didn't do this but the procedure may be useful to know. If you get complaints from some software (old games?) about missing libGL.so, issue just install nvidia-glx-devYou get a bit of a delay by using the Debian packages, but at this point that may not matter. AGP A. Using the AGP in the kernel Select these in the kernel: CONFIG_AGP=mComment out this in the X11 configuration file: # Option "NvAGP" "4"You will now use the kernel AGP. The X11 log file will say, (II) NVIDIA(0): AGP 4X successfully initializedI get 1034 FPS on glxgears. B. Using nVidia's AGP Leave the two options above from the kernel, or don't insert the modules (you'll have to leave them out of /etc/modules.conf). Unomment this in the X11 configuration file: # Option "NvAGP" "4"The X11 log file will say, (**) NVIDIA(0): Option "NvAGP" "4"I get 1034 FPS on glxgears -- same value. However, 3D games like tuxracer appear half in the upper screen and half in the lower. Finding: the kernel's AGP is better. 29 December 2003 Since I ran into a problem with thread-local storage (TLS) on
Sigillo, I upgraded to 5328, which so far runs perfectly. The upgrade was simplicity itself: download and run the patch. It took 30 seconds
(you need to exit x-windows). The TLS problem was triggered by mplayer-mozilla in
conjunction with mozilla; the patched nVidia driver uses TLS and the
three did not play well together. I uninstalled mplayer-mozilla. 26 December 2003 There are now two new drivers, and you can get pre-patched run
versions here.
Early reports on the 5328 are mixed. Since I'm having zero problems
with the current driver, 4363, there's no reason to upgrade. I might do
it
when I upgrade the kernel (still running 2.6.0-test9). See also this new Debian/nVidia/2.6
recipe. 28 October 2003 The main page says, "Debian GNU/Linux's make-kpkg translates a
custom suffix appended to the kernel version via --append-to-version
into an extended EXTRAVERSION passed on the command line. The same
EXTRAVERSION needs to be set when the NVIDIA kernel module is built." I
used kernel-image-2.6.0-test9_sigillo.1_i386.deb this time -- how do I
pass _sigillo.1 on? No idea. Maybe make --append-to-version sigillo.1 installSkirting this issue, I proceeded to build a modified installer: /vc/software/binary/nVidia/NVIDIA-4496# sh NVIDIA-Linux-x86-1.0-4496-pkg0/usr/bin/makeself.sh --target-os Linux --target-arch x86 NVIDIA-Linux-x86-1.0-4496-pkg0 NVIDIA-Linux-x86-1.0-4496-pkg0.run "NVIDIA Accelerated Graphics Driver for Linux-x86 1.0-4496" ./nvidia-installer That worked. I then ran the installer with this command: sh NVIDIA-Linux-x86-1.0-4496-pkg0.run --kernel-name=2.6.0-test9This built flawlessly and is the way to go. I was now able to boot into 2.6.0-test9 and get X11. However, the 4496 driver didn't return me to a console after exiting, so I reverted to 4363, which is working fine (still as of end December 2003): root@sigillo:~# cat /proc/driver/nvidia/agp/status 24 October 2003 To check what version of gcc was used to compile your kernel,
you can examine the output of: cat /proc/version To check what version of gcc is currently in your $PATH, you
can examine the output of: gcc -v [From the nVidia README.txt for 1.0-4496.] Please note that NVIDIA's internal AGP support cannot work if
AGPGART is either statically compiled into your kernel or is built as a
module, but loaded into your kernel. [From the nVidia README.txt for 1.0-4496.] Use startx -- -logverbose 5 for better log files. 8 July 2003 Going to /vc/software/binary/nVidia, I ran
NVIDIA-Linux-x86-1.0-4349.run to install a new driver on Spello.
However, the script exited on finding that the current gcc was
different from the compiler used to build the kernel. I tried export
CC=/usr/bin/gcc-3.2 and export CC=/usr/bin/gcc-2.95, and even export
CC=gcc-3.2 and export CC=gcc-2.95, but got nowhere. Problem: I don't
know how to find out the compiler used for my current kernel. I asked
on the nVidia
site
if anyone knew. Later I realized this is clearly spelled out in dmesg
-- at any rate, I rebuilt the kernel with 2.4.21-ac2 and then installed
the new nVidia driver on Spello; it's working fine. For nVidia patches
to the 2.5 kernels, see http://linuxespana.scripterz.org
and http://www.minion.de
(I used the latter). For the 2.5.69, I just had to patch the Makefile.
I got the original makefile from nVidia's
ftp site
-- specifically, you need NVIDIA_kernel-1.0-4363.tar.gz for the 4363
driver patch and NVIDIA_GLX-1.0-4363.tar.gz for glx. Untar the kernel
driver; you'll see the Makefile in the resulting directory. To patch,
issue: root@sigillo:/vc/software/binary/nVidia# patch -p0 < NVIDIA_kernel-1.0-4363-2.5.diff "After patching the NVIDIA driver, you will need to choose one
of the two provided Makefiles by creating a symbolic link from the
Makefile of your choice, Makefile.kbuild or Makefile.nvidia, to
Makefile." cp /vc/software/binary/nVidia/NVIDIA_kernel-1.0-4363/nvidia.o /lib/modules/2.5.69/kernel/drivers/video Then untar the glx driver, enter the directory and issue make -- the installation should be automatic and worked fine when I did it. Issue depmod-a -- and make sure you remove any current
nvidia.o before you try to insmod the new one. Tested: it works! So I have both screens working in 2.5.69.
Wow. It took me a few days to realize that ctrl-alt-+/- was no longer working in TwinView under the 1.0-4349 driver; this was fixed in the 1.0-4363 release. I used the nvidia-installer to get this at first, and GLX wouldn't load. Then I downloaded the NVIDIA-Linux-x86-1.0-4363.run package (see /vc/software/binary/nVidia) and ran that, and everything's been working. This was all for the 2.4 kernel of course. 17 May 2003: To update the nVidia driver, issue
After the update, issue "insmod nvidia" -- otherwise X-windows
will "fail to initialize the nvidia driver." XFree86 4.3.0 works great, as long as you avoid xlibs, xlibs-dev,
and xbase-clients (these screw up international keyboards). I was
initially unable to switch between display modes in 4.3 -- this was a
problem with the nVidia driver that was fixed with the 4363
update. The 1.0-4349 may still be a bit buggy, according to reports at The installer worked great, and you can use it to install an
update -- instructions at 22 Feb 2003 Switched to the Dell monitor for the external display for Sigillo.
This gave me splash and the icons in the large screen above The menu bar at the bottom in the small screen (where it should be) The passage between the two screens was correct (0 on top of 1) Raising screen1 has the effect of placing the icons above The rest looks great and the passage is correct
Splash top
Two splash screens
Two splash screens
Menu bar on top screen No -- precisely not. Logically, raising screen0 situates screen1 above it
Weird -- and not useful
Same effect as Problem: icons on top, otherwise fine
Same effect as What you want to do is to raise screen0 -- which means what?
The menu bar got squeezed down below the bottom of 1 to appear in 0
Weird gray area -- not coherent
AGP In the nVidia driver guide it said that nVidia can't use its own agp software if XFree86's is already loaded -- and it looks like it is:
So this may need to be removed from the kernel -- I wonder if I always had it in? You also need to check if agp is deactivated for this chipset -- that's to say the Ali M1671. The 128M is the video memory I take it. The nVidia guide says that nVidia disables agp for Ali 1541 and 1647, but does not mention 1671. However, on page 46 (51) it says that "the nVidia internal AGP support cannot work if AGPART is either statistically compiled into your kernel or is built as a module and loaded into your kernel" -- and this is clearly happening. So remove it from the kernel? In /etc/modutils/aliases I commented out "alias char-major-10-175 agpgart" and issued update-modules -- let's reboot and see if we get a difference -- well it didn't because it's in the kernel and Linux finds it anyway on booting. So I removed it from the kernel and indeed it is now gone -- but I see no difference in the nVidia / XFree bootlog -- in both cases it says AGP 4X was successfully initialized. So maybe it didn't matter. On the other hand, I don't believe I needed the kernel-land agp, so it's good to leave it out. The kernel did get a bit smaller. XV Current X11 problem: no video overlay I killed X11 from the console bit by bit, which is perhaps a
bad idea -- and ever since I've had problems. The video overlay problem
is consistent for steen and root and kde and icewm. So that's my best guess -- some of these files got corrupted when I killed X in that messy manner. It's less likely it's the nVidia driver, since I've already installed it and it appears from the log file to run great. It's bad of course that there are no error messages -- no realization that something is profoundly awry. However, when I came to work it all disappeared on its own; the system is working fine. Does it now demand having a second monitor? I'll boot with a single one. This got me the problem back again, and I discovered nVidia provides XV in two ways -- through the NV17 Video Overlay and the NV05 Video Blitter. The blitter works, the overlay doesn't -- specifically, it doesn't since I set up twinview, even when the x-configuration file no longer mentions twinview.
This made no difference. There is a collective psychosis in America that is called "the American dream". Of course dreams are unreal, but in this case the dream has become sacred. So you need a clear understanding of the sacred, so that it can be coherently contrasted with a psychosis. nVidia has two XVideo drivers, the NV17 Video Overlay and the NV05 Video Blitter (type xvinfo under X11 on Sigillo for details). After installing TwinView, which relies on the Blitter driver, the Video Overlay driver ceased to work. That means that when I run Sigillo without an external attached monitor, I no longer have XVideo. The weird thing is that there are no error messages -- the system doesn't realize that something has gone wrong. Try startx -- -verbose 5 -logverbose 5 To the nVidia board (user and pw moksha): Overlay and blitter I've been running the 1.0-4191 driver on a Debian sid laptop for a few weeks with excellent results, on the 2.4.20 kernel and XFree86 4.2.1.1. I would run with just the built-in monitor or with an external one dynamically detected, in clone mode, without defining anything in XF86Config-4 other than a modeline for each of the two monitors. Then I discovered TwinView and set up spanning mode, which is also working great (though I have a minor question, see below). Then an odd thing happened: I lost Xvideo in single mode. That is, I can still play and edit movies with xv when I'm using two monitors, but it fails when I'm just using the laptop built-in screen. The failure doesn't appear in the /var/log/XFree86 logs and there are no error messages. I just don't have xv. There's a black screen that reveals a blue background when moved in the place where the video footage should be. x11 still works. When I run xvinfo with an external monitor attached, whether in the default clone mode or in twinview, I get this:
- and so on, all nice and tidy, and everything is working -- xine will tell me I'm using the Blitter. Then I power down the laptop, unplug the external monitor, and restart. I use an XF86Config-4 file that used to give me great XV in single-view as well as clone mode. When I run xvinfo I get this:
and then further down:
-- looks good, but NV17 Video Overlay is not in fact working, and NV05 Video Blitter is not being accessed. Is this a known bug, and is there a workaround? I've reinstalled XFree86 and the driver itself to no effect. This is a vpr matrix 200a5 with a GeForce4 420 Go M32 chipset and ALi Corporation M1671 Super P4 Northbridge [AGP4X,PCI and SDR/DDR]. In the XFree86 log I get
When I run glxinfo, I get "direct rendering: Yes." Now bear in mind that the weird thing is that I'm running x-windows with exactly the same configuration file and driver as before, but the Video Overlay no longer works. Could this be a hardware problem? Here are my questions: 1. How can I get Video Overlay / xv to work again? Finally, I have a question about twinview. I have the external monitor located above my laptop screen. If I say "Above", the main part of the window with all the icons ends up in the external monitor. If I say "Below", the icons stay below, but the external monitor is mapped below the laptop. If I say "LeftOf", the screens look right, but the external monitor is mapped to the right of the laptop. How can I map the external monitor above the laptop, but keep the icons on the laptop screen? Appreciate your help with this. Cheers, After spending days troubleshooting this, I discovered that the problem went away if I deleted the .xmms configuration file. At some point I must have set a value that triggered this failure. Lesson: it's very hard to track the relevant variable, so be careful before you make claims. This likely had nothing to do with TwinView -- although it's still a nVidia driver bug. The way it works is this: you change a setting in .xine which destroys xv; xv is then destroyed for all programs and users until you reboot. I figured this out by using the spare partition to install a
different version of Linux that I could mess around with freely. Two monitors It turns out that adding this line to /etc/X11/XF86Config-4 makes it work great for both the onboard display and the external display:
The effect is interesting: the external display has a real resolution of 1024x768, but a virtual size of 1280x854. This means that the onboard display is full size, and the external display spills over the screen. That effect is actually fine -- and I don't get my desktop messed up. It actually looks like you get the full refresh rate on the onboard monitor -- 85MHz -- at the same time as you get 60MHz on the external monitor. So this shows that the nVidia is indeed capable of driving two monitors at two different resolutions and sizes at the same time! Double wow: it turns out that adding this line solves the problem with the display on exiting X-windows -- which has annoyed me from the beginning!! Basically, when X exits, the terminal mode doesn't get a correct definition. It spills over the screen, trying to effect a 1280 height, but apparently not fully succeeding, and in the process messing up the fonts. When I now exit from X, I see it switching to a new mode -- namely the 1024x768 -- which is what I need in terminal mode, or console mode, or the terminal console. I hadn't noticed that this happens when I exit the .class configuration, though it likely did. Anyway, now it's doing a beautiful job and I have a perfect console.
Initial installation Initially I just went with a smaller screen definition, as the X
configuration utility didn't provide the option of a 1280x854 I
needed. Later, I sorted this out as follows. The size of the monitor is the same as the Titanium G4. I booted to XP and saw the refresh rate was 60Hz -- it turned out I didn't need to know. At http://www.geocrawler.com I found an example of a TiBook configuration and copied these parts over to /etc/X11/XF86Config-4, modifying only the device name and the Identifier as "Default Screen":
I rebooted -- and it worked! I must admit I was pretty amazed -- essentially, the Mac screen is identical. The graphics card is nVidia GeForce 420 Go. Note that the XF86 driver gives you GLX [not] and XVideo -- there is no neeed to install the binary nVidia driver -- in fact, I tested it and it wouldn't do better than 800x600. The default is crisp and fast.
|