Re: nvidia kernel module and GLX
On Sun, Oct 29, 2000 at 10:31:29PM +, Matthew Sackman wrote: > > I've installed XFree 4v26 and it seemed ok - no error messages etc; > I use an Nvidia TNT2 M64 card, and got the kernel module and the > GLX files from NVidia. > > However, both refused to compile. I figured that I needed > /usr/src/linux to point to /usr/src/kernel-source... but that didn't > solve it either. I've tried downloading the rpms and using alien, > and have scratched my head a lot! Hi Matthew, There must be the corresponding kernel-headers for your running kernel linked under /usr/src/linux. I like to use make-kpkg (deb kernel-package) to create a kernel-image...deb and a kernel-headers...deb. The kernel-headers install to /usr/src/kernel-headers- and /usr/src/linux is a symbolic link to them. This has the advantage that you can mess around with your sources, without messing up your headers. I'm using NVIDIA_GLX-0.9-5.tar.gz and NVIDIA_kernel-0.9-5.tar.gz from the nvidia ftp site. I don't know whether there are newer ones available, but those are working with branden's debs and kernel-2.4.0-test9 > Basically, XFree starts, but does not load any window manager, plus, > when I kill the server, the consoles have darkened, and the entire > colour set seems to have altered - the blues of mutt are now green. > An XFree86 -configure exits with: > > > (... xserver output ...) > > (--) PCI:*(1:0:0) NVidia Riva Ultra 64 rev 21, Mem @ 0xf500/24, > 0xfc00/25 > List of video drivers: > nvidia > mga > glint > nv > > (... xserver output ...) > > Duplicate symbol RivaEnterLeave in /usr/X11R6/lib/modules/drivers/nv_drv.o > Also defined in /usr/X11R6/lib/modules/drivers/nvidia_drv.o > > Fatal server error: > Module load failure Here's the problem. There are 2 drivers for the same card family nv - provided by xfree86 nvidia - provided by nvidia > Now it may be that I've messed things up by trying to install the NVidia > modules, but I've followed the instructions to the letter and simply have no > idea why things have not gone to plan. 1. you have to move away the xfree86 nv_drv.o. 'dpkg-divert --add --rename /usr/X11R6/lib/modules/drivers/nv_drv.o' will survive the next update, too. As the nvidia_drv.o is there, I assume you manage to compile the GLX tarball. 2. there is a conflict between /usr/X11R6/lib/modules/extensions/libglx.a - provided by xfree86 and /usr/X11R6/lib/modules/extensions/libglx.so - provided by nvidia I solved this by adding another diversion 'dpkg-divert --add --rename /usr/X11R6/lib/modules/extensions/libglx.a' but I've been told that referencing the libglx modules with full path in XF86Config-4 will also work. 3. libraries in /usr/lib 'ls libGL*' libGLcore.so -> libGLcore.so.1- nvidia libGLcore.so.1 -> libGLcore.so.1.0.5 - nvidia libGLcore.so.1.0.5- nvidia libGL.so -> libGL.so.1- nvidia libGL.so.1 -> libGL.so.1.0.5 - nvidia libGL.so.1.0.5- nvidia There used to be a libGL.so.1.2 provided by xlibmesa3 (I think) conflicting with libGL.so.1.0.5 'dpkg-divert --add --rename --divert /usr/lib/divert.libGL.so.1.2 \ /usr/lib/libGL.so.1.2' will solve this and survive the next apt-get upgrade. !! It is import that the library moved away does not start with lib !! Otherwise ldconfig will recognize it as a library an alter the links libGL.so and libGL.so.1 to point to it. ==> your system will crash, when starting, e.g.. quake3 4. you need kernle support (NVIDIA_kernel-0.9-5.tar.gz) I enabled the agpart device and dri support during kernel configuration (kernel-source-2.4.0-test9). Use make-kpkg from (kernel-package) to create an image and headers as mentioned above. Then compile and install the NVIDIA_kernel module. (The kernel you are installing for, should by running by this time) 'echo "alias char-major-195 NVdriver" > /etc/modutils/nvidia' 'update-modules' now the NVdriver gets automtically loaded when X is started. Your system should be fine now. Have I anything forgotten? If there are still problems, detailed problem descriptions would be useful. regards florian -- Florian Friesdorf <[EMAIL PROTECTED]> OpenPGP key available on public key servers --> Save the future of Open Source <-- -> Online-Petition against Software Patents <- --> http://petition.eurolinux.org <--- pgp2uJcjPa0nx.pgp Description: PGP signature
Re: nvidia kernel module and GLX
On Sun, Oct 29, 2000 at 10:31:29PM +, Matthew Sackman wrote: > > I've installed XFree 4v26 and it seemed ok - no error messages etc; > I use an Nvidia TNT2 M64 card, and got the kernel module and the > GLX files from NVidia. > > However, both refused to compile. I figured that I needed > /usr/src/linux to point to /usr/src/kernel-source... but that didn't > solve it either. I've tried downloading the rpms and using alien, > and have scratched my head a lot! Hi Matthew, There must be the corresponding kernel-headers for your running kernel linked under /usr/src/linux. I like to use make-kpkg (deb kernel-package) to create a kernel-image...deb and a kernel-headers...deb. The kernel-headers install to /usr/src/kernel-headers- and /usr/src/linux is a symbolic link to them. This has the advantage that you can mess around with your sources, without messing up your headers. I'm using NVIDIA_GLX-0.9-5.tar.gz and NVIDIA_kernel-0.9-5.tar.gz from the nvidia ftp site. I don't know whether there are newer ones available, but those are working with branden's debs and kernel-2.4.0-test9 > Basically, XFree starts, but does not load any window manager, plus, > when I kill the server, the consoles have darkened, and the entire > colour set seems to have altered - the blues of mutt are now green. > An XFree86 -configure exits with: > > > (... xserver output ...) > > (--) PCI:*(1:0:0) NVidia Riva Ultra 64 rev 21, Mem @ 0xf500/24, 0xfc00/25 > List of video drivers: > nvidia > mga > glint > nv > > (... xserver output ...) > > Duplicate symbol RivaEnterLeave in /usr/X11R6/lib/modules/drivers/nv_drv.o > Also defined in /usr/X11R6/lib/modules/drivers/nvidia_drv.o > > Fatal server error: > Module load failure Here's the problem. There are 2 drivers for the same card family nv - provided by xfree86 nvidia - provided by nvidia > Now it may be that I've messed things up by trying to install the NVidia > modules, but I've followed the instructions to the letter and simply have no > idea why things have not gone to plan. 1. you have to move away the xfree86 nv_drv.o. 'dpkg-divert --add --rename /usr/X11R6/lib/modules/drivers/nv_drv.o' will survive the next update, too. As the nvidia_drv.o is there, I assume you manage to compile the GLX tarball. 2. there is a conflict between /usr/X11R6/lib/modules/extensions/libglx.a - provided by xfree86 and /usr/X11R6/lib/modules/extensions/libglx.so - provided by nvidia I solved this by adding another diversion 'dpkg-divert --add --rename /usr/X11R6/lib/modules/extensions/libglx.a' but I've been told that referencing the libglx modules with full path in XF86Config-4 will also work. 3. libraries in /usr/lib 'ls libGL*' libGLcore.so -> libGLcore.so.1- nvidia libGLcore.so.1 -> libGLcore.so.1.0.5 - nvidia libGLcore.so.1.0.5- nvidia libGL.so -> libGL.so.1- nvidia libGL.so.1 -> libGL.so.1.0.5 - nvidia libGL.so.1.0.5- nvidia There used to be a libGL.so.1.2 provided by xlibmesa3 (I think) conflicting with libGL.so.1.0.5 'dpkg-divert --add --rename --divert /usr/lib/divert.libGL.so.1.2 \ /usr/lib/libGL.so.1.2' will solve this and survive the next apt-get upgrade. !! It is import that the library moved away does not start with lib !! Otherwise ldconfig will recognize it as a library an alter the links libGL.so and libGL.so.1 to point to it. ==> your system will crash, when starting, e.g.. quake3 4. you need kernle support (NVIDIA_kernel-0.9-5.tar.gz) I enabled the agpart device and dri support during kernel configuration (kernel-source-2.4.0-test9). Use make-kpkg from (kernel-package) to create an image and headers as mentioned above. Then compile and install the NVIDIA_kernel module. (The kernel you are installing for, should by running by this time) 'echo "alias char-major-195 NVdriver" > /etc/modutils/nvidia' 'update-modules' now the NVdriver gets automtically loaded when X is started. Your system should be fine now. Have I anything forgotten? If there are still problems, detailed problem descriptions would be useful. regards florian -- Florian Friesdorf <[EMAIL PROTECTED]> OpenPGP key available on public key servers --> Save the future of Open Source <-- -> Online-Petition against Software Patents <- --> http://petition.eurolinux.org <--- PGP signature
Re: xlibs 40.1-0phase2v13 break xawtv
On Fri, Oct 06, 2000 at 07:36:10PM +0200, Florian Friesdorf wrote: > On Fri, Oct 06, 2000 at 01:56:02AM -0500, Branden Robinson wrote: > > On Thu, Oct 05, 2000 at 01:03:36AM -0400, Decklin Foster wrote: > > > Robert Vollmert <[EMAIL PROTECTED]> writes: > > > > > > > Error: XtMakeGeometryRequest - parent not composite > > > > > > Actually, this is not just happening with xawtv, but any xaw menu. > > > It appears to be an upstream problem; send your report there. > > > > Are you using phase2v13? If not, please try it, because: > > > > 732. Fixed handling of XtMakeGeometryRequest() to test for parent > > belonging to subclass of composite class only if the widget > > itself is managed. This follows the specs more closely. > > (Keith Packard). > > > > If you already are using v13, then it is possible the client is coded > > wrongly. Or maybe Keith messed up (possible, but unusual). > > I am running > > kernel-2.4.0-test9 > x phase2v13 > xawtv 3.22 > > and I don't experience any problems watching tv. Sorry for the perhaps unqualified posting. I know realized, that xawtv 3.22 on my system is using or at least depending on xaw3dg. This seems not to be influenced by the experimental libxaw packages, as I don't get the reported errors with phase2v13 and phase2v15. regards florian -- Florian Friesdorf <[EMAIL PROTECTED]> OpenPGP key available on public key servers --> Save the future of Open Source <-- -> Online-Petition against Software Patents <- --> http://petition.eurolinux.org <--- pgpQiHKH1Asxo.pgp Description: PGP signature
Re: xlibs 40.1-0phase2v13 break xawtv
On Fri, Oct 06, 2000 at 07:36:10PM +0200, Florian Friesdorf wrote: > On Fri, Oct 06, 2000 at 01:56:02AM -0500, Branden Robinson wrote: > > On Thu, Oct 05, 2000 at 01:03:36AM -0400, Decklin Foster wrote: > > > Robert Vollmert <[EMAIL PROTECTED]> writes: > > > > > > > Error: XtMakeGeometryRequest - parent not composite > > > > > > Actually, this is not just happening with xawtv, but any xaw menu. > > > It appears to be an upstream problem; send your report there. > > > > Are you using phase2v13? If not, please try it, because: > > > > 732. Fixed handling of XtMakeGeometryRequest() to test for parent > > belonging to subclass of composite class only if the widget > > itself is managed. This follows the specs more closely. > > (Keith Packard). > > > > If you already are using v13, then it is possible the client is coded > > wrongly. Or maybe Keith messed up (possible, but unusual). > > I am running > > kernel-2.4.0-test9 > x phase2v13 > xawtv 3.22 > > and I don't experience any problems watching tv. Sorry for the perhaps unqualified posting. I know realized, that xawtv 3.22 on my system is using or at least depending on xaw3dg. This seems not to be influenced by the experimental libxaw packages, as I don't get the reported errors with phase2v13 and phase2v15. regards florian -- Florian Friesdorf <[EMAIL PROTECTED]> OpenPGP key available on public key servers --> Save the future of Open Source <-- -> Online-Petition against Software Patents <- --> http://petition.eurolinux.org <--- PGP signature
Re: how to deal with nvidia driver/libs
Hi Marc, thanks for the fast reply. On Wed, Oct 11, 2000 at 06:52:48PM -0700, Marc Martinez wrote: > On Thu, Oct 12, 2000 at 03:06:17AM +0200, Florian Friesdorf wrote: > > I have a Geforce256 card and I am using the nvidia drivers 0.9-5. > > nvidia provides several libs/modules which conflict with the debian > > package ones. > > > libglx.a.distrib# local diversion > > this diversion can be avoided by specifying the full path to the libglx.so > in the configuration file. that's good to know. > > > /usr/X11R6/lib/modules/drivers > > nv_drv.o.distrib# local diversion > > nvidia_drv.o# from nvidia > > no need for this diversion either since they are different names (you just > use "nvidia" instead of "nv" in the config file). I diverted nv, because of xf86cfg failing to start, because of to conflicting drivers. > for a quick fix if you change the divert-to name to something like: > 'distrib.libGL.so.1.2' or anything that changes the name from having 'lib' > as the first part of the filename the dynamic linker won't load it > automatically and you should be safe from ldconfig changing the symlink on > you. that's also good to know. > > Is there a better approach of integrating the vendor supplied drivers? > > my solution was to put together all the necessary components and generate > .deb packages for them which has 'Provides: libgl1' so that all dependencies > are met and I don't need to go around dpkg-divert'ing everything (which was > how I started when first testing out the drivers). Ok, then I will have a look at the packaging manual. regards ff -- Florian Friesdorf <[EMAIL PROTECTED]> OpenPGP key available on public key servers --> Save the future of Open Source <-- -> Online-Petition against Software Patents <- --> http://petition.eurolinux.org <--- pgpSJevd3ZAGU.pgp Description: PGP signature
how to deal with nvidia driver/libs
I have a Geforce256 card and I am using the nvidia drivers 0.9-5. nvidia provides several libs/modules which conflict with the debian package ones. so far I have solved the following conflicts with dpkg-divert. /usr/X11R6/lib/modules/extensions libGLcore.a.distrib # local diversion libglx.a.distrib# local diversion libglx.so -> libglx.so.1.0.5# from nvidia libglx.so.1.0.5 # from nvidia /usr/X11R6/lib/modules/drivers nv_drv.o.distrib# local diversion nvidia_drv.o# from nvidia /usr/lib libGLcore.so -> libGLcore.so.1 # from nvidia libGLcore.so.1 -> libGLcore.so.1.0.5# from nvidia libGLcore.so.1.0.5 # from nvidia libGL.so -> libGL.so.1 # here comes the problematic one libGL.so.1 -> libGL.so.1.2 libGL.so.1.0.5 # from nvidia libGL.so.1.2# xlibmesa3 xlibmesa3 provides libGL.so.1.2 and something insist on libGL.so.1 pointing to it. I tried to divert the link, so that my link (libGL.so.1 -> libGL.so.1.0.5) is not delete by xlibmesa3. This works fine during package install, but as soon as ldconfig is called, my link is replace by libGL.so.1 -> libGL.so.1.2. How can I stop this? Is there a better approach of integrating the vendor supplied drivers? regards ff -- Florian Friesdorf <[EMAIL PROTECTED]> OpenPGP key available on public key servers --> Save the future of Open Source <-- -> Online-Petition against Software Patents <- --> http://petition.eurolinux.org <--- pgph23LMlBLVg.pgp Description: PGP signature
dexter, mouse port
Hi,
I think I'm going to like dexter,
but at the moment it's missing /dev/gpmdata in the mouse port selection menu.
-ff
--
Florian Friesdorf <[EMAIL PROTECTED]>
OpenPGP key available on public key servers
--> Save the future of Open Source <--
-> Online-Petition against Software Patents <-
--> http://petition.eurolinux.org <---
pgpeJaOtOtP6v.pgp
Description: PGP signature
Re: how to deal with nvidia driver/libs
Hi Marc, thanks for the fast reply. On Wed, Oct 11, 2000 at 06:52:48PM -0700, Marc Martinez wrote: > On Thu, Oct 12, 2000 at 03:06:17AM +0200, Florian Friesdorf wrote: > > I have a Geforce256 card and I am using the nvidia drivers 0.9-5. > > nvidia provides several libs/modules which conflict with the debian > > package ones. > > > libglx.a.distrib# local diversion > > this diversion can be avoided by specifying the full path to the libglx.so > in the configuration file. that's good to know. > > > /usr/X11R6/lib/modules/drivers > > nv_drv.o.distrib# local diversion > > nvidia_drv.o# from nvidia > > no need for this diversion either since they are different names (you just > use "nvidia" instead of "nv" in the config file). I diverted nv, because of xf86cfg failing to start, because of to conflicting drivers. > for a quick fix if you change the divert-to name to something like: > 'distrib.libGL.so.1.2' or anything that changes the name from having 'lib' > as the first part of the filename the dynamic linker won't load it > automatically and you should be safe from ldconfig changing the symlink on > you. that's also good to know. > > Is there a better approach of integrating the vendor supplied drivers? > > my solution was to put together all the necessary components and generate > .deb packages for them which has 'Provides: libgl1' so that all dependencies > are met and I don't need to go around dpkg-divert'ing everything (which was > how I started when first testing out the drivers). Ok, then I will have a look at the packaging manual. regards ff -- Florian Friesdorf <[EMAIL PROTECTED]> OpenPGP key available on public key servers --> Save the future of Open Source <-- -> Online-Petition against Software Patents <- --> http://petition.eurolinux.org <--- PGP signature
how to deal with nvidia driver/libs
I have a Geforce256 card and I am using the nvidia drivers 0.9-5. nvidia provides several libs/modules which conflict with the debian package ones. so far I have solved the following conflicts with dpkg-divert. /usr/X11R6/lib/modules/extensions libGLcore.a.distrib # local diversion libglx.a.distrib# local diversion libglx.so -> libglx.so.1.0.5# from nvidia libglx.so.1.0.5 # from nvidia /usr/X11R6/lib/modules/drivers nv_drv.o.distrib# local diversion nvidia_drv.o# from nvidia /usr/lib libGLcore.so -> libGLcore.so.1 # from nvidia libGLcore.so.1 -> libGLcore.so.1.0.5# from nvidia libGLcore.so.1.0.5 # from nvidia libGL.so -> libGL.so.1 # here comes the problematic one libGL.so.1 -> libGL.so.1.2 libGL.so.1.0.5 # from nvidia libGL.so.1.2# xlibmesa3 xlibmesa3 provides libGL.so.1.2 and something insist on libGL.so.1 pointing to it. I tried to divert the link, so that my link (libGL.so.1 -> libGL.so.1.0.5) is not delete by xlibmesa3. This works fine during package install, but as soon as ldconfig is called, my link is replace by libGL.so.1 -> libGL.so.1.2. How can I stop this? Is there a better approach of integrating the vendor supplied drivers? regards ff -- Florian Friesdorf <[EMAIL PROTECTED]> OpenPGP key available on public key servers --> Save the future of Open Source <-- -> Online-Petition against Software Patents <- --> http://petition.eurolinux.org <--- PGP signature
dexter, mouse port
Hi,
I think I'm going to like dexter,
but at the moment it's missing /dev/gpmdata in the mouse port selection menu.
-ff
--
Florian Friesdorf <[EMAIL PROTECTED]>
OpenPGP key available on public key servers
--> Save the future of Open Source <--
-> Online-Petition against Software Patents <-
--> http://petition.eurolinux.org <---
PGP signature
Re: xlibs 40.1-0phase2v13 break xawtv
On Fri, Oct 06, 2000 at 01:56:02AM -0500, Branden Robinson wrote: > On Thu, Oct 05, 2000 at 01:03:36AM -0400, Decklin Foster wrote: > > Robert Vollmert <[EMAIL PROTECTED]> writes: > > > > > Error: XtMakeGeometryRequest - parent not composite > > > > Actually, this is not just happening with xawtv, but any xaw menu. > > It appears to be an upstream problem; send your report there. > > Are you using phase2v13? If not, please try it, because: > > 732. Fixed handling of XtMakeGeometryRequest() to test for parent > belonging to subclass of composite class only if the widget > itself is managed. This follows the specs more closely. > (Keith Packard). > > If you already are using v13, then it is possible the client is coded > wrongly. Or maybe Keith messed up (possible, but unusual). I am running kernel-2.4.0-test9 x phase2v13 xawtv 3.22 and I don't experience any problems watching tv. -ff -- Florian Friesdorf <[EMAIL PROTECTED]> OpenPGP key available on public key servers --> Save the future of Open Source <-- -> Online-Petition against Software Patents <- --> http://petition.eurolinux.org <--- pgpxXtx8KvGVM.pgp Description: PGP signature
Re: xlibs 40.1-0phase2v13 break xawtv
On Fri, Oct 06, 2000 at 01:56:02AM -0500, Branden Robinson wrote: > On Thu, Oct 05, 2000 at 01:03:36AM -0400, Decklin Foster wrote: > > Robert Vollmert <[EMAIL PROTECTED]> writes: > > > > > Error: XtMakeGeometryRequest - parent not composite > > > > Actually, this is not just happening with xawtv, but any xaw menu. > > It appears to be an upstream problem; send your report there. > > Are you using phase2v13? If not, please try it, because: > > 732. Fixed handling of XtMakeGeometryRequest() to test for parent > belonging to subclass of composite class only if the widget > itself is managed. This follows the specs more closely. > (Keith Packard). > > If you already are using v13, then it is possible the client is coded > wrongly. Or maybe Keith messed up (possible, but unusual). I am running kernel-2.4.0-test9 x phase2v13 xawtv 3.22 and I don't experience any problems watching tv. -ff -- Florian Friesdorf <[EMAIL PROTECTED]> OpenPGP key available on public key servers --> Save the future of Open Source <-- -> Online-Petition against Software Patents <- --> http://petition.eurolinux.org <--- PGP signature
