xmms, xfree4
This is a rather odd situation. I'll just summarize, I have two machines, a desktop called baboon, and a laptop called gorilla: When running xmms on baboon, but directing output to gorilla (connected to baboon with ssh -X), xmms segfaults. When running xmms on gorilla (same version), output to baboon, everything appears fine. When running xmms on baboon, my display "hangs". It is still possible to connect over the network and order the machine to reboot, but display/keyboard cannot be restored. (Or is there a better way than "kill [-9?] X"?) I made a major system upgrade a while back, running latest debian xmms, XFree4.0.1, I have a nvidia TNT2-m64... It seems xmms has some bug that appears on baboon but not on gorilla, but this bothers me less than the fact that it takes my display down with it. (I'm not sure X crashes, but my screen is not updated anymore, and the mouse cursor disappears.) I have commented 'Load "glx"' in my XF86Config-4, unresolved symbols stops X from loading if I don't. I also commented 'Load "dri"', as I don't have a 2.4.x kernel. I have tried nvidia's drivers - these hang my machine completely, no longer responds to pings, etc. Before I solve that though, I first want to fix up this xmms with the normal "nv" open source driver. Any ideas? What other modules can/should I comment? Hugo van der Merwe ps. I haven't subscribed to this list, I read it via the web. CC'ing to me will make replying that much easier. Thanks.
Re: xmms, xfree4
On Fri, Nov 24, 2000 at 04:29:49PM +0200, hugo wrote: > This is a rather odd situation. I'll just summarize, I have two > machines, a desktop called baboon, and a laptop called gorilla: ARGH! Damn it! I lie! Sorry, the upgrade I did three hours ago appears to have fixed this. xmms now runs fine, as does the dexter-configured XF86Config-4: no unresolved symbols or anything. Please disregard my previous email. My next thing is to get the nvidia drivers working. I'll do some extensive testing before mailing again. Without 2.4, I'd guess it's best to comment out the "dri" module? Sorry for wasting your time, this was nevertheless a rather peculiar problem. (If anyone knows what caused it, I'd still be interested.) Hugo van der Merwe
X server catching signal 11
This has actually been going on for a couple months. I've swapped out window manager and display manager, ditching gnome for the time being. As far as I can recall, stability was fine during -phase1. Hardware configuration: Dual P200mmx on a piix3 chipset(430HX), APICs enabled. Video: 00:0a.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro 215GP (rev 5c) 00:0b.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II] 128MB non-parity memory. Head 0 boots with atyfb because I do switch from X to work on the console. Kernel: Linux heathen 2.4.0-test10 #1 SMP Sat Nov 11 14:17:41 PST 2000 i586 unknown I'd like to supply some useful debugging information, but I'm not sure what would be considered useful and what wouldn't.
Prepackaged indirected X terminal
I know how to have xdm use the indirect and chooser features to work with external X terminals and determine where they go. Works great, but it leaves me with a simple question ... Is there a clean way to specify that the locally managed display should be indirected (like a terminal would be) for the option of attaching it elsewhere instead of locally ? I can do it by disabling it in xdm and putting a line in the inittab, but the authentication stuff is a pain and I'm assuming there must be a better way of setting it all up. Separately to that, the X traffic of a remoted display is not normally encrypted. Sometimes that is important. Is there a clean way to have that local X display make its connection to the remote machine using (for example) ssh -X ? I know how to do it manually, with some extra scripting, but I was hoping that there was something packaged for this. Alex.
Re: [tomlins@cam.org: DRI wth 2.2.18pre kernels]
Hi, Some info and feedback on DRI in 2.2.18pre. Chip Salzenberg posted a patch for 2.2.18pre21 that upgrades drm to 2.0.0 levels. This lets the G400 work with xf4 as is in woody. Without this patch DRI does not work for G400s. TIA, Ed Tomlinson On November 23, 2000 07:29 pm, Ed Tomlinson wrote: > On November 23, 2000 06:38 pm, Zephaniah E. Hull wrote: > > > Please don't send mail to Branden directly, questions such as this are > > > > much better suited for debian-x. > > > > > - Forwarded message from Ed Tomlinson <[EMAIL PROTECTED]> - > > > Hi, > > > > > > I do not know if this has been reported as a bug yet as the > > > bugs.debian.org page does not seem to work... > > > > > > I have just upgraded to woody (worked but was a little painfull). The > > > major reason for this was to get to XF4 and get DRI and dualhead > > > working with my matrox G400 MAX. Well I can get everything going > > > except that when drm is finally ready to enable DRI it fails since the > > > version reported my mga.o is 1.0.0 and the xserver wants 2.0.0 or > > > above. > > > > This is an upstream decision, I believe there are back port patches for > > the DRM modules to 2.2.x kernels, however I am not positive. > > > > Also I believe that the current 2.2.x pre kernels from Alan Cox have an > > up to date DRM module. > > Yes. I am running 2.2.18pre21aa2 with agpgart and dri built from the stuff > in pre21. Problem is that the mga.o module it builds reports its version > as 1.0.0 and the stuff in the debs expects 2.0.0. This stops things dead. > Note ifs not as simple as hacking mga.o to report 2.0.0. This will get dri > enable but will not work (the xserver crashes when dri start). > > I have also tried the mga_drv.o from matrox. This one lets dri enable but > then libGL.o complains about the version. The matrox version also messes > up the card settings so a reqular framebuffer screen will not display > correctly (a problem for matrox to fix...). > > > The only thing we (Debian) can do to fix this is try and make sure that > > the kernel sources we package have the current DRM module patches. > > Understood. Then consider this a heads up. The 2.2.18 kernel has lots of > nice goodies, usb, agpgart, dri, nfsv3. IMVHO Its going to be a very > popular kernel. It would be a good idea to be ready to support this when > it arrives. Suggest that 2.2.18pre23 be used as a model and packaged and > the various accessories (like XF4) built to work with it. > > TIA, > Ed Tomlinson > > > Zephaniah E. Hull. > > (The Debian developer who somehow got the 3Dfx issues, even under > > packages he does not maintain.) > > > > > Before I go through the pain of learning how to rebuild the > > > package(s), will it work with dri 1.0.0 at all? If so are you > > > planning .debs for 2.2.18? In any case if it will work with dri 1.0.0 > > > just what packages need to be rebuilt? Do you have pointers to docs > > > on just how to rebuild them? > > > > > > TIA, > > > Ed Tomlinson <[EMAIL PROTECTED]> > > > > > > BTW xf86cfg fails here. first it cannot detect my usb mouse correctly. > > > Once I fixed the symlink in /dev it failed to autodetect the protocol > > > needed. It did write enought of an XF86Config to get X started after > > > fixing the mouse up. Then, when started under X, it complained that the > > > cards DB was not found On irc I was advised to try dexter. Dexter > > > will not generate anything but an 3.3.6 version file for me... I did > > > get it all working (manually) but thought the above might help. > > > Content-Type: application/pgp-signature; charset="us-ascii"; > name="Attachment: 1" > Content-Transfer-Encoding: 7bit > Content-Description: >
xmms, xfree4
This is a rather odd situation. I'll just summarize, I have two machines, a desktop called baboon, and a laptop called gorilla: When running xmms on baboon, but directing output to gorilla (connected to baboon with ssh -X), xmms segfaults. When running xmms on gorilla (same version), output to baboon, everything appears fine. When running xmms on baboon, my display "hangs". It is still possible to connect over the network and order the machine to reboot, but display/keyboard cannot be restored. (Or is there a better way than "kill [-9?] X"?) I made a major system upgrade a while back, running latest debian xmms, XFree4.0.1, I have a nvidia TNT2-m64... It seems xmms has some bug that appears on baboon but not on gorilla, but this bothers me less than the fact that it takes my display down with it. (I'm not sure X crashes, but my screen is not updated anymore, and the mouse cursor disappears.) I have commented 'Load "glx"' in my XF86Config-4, unresolved symbols stops X from loading if I don't. I also commented 'Load "dri"', as I don't have a 2.4.x kernel. I have tried nvidia's drivers - these hang my machine completely, no longer responds to pings, etc. Before I solve that though, I first want to fix up this xmms with the normal "nv" open source driver. Any ideas? What other modules can/should I comment? Hugo van der Merwe ps. I haven't subscribed to this list, I read it via the web. CC'ing to me will make replying that much easier. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xmms, xfree4
On Fri, Nov 24, 2000 at 04:29:49PM +0200, hugo wrote: > This is a rather odd situation. I'll just summarize, I have two > machines, a desktop called baboon, and a laptop called gorilla: ARGH! Damn it! I lie! Sorry, the upgrade I did three hours ago appears to have fixed this. xmms now runs fine, as does the dexter-configured XF86Config-4: no unresolved symbols or anything. Please disregard my previous email. My next thing is to get the nvidia drivers working. I'll do some extensive testing before mailing again. Without 2.4, I'd guess it's best to comment out the "dri" module? Sorry for wasting your time, this was nevertheless a rather peculiar problem. (If anyone knows what caused it, I'd still be interested.) Hugo van der Merwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Prepackaged indirected X terminal
I know how to have xdm use the indirect and chooser features to work with external X terminals and determine where they go. Works great, but it leaves me with a simple question ... Is there a clean way to specify that the locally managed display should be indirected (like a terminal would be) for the option of attaching it elsewhere instead of locally ? I can do it by disabling it in xdm and putting a line in the inittab, but the authentication stuff is a pain and I'm assuming there must be a better way of setting it all up. Separately to that, the X traffic of a remoted display is not normally encrypted. Sometimes that is important. Is there a clean way to have that local X display make its connection to the remote machine using (for example) ssh -X ? I know how to do it manually, with some extra scripting, but I was hoping that there was something packaged for this. Alex. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [tomlins@cam.org: DRI wth 2.2.18pre kernels]
Hi, Some info and feedback on DRI in 2.2.18pre. Chip Salzenberg posted a patch for 2.2.18pre21 that upgrades drm to 2.0.0 levels. This lets the G400 work with xf4 as is in woody. Without this patch DRI does not work for G400s. TIA, Ed Tomlinson On November 23, 2000 07:29 pm, Ed Tomlinson wrote: > On November 23, 2000 06:38 pm, Zephaniah E. Hull wrote: > > > Please don't send mail to Branden directly, questions such as this are > > > > much better suited for debian-x. > > > > > - Forwarded message from Ed Tomlinson <[EMAIL PROTECTED]> - > > > Hi, > > > > > > I do not know if this has been reported as a bug yet as the > > > bugs.debian.org page does not seem to work... > > > > > > I have just upgraded to woody (worked but was a little painfull). The > > > major reason for this was to get to XF4 and get DRI and dualhead > > > working with my matrox G400 MAX. Well I can get everything going > > > except that when drm is finally ready to enable DRI it fails since the > > > version reported my mga.o is 1.0.0 and the xserver wants 2.0.0 or > > > above. > > > > This is an upstream decision, I believe there are back port patches for > > the DRM modules to 2.2.x kernels, however I am not positive. > > > > Also I believe that the current 2.2.x pre kernels from Alan Cox have an > > up to date DRM module. > > Yes. I am running 2.2.18pre21aa2 with agpgart and dri built from the stuff > in pre21. Problem is that the mga.o module it builds reports its version > as 1.0.0 and the stuff in the debs expects 2.0.0. This stops things dead. > Note ifs not as simple as hacking mga.o to report 2.0.0. This will get dri > enable but will not work (the xserver crashes when dri start). > > I have also tried the mga_drv.o from matrox. This one lets dri enable but > then libGL.o complains about the version. The matrox version also messes > up the card settings so a reqular framebuffer screen will not display > correctly (a problem for matrox to fix...). > > > The only thing we (Debian) can do to fix this is try and make sure that > > the kernel sources we package have the current DRM module patches. > > Understood. Then consider this a heads up. The 2.2.18 kernel has lots of > nice goodies, usb, agpgart, dri, nfsv3. IMVHO Its going to be a very > popular kernel. It would be a good idea to be ready to support this when > it arrives. Suggest that 2.2.18pre23 be used as a model and packaged and > the various accessories (like XF4) built to work with it. > > TIA, > Ed Tomlinson > > > Zephaniah E. Hull. > > (The Debian developer who somehow got the 3Dfx issues, even under > > packages he does not maintain.) > > > > > Before I go through the pain of learning how to rebuild the > > > package(s), will it work with dri 1.0.0 at all? If so are you > > > planning .debs for 2.2.18? In any case if it will work with dri 1.0.0 > > > just what packages need to be rebuilt? Do you have pointers to docs > > > on just how to rebuild them? > > > > > > TIA, > > > Ed Tomlinson <[EMAIL PROTECTED]> > > > > > > BTW xf86cfg fails here. first it cannot detect my usb mouse correctly. > > > Once I fixed the symlink in /dev it failed to autodetect the protocol > > > needed. It did write enought of an XF86Config to get X started after > > > fixing the mouse up. Then, when started under X, it complained that the > > > cards DB was not found On irc I was advised to try dexter. Dexter > > > will not generate anything but an 3.3.6 version file for me... I did > > > get it all working (manually) but thought the above might help. > > > Content-Type: application/pgp-signature; charset="us-ascii"; > name="Attachment: 1" > Content-Transfer-Encoding: 7bit > Content-Description: > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[nveber@primusolutions.net: DGA problems in 4.0.1]
- Forwarded message from Norbert Veber <[EMAIL PROTECTED]> -
From: "Norbert Veber" <[EMAIL PROTECTED]>
To: Branden Robinson <[EMAIL PROTECTED]>
Subject: DGA problems in 4.0.1
Date: Sat, 25 Nov 2000 02:04:04 -0500
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
User-Agent: Mutt/1.2.5i
Hi,
I have a few programs that use DGA extentions such as xawtv, and vmware, but
they have stopped working as of 4.x. For example if I try to run xawtv, I
get:
This is xawtv-3.24, running on Linux/i686 (2.2.17)
visual: id=0x22 class=4 (TrueColor), depth=16
visual: id=0x23 class=4 (TrueColor), depth=16
x11: 1152x864, 16 bit/pixel, 0 byte/scanline
WARNING: No DGA support available for this display.
WARNING: couldn't find framebuffer base address, try manual
configuration ("v4l-conf -a ")
WARNING: No DGA support available for this display.
WARNING: couldn't find framebuffer base address, try manual
configuration ("v4l-conf -a ")
v4l: bttv version 0.7.46
v4l: 1152x864, 16 bit/pixel, 2304 byte/scanline
wmhooks: gnome
no infrared remote support available
ioctl VIDIOCCAPTURE: Invalid argument
ioctl VIDIOCCAPTURE: Invalid argument
The end result is that I get audio-only, and no picture from my tv tuner.
Vmware just pops up a box saying DGA is not available, and full screen mode
wont work.
My video card is a Tseng Labs ET6000 with 2mb video ram. The strange thing
is that it works fine on my debian machine at work. I am pretty much
stumped. The XF86Config-4 loads the "extmod" module which is supposed to
contain DGA support, I'm not sure where else to look.
Attached is my startx output, as well as my XF86Config-4 file.
Thanks for your time.
This is a pre-release version of XFree86, and is not supported in any
way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted
to [EMAIL PROTECTED] Before reporting bugs in pre-release versions,
please check the latest version in the XFree86 CVS repository
(http://www.XFree86.Org/cvs)
XFree86 Version 4.0.1e / X Window System
(protocol Version 11, revision 0, vendor release 6400)
Release Date: 6 November 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.18pre15 i686 [ELF]
Module Loader present
(==) Log file: "/var/log/XFree86.1.log", Time: Sat Nov 25 01:31:49 2000
(==) Using config file: "/etc/X11/XF86Config-4"
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (??) unknown.
(==) ServerLayout "Default Layout"
(**) |-->Screen "Default Screen" (0)
(**) | |-->Monitor "Generic Monitor"
(**) | |-->Device "Generic Graphics Device"
(**) |-->Input Device "Generic Keyboard"
(**) XKB: rules: "xfree86"
(**) XKB: model: "pc104"
(**) XKB: layout: "us"
(**) |-->Input Device "Generic Mouse"
(**) FontPath set to
"unix/:7100,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/100dpi/:unscaled,/usr/X11R6/lib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/misc/:unscaled,/usr/X11R6/lib/X11/fonts/cyrillic/:unscaled,/usr/X11R6/lib/X11/fonts/100dpi/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/cyrillic/,/usr/X11R6/lib/X11/fonts/freefont/,/usr/X11R6/lib/X11/fonts/sharefont/"
(==) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(==) ModulePath set to "/usr/X11R6/lib/modules"
(--) using VT number 8
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor="The XFree86 Project"
compiled for 4.0.1e, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor="The XFree86 Project"
compiled for 4.0.1e, module version = 0.1.0
(II) Loading /usr/X11R6/lib/modules/libscanpci.a
(II) Module scanpci: vendor="The XFree86 Project"
compiled for 4.0.1e, module version = 0.1.0
(II) Unloading /usr/X11R6/lib/modules/libscanpci.a
(--) PCI: (0:8:0) BrookTree unknown chipset (0x036e) rev 2, Mem @ 0xe7002000/12
(--) PCI:*(0:9:0) Tseng Labs ET6000/6100 rev 48, Mem @ 0xe400/24, I/O @ 0xe400/8
(II) Loading /usr/X11R6/lib/modules/libddc.a
(II) Module ddc: vendor="The XFree86 Project"
compiled for 4.0.1e, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a
(II) Module GLcore: vendor="The XFree86 Project"
compiled for 4.0.1e, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a
(II) Module dbe: vendor="The XFree86 Project"
compiled for 4.0.1e, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/extensions/libdri.a
(II) Module dri: vendor="The XFree86 Project"
compiled for 4.0.1e, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/linux/libdrm.a
(II) Module drm: vendor="The XFree86 Project
X server catching signal 11
This has actually been going on for a couple months. I've swapped out window manager and display manager, ditching gnome for the time being. As far as I can recall, stability was fine during -phase1. Hardware configuration: Dual P200mmx on a piix3 chipset(430HX), APICs enabled. Video: 00:0a.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro 215GP (rev 5c) 00:0b.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II] 128MB non-parity memory. Head 0 boots with atyfb because I do switch from X to work on the console. Kernel: Linux heathen 2.4.0-test10 #1 SMP Sat Nov 11 14:17:41 PST 2000 i586 unknown I'd like to supply some useful debugging information, but I'm not sure what would be considered useful and what wouldn't. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
