Re: [GATOS]how to check if hardware mpeg2 decoder is working
On Mon, 19 Jan 2004, MB wrote: >How does one check the version of the various items of software running on >one's Linux platform, like Xfree86 etc ? xdpyinfo gives the version of the running X server on the display that you are looking at, whereas "X -version" gives the version number of the X server 'installed' on the computer you have a shell on. If the X server and the shell on the computer are one and the same machine, these two versions generally will match unless you have some customized multiple X server installation or something else funky. Other commands may use commandline switches such as -version, --version, -v, -V, --help or similar. Check the documentation for a given command to see if it has a method to display it's version number. Most applications do, however there is no one method that works with all software. Hope this helps. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
On Mon, 19 Jan 2004, William M. Quarles wrote: >Also, I need to be a little more explicit as to how I have my file >structure setup. I never actually write the file as "radeon.o" in my >kernel modules tree, and I don't actually have a /usr/X11R6 directory. >I have a file named radeon-RH.o and a file named radeon-gatos.o, and >radeon.o is just a symbolic link to which ever driver that I am using. >Same thing with the X11R6 directory. So again nothing gets overwritten. >This also allows me to switch drivers, especially important since the >GATOS drivers have not been working very well for me. > >In order to switch drivers, I have exit my XFree86 session, rmmod >radeon, switch both symbolic links, and startx again. If I miss any of >these steps, it's not a matter of losing DRI, it's a matter of my >computer locking up, so I am fairly certain that I am using the GATOS >driver when I know that I am using the GATOS driver. AVview also works >when using the GATOS driver, but not when using the Red Hat driver. >However, since I'm sure my system is going to be doubted, I recompiled >and reinstalled the Radeon module and redumped the ATI.2 XFree86 >binaries, and saw no improvement. Instead of using symbolic links, you can install custom X modules in any other directory somewhere else, and use the ModulePath directive in the config file to override where the X server looks for modules first. Using multiple config files (or a single well crafted file), you can switch between drivers by using startx with commandline options. Hope this helps. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
Alex Deucher wrote: [snip this time the DRI was enabled: (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): [drm] dma control initialized, using IRQ 11 (II) RADEON(0): [drm] Initialized kernel agp heap manager, 5111808 (II) RADEON(0): Direct rendering enabled If glxinfo still shows indirect rendering, then I suspect you may have a problem with your copy of libGL. check to make sure you don't have multiple copies floating around. Use ldd to find out what version your apps are using. [snip] Alex, I can't have multiple copies floating around because I did a fresh install on a formatted partition. Also, rpm would have a hissy fit if I tried that. I checked which libGL is being used, and it is the same one that came along when I installed Red Hat Linux 9 on here. Perhaps there is some incompatibilty between the GATOS drivers and the libGL that came with Red Hat Linux 9. Do the GATOS drivers expect any particular version of libGL? Is there something besides the remap_page_range patch in the drivers' sources that I might need to patch? I'm going to write another message with a different subject asking if any other Red Hat Linux 9 users on the list have had problems, because we are way off the topic of DVD decoding now. Peace, William ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
--- "William M. Quarles" <[EMAIL PROTECTED]> wrote: > Alex Deucher wrote: > > > > try disabling fastwrites or pageflipping. > > Option "AGPFastWrite" "false" > > Option "EnablePageFlip" "false" > > Also make sure agpgart is loaded (kernel 2.4) or agpgart and the > agp > > chipset specific driver (kernel 2.6). > > > > Hi Alex, > > I'm using Red Hat kernel 2.4.20-28.9, but a custom build from their > kernel sources. > > The agpgart module is loaded. And the options brought the speed up a > > little in glxgears, but still definitely not hardware accelerated. > glxinfo still shows that DRI is disabled. > > [EMAIL PROTECTED] root]# lsmod > Module Size Used byNot tainted > radeon115396 1 > udf98016 0 (autoclean) > emu10k169064 0 > ac97_codec 14568 0 [emu10k1] > sound 74196 0 [emu10k1] > soundcore 6436 7 (autoclean) [emu10k1 sound] > mousedev5556 1 (autoclean) > input 5888 0 (autoclean) [mousedev] > agpgart23952 3 > parport_pc 19076 1 (autoclean) > lp 8996 0 (autoclean) > parport37056 1 (autoclean) [parport_pc lp] > autofs 13268 0 (autoclean) (unused) > tulip 43840 1 > ipt_REJECT 3992 6 (autoclean) > iptable_filter 2412 1 (autoclean) > ip_tables 15096 2 [ipt_REJECT iptable_filter] > sr_mod 18104 0 (autoclean) > nls_iso8859-1 3516 1 (autoclean) > nls_cp437 5148 1 (autoclean) > vfat 13036 1 (autoclean) > fat38808 0 (autoclean) [vfat] > isa-pnp40932 0 > acm 7840 0 > usb-uhci 26412 0 (unused) > usbcore79072 1 [acm usb-uhci] > [EMAIL PROTECTED] root]# glxgears > 530 frames in 5.0 seconds = 106.000 FPS > 353 frames in 5.0 seconds = 70.600 FPS > 423 frames in 5.0 seconds = 84.600 FPS > 423 frames in 5.0 seconds = 84.600 FPS > 423 frames in 5.0 seconds = 84.600 FPS > 423 frames in 5.0 seconds = 84.600 FPS > X connection to :0.0 broken (explicit kill or server shutdown). > [EMAIL PROTECTED] root]# glxinfo > name of display: :0.0 > display: :0 screen: 0 > direct rendering: No > > My XFree86 log is different now, I can't find the section where DRI > is > verbosely disabled, but maybe that is related to the options you > asked > me to add. It is attached. this time the DRI was enabled: (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): [drm] dma control initialized, using IRQ 11 (II) RADEON(0): [drm] Initialized kernel agp heap manager, 5111808 (II) RADEON(0): Direct rendering enabled If glxinfo still shows indirect rendering, then I suspect you may have a problem with your copy of libGL. check to make sure you don't have multiple copies floating around. Use ldd to find out what version your apps are using. Alex > > Thanks, > William > > [snip] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
William M. Quarles wrote: Alex Deucher wrote: try disabling fastwrites or pageflipping. Option "AGPFastWrite" "false" Option "EnablePageFlip" "false" Also make sure agpgart is loaded (kernel 2.4) or agpgart and the agp chipset specific driver (kernel 2.6). Hi Alex, I'm using Red Hat kernel 2.4.20-28.9, but a custom build from their kernel sources. The agpgart module is loaded. And the options brought the speed up a little in glxgears, but still definitely not hardware accelerated. glxinfo still shows that DRI is disabled. [EMAIL PROTECTED] root]# lsmod Module Size Used byNot tainted radeon115396 1 udf98016 0 (autoclean) emu10k169064 0 ac97_codec 14568 0 [emu10k1] sound 74196 0 [emu10k1] soundcore 6436 7 (autoclean) [emu10k1 sound] mousedev5556 1 (autoclean) input 5888 0 (autoclean) [mousedev] agpgart23952 3 parport_pc 19076 1 (autoclean) lp 8996 0 (autoclean) parport37056 1 (autoclean) [parport_pc lp] autofs 13268 0 (autoclean) (unused) tulip 43840 1 ipt_REJECT 3992 6 (autoclean) iptable_filter 2412 1 (autoclean) ip_tables 15096 2 [ipt_REJECT iptable_filter] sr_mod 18104 0 (autoclean) nls_iso8859-1 3516 1 (autoclean) nls_cp437 5148 1 (autoclean) vfat 13036 1 (autoclean) fat38808 0 (autoclean) [vfat] isa-pnp40932 0 acm 7840 0 usb-uhci 26412 0 (unused) usbcore79072 1 [acm usb-uhci] [EMAIL PROTECTED] root]# glxgears 530 frames in 5.0 seconds = 106.000 FPS 353 frames in 5.0 seconds = 70.600 FPS 423 frames in 5.0 seconds = 84.600 FPS 423 frames in 5.0 seconds = 84.600 FPS 423 frames in 5.0 seconds = 84.600 FPS 423 frames in 5.0 seconds = 84.600 FPS X connection to :0.0 broken (explicit kill or server shutdown). [EMAIL PROTECTED] root]# glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No My XFree86 log is different now, I can't find the section where DRI is verbosely disabled, but maybe that is related to the options you asked me to add. It is attached. Thanks, William Attached is the XFree86 log. How about changing the AGP bus speed? Add: Option "agpmode" "2" to the device config in your X config. Thanks, William [snip] (II) RADEON(0): [dri] RADEONDRISAREAInit. drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmGetBusid returned '' (II) RADEON(0): [drm] loaded kernel module for "radeon" driver (II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:0:0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0xd098e000 (II) RADEON(0): [drm] mapped SAREA 0xd098e000 to 0x40016000 (II) RADEON(0): [drm] framebuffer handle = 0xf000 (II) RADEON(0): [drm] added 1 reserved context for kernel (EE) RADEON(0): [dri] RADEONDRIScreenInit failed because of a version mismatch. [dri] radeon.o kernel module version is 1.7.0 but version 1.100.0 or newer is needed. [dri] Disabling DRI. (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xd098e000 at 0x40016000 It looks like either the DRM version check in the GATOS drivers is wrong, or you need a newer DRM. Alex __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Gatos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gatos-devel XFree86 Version 4.3.0 (Red Hat Linux 9 release: 4.3.0-2.90.43) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.21-2.ELsmp i686 [ELF] Build Date: 07 November 2003 Build Host: porky.devel.redhat.com Before reporting any problems, please make sure you are using the most recent XFree86 packages available from Red Hat by che
Re: [GATOS]how to check if hardware mpeg2 decoder is working
Vladimir Dergachev wrote: Why don't you try rmmod radeon driver and then insmod'ing the correct one ? On the off chance it would help. best Vladimir Dergachev Vladimir, I attached my XFree86 log in the message immediately preceding this one. I insmodded the Radeon module directly from the GATOS drm-kernel build directory. However, that was with the options that Alex suggested, so I attached a new log without those options (sans the AGP 2x option). The logfile seems to say that DRI is enabled, but if I run glxinfo (also attached), it says that DRI is disabled. Peace, William name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.3 Mesa 4.0.4 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 24 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x25 24 tc 0 24 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x26 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x27 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x28 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x29 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2a 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2b 24 dc 0 24 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2c 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2d 24 dc 0 24 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2e 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2f 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x30 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x31 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x32 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow XFree86 Version 4.3.0 (Red Hat Linux 9 release: 4.3.0-2.90.43) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.21-2.ELsmp i686 [ELF] Build Date: 07 November 2003 Build Host: porky.devel.redhat.com Before reporting any problems, please make sure you are using the most recent XFree86 packages available from Red Hat by checking for updates at http://rhn.redhat.com/errata or by using the Red Hat Network up2date tool. If you still encounter problems, please file bug reports in the XFree86.org bugzilla at http://bugs.xfree86.org and/or Red Hat bugzilla at http://bugzilla.redhat.com Module Loader present OS Kernel: Linux version 2.4.20-28.9pent3 ([EMAIL PROTECTED]) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #2 Tue Jan 13 19:47:25 EST 2004 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Mon Jan 19 22:38:25 2004 (==) Using config file: "/etc/X11/XF86Config" (==) ServerLayout "Default Layout" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Videocard0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "us" (**) XKB: layout: "us" (==) Keyboard: CustomKeycode disabled (**) |-->Input Device "DevInputMice" (**) FontPath set to "unix/:7100" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video
Re: [GATOS]how to check if hardware mpeg2 decoder is working
Alex Deucher wrote: try disabling fastwrites or pageflipping. Option "AGPFastWrite" "false" Option "EnablePageFlip" "false" Also make sure agpgart is loaded (kernel 2.4) or agpgart and the agp chipset specific driver (kernel 2.6). Hi Alex, I'm using Red Hat kernel 2.4.20-28.9, but a custom build from their kernel sources. The agpgart module is loaded. And the options brought the speed up a little in glxgears, but still definitely not hardware accelerated. glxinfo still shows that DRI is disabled. [EMAIL PROTECTED] root]# lsmod Module Size Used byNot tainted radeon115396 1 udf98016 0 (autoclean) emu10k169064 0 ac97_codec 14568 0 [emu10k1] sound 74196 0 [emu10k1] soundcore 6436 7 (autoclean) [emu10k1 sound] mousedev5556 1 (autoclean) input 5888 0 (autoclean) [mousedev] agpgart23952 3 parport_pc 19076 1 (autoclean) lp 8996 0 (autoclean) parport37056 1 (autoclean) [parport_pc lp] autofs 13268 0 (autoclean) (unused) tulip 43840 1 ipt_REJECT 3992 6 (autoclean) iptable_filter 2412 1 (autoclean) ip_tables 15096 2 [ipt_REJECT iptable_filter] sr_mod 18104 0 (autoclean) nls_iso8859-1 3516 1 (autoclean) nls_cp437 5148 1 (autoclean) vfat 13036 1 (autoclean) fat38808 0 (autoclean) [vfat] isa-pnp40932 0 acm 7840 0 usb-uhci 26412 0 (unused) usbcore79072 1 [acm usb-uhci] [EMAIL PROTECTED] root]# glxgears 530 frames in 5.0 seconds = 106.000 FPS 353 frames in 5.0 seconds = 70.600 FPS 423 frames in 5.0 seconds = 84.600 FPS 423 frames in 5.0 seconds = 84.600 FPS 423 frames in 5.0 seconds = 84.600 FPS 423 frames in 5.0 seconds = 84.600 FPS X connection to :0.0 broken (explicit kill or server shutdown). [EMAIL PROTECTED] root]# glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No My XFree86 log is different now, I can't find the section where DRI is verbosely disabled, but maybe that is related to the options you asked me to add. It is attached. Thanks, William Attached is the XFree86 log. How about changing the AGP bus speed? Add: Option "agpmode" "2" to the device config in your X config. Thanks, William [snip] (II) RADEON(0): [dri] RADEONDRISAREAInit. drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmGetBusid returned '' (II) RADEON(0): [drm] loaded kernel module for "radeon" driver (II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:0:0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0xd098e000 (II) RADEON(0): [drm] mapped SAREA 0xd098e000 to 0x40016000 (II) RADEON(0): [drm] framebuffer handle = 0xf000 (II) RADEON(0): [drm] added 1 reserved context for kernel (EE) RADEON(0): [dri] RADEONDRIScreenInit failed because of a version mismatch. [dri] radeon.o kernel module version is 1.7.0 but version 1.100.0 or newer is needed. [dri] Disabling DRI. (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xd098e000 at 0x40016000 It looks like either the DRM version check in the GATOS drivers is wrong, or you need a newer DRM. Alex __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Gatos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gatos-devel XFree86 Version 4.3.0 (Red Hat Linux 9 release: 4.3.0-2.90.43) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.21-2.ELsmp i686 [ELF] Build Date: 07 November 2003 Build Host: porky.devel.redhat.com Before reporting any problems, please make sure you are using the most recent XFree86 packages available from Red Hat by checking for updates at http://rhn.redhat.com/errata or by using the Red Hat Network up2date
Re: [GATOS]how to check if hardware mpeg2 decoder is working
How does one check the version of the various items of software running on one's Linux platform, like Xfree86 etc ? MB - Original Message - From: "Vladimir Dergachev" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Michel DÃnzer" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Francesco" <[EMAIL PROTECTED]>; "Christopher Crawford" <[EMAIL PROTECTED]>; "Dan Huber" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, January 19, 2004 3:01 PM Subject: Re: [GATOS]how to check if hardware mpeg2 decoder is working On Mon, 19 Jan 2004, William M. Quarles wrote: > Michel DÃnzer wrote: > > On Mon, 2004-01-19 at 19:00, William M. Quarles wrote: > > > >>(EE) RADEON(0): [dri] RADEONDRIScreenInit failed because of a version mismatch. > >>[dri] radeon.o kernel module version is 1.7.0 but version 1.100.0 or newer is needed. > > > > > > (BTW, this isn't correct, the major should have been bumped) > > > > > >>[dri] Disabling DRI. > > > > > > You need the DRM from GATOS as well. > > > > > > I installed the files from the ATI-4.3.0-14.i386 tarball into my X11R6 > tree, and I compiled the radeon.o module file from the drm-kernel > tarball and put it in the appropriate place in my modules tree. What > else do I need to do? Most likely you have another radeon.o file, leftover from previous installation. Try: find /lib/modules -name radeon.o -print and see whether everything is like you think it is. Also, the new driver that you compiled might have been overwritten if you recompiled your kernel in the process. best Vladimir Dergachev > > Also, I'm not sure how the XFree86 logging works, but if that log file > maintains multiple sessions, you might be looking at one where my > computer ended up hanging. > > I still could us a hand with changing my AGP bus speed. > > Thanks, > William > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Gatos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gatos-devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
Thanks for the info, Alex! Alex Deucher wrote: --- "William M. Quarles" <[EMAIL PROTECTED]> wrote: Attached are the two glxinfo outputs. They are in fact different. The Red Hat one is still a bit disappointing because it says that my card is only running at 1x. Does anybody know how to get it going at 2x? Add: option "agpmode" "2x" to the device section of your config. Thanks, William name of display: :0.0 display: :0 screen: 0 direct rendering: Yes [snip] OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI Radeon 20020611 AGP 1x x86/MMX/SSE TCL OpenGL version string: 1.2 Mesa 4.0.4 You are using 3D acceleration here. [snip] direct rendering: No [snip] OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect ^ OpenGL version string: 1.3 Mesa 4.0.4 Here you are using software acceleration. that would explain the differences in speed. Alex ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
> Everything is exactly where it is supposed to be. > > Every kernel build that I do I put a different tag on the end of the > version number, and every build is done in a separate directory. > Nothing gets overwritten. However, I only have one custom kernel build > that I use. The other builds are two Red Hat RPM-installed kernels, and > one standard Linux kernel build that I did as part of this > troubleshooting process. As noted earlier, using that build did not > produce results that were any different. The standard Linux Radeon > driver supported DRI, the GATOS one did not on my computer. > > Also, I need to be a little more explicit as to how I have my file > structure setup. I never actually write the file as "radeon.o" in my > kernel modules tree, and I don't actually have a /usr/X11R6 directory. > I have a file named radeon-RH.o and a file named radeon-gatos.o, and > radeon.o is just a symbolic link to which ever driver that I am using. > Same thing with the X11R6 directory. So again nothing gets overwritten. > This also allows me to switch drivers, especially important since the > GATOS drivers have not been working very well for me. > > In order to switch drivers, I have exit my XFree86 session, rmmod > radeon, switch both symbolic links, and startx again. If I miss any of > these steps, it's not a matter of losing DRI, it's a matter of my > computer locking up, so I am fairly certain that I am using the GATOS > driver when I know that I am using the GATOS driver. AVview also works > when using the GATOS driver, but not when using the Red Hat driver. > However, since I'm sure my system is going to be doubted, I recompiled > and reinstalled the Radeon module and redumped the ATI.2 XFree86 > binaries, and saw no improvement. Why don't you try rmmod radeon driver and then insmod'ing the correct one ? On the off chance it would help. best Vladimir Dergachev > > Peace, > William > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
Vladimir Dergachev wrote: On Mon, 19 Jan 2004, William M. Quarles wrote: Michel DÃnzer wrote: On Mon, 2004-01-19 at 19:00, William M. Quarles wrote: (EE) RADEON(0): [dri] RADEONDRIScreenInit failed because of a version mismatch. [dri] radeon.o kernel module version is 1.7.0 but version 1.100.0 or newer is needed. (BTW, this isn't correct, the major should have been bumped) [dri] Disabling DRI. You need the DRM from GATOS as well. I installed the files from the ATI-4.3.0-14.i386 tarball into my X11R6 tree, and I compiled the radeon.o module file from the drm-kernel tarball and put it in the appropriate place in my modules tree. What else do I need to do? Most likely you have another radeon.o file, leftover from previous installation. Try: find /lib/modules -name radeon.o -print and see whether everything is like you think it is. Also, the new driver that you compiled might have been overwritten if you recompiled your kernel in the process. best Vladimir Dergachev Everything is exactly where it is supposed to be. Every kernel build that I do I put a different tag on the end of the version number, and every build is done in a separate directory. Nothing gets overwritten. However, I only have one custom kernel build that I use. The other builds are two Red Hat RPM-installed kernels, and one standard Linux kernel build that I did as part of this troubleshooting process. As noted earlier, using that build did not produce results that were any different. The standard Linux Radeon driver supported DRI, the GATOS one did not on my computer. Also, I need to be a little more explicit as to how I have my file structure setup. I never actually write the file as "radeon.o" in my kernel modules tree, and I don't actually have a /usr/X11R6 directory. I have a file named radeon-RH.o and a file named radeon-gatos.o, and radeon.o is just a symbolic link to which ever driver that I am using. Same thing with the X11R6 directory. So again nothing gets overwritten. This also allows me to switch drivers, especially important since the GATOS drivers have not been working very well for me. In order to switch drivers, I have exit my XFree86 session, rmmod radeon, switch both symbolic links, and startx again. If I miss any of these steps, it's not a matter of losing DRI, it's a matter of my computer locking up, so I am fairly certain that I am using the GATOS driver when I know that I am using the GATOS driver. AVview also works when using the GATOS driver, but not when using the Red Hat driver. However, since I'm sure my system is going to be doubted, I recompiled and reinstalled the Radeon module and redumped the ATI.2 XFree86 binaries, and saw no improvement. Peace, William ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
On Mon, 19 Jan 2004, William M. Quarles wrote: > Michel DÃnzer wrote: > > On Mon, 2004-01-19 at 19:00, William M. Quarles wrote: > > > >>(EE) RADEON(0): [dri] RADEONDRIScreenInit failed because of a version mismatch. > >>[dri] radeon.o kernel module version is 1.7.0 but version 1.100.0 or newer is > >>needed. > > > > > > (BTW, this isn't correct, the major should have been bumped) > > > > > >>[dri] Disabling DRI. > > > > > > You need the DRM from GATOS as well. > > > > > > I installed the files from the ATI-4.3.0-14.i386 tarball into my X11R6 > tree, and I compiled the radeon.o module file from the drm-kernel > tarball and put it in the appropriate place in my modules tree. What > else do I need to do? Most likely you have another radeon.o file, leftover from previous installation. Try: find /lib/modules -name radeon.o -print and see whether everything is like you think it is. Also, the new driver that you compiled might have been overwritten if you recompiled your kernel in the process. best Vladimir Dergachev > > Also, I'm not sure how the XFree86 logging works, but if that log file > maintains multiple sessions, you might be looking at one where my > computer ended up hanging. > > I still could us a hand with changing my AGP bus speed. > > Thanks, > William > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
Michel DÃnzer wrote: On Mon, 2004-01-19 at 19:00, William M. Quarles wrote: (EE) RADEON(0): [dri] RADEONDRIScreenInit failed because of a version mismatch. [dri] radeon.o kernel module version is 1.7.0 but version 1.100.0 or newer is needed. (BTW, this isn't correct, the major should have been bumped) [dri] Disabling DRI. You need the DRM from GATOS as well. I installed the files from the ATI-4.3.0-14.i386 tarball into my X11R6 tree, and I compiled the radeon.o module file from the drm-kernel tarball and put it in the appropriate place in my modules tree. What else do I need to do? Also, I'm not sure how the XFree86 logging works, but if that log file maintains multiple sessions, you might be looking at one where my computer ended up hanging. I still could us a hand with changing my AGP bus speed. Thanks, William ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
--- "William M. Quarles" <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > On Mon, Jan 19, 2004 at 12:59:25AM -0500, William M. Quarles wrote: > > [RH] > > > >>name of display: :0.0 > >>display: :0 screen: 0 > >>direct rendering: Yes > > > > > > [Gatos] > > > >>name of display: :0.0 > >>display: :0 screen: 0 > >>direct rendering: No > > > > > > No hardware acceleration at all. Is the DRM kernel module loaded? > If so, > > how about XFree log from the gatos case? > > > > R C > > > > The DRM kernel module loads automatically, and the system shows it as > in > use. In either case, if the wrong module is loaded, my system hangs, > so > it has to be doing something. try disabling fastwrites or pageflipping. Option "AGPFastWrite" "false" Option "EnablePageFlip" "false" Also make sure agpgart is loaded (kernel 2.4) or agpgart and the agp chipset specific driver (kernel 2.6). > Attached is the XFree86 log. > How about changing the AGP bus speed? Add: Option "agpmode" "2" to the device config in your X config. > > Thanks, > William > > [snip] > (II) RADEON(0): [dri] RADEONDRISAREAInit. > drmOpenDevice: minor is 0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is -1, (No such device) > drmOpenDevice: open result is -1, (No such device) > drmOpenDevice: Open failed > drmOpenDevice: minor is 0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is -1, (No such device) > drmOpenDevice: open result is -1, (No such device) > drmOpenDevice: Open failed > drmOpenDevice: minor is 0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 7, (OK) > drmGetBusid returned '' > (II) RADEON(0): [drm] loaded kernel module for "radeon" driver > (II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:0:0" > (II) RADEON(0): [drm] added 8192 byte SAREA at 0xd098e000 > (II) RADEON(0): [drm] mapped SAREA 0xd098e000 to 0x40016000 > (II) RADEON(0): [drm] framebuffer handle = 0xf000 > (II) RADEON(0): [drm] added 1 reserved context for kernel > (EE) RADEON(0): [dri] RADEONDRIScreenInit failed because of a version > mismatch. > [dri] radeon.o kernel module version is 1.7.0 but version 1.100.0 or > newer is needed. > [dri] Disabling DRI. > (II) RADEON(0): [drm] removed 1 reserved context for kernel > (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xd098e000 at > 0x40016000 It looks like either the DRM version check in the GATOS drivers is wrong, or you need a newer DRM. Alex __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
On Mon, 2004-01-19 at 19:00, William M. Quarles wrote: > > (EE) RADEON(0): [dri] RADEONDRIScreenInit failed because of a version mismatch. > [dri] radeon.o kernel module version is 1.7.0 but version 1.100.0 or newer is needed. (BTW, this isn't correct, the major should have been bumped) > [dri] Disabling DRI. You need the DRM from GATOS as well. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
[EMAIL PROTECTED] wrote: On Mon, Jan 19, 2004 at 12:59:25AM -0500, William M. Quarles wrote: [RH] name of display: :0.0 display: :0 screen: 0 direct rendering: Yes [Gatos] name of display: :0.0 display: :0 screen: 0 direct rendering: No No hardware acceleration at all. Is the DRM kernel module loaded? If so, how about XFree log from the gatos case? R C The DRM kernel module loads automatically, and the system shows it as in use. In either case, if the wrong module is loaded, my system hangs, so it has to be doing something. Attached is the XFree86 log. How about changing the AGP bus speed? Thanks, William XFree86 Version 4.3.0 (Red Hat Linux 9 release: 4.3.0-2.90.43) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.21-2.ELsmp i686 [ELF] Build Date: 07 November 2003 Build Host: porky.devel.redhat.com Before reporting any problems, please make sure you are using the most recent XFree86 packages available from Red Hat by checking for updates at http://rhn.redhat.com/errata or by using the Red Hat Network up2date tool. If you still encounter problems, please file bug reports in the XFree86.org bugzilla at http://bugs.xfree86.org and/or Red Hat bugzilla at http://bugzilla.redhat.com Module Loader present OS Kernel: Linux version 2.4.20-28.9pent3 ([EMAIL PROTECTED]) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #2 Tue Jan 13 19:47:25 EST 2004 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Mon Jan 19 12:53:20 2004 (==) Using config file: "/etc/X11/XF86Config" (==) ServerLayout "Default Layout" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Videocard0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "us" (**) XKB: layout: "us" (==) Keyboard: CustomKeycode disabled (**) |-->Input Device "DevInputMice" (**) FontPath set to "unix/:7100" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (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.3.0, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (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.3.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,7190 card , rev 03 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,7191 card , rev 03 class 06,04,00 hdr 01 (II) PCI: 00:07:0: chip 8086,7110 card , rev 02 class 06,01,00 hdr 80 (II) PCI: 00:07:1: chip 8086,7111 card , rev 01 class 01,01,80 hdr 00 (II) PCI: 00:07:2: chip 8086,7112 card , rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:07:3: chip 8086,7113 card , rev 02 class 06,80,00 hdr 00 (II) PCI: 00:0d:0: chip 1102,0002 card 1102,8064 rev 0a class 04,01,00 hdr 80 (II) PCI: 00:0d:1: chip 1102,7002 card 1102,0020 rev 0a class 09,80,00 hdr 80 (II) PCI: 00:0e:0: chip 11ad,c115 card 11ad,c001 rev 25 class 02,00,00 hdr 00 (II) PCI: 00:0f:0: chip 105a,4d68 card 105a,4d68 rev 02 class 01,80,85 hdr 00 (II) PCI: 01:00:0: chip 1002,5144 card 1002,02aa rev 00 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x008c (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0x9000 - 0x90ff (0x100) IX[B] [1] -1 0 0x9400 - 0x94ff (0x100) IX[B] [2] -1 0 0x9800 - 0x98ff (0x100) IX[B] [3] -1 0 0x9c00 - 0x
Re: [GATOS]how to check if hardware mpeg2 decoder is working
--- "William M. Quarles" <[EMAIL PROTECTED]> wrote: > Vladimir Dergachev wrote: [snip] > > > > Is this fullscreen or in the default window ? If the latter, than > this > > speed is indicative of no acceleration at all - what does glxinfo > > tell you ? > > > >best > > > > Vladimir Dergachev > > > > > >>Pentium III 1.1 GHz (100 Mhz FSB), 256 MB ECC SDRAM, ATI All-In > Wonder > >>Radeon AGP running at 2x, 1024x768 24 bpp. > >> > >>Peace, > >>William > >> > > Attached are the two glxinfo outputs. They are in fact different. > The > Red Hat one is still a bit disappointing because it says that my card > is > only running at 1x. Does anybody know how to get it going at 2x? > Add: option "agpmode" "2x" to the device section of your config. > Thanks, > William > > name of display: :0.0 > display: :0 screen: 0 > direct rendering: Yes [snip] > OpenGL vendor string: Tungsten Graphics, Inc. > OpenGL renderer string: Mesa DRI Radeon 20020611 AGP 1x x86/MMX/SSE > TCL > OpenGL version string: 1.2 Mesa 4.0.4 You are using 3D acceleration here. [snip] > direct rendering: No [snip] > OpenGL vendor string: Mesa project: www.mesa3d.org > OpenGL renderer string: Mesa GLX Indirect ^ > OpenGL version string: 1.3 Mesa 4.0.4 Here you are using software acceleration. that would explain the differences in speed. Alex __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
On Mon, Jan 19, 2004 at 12:59:25AM -0500, William M. Quarles wrote: [RH] > name of display: :0.0 > display: :0 screen: 0 > direct rendering: Yes [Gatos] > name of display: :0.0 > display: :0 screen: 0 > direct rendering: No No hardware acceleration at all. Is the DRM kernel module loaded? If so, how about XFree log from the gatos case? R C ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
Vladimir Dergachev wrote: Well, then my results are too low too. I have X4.3 w ati.2 @[EMAIL PROTECTED] kernel 2.4.23 and I only get ~1400 FPS with glxgears My system is AthlonXP [EMAIL PROTECTED] + Radeon 8500LE How do I check if I have this problem with AGP bandwidth? Are you guys multiplying by 10 or is my hardware just a whole lot slower? With the GATOS drivers, I'm getting around 170 fps. With the Red Hat drivers, I'm getting around 798 fps. So there is definitely more than a significant slow-down in the GATOS drivers. Is this fullscreen or in the default window ? If the latter, than this speed is indicative of no acceleration at all - what does glxinfo tell you ? best Vladimir Dergachev Pentium III 1.1 GHz (100 Mhz FSB), 256 MB ECC SDRAM, ATI All-In Wonder Radeon AGP running at 2x, 1024x768 24 bpp. Peace, William Attached are the two glxinfo outputs. They are in fact different. The Red Hat one is still a bit disappointing because it says that my card is only running at 1x. Does anybody know how to get it going at 2x? Thanks, William name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI Radeon 20020611 AGP 1x x86/MMX/SSE TCL OpenGL version string: 1.2 Mesa 4.0.4 OpenGL extensions: GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_convolution, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 24 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x25 24 tc 0 24 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x26 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x27 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x28 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x29 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2a 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2b 24 dc 0 24 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2c 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2d 24 dc 0 24 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2e 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2f 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x30 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x31 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x32 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.3 Mesa 4.0.4 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
Re: [GATOS]how to check if hardware mpeg2 decoder is working
> >> > > Well, then my results are too low too. I have X4.3 w ati.2 > > @[EMAIL PROTECTED] kernel 2.4.23 and I only get ~1400 FPS with glxgears > > My system is AthlonXP [EMAIL PROTECTED] + Radeon 8500LE > > > > How do I check if I have this problem with AGP bandwidth? > > > > > Are you guys multiplying by 10 or is my hardware just a whole lot slower? > > With the GATOS drivers, I'm getting around 170 fps. With the Red Hat > drivers, I'm getting around 798 fps. So there is definitely more than a > significant slow-down in the GATOS drivers. Is this fullscreen or in the default window ? If the latter, than this speed is indicative of no acceleration at all - what does glxinfo tell you ? best Vladimir Dergachev > > Pentium III 1.1 GHz (100 Mhz FSB), 256 MB ECC SDRAM, ATI All-In Wonder > Radeon AGP running at 2x, 1024x768 24 bpp. > > Peace, > William > > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
Francesco wrote: Christopher Crawford wrote: William M. Quarles wrote: William M. Quarles wrote: Vladimir Dergachev wrote: -the AGP bandwidth problems are not an XFree86 bug, but are a GATOS bug, right? Because I only have problems with display speed when using the GATOS drivers. -I've got a Pentium III, so it is not just an Athlon/Duron problem. No, GATOS code does not mess with AGP or mtrr. There was some issue with mtrr settings - whereby the framebuffer region was not properly marked, this manifested (due to different causes) with both Athlons and Pentiums. I don't remember the details.. However, I would have expected that this has been fixed in new kernels. best Vladimir Dergachev There was an issue with Athlon/Duron AGP bandwidth issues that arose in Xfree 4.3.0, and was unaffected by GATOS drivers. A later kernel update made it a bit better, but I do still get better xv throughput on my PCI Rage128 card, than my AGP(4x) Radeon8500 card. The AGP bandwidth issue affects only Athlon systems using older <=266 MHz chipsetsmade by Via, and does not affect DRI bandwidth. It sounds as if your problem is something different. If remember right the problem was that AGP space and framebuffer space could both be referenced by CPU in more than one way. It had something to do with O_SYNC flag being added when opening /dev/mem which effectively turned off mtrr settings. The problem was first noticed on Athlons, but then a similar effect was noticed with Pentiums. XFree86 4.2.0 does not exhibit this problem because (AFAIK.. ) it did not use O_SYNC flag when opening /dev/mem. My understanding is that with O_SYNC flag we describe two kinds of behaviour: when data is written right away and when the write can be delayed by the kernel. However, with mttr the meaning of "written right away" splits in two parts "written right away, even a single byte" (used for access to registers) and "written right away, grouped into blocks for fast transfer" (used for access to framebuffer memory). Note that grouping into blocks is done by the hardware, not the kernel. So, when XFree86 4.3.0 uses O_SYNC flag to open /dev/mem l-k sets mtrr to "written right away, even a single byte" and direct writes to framebuffer (as needed for transfer of Xv images) become a lot slower. Now that I have written all this it occurred to me that I too seen some slowdown after installing GATOS drivers. It might be that whatever workaround is employed breaks when GATOS reprograms the memory controller on Radeons. Now how this could happen I have no idea, as Radeon memory controller is completely separate from mtrr. Could someone correct me please ? (CC'd to [EMAIL PROTECTED]) best Vladimir Dergachev I noticed the slowdown most profoundly on this 3D game called Chromium. It acts like I'm not getting acceleration. DVD playback was also a bit finicky. I'm using an ATI All-In-Wonder Radeon. Then again, I'm also using the Red Hat kernel. Although this kernel variant generally performs better because of low latency patches and 2.6 DRM, may not be 100% GATOS friendly. I'll try the latest standard 2.4 kernel and report. Peace, William I tried the standard Linux kernel with the GATOS drivers, and there was no improvement in graphics performance over using the Red Hat kernel and the GATOS drivers. 2D graphics are slow, 3D graphics are ridiculously slower. The drivers included with the kernel packages work much better. Something is definitely wrong with the GATOS drivers for XFree86 4.3. Peace, William What frame rate do you get from glxgears?? Please include resolution and color depth. I get 2400fps (default) with X4.3 w/ati.2 @ [EMAIL PROTECTED] [EMAIL PROTECTED]@24bpp. AthonXP 1700+ w/512MB DDR & 4x AGP AiW Radeon8500DV Well, then my results are too low too. I have X4.3 w ati.2 @[EMAIL PROTECTED] kernel 2.4.23 and I only get ~1400 FPS with glxgears My system is AthlonXP [EMAIL PROTECTED] + Radeon 8500LE How do I check if I have this problem with AGP bandwidth? Are you guys multiplying by 10 or is my hardware just a whole lot slower? With the GATOS drivers, I'm getting around 170 fps. With the Red Hat drivers, I'm getting around 798 fps. So there is definitely more than a significant slow-down in the GATOS drivers. Pentium III 1.1 GHz (100 Mhz FSB), 256 MB ECC SDRAM, ATI All-In Wonder Radeon AGP running at 2x, 1024x768 24 bpp. Peace, William ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
Christopher Crawford wrote: William M. Quarles wrote: William M. Quarles wrote: Vladimir Dergachev wrote: -the AGP bandwidth problems are not an XFree86 bug, but are a GATOS bug, right? Because I only have problems with display speed when using the GATOS drivers. -I've got a Pentium III, so it is not just an Athlon/Duron problem. No, GATOS code does not mess with AGP or mtrr. There was some issue with mtrr settings - whereby the framebuffer region was not properly marked, this manifested (due to different causes) with both Athlons and Pentiums. I don't remember the details.. However, I would have expected that this has been fixed in new kernels. best Vladimir Dergachev There was an issue with Athlon/Duron AGP bandwidth issues that arose in Xfree 4.3.0, and was unaffected by GATOS drivers. A later kernel update made it a bit better, but I do still get better xv throughput on my PCI Rage128 card, than my AGP(4x) Radeon8500 card. The AGP bandwidth issue affects only Athlon systems using older <=266 MHz chipsetsmade by Via, and does not affect DRI bandwidth. It sounds as if your problem is something different. If remember right the problem was that AGP space and framebuffer space could both be referenced by CPU in more than one way. It had something to do with O_SYNC flag being added when opening /dev/mem which effectively turned off mtrr settings. The problem was first noticed on Athlons, but then a similar effect was noticed with Pentiums. XFree86 4.2.0 does not exhibit this problem because (AFAIK.. ) it did not use O_SYNC flag when opening /dev/mem. My understanding is that with O_SYNC flag we describe two kinds of behaviour: when data is written right away and when the write can be delayed by the kernel. However, with mttr the meaning of "written right away" splits in two parts "written right away, even a single byte" (used for access to registers) and "written right away, grouped into blocks for fast transfer" (used for access to framebuffer memory). Note that grouping into blocks is done by the hardware, not the kernel. So, when XFree86 4.3.0 uses O_SYNC flag to open /dev/mem l-k sets mtrr to "written right away, even a single byte" and direct writes to framebuffer (as needed for transfer of Xv images) become a lot slower. Now that I have written all this it occurred to me that I too seen some slowdown after installing GATOS drivers. It might be that whatever workaround is employed breaks when GATOS reprograms the memory controller on Radeons. Now how this could happen I have no idea, as Radeon memory controller is completely separate from mtrr. Could someone correct me please ? (CC'd to [EMAIL PROTECTED]) best Vladimir Dergachev I noticed the slowdown most profoundly on this 3D game called Chromium. It acts like I'm not getting acceleration. DVD playback was also a bit finicky. I'm using an ATI All-In-Wonder Radeon. Then again, I'm also using the Red Hat kernel. Although this kernel variant generally performs better because of low latency patches and 2.6 DRM, may not be 100% GATOS friendly. I'll try the latest standard 2.4 kernel and report. Peace, William I tried the standard Linux kernel with the GATOS drivers, and there was no improvement in graphics performance over using the Red Hat kernel and the GATOS drivers. 2D graphics are slow, 3D graphics are ridiculously slower. The drivers included with the kernel packages work much better. Something is definitely wrong with the GATOS drivers for XFree86 4.3. Peace, William What frame rate do you get from glxgears?? Please include resolution and color depth. I get 2400fps (default) with X4.3 w/ati.2 @ [EMAIL PROTECTED] [EMAIL PROTECTED]@24bpp. AthonXP 1700+ w/512MB DDR & 4x AGP AiW Radeon8500DV Well, then my results are too low too. I have X4.3 w ati.2 @[EMAIL PROTECTED] kernel 2.4.23 and I only get ~1400 FPS with glxgears My system is AthlonXP [EMAIL PROTECTED] + Radeon 8500LE How do I check if I have this problem with AGP bandwidth? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
William M. Quarles wrote: William M. Quarles wrote: Vladimir Dergachev wrote: -the AGP bandwidth problems are not an XFree86 bug, but are a GATOS bug, right? Because I only have problems with display speed when using the GATOS drivers. -I've got a Pentium III, so it is not just an Athlon/Duron problem. No, GATOS code does not mess with AGP or mtrr. There was some issue with mtrr settings - whereby the framebuffer region was not properly marked, this manifested (due to different causes) with both Athlons and Pentiums. I don't remember the details.. However, I would have expected that this has been fixed in new kernels. best Vladimir Dergachev There was an issue with Athlon/Duron AGP bandwidth issues that arose in Xfree 4.3.0, and was unaffected by GATOS drivers. A later kernel update made it a bit better, but I do still get better xv throughput on my PCI Rage128 card, than my AGP(4x) Radeon8500 card. The AGP bandwidth issue affects only Athlon systems using older <=266 MHz chipsetsmade by Via, and does not affect DRI bandwidth. It sounds as if your problem is something different. If remember right the problem was that AGP space and framebuffer space could both be referenced by CPU in more than one way. It had something to do with O_SYNC flag being added when opening /dev/mem which effectively turned off mtrr settings. The problem was first noticed on Athlons, but then a similar effect was noticed with Pentiums. XFree86 4.2.0 does not exhibit this problem because (AFAIK.. ) it did not use O_SYNC flag when opening /dev/mem. My understanding is that with O_SYNC flag we describe two kinds of behaviour: when data is written right away and when the write can be delayed by the kernel. However, with mttr the meaning of "written right away" splits in two parts "written right away, even a single byte" (used for access to registers) and "written right away, grouped into blocks for fast transfer" (used for access to framebuffer memory). Note that grouping into blocks is done by the hardware, not the kernel. So, when XFree86 4.3.0 uses O_SYNC flag to open /dev/mem l-k sets mtrr to "written right away, even a single byte" and direct writes to framebuffer (as needed for transfer of Xv images) become a lot slower. Now that I have written all this it occurred to me that I too seen some slowdown after installing GATOS drivers. It might be that whatever workaround is employed breaks when GATOS reprograms the memory controller on Radeons. Now how this could happen I have no idea, as Radeon memory controller is completely separate from mtrr. Could someone correct me please ? (CC'd to [EMAIL PROTECTED]) best Vladimir Dergachev I noticed the slowdown most profoundly on this 3D game called Chromium. It acts like I'm not getting acceleration. DVD playback was also a bit finicky. I'm using an ATI All-In-Wonder Radeon. Then again, I'm also using the Red Hat kernel. Although this kernel variant generally performs better because of low latency patches and 2.6 DRM, may not be 100% GATOS friendly. I'll try the latest standard 2.4 kernel and report. Peace, William I tried the standard Linux kernel with the GATOS drivers, and there was no improvement in graphics performance over using the Red Hat kernel and the GATOS drivers. 2D graphics are slow, 3D graphics are ridiculously slower. The drivers included with the kernel packages work much better. Something is definitely wrong with the GATOS drivers for XFree86 4.3. Peace, William What frame rate do you get from glxgears?? Please include resolution and color depth. I get 2400fps (default) with X4.3 w/ati.2 @ [EMAIL PROTECTED] [EMAIL PROTECTED]@24bpp. AthonXP 1700+ w/512MB DDR & 4x AGP AiW Radeon8500DV --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Gatos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gatos-devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
William M. Quarles wrote: Vladimir Dergachev wrote: -the AGP bandwidth problems are not an XFree86 bug, but are a GATOS bug, right? Because I only have problems with display speed when using the GATOS drivers. -I've got a Pentium III, so it is not just an Athlon/Duron problem. No, GATOS code does not mess with AGP or mtrr. There was some issue with mtrr settings - whereby the framebuffer region was not properly marked, this manifested (due to different causes) with both Athlons and Pentiums. I don't remember the details.. However, I would have expected that this has been fixed in new kernels. best Vladimir Dergachev There was an issue with Athlon/Duron AGP bandwidth issues that arose in Xfree 4.3.0, and was unaffected by GATOS drivers. A later kernel update made it a bit better, but I do still get better xv throughput on my PCI Rage128 card, than my AGP(4x) Radeon8500 card. The AGP bandwidth issue affects only Athlon systems using older <=266 MHz chipsetsmade by Via, and does not affect DRI bandwidth. It sounds as if your problem is something different. If remember right the problem was that AGP space and framebuffer space could both be referenced by CPU in more than one way. It had something to do with O_SYNC flag being added when opening /dev/mem which effectively turned off mtrr settings. The problem was first noticed on Athlons, but then a similar effect was noticed with Pentiums. XFree86 4.2.0 does not exhibit this problem because (AFAIK.. ) it did not use O_SYNC flag when opening /dev/mem. My understanding is that with O_SYNC flag we describe two kinds of behaviour: when data is written right away and when the write can be delayed by the kernel. However, with mttr the meaning of "written right away" splits in two parts "written right away, even a single byte" (used for access to registers) and "written right away, grouped into blocks for fast transfer" (used for access to framebuffer memory). Note that grouping into blocks is done by the hardware, not the kernel. So, when XFree86 4.3.0 uses O_SYNC flag to open /dev/mem l-k sets mtrr to "written right away, even a single byte" and direct writes to framebuffer (as needed for transfer of Xv images) become a lot slower. Now that I have written all this it occurred to me that I too seen some slowdown after installing GATOS drivers. It might be that whatever workaround is employed breaks when GATOS reprograms the memory controller on Radeons. Now how this could happen I have no idea, as Radeon memory controller is completely separate from mtrr. Could someone correct me please ? (CC'd to [EMAIL PROTECTED]) best Vladimir Dergachev I noticed the slowdown most profoundly on this 3D game called Chromium. It acts like I'm not getting acceleration. DVD playback was also a bit finicky. I'm using an ATI All-In-Wonder Radeon. Then again, I'm also using the Red Hat kernel. Although this kernel variant generally performs better because of low latency patches and 2.6 DRM, may not be 100% GATOS friendly. I'll try the latest standard 2.4 kernel and report. Peace, William I tried the standard Linux kernel with the GATOS drivers, and there was no improvement in graphics performance over using the Red Hat kernel and the GATOS drivers. 2D graphics are slow, 3D graphics are ridiculously slower. The drivers included with the kernel packages work much better. Something is definitely wrong with the GATOS drivers for XFree86 4.3. Peace, William ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
Vladimir Dergachev wrote: -the AGP bandwidth problems are not an XFree86 bug, but are a GATOS bug, right? Because I only have problems with display speed when using the GATOS drivers. -I've got a Pentium III, so it is not just an Athlon/Duron problem. No, GATOS code does not mess with AGP or mtrr. There was some issue with mtrr settings - whereby the framebuffer region was not properly marked, this manifested (due to different causes) with both Athlons and Pentiums. I don't remember the details.. However, I would have expected that this has been fixed in new kernels. best Vladimir Dergachev There was an issue with Athlon/Duron AGP bandwidth issues that arose in Xfree 4.3.0, and was unaffected by GATOS drivers. A later kernel update made it a bit better, but I do still get better xv throughput on my PCI Rage128 card, than my AGP(4x) Radeon8500 card. The AGP bandwidth issue affects only Athlon systems using older <=266 MHz chipsetsmade by Via, and does not affect DRI bandwidth. It sounds as if your problem is something different. If remember right the problem was that AGP space and framebuffer space could both be referenced by CPU in more than one way. It had something to do with O_SYNC flag being added when opening /dev/mem which effectively turned off mtrr settings. The problem was first noticed on Athlons, but then a similar effect was noticed with Pentiums. XFree86 4.2.0 does not exhibit this problem because (AFAIK.. ) it did not use O_SYNC flag when opening /dev/mem. My understanding is that with O_SYNC flag we describe two kinds of behaviour: when data is written right away and when the write can be delayed by the kernel. However, with mttr the meaning of "written right away" splits in two parts "written right away, even a single byte" (used for access to registers) and "written right away, grouped into blocks for fast transfer" (used for access to framebuffer memory). Note that grouping into blocks is done by the hardware, not the kernel. So, when XFree86 4.3.0 uses O_SYNC flag to open /dev/mem l-k sets mtrr to "written right away, even a single byte" and direct writes to framebuffer (as needed for transfer of Xv images) become a lot slower. Now that I have written all this it occurred to me that I too seen some slowdown after installing GATOS drivers. It might be that whatever workaround is employed breaks when GATOS reprograms the memory controller on Radeons. Now how this could happen I have no idea, as Radeon memory controller is completely separate from mtrr. Could someone correct me please ? (CC'd to [EMAIL PROTECTED]) best Vladimir Dergachev I noticed the slowdown most profoundly on this 3D game called Chromium. It acts like I'm not getting acceleration. DVD playback was also a bit finicky. I'm using an ATI All-In-Wonder Radeon. Then again, I'm also using the Red Hat kernel. Although this kernel variant generally performs better because of low latency patches and 2.6 DRM, may not be 100% GATOS friendly. I'll try the latest standard 2.4 kernel and report. Peace, William ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
> >>-the AGP bandwidth problems are not an XFree86 bug, but are a GATOS bug, > >>right? Because I only have problems with display speed when using the > >>GATOS drivers. > >>-I've got a Pentium III, so it is not just an Athlon/Duron problem. > >> > >> > > > >No, GATOS code does not mess with AGP or mtrr. There was some issue with > >mtrr settings - whereby the framebuffer region was not properly marked, > >this manifested (due to different causes) with both Athlons and Pentiums. > >I don't remember the details.. > > > >However, I would have expected that this has been fixed in new kernels. > > > > best > > > > Vladimir Dergachev > > > > > > > There was an issue with Athlon/Duron AGP bandwidth issues that arose in > Xfree 4.3.0, and was unaffected by GATOS drivers. A later kernel update > made it a bit better, but I do still get better xv throughput on my PCI > Rage128 card, than my AGP(4x) Radeon8500 card. The AGP bandwidth issue > affects only Athlon systems using older <=266 MHz chipsetsmade by Via, > and does not affect DRI bandwidth. > > It sounds as if your problem is something different. If remember right the problem was that AGP space and framebuffer space could both be referenced by CPU in more than one way. It had something to do with O_SYNC flag being added when opening /dev/mem which effectively turned off mtrr settings. The problem was first noticed on Athlons, but then a similar effect was noticed with Pentiums. XFree86 4.2.0 does not exhibit this problem because (AFAIK.. ) it did not use O_SYNC flag when opening /dev/mem. My understanding is that with O_SYNC flag we describe two kinds of behaviour: when data is written right away and when the write can be delayed by the kernel. However, with mttr the meaning of "written right away" splits in two parts "written right away, even a single byte" (used for access to registers) and "written right away, grouped into blocks for fast transfer" (used for access to framebuffer memory). Note that grouping into blocks is done by the hardware, not the kernel. So, when XFree86 4.3.0 uses O_SYNC flag to open /dev/mem l-k sets mtrr to "written right away, even a single byte" and direct writes to framebuffer (as needed for transfer of Xv images) become a lot slower. Now that I have written all this it occurred to me that I too seen some slowdown after installing GATOS drivers. It might be that whatever workaround is employed breaks when GATOS reprograms the memory controller on Radeons. Now how this could happen I have no idea, as Radeon memory controller is completely separate from mtrr. Could someone correct me please ? (CC'd to [EMAIL PROTECTED]) best Vladimir Dergachev > > Christopher Crawford > > >>Peace, > >>William > >> > >> > >> > >>--- > >>The SF.Net email is sponsored by EclipseCon 2004 > >>Premiere Conference on Open Tools Development and Integration > >>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > >>http://www.eclipsecon.org/osdn > >>___ > >>Gatos-devel mailing list > >>[EMAIL PROTECTED] > >>https://lists.sourceforge.net/lists/listinfo/gatos-devel > >> > >> > >> > > > > > >--- > >The SF.Net email is sponsored by EclipseCon 2004 > >Premiere Conference on Open Tools Development and Integration > >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > >http://www.eclipsecon.org/osdn > >___ > >Gatos-devel mailing list > >[EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/gatos-devel > > > > > > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
