Re: CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 06/01/24 20:32:10 Log message: 187. Add two new functions that can be used to scroll the content of an Xaw viewport from outside the viewportWidgetClass (Bugzilla #1648, Alexander Pohoyda). 186. Fix i18n for Xaw's tip widget (Bugzilla #1647, Alexander Pohoyda). 185. Fix a performance issue with Xaw's Tree widget caused by useless relayouts (Bugzilla #1645, Alexander Pohoyda). 184. Add some XChar2b string manipulation functions to Xt (Bugzilla #1646, Alexander Pohoyda). Modified files: xc/lib/Xaw/: Label.c Label.h LabelP.h Simple.c Simple.h SimpleP.h Tip.c Tree.c TreeP.h Viewport.c Viewport.h xc/lib/Xt/: Functions.c Intrinsic.h Xt-def.cpp jump_funcs xc/programs/Xserver/hw/xfree86/: CHANGELOG libXaw and libXt minor revision numbers should be incremented when adding functions. -- Matthieu Herrb ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Xrender and 64bit
Michael wrote: Hello, FYI, this is the same problem as: https://bugs.freedesktop.org/attachment.cgi?id=3095 Indeed. Is this considered the 'canonical' fix by the Xrender guys? No. I'm still waiting on feedback on this. -- Matthieu Herrb ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Xrender and 64bit
Michael wrote:
Hello,
I recently found out that whoever wrote Xrender apparently didn't waste
a single thought on 64bit systems. Base types are unsigned longs ( see
X11/extensions/render.h ):
typedef unsigned long Glyph;
typedef unsigned long GlyphSet;
typedef unsigned long Picture;
typedef unsigned long PictFormat;
but everything seems to assume they're size 4 bytes and goes some
lengths to ensure 4 byte alignment but this still leads to occasional
SIGBUS from Xserver/render/render.c, especially
ProcRenderCompositeGlyph(). A quick, working but dead ugly 'fix' is
this:
Index: render.c
===
RCS file: /cvsroot/xsrc/xfree/xc/programs/Xserver/render/render.c,v
retrieving revision 1.1.1.6 diff -u -w -r1.1.1.6 render.c
--- render.c 18 Mar 2005 13:13:16 - 1.1.1.6
+++ render.c24 Jul 2005 17:46:09 -
@@ -1300,7 +1300,7 @@
{
if (buffer + sizeof (GlyphSet) end)
{
- gs = *(GlyphSet *) buffer;
+ gs = *(CARD32 *) buffer;
glyphSet = (GlyphSetPtr) SecurityLookupIDByType (client,
gs,
GlyphSetType,
A real fix would be to change the base types to something that's always
32bit I think but that would disrupt more or less everything that uses
Xrender since they're exposed to clients.
Any ideas what to do about this? On sparc64 this leads to firefox
occasionally crashing the Xserver and I'm pretty sure it would affect
other 64bit architectures as well.
have fun
Michael
FYI, this is the same problem as:
https://bugs.freedesktop.org/attachment.cgi?id=3095
--
Matthieu Herrb
smime.p7s
Description: S/MIME Cryptographic Signature
Re: keymap submission
Use bugzilla : http://bugzilla.xfree86.org/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
xterm dumping core with BSD's malloc
Hi,
several users have reported crashes with xterm on OpenBSD with
/etc/malloc.conf pointing to 'J' (fill allocated areas with junk).
After some debugging, it appears that the following patch is needed to
fix that.
--
Matthieu
Index: button.c
===
RCS file: /cvs/OpenBSD/XF4/xc/programs/xterm/button.c,v
retrieving revision 1.1.1.5
diff -u -r1.1.1.5 button.c
--- button.c13 Feb 2004 21:45:49 - 1.1.1.5
+++ button.c14 Jul 2004 17:02:19 -
@@ -2108,7 +2108,8 @@
endCol--;
}
-if (iswide(XTERM_CELL(endRow, endCol - 1))
+if (endCol 1
+iswide(XTERM_CELL(endRow, endCol - 1))
XTERM_CELL(endRow, endCol) == HIDDEN_CHAR) {
endCol += 1;
}
Re: xf86Io.c, libos.a GetTimeInMillis() change.
Tyler Retzlaff wrote: Just want to confirm something, xc/programs/Xserver/hw/xfree86/common/xf86Io.c,v 3.58 has had GetTimeInMillis() removed from it, the commit message doesn't say anything specific about it but is the copy of GetTimeInMillis() from libos.a the one that linked into the XFree86 server from now on? I can't speak in place of David, but I think it's a good thing to finally get rid of this duplicate definition, which has mostly caused problems when building oher X servers in addition to the XFree86 one. There are probably a few more cleanings that could be done now that XFree86 uses the libos version (and builds it). -- Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: API Call for Switching Resolution at Runtime?
Scott, Thomas wrote: I know that you can press Ctrl-Alt-Plus and Ctrl-Alt-Minus to dynamically switch your configured screen resolutions at runtime. Therefore, I assume there is some API call that accomplishes this task. Does anyone know what it is? Please provide an example of use if you respond. See XF86VidModeSwitchToMode(3) and the source of xvidtune for an example of use. -- Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: cvsup for modern machines ?
Dr Andrew C Aitchison wrote: I've recently upgraded my Red Hat 6.2 machine to Red Hat 9 (yes that is a bit long in the tooth too). I now find that cvsup fails with the message *** *** runtime error: ***Segmentation violation - possible attempt to dereference NIL0 *** use option @M3stackdump to get a stack trace Aborted I don't know much about Modula 3, so don't know what to do with @M3stackdump, and wonder where to get a newer version of cvsup ? I've found binary packages for Red Hat 8, 9 and Fedora Core 1 here: http://rpm.pbone.net/index.php3/stat/11/limit/5/dl/40/vendor/2001/com/Fedora%20Linux.html I think we could think about providing cvsync (http://www.cvsync.org/) in addition to CVsup to access the XFree86 repository. OpenBSD is using it for 6 month now with success (http://www.openbsd.org/cvsync.html). -- Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
3dfx driver on Pegasos II
Hi, has someone managed to get the 3dfx driver work on a Pegasos II under Linux (or OpenBSD)? Out of the box, it fails because apparently the PCI BIOS is not mapping the PIO registers (or XFree86 can't find them): (EE) TDFX(0): No valid PIO address in PCI config space. -- Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: license statements in CVS commit messages
David Dawes wrote: On Tue, Apr 06, 2004 at 09:05:06AM -0700, Alan Coopersmith wrote: I notice many of the affected files do not bear the license notice mentioned in the checkin notice. Is that intentional? Will everyone investigating the license that applies to a file now have to check every CVS commit log entry for that file as well as the file itself to find out which license applies? Assume that anything attributed to me is covered by the 1.1 licence unless explicitly stated otherwise. You mean anything attributed to you in the existing copyright notice, or in the CHANGELOG file? If you mean the latter, I think you're wrong. We should attach the appropriate license to each file it applies to. Having each file carry it's full license(s) is the only way to determine what applies to a particular file, in a project with many contributors and many different licenses. -- Matthieu Herrb smime.p7s Description: S/MIME Cryptographic Signature
Re: (patch seq: 6202) XFree86-4.4.0 -- IPv6 support causes serious problems
Marc Aurele La France wrote: On Mon, 22 Mar 2004, Peter Breitenlohner wrote: It seems that originally there were plans to have two distinct sockets that were abandonned in the middle. Maybe that ought to be cleaned up (fairly trivial mods in xdmcp.c, just excise chooserFd6). Since Alan Coopersmith originally implemented this on Solaris, which can handle both IPv6 and IPv4 on the same socket, there was initially only one socket. As you might know, IPv4 addresses mapped in IPv6 are considered by a potential security problem and are disabled by default in some of the *BSD systems. (I can't repost the link to Itojun's papers on this later). For now IPv6 support for xdmcp is disabled on the hosts that don't support mapped v4 addresses. I started to implement something with 2 sockets for xdmcp, but it turned out to be too much modifications for the XFree86 code freeze (which lasted longer than I expected). It is possible that some of the ChooserFd6 code present here splipped through some of my other fixes for xdm. I think it would be better to keep the chooserFd's separate, i.e. change socket.c. My reasoning is that some systems don't allow IPv4 traffic with an IPv6 socket, i.e. IPv6 is treated as a seperate protocol, rather than a superset of IPv4. Yes I think that too. But the changes to the control flow of xdm are pretty invasive to support that. It's on my todo list for the next weeks when (hopefully) I'll have some more time to spend on X hacking. Another issue is that the XDM-AUTHORIZATION-1 protocol cannot support. A new revision XDM-AUTHORIZATION-2 has been designed by X.Org but no one has implemented it yet. Althrough XDM-AUTHORIZATION-1 is not built by default by XFree86, it provides some enhancements to the security of remote X connections. -- Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
__AMD64__ or __amd64__ ?
Hi, While working on OpenBSD/amd64 support for XFree86, I found out that the C preprocessor symbol for AMD64 machines was changed from __x86_64__ to __AMD64__. But looking at what gcc defines on different AMD63 systems (*BSD, Linux), it looks __AMD64__ is never used. Generally __amd64__ is defined. linux.cf add -D__AMD64__ to StandardCppDefines, so the code actually works there. Also, in many places where checks are done for 64 bits arches, the test is in the form #if defined(_LP64) || defined(__alpha__) || defined(__AMD64__). Since on the BSDs gcc defines _LP64, these conditions will be true. But there are a few cases where the _LP64 test is missing. Any clues on how to fix that correctly (after 4.4) ? Instead of enumerating all the LP64 arches in several different places, it would be better imho to make sure _LP64 is defined and only testing on this. For other cases (where the dependance is not a general LP64 problem, but AMD64 specific, it would be more logic imho to use __amd64__. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: driver include files
dave wrote: Hi my driver need some system include files in it so I can use the flowing functions #include sys/types.h #include sys/stat.h #include sys/ioctl.h #include fcntl.h #include unistd.h open() ioctl() close() but the X server design book says all modules (my driver is static) must NOT include any system include files If your driver needs to do ioctls directly, it will probably not be OS independant, which breaks one of the XFree86 modules design goal. The Correct way to handle this would be to implement the functions that need ioctls in a os-independant manner in the os-support/ part of the server, export these os-idenpdendant API to the modules and then use these os-independant functions in your module. If you don't follow the above recommendation, you should be able to compile your driver anyways, but it won't be useable on any other os than the one it was developped for, which is not completely correct. (But such modules already exist). ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: broken xf86PciInfo.h and xf86cfg/config.h
Dr Andrew C Aitchison wrote (in a message from Sunday 15) The licence updates to xf86PciInfo.h haven't patched cleanly, and are mis-commented, breaking the build. The attached patch fixes this. -- xc/programs/Xserver/hw/xfree86/xf86cfg/config.h is also broken; Both problems have already been fixed in the repository. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: -rpath not used under Linux
David Dawes wrote (in a message from Saturday 24) Does NetBSD have an ld.so cache/hints mechanism like Linux and FreeBSD? NetBSD has /etc/ld.so.conf. But it's default setup doesn't include /usr/X11R6/lib. Or is the search order different on NetBSD? What about OpenBSD? OpenBSD adds /usr/X11R6/lib to the ld.so search path in /etc/rc. (using ldconfig). The problem, at least on Linux and FreeBSD, is that using -rpath prevents the admin from configuring a different path, not to mention preventing the use of LD_LIBRARY_PATH for temporary overrides. (That explains the problems I've had in the past debugging on FreeBSD vs Linux.) My experience is that X has more than one way to fail if it's configured and built with /usr/X11R6 as the target directory and it's later moved to some other directory. I always recommend to people who want to make several X versions to coexist to set a different ProjectRoot in host.def. This way each instance will have its own shared libs search PATH and this will avoid mixing shared libs from differents versions. If -rpath is not set, then all installed versions will pick up the default path and use libs from /usr/X11R6. If there is no general consensus, I will at least add a build option to make it easy to turn -rpath on or off for a host.def setting, and leave the defaults as they are now. Yes I think this makes sense. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: cannot find -lfl
Suresh Chandra Mannava wrote (in a message from Friday 23) Dear Friends, I am encountering the following error while Installing the build of XFree86 TinyX. I cross compiled X with Abacus compiler (India build processor) make[3]: Entering directory `/home/suresh/xfree/build/programs/xgc' rm -f xgc /usr/abacus-linux-uclibc/bin/abacus-uclibc-gcc -o xgc -O2 -L../../exports/lib -L/usr/X11R6/lib dashlist.o planemask.o getfile.o tests.o text.o choice.o main.o interpret.o record.o testfrac.o gram.o lex.o -lXaw -lXmu -lXt -lSM -lICE -lXpm -lXext -lX11 -lfl -L/usr/abacus-linux-uclibc/lib -lm /usr/abacusnewb/abacus-anurag-linux/bin/ld: cannot -lfl is the library containing some routines used by lexical analysers generated by flex, a lexical analyser generator. You should check you system to find what's the equivalent library name on the target system. If your target system doesn't provide it, you can probably cross-compile this library from flex sources first. http://www.gnu.org/software/flex/flex.html Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Untrusted XSecurity connection handling in X applications
Hi, I'd like to focus attention of application developpers on one of the X server feature that will become more used in the near future: the XSecurity extension which create the possibility of using 'xauth generate' to dynamically create xauth cookies. By default clients connecting with these cookies will be 'untrusted' by the X server, meaning that it will apply a number of restrictions which are described in xc/doc/hardcopy/Xext/security.PS.gz in the source code - I've also made a PDF available as http://www.xfree86.org/~herrb/security.pdf. Among those restrictions, the one of interest is the property security which is controlled by /etc/X11/XServer/SecurityPolicy. The default policy included in the sample implementation and in XFree86 is quite restrictive and causes a lot of X applications to get Bad Access errors when run as 'unsecure'. But many applications (it looks to me that it's especially true for GTK applications like xmms or gmplayer, but it's in no way GTK specific) don't have a decent X protocol error handler and they will abort ungracefully in this case. So this is a Heads Up message for application developpers, to add a correct X protocol errors handler to their applications and to make this handler aware of the BadAccess errors that untrusted clients may get. Thanks for listening. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6-enabled XFree86 4.4.0 with IPv4-only kernel
David Dawes wrote (in a message from Thursday 8) I need to make a correction to that. While I could have sworn that it was the default on all platforms, it is only the default on a few platforms (including Linux though). I think it should be the default everywhere. Something like the attached patch (relative to the current CVS trunk) would do it. I think this should be commited. In fact it looks like my last test on a IPv4 only kernel was before the last change in the logic there. I've commited a patch to add -DPART_NET to OpenBSD.cf and was about to do the same for NetBSD.cf, but I'll be happy to revert the OpenBSD.cf part if we change the default. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: documentation of the format of files in xkb/symbols?
Sven Köhler wrote (in a message from Monday 5) Hi, i want to write a keyboard-layout or keymap that ignores any key. the problem is, that i don't find any documentation on how to write such files or which commands are available. you may also have a better idea how to disbale the keyboard under X. Using the void-Driver doesn't work for me, since DontVTSwitch won't work when using the void-Driver. You'll find some documentation here: http://pascal.tsu.ru/en/xkb/ Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cannot compile current CVS
Pavel Troller wrote (in a message from Saturday 3) Hello, dear XF86 developers, first of all, happy New Year to all of You and to the XF86 project! And now, the problem: I cannot compile CVS from about 2.1.2004 up. Formerly it compiled perfectly (about 20.12.). The problem is the following: gcc -m32 -c -O6 -fomit-frame-pointer -march=i586 -mcpu=i586 -fforce-addr -fforce-mem -ansi -pedantic -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs-fno-merge-constants -I. -I../include -I../../../exports/include/X11 -I../../../include/extensions -I../../../programs/Xserver/Xext -I../../../include/fonts -I../../../programs/Xserver/render -I../../../lib/Xau -I../lbx -I../../.. -I../../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPIXPRIV -DPANORAMIX -DRENDER -DRANDR -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER -DXFree86Server -DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE -DBUILDDEBUG -DXResExtension -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG! ! -DFUNCPROTO=15 -DNARROWPROTO -DXSERV_t -DTRANS_SERVER -DUNIXCONN -DTCPCONN -DHAS_STICKY_DIR_BIT -DHAS_FCHOWN -DIPv6 -DDDXOSINIT -DSERVER_LOCK -DDDXOSFATALERROR -DDDXOSVERRORF -DDDXTIME -DPART_NET -DUSE_RGB_TXT -DXDMCP access.c access.c: In function `DefineSelf': access.c:780: structure has no member named `ifa_addr' make[4]: *** [access.o] Error 1 make[4]: Leaving directory `/usr/src/cvs-xc/programs/Xserver/os' make[3]: *** [os] Error 2 make[3]: Leaving directory `/usr/src/cvs-xc/programs/Xserver' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/src/cvs-xc/programs' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/cvs-xc' make: *** [all] Error 2 I'm trying to compile on a Linux box with 2.4.23 kernel, glibc 2.3.1. IPv6 is enabled on this host. Sorry. This has been fixed in -current CVS. Wait for the next update or appley the following patch: Index: access.c === RCS file: /cvs/xf86/xc/programs/Xserver/os/access.c,v retrieving revision 3.52 retrieving revision 3.53 diff -u -r3.52 -r3.53 --- access.c1 Jan 2004 15:03:37 - 3.52 +++ access.c2 Jan 2004 18:23:19 - 3.53 @@ -45,7 +45,7 @@ SOFTWARE. **/ -/* $XFree86: xc/programs/Xserver/os/access.c,v 3.52 2004/01/01 15:03:37 herrb Exp $ */ +/* $XFree86: xc/programs/Xserver/os/access.c,v 3.53 2004/01/02 18:23:19 tsi Exp $ */ #ifdef WIN32 #include X11/Xwinsock.h @@ -777,7 +777,7 @@ continue; #if defined(IPv6) defined(AF_INET6) if (family == FamilyInternet6) - in6_fillscopeid((struct sockaddr_in6 *)ifr-ifa_addr); + in6_fillscopeid((struct sockaddr_in6 *)IFR_IFR_ADDR); #endif #ifdef DEF_SELF_DEBUG if (family == FamilyInternet) Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XDMCP problems (was: [XonX-Announce] XFree86 4.4.0 RC2)
I removed the HasGetIfAddrs definition from darwin.cf again and tried a different aproach to solve the XDMCP problem. I reordered the connections in a way that connections of the same type as the XDMCP manager connection are send first. And it worked. :-) Thanks, I've commited this patch. I've also commited a fix for the original problem in XDM (returning out of memory when an unsuppoted connection type is sent first in the request paquet) by impementing a policy in SelectConnectionTypeIndex() (in xdm/policy.c) to choose a connexion type that is supported. P.S. two problems still are left unresolved: -broadcast does not send XDMCP requests to a broadcast address and DefineSelf() does not deliver IPv6 addresses when HasGetIfAddrs is set. I've fixed the the IPv6 problem with getifaddrs() and enabled HasGetIfAddrs for darwin, so -broadcast works now. There are still 2 problems remaining : -multicast doesn't seem to work on Darwin the query packets are sent but xdm doesn't see them. And for now the link-local address for the loopback interface (fe80::1) is still (wrongly) advertized in the request packet. I hope to be able to fix these problems soon. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Building a single program for debugging
Ross Boylan wrote (in a message from Thursday 1) I'm interested in building xterm for debugging on a system that already has a full install of XFree 4.2.1 (Debian GNU/Linux). I realize most of you are probably thinking about newer versions of XFree, but I'm hoping someone might have some useful advice on this list. Any tips about how to do a partial, debugging build? Or about xterm? I notice the comments saying the code is a mess; I'm really just interested in identifying the font it thinks its using and the font lookup and rendering system that it relies on--core, xft1, or xft2. (xterm gets me a font that is very s p a c e d o u t, while xterm -fn fixed works fine. I've been unable to duplicate the font I get with xterm alone using any specific -fn or -fa argument). There are some instructions on how to rebuild parts of the XFree86 source tree for debugging here: http://www.openbsd.org/cgi-bin/cvsweb.cgi/~checkout~/XF4/README?rev=1.12content-type=text/plain This was written for the XFree86 tree in OpenBSD, but most of it applies regardless of the operating system. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XDMCP problems (was: [XonX-Announce] XFree86 4.4.0 RC2)
Mario Klebsch wrote (in a message from Tuesday 30) Hi! I tried your fix of the call to XdmcpFlush() and it works for me. Thank you. Unfortunately, the -broadcast flag still does not work. The X server sends the XDMCP queries to its own IP address instead of using the networks broadcast address. I can't reproduce it here. But there are 2 things that may influence that : 1. I'm using '#define HasGetIfAddrs YES' in darwin.cf (This should probably be the default, but I forgot about it until now), it changes the way network interfaces addresses are collected. 2. I've just commited a fix for a stupid typo in Xserver/os/access.c that was causing localhost addresses to be advertized by error in the 'Request' message. Can you try these 2 things ? Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
fix manual page building on Mac OS X
Hi, The process that builds XFree86 manual pages needs cpp -traditional when GNU cpp is used. I'd propose to apply the following patch do darwin.cf. Index: darwin.cf === RCS file: /cvs/xf86/xc/config/cf/darwin.cf,v retrieving revision 1.46 diff -u -r1.46 darwin.cf --- darwin.cf 18 Nov 2003 19:00:14 - 1.46 +++ darwin.cf 29 Dec 2003 09:15:28 - @@ -153,6 +153,7 @@ */ #if OSMajorVersion = 7 # define CppCmd /usr/bin/cpp3 +# define StandardCppOptions-traditional #else # define CppCmd /usr/bin/cpp #endif Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
via driver build fix
Ok? Index: via_driver.c === RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/via/via_driver.c,v retrieving revision 1.18 diff -u -r1.18 via_driver.c --- via_driver.c24 Dec 2003 02:36:46 - 1.18 +++ via_driver.c29 Dec 2003 11:28:58 - @@ -2430,8 +2430,7 @@ if(!pVia-NoAccel) viaInitVideo(pScreen); else - xf86DrvMsg(pScrn-scrnIndex, X_INFO, Acceleration disabled; no Xvideo support.\n, - pScrn-virtualX, pScrn-virtualY); + xf86DrvMsg(pScrn-scrnIndex, X_INFO, Acceleration disabled; no Xvideo support.\n); } if (serverGeneration == 1) Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.3.902 bug report
Kean Johnston wrote (in a message from Sunday 21) I think you're right here. Since we can't assume that every platform on which XFree86 is built has C99 types and that there's no previous art of using uint32_t instead of the older u_int32_t in the XFree86 tree, the SCO diff should be reverted and changed to something that will define u_int32_t on SCO if needed. I can do that but there's not much prior art of using u_int32_t either. In fact, just one file: loader/xf86sym.c, and a few header files, most of which seem BSD related. And equally small number use uint32_t. I didnt run into problems before your checking at revision 3.18. Perhaps the best way to avoid this is to use neither ... simply use unsigned int? We settled down for using CARD32 for now. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.3.902 bug report
Kean Johnston wrote (in a message from Sunday 21) We settled down for using CARD32 for now. Mmmm ok. I just finished taking a closer look at where the variable was being used and it is more appropriate to use unsigned int. The two functions that it is calling above are both prototyped to take unsigned int's. CARD32 will work too but it generates 4 extra warnings whereas unsigned int doesn't. But I'm not emotionally attached to either solution :) ints can be 64 bit long on some weird machines (CRay I think was one of them). Here the lenght of the type matters, so better don't loose this information. Which compiler are you using ? CARD32 is typedef'd to an unsigned int. And none of the compilers I use is generating a warning for such casts. But well the pmd5* functions can have their prototypes fixed. These are all static functions local to this file. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.3.902 bug report
Warren Turkal wrote (in a message from Saturday 20) The uint32_t in xc/programs/xdm/genauth.c doesn't compile on my computer. It appears that stdint.h needs to be included somewhere (most likely Xos.h), but it is not. It appears that uint32_t was changed from u_int32_t in some SCO fixes. I have included output from trying to compile below. I think you're right here. Since we can't assume that every platform on which XFree86 is built has C99 types and that there's no previous art of using uint32_t instead of the older u_int32_t in the XFree86 tree, the SCO diff should be reverted and changed to something that will define u_int32_t on SCO if needed. For a later XFree86 release we shoud consider switching to C99 types everywhere and providing definitions for systems that don't have stdint.h nor inttypes.h. But this is not something to do so close to a release. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.3.902 bug report
I wrote (in a message from Saturday 20) Warren Turkal wrote (in a message from Saturday 20) The uint32_t in xc/programs/xdm/genauth.c doesn't compile on my computer. It appears that stdint.h needs to be included somewhere (most likely Xos.h), but it is not. It appears that uint32_t was changed from u_int32_t in some SCO fixes. I have included output from trying to compile below. I think you're right here. Since we can't assume that every platform on which XFree86 is built has C99 types and that there's no previous art of using uint32_t instead of the older u_int32_t in the XFree86 tree, the SCO diff should be reverted and changed to something that will define u_int32_t on SCO if needed. On a 2nd thought, I guess using CARD32 here is fine. I have somewhere the idea that CARD32 and such types were reserved to describe the on-the-wire X protocol, but there are alreadt many (ab)uses of it in some drivers. semantically CARD32 is the same as uint32_t and u_int32_t anyways. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Via driver build problems
I need the attached patch to build the latest via driver on platforms
without DRI. But this raises the question: shouldn't XFREE_44 be
defined for this driver ?
Index: xc/programs/Xserver/hw/xfree86/drivers/via/via_memory.c
===
RCS file: /cvs/xf86/xc/programs/Xserver/hw/xfree86/drivers/via/via_memory.c,v
retrieving revision 1.1
diff -u -r1.1 via_memory.c
--- xc/programs/Xserver/hw/xfree86/drivers/via/via_memory.c 17 Dec 2003 18:58:35
- 1.1
+++ xc/programs/Xserver/hw/xfree86/drivers/via/via_memory.c 17 Dec 2003 22:59:08
-
@@ -82,8 +82,11 @@
unsigned long VIAAllocLinear(VIAMemPtr mem, ScrnInfoPtr pScrn, unsigned long size)
{
-#ifdef XF86DRI
+#if defined(XF86DRI) || !defined(XFREE_44)
VIAPtr pVia = VIAPTR(pScrn);
+#endif
+
+#ifdef XF86DRI
if(mem-pool)
ErrorF(VIA Double Alloc.\n);
Matthieu
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: [PATCH] Update gnu.cf and add support for GNU/K*BSD
Robert Millan wrote (in a message from Friday Nov 21) --- xc/config/cf.old/Imake.cf2003-11-20 23:45:05.0 +0100 +++ xc/config/cf/Imake.cf2003-11-21 00:13:21.0 +0100 @@ -177,6 +177,11 @@ # endif /* __hppa__ */ #endif /* OpenBSD */ +/* Systems based on kernel of OpenBSD */ +#if defined(__OpenBSD__) || defined(__OpenBSD_kernel__) +#define KOpenBSDArchitecture +#endif + #ifdef __NetBSD__ # define MacroIncludeFile NetBSD.cf # define MacroFile NetBSD.cf @@ -224,6 +229,11 @@ # endif #endif /* NetBSD */ +/* Systems based on kernel of NetBSD */ +#if defined(__NetBSD__) || defined(__NetBSD_kernel__) +#define KNetBSDArchitecture +#endif + #ifdef __FreeBSD__ # define MacroIncludeFile FreeBSD.cf # define MacroFile FreeBSD.cf @@ -254,6 +264,11 @@ # endif #endif /* __FreeBSD__ */ +/* Systems based on kernel of FreeBSD */ +#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) +#define KFreeBSDArchitecture +#endif + #ifdef AMOEBA /* Should be before the 'sun' entry because we may be cross-compiling */ # define MacroIncludeFile Amoeba.cf @@ -962,10 +977,20 @@ #define i386Architecture #endif /* minix */ -#ifdef MACH -#ifdef __GNU__ +/* Systems with GNU libc and userland */ +#if defined(__GNU__) || defined(__GNU_KFreeBSD__) || \ + defined(__GNU_KNetBSD__) || defined(__GNU_KOpenBSD__) +#define GNUArchitecture #define MacroIncludeFile gnu.cf #define MacroFile gnu.cf +#ifdef __i386__ +#define i386Architecture +#endif +#endif + +#ifdef MACH +#ifdef __GNU__ +/* Mach-based GNU system */ #define GNUMachArchitecture #else #define MacroIncludeFile mach.cf This patch together with the one in bugzilla #908 broke XFree86 builds on OpenBSD on everything but i386. By inspection of the code, I guess it also breaks FreeBSD and NetBSD on non i386 platforms. The problem is that the patch above fails to define K*BSDArchitecture because __*BSD__ is #undef'd before the attempt to define the former. The following patch to Imake.cf makes it behave as intended and causes the current code in xc/programs/Xserver/hw/xfre86/os-support/Imakefile to work again. But systems that don't define BUS_SUBDIR will fail anyways. So maybe it's better to remove the gigantic test to define BUS_SUBDIR? --- xc/config/cf/Imake.cf.orig Mon Dec 15 20:32:07 2003 +++ xc/config/cf/Imake.cf Mon Dec 15 20:33:21 2003 @@ -102,6 +102,7 @@ # undef __OpenBSD__ # undef __NetBSD__ # define OpenBSDArchitecture +# define KOpenBSDArchitecture # define MacroIncludeFile OpenBSD.cf # define MacroFile OpenBSD.cf # ifdef __i386__ @@ -178,7 +179,7 @@ #endif /* OpenBSD */ /* Systems based on kernel of OpenBSD */ -#if defined(__OpenBSD__) || defined(__OpenBSD_kernel__) +#if defined(__OpenBSD_kernel__) #define KOpenBSDArchitecture #endif @@ -187,6 +188,7 @@ # define MacroFile NetBSD.cf # undef __NetBSD__ # define NetBSDArchitecture +# define KNetBSDArchitecture # ifdef __i386__ # define i386BsdArchitecture # define i386Architecture @@ -230,7 +232,7 @@ #endif /* NetBSD */ /* Systems based on kernel of NetBSD */ -#if defined(__NetBSD__) || defined(__NetBSD_kernel__) +#if defined(__NetBSD_kernel__) #define KNetBSDArchitecture #endif @@ -239,6 +241,7 @@ # define MacroFile FreeBSD.cf # undef __FreeBSD__ # define FreeBSDArchitecture +# define KFreeBSDArchitecture # ifdef __i386__ # define i386BsdArchitecture # define i386Architecture @@ -265,7 +268,7 @@ #endif /* __FreeBSD__ */ /* Systems based on kernel of FreeBSD */ -#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) +#if defined(__FreeBSD_kernel__) #define KFreeBSDArchitecture #endif Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: REGION_* rework (CVS Update: xc (branch: trunk))
Marc Aurele La France wrote (in a message from Wednesday 3) On Thu, 4 Dec 2003, Harald Nordgård-Hansen wrote: Marc Aurele La France [EMAIL PROTECTED] writes: Log message: An improved implementation of ... 573. Rework REGION_* macros to eliminate NEED_SCREEN_REGIONS build failures (Marc La France). ... to eliminate the extra store that was introduced. I just tried to compile current HEAD here, and this change causes compilation errors in xc/programs/Xserver/Xext/security.c, which uses the REGION_*-macros. I guess that one needs updates as well. Details? I see no such failures here. I see that on OpenBSD too. I've not had time on investigate yet: cc -c -O2 -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes - Wmissing-declarations -Wnested-externs -Wundef -fno-stack-protector -I. -I../ include -I../../../exports/include/X11 -I../../../include/extensions -I../../../include/fonts -I../mi -I../render -I../../../programs/Xserver/hw/xfre e86/common -I../../../include/fonts -I../../.. -I../../../exports/ include -DCSRG_BASED -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DT OGCUP -DXF86BIGFONT -DDPMSExtension -DPIXPRIV -DPANORAMIX -DRENDER -DRANDR -D GCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -D XFree86LOADER -DXFree86Server -DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE -D BUILDDEBUG -DXResExtension -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG -DFUNCPROTO =15 -DNARROWPROTO -DMITMISC -DXTEST -DXTRAP -DXSYNC -DXCMISC -DXRECORD -DMITSH M -DBIGREQS -DXF86VIDMODE -DXF86MISC -DDBE -DDPMSExtension -DEVI -DSCREENSAVER - DXV -DXVMC -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_ MESA -DFONTCACHE -DRES -DDEFAULTPOLICYFILE=\/usr/X11R6/lib/X11/xserver/Secur ityPolicy\ security.c security.c: In function `SecurityCensorImage': security.c:1232: dereferencing pointer to incomplete type security.c:1233: dereferencing pointer to incomplete type security.c:1236: dereferencing pointer to incomplete type security.c:1236: warning: left-hand operand of comma expression has no effect security.c:1307: dereferencing pointer to incomplete type security.c:1308: dereferencing pointer to incomplete type *** Error code 1 Stop in /local/X11R6-test/build/programs/Xserver/Xext (line 1106 of Makefile). *** Error code 1 Stop in /local/X11R6-test/build/programs/Xserver (line 1380 of Makefile). *** Error code 1 Stop in /local/X11R6-test/build/programs (line 1026 of Makefile). *** Error code 1 Stop in /local/X11R6-test/build (line 977 of xmakefile). *** Error code 1 Stop in /local/X11R6-test/build (line 1057 of xmakefile). *** Error code 1 Stop in /local/X11R6-test/build (line 45 of Makefile). Exit 1 Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Compile error --- no lbx-zlib.h
xian xue wrote (in a message from Tuesday 2) Dear, I download xfree86-4.3.99-16 and compile it on a Athlon XP pc with an alsa geforce4 mx440 video card. System -- debian testing no X installed Gcc -- Gcc3.3.2 commandline: $make World world.log Error: The world log say at the last part lbx_zlib.h:55:18: zlib.h: No such file or directory followed by a long list of errors. You need to install the zlib-devel package, or set 'HasZlib' to NO in host.def before building XFree86. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Problem connecting to IPv4 in IPv6 format
David Dawes wrote (in a message from Thursday 27) Incidentally related to this is another problem I've run in to. Old FreeBSD X apps, that use a version of libc without IPv6 support, crash when run on a recent system when trying to connect to a remote display when using our newly built X libraries. I have a patch that restores compatibility to our X libraries by checking if the IPv6 libc support is available at run-time, and falling back to the IPv4 code otherwise. I think it is complete enough, but I'd like some feedback before committing it. I think that this particular case (using binary libraries with IPv6 enabled on a older libc which doesn't know at all about IPv6) is probably going to fail in applications too. I'm not sure if it's worth handling it inside of Xlib. There are enough issues and separate cases when the libraries are consistent wrt. IPv6 to handle not to add this additional complexity. But having said that, your patch seem to handle this particular situation and since it's the base for your 2nd patch that handles something more important, I guess both should go in. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Problem connecting to IPv4 in IPv6 format
A related problem is that I was not able to connect to a v4 only X server running on a machine which happens to have a DNS record, from a NetBSD or OpenBSD host with IPv6 configured. The following patch fixes that: Index: xc/lib/xtrans/Xtranssock.c === RCS file: /cvs/xf86/xc/lib/xtrans/Xtranssock.c,v retrieving revision 3.65 diff -u -r3.65 Xtranssock.c --- xc/lib/xtrans/Xtranssock.c 20 Nov 2003 00:41:37 - 3.65 +++ xc/lib/xtrans/Xtranssock.c 30 Nov 2003 16:36:34 - @@ -1639,7 +1639,11 @@ || ( ((addrlist-addr-ai_next != NULL) || (addrlist-addr != addrlist-firstaddr)) (olderrno == ENETUNREACH || olderrno == EAFNOSUPPORT || -olderrno == EADDRNOTAVAIL || olderrno == ETIMEDOUT)) +olderrno == EADDRNOTAVAIL || olderrno == ETIMEDOUT +#if defined(EHOSTDOWN) + || olderrno == EHOSTDOWN +#endif + )) #endif ) res = TRANS_TRY_CONNECT_AGAIN; Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
ICEauthority files and bugzilla #902
Hi, in order to fix the core dump described in bugzilla #902 http://bugs.xfree86.org/show_bug.cgi?id=902, I need help to understand the ICE auth specification. My understanding is that at least 3 fields (protocol name, netid and auth_name) cannot be of 0 length in an entry stored in a valid .ICEauthority. Can anyone confirm this ? If I'm wrong what are the correct rules ? Thanks in advance. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
libGL dependencies problems
Hi, while building -current XFree86 on Panther I get the following error: /usr/bin/gcc-3.3 -o glxinfo -Os -Wall -Wpointer-arith -no-cpp-precomp -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11 -L/usr/X11R6/lib ld: warning can't open dynamic library: /usr/X11R6/lib/libXxf86vm.1.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) ld: Undefined symbols: _XF86VidModeGetModeLine referenced from libGL expected to be defined in /usr/X11R6/lib/libXxf86vm.1.dylib _XF86VidModeQueryVersion referenced from libGL expected to be defined in /usr/X11R6/lib/libXxf86vm.1.dylib make: *** [glxinfo] Error 1 It looks indeed that libGL is referencing those symbols. OTOH, I don't see any reference to them in libMesaGL. So I guess something changed in a recent Mesa update... What about this patch ? (and similar changes to the other *Lib.tmpl) Matthieu Index: xc/config/cf/darwinLib.tmpl === RCS file: /cvs/xf86/xc/config/cf/darwinLib.tmpl,v retrieving revision 1.19 diff -u -r1.19 darwinLib.tmpl --- xc/config/cf/darwinLib.tmpl 4 Nov 2003 00:24:36 - 1.19 +++ xc/config/cf/darwinLib.tmpl 16 Nov 2003 18:11:37 - @@ -22,9 +22,9 @@ #define SharedXfontReqs $(LDPRELIB) $(FONTSTUBLIB) GzipLibrary $(FREETYPE2LIB) -flat_namespace #define SharedAppleWMReqs $(LDPRELIB) $(XLIB) -#define SharedGLReqs$(LDPRELIB) $(XLIB) +#define SharedGLReqs$(LDPRELIB) $(XLIB) $(XXF86VMLIB) #define SharedGLUReqs $(LDPRELIB) $(XLIB) $(GLXLIB) -#define SharedOSMesaReqs$(LDPRELIB) $(XLIB) $(GLXLIB) $(XXF86VMLIB) +#define SharedOSMesaReqs$(LDPRELIB) $(XLIB) $(GLXLIB) #define SharedSMReqs$(LDPRELIB) $(ICELIB) #define SharedXawReqs $(LDPRELIB) $(XMULIB) $(XTOOLLIB) $(XPMLIB) $(XLIB) #define SharedXaw6Reqs $(LDPRELIB) $(XMULIB) $(XTOOLLIB) $(XLIB) Index: xc/programs/glxinfo/Imakefile === RCS file: /cvs/xf86/xc/programs/glxinfo/Imakefile,v retrieving revision 1.8 diff -u -r1.8 Imakefile --- xc/programs/glxinfo/Imakefile 22 Nov 2002 22:56:03 - 1.8 +++ xc/programs/glxinfo/Imakefile 16 Nov 2003 18:12:44 - @@ -4,8 +4,8 @@ #if BuildGLULibrary -DEPLIBS = $(DEPGLULIB) $(DEPGLXLIB) $(DEPXLIB) -LOCAL_LIBRARIES = $(GLULIB) $(GLXLIB) $(XLIB) +DEPLIBS = $(DEPGLULIB) $(DEPGLXLIB) $(DEPXXF86VMLIB) $(DEPXLIB) +LOCAL_LIBRARIES = $(GLULIB) $(GLXLIB) $(XXF86VMLIB) $(XLIB) DEFINES = -DDO_GLU #else ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 specific patch to freetype-config.in
Matthieu Herrb wrote (in a message from Tuesday 28)
Unfortunately, -R is not a recognized option to ld on Darwin and
perhaps other platforms as well. This should be conditionalized in
some way. My configure-foo is fairly weak, but it appears that the
hardcode_libdir_flag_spec is the configure option that should be used
here, rather then a hardwired ELF loader specific option.
There's also bugzilla #832 that requests that the same is done for the
other xxx-config and xxx.pc files shipped by XFree86.
Here's the patch I intend to commit. I didn't want to use
EXTRA_LOAD_FLAGS directly, as its semantics is not clearly defined.
I've used 'hardcode_libdir_flag_spec' for consistancy with
autoconf/libtool.
Someone also mentionned possible issues on mixed 32/64 bits platforms
where a separate directory may be used for 64 bit versions of the
libraries; more work is needed in this case in other areas too...
Matthieu
Index: xc/config/cf/Imake.tmpl
===
RCS file: /cvs/xf86/xc/config/cf/Imake.tmpl,v
retrieving revision 3.151
diff -u -r3.151 Imake.tmpl
--- xc/config/cf/Imake.tmpl 29 Oct 2003 05:51:37 - 3.151
+++ xc/config/cf/Imake.tmpl 30 Oct 2003 22:52:38 -
@@ -991,6 +991,9 @@
#ifndef DefaultCplusplusOptions
#define DefaultCplusplusOptions /* floating point, etc. */
#endif
+#ifndef HardCodeLibdirFlag
+#define HardCodeLibdirFlag /**/
+#endif
#ifndef NoRConst
#define NoRConst NO /* YES if const for structs of funcs is bad */
#endif
Index: xc/config/cf/OpenBSDLib.rules
===
RCS file: /cvs/xf86/xc/config/cf/OpenBSDLib.rules,v
retrieving revision 1.9
diff -u -r1.9 OpenBSDLib.rules
--- xc/config/cf/OpenBSDLib.rules 11 Oct 2003 09:40:09 - 1.9
+++ xc/config/cf/OpenBSDLib.rules 30 Oct 2003 22:52:38 -
@@ -53,7 +53,10 @@
#define ExtraLoadFlags -Wl,-rpath,$(USRLIBDIRPATH) -Wl,-rpath-link,$(BUILDLIBDIR)
#endif
#endif
+#ifndef HardCodeLibdirFlag
+#define HardCodeLibdirFlag -Wl,-rpath,$(USRLIBDIRPATH)
#endif
+#endif /* UseElfFormat */
/*
* InstallSharedLibrary - generate rules to install the shared library.
Index: xc/config/cf/bsdLib.rules
===
RCS file: /cvs/xf86/xc/config/cf/bsdLib.rules,v
retrieving revision 3.24
diff -u -r3.24 bsdLib.rules
--- xc/config/cf/bsdLib.rules 18 Oct 2003 17:21:41 - 3.24
+++ xc/config/cf/bsdLib.rules 30 Oct 2003 22:52:39 -
@@ -201,6 +201,10 @@
#endif
#endif
+#ifndef HardCodeLibdirFlag
+#define HardCodeLibdirFlag -Wl,-rpath,$(USRLIBDIRPATH)
+#endif
+
#if !defined(ShlibGlobalsFlags)
#define ShlibGlobalsFlags -Wl,-Bsymbolic
#endif
Index: xc/config/cf/lnxLib.rules
===
RCS file: /cvs/xf86/xc/config/cf/lnxLib.rules,v
retrieving revision 3.51
diff -u -r3.51 lnxLib.rules
--- xc/config/cf/lnxLib.rules 25 Oct 2003 01:21:25 - 3.51
+++ xc/config/cf/lnxLib.rules 30 Oct 2003 22:52:39 -
@@ -85,7 +85,9 @@
# define ExtraLoadFlags -Wl,-rpath,$(USRLIBDIRPATH)
# endif
# endif
-
+# ifndef HardCodeLibdirFlag
+# define HardCodeLibdirFlag -Wl,-rpath,$(USRLIBDIRPATH)
+# endif
# if !defined(ShlibGlobalsFlags)
# define ShlibGlobalsFlags -Wl,-Bsymbolic
# endif
Index: xc/extras/fontconfig/fontconfig-config.in
===
RCS file: /cvs/xf86/xc/extras/fontconfig/fontconfig-config.in,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 fontconfig-config.in
--- xc/extras/fontconfig/fontconfig-config.in 4 Jun 2003 02:56:24 - 1.1.1.1
+++ xc/extras/fontconfig/fontconfig-config.in 30 Oct 2003 22:52:40 -
@@ -3,6 +3,7 @@
prefix=@prefix@
exec_prefix=@exec_prefix@
libdir=@libdir@
[EMAIL PROTECTED]@
includedir=@includedir@
version=@PACKAGE_VERSION@
@@ -85,7 +86,7 @@
if test $echo_libs = yes ; then
libs=-lfontconfig
if test ${libdir} != /usr/lib ; then
- echo -L${libdir} $libs
+ echo ${hardcode_libdir_flag_spec} -L${libdir} $libs
else
echo $libs
fi
Index: xc/extras/fontconfig/fontconfig.pc.in
===
RCS file: /cvs/xf86/xc/extras/fontconfig/fontconfig.pc.in,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 fontconfig.pc.in
--- xc/extras/fontconfig/fontconfig.pc.in 4 Jun 2003 02:56:24 - 1.1.1.1
+++ xc/extras/fontconfig/fontconfig.pc.in 30 Oct 2003 22:52:40 -
@@ -1,10 +1,11 @@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
Name: Fontconfig
Description: Font configuration and customization library
Version: @PACKAGE_VERSION@
-Libs: -L${libdir} -lfontconfig
+Libs: ${hardcode_libdir_flag_spec} -L${libdir} -lfontconfig
Cflags: -I${includedir}
Index: xc/extras/freetype2/builds/unix
Re: XFree86 specific patch to freetype-config.in
Torrey Lyons wrote (in a message from Monday 27) The following revision to xc/extras/freetype2/builds/unix/freetype-config.in is XFree86 specific and not in the Freetype tree: revision 1.2 date: 2003/05/05 16:12:27; author: dawes; state: Exp; lines: +29 -15 159. Make freetype-config more useful on NetBSD (#5693, Thomas Klausner). cvs diff -r xf-4_3-branch -r 1.2 freetype-config.in Index: freetype-config.in === RCS file: /home/x-cvs/xc/extras/freetype2/builds/unix/freetype-config.in,v retrieving revision 1.1.1.4 retrieving revision 1.2 diff -u -d -b -w -r1.1.1.4 -r1.2 --- freetype-config.in 15 Feb 2002 00:33:20 - 1.1.1.4 +++ freetype-config.in 5 May 2003 16:12:27 - 1.2 @@ -90,7 +90,7 @@ if test $echo_libs = yes ; then libs=-lfreetype if test @libdir@ != /usr/lib ; then - echo [EMAIL PROTECTED]@ $libs + echo -Wl,[EMAIL PROTECTED]@ [EMAIL PROTECTED]@ $libs else echo $libs fi Unfortunately, -R is not a recognized option to ld on Darwin and perhaps other platforms as well. This should be conditionalized in some way. My configure-foo is fairly weak, but it appears that the hardcode_libdir_flag_spec is the configure option that should be used here, rather then a hardwired ELF loader specific option. There's also bugzilla #832 that requests that the same is done for the other xxx-config and xxx.pc files shipped by XFree86. I'm going to handle it. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] Kerberos xfree
[EMAIL PROTECTED] wrote (in a message from Tuesday 28) What are the state of implementation of kerberos support in X? I try to compile X with flag HasKrb5 YES I'd say that it's basically unsupported. I don't think any X developper is currently using kerberos. The kerberos IV code was tested by OpenBSD people, but they have not yet tried to use the krb5 code. but it do not compiled. It wants very strange headers, which I do not found neither in mit-krb5, nor heimdal. What I ought to do to compile X with kerberos 5 support? I've no idea. But if someone wants to work on this and submit patches, he's welcome. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Problems with shared lesstif and shared Xt on Cygwin/XFree86
Torrey Lyons wrote (in a message from Saturday 25) The issue on Mac OS X is that most shared libraries want to be built as two-level namespace images. Two-level namespace images have significant advantages in loading speed, but they require that they have no unresolved symbols when linking the library. This is why the darwinLib.tmpl contains a complete list of every library's dependencies. Unfortunately this causes a problem with two shared libraries, Xt and Xfont. The problem is that these libraries are designed to have certain symbols undefined and to have theses references resolved at application link time by one of various other library choices. In the case of Xt, SM and ICE provide the default resolution of these symbols in darwinLib.tmpl (and cygwin.tmpl), but symbols with the same names from lesstif should be used instead when the application is linked with it. Two-level namespace libraries don't allow you to do that since all symbols get resolved at library link time, not application link time. Thus we fixed this problem by building libXt and libXfont as flat namespace images, which have the same linking semantics that most people on other *nixes are used to. Weak symbols can be used on systems that support them to solve this kind of issues. Does cygwin support them ? If so libXt and libXfont can be patched to provide weak definitions of the SM/ICE functions it needs instead of linking libXt against those libs. Matthieu ___ 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: error building shared libXau
Matthieu Herrb wrote (in a message from Tuesday April 1) Frank Liu wrote (in a message from Monday 31) I am trying to enable building shared lib for libXau, but got an error: ... gcc -o ./libXau.so.6.0~ -shared -Wl,-rpath,/usr/X11R6/lib -Wl,-soname,libXau.so.6 AuDispose.o AuFileName.o AuGetAddr.o AuGetBest.o AuLock.o AuRead.o AuUnlock.o AuWrite.o + rm -f libXau.so.6 + ln -s libXau.so.6.0 libXau.so.6 + rm -f ../../exports/lib/libXau.so.6 + cd ../../exports/lib /bin/sh: cd: /home/fliu/src/x/xc/exports/lib - No such file or directory apparently nobody created the directory ../../exports/lib I am wondering why I didn't get this error for building other shared libs such as those default libs that have shared enabled? Any ideas? Looks like a bug in many *lib.rules configuration files. The LinkBuildSonameLibrary() macro doesn't build the export/lib directory first. (The LinkBuildLibrary() macro used by non-shared libs does). It currently works with other shared libraries because the 1st built library is precisely libXau and its normally built non-shared only, so its build rule will indeed create the export/lib directory. If the 1st built library is shared and since the shared target appears 1st in Library.tmpl, the directory isn't created. This should be fixed. Better late then never. I just committed a fix for that. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: error building shared libXau
Frank Liu wrote (in a message from Tuesday Apr 1) more errors while final linking of XFree86, Xprt, Xnest, etc. eg: ... os/libos.a(auth.o): In function `LoadAuthorization': auth.o(.text+0x126): undefined reference to `XauDisposeAuth' auth.o(.text+0x135): undefined reference to `XauReadAuth' os/libos.a(xdmcp.o): In function `XdmcpRegisterAuthentication': xdmcp.o(.text+0x2ed): undefined reference to `XdmcpAllocARRAY8' xdmcp.o(.text+0x308): undefined reference to `XdmcpAllocARRAY8' ... If I build libXau and libXdmcp static, those errors will go away. do I need to add -lXau and -lXdmcp in the linking command line? Why static works? Because in the static case the libraries where on the command line as $(DEPLIBXAUTH) and $(DEPLIBXDMCP) - which are empty in the shared case. I'm going to fix that shortly too. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
add Sigma design chip to xf86PciInfo.h ?
Index: xc/programs/Xserver/hw/xfree86/common/xf86PciInfo.h === RCS file: /cvs/xf86/xc/programs/Xserver/hw/xfree86/common/xf86PciInfo.h,v retrieving revision 1.152 diff -u -r1.152 xf86PciInfo.h --- xc/programs/Xserver/hw/xfree86/common/xf86PciInfo.h 5 Sep 2003 21:59:43 - 1.152 +++ xc/programs/Xserver/hw/xfree86/common/xf86PciInfo.h 30 Sep 2003 19:57:24 - @@ -90,6 +90,7 @@ #define PCI_VENDOR_ALLIANCE0x1142 #define PCI_VENDOR_RENDITION 0x1163 #define PCI_VENDOR_3DFX0x121A +#define PCI_VENDOR_SIGMA_DESIGN0x1236 #define PCI_VENDOR_SMI 0x126F #define PCI_VENDOR_TRITECH 0x1292 #define PCI_VENDOR_NVIDIA_SGS 0x12D2 @@ -509,6 +510,9 @@ #define PCI_CARD_VOODOO3_2000 0x0036 #define PCI_CARD_VOODOO3_3000 0x003A + +/* Sigma design */ +#define PCI_CHIP_REALMAGIC64_GX0x6401 /* Rendition */ #define PCI_CHIP_V1000 0x0001 Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: embedded (GPL)Xfree86
jassi brar wrote (in a message from 26) Dear all, I m working on porting the X11 onto an embedded environment. The regular XFree86 is obviously MUCH MORE than needed. I need some trimmed version of XFree86 for embedded linux(mizi), that too under GPL(i can't buy any comercial s/w). Cud you plz suggest me some suggestion or link where i can find the same. I have extensively google'd without much luck :-( http://x2.freedesktop.org/Software/xserver is the new home of TinyX aka kdrive. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
build fixes for systems where BuildXF86DRI is NO
OK ?
Index: xc/programs/Xserver/hw/xfree86/drivers/mga/mga_driver.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/mga/mga_driver.c,v
retrieving revision 1.237
diff -u -r1.237 mga_driver.c
--- xc/programs/Xserver/hw/xfree86/drivers/mga/mga_driver.c 21 Sep 2003 01:20:20
- 1.237
+++ xc/programs/Xserver/hw/xfree86/drivers/mga/mga_driver.c 23 Sep 2003 22:34:43
-
@@ -2402,13 +2402,14 @@
xf86LoaderReqSymLists(shadowSymbols, NULL);
}
+#ifdef XF86DRI
/* Load the dri module if requested. */
if (xf86ReturnOptValBool(pMga-Options, OPTION_DRI, FALSE)) {
if (xf86LoadSubModule(pScrn, dri)) {
xf86LoaderReqSymLists(driSymbols, drmSymbols, NULL);
}
}
-
+#endif
pMga-CurrentLayout.bitsPerPixel = pScrn-bitsPerPixel;
pMga-CurrentLayout.depth = pScrn-depth;
pMga-CurrentLayout.displayWidth = pScrn-displayWidth;
Index: xc/programs/Xserver/hw/xfree86/drivers/tdfx/tdfx_driver.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/tdfx/tdfx_driver.c,v
retrieving revision 1.100
diff -u -r1.100 tdfx_driver.c
--- xc/programs/Xserver/hw/xfree86/drivers/tdfx/tdfx_driver.c 21 Sep 2003 01:20:20
- 1.100
+++ xc/programs/Xserver/hw/xfree86/drivers/tdfx/tdfx_driver.c 23 Sep 2003 22:34:52
-
@@ -1092,13 +1092,14 @@
pTDFX-writeLong(pTDFX, MISCINIT0, pTDFX-ModeReg.miscinit0);
#endif
+#ifdef XF86DRI
/* Load the dri module if requested. */
if (xf86ReturnOptValBool(pTDFX-Options, OPTION_DRI, FALSE)) {
if (xf86LoadSubModule(pScrn, dri)) {
xf86LoaderReqSymLists(driSymbols, drmSymbols, NULL);
}
}
-
+#endif
return TRUE;
}
Matthieu
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Exporting sched_yield to the drivers
Ian Romanick wrote (in a message from Monday 22) Mark Vojkovich wrote: Can we export to the drivers some function that yields the CPU? Currently alot of drivers burn the CPU waiting for fifos, etc... usleep(0) is not good for this because it's jiffy based and usually never returns in less than 10 msec which has the effect of making interactivity worse instead of better. I'm not sure which platforms don't export sched_yield() and which will need alternative implementations. There was a thread about this on the dri-devel list some months ago. The short answer is DON'T DO IT! :) I don't think that sched_yield will give the desired results in the 2D driver any more than it does in the 3D driver. I *believe* that there is another function for this purpose, but I can't recall what it is called. Sched_yield() is not portable enough. On most systems a poll() or select() with a zero timeout should be better. May be even nanosleep(0). Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 developer
Chaitanya Chaitanya wrote (in a message from Sunday 21) i want to be a XFree86 developer But how ? You should start by checking the mailing list archives... This question was asked exactly one week ago. Egbert Eich answered: Please check out this: http://www.xfree86.org/developer.html You can also find some info at http://xfree86.linuxwiki.org where I've started adding some development pages. And here was my answer: There are many ways to participate, depending on your level of knowledge about X in general, the XFree86 server and other related topics. You can contribute by developing code, testing existing code and providing feedback, by writing documentation, and probably other means that I don't have in mind right now. As a starting point, if you don't already have a precise idea of the area on which you'd like to help, you can browse the bugzilla database (http://bugs.xfree86.org/) and look for problems not yet solved for which you may be able to submit a solution. There have also been wish lists of new features posted (among other) to the [EMAIL PROTECTED] list; check the archives. The [EMAIL PROTECTED] list is aimed to be link between developpers (in the wide sense of the term, including documentation). If you have code to submit, use the bugzilla to submit it. The team of developpers with commit access will look at it and commit it into the XFree86 repository if it's worth. Documentation enhancements are very welcome too and can be submitted through bugzilla too. Commit access is proposed after some time to people who are regularly submitting code that gets included and/or who are working on an area of the XFree86 code not already well covered by existing commiters. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: C version of ucs2any.pl
David Dawes wrote (in a message from Friday 19)
If it does need to be done in the includes phase, for example, because
a host version of ucs2any is needed to do the conversion when
cross-compliling, but a target version of ucs2any needs to get built
later for installation,
After looking at some existing Imafiles, it doesn't look like the
existing cross-compiling code supports building the fonts. There's no
visible code to build bdftopcf as a host tool for example. And the 2
systems configs (itsy.cf and iPAQ.cf) that set CrossCompiling to YES,
also set BuildFonts to NO.
BTW, how are things like host vs target imake binaries handled when
cross-compiling?
Imake itself get built as a host tool during bootstrap, but not target
version is built or installed afaict.
Of course someone who actually uses the cross-compile support and
knowns better can always correct me if I'm wrong here.
In order to avoid such problems more easily in the future, I suggest
that for XFree86 5.0 we isolate the build of host tools in a separate
phase of the global process (bootstrap imake / Makefiles /
host-{includes,depend,all} / includes / depend / all / install).
Matthieu
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
C version of ucs2any.pl
Hi, It seems to me that the C langage version of ucs2any.pl developped by Ben Collver and other NetBSD developpers is now stable enough to be included in XFree86. I've put a patch against the current XFree86 CVS version at http://www.xfree86.org/~herrb/ucs2any.diffs for those who'd like to review it. I plan to commit that in the next days if no problems are found. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: developer XFree86
Alex Constantine wrote (in a message from Sunday 14) I would like to participate Well there are many ways to participate, depending on your level of knowledge about X in general, the XFree86 server and other related topics. You can contribute by developing code, testing existing code and providing feedback, by writing documentation, and probably other means that I don't have in mind right now. As a starting point, if you don't already have a precise idea of the area on which you'd like to help, you can browse the bugzilla database (http://bugs.xfree86.org/) and look for problems not yet solved for which you may be able to submit a solution. There have also been wish lists of new features posted (among other) to the [EMAIL PROTECTED] list; check the archives. The [EMAIL PROTECTED] list is aimed to be link between developpers (in the wide sense of the term, including documentation). If you have code to submit, use the bugzilla to submit it. The team of developpers with commit access will look at it and commit it into the XFree86 repository if it's worth. Documentation enhancements are very welcome too and can be submitted through bugzilla too. Commit access is proposed after some time to people who are regularly submitting code that gets included and/or who are working on an area of the XFree86 code not already well covered by existing commiters. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Wraphelp.c
Kean Johnston wrote (in a message from Wednesday 10) All, With the relaxing of US export restrictions is there any reason why Wraphelp.c isn't provided by default? Last time I checked, I was told DES is still restricted for exportation from the US to a list of countries like North Korea, Syria or Lybia. Other countries (like France) also have various export restrictions on crypto code. If XFree86 wants to be freely redistribuable, it should better stay away from crypto code in order to avoid all these regulations. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Warning related to SOCKLEN_TYPE in Xserver/os/xdmcp.c
David Dawes wrote (in a message from Monday 8) When building on FreeBSD 4.4 I'm getting the following warnings: The sa_len and sin_len fields are defined on this platform as u_char, while SOCKLEN_TYPE is defined as unsigned int. This looks like a potential problem given that the (u_char *) is dereferenced and written to as an (unsigned int *). oops, yes. What types to other BSD44SOCKETS platforms use for the sa_len and sin_len fields? They are both unsigned chars on Darwin, NetBSD and OpenBSD too. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ansifying
Warren Turkal wrote (in a message from Tuesday 9)
When ansifying from KR code, which order should the arguments come in?
KR code:
int
blah(x, y)
float y;
int x;
{ ... }
Does the KR code go to (1) or (2)?
(1)
int
blah(int x, float y)
{ ... }
(2)
int
blah(float y, int x)
{ ... }
I am guessing that (1) is the correct answer.
Yes. And this is a trap doing conversions semi-automatically. One need
to be careful.
Also, can you have KR and ansi function definitions in the same file?
Yes, you can. But if you are converting existing code to ANSI
prototypes, try to be complete :)
Matthieu
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: ansifying xwininfo.c
Thomas Dickey wrote (in a message from Tuesday 9) On Tue, 9 Sep 2003, Warren Turkal wrote: -#if NeedFunctionPrototypes -extern void scale_init(void); -extern char *nscale(int, int, int, char *); while I'm perfectly aware that extern is redundant, there are two things to be said in favor of keeping it: a) it's easy to grep for b) some compilers silently ignore conflicts with a static definition of the prototype, but can be persuaded to warn if the extern is explicit. (gcc does this, making it unsuitable as the only compiler to use for testing). ... and a 3rd reason is that 'extern' is not optional for variables. Most traditional Unix linkers will allow the same variable to be declared without 'extern' in multiple object files and merge them into only one, but this behaviour is not a feature one should rely on. And it fact, at least the Darwin linker treats this as an error. Doing the same for functions is more consistent. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Shared library inter-dependencies
I wrote (in a message from Friday 5) inter-dependencies are both good and bad. It's a good thing to list them at build time, It helps finding some kind of conflicts. OTOH, one should not rely on them to prune the list of libraries used to link an executable. First, this will break on static only build (yes there are still systems without shared libs these days), and then it can cause weird failures at run-time if the linker does not walk the full dependencies. So the *Lib.tmpl should be fixed to describe correct dependencies (on Darwin it's strictly required) and Imakefiles should list the full dependencies too. Hmm I forgot one point: sometimes you don't want to specify full dependencies for a library since there can be 2 differents libs capable to satisfy the dependency and you want to chose at application link time. The most current exemple is -lc_r vs -lc (or -lXThrstubs vs -lpthreads) on some systems for threaded vs non-threaded applications. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XDarwin build error
Hi, when building the latest XFree86 on Mac OS 10.2.4, I get link errors. A first one is easily fixed by the attached patch, but XDarwinApp also fails to link with the following error for which I can't find the missing code... making all in programs/Xserver/miext/rootless... make[4]: Nothing to be done for `all'. /usr/bin/cc -o XDarwinApp -Os -Wall -Wpointer-arith -no-cpp-precomp -L../../exports/lib dix/libdix.a os/libos.a ../../exports/lib/libXau.a ../../exports/lib/libXdmcp.a hw/darwin/libdarwin.a hw/darwin/quartz/libXQuartz.a hw/darwin/quartz/cr/libcr.a miext/rootless/librootless.a hw/darwin/quartz/aquaWindow.o hw/darwin/quartz/aquaPicture.o miext/shadow/libshadow.a fb/libfb.a Xext/libext.a xkb/libxkb.a lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a dbe/libdbe.a record/librecord.a XTrap/libxtrap.a randr/librandr.a render/librender.a dix/libxpstubs.a mi/libmi.a Xext/libext.a xkb/libxkb.albx/liblbx.a ../../lib/lbxutil/liblbxutil.a dbe/libdbe.a record/librecord.a XTrap/libxtrap.a randr/librandr.a render/librender.a -L/usr/X11R6/lib ../../lib/font/libXfont.a -lfreetype dix/libxpstubs.a -lz -framework IOKit -framework ApplicationServices -framework Cocoa ! -framework CoreAudio -framework Carbon -ObjC ld: Undefined symbols: _xp_configure_window _xp_disable_update _xp_frame_draw _xp_frame_get_rect _xp_frame_hit_test _xp_reenable_update make[3]: *** [XDarwinApp] Error 1 Here's the patch to build applewm.o: Index: Imakefile === RCS file: /cvs/xf86/xc/programs/Xserver/hw/darwin/quartz/Imakefile,v retrieving revision 1.9 diff -u -r1.9 Imakefile --- Imakefile 12 Aug 2003 23:47:10 - 1.9 +++ Imakefile 1 Sep 2003 21:15:30 - @@ -18,6 +18,7 @@ quartzPasteboard.c \ quartzStartup.c \ pseudoramiX.c \ + applewm.c \ aquaPicture.c \ aquaWindow.c \ $(APPLEWMSRC) @@ -32,6 +33,7 @@ quartzPasteboard.o \ quartzStartup.o \ pseudoramiX.o \ + applewm.o \ aquaPicture.o \ aquaWindow.o \ $(APPLEWMOBJ) Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: final issues... xfree86 for the VIA Apollo CLE266
On Tuesday, Aug 5, 2003, at 08:58 Europe/Paris, Aidan Kehoe wrote: Ar an 4ú lá de mí 8, scríobh George Georgalis : It works great, even if I kill X it comes back up, but it still listens on 6000. I find this odd, maybe I need to invoke it with Xfree86, not X? Hmm, that shouldn't make a difference. I've got -nolisten tcp working on this machine with the 4.3.99.5 snapshot; it's getting called as More recent snapshots have the IPv6 integrated, and on IPv6 capable systems, the handling of -nolisten has changed (and will probably change again before the next release). You should use '-nolisten inet4 -nolisten inet6' with the -current code to disable tcp sockets on both IPv4 and IPv6 addresses. A better solution that will make '-nolisten tcp' do that again is in the works. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
Keith Packard wrote (in a message from Wednesday 23) While supporting multiple -nolisten arguments is good, I suggest that the current '-nolisten tcp' should include both inet4 and inet6 tcp options; most people use '-nolisten tcp' to avoid exposing an open port to the X server to the network. -nolisten inet4 don't listen for TCP/IPv4 connections -nolisten inet6 don't listen for TCP/IPv6 connections -nolisten tcp don't listen for any TCP connections I agree here, except that it looks like Sun and X.Org are using inet for IPv4, not inet4. I'm going to do this change. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
I wrote (in a message from Sunday 27)
Keith Packard wrote (in a message from Wednesday 23)
While supporting multiple -nolisten arguments is good, I suggest that the
current '-nolisten tcp' should include both inet4 and inet6 tcp options;
most people use '-nolisten tcp' to avoid exposing an open port to the X
server to the network.
-nolisten inet4 don't listen for TCP/IPv4 connections
-nolisten inet6 don't listen for TCP/IPv6 connections
-nolisten tcp don't listen for any TCP connections
I agree here, except that it looks like Sun and X.Org are using inet
for IPv4, not inet4. I'm going to do this change.
Here's a proposed patch. When a -nolisten argument is an alias, it
will look for transport entries matching this alias (ie using the same
methods) and set the NOLISTEN flag there.
I plan to commit this in a few days, unless someone finds out that
this is wrong.
Matthieu
Index: xc/lib/xtrans/Xtrans.c
===
RCS file: /cvs/xf86/xc/lib/xtrans/Xtrans.c,v
retrieving revision 3.32
diff -u -r3.32 Xtrans.c
--- xc/lib/xtrans/Xtrans.c 24 Jul 2003 13:50:18 - 3.32
+++ xc/lib/xtrans/Xtrans.c 27 Jul 2003 17:26:30 -
@@ -131,6 +131,8 @@
#define ioctl ioctlsocket
#endif
+static int
+TRANS(AliasEq)(Xtransport *, Xtransport *);
/*
@@ -778,7 +780,8 @@
TRANS(NoListen) (char * protocol)
{
- Xtransport *trans;
+ Xtransport *trans, *t;
+ int i;
if ((trans = TRANS(SelectTransport)(protocol)) == NULL)
{
@@ -787,8 +790,23 @@
return -1;
}
-
- trans-flags |= TRANS_NOLISTEN;
+
+ /* If protocol is an alias, set the flag for all matching protocols */
+ if (trans-flags TRANS_ALIAS)
+ {
+ for (i = 0; i NUMTRANS; i++)
+ {
+ t = Xtransports[i].transport;
+ if (!strcmp(trans-TransName, t-TransName))
+ continue; /* skip self */
+ if (TRANS(AliasEq)(trans, t))
+ t-flags |= TRANS_NOLISTEN;
+ }
+ }
+ else
+ {
+ trans-flags |= TRANS_NOLISTEN;
+ }
return 0;
}
@@ -1386,4 +1404,62 @@
len = strlen(buf);
#endif /* NEED_UTSNAME */
return len;
+}
+
+static int
+TRANS(AliasEq)(Xtransport *t1, Xtransport *t2)
+{
+#ifdef TRANS_CLIENT
+ if (t1-OpenCOTSClient != t2-OpenCOTSClient)
+ return 0;
+#endif
+#ifdef TRANS_SERVER
+ if (t1-OpenCOTSServer != t2-OpenCOTSServer)
+ return 0;
+#endif
+#ifdef TRANS_CLIENT
+ if (t1-OpenCLTSClient != t2-OpenCLTSClient)
+ return 0;
+#endif
+#ifdef TRANS_SERVER
+ if (t1-OpenCLTSServer != t2-OpenCLTSServer)
+ return 0;
+#endif
+#ifdef TRANS_REOPEN
+ if (t1-ReopenCOTSServer != t2-ReopenCOTSServer)
+ return 0;
+ if (t1-ReopenCLTSServer != t2-ReopenCLTSServer)
+ return 0;
+#endif
+ if (t1-SetOption != t2-SetOption)
+ return 0;
+#ifdef TRANS_SERVER
+ if (t1-CreateListener != t2-CreateListener)
+ return 0;
+ if (t1-ResetListener != t2-ResetListener)
+ return 0;
+ if (t1-Accept != t2-Accept)
+ return 0;
+#endif
+#ifdef TRANS_CLIENT
+ if (t1-Connect != t2-Connect)
+ return 0;
+#endif
+ if (t1-BytesReadable != t2-BytesReadable)
+ return 0;
+ if (t1-Read != t2-Read)
+ return 0;
+ if (t1-Write != t2-Write)
+ return 0;
+ if (t1-Readv != t2-Readv)
+ return 0;
+ if (t1-Writev != t2-Writev)
+ return 0;
+ if (t1-Disconnect != t2-Disconnect)
+ return 0;
+ if (t1-Close != t2-Close)
+ return 0;
+ if (t1-CloseForCloning != t2-CloseForCloning)
+ return 0;
+ return 1;
}
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Forwarded from Jun-ichiro itojun Hagino: Re: IPv6 problems on Linux
---BeginMessage--- (todd and matthieu, if this does not go through please forward it) I wasn't suggesting to use it on Linux. My suggestion was to revert to using a single socket on all platforms and use the above code to enable accepting IPv4 connections on *BSD. there is security risk in using single socket, as outlined in draft-cmetz-v6ops-v4mapped-api-harmful-00.txt draft-itojun-v6ops-v4mapped-harmful-01.txt therefore, there are platforms which does not have IPV6_V6ONLY sysctl, and there are platforms which does not work at all with single socket (IPv4 packet does not get routed to IPv6). therefore, i suggest - on all platforms try to open 2 sockets, AF_INET6 then AF_INET - ignore error from socket(2) and bind(2) on both cases - raise error only if both attempt fails by doing this, - userland code works with IPv4-only kernel, IPv6-only kernel or IPv4/v6 dual stack kernel (independence from kernel configuration) - with linux IPv4/v6 dual stack case, it will use single AF_INET6 socket (with security risk described above) - other platforms should work with two sockets itojun ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ---End Message---
Re: IPv6 problems on Linux
Here's a patch to allow multiple '-nolisten' options on the command
line. To disable both IPv4 and IPv6 transports, one needs to say:
X -nolisten tcp -nolisten inet6
I'll add a documentation patch too later.
Index: xc/programs/Xserver/include/os.h
===
RCS file: /cvs/xf86/xc/programs/Xserver/include/os.h,v
retrieving revision 3.45
diff -u -r3.45 os.h
--- xc/programs/Xserver/include/os.h4 Jul 2003 16:24:29 - 3.45
+++ xc/programs/Xserver/include/os.h23 Jul 2003 20:34:47 -
@@ -480,5 +480,12 @@
extern void AbortDDX(void);
extern void ddxGiveUp(void);
extern int TimeSinceLastInputEvent(void);
+
+typedef struct NoListenList {
+ char *name;
+ struct NoListenList *next;
+} *NoListenListPtr;
+
+extern NoListenListPtr noListenList;
#endif /* OS_H */
Index: xc/programs/Xserver/os/connection.c
===
RCS file: /cvs/xf86/xc/programs/Xserver/os/connection.c,v
retrieving revision 3.61
diff -u -r3.61 connection.c
--- xc/programs/Xserver/os/connection.c 16 Jul 2003 01:39:00 - 3.61
+++ xc/programs/Xserver/os/connection.c 23 Jul 2003 20:34:47 -
@@ -186,7 +186,7 @@
Bool RunFromSmartParent; /* send SIGUSR1 to parent process */
Bool PartialNetwork; /* continue even if unable to bind all addrs */
-char *protNoListen; /* don't listen on this protocol */
+NoListenListPtr noListenList; /* don't listen on these protocols */
static Pid_t ParentProcess;
#ifdef __UNIXOS2__
Pid_t GetPPID(Pid_t pid);
@@ -309,6 +309,7 @@
inti;
intpartial;
char port[20];
+NoListenListPtr p;
FD_ZERO(AllSockets);
FD_ZERO(AllClients);
@@ -323,13 +324,13 @@
FD_ZERO (WellKnownConnections);
-sprintf (port, %d, atoi (display));
+snprintf (port, sizeof(port), %d, atoi (display));
-if (protNoListen)
-if (_XSERVTransNoListen(protNoListen))
-{
- FatalError (Failed to disable listen for %s, protNoListen);
- }
+for (p = noListenList; p != NULL; p = p-next) {
+ if (_XSERVTransNoListen(p-name)) {
+ FatalError(Failed to disable listen for %s, p-name);
+ }
+}
if ((_XSERVTransMakeAllCOTSServerListeners (port, partial,
ListenTransCount, ListenTransConns) = 0)
Index: xc/programs/Xserver/os/utils.c
===
RCS file: /cvs/xf86/xc/programs/Xserver/os/utils.c,v
retrieving revision 3.89
diff -u -r3.89 utils.c
--- xc/programs/Xserver/os/utils.c 9 Jul 2003 15:27:35 - 3.89
+++ xc/programs/Xserver/os/utils.c 23 Jul 2003 20:34:47 -
@@ -602,6 +602,7 @@
{
int i, skip;
+noListenList = NULL;
defaultKeyboardControl.autoRepeat = TRUE;
#ifdef PART_NET
@@ -816,8 +823,13 @@
#endif
else if ( strcmp( argv[i], -nolisten) == 0)
{
-if(++i argc)
- protNoListen = argv[i];
+ if(++i argc) {
+ NoListenListPtr p =
+ (NoListenListPtr)xalloc(sizeof(struct NoListenList));
+ p-name = argv[i];
+ p-next = noListenList;
+ noListenList = p;
+ }
else
UseMsg();
}
Matthieu
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: More IPv6 RedHat 6.2 problems compiles but doesn't work
Dr Andrew C Aitchison wrote (in a message from Monday 21) This is with RedHat 6.2. The latest IPv6 fixes allow X to compile, but remote connections no longer work on a machione without IPv6 configured. I've recompiled with XTRANSDEBUG set high (5 I think): % xbiff -display localhost:0 _X11TransOpenCOTSClient(tcp/localhost:0) _X11TransOpen(1,tcp/localhost:0) _X11TransParseAddress(tcp/localhost:0) _X11TransSelectTransport(tcp) _X11TransSocketOpenCOTSClient(tcp,localhost,0) _X11TransSocketSelectFamily(tcp) _X11TransSocketOpen(1,1) _X11TransSocketOpen: socket() failed for tcp _X11TransSocketOpenCOTSClient: Unable to open socket for tcp _X11TransOpen: transport open failed for tcp/localhost:0 Error: Can't open display: localhost:0 % strace shows socket(PF_INET6, SOCK_STREAM, 0) = -1 ENOSYS (Function not implemented) socket(PF_INET6, SOCK_STREAM, 0) = -1 ENOSYS (Function not implemented) socket(PF_INET6, SOCK_STREAM, 0) = -1 EAFNOSUPPORT (Address family not supported by protocol) Can you try with the '-nolisten inet6' option ? Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: a small twm/Imakefile patch
Alexander Pohoyda wrote (in a message from Monday 7) Does not really deserves a Bugzilla report (1K): http://www.alexander-pohoyda.privat.t-online.de/patches/twm.Imakefile.diff Can you elaborate on why is it useful to switch from single quote quoting to backslashes? Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: stack size
mnicolet wrote (in a message from Tuesday 8) May be this question is not strictly suited to this list, but I see lots of people contributing from lots of different platforms. The question regards to stack space management under different platforms, or execution models. Under my preferred platform ( QNX 4.25 ) stack space is allocated at process creation, and remains fixed until process death. Thas is so because the data segment layout leaves the heap on top, so it can grow easily. So, one must guess how much stack would be needed, and give the figure to the linker. The question is: are there some other ( not exotic, of course ) platforms that allows stack growing on demand ? i.e the stack as one segment by its own, which can be dynamically re-allocated during process lifetime ? On Unix-like systems (and I guess in modern MS Window too) the virtual memory system allows to allocate a large stack for each process. Real memory is used only as stack grows and as virtual addresses need to have real memory pages vired to them. There still is a physical fixed stack size limit, but it's generally set quite high. I don't know any system without shared memory that would behave this way. In VxWorks you specify the stack size at task creation and it's allocating memory from the global pool. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
fonttosfnt portability patch
Hi, Currently fonttosfnt doesn't compile on NetBSD, OpenBSD or Mac OS X (and probably others) because it depends on byteswap.h which is a linuxism. I've created Bugzilla #433 with a proposed patch. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Keyboard driver for X
Robert wrote (in a message from Sunday 15) Brad Hards schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 12 Jun 2003 14:57 pm, Jason Kim wrote: Has anyone developed keyboard driver for X ? Or does anyone know current situation? XFree86 4.x has loadable drivers, including keyboard. really ? i thought the keyboard is compiled into server??? There are 2 keyboard drivers in XFree86 4.3.0. One is the legacy X driver which is part of the base X server and the 2nd one is a new Xinput based driver which is dynamically loadable. The name of this loadable module is kbd (while the legacy driver is named keyboard). Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Bugzilla #306 (Building with #define BuildRender NO)
Hi, I've attached a proposed patch to Bugzilla #306. Please review and comment. I may have missed something important... Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: portability of function prototypes?
Alexander Stohr wrote (in a message from Saturday 12)
i am seeing constructs like this at
several locations of the XFree86 sources:
*.h:
extern char *Xpermalloc(
#if NeedFunctionPrototypes
unsingend int /* size */
#endif
);
*.c:
char *Xpermalloc(unsigned int length)
{ ... }
#if NeedFunctionPrototypes
XrmQuark XrmStringToQuark(
_Xconst char *name)
#else
XrmQuark XrmStringToQuark(name)
XrmString name;
#endif
{ ... }
for my impression the applied macro check
is obsolete nowadays and should not used
any longer for current coding. the phrase
inside the first #if #endif is a needed one.
i think for the second one the if-case is
probably the prefered coding style whilst
the else-case is the obsolete coding style.
am i right? this is a pure leftover?
or am i wrong and some targets do still
have some heavy dependencys on that?
are there some coding guidlines somewhere
in the tree that do outline on that subject?
i am personally targetting on compatible
coding and avoiding breakage of other codes.
This is a leftover from the times where X could get compiled on
non-ansi compiler. Since X11R6.3 an ANSI C compiler is needed.
There's no reason to use this in new code.
We are removing them slowly, whenever a file that still use them
is edited.
Matthieu
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: non-standart pointer device(ala mouse) how to implement ?
DaemonSerj wrote (in a message from Saturday 5) Hi! I have a special pointer-type device and need to implement functionality like mouse. Its work through COM port ,but it have own internal protocol and specific hardware. How to start? Write a new input driver for your device. You can use existing input drivers as an example. The input drivers are located in xc/programs/Xserver/hw/xfree86/input. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Matthieu Herrb wrote (in a message from Thursday 3) CVSROOT: /home/x-cvs Module name: xc Changes by: [EMAIL PROTECTED] 03/04/03 13:48:25 Log message: Document that mode switching functions are asynchronous and that XSetErrorHandler() and XSync() need to be used to get a synchronous like behaviour. (Bugzilla #22). This should read: Bugzilla #48. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: error building shared libXau
Frank Liu wrote (in a message from Monday 31) I am trying to enable building shared lib for libXau, but got an error: ... gcc -o ./libXau.so.6.0~ -shared -Wl,-rpath,/usr/X11R6/lib -Wl,-soname,libXau.so.6 AuDispose.o AuFileName.o AuGetAddr.o AuGetBest.o AuLock.o AuRead.o AuUnlock.o AuWrite.o + rm -f libXau.so.6 + ln -s libXau.so.6.0 libXau.so.6 + rm -f ../../exports/lib/libXau.so.6 + cd ../../exports/lib /bin/sh: cd: /home/fliu/src/x/xc/exports/lib - No such file or directory apparently nobody created the directory ../../exports/lib I am wondering why I didn't get this error for building other shared libs such as those default libs that have shared enabled? Any ideas? Looks like a bug in many *lib.rules configuration files. The LinkBuildSonameLibrary() macro doesn't build the export/lib directory first. (The LinkBuildLibrary() macro used by non-shared libs does). It currently works with other shared libraries because the 1st built library is precisely libXau and its normally built non-shared only, so its build rule will indeed create the export/lib directory. If the 1st built library is shared and since the shared target appears 1st in Library.tmpl, the directory isn't created. This should be fixed. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 host.def file questions
On Thursday, Mar 27, 2003, at 11:02 Europe/Paris, Aidan Kehoe wrote: That would be really useful. Also, defining HasParallelMake causes a obscure build failure for me on NetBSD 1.6P; it may be worth mentioning this in the docs so other people don't have to resort to binary search on customized host.defs :-) . Could you submit this report to the XFre86 bugzilla, so that we don't forget to look at this and hopefully fix it ? Parallel builds have beed mostly tested using GNU make on linux. Having them work with BSD make is a good thing. Matthieu Herrb ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xmkmf problems
Daniel Albuschat wrote (in a message from Monday 24) Could someone tell me how I can recompile the the radeon_drv.o from my xfree source tree after I made my changes (what i have actually done already)? Start by reading http://www.xfree86.org/4.3.0/BUILD.html which contains some informations. Another source is: http://www.openbsd.org/cgi-bin/cvsweb.cgi/XF4/README?rev=1.11content-type=text/plain This text is aimed for the XFree86 tree shipped with OpenBSD, but most of it is not specific to OpenBSD. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: I'm stuck: font-related crash with current CVS
Keith Packard wrote (in a message from Wednesday 19) Around 15 o'clock on Feb 19, Stuart Anderson wrote: This approach strikes me as being inherently non-portable wrt the module ABI. setjmp/longjmp are too system specific to be used in modules. Yes, they are rather system specific, but FreeType2 uses setjmp and longjmp extensively for error recovery. Disallowing setjmp and longjmp would make using FreeType2 rather difficult. Given that setjmp/longjmp are not thread safe, wouldn't it be better to have FreeType2 drop them in the future ? For the short term, makeing aliases for xf86setjmp/xf86longjump is probably good enough. Even if the binary compat is broken, the need to run a foreign OS font module is low, since they are open source. The use of xf86setjmp/xf86longjmp should be discouraged. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: LgProbe or AlpProbe undefined Symbol
Wayne Gowcher wrote (in a message from Wednesday 15) Can anyone tell me why dlopen is trying to resolve the sysmbols LgProbe and AlpProbe when module cirrus_drv.so is loaded ? Is it a problem with my compile ? With dlopen ? Any hints greatly appreciated. Please note if I comment both subprobe = LgProbe; and subprobe = AlpProbe; The cirrus module has sub-modules to handle alpine and laguna chipsets. It is supposed to load the appropriate sub-module once it has probed the chipset. For some reason the X server fails to load the sub-module in your case. I'm not familiar with Linux/mips so I don't know if it's expected that the X server uses the dlopen() based module loader instead of the internal XFree86 ELF loader on this platform. XFree86 modules don't work well with dlopen() and this method should be avoided if possible. On OpenBSD, I prefer to build a static X server (DoLoadableServer = NO) on architectures where the XFree86 loader doesn't work for some reason, than falling back to dlopen(). See section 17 of the DESIGN doc for more details. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xterm on Mac OSX
Hans Mittendorf wrote (in a message from Monday 13) Hello, Installing X11 on a Mac under OS 10.2.3 gave a problem related to typing inside xterm from a french keyboard. For typing m¹ I have ;¹. Changing keyboard to US via software, does not change anything. Therefore, my question: does XFree86 4.2.1 support french keyboards? Are you referring to XDarwin or the X11 package from Apple ? XDarwin has a global preference to set the keyboard layout, but it needs to be restarted to take effect. AFAIK Apple's X11 need a command line option to speficy the keyboard layout. Both X server can't change their layout from the main OS X menu bar. If you want to change your keyboard dynamically (ie without restarting X) on Mac OS X, you can use xmodmap(1). Appended below is set of xmodmap commands to set up an french layout keyboard. For more information see the xmodmap manual page. -- cut -- keycode 234 = Mode_switch remove mod1 = Alt_L remove mod1 = Alt_R add mod1 = Meta_L !add mod3 = Mode_switch !keysym Alt_L = Mode_switch Alt_L keycode 61 = at numbersign keycode 38 = ampersand 1 keycode 39 = eacute 2 keycode 40 = quotedbl 3 keycode 41 = apostrophe 4 keycode 42 = parenleft 5 keycode 43 = paragraph 6 keycode 44 = egrave 7 keycode 45 = exclam 8 keycode 46 = ccedilla 9 keycode 47 = agrave 0 keycode 53 = parenright degree keycode 54 = minus underscore keycode 50 = BackSpace Delete keycode 28 = A keycode 34 = Z keycode 55 = dead_circumflex dead_diaeresis keycode 56 = dollar asterisk keycode 12 = Q keycode 59 = M keycode 60 = ugrave percent keycode 58 = grave sterling keycode 108 = less greater keycode 37 = W keycode 24 = comma question keycode 62 = semicolon period keycode 63 = colon slash backslash bar keycode 64 = equal plus -- cut -- Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
Mike A. Harris wrote (in a message from Monday 13) I'd be interested also in hearing feedback and comments from Debian, Mandrake, SuSE, Gentoo, FreeBSD, NetBSD, OpenBSD, Caldera, and other Linux and BSD distribution XFree86 package maintainers, and other developers also. I've talked personally with some of them already, but the more who get involved the better. We all benefit, and everyone's feedback is very valuable. In my opinion, a bug tracking system would help, but as others already said, setting up and maintaining such a system in a useful state is a really time-consuming task. The Gnats systems used in OpenBSD (and in other BSDs too) is not perfect, but it has been proven itself useful in a few occasions, although not all submitted PRs get handled. On the other side, I've seen other projects where the bug tracking system totally failed : no one would take the time to fill reports and anyways no developper ever bothered to look at the few reports that were filed. A bug tracking software per itself doesn't prevent bug reports from staying unanswered for weeks nor does it automagically insure that fixes are correct. Only the work of the people reviewing and editing the contents of the database can produce those effects. If some people are seriously volunteering to go through a specification and review process to setup a system that will be bring something the project, let's start it. If done right it will help to focus developper attention on things that need fixing. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
