Re: xfree86-common_4.0.1-0phase2v4_all.deb
On Wed, Sep 13, 2000 at 10:13:43PM -0400, Zephaniah E. Hull wrote: On Wed, Sep 13, 2000 at 10:00:06PM -0400, [EMAIL PROTECTED] wrote: snip I also resolved mouse issues I had by changing the repeat_type value in /etc/gpm.conf to "raw" ... /dev/gpmdata was causing erratic behavior before (gpm's fault, not X). So now gpm and X get along well, so everything works flawlessly. No no no NO NO NO! Repeat in what gpm calls ms3 and what X calls IntelliMouse. Unless you really LIKE shooting yourself in the foot. What is the problem with using raw repeating ? It was the only setup that works for me (still using 3.3 though, and aps/2 mouse). But then, an USB mouse is very nice, since the USB mouse driver can give data to both X and gpm without problems, as can my amiga mouse on my apus box. Friendly, Sven LUTHER -- 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 Wed, Sep 13, 2000 at 10:13:43PM -0400, Zephaniah E. Hull wrote: On Wed, Sep 13, 2000 at 10:00:06PM -0400, [EMAIL PROTECTED] wrote: snip I also resolved mouse issues I had by changing the repeat_type value in /etc/gpm.conf to raw ... /dev/gpmdata was causing erratic behavior before (gpm's fault, not X). So now gpm and X get along well, so everything works flawlessly. No no no NO NO NO! Repeat in what gpm calls ms3 and what X calls IntelliMouse. Unless you really LIKE shooting yourself in the foot. What is the problem with using raw repeating ? It was the only setup that works for me (still using 3.3 though, and aps/2 mouse). But then, an USB mouse is very nice, since the USB mouse driver can give data to both X and gpm without problems, as can my amiga mouse on my apus box. Friendly, Sven LUTHER
Re: xfree86-common_4.0.1-0phase2v4_all.deb
On Tue, 12 Sep 2000 at 16:03:53 -0700, Marc Martinez [EMAIL PROTECTED] wrote: Load "/usr/X11R6/lib/modules/extensions/libglx.so" You were absolutely right -- replacing "glx" with the above did the trick. I don't know why I missed this, as I got 4.0.1 working on a different debian box after going through the headaches of getting the mesa and other glx stuff out of the way (moving the files themselves rather than changing the references in XF86Config). I also resolved mouse issues I had by changing the repeat_type value in /etc/gpm.conf to "raw" ... /dev/gpmdata was causing erratic behavior before (gpm's fault, not X). So now gpm and X get along well, so everything works flawlessly. Thanks, Matt Toups -- 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 Wed, Sep 13, 2000 at 10:00:06PM -0400, [EMAIL PROTECTED] wrote: snip I also resolved mouse issues I had by changing the repeat_type value in /etc/gpm.conf to "raw" ... /dev/gpmdata was causing erratic behavior before (gpm's fault, not X). So now gpm and X get along well, so everything works flawlessly. No no no NO NO NO! Repeat in what gpm calls ms3 and what X calls IntelliMouse. Unless you really LIKE shooting yourself in the foot. Zephaniah E. Hull. (gpm maintainer) Thanks, Matt Toups -- PGP EA5198D1-Zephaniah E. Hull [EMAIL PROTECTED]-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Upholder Seen on the back of a T-Shirt: "I am a bomb technician. If you see me running, try to keep up." PGP signature
Re: xfree86-common_4.0.1-0phase2v4_all.deb
On Wed, 13 Sep 2000, Zephaniah E. Hull wrote: Repeat in what gpm calls ms3 and what X calls IntelliMouse. Unless you really LIKE shooting yourself in the foot. That worked also (ie, same result as type "raw" in gpm.conf and "IMPS/2" in XF86Config) ... I assumed that repeat type "imps2" would be logical, but when it cause the mouse to behave erratically under X. Changing the repeat type to "raw" fixed that (from reading the man page, that seemed like the logical next step). The combo of "ms3" as repeat type and "intellimouse" in XF86Config seems a lot cleaner though.. while I don't see how "raw" was shooting myself in the foot (since everything worked), I appreciate the clarificaion. Thanks, Matt Toups (please continue to cc: me in replies as I am not subscribed to the list) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-common_4.0.1-0phase2v4_all.deb
Though in bad taste, I'll reply above but leave the message intact below. In all protocols except ms3/IntelliMouse X4 attempts to communicate with the mouse, trying this into a fifo is, err, a bad idea, largely because X4 gets it right back as if it was sent by the mouse, resulting in the erratic behaver. How bad it is depends on the protocol, but ms3/IntelliMouse is the only one which is actually safe, it also handles the mouse wheels. Zephaniah E. Hull. On Wed, Sep 13, 2000 at 10:50:00PM -0400, [EMAIL PROTECTED] wrote: On Wed, 13 Sep 2000, Zephaniah E. Hull wrote: Repeat in what gpm calls ms3 and what X calls IntelliMouse. Unless you really LIKE shooting yourself in the foot. That worked also (ie, same result as type "raw" in gpm.conf and "IMPS/2" in XF86Config) ... I assumed that repeat type "imps2" would be logical, but when it cause the mouse to behave erratically under X. Changing the repeat type to "raw" fixed that (from reading the man page, that seemed like the logical next step). The combo of "ms3" as repeat type and "intellimouse" in XF86Config seems a lot cleaner though.. while I don't see how "raw" was shooting myself in the foot (since everything worked), I appreciate the clarificaion. Thanks, Matt Toups (please continue to cc: me in replies as I am not subscribed to the list) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- PGP EA5198D1-Zephaniah E. Hull [EMAIL PROTECTED]-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Overfiend Oh God yes, please, Espy...let me mount your hard-driving SPARCbeast until I undulate in X-compiling ecstasy PGP signature
Re: xfree86-common_4.0.1-0phase2v4_all.deb
On Tue, 12 Sep 2000 at 16:03:53 -0700, Marc Martinez [EMAIL PROTECTED] wrote: Load /usr/X11R6/lib/modules/extensions/libglx.so You were absolutely right -- replacing glx with the above did the trick. I don't know why I missed this, as I got 4.0.1 working on a different debian box after going through the headaches of getting the mesa and other glx stuff out of the way (moving the files themselves rather than changing the references in XF86Config). I also resolved mouse issues I had by changing the repeat_type value in /etc/gpm.conf to raw ... /dev/gpmdata was causing erratic behavior before (gpm's fault, not X). So now gpm and X get along well, so everything works flawlessly. Thanks, Matt Toups
Re: xfree86-common_4.0.1-0phase2v4_all.deb
On Wed, Sep 13, 2000 at 10:00:06PM -0400, [EMAIL PROTECTED] wrote: snip I also resolved mouse issues I had by changing the repeat_type value in /etc/gpm.conf to raw ... /dev/gpmdata was causing erratic behavior before (gpm's fault, not X). So now gpm and X get along well, so everything works flawlessly. No no no NO NO NO! Repeat in what gpm calls ms3 and what X calls IntelliMouse. Unless you really LIKE shooting yourself in the foot. Zephaniah E. Hull. (gpm maintainer) Thanks, Matt Toups -- PGP EA5198D1-Zephaniah E. Hull [EMAIL PROTECTED]-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Upholder Seen on the back of a T-Shirt: I am a bomb technician. If you see me running, try to keep up. pgp3oiB3KIdOK.pgp Description: PGP signature
Re: xfree86-common_4.0.1-0phase2v4_all.deb
On Wed, 13 Sep 2000, Zephaniah E. Hull wrote: Repeat in what gpm calls ms3 and what X calls IntelliMouse. Unless you really LIKE shooting yourself in the foot. That worked also (ie, same result as type raw in gpm.conf and IMPS/2 in XF86Config) ... I assumed that repeat type imps2 would be logical, but when it cause the mouse to behave erratically under X. Changing the repeat type to raw fixed that (from reading the man page, that seemed like the logical next step). The combo of ms3 as repeat type and intellimouse in XF86Config seems a lot cleaner though.. while I don't see how raw was shooting myself in the foot (since everything worked), I appreciate the clarificaion. Thanks, Matt Toups (please continue to cc: me in replies as I am not subscribed to the list)
Re: xfree86-common_4.0.1-0phase2v4_all.deb
Though in bad taste, I'll reply above but leave the message intact below. In all protocols except ms3/IntelliMouse X4 attempts to communicate with the mouse, trying this into a fifo is, err, a bad idea, largely because X4 gets it right back as if it was sent by the mouse, resulting in the erratic behaver. How bad it is depends on the protocol, but ms3/IntelliMouse is the only one which is actually safe, it also handles the mouse wheels. Zephaniah E. Hull. On Wed, Sep 13, 2000 at 10:50:00PM -0400, [EMAIL PROTECTED] wrote: On Wed, 13 Sep 2000, Zephaniah E. Hull wrote: Repeat in what gpm calls ms3 and what X calls IntelliMouse. Unless you really LIKE shooting yourself in the foot. That worked also (ie, same result as type raw in gpm.conf and IMPS/2 in XF86Config) ... I assumed that repeat type imps2 would be logical, but when it cause the mouse to behave erratically under X. Changing the repeat type to raw fixed that (from reading the man page, that seemed like the logical next step). The combo of ms3 as repeat type and intellimouse in XF86Config seems a lot cleaner though.. while I don't see how raw was shooting myself in the foot (since everything worked), I appreciate the clarificaion. Thanks, Matt Toups (please continue to cc: me in replies as I am not subscribed to the list) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- PGP EA5198D1-Zephaniah E. Hull [EMAIL PROTECTED]-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Overfiend Oh God yes, please, Espy...let me mount your hard-driving SPARCbeast until I undulate in X-compiling ecstasy pgpnRPwLVf1Kx.pgp Description: PGP signature
re: xfree86-common_4.0.1-0phase2v4_all.deb
On Sat, 9 Sep 2000 20:57:16 -0700, Josh Carroll [EMAIL PROTECTED] wrote: I just recently updated to the phase2 debs (version4), and all I get is sig11 constantly, at random times. Sometimes as soon as I start X, sometimes no for almost an hour. It varies, but it NEVER stays resident more than an hour or two. This is really annoying, and I'm not sure what the problem is. I'm using the GeForce2 with the latest Nvidia drivers (0.9.5). I've attached the log from XFree. 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. Matt Toups -- 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 Sat, 9 Sep 2000 20:57:16 -0700, Josh Carroll [EMAIL PROTECTED] wrote: I just recently updated to the phase2 debs (version4), and all I get is sig11 constantly, at random times. Sometimes as soon as I start X, sometimes no for almost an hour. It varies, but it NEVER stays resident more than an hour or two. This is really annoying, and I'm not sure what the problem is. I'm using the GeForce2 with the latest Nvidia drivers (0.9.5). I've attached the log from XFree. 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. Matt Toups
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
Josh, I have two main thoughts. First, try to do something like compile your kernel (when running in a text console :) to make sure your memory isn't running beyond its limits. If you can compile kernels fine, then you probably have fine memory. :) I was getting signal 11s when I had my sync rates set too high. See if you can set your sync rates lower. (When I had mine set high, sig11. Changing them lower removed my sig11s. High again, sig11 again. However, it was quite specifically right at start.) HTH, good luck. * Josh Carroll [EMAIL PROTECTED] [000909 20:58]: I just recently updated to the phase2 debs (version4), and all I get is sig11 constantly, at random times. Sometimes as soon as I start X, sometimes not for almost an hour. It varies, but it NEVER stays resident more than an hour or two. This is really annoying, and I'm not sure what the problem is. I'm using the GeForce2 with the latest Nvidia drivers (0.9.5). I've attached the log from XFree. -- Seth Arnold | http://www.willamette.edu/~sarnold/
Re: xfree86-common_4.0.1-0phase2v4_all.deb
Josh Carroll wrote: I just recently updated to the phase2 debs (version4), and all I get is sig11 constantly, at random times. Sometimes as soon as I start X, sometimes not for almost an hour. It varies, but it NEVER stays resident more than an hour or two. This is really annoying, and I'm not sure what the problem is. I'm using the GeForce2 with the latest Nvidia drivers (0.9.5). I've attached the log from XFree. Thanks, Josh This is maybe because your XFree is newer than the one the nvidia driver was released for. Try waiting for 4.0.2 :-/ XFree86 Version 4.0.1c / X Window System (protocol Version 11, revision 0, vendor release 6400) Release Date: 28 August 2000 [...] (II) LoadModule: dbe (II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a (II) Module dbe: vendor=The XFree86 Project compiled for 4.0.1c, module version = 1.0.0 _^^ Module class: XFree86 Server Extension ABI class: XFree86 Server Extension, version 0.1 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: glx (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so (II) Module glx: vendor=NVIDIA Corporation compiled for 4.0.1, module version = 1.0.5 _^ Module class: XFree86 Server Extension ABI class: XFree86 Server Extension, version 0.1 (II) Loading extension GLX [...]
Re: xfree86-common_4.0.1-0phase2v4_all.deb
Josh, I have two main thoughts. First, try to do something like compile your kernel (when running in a text console :) to make sure your memory isn't running beyond its limits. If you can compile kernels fine, then you probably have fine memory. :) I was getting signal 11s when I had my sync rates set too high. See if you can set your sync rates lower. (When I had mine set high, sig11. Changing them lower removed my sig11s. High again, sig11 again. However, it was quite specifically right at start.) HTH, good luck. * Josh Carroll [EMAIL PROTECTED] [000909 20:58]: I just recently updated to the phase2 debs (version4), and all I get is sig11 constantly, at random times. Sometimes as soon as I start X, sometimes not for almost an hour. It varies, but it NEVER stays resident more than an hour or two. This is really annoying, and I'm not sure what the problem is. I'm using the GeForce2 with the latest Nvidia drivers (0.9.5). I've attached the log from XFree. -- Seth Arnold | http://www.willamette.edu/~sarnold/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
xfree86-common_4.0.1-0phase2v4_all.deb
I just recently updated to the phase2 debs (version4), and all I get is sig11 constantly, at random times. Sometimes as soon as I start X, sometimes not for almost an hour. It varies, but it NEVER stays resident more than an hour or two. This is really annoying, and I'm not sure what the problem is. I'm using the GeForce2 with the latest Nvidia drivers (0.9.5). I've attached the log from XFree. Thanks, Josh XFree86 Version 4.0.1c / X Window System (protocol Version 11, revision 0, vendor release 6400) Release Date: 28 August 2000 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (see http://www.XFree86.Org/FAQ) Operating System: Linux 2.2.17pre10 i686 [ELF] Module Loader present (==) Log file: /var/log/XFree86.0.log, Time: Sat Sep 9 20:47:37 2000 (==) Using config file: /etc/X11/XF86Config Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (??) unknown. (==) ServerLayout Simple Layout (**) |--Screen Screen 1 (0) (**) | |--Monitor My Monitor (**) | |--Device NVIDIA GeForce DDR (generic) (**) |--Input Device Mouse1 (**) |--Input Device Keyboard1 (**) Option AutoRepeat 500 30 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc101 (**) XKB: model: pc101 (**) Option XkbLayout us (**) XKB: layout: us (WW) The directory /usr/X11R6/lib/X11/fonts/100dpi/ does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/100dpi/ does not exist. Entry deleted from font path. (**) FontPath set to /usr/X11R6/lib/X11/fonts/local/,/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/Speedo/ (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (--) using VT number 7 (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.3 XFree86 XInput driver : 0.1 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.1 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.0.1c, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.1 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.0.1c, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.3 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x8080, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1106,0691 card 1043,8017 rev c4 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,8598 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:04:0: chip 1106,0596 card 1043,8017 rev 23 class 06,01,00 hdr 80 (II) PCI: 00:04:1: chip 1106,0571 card , rev 10 class 01,01,8a hdr 00 (II) PCI: 00:04:2: chip 1106,3038 card 0925,1234 rev 11 class 0c,03,00 hdr 00 (II) PCI: 00:04:3: chip 1106,3050 card , rev 30 class 06,00,00 hdr 00 (II) PCI: 00:09:0: chip 109e,0350 card , rev 12 class 04,00,00 hdr 00 (II) PCI: 00:0a:0: chip 8086,1229 card , rev 01 class 02,00,00 hdr 00 (II) PCI: 00:0b:0: chip 1274,5000 card 4942,4c4c rev 00 class 04,01,00 hdr 00 (II) PCI: 00:0c:0: chip 109e,0350 card , rev 12 class 04,00,00 hdr 00 (II) PCI: 01:00:0: chip 10de,0150 card 1048,0c50 rev a3 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) LoadModule: scanpci (II) Loading /usr/X11R6/lib/modules/libscanpci.a (II) Module scanpci: vendor=The XFree86 Project compiled for 4.0.1c, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.3 (II) UnloadModule: scanpci (II) Unloading /usr/X11R6/lib/modules/libscanpci.a (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x08 (VGA_EN is set) (II) Bus 1 I/O range: (II) Bus 1 non-prefetchable memory range: [0] -1 0xd400 - 0xd57f (0x180) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0xd7f0 - 0xdfff (0x810) MX[B] (--) PCI: (0:9:0) BrookTree 848 rev 18, Mem @ 0xd700/12 (--) PCI: (0:12:0) BrookTree 848 rev 18, Mem @ 0xd580/12 (--) PCI:*(1:0:0) NVidia GeForce2 GTS rev 163, Mem @ 0xd400/24, 0xd800/27 (II) Addressable bus resource ranges are [0] -1 0x - 0x (0x0) MX[B] [1] -1 0x - 0x (0x1) IX[B] (II) OS-reported resource ranges: [0] -1 0xffe0 - 0x (0x20) MX[B](B) [1] -1 0x0010 - 0x3fff (0x3ff0) MX[B]E(B) [2] -1 0x000f -