Re: [Dri-devel] Complain and request for Mach64 binaries a la Gatos
On 2002.02.19 03:21 Daryll Strauss wrote: On Mon, Feb 18, 2002 at 06:50:36PM -0800, Gareth Hughes wrote: Sergey V. Udaltsov wrote: ... The main point of this letter: could someone please consider the possibility of periodical publishing mach64.tar.gz using the method of Gatos project: just XFree modules and drm kernel modules (I think, for libGL.* will go there too). The building of the whole tree is time- and space-consuming task, so these builds could simplify the life for ordinary but adventurous people like me. Is it wrong idea? I do not think it is very difficult to hack little shell script which makes this archive... Why limit this to the mach64 driver? We don't build binaries for anything else, and some might argue that other drivers are used more than this one and are thus more worthy of having pre-built binaries :-) If someone wants to take the role of release manager, that would be great. The job is just to keep your CVS tree up to date with all the drivers, build it all (and report any problems), and release make releases to the download page at regular intervals. It isn't a tough job. We even had people make the packaging tools a while back. All it takes is some bandwidth and cycles, which could be run in the middle of the night. So, for those of you looking to help, here's another suggestion. - |Daryll I'm willing to give it a go. Are there any scripts already done that I can base upon for automate this taks? Regards, José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Complain and request for Mach64 binaries a la Gatos
Hi all Once again, I managed to came through the waters and fires of the updating and building process. Again, got DRM working with my humble Mobility (at least with glxgears/tunnel). There are 2 minor questions: 1. After all these discussions in IRC, I realized that fog in Mach64 is not ready yet. Is it? So the fact I cannot see fog in the tunnel - it is OK for a moment, isn't it? 2. For some reason, X server gets signal 11 after closing any GL program. Is it registered bug? Can I help with debugging (with my XFree.0.log/dmesg)? Anyway, Jos's effort for packaging is still in very high demand among me, my system, and openuniverse:) Hope others are interested too. Thanks for support to this idea. Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Complain and request for Mach64 binaries a la Gatos
That's because tunnel tries to use alpha blending _and_ fog, which isn't possible on mach64 (we're looking into a workaround though). If you OK. For a moment, I just will remember this fact. 2. For some reason, X server gets signal 11 after closing any GL program. Is it registered bug? Can I help with debugging (with my XFree.0.log/dmesg)? Hmmm, I haven't seen that. Post the logs and we can take a look. OK. With my pleasure. Actually, almost all the stuff in this file is from the initialization. Till the line Open APM successful. Actions: 1. In vt1, I do /usr/X11R6-DRI/bin/X 2. In vt2, I do DISPLAY=:0.0 glxinfo.. 3. Switch to vt4. The whole system crashes but glxinfo returns some sensible data. If I use glxgears instead, it runs till I stop it (by Ctl-C in vt2) and X terminates with the same signal 11. Does it have something to do with vt management? Cheers, Sergey 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.1.99.1 (DRI mach64 branch) / X Window System (protocol Version 11, revision 0, vendor release 6510) Release Date: 20 August 2001 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) Build Operating System: Linux 2.4.17-0.12 i686 [ELF] Module Loader present (==) Log file: /var/log/XFree86.0.log, Time: Tue Feb 19 23:39:31 2002 (==) Using config file: /etc/X11/XF86Config Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) ServerLayout Simple Layout (**) |--Screen Screen 1 (0) (**) | |--Monitor gw (**) | |--Device gw (**) |--Input Device Mouse1 (**) |--Input Device USBMouse (**) |--Input Device Keyboard1 (**) Option AutoRepeat 500 30 (**) Option XkbKeymap en_ru_de (**) XKB: keymap: en_ru_de (overrides other XKB settings) (==) Keyboard: CustomKeycode disabled (**) FontPath set to unix/:7000 (**) RgbPath set to /usr/X11R6/lib/X11/rgb (**) ModulePath set to /usr/X11R6-DRI/lib/modules,/usr/X11R6-DRI/lib/modules/multimedia (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.5 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6-DRI/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.1.99.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6-DRI/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.1.99.1, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (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 107b,9300 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 03 class 06,80,00 hdr 00 (II) PCI: 00:08:0: chip 125d,1978 card 107b,9300 rev 10 class 04,01,00 hdr 00 (II) PCI: 00:0b:0: chip 11c1,0448 card 1668,2000 rev 01 class 07,80,00 hdr 00 (II) PCI: 00:0c:0: chip 104c,ac40 card 4000, rev 00 class 06,07,00 hdr 82 (II) PCI: 00:0c:1: chip 104c,ac40 card 4800, rev 00 class 06,07,00 hdr 82 (II) PCI: 00:0c:2: chip 104c,8011 card 107b,9300 rev 00 class 0c,00,10 hdr 80 (II) PCI: 01:00:0: chip 1002,4c4d card 107b,9300 rev 64 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) LoadModule: scanpci (II) Loading /usr/X11R6-DRI/lib/modules/libscanpci.a (II) Module scanpci: vendor=The XFree86 Project compiled for 4.1.99.1, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) UnloadModule: scanpci (II) Unloading /usr/X11R6-DRI/lib/modules/libscanpci.a (II) Host-to-PCI bridge: (II) PCI-to-ISA bridge: (II) PCI-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable
Re: [Dri-devel] Complain and request for Mach64 binaries a la Gatos
On 19 Feb 2002, Sergey V. Udaltsov wrote: That's because tunnel tries to use alpha blending _and_ fog, which isn't possible on mach64 (we're looking into a workaround though). If you OK. For a moment, I just will remember this fact. 2. For some reason, X server gets signal 11 after closing any GL program. Is it registered bug? Can I help with debugging (with my XFree.0.log/dmesg)? Hmmm, I haven't seen that. Post the logs and we can take a look. OK. With my pleasure. Actually, almost all the stuff in this file is from the initialization. Till the line Open APM successful. Actions: 1. In vt1, I do /usr/X11R6-DRI/bin/X 2. In vt2, I do DISPLAY=:0.0 glxinfo.. 3. Switch to vt4. The whole system crashes but glxinfo returns some sensible data. If I use glxgears instead, it runs till I stop it (by Ctl-C in vt2) and X terminates with the same signal 11. Does it have something to do with vt management? Yes, I think so. There are still locking issues to resolve between the Mesa driver, drm and the DDX driver. Switching vts when an GL app is running will most likely lock the card at this point. You should be able to run glxinfo and glxgears from an xterm without a problem. Does X crash if you run glxgears from an xterm? btw, your Xlog seems to end at the message about virtual resolutions being limited due to ... Is that really the end? (maybe I'm having problems with the charset). -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Complain and request for Mach64 binaries a la Gatos
Sergey, On 2002.02.19 00:46 Sergey V. Udaltsov wrote: Hello all Just tried to build mach64 branch. Got an error: make[4]: Entering directory `/db2/xfree/xc/xc/lib/GL/mesa/src/drv/sis' make[4]: *** No rule to make target `../../../../../../lib/GL/dri/drm/sis_drm.h', needed by `sis_alloc.o'. Stop. make[4]: Leaving directory `/db2/xfree/xc/xc/lib/GL/mesa/src/drv/sis' make[3]: *** [all] Error 2 make[3]: Leaving directory `/db2/xfree/xc/xc/lib/GL/mesa/src/drv' make[2]: *** [all] Error 2 make[2]: Leaving directory `/db2/xfree/xc/xc/lib/GL' make[1]: *** [all] Error 2 make[1]: Leaving directory `/db2/xfree/xc/xc/lib' make: *** [all] Error 2 Any clue? Is it FAQ? No clue. The only thing I noticed unusual is that you're not building on a seperate lndir tree, but I don't see how that could affect the build. If you really want to know make a 'find /db2/xfree/ -name sis_drm.h' to see were that file went to and compare to the path were make is trying to get it. The main point of this letter: could someone please consider the possibility of periodical publishing mach64.tar.gz using the method of Gatos project: just XFree modules and drm kernel modules (I think, for libGL.* will go there too). The building of the whole tree is time- and You don't need to build the whole tree. You could just went to xc/lib/GL/mesa/src/drv/mach64 and do 'cvs update', 'make' and 'su -c make install'... space-consuming task, so these builds could simplify the life for ...although space-consuming is indeed, unfortunately. ordinary but adventurous people like me. Is it wrong idea? I do not think it is very difficult to hack little shell script which makes this archive... Since your not only a ordinary but adventurous people but a rather persistent one as well I'm going to do what ask for! :-) I'll post here when it's done. Cheers, Sergey Regards, José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Complain and request for Mach64 binaries a la Gatos
On Mon, Feb 18, 2002 at 06:50:36PM -0800, Gareth Hughes wrote: Sergey V. Udaltsov wrote: Hello all Just tried to build mach64 branch. Got an error: make[4]: Entering directory `/db2/xfree/xc/xc/lib/GL/mesa/src/drv/sis' make[4]: *** No rule to make target `../../../../../../lib/GL/dri/drm/sis_drm.h', needed by `sis_alloc.o'. Stop. make[4]: Leaving directory `/db2/xfree/xc/xc/lib/GL/mesa/src/drv/sis' make[3]: *** [all] Error 2 make[3]: Leaving directory `/db2/xfree/xc/xc/lib/GL/mesa/src/drv' make[2]: *** [all] Error 2 make[2]: Leaving directory `/db2/xfree/xc/xc/lib/GL' make[1]: *** [all] Error 2 make[1]: Leaving directory `/db2/xfree/xc/xc/lib' make: *** [all] Error 2 Any clue? Is it FAQ? No idea... Did you follow the compilation guide? It looks sort of like you didn't do 'make World' and just did make. The main point of this letter: could someone please consider the possibility of periodical publishing mach64.tar.gz using the method of Gatos project: just XFree modules and drm kernel modules (I think, for libGL.* will go there too). The building of the whole tree is time- and space-consuming task, so these builds could simplify the life for ordinary but adventurous people like me. Is it wrong idea? I do not think it is very difficult to hack little shell script which makes this archive... Why limit this to the mach64 driver? We don't build binaries for anything else, and some might argue that other drivers are used more than this one and are thus more worthy of having pre-built binaries :-) If someone wants to take the role of release manager, that would be great. The job is just to keep your CVS tree up to date with all the drivers, build it all (and report any problems), and release make releases to the download page at regular intervals. It isn't a tough job. We even had people make the packaging tools a while back. All it takes is some bandwidth and cycles, which could be run in the middle of the night. So, for those of you looking to help, here's another suggestion. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
