Re: Bug#77130: dexter is not devfs ready
On Mon, Nov 20, 2000 at 11:00:34PM -0500, Branden Robinson wrote: > I check for a mounted devfs using a check given to me. How about reading > the source of dexter and telling me what's wrong with it? a much simpler test than working out proper grep semantics is the following: [ -c /dev/.devfsd ] Marc
Re: Bug#77130: dexter is not devfs ready
On Mon, Nov 20, 2000 at 11:00:34PM -0500, Branden Robinson wrote: > I check for a mounted devfs using a check given to me. How about reading > the source of dexter and telling me what's wrong with it? a much simpler test than working out proper grep semantics is the following: [ -c /dev/.devfsd ] Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#77130: dexter is not devfs ready
On Wed, Nov 15, 2000 at 11:27:14PM -0500, Branden Robinson wrote: > On Wed, Nov 15, 2000 at 09:55:30PM +0100, Goswin Brederlow wrote: > > All suggestions for the mouse device use the old device names, devfs > > has them in subdirectories. Please use the new names when devfs is used. > > You're going to have to tell me what these are. I asked on IRC what I > should use, and I used what I was told. the real device for at least psaux is /dev/misc/psaux .. if you have the compatibility options enabled in devfsd it also makes a symlink back to /dev/psaux for you. looks like the ttyS* serial devices are now in the form of /dev/tts/0 .. I don't have any usb mice connected right now so that's all I can tell you offhand. while it's just personal preference, for any box that I use devfs on but don't use devfsd, I also don't let it mount as /dev, but rather keep it off on other directories just as a guide to know what devices are available at any given time (which was handy for example to see that the major for joystick devices got moved around in newer kernels). Marc
Re: Bug#77130: dexter is not devfs ready
On Wed, Nov 15, 2000 at 11:27:14PM -0500, Branden Robinson wrote: > On Wed, Nov 15, 2000 at 09:55:30PM +0100, Goswin Brederlow wrote: > > All suggestions for the mouse device use the old device names, devfs > > has them in subdirectories. Please use the new names when devfs is used. > > You're going to have to tell me what these are. I asked on IRC what I > should use, and I used what I was told. the real device for at least psaux is /dev/misc/psaux .. if you have the compatibility options enabled in devfsd it also makes a symlink back to /dev/psaux for you. looks like the ttyS* serial devices are now in the form of /dev/tts/0 .. I don't have any usb mice connected right now so that's all I can tell you offhand. while it's just personal preference, for any box that I use devfs on but don't use devfsd, I also don't let it mount as /dev, but rather keep it off on other directories just as a guide to know what devices are available at any given time (which was handy for example to see that the major for joystick devices got moved around in newer kernels). Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Nvidia driver
On Sat, Nov 11, 2000 at 12:24:08AM +0100, Mithrandir wrote:
> i will attach a log-file from a compilation and installation of the modules,
> in
> hope someone already got the same prob (and perhaps already solved it ;) )
> By the way, the graphic-board is a "Elsa Erazor III Pro - TNT2"
> perhaps this is the problem :((
indeed somebody has, I picked up a patch (attached) from the ice-dcc bot on
the openprojects irc network. I have 2 boxes, one with an Erazor II and one
with an Erazor III, I've only tested this patch on the first one, but X
comes up fine, but the system locks shortly thereafter due to other reasons,
the box with the Erazor III runs fine with this driver and test9 though, I
intend to try out test10 over the weekend on it. if you run into further
problems getting things configured with these drivers the people in #nvidia
(on the openprojects servers) may also be of help.
Marc
diff -ru NVIDIA_kernel-0.9-5/nv.c nvdriver/nv.c
--- NVIDIA_kernel-0.9-5/nv.cSat Aug 26 02:48:38 2000
+++ nvdriver/nv.c Wed Nov 1 00:29:36 2000
@@ -553,7 +553,7 @@
if (map_nr)
{
mem_map_reserve(map_nr);
-mem_map_inc_count(map_nr);
+atomic_inc(&((map_nr)->count));
}
}
}
@@ -580,7 +580,7 @@
#endif
if (map_nr)
{
-mem_map_dec_count(map_nr);
+atomic_dec(&((map_nr)->count));
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 4, 0)
if (atomic_read(&mem_map[map_nr].count) == 1)
#else
Re: Nvidia driver
On Sat, Nov 11, 2000 at 12:24:08AM +0100, Mithrandir wrote:
> i will attach a log-file from a compilation and installation of the modules, in
> hope someone already got the same prob (and perhaps already solved it ;) )
> By the way, the graphic-board is a "Elsa Erazor III Pro - TNT2"
> perhaps this is the problem :((
indeed somebody has, I picked up a patch (attached) from the ice-dcc bot on
the openprojects irc network. I have 2 boxes, one with an Erazor II and one
with an Erazor III, I've only tested this patch on the first one, but X
comes up fine, but the system locks shortly thereafter due to other reasons,
the box with the Erazor III runs fine with this driver and test9 though, I
intend to try out test10 over the weekend on it. if you run into further
problems getting things configured with these drivers the people in #nvidia
(on the openprojects servers) may also be of help.
Marc
diff -ru NVIDIA_kernel-0.9-5/nv.c nvdriver/nv.c
--- NVIDIA_kernel-0.9-5/nv.cSat Aug 26 02:48:38 2000
+++ nvdriver/nv.c Wed Nov 1 00:29:36 2000
@@ -553,7 +553,7 @@
if (map_nr)
{
mem_map_reserve(map_nr);
-mem_map_inc_count(map_nr);
+atomic_inc(&((map_nr)->count));
}
}
}
@@ -580,7 +580,7 @@
#endif
if (map_nr)
{
-mem_map_dec_count(map_nr);
+atomic_dec(&((map_nr)->count));
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 4, 0)
if (atomic_read(&mem_map[map_nr].count) == 1)
#else
Re: x-terminal-emulator
On Mon, Oct 30, 2000 at 07:17:21PM -0500, Branden Robinson wrote: > Can someone help me establish whether the existing X terminal emulators in > Debian do in fact support all those options? If so, then it should be > straightforward to make this requirement part of policy. > > To try to answer your question, my guess is that most, but not all, > terminal emulators support these flags. rxvt's man page lists '-title' as the preferred switch, but also mentions that -T is supported as well for compatibility. of the rxvt derivatives I only have wterm installed presently, and while its manpage does not mention the -T compatibility switch it does indeed honour it just like -title. both programs support -e as well. I'll let somebody else more familiar with the others fill in the blanks (aterm, eterm, xvt, etc). Marc
Re: x-terminal-emulator
On Mon, Oct 30, 2000 at 07:17:21PM -0500, Branden Robinson wrote: > Can someone help me establish whether the existing X terminal emulators in > Debian do in fact support all those options? If so, then it should be > straightforward to make this requirement part of policy. > > To try to answer your question, my guess is that most, but not all, > terminal emulators support these flags. rxvt's man page lists '-title' as the preferred switch, but also mentions that -T is supported as well for compatibility. of the rxvt derivatives I only have wterm installed presently, and while its manpage does not mention the -T compatibility switch it does indeed honour it just like -title. both programs support -e as well. I'll let somebody else more familiar with the others fill in the blanks (aterm, eterm, xvt, etc). Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to deal with nvidia driver/libs
On Thu, Oct 12, 2000 at 04:10:10AM +0200, Florian Friesdorf wrote: > I diverted nv, because of xf86cfg failing to start, because of to conflicting > drivers. ahh, I went through the config with the stock drivers before even extracting the nvidia stuff just to make sure the shipping defaults would at least get me a usable display. afterwards it was just a couple of tweaks in the config file and nvidia's driver was humming along happily.. > Ok, then I will have a look at the packaging manual. as a final note, the recipe I used to cook my stuff up was to start with: for the -GLX package I started with debhelper (hadn't used it for any personal packages yet and was curious about what it was like from an initial packaging point of view) and used the ROOT variable in nvidia's Makefile to install the necessary files in the debian/tmp dir .. added in the docs and removed the _drv.o file from the dh_shlibdeps call .. after that was just the standard stuff of filling out the control file and changelogs and such. the second step was to create a framework for the module, my solution there was to start with the source tree that device3dfx installs and use that structure as the start of a sourcetree for the nvidia module component. this way a 'make-kpkg kernel-image modules-image' builds everything necessary and I don't hafta remember to go back out and build the module seperately before rebooting.. hopefully the notes above will help you and anybody else interested in building custom .deb's for these drivers make your own packages.. Marc
Re: how to deal with nvidia driver/libs
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. > > so far I have solved the following conflicts with dpkg-divert. > > /usr/X11R6/lib/modules/extensions > libGLcore.a.distrib # local diversion really no need to divert this... > libglx.a.distrib# local diversion this diversion can be avoided by specifying the full path to the libglx.so in the configuration file. > /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). > /usr/lib [snip] > # 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? 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. > 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). Marc
Re: how to deal with nvidia driver/libs
On Thu, Oct 12, 2000 at 04:10:10AM +0200, Florian Friesdorf wrote: > I diverted nv, because of xf86cfg failing to start, because of to conflicting > drivers. ahh, I went through the config with the stock drivers before even extracting the nvidia stuff just to make sure the shipping defaults would at least get me a usable display. afterwards it was just a couple of tweaks in the config file and nvidia's driver was humming along happily.. > Ok, then I will have a look at the packaging manual. as a final note, the recipe I used to cook my stuff up was to start with: for the -GLX package I started with debhelper (hadn't used it for any personal packages yet and was curious about what it was like from an initial packaging point of view) and used the ROOT variable in nvidia's Makefile to install the necessary files in the debian/tmp dir .. added in the docs and removed the _drv.o file from the dh_shlibdeps call .. after that was just the standard stuff of filling out the control file and changelogs and such. the second step was to create a framework for the module, my solution there was to start with the source tree that device3dfx installs and use that structure as the start of a sourcetree for the nvidia module component. this way a 'make-kpkg kernel-image modules-image' builds everything necessary and I don't hafta remember to go back out and build the module seperately before rebooting.. hopefully the notes above will help you and anybody else interested in building custom .deb's for these drivers make your own packages.. Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to deal with nvidia driver/libs
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. > > so far I have solved the following conflicts with dpkg-divert. > > /usr/X11R6/lib/modules/extensions > libGLcore.a.distrib # local diversion really no need to divert this... > libglx.a.distrib# local diversion this diversion can be avoided by specifying the full path to the libglx.so in the configuration file. > /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). > /usr/lib [snip] > # 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? 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. > 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). Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [AKennedy@bursteinlabs.com: GeForce2 divers for XFree86 4.x/Debian]
On Sat, Oct 07, 2000 at 06:38:10PM -0700, Seth Arnold wrote: > Yeah, me too. > > Andrew, your best and easiest bet is to see if nvidia has a tarball, or > a single file, the way matrox does. It is very easy with matrox, and if > they don't offer something so simple, then I suggest you write them, and > ask them to try the matrox drivers. :) well, the quick answer is that yes, nvidia does have tarballs available, and they function quite nicely in conjunction with the debian packaged XFree 4.0 stuff. the bit that Andrew seems to be asking after is the kernel module part of things. since he's using an smp system I'm guessing he's already got a custom kernel compiled to take advantage of it, and as such the module would likely need to be built on his own system (or at the very least using a configured source tree setup with the same options). what I've done for my own setup is made a quick hack of a package for the gl libraries to satisfy dependency issues without needing dpkg-divert nastiness all over the place, another for the server module binaries needed, and made a quick tarball of a directory which can be dropped into the /usr/src/modules dir to compile the nvidia kernel module into its own package in conjunction with make-kpkg invocations (got tired of forgetting to install it before rebooting a new kernel and having to ssh in from another box to get things in proper working order again). I based all of that structure off of the device-3dfx source setup, very quick adaptation and it really should be cleaned up some before I consider giving it out or making a proper package from it (for instance it currently assumes later 2.4 kernel module paths to install in, since that's all I run on the game box). I haven't looked over the licensing terms for all the aforementioned items as I really hadn't intended on them going any farther than my own network. If there is sufficient demand for such I'll see about getting an "installer" type of package put together if necessary that can create these components from the tarballs (something I've been considering for my own convenience anyway, but new releases are fairly rare) if the licensing is too restrictive (which I've a feeling it probably is). Andrew, in the meantime, can you give me/us some more details about the steps you've taken in attempting to set up the nvidia drivers on your system, and also your kernel setup. Note that you may need to set the SYSINCLUDE variable I think it was to point to your kernel source tree location so that the nvidia module will have the right headers available for it, that's the only thing I needed to do when I first set the drivers up out of the tarballs. Marc
Re: [AKennedy@bursteinlabs.com: GeForce2 divers for XFree86 4.x/Debian]
On Sat, Oct 07, 2000 at 06:38:10PM -0700, Seth Arnold wrote: > Yeah, me too. > > Andrew, your best and easiest bet is to see if nvidia has a tarball, or > a single file, the way matrox does. It is very easy with matrox, and if > they don't offer something so simple, then I suggest you write them, and > ask them to try the matrox drivers. :) well, the quick answer is that yes, nvidia does have tarballs available, and they function quite nicely in conjunction with the debian packaged XFree 4.0 stuff. the bit that Andrew seems to be asking after is the kernel module part of things. since he's using an smp system I'm guessing he's already got a custom kernel compiled to take advantage of it, and as such the module would likely need to be built on his own system (or at the very least using a configured source tree setup with the same options). what I've done for my own setup is made a quick hack of a package for the gl libraries to satisfy dependency issues without needing dpkg-divert nastiness all over the place, another for the server module binaries needed, and made a quick tarball of a directory which can be dropped into the /usr/src/modules dir to compile the nvidia kernel module into its own package in conjunction with make-kpkg invocations (got tired of forgetting to install it before rebooting a new kernel and having to ssh in from another box to get things in proper working order again). I based all of that structure off of the device-3dfx source setup, very quick adaptation and it really should be cleaned up some before I consider giving it out or making a proper package from it (for instance it currently assumes later 2.4 kernel module paths to install in, since that's all I run on the game box). I haven't looked over the licensing terms for all the aforementioned items as I really hadn't intended on them going any farther than my own network. If there is sufficient demand for such I'll see about getting an "installer" type of package put together if necessary that can create these components from the tarballs (something I've been considering for my own convenience anyway, but new releases are fairly rare) if the licensing is too restrictive (which I've a feeling it probably is). Andrew, in the meantime, can you give me/us some more details about the steps you've taken in attempting to set up the nvidia drivers on your system, and also your kernel setup. Note that you may need to set the SYSINCLUDE variable I think it was to point to your kernel source tree location so that the nvidia module will have the right headers available for it, that's the only thing I needed to do when I first set the drivers up out of the tarballs. Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-common_4.0.1-0phase2v4_all.deb
On Tue, Sep 12, 2000 at 05:57:51PM -0400, [EMAIL PROTECTED] wrote: > FWIW, I've been using the phase1 debs of X4.0.1 with the 0.9.4 NVidia > drivers on a GeForce2, and haven't had any sig11's -- but the server hangs > (and the displacy is garbled, have to reboot blindly) if the line > #Load "glx" > is uncommented in XF86Config (ie, no quake3). > > I've had everything work flawlessly with this setup (phase1 debs, 0.9.4 > NVidia drivers) on a PCI TNT card, though. Quake3 ran decently on a > k6-300 with this card. > > I'll upgrade to phase2 and 0.9.5 once my bandwidth allows me to, and see > if the GLX problem persists. the GLX problem has nothing to do with the debian packaging, I had issues with it when using XFree's binary release for testing (though I think it didn't crop up until the 4.0.1 release IIRC).. the problem comes into play because you're only specifying "glx", and in the directory is the "libglx.a" installed by the regular XFree things, and also the "libglx.so" symlink to the library NVidia provides. Care to guess which one it chooses by default? ;) here's what I've been using in my XF86Config file and everything functions normally (just updated to the 0.9-5 release the other day, no issues for my setup, which is just a TNT2 btw): Load "/usr/X11R6/lib/modules/extensions/libglx.so" Marc
Re: xfree86-common_4.0.1-0phase2v4_all.deb
On Tue, Sep 12, 2000 at 05:57:51PM -0400, [EMAIL PROTECTED] wrote: > FWIW, I've been using the phase1 debs of X4.0.1 with the 0.9.4 NVidia > drivers on a GeForce2, and haven't had any sig11's -- but the server hangs > (and the displacy is garbled, have to reboot blindly) if the line > #Load "glx" > is uncommented in XF86Config (ie, no quake3). > > I've had everything work flawlessly with this setup (phase1 debs, 0.9.4 > NVidia drivers) on a PCI TNT card, though. Quake3 ran decently on a > k6-300 with this card. > > I'll upgrade to phase2 and 0.9.5 once my bandwidth allows me to, and see > if the GLX problem persists. the GLX problem has nothing to do with the debian packaging, I had issues with it when using XFree's binary release for testing (though I think it didn't crop up until the 4.0.1 release IIRC).. the problem comes into play because you're only specifying "glx", and in the directory is the "libglx.a" installed by the regular XFree things, and also the "libglx.so" symlink to the library NVidia provides. Care to guess which one it chooses by default? ;) here's what I've been using in my XF86Config file and everything functions normally (just updated to the 0.9-5 release the other day, no issues for my setup, which is just a TNT2 btw): Load "/usr/X11R6/lib/modules/extensions/libglx.so" Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
