Re: Re: Re: png.h not found!!!
Hi david, thanx for the advice... it worked like a charm :-) greatt. I m little confusion . why does kamp.c look for asm/mtrr.h when this header is only for i386 arch( i think)? Could you please suggest me any article which explains howto set the X-windows system manually. Thanx again, Jassi On Fri, 24 Oct 2003 David Dawes wrote : On Thu, Oct 23, 2003 at 03:46:34PM -, jassi brar wrote: Hi david, Noo, i m crosscompiling XFree86. By the way, can't i do without it? Yes, just add the following line to your xc/config/cf/host.def file: #define HasLibpng NO David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Shared libraries
Hello, even after the recent changes to XFree86-current libGLw, libXau and libXdmcp are still not built shared. I've got a report that this causes problem with certain 3rd party applications which try to build shared objects using these libraries. So may I ask what is the reason that these libraries are not built shared? Kind regards -- Matthias Scheler http://scheler.de/~matthias/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Building XFree86 for AMD Au1100 mips version
Hi, I'm building a version fo XFree86 for the AMD Au1100 MIPS based system. I believe that I have all of the configuration set up correctly and the build completes with a full build. But there is a problem during the build. In swaprep.c the CopySwap32Write() function is causing a gcc internal error: Segmentation fault. I'm using gcc version 3.2 that came with the Timesys Linux system, and this is a native build on Timesys Linux running on an AMD Au1100 development board. Has anyone else encountered this problem, and if so how did you resolve it? I'm reviewing my configuration to make sure that there isn't a #define somewhere that didn't get set, but so far I haven't found anything obvious. If anyone knows of an existing port for the Au1100 that would be even better. Thanks, Burt ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Building XFree86 for AMD Au1100 mips version
Burt Bicksler wrote: Hi, I'm building a version fo XFree86 for the AMD Au1100 MIPS based system. I believe that I have all of the configuration set up correctly and the build completes with a full build. But there is a problem during the build. In swaprep.c the CopySwap32Write() function is causing a gcc internal error: Segmentation fault. gcc internal errors are bad things. I'd suggest reducing the optimisation level on gcc; it often causes it to go via a different path. (If the segmentation fault hits in lots of different nonrepeatable places its more likely a hardware fault on the system running the compiler). Dave ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: FATAL ERROR 4.3.0: make install
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Justin, You wrote, ... installing in lib/GL/mesa/src/OSmesa... make[4]: Entering directory `/home/war/4.3.0/source/xc/lib/GL/mesa/src/OSmesa' gcc -c -o ../../../../../lib/GL/mesa/src/X86/common_x86_asm.o ../../../../../lib/GL/mesa/src/X86/common_x86_asm.S In file included from ../../../../../lib/GL/mesa/src/X86/common_x86_asm.S:43: ../../../../../lib/GL/mesa/src/X86/matypes.h:9:22: assyntax.h: No such file or directory ../../../../../lib/GL/mesa/src/X86/common_x86_asm.S:44:33: common_x86_features.h: No such file or directory ... I had the same problem, but the origin was located earlier. The build process of XFree86 seems to be very [=too??] tolerant against first errors and a kind of hides them by proceeding on: Already during ``make all´´, I had this problem, and the very reason was, that my /usr/bin/cpp could not have been found due to a permission inconsistency. Bye, Markus -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQE/mQ506SfXGSt1/TMRAsztAJwI0jJt5v0vAizhdlhGzDpFPB6omQCdHRVi s3caHR/h8i09WX3hLDoeers= =TePm -END PGP SIGNATURE- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: FATAL ERROR 4.3.0: make install
On Fri, 24 Oct 2003, Markus Pilzecker wrote: installing in lib/GL/mesa/src/OSmesa... make[4]: Entering directory `/home/war/4.3.0/source/xc/lib/GL/mesa/src/OSmesa' gcc -c -o ../../../../../lib/GL/mesa/src/X86/common_x86_asm.o ../../../../../lib/GL/mesa/src/X86/common_x86_asm.S In file included from ../../../../../lib/GL/mesa/src/X86/common_x86_asm.S:43: ../../../../../lib/GL/mesa/src/X86/matypes.h:9:22: assyntax.h: No such file or directory ../../../../../lib/GL/mesa/src/X86/common_x86_asm.S:44:33: common_x86_features.h: No such file or directory ... I had the same problem, but the origin was located earlier. The build process of XFree86 seems to be very [=too??] tolerant against first errors and a kind of hides them by proceeding on: Already during ``make all´´, I had this problem, and the very reason was, that my /usr/bin/cpp could not have been found due to a permission inconsistency. make World WORLDOPTS= will cause the build to fail immediately in all versions of XFree86. I believe this has been made the default in CVS head. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: C+T 69030 driver on powerpc
Tim Roberts writes: On Thu, 23 Oct 2003 17:16:19 +0100, Rob Taylor wrote: Has anyone sucessfully run the chips 69030 driver on powerpc based systems? I'm trying to get it running on a custon 7410 based board with two 69030's on,a nd i;'m seing soem off things: ... Also does anyone know the reason for the addition of 0x80 to the base address in the big-endian case? Many graphics chips include two separate views of the frame buffer: one that swaps bytes, one that does not. This makes it easy to handle endian mismatches. I'm guessing that's the case here. Right, that's exactly the reason for this. The BE support was tested for one of the HiQV chipsets - however I'm not sure if it was tested for the 69030. thanks for the info! google now tells me that Michael Stephen Hanni wrote the +0x8 hack for running ct65550 on his powerbook 3400 :) Currently theres a a lot of possibiliites as to what could be going wrong, so knowing whats right's a good place to start :) I'll try and get a well formed patch in when i get this all working (and I *will* get it working... *grr* ;)) noticed i forgot to mention the immediate symtoms in my last post - the driver starts up, the server gets to running, but there's no display, no change in output whatsover... We're running an fbdev driver for the card in the kernel, could i be seeing some sort of resorce allocation problem? We currently run an fbdev based driver in Xfree86 that works flawlessly but leaves a lot to be desired on the accelaration side, so hardware is all good. Thanks Rob Taylor Senior Developerrobt at flyingpig dot com Flying Pig Systems http://www.flyingpig.com Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Shared libraries
On Fri, Oct 24, 2003 at 09:43:13AM +0200, Matthias Scheler wrote: Hello, even after the recent changes to XFree86-current libGLw, libXau and libXdmcp are still not built shared. I've got a report that this causes problem with certain 3rd party applications which try to build shared objects using these libraries. So may I ask what is the reason that these libraries are not built shared? I'm not sure about the reasons for libGLw. The other two can be built shared providing that the build is setup so that the static versions are always built too, and the X servers (at least) continue to link against the static versions. Linking the X servers against shared versions can be re-examined if necessary after 4.4 is out. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Re: Re: png.h not found!!!
On Fri, Oct 24, 2003 at 07:24:17AM -, jassi brar wrote: Hi david, thanx for the advice... it worked like a charm :-) greatt. I m little confusion . why does kamp.c look for asm/mtrr.h when this header is only for i386 arch( i think)? I don't see any file with that name in the XFree86 source tree. Maybe it's a KDE app? If so, it'd be best to ask about it on a KDE list. Could you please suggest me any article which explains howto set the X-windows system manually. There are links for lots of X-related docs at http://www.xfree86.org/support.html. I'm not familiar with a specific article that deals with what you're looking for, but maybe someone else here can point you to something specific. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Sis DRI test
I have build X from CVS with Kernel 2.6-test8 and SiS DRI (I have a SiS 630 with 32MB) worked quite well ... like in 4.2 But there's still an out of video/agp memory Error in some applications (Serious Sam / some games with wine) but quake3 works quite well ... Also Blender and wings3d look somehow different after some time (like explained on winischhofer.net) Also at start from X I get: agp acquire failed. Does somebody want perhaps a strace output form that apps? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Sis DRI test
Stjepan Stamenkovic wrote: I have build X from CVS with Kernel 2.6-test8 and SiS DRI (I have a SiS 630 with 32MB) worked quite well ... like in 4.2 But there's still an out of video/agp memory Error in some applications (Serious Sam / some games with wine) but quake3 works quite well ... Well, the driver assumingly still can't swap to system RAM. Same situation as before. Set the memory to 64MB in the BIOS setup, helps perhaps a little. Also Blender and wings3d look somehow different after some time (like explained on winischhofer.net) Also at start from X I get: agp acquire failed. agpgart in the kernel? Current DRM module? Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Sis DRI test
On Fri, 2003-10-24 at 09:45, Stjepan Stamenkovic wrote: I have build X from CVS with Kernel 2.6-test8 and SiS DRI (I have a SiS 630 with 32MB) worked quite well ... like in 4.2 But there's still an out of video/agp memory Error in some applications (Serious Sam / some games with wine) but quake3 works quite well ... Also Blender and wings3d look somehow different after some time (like explained on winischhofer.net) Also at start from X I get: agp acquire failed. Does somebody want perhaps a strace output form that apps? Code could be written to deal with swapping out of the app's own memory allocations (dealing with out of video/agp memory for the single app case), but it's just a workaround for a very poor memory management implementation. The DRI common memory allocator has its own issues, but it's much better overall I'd say. The issues of backwards compatibility requirements are enough that I don't want to spend my time on that right now, and would rather spend it thinking about a new general memory allocator. For you, you probably want to just figure out how to get AGP working properly, which will be used as a fallback when you run out of card memory. I don't think strace output of broken apps would be useful to me. There are still known glean errors to be taken care of, along with trying to get information from SiS on how to do GL_BLEND properly so that modern games don't hit software fallbacks. Simple demos with source are the best way to deal with getting rendering errors fixed. If you can come up with those, then a fix is usually pretty quick to produce. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Shared libraries
Matthias Scheler wrote (in a message from Friday 24) Hello, even after the recent changes to XFree86-current libGLw, libXau and libXdmcp are still not built shared. I've got a report that this causes problem with certain 3rd party applications which try to build shared objects using these libraries. So may I ask what is the reason that these libraries are not built shared? libGLw has some comments attached, explaining that it would depend on libXm (Motif) if built shared. It seemed true to me last time I checked. So we could build a shared version of it only on systems with weak symbols, by providing a weak definition of the needed libXm symbols. The same thing holds for libXdmcp. If HasXdmAuth is defined, libXdmcp provides some additional symbols. Weak definitions of those should be provided if building a shared lib. I'm not sure if I'll have time to test an implementation of weak symbols in those 2 libs in all possible cases. Help is welcome. I don't have good reasons for libXau, except the one that David already mentionned (linking the server statically against it). Out of curiosity, what applications are you referring to ? Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Shared libraries
On Fri, 24 Oct 2003, David Dawes wrote: even after the recent changes to XFree86-current libGLw, libXau and libXdmcp are still not built shared. I've got a report that this causes problem with certain 3rd party applications which try to build shared objects using these libraries. So may I ask what is the reason that these libraries are not built shared? I'm not sure about the reasons for libGLw. The other two can be built shared providing that the build is setup so that the static versions are always built too, and the X servers (at least) continue to link against the static versions. Linking the X servers against shared versions can be re-examined if necessary after 4.4 is out. I think one of the fixes I've got here for 4.3.0 might resolve this for libXau, and some other libs. We experienced a problem where shared libs trying to link to static libs caused application failures due to non-PIC code being used. I'll have to have a look at this soon and port forward to HEAD if need be, and send a patch in. Not 100% sure that our problem is identical to this one though. TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Building XFree86 for AMD Au1100 mips version
On Fri, Oct 24, 2003 at 07:15:14AM -0400, Burt Bicksler wrote: I'm building a version fo XFree86 for the AMD Au1100 MIPS based system. I believe that I have all of the configuration set up correctly and the build completes with a full build. Remove the -k from WORLDOPTS in the top level Makefile to let the build stop on the first error. But there is a problem during the build. In swaprep.c the CopySwap32Write() function is causing a gcc internal error: Segmentation fault. I can built XFree86 fine on mips with gcc 3.3.2. You're not building for mips64, are you? Cheers, -- Guido signature.asc Description: Digital signature
Re: Building XFree86 for AMD Au1100 mips version
Thanks Dave, I figured that the internal compiler error was likely related to an optimization bug since the code looks pretty simple and direct. I'm doing a build with the optimization relaxed to see if that was the culprit. Burt At 12:23 PM 10/24/2003 +0100, you wrote: gcc internal errors are bad things. I'd suggest reducing the optimisation level on gcc; it often causes it to go via a different path. (If the segmentation fault hits in lots of different nonrepeatable places its more likely a hardware fault on the system running the compiler). Dave ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Building XFree86 for AMD Au1100 mips version
Thanks Guido, No, I'm definitely building for 32 bit mips. I suspect either an optimization related issue, or I still don't have something properly configured. Thanks for the tip on removing the -k switch. I'd missed that and it will make life much easier. Burt At 11:35 PM 10/24/2003 +0200, you wrote: On Fri, Oct 24, 2003 at 07:15:14AM -0400, Burt Bicksler wrote: I'm building a version fo XFree86 for the AMD Au1100 MIPS based system. I believe that I have all of the configuration set up correctly and the build completes with a full build. Remove the -k from WORLDOPTS in the top level Makefile to let the build stop on the first error. But there is a problem during the build. In swaprep.c the CopySwap32Write() function is causing a gcc internal error: Segmentation fault. I can built XFree86 fine on mips with gcc 3.3.2. You're not building for mips64, are you? Cheers, -- Guido ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Generic rootless code bug
At 1:17 AM +0900 10/25/03, Kensuke Matsuzaki wrote:
Rootless code in Xserver/miext/rootless has a small bug.
Kensuke Matsuzaki
diff -u -r1.6 rootlessWindow.c
--- rootlessWindow.c23 Jul 2003 00:48:58 - 1.6
+++ rootlessWindow.c24 Oct 2003 13:02:02 -
@@ -889,9 +889,9 @@
gResizeDeathBits = xalloc(copy_rowbytes
* copy_rect_height);
-if (rootless_CopyWindow_threshold
+if (rootless_CopyBytes_threshold
copy_rect_width * copy_rect_height
-rootless_CopyWindow_threshold)
+rootless_CopyBytes_threshold)
{
SCREENREC(pScreen)-imp-CopyBytes(
copy_rect_width * Bpp, copy_rect_height,
Thanks for catching that. I'll apply your patch.
A side note about the rootless acceleration functions: In the top of
the tree (since yesterday) we have added lots more use of these
optional functions. They are also tested for existence directly
instead of using the corresponding threshold. For example we would
test here for SCREENREC(pScreen)-imp-CopyBytes to not be NULL
instead of rootless_CopyBytes_threshold != 0. This seems safer and is
no slower if the test is true. Please let me know if you have any
comments or questions.
--Torrey
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
