Re: porting xfree86 to new processor platform
Suresh Chandra Mannava wrote: here are my queries on porting xfree86 to this platform. We are going to cross-compile xfree86-4.2.0. Why not 4.3 or the release candidate? C Compiler: Based on GCC 2.95.3 Assembler:Based on GNU binutils 2.10.1 Linker: Based on GNU binutils 2.10.1 Disassembler: Based on GNU binutils 2.10.1 Archiver: Based on GNU binutils 2.10.1 Standard C library: GLIBC 2.2.5 Client requested us specifically port Xfree86-4.2.0, If above toolchain supports Xfree86-4.3.0, I will be happy to port that because, I read Xfree86 cross-compile system has been changed after the release of 4.2.0. I would try it if I were you. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: porting xfree86 to new processor platform
Suresh Chandra Mannava wrote: *snip* here are my queries on porting xfree86 to this platform. We are going to cross-compile xfree86-4.2.0. Why not 4.3 or the release candidate? *snip* wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Docs on writing an extension
Suzy Deffeyes wrote: Is appendix C of xlib.ps a good source? http://cvsweb.xfree86.org/cvsweb/xc/doc/hardcopy/X11/xlib.PS.gz IMO, this reference is not very detailed and needs significant expansion to be a useful resource. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: C++ code in Xfree86?
Suresh Chandra Mannava wrote: Is there any C++ code in Xfree86-4.2.0 source? I believe that GLU or something else GL related may have c++ code. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: building X11 in separate pieces
Mario Klebsch wrote: xlib is just a small layer on top of the XLib protocol. So what should be gained by using a different implementation? But without digging to deep into that question, does freedesktop only provide an alternative xlib or do they offer an alternative to XFree (providing a complete set of libraries (xlib, Xt, Xaw, ...) and the imake based build system? Freedesktop is intending to produce a full set of xlibs. All of the libs we have packaged are built with autotools. We have also broken many of the libs into their own packages so that pieces can be upgraded independently. We have added pkgconfig support to all libs so that autoconf can more easily detect libs and compile flags and link flags needed. We are hoping to do a number of things including moving to an XCB/XCL implementation in the near future. We would love it if XFree86 programs could be compiled against our libs so that we could test our libs more fully. Only having an xlib is not sufficient to build most X11 applications. We also have the canonical versions of the render extension, the randr extension, the kdrive server, and other goodies. Check it out at http://www.freedesktop.org or http://freedesktop.org/cgi-bin/viewcvs.cgi/?cvsroot=xlibs. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: building X11 in separate pieces
Mario Klebsch wrote: Am Samstag, 10.01.04 um 13:40 Uhr schrieb Warren Turkal: I never understood why so many people consider these autotools easier to use than the imake system. Imake (or to be precise, the config files included with X11) knows everything about the local X11 installation, where configure has to guess and far too often guesses wrong. I really do see no benefit in not using the imake system and I must admit that I do not understand why configure does not use an Imakefile to find out all the details needed to compile X11 programs on a given platform. Pkgconfig is meant to take care of providing these settings without resorting to brute force checks or manually assigning lib location and whatnot. It also provides a really simple autoconf macro in order to use this functionality. An example from our lib build system: PKG_CHECK_MODULES(X11, xextensions xtrans xcb) This is used to determine the presence of the the xextention, xtrans, and xcb libs. *snip* I hope X11 will keep the imake system. However if these efforts do get configure to reliably detect the X11 specific settings, I would be happy if this stuff is included in X11, so this pain finally get to an end. Detecting it with the brute force of old days is crappy. If someone has X installed in /usr/local/X/ instead of /usr/X11R6/, I don't think that autoconf will detect the libs right without pkgconfig or using a custom macro. pkgconfig is a solution that can be used in more than just one project and is an easier solution to maintain. I tried a while back to get the libX11 in XF86 to include pkgconfig files needed to do this kind of thing. You all didn't see the point. I would still like to do that if there is any interest in making autotools work better with the XF86 built environment. I still do not see, what is gained by this. As long, as the X11 protocol is still used, it should not matter, which libs are linked. BTW, it is easy to build everything of X11 except the Xserver. A simple setting in site.def will do the job. Different implementations of libX11 can be tested without copying them into the tree and making sure that they have the same build system as XF86. You could just install X11 somewhere on your system, make a copy of xmkmf, imake and its configuration, edit the config files according to your needs and compile the X11 programs using your new configuration. No changes should be needed anywhere inside of the X11 application directories. As a starting point you could pick up xlogo or xlock and compile them stand alone. just type Well, how do I do that and easily make them link against my libs? Can I do this for the entire tree? and it should do the job. I just did it for xclock and it worked fine. Just for curiosity, I tried it witk Xaw and it worked, too. Sou it seems, you can also build the X11 libs against your imake system and your config files as well as individual libs agaainst the rest of your package. So, now can I stop libX11 from compiling in the XF86 tree and force the tree to use an external libX11? I also tried it for lib/X11, but it failed. :-( It somehow references source files in a sibling directory named xtrans. xtrans itself does contain some code but does not produce anything when I run make. xmkmf simply creates some symbolic links. I am not sure, wether compiling libX11 standalone is is supposed to work. I am not only trying to use your Xlib with a new build system. We have a prototype of the XCB/XCL implementation that I would like to use during the build process. We have it building fine with autotools. How can I make the XF86 tree use this? Do you have the imake build system? X11 applications generally have an Imakefile, so you must have xmkmf, imake and the config files to build it. The only X11 apps that I know of that use imake are the ones that come with XF86. KDE, Gnome, and most oss projects use autotools. With pkgconfig support, it should make it easier in the future for them to detect what they need. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: building X11 in separate pieces
Thomas Dickey wrote: On Sat, 10 Jan 2004, Mario Klebsch wrote: They are not - within the imake build system. Outside it, there are two issues a) accommodating mis-installed or obsolete imake config files b) setting different compile-time options. included with X11) knows everything about the local X11 installation, where configure has to guess and far too often guesses wrong. I really do see no benefit in not using the imake system and I must admit that I do not understand why configure does not use an Imakefile to find out all the details needed to compile X11 programs on a given platform. I do that with xterm (but see (a) above). I hope X11 will keep the imake system. However if these efforts do get configure to reliably detect the X11 specific settings, I would be happy if this stuff is included in X11, so this pain finally get to an end. It'll take these people a long time to make it work properly other than for the trivial case of different Linux configurations, e.g., where the difficult autoconf checks are glossed over by hardcoding things. I believe that we have it working in all gcc based build environments that it can. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: building X11 in separate pieces
Mario Klebsch wrote: The libraries are no problem here, since the build system uses the system installed libs. The imake build system is flexible enough to use the just compiled but uninstalled libs, when called from make world but to use the system installed libs when called stand alone. Is it able to say build the whole tree with an externally built libX11? Is so, how would I tell it to do that? wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: building X11 in separate pieces
Mario Klebsch wrote: You cannot get anything worse than a compiler error. :-) BTW, what is your intention? I wanna use the freedesktop.org xlib with the XFree86 source tree. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
small build fix for Arm arch
The patch here makes the build system not assume that all arm systems are using netbsd. This was pulled from the Debian patch set. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org$Id: 301_not_all_arm_boxes_run_netbsd.diff 834 2003-12-10 07:13:21Z wt $ This patch by Michel Dänzer and Othmar Pasteka. --- xc/programs/Xserver/hw/xfree86/drivers/chips/ct_bank.c.orig 2002-10-03 19:06:39.0 + +++ xc/programs/Xserver/hw/xfree86/drivers/chips/ct_bank.c 2002-10-03 19:06:51.0 + @@ -53,12 +53,15 @@ /* Driver specific headers */ #include ct_driver.h -#ifdef __arm32__ -/*#include machine/sysarch.h*/ +#if defined(__arm32__) defined(__NetBSD__) +#include machine/sysarch.h #define arm32_drain_writebuf() sysarch(1, 0) -#define ChipsBank(pScreen) CHIPSPTR(xf86Screens[pScreen-myNum])-Bank +#elif defined(__arm32__) +#define arm32_drain_writebuf() #endif +#define ChipsBank(pScreen) CHIPSPTR(xf86Screens[pScreen-myNum])-Bank + #ifdef DIRECT_REGISTER_ACCESS int CHIPSSetRead(ScreenPtr pScreen, int bank)
Re: [PATCH] documentation fix addition for config/cf/README
David Dawes wrote: It still fails in the same way. Tabs have been converted to spaces, either by your mailer or because you cut'n'pasted it. Try sending it as an attachment. done wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org--- ../../../xc-old/config/cf/README 2003-04-25 06:00:03.0 -0500 +++ README 2003-12-10 22:47:32.0 -0600 @@ -25,7 +25,6 @@ CURDIR current directory relative to top of sources CcCmd command to run C compiler CompressCmd command to run compress program - GzipCmd command to run gzip program ConstructMFLAGS System V option to set MFLAGS make variable CpCmd command to copy one file to another CplusplusCmd command to run C++ compiler @@ -50,6 +49,7 @@ FortranCmd command to run Fortran compiler FortranDebugFlags flags for Fortran debug info FortranFlags Fortran compiler flags + GzipCmd command to run gzip program HasBSD44Sockets boolean for system has BSD4.4 sockets HasBsdMake use the 4.4BSD variant of the make program? HasBsearch boolean for libc has bsearch() @@ -218,6 +218,8 @@ DefaultUserPath default user xdm PATH environment variable DependCmd command to run makedepend DependDir build directory containing makedepend program + DriverManDir directory in which to install driver man pages + DriverManSuffix man suffix for driver pages ExtensionDefines -D's for universal extensions ExtensionOSDefines -D's for additional extensions FontCompilerFlags flags for bdftosnf @@ -246,6 +248,7 @@ ManSourcePath common prefix of man page directories ManSuffix man suffix for programs MiscManSuffix man suffix for miscellaneous pages + MiscManDir directory in which to install misc man pages NeedDefaultDepLibs boolean for enabling default DEPLIBS NlsDir directory in which to install nls files NormalLibFS build libFS.a
Re: [PATCH] documentation fix addition for config/cf/README
David Dawes wrote: On Wed, Dec 10, 2003 at 10:51:40PM -0600, Warren Turkal wrote: Can you re-send without the white space mangling? David I don't know what I did. Here it is again. It applies to 4.3.901. I am hoping it applies to HEAD also. wt --- ../../../xc-old/config/cf/README2003-04-25 06:00:03.0 -0500 +++ README 2003-12-10 22:47:32.0 -0600 @@ -25,7 +25,6 @@ CURDIR current directory relative to top of sources CcCmd command to run C compiler CompressCmd command to run compress program - GzipCmd command to run gzip program ConstructMFLAGS System V option to set MFLAGS make variable CpCmd command to copy one file to another CplusplusCmdcommand to run C++ compiler @@ -50,6 +49,7 @@ FortranCmd command to run Fortran compiler FortranDebugFlags flags for Fortran debug info FortranFlagsFortran compiler flags + GzipCmd command to run gzip program HasBSD44Sockets boolean for system has BSD4.4 sockets HasBsdMake use the 4.4BSD variant of the make program? HasBsearch boolean for libc has bsearch() @@ -218,6 +218,8 @@ DefaultUserPath default user xdm PATH environment variable DependCmd command to run makedepend DependDir build directory containing makedepend program + DriverManDirdirectory in which to install driver man pages + DriverManSuffix man suffix for driver pages ExtensionDefines-D's for universal extensions ExtensionOSDefines -D's for additional extensions FontCompilerFlags flags for bdftosnf @@ -246,6 +248,7 @@ ManSourcePath common prefix of man page directories ManSuffix man suffix for programs MiscManSuffix man suffix for miscellaneous pages + MiscManDir directory in which to install misc man pages NeedDefaultDepLibs boolean for enabling default DEPLIBS NlsDir directory in which to install nls files NormalLibFS build libFS.a -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
support for riscpc keycodes
Here is a goodie from the Debian patch set that applies to head. It adds
keycodes for riscpc. If keycodes don't step on each other, is there any way
this could be added before 4.4?
wt
$Id: 300_riscpc_xkb_keycodes.diff $
Thanks to Phil Blundell for this patch.
--- /dev/null Wed Dec 31 19:00:00 1969
+++ xc/programs/xkbcomp/keycodes/riscpc Mon Apr 8 21:09:03 2002
@@ -0,0 +1,130 @@
+// XFree86 codes for RiscPC
+
+default xkb_keycodes xfree86 {
+minimum = 8;
+maximum = 127;
+
+TLDE = 24;
+AE01 = 25;
+AE02 = 26;
+AE03 = 27;
+AE04 = 28;
+AE05 = 29;
+AE06 = 30;
+AE07 = 31;
+AE08 = 32;
+AE09 = 33;
+AE10 = 34;
+AE11 = 35;
+AE12 = 36;
+BKSP = 38;
+
+TAB = 46;
+AD01 = 47;
+AD02 = 48;
+AD03 = 49;
+AD04 = 50;
+AD05 = 51;
+AD06 = 52;
+AD07 = 53;
+AD08 = 54;
+AD09 = 55;
+AD10 = 56;
+AD11 = 57;
+AD12 = 58;
+RTRN = 79;
+
+CAPS = 101;
+AC01 = 68;
+AC02 = 69;
+AC03 = 70;
+AC04 = 71;
+AC05 = 72;
+AC06 = 73;
+AC07 = 74;
+AC08 = 75;
+AC09 = 76;
+AC10 = 77;
+AC11 = 78;
+
+LFSH = 84;
+BKSL = 37;
+LSGT = 59;
+AB01 = 86;
+AB02 = 87;
+AB03 = 88;
+AB04 = 89;
+AB05 = 90;
+AB06 = 91;
+AB07 = 92;
+AB08 = 93;
+AB09 = 94;
+AB10 = 95;
+RTSH = 96;
+
+LALT = 102;
+LCTL = 67;
+SPCE = 103;
+//RCTL = 54;
+RALT = 127;
+
+PRSC = 21;
+//SYRQ = 22;
+SCLK = 22;
+//PAUS = 31;
+BRK = 23;
+
+INS = 39;
+HOME = 40;
+PGUP = 41;
+DELE = 60;
+END = 61;
+PGDN = 62;
+
+UP= 97;
+LEFT = 106;
+DOWN = 107;
+RGHT = 108;
+
+NMLK = 42;
+KPDV = 43;
+KPMU = 44;
+KPSU = 45;
+
+KP7 = 63;
+KP8 = 64;
+KP9 = 65;
+KPAD = 83;
+
+KP4 = 80;
+KP5 = 81;
+KP6 = 82;
+
+KP1 = 98;
+KP2 = 99;
+KP3 = 100;
+KPEN = 111;
+
+KP0 = 109;
+KPDL = 110;
+
+ESC = 8;
+FK01= 9;
+FK02= 10;
+FK03= 11;
+FK04= 12;
+FK05= 13;
+FK06= 14;
+FK07= 15;
+FK08= 16;
+FK09= 17;
+FK10= 18;
+FK11= 19;
+FK12= 20;
+
+indicator 1 = Caps Lock;
+indicator 2 = Num Lock;
+indicator 3 = Scroll Lock;
+
+alias ALGR = RALT;
+};
--- xc/programs/xkbcomp/keycodes/Imakefile~ Mon Apr 8 21:11:18 2002
+++ xc/programs/xkbcomp/keycodes/Imakefile Mon Apr 8 21:11:38 2002
@@ -7,7 +7,7 @@
#define IHaveSubdirs
-DATAFILES = README amiga ataritt fujitsu hp ibm macintosh sony sun \
+DATAFILES = README amiga ataritt fujitsu hp ibm macintosh riscpc sony
sun \
xfree86 xfree98 powerpcps2 aliases
SUBDIRS = digital sgi
--
Warren Turkal
President, GOLUM, Inc.
http://www.golum.org
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: support for riscpc keycodes
David Dawes wrote: Our preferred method is to remap them internally. What do you mean by internally? Where can I find information that would help me do this in a way that would be optimal for you? wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Patch] Debian manpage locations
David Dawes wrote: On Fri, Dec 12, 2003 at 09:57:39AM -0600, Warren Turkal wrote: This changes the configuration, only for Debian, such that the manpages end up in the right places with the right names. I would be wonderful if this could be committed so this happens automatically for people compiling on Debian. How are you handling removing existing copies of the manpages with the old names? Which one will 'man' pick up if both exist? Removing the XFree86 packages installed will remove the existing if you had packages installed. This is standard location for XF86 manpages on Debian. Debian policy calls for following FHS which calls for all X11 manpages to be located in the following: /usr/X11R6/man/mansec/blah.secx Man goes through the MANDIR env var if looking for the first match, I suppose. BTW, right now, the Debian packages for 4.3.0 have a nasty patch that reworks manpage handling so that it fits the right scheme. This patch was not neccessary as even 4.3.0 had this functionality; it just wasn't documented (that's what the documentation patch for xc/config/cf/README was). This patch makes the manpages install in the right place by default. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Debian patches
I was messing around with the Debian packages a that are in the 4.3.0 Debian packages and trying to apply them to 4.3.901. I came across one that applied that I thought was already done. Does DPMS on ati radeon work in the 4.3.901? I could not find the bug in bugzilla that used to be associated with this problem even when I searched closed bugs. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[Patch] Debian manpage locations
This changes the configuration, only for Debian, such that the manpages end up in the right places with the right names. I would be wonderful if this could be committed so this happens automatically for people compiling on Debian. Also, is there any chance of that documentation patch I put on the list getting committed? wt diff -ruN xc-old/config/cf/linux.cf xc/config/cf/linux.cf --- xc-old/config/cf/linux.cf 2003-12-12 02:40:31.0 -0600 +++ xc/config/cf/linux.cf 2003-12-12 03:03:45.0 -0600 @@ -109,6 +109,12 @@ # define NormalLibGlu YES # define FSUseSyslog YES +# define DriverManSuffix 4x +# define DriverManDir $(MANSOURCEPATH)4 + +# define MiscManSuffix 7x +# define MiscManDir$(MANSOURCEPATH)7 + /* * * -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Debian patches
I was messing around with the Debian packages a that are in the 4.3.0 Debian packages and trying to apply them to 4.3.901. I came across one that applied that I thought was already done. Does DPMS on ati radeon work in the 4.3.901? I could not find the bug in bugzilla that used to be associated with this problem even when I searched closed bugs. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
of manpages and names
I was wondering if it is possible to get manpages to be named slightly different than default without major surgery. I will illustrate what I want with an example. Say I have a manpage xterm.man. It gets generated as xterm.1 stored in the $(INSTALL_DIR)/man/man1. I want to change the generated file to be xterm.1x instead. How would one accomplish this? Is there some Imake #define that can be set? Thanks a lot, wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: of manpages and names
Thomas Dickey wrote: That's ManSuffix, which is set in several files under config/cf Thanks very much. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[PATCH] documentation fix addition for config/cf/README
I moved the GzipCmd to get it in alphabetical order. I also added documentation for DriverManSuffix. wt --- README.old 2003-12-10 20:33:23.0 -0600 +++ README 2003-12-10 20:35:31.0 -0600 @@ -25,7 +25,6 @@ CURDIR current directory relative to top of sources CcCmd command to run C compiler CompressCmd command to run compress program - GzipCmd command to run gzip program ConstructMFLAGS System V option to set MFLAGS make variable CpCmd command to copy one file to another CplusplusCmdcommand to run C++ compiler @@ -50,6 +49,7 @@ FortranCmd command to run Fortran compiler FortranDebugFlags flags for Fortran debug info FortranFlagsFortran compiler flags + GzipCmd command to run gzip program HasBSD44Sockets boolean for system has BSD4.4 sockets HasBsdMake use the 4.4BSD variant of the make program? HasBsearch boolean for libc has bsearch() @@ -218,6 +218,7 @@ DefaultUserPath default user xdm PATH environment variable DependCmd command to run makedepend DependDir build directory containing makedepend program + DriverManSuffix man suffix for driver pages ExtensionDefines-D's for universal extensions ExtensionOSDefines -D's for additional extensions FontCompilerFlags flags for bdftosnf -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [PATCH] documentation fix addition for config/cf/README
Warren Turkal wrote: I moved the GzipCmd to get it in alphabetical order. I also added documentation for DriverManSuffix. This is an update of the previous. In addition to what is done in the last patch (this patch includes it), I also documented DriverManDir and MiscManDir. wt --- ../../../xc-old/config/cf/README2003-04-25 06:00:03.0 -0500 +++ README 2003-12-10 22:47:32.0 -0600 @@ -25,7 +25,6 @@ CURDIR current directory relative to top of sources CcCmd command to run C compiler CompressCmd command to run compress program - GzipCmd command to run gzip program ConstructMFLAGS System V option to set MFLAGS make variable CpCmd command to copy one file to another CplusplusCmdcommand to run C++ compiler @@ -50,6 +49,7 @@ FortranCmd command to run Fortran compiler FortranDebugFlags flags for Fortran debug info FortranFlagsFortran compiler flags + GzipCmd command to run gzip program HasBSD44Sockets boolean for system has BSD4.4 sockets HasBsdMake use the 4.4BSD variant of the make program? HasBsearch boolean for libc has bsearch() @@ -218,6 +218,8 @@ DefaultUserPath default user xdm PATH environment variable DependCmd command to run makedepend DependDir build directory containing makedepend program + DriverManDirdirectory in which to install driver man pages + DriverManSuffix man suffix for driver pages ExtensionDefines-D's for universal extensions ExtensionOSDefines -D's for additional extensions FontCompilerFlags flags for bdftosnf @@ -246,6 +248,7 @@ ManSourcePath common prefix of man page directories ManSuffix man suffix for programs MiscManSuffix man suffix for miscellaneous pages + MiscManDir directory in which to install misc man pages NeedDefaultDepLibs boolean for enabling default DEPLIBS NlsDir directory in which to install nls files NormalLibFS build libFS.a -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
simple patch for certain configs
Here is a patch from the Debian packages that fixes certain build configs. $Id: 017_fix_Xlib_depend_target.diff 586 2003-09-25 19:31:35Z branden $ This patch by Ishikawa MUTSUMI. Fixes build failure due to missing depend target in Xlib's Imakefile if BuildServersOnly is YES, BuildXnestServer is NO, and BuildGLXLibrary is NO. --- xc/lib/X11/Imakefile.orig 2003-02-20 11:41:45.0 -0500 +++ xc/lib/X11/Imakefile2003-02-20 11:41:48.0 -0500 @@ -1087,5 +1087,7 @@ #else all:: +depend:: + BuildIncludes($(HEADERS),IncSubdir,..) #endif -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
using externally built libs (Xcursor, Xrender, Xft)
Here is another patch from the Debian project. It comes in 3 parts. I basically allows XFree86 to build using an externally built libs. http://bugs.xfree86.org/show_bug.cgi?id=741 It wouldn't let me classify into multiple libraries...so I just associated it with other. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: simple patch for certain configs
David Dawes wrote: That just fixes one of the symptoms of IHaveSubdirs being defined in this case when it shouldn't be. The others remain. I'll commit a patch that fixes it properly. Thanks, David :-D -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: pkg-config support for libs
Mike A. Harris wrote: Should the /usr/X11R6 heirarchy be added to pkgconfig's default config? Perhaps it would be better if pkg-config provided an opaque way to add directories to the search paths. Does it have a config file in /etc. My Debian system doesn't have anything in /etc for pkg-config. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: pkg-config support for libs
David Dawes wrote: In five minutes I can come up with a dumb script that extracts the same information from imake. Proof of concept attached. Works for Xv, Xxf86misc, etc. Now dump the info into a .pc file so that it can be used with pkg-config. The point was not the method of my patch (I was following what is already in your cvs in xc/lib/Xft/). The point was to get pkg-config support. I will not deny that there was probably a better way to extract the info from imake. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: pkg-config support for libs
David Dawes wrote: I can only recall one case in my own experience where an autotooled program had a problem concerning X-related libs. Ironically those were exactly the libs that had pkgconfig support. The autotool and pkgconfig combination didn't know where to look for the needed .pc files. Assuming distribution packagers do their job, the .pc files will end up in the right place. For instance, I just committed the smaller version of the libX11 patch to Debian's XFree86 4.3 packages. By default, the pkg-config stuff is put into /usr/X11R6/lib/pkgconfig. For Debian (and possibly many others), the right directory is /usr/lib/pkgconfig. I manually shift the file (as many others are done). Warren -- President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
new patch for pkg-config in libX11 - much shorter
I found that I don't need some of the stuff I had in the patch. Here is a
new patch representing that knowledge.
diff -r -u3 -N xc/lib/X11/Imakefile 017_x11-pkg-config-enable.diff/xc/lib
X11/Imakefile
--- xc/lib/X11/Imakefile2002-11-25 20:31:23.0 -0600
+++ xc/lib/X11/Imakefile2003-09-18 04:23:45.0 -0500
@@ -1089,3 +1089,22 @@
BuildIncludes($(HEADERS),IncSubdir,..)
#endif
+
+
+SUBSTVARS=prefix=$(PROJECTROOT) \
+ exec_prefix=$(BINDIR) \
+ libdir=$(USRLIBDIR) \
+ includedir=$(INCROOT) \
+ PACKAGE_VERSION=$(SOXLIBREV) \
+
+all:: X11.pc
+
+X11.pc: X11.pc.in
+ RemoveFile($@)
+ sh config/config-subst $(SUBSTVARS) X11.pc.in $@
+
+InstallNonExecFile(X11.pc,$(USRLIBDIR)/pkgconfig)
+
+clean::
+ RemoveFile(X11.pc)
+
diff -r -u3 -N xc/lib/X11/X11.pc.in 017_x11-pkg-config-enable.diff/xc/lib
X11/X11.pc.in
--- xc/lib/X11/X11.pc.in1969-12-31 18:00:00.0 -0600
+++ xc/lib/X11/X11.pc.in2003-09-18 04:23:45.0 -0500
@@ -0,0 +1,11 @@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
+
+Name: X11
+Description: X11 library
+Version: @PACKAGE_VERSION@
+Requires: fontconfig
+Libs: -L${libdir} -lX11
+Cflags: -I${includedir}
diff -r -u3 -N xc/lib/X11/config/config-subst
017_x11-pkg-config-enable.diff/xc/lib/X11/config/config-subst
--- xc/lib/X11/config/config-subst 1969-12-31 18:00:00.0 -0600
+++ xc/lib/X11/config/config-subst 2003-09-18 04:23:45.0 -0500
@@ -0,0 +1,10 @@
+#!/bin/sh
+script=config-subst.$$
+trap rm $script 0
+rm -f $script
+for i in ${1+$@}; do
+ var=`echo $i | sed 's/=.*$//'`
+ val=`echo $i | sed 's/^[^=]*=//'`
+ echo s;@$var@;$val; $script
+done
+sed -f $script
--
President, GOLUM, Inc.
http://www.golum.org
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
pkg-config support for libs
I see that there are some libs in the cvs with pkg-config support. Will patches be accepted that add this support for other libs as well? Warren -- President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
synaptics relicensing
I opened my email today and got another response, and I got in touch with the developer whose email bounced. The totals for now are. no reply: S. Lehner [EMAIL PROTECTED] contacted: Henry Davies reviewing license approved: Stefan Gmeiner tentative Bruce Kall C. Scott Ananian Helwig Felger Peter Osterlund -- President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Audio in X11
Fred Heitkamp wrote: I was wondering. Was there ever an effort to make a network independent audio extension for X11? (forgive my terminology if it's wrong.) For example, if I am logged on from a remote terminal and want to play an MP3 from the distant machine on the remote terminal, is this possible? Sorry if this is a FAQ, but I didn't see one while googling. Arts is supposedly network transparent. -- President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: ansifying xwininfo.c
Alexander Stohr wrote: i have no reason to object to such patches. it was done in 100 kB sized tarballs for the XFree86 tree in the past and worked well that way. So who applies these patches then? I don't have CVS write, nor do I want it at this point. Warren Turkal -- President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
More sdk stuff
Is there any documentation other than reading Imake to figure out what gets included in the sdk...I am working on autotooling some of X, and maybe I would like to know how this sdk is currently constructed. Warren Turkal -- President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ansifying xwininfo.c
Warren Turkal wrote: Here is a patch ansifying xwininfo.c. I diffed the executable after the changes to the executable from before the changes, and they were the same. I have opened a bug report at http://bugzilla.xfree86.org/show_bug.cgi?id=677 Warren Turkal -- President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ansifying xwininfo.c
Thomas Dickey wrote: If a function's not used outside a given file, there's no reason to mark it extern... This is the minimum work to get this program into ansi shape. This patch is ready for inclusion. If their are no objections to the patch, it would be very nice to get this in ASAP. It will make some other projects I am working on go smoother. Thanks, Warren Turkal -- President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
synaptics lockups (was Re: radeon lockups ...)
Warren Turkal wrote: Michel Dänzer wrote: In that case it can hardly be an X problem. Sounds rather like the kernel (anything interesting in its output? Does the same thing happen with 2.4 kernels?) or hardware. I am testing 4.2.1 at this point to see if I come up with the same issues as with 4.3.0. Warren Turkal I came up with the same issues as with 4.3. It turns out that I was running a not-the-latest version of the synaptics event driver for XFree86. I looked in the changelog of the newest one, and it claims to have a work around for a bug in XFree86 that could cause lockups. Does this bug still exist? Here is link to the driver: http://w1.894.telia.com/~u89404340/touchpad/index.html I guess my personal suspicions that it was only locking while I was using the touchpad could have had some merit. I am sorry I did not mention that earlier. Is the synaptics driver to be included in XFree86 anytime soon since it is required with 2.6 kernels on computers with synaptics touchpads? You cannot use a regular ps2 mouse driver without lots of contortions (ie kernel options). Warren Turkal -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley wrote: No but you don't want to be a jerk and compete with somebody else. As if there were enough developers to go around that we'd steal each other's projects :-) Sometimes a little competition can improve the final product. Think lvm2 v. evms in the early 2.5 kernels. Warren -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch for ia64 page size
Mike A. Harris wrote: On Sun, 10 Aug 2003, Warren Turkal wrote: Date: Sun, 10 Aug 2003 19:06:58 -0500 From: Warren Turkal [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: patch for ia64 page size Here is a patch for page size problems on ia64 and radeon. Patch by Chris Ahna: Fixes critical page size problems on ia64 architecture. See following URL for details: https://external-lists.valinux.com/archives/linux-ia64/2001-August/002037.html Comment by [EMAIL PROTECTED]: Why are you submitting _my_ patch, without even asking me about it? If you had, I'd have told you that that patch is an ugly mess, not suitable for upstream submission for numerous reasons. It works, but it is far from clean and ready for inclusion in CVS. Before submitting my patches upstream, please contact me first to find out what my own plans are. I generally send patches upstream myself personally when I feel they are ready to be included upstream. If I haven't, it is a good idea to ask me why not first. I can save you some headaches. These patches are included in the debian packages for X. I was trying to make sure that the stuff got included in X so that other distributions could take advantage of it. I simply tried to make it apply and then sent it to the list in hopes that more knowledgable developers would let me know its status or include it if they chose. I was just trying to help. Warren Turkal -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
patch to disable vt switching on hurd
I cannot find any info about [EMAIL PROTECTED] on the xfree86.org website.
Therefore, I will post this here. This patch is to disable vt switching on
hurd as hurd does not support the VT_ACTIVATE ioctl. Once again, this patch
comes from the debian patch set, and I simply ported it to the current
snapshot.
This patch from Robert Millan.
--- xc/programs/Xserver/hw/xfree86/common/xf86Events.c.old 2003-04-11
15:03:23.0 +0200
+++ xc/programs/Xserver/hw/xfree86/common/xf86Events.c 2003-04-11
15:04:55.0 +0200
@@ -320,6 +320,9 @@
}
break;
#if !defined(__SOL8__) !defined(__UNIXOS2__) (!defined(sun) ||
defined(i386))
+#ifndef VT_ACTIVATE
+#warning missing VT_ACTIVATE ioctl; vt switching is disabled.
+#else
case ACTION_SWITCHSCREEN:
if (VTSwitchEnabled !xf86Info.dontVTSwitch arg) {
int vtno = *((int *) arg);
@@ -355,6 +358,7 @@
ErrorF(Failed to switch consoles (%s)\n, strerror(errno));
}
break;
+#endif /* VT_ACTIVATE */
#endif
case ACTION_MESSAGE:
{
--
Treasurer, GOLUM, Inc.
http://www.golum.org
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
patch for sun type6 keyboard support from debian patches
This is a patch to add sun type6 keyboard support. It comed from the patches
debian puts on the 4.3.0 source before building the packages. I think this
type of info should be passed to the XFree86 core so that everyone who uses
XFree86 can take advantage of this.
Warren Turkal
--- xc/programs/xkbcomp/keycodes/sun~ 2002-10-31 02:42:01.0 -0500
+++ xc/programs/xkbcomp/keycodes/sun2002-10-31 02:45:50.0 -0500
@@ -301,6 +301,152 @@
indicator 1 = Num Lock;
};
+xkb_keycodes type6 {
+minimum= 8;
+maximum= 255;
+
+TLDE = 49;
+AE01 = 10;
+AE02 = 11;
+AE03 = 12;
+AE04 = 13;
+AE05 = 14;
+AE06 = 15;
+AE07 = 16;
+AE08 = 17;
+AE09 = 18;
+AE10 = 19;
+AE11 = 20;
+AE12 = 21;
+BKSP = 22;
+
+TAB = 23;
+AD01 = 24;
+AD02 = 25;
+AD03 = 26;
+AD04 = 27;
+AD05 = 28;
+AD06 = 29;
+AD07 = 30;
+AD08 = 31;
+AD09 = 32;
+AD10 = 33;
+AD11 = 34;
+AD12 = 35;
+RTRN = 36;
+
+CAPS = 66;
+AC01 = 38;
+AC02 = 39;
+AC03 = 40;
+AC04 = 41;
+AC05 = 42;
+AC06 = 43;
+AC07 = 44;
+AC08 = 45;
+AC09 = 46;
+AC10 = 47;
+AC11 = 48;
+
+LFSH = 50;
+AB01 = 52;
+AB02 = 53;
+AB03 = 54;
+AB04 = 55;
+AB05 = 56;
+AB06 = 57;
+AB07 = 58;
+AB08 = 59;
+AB09 = 60;
+AB10 = 61;
+RTSH = 62;
+BKSL = 51;
+
+LALT = 64;
+LCTL = 37;
+SPCE = 65;
+ALGR = 113;
+alias RALT = ALGR;
+
+LMTA = 115;
+RMTA = 116;
+COMP = 117;
+
+ESC = 9;
+FK01 = 67;
+FK02 = 68;
+FK03 = 69;
+FK04 = 70;
+FK05 = 71;
+FK06 = 72;
+FK07 = 73;
+FK08 = 74;
+FK09 = 75;
+FK10 = 76;
+FK11 = 95;
+FK12 = 96;
+
+PRSC = 111;
+SCLK = 78;
+PAUS = 110;
+
+INS = 106;
+HOME = 97;
+PGUP = 99;
+DELE = 107;
+END = 103;
+PGDN = 105;
+
+UP = 98;
+LEFT = 100;
+DOWN = 104;
+RGHT = 102;
+
+NMLK = 77;
+KPDV = 112;
+KPMU = 63;
+KPSU = 82;
+
+KP7 = 79;
+KP8 = 80;
+KP9 = 81;
+KPAD = 86;
+
+KP4 = 83;
+KP5 = 84;
+KP6 = 85;
+
+KP1 = 87;
+KP2 = 88;
+KP3 = 89;
+KPEN = 108;
+
+KP0 = 90;
+KPDL = 91;
+
+STOP = 222;
+AGAI = 223;
+PROP = 224;
+UNDO = 225;
+FRNT = 226;
+COPY = 227;
+OPEN = 228;
+PAST = 229;
+FIND = 230;
+CUT = 231;
+
+HELP = 232;
+
+MUTE = 165;
+VOL- = 159;
+VOL+ = 158;
+POWR = 160;
+
+indicator 1 = Caps Lock;
+indicator 2 = Num Lock;
+indicator 3 = Scroll Lock;
+};
+
xkb_keycodes type4_euro {
include sun(type4)
LSGT = 131;
@@ -311,6 +457,11 @@
LSGT = 131;
};
+xkb_keycodes type6_euro {
+include sun(type6)
+LSGT = 94;
+};
+
xkb_keycodes type5_se {
minimum= 8;
--- xc/programs/xkbcomp/symbols/sun/us~ 2002-10-31 02:53:25.0 -0500
+++ xc/programs/xkbcomp/symbols/sun/us 2002-10-31 03:10:18.0 -0500
@@ -34,8 +34,7 @@
key TLDE { [ grave, asciitilde ], [ acute ] };
key AC11 { [ apostrophe, quotedbl], [ acute ] };
-key RTSH { [ Shift_R ] };
-
+key RTSH { [ Shift_R ] };
key LALT { [ Alt_L ] };
key ALGR { [ Mode_switch ] };
key LMTA { [ Meta_L ] };
@@ -95,19 +94,19 @@
key KP1 { [ KP_End,KP_1], [ F33 ] };
key KP2 { [ KP_Down, KP_2], [ F34 ] };
key KP3 { [ KP_Next, KP_3], [ F35 ] };
-key KPEN { [ KP_Enter] };
+key KPEN { [ KP_Enter] };
key KP0 { [ KP_Insert, KP_0] };
key KPDL { [ KP_Delete, KP_Decimal ]};
// End Keypad section
// begin modifier mappings
-modifier_map Shift { Shift_R };
-modifier_map Mod1 { Meta_L, Meta_R };
-modifier_map Mod2 { Alt_L };
-modifier_map Mod3 { Mode_switch };
-modifier_map Mod4 { Num_Lock };
-modifier_map Mod5 { F13, F18, F20 };
+modifier_map Shift { Shift_R };
+modifier_map Mod1 { Meta_L, Meta_R };
+modifier_map Mod2 { Alt_L };
+modifier_map Mod3 { Mode_switch };
+modifier_map Mod4 { Num_Lock };
+modifier_map Mod5 { F13, F18, F20 };
};
hidden partial function_keys xkb_symbols broken_openlook_map {
@@ -137,7 +136,7 @@
key TLDE { [ grave, asciitilde ], [ acute ] };
key AC11 { [ apostrophe, quotedbl], [ acute ] };
-key RTSH { [ Shift_R ] };
+key RTSH { [ Shift_R ] };
key LALT { [ Alt_L ] };
key ALGR
autotooling xrandr
As an excercise, I autotooled xrandr. It was easy for xrandr, and I expect it would be easy for a number of other small utility programs in the X distribution. The source for this experiment is located at http://ss.kicks-ass.org/~wt/development/xfree86-autotool/xrandr/. Are there any efforts to autotool X as a whole? If so, who do I contact? If not, I would like to start an effort if there is any interest upstream acceptance. It would definitely allow for an easier way to modularize the X source. Warren Turkal -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
NeedFunctionPrototypes and ANSI C
Is there an effort to get rid of NeedFunctionPrototypes and to convert function prototypes to ANSI style? If so, I would like to work on doing this for the xwininfo binary. My research indicates that X11R6.3+ require an ANSI compiler and that this type of conversion is desirable. Warren Turkal -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
patch for ia64 page size
Here is a patch for page size problems on ia64 and radeon. Patch by Chris Ahna: Fixes critical page size problems on ia64 architecture. See following URL for details: https://external-lists.valinux.com/archives/linux-ia64/2001-August/002037.html Comment by [EMAIL PROTECTED]: This probably should be rewritten to be outside of the drivers themselves so that it doesn't have to be done per-driver. I'm applying this to our XFree86 for now however until I've got time to investigate doing it more generically. diff -ur xc/programs/Xserver/hw/xfree86/drivers/ati.ORIG/r128_dri.c xc/programs/Xserver/hw/xfree86/drivers/ati/r128_dri.c --- xc/programs/Xserver/hw/xfree86/drivers/ati.ORIG/r128_dri.c 2002-10-20 02:48:27.0 +0900 +++ xc/programs/Xserver/hw/xfree86/drivers/ati/r128_dri.c 2002-10-20 03:05:24.0 +0900 @@ -54,15 +54,7 @@ #include GL/glxtokens.h #include sarea.h -/* ?? HACK - for now, put this here... */ -/* ?? Alpha - this may need to be a variable to handle UP1x00 vs TITAN */ -#if defined(__alpha__) -# define DRM_PAGE_SIZE 8192 -#elif defined(__ia64__) -# define DRM_PAGE_SIZE getpagesize() -#else -# define DRM_PAGE_SIZE 4096 -#endif +static size_t r128_drm_page_size; /* Initialize the visual configs that are supported by the hardware. These are combined with the visual configs that the indirect @@ -489,11 +481,11 @@ /* Initialize the CCE ring buffer data */ info-ringStart = info-agpOffset; -info-ringMapSize = info-ringSize*1024*1024 + DRM_PAGE_SIZE; +info-ringMapSize = info-ringSize*1024*1024 + r128_drm_page_size; info-ringSizeLog2QW = R128MinBits(info-ringSize*1024*1024/8) - 1; info-ringReadOffset = info-ringStart + info-ringMapSize; -info-ringReadMapSize = DRM_PAGE_SIZE; +info-ringReadMapSize = r128_drm_page_size; /* Reserve space for vertex/indirect buffers */ info-bufStart= info-ringReadOffset + info-ringReadMapSize; @@ -642,11 +634,11 @@ /* Initialize the CCE ring buffer data */ info-ringStart = info-agpOffset; -info-ringMapSize = info-ringSize*1024*1024 + DRM_PAGE_SIZE; +info-ringMapSize = info-ringSize*1024*1024 + r128_drm_page_size; info-ringSizeLog2QW = R128MinBits(info-ringSize*1024*1024/8) - 1; info-ringReadOffset = info-ringStart + info-ringMapSize; -info-ringReadMapSize = DRM_PAGE_SIZE; +info-ringReadMapSize = r128_drm_page_size; /* Reserve space for vertex/indirect buffers */ info-bufStart= info-ringReadOffset + info-ringReadMapSize; @@ -1003,6 +993,8 @@ break; } +r128_drm_page_size = getpagesize(); + /* Create the DRI data structure, and fill it in before calling the DRIScreenInit(). */ if (!(pDRIInfo = DRICreateInfoRec())) return FALSE; diff -ur xc/programs/Xserver/hw/xfree86/drivers/ati.ORIG/radeon_dri.c xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c --- xc/programs/Xserver/hw/xfree86/drivers/ati.ORIG/radeon_dri.c2002-10-20 02:48:27.0 +0900 +++ xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c 2002-10-20 03:04:18.0 +0900 @@ -56,15 +56,7 @@ #include sarea.h #include radeon_sarea.h -/* HACK - for now, put this here... */ -/* Alpha - this may need to be a variable to handle UP1x00 vs TITAN */ -#if defined(__alpha__) -# define DRM_PAGE_SIZE 8192 -#elif defined(__ia64__) -# define DRM_PAGE_SIZE getpagesize() -#else -# define DRM_PAGE_SIZE 4096 -#endif +static size_t radeon_drm_page_size; static Bool RADEONDRICloseFullScreen(ScreenPtr pScreen); @@ -774,11 +766,11 @@ /* Initialize the CP ring buffer data */ info-ringStart = info-agpOffset; -info-ringMapSize = info-ringSize*1024*1024 + DRM_PAGE_SIZE; +info-ringMapSize = info-ringSize*1024*1024 + radeon_drm_page_size; info-ringSizeLog2QW = RADEONMinBits(info-ringSize*1024*1024/8)-1; info-ringReadOffset = info-ringStart + info-ringMapSize; -info-ringReadMapSize = DRM_PAGE_SIZE; +info-ringReadMapSize = radeon_drm_page_size; /* Reserve space for vertex/indirect buffers */ info-bufStart= info-ringReadOffset + info-ringReadMapSize; @@ -900,11 +892,11 @@ /* Initialize the CCE ring buffer data */ info-ringStart = info-agpOffset; -info-ringMapSize = info-ringSize*1024*1024 + DRM_PAGE_SIZE; +info-ringMapSize = info-ringSize*1024*1024 + radeon_drm_page_size; info-ringSizeLog2QW = RADEONMinBits(info-ringSize*1024*1024/8)-1; info-ringReadOffset = info-ringStart + info-ringMapSize; -info-ringReadMapSize = DRM_PAGE_SIZE; +info-ringReadMapSize = radeon_drm_page_size; /* Reserve space for vertex/indirect buffers */ info-bufStart=
Re: autotooling xrandr
Harold L Hunt II wrote: Warren, Most people are probably smart enough not to respond to this... so I will take the plunge for all of them :) Autotooling xrandr might not have been too hard, for one platform and one version of the autotools. However, autotooling X as a whole might be a much larger job than you are thinking of. For example, the current system supports cross compiling quite well, which you would have to be careful not to break in autotool scripts (again, on all supported platforms). For another example, X can be built on Cygwin and OS/2, both of which has strange handling of executable extentions and lots of special linker magic to make things work. Currently all of this magic is contained explicitly and implicitly in Imakefiles. It might be easy for you to autotool what is explicity mentioned in the Imakefiles, but it will be a very large job to autotool all of the implicit things going on behind the scenes. In other words, you can't just look at a given Imakefile and autotool it... you have to grok all of the *.cf files for the various supported platforms to understand what different combinations of flags are supposed to do. If you have thought of all of this and are still interested, then best of luck. However, I wouldn't expect a lot of interest from others, as this gets mentioned every so often but the person suggesting it often gives up after they realize how large of a job it is. Thus, a lot of people are probably going to assume that you will give up as others before you have. Harold Is there any chance of upstream acceptance of this type of work? A lot of the utility binaries should be pretty easy to break out the xc hierarchy. Warren Turkal -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
patch for ia64 page size
Here is a patch for page size problems on ia64 and radeon. Patch by Chris Ahna: Fixes critical page size problems on ia64 architecture. See following URL for details: https://external-lists.valinux.com/archives/linux-ia64/2001-August/002037.html Comment by [EMAIL PROTECTED]: This probably should be rewritten to be outside of the drivers themselves so that it doesn't have to be done per-driver. I'm applying this to our XFree86 for now however until I've got time to investigate doing it more generically. diff -ur xc/programs/Xserver/hw/xfree86/drivers/ati.ORIG/r128_dri.c xc/programs/Xserver/hw/xfree86/drivers/ati/r128_dri.c --- xc/programs/Xserver/hw/xfree86/drivers/ati.ORIG/r128_dri.c 2002-10-20 02:48:27.0 +0900 +++ xc/programs/Xserver/hw/xfree86/drivers/ati/r128_dri.c 2002-10-20 03:05:24.0 +0900 @@ -54,15 +54,7 @@ #include GL/glxtokens.h #include sarea.h -/* ?? HACK - for now, put this here... */ -/* ?? Alpha - this may need to be a variable to handle UP1x00 vs TITAN */ -#if defined(__alpha__) -# define DRM_PAGE_SIZE 8192 -#elif defined(__ia64__) -# define DRM_PAGE_SIZE getpagesize() -#else -# define DRM_PAGE_SIZE 4096 -#endif +static size_t r128_drm_page_size; /* Initialize the visual configs that are supported by the hardware. These are combined with the visual configs that the indirect @@ -489,11 +481,11 @@ /* Initialize the CCE ring buffer data */ info-ringStart = info-agpOffset; -info-ringMapSize = info-ringSize*1024*1024 + DRM_PAGE_SIZE; +info-ringMapSize = info-ringSize*1024*1024 + r128_drm_page_size; info-ringSizeLog2QW = R128MinBits(info-ringSize*1024*1024/8) - 1; info-ringReadOffset = info-ringStart + info-ringMapSize; -info-ringReadMapSize = DRM_PAGE_SIZE; +info-ringReadMapSize = r128_drm_page_size; /* Reserve space for vertex/indirect buffers */ info-bufStart= info-ringReadOffset + info-ringReadMapSize; @@ -642,11 +634,11 @@ /* Initialize the CCE ring buffer data */ info-ringStart = info-agpOffset; -info-ringMapSize = info-ringSize*1024*1024 + DRM_PAGE_SIZE; +info-ringMapSize = info-ringSize*1024*1024 + r128_drm_page_size; info-ringSizeLog2QW = R128MinBits(info-ringSize*1024*1024/8) - 1; info-ringReadOffset = info-ringStart + info-ringMapSize; -info-ringReadMapSize = DRM_PAGE_SIZE; +info-ringReadMapSize = r128_drm_page_size; /* Reserve space for vertex/indirect buffers */ info-bufStart= info-ringReadOffset + info-ringReadMapSize; @@ -1003,6 +993,8 @@ break; } +r128_drm_page_size = getpagesize(); + /* Create the DRI data structure, and fill it in before calling the DRIScreenInit(). */ if (!(pDRIInfo = DRICreateInfoRec())) return FALSE; diff -ur xc/programs/Xserver/hw/xfree86/drivers/ati.ORIG/radeon_dri.c xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c --- xc/programs/Xserver/hw/xfree86/drivers/ati.ORIG/radeon_dri.c2002-10-20 02:48:27.0 +0900 +++ xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c 2002-10-20 03:04:18.0 +0900 @@ -56,15 +56,7 @@ #include sarea.h #include radeon_sarea.h -/* HACK - for now, put this here... */ -/* Alpha - this may need to be a variable to handle UP1x00 vs TITAN */ -#if defined(__alpha__) -# define DRM_PAGE_SIZE 8192 -#elif defined(__ia64__) -# define DRM_PAGE_SIZE getpagesize() -#else -# define DRM_PAGE_SIZE 4096 -#endif +static size_t radeon_drm_page_size; static Bool RADEONDRICloseFullScreen(ScreenPtr pScreen); @@ -774,11 +766,11 @@ /* Initialize the CP ring buffer data */ info-ringStart = info-agpOffset; -info-ringMapSize = info-ringSize*1024*1024 + DRM_PAGE_SIZE; +info-ringMapSize = info-ringSize*1024*1024 + radeon_drm_page_size; info-ringSizeLog2QW = RADEONMinBits(info-ringSize*1024*1024/8)-1; info-ringReadOffset = info-ringStart + info-ringMapSize; -info-ringReadMapSize = DRM_PAGE_SIZE; +info-ringReadMapSize = radeon_drm_page_size; /* Reserve space for vertex/indirect buffers */ info-bufStart= info-ringReadOffset + info-ringReadMapSize; @@ -900,11 +892,11 @@ /* Initialize the CCE ring buffer data */ info-ringStart = info-agpOffset; -info-ringMapSize = info-ringSize*1024*1024 + DRM_PAGE_SIZE; +info-ringMapSize = info-ringSize*1024*1024 + radeon_drm_page_size; info-ringSizeLog2QW = RADEONMinBits(info-ringSize*1024*1024/8)-1; info-ringReadOffset = info-ringStart + info-ringMapSize; -info-ringReadMapSize = DRM_PAGE_SIZE; +info-ringReadMapSize = radeon_drm_page_size; /* Reserve space for vertex/indirect buffers */ info-bufStart=
Re: sparc pci patch
Egbert Eich wrote: Please put your patches into the bugzilla: http://bugs.xfree86.org Here they are likely to get lost. Egbert. Thanks, I hope the developers pay attention to the bugzilla. Warren Turkal -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch for ia64 page size
Jakub Jelinek wrote: On Sun, Aug 10, 2003 at 07:06:58PM -0500, Warren Turkal wrote: @@ -1003,6 +993,8 @@ break; } +r128_drm_page_size = getpagesize(); + sysconf (_SC_PAGESIZE) is the standardized way of querying page size. Jakub I didn't write this patch. Are you saying that the line with r128_drm_page_size should be the following: r128_drm_page_size = sysconf(_SC_PAGESIZE) If so, I will change it, but I cannot test it as I don't have access to ia64 hardware. Also, I just wanna remind everyone that these patches I am sending come from the debian packages. I wrote none of them myself. I am just trying to make sure that all fixes that should go upstream do. BTW, if I submit a patch to patches@, will I get a notification of acceptance or rejection? Warren Turkal -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
sparc pci patch
Here is a patch for sparc and PCI. --- xc/programs/Xserver/hw/xfree86/os-support/bus/Imakefile~2002-10-30 10:03:18.0 +0900 +++ xc/programs/Xserver/hw/xfree86/os-support/bus/Imakefile 2002-11-18 09:49:56.0 +0900 @@ -18,8 +18,8 @@ XCOMM Sparc SBUS driver and generic Linux PCI driver -PCIDRVRSRC = linuxPci.c -PCIDRVROBJ = linuxPci.o +PCIDRVRSRC = sparcPci.c linuxPci.c +PCIDRVROBJ = sparcPci.o linuxPci.o SBUSDRVSRC = Sbus.c SBUSDRVOBJ = Sbus.o -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
patch for ia64
This patch makes the radeon driver treat ia64 as a non-legacy architecture. This patch by Alex Williamson. xc/programs/Xserver/hw/xfree86/drivers/ati/Imakefile assumes ia64 should behave the same as i386 and allows random probing or I/O port space. In moving away from the legacy model, I believe we should change this to set ATIAvoidCPIO to YES. Systems that do no provide a legacy I/O port range may otherwise machine check. --- xc-old/programs/Xserver/hw/xfree86/drivers/ati/Imakefile2003-07-25 06:04:31.0 -0500 +++ xc/programs/Xserver/hw/xfree86/drivers/ati/Imakefile2003-08-07 04:35:24.0 -0500 @@ -82,7 +82,6 @@ * ATIAvoidNonPCI necessarily implies ATIAvoidCPIO. */ #if defined(i386Architecture) || \ -defined(ia64Architecture) || \ defined(AMD64Architecture) || \ defined(AlphaArchitecture) # ifndef ATIAvoidCPIO -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
patch for ia64
This patch makes the radeon driver treat ia64 as a non-legacy architecture. This patch by Alex Williamson. xc/programs/Xserver/hw/xfree86/drivers/ati/Imakefile assumes ia64 should behave the same as i386 and allows random probing or I/O port space. In moving away from the legacy model, I believe we should change this to set ATIAvoidCPIO to YES. Systems that do no provide a legacy I/O port range may otherwise machine check. --- xc-old/programs/Xserver/hw/xfree86/drivers/ati/Imakefile2003-07-25 06:04:31.0 -0500 +++ xc/programs/Xserver/hw/xfree86/drivers/ati/Imakefile2003-08-07 04:35:24.0 -0500 @@ -82,7 +82,6 @@ * ATIAvoidNonPCI necessarily implies ATIAvoidCPIO. */ #if defined(i386Architecture) || \ -defined(ia64Architecture) || \ defined(AMD64Architecture) || \ defined(AlphaArchitecture) # ifndef ATIAvoidCPIO -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] account on svn repo
How do I get an account on the svn repo? I would like to see if I can do a decent job of updating some of the README stuff for the new dbs system. I would also like to see if there are any more changes that can be made to make the new dbs system behave more like the dbs examples. Warren Turkal ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] 4.2.99.4 problem with mouse cursor
In kde and twm, there is a huge delay when changing the mouse cursor to something other than the white glass cursors. For instance, in kde mouse over the edge of a windows to resize them and there is a delay. There is also a delay when reloading the white glass cursors after I mouse off the edge. There does not seem to be a delay when it changes from a white glass cursor to some other white glass cursor or when the window resize arrows changes to another window resize arrow. Thanks, Warren -- Treasurer, GOLUM, Inc. http://www.golum.org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[Xpert]policy
Who makes the decisions for things like XFree86 freeze dates and releases and what not? Or is there some mailing list somewhere? Warren -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]exact integral types
On Tuesday 10 December 2002 08:36 pm, Marc Aurele La France wrote: I attach the little bit I have on this matter (which includes your patch). Thanks, Warren -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]exact integral types
On Tuesday 10 December 2002 03:24 pm, Marc Aurele La France wrote: After going through that exercise, perhaps, you will have gained a greater appreciation for what portability really means. Thank you for the explanation. In these places that warnings are produced, should the code call for a CARD32 instead of calling for an unsigned long or something like that? Warren -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]exact integral types
On Monday 09 December 2002 09:55 am, Marc Aurele La France wrote: A larger issue is that, on some 32-bit systems, this ends up typedef'ing CARD32 as 'unsigned int', and on others, as 'unsigned long'. For reasons I won't get into here, the X sources currently need CARD32 to be typedef'ed as 'unsigned long' for all 32-bit environments. The same issue, without 'unsigned' occurs with INT32. What does it matter if the type is unsigned and 32 bits in length? Warren -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Mouse with many buttons (e.g. 7)
It requires xmodmap magic to get this to work right on a MS Intellimouse Explorer. I have done it before. Warren -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]LCD panel white screens
On Thursday 28 November 2002 01:30 am, Case Jones wrote: XFree86-cvs produces all of the resolutions I could want, and also seems pretty stable (based on 2 days testing) on suspend and resume. However, white screens (where the LCD panel floods with white, forcing me to turn the machine off without properly shutting down first) have occurred under two circumstances: I have had this problem with radeon cards when using a kernel framebuffer. You may want to try disabling the framebuffer driver in kernel if it is there. Warren -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]LCD panel white screens
On Thursday 28 November 2002 11:34 am, Case Jones wrote: On Thursday 28 November 2002 3:48 am, Warren Turkal wrote: Thanks! .. framebuffer support is completely disabled in my kernel, but are the vga text console or Video mode selection support options related? Just disable kernel framebuffer support. You will have to sacrifice the boot logo; sorry. ;-P Warren -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]LCD panel white screens
On Thursday 28 November 2002 08:34 pm, Case Jones wrote: oops, I meant that kernel framebuffer support was _already_ disabled in my kernel... so I guess it's something else? I am out of suggestions, then. I am sorry. Warren -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert] : Kdrive web browser
How big is Konq/E? Warren On Tuesday 26 November 2002 10:57 pm, P.R. Patil wrote: Hi, Can anybody suggest me a small (less than 5MByte) free web browser that works on Kdrive and with Java Script support? -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Radeon XVideo
I am wondering why an XVideo display cannot be covered. I have the radeon driver and a Radeon Mobility 7500. Warren -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon XVideo
4.2.1 If it is already fixed, I am sorry. Thanks Keith for fixing if that's it. Warren On Friday 15 November 2002 09:54 pm, Dr Andrew C Aitchison wrote: On Fri, 15 Nov 2002, Warren Turkal wrote: I am wondering why an XVideo display cannot be covered. I have the radeon driver and a Radeon Mobility 7500. Warren Is this 4.2.1 or CVS ? This sounds a little like the problem fixed in radeon_driver.c r1.54, change 118: Radeon Xv fixes and video key support added (Keith Packard) which is later than 4.2.1 -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Xinput question
Does the Xinput extension allow for dynamically changing the list of input devices? Warren -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]change input device on the fly?
How do you make it make the X wacom driver pick up the different event file for the wacom when it can be named different each time? Warren On Sunday 10 November 2002 03:24 pm, you wrote: I actually have an answer to this, which basically provides a kernel config option to disable the mousedev driver claiming the tablet. You'd still need to have a suitable driver (eg the wacom X driver). Would that solve your problem? Brad -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]change input device on the fly?
On Thursday 07 November 2002 07:18 pm, Alexander Stohr wrote: some experimental thoughts... Hmm, the mouse manager of the shell 'gpm' can handle multiple mice simultanousely. I wonder if there is a way to trick X11 so that it does use the gpm provided API and therefore allowing multiple mice to be merged. GPM has the same issue as X in that it cannot dynamically add new devices. For instance, when a new USB tablet is attached, it should let the tablet work with full functionality (ie. pressure sensitivity, tilt, etc.). This does not happen. X11 can deal with multiple mice, but this is normally tought to be used for multiple heads, meaning you do have one mouse and one keyboard per display. I don't think so. X has the ability for multiple pointing devices in the Xinput by default. Maybe X should somehow link into the hotplug scripts of Linux? I would love to see XFree automagically configure and make available my Wacom Graphire tablet when I plug it into the USB port. I cannot use /dev/input/mice in my config files because the tablet will simply work as a normal mouse without tablet features (ie, no pressure sensitivity). If I always have X configured to use my tablet, it will complain about not being able to open the device files. I also have a USB mouse. This presents the problem that involves the non-static mapping of the devices when plugged in. Whatever the first device to be plugged in gets mapped to /dev/input/event0. If this is my tablet, I can use my tablet. If I plug in the usb mouse, I have to configure X to use /dev/input/mice. Another problem is that X has to configure the top two mouse buttons as the ZAxisMapping. I have a mouse with 7 buttons, and I have to map 6 and 7 to ZAxisMapping and xmodmap pointer='1 2 3 6 7 4 5' to get all buttons to work. I know this is not a wonderful explanation, but I am hoping to get people thinking. Warren -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]change input device on the fly?
Now try to use a wacom tablet with that. Warren On Thursday 07 November 2002 10:56 am, Michel Dänzer wrote: On Don, 2002-11-07 at 17:47, Adam Luter wrote: Not an expert, but have you tried to specify both devices at the same time? You may still have to restart X, Not if you use /dev/input/mice for the USB mouse. -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]X starting with GNOME Desktop Error
On Wednesday 23 October 2002 08:33 pm, Jacky, Lau wrote: Should you add xhosts + in some where like xinitrc, etc/? This seems like a really bad idea to me with respect to security. Warren -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]exact integral types
Here is a patch that should make Xmd.h use C99 when available. --- /usr/include/X11/Xmd.h 2002-10-16 15:14:38.0 -0500 +++ Xmd.h 2002-10-19 14:23:33.0 -0500 @@ -47,6 +47,7 @@ **/ #ifndef XMD_H #define XMD_H 1 + /* $Xorg: Xmd.h,v 1.4 2001/02/09 02:03:22 xorgcvs Exp $ */ /* * Xmd.h: MACHINE DEPENDENT DECLARATIONS. @@ -101,6 +102,36 @@ #define SIZEOF(x) sz_/**/x #endif /* if ANSI C compiler else not */ +#if defined(__STDC_VERSION__) (__STDC_VERSION__ == 199901L) + +#include stdint.h + +typedef uint8_t CARD8; +typedef uint16_t CARD16; +typedef uint32_t CARD32; +typedef uint64_t CARD64; + +typedef int8_t INT8; +typedef int16_t INT16; +typedef int32_t INT32; +typedef int64_t INT64; + +typedef CARD8 BYTE; +typedef CARD8 BOOL; + +typedef CARD32 BITS32; +typedef CARD16 BITS16; + +/*is there any reason why B32 and B16 cannot always be defined?*/ +# if defined(WORD64) +#define B32 :32 +#define B16 :16 +# else +#define B32 +#define B16 +# endif + +#else //__STDC_VERSION__ /* * Bitfield suffixes for the protocol structure elements, if you * need them. Note that bitfields are not guarranteed to be signed @@ -165,6 +196,8 @@ #define BOOL CARD8 #endif /* __EMX__ */ +#endif // __STDC_VERSION__ + /* * definitions for sign-extending bitfields on 64-bit architectures */ On Wednesday 16 October 2002 03:37 am, Dr Andrew C Aitchison wrote: On Wed, 16 Oct 2002, Warren Turkal wrote: Why does X not use the exact integral types in its typedefs? For instance, typedef uint32_t CARD32; instead of all the magic in Xmd.h? These are the ISO C 9X integer types aren't they ? I don't think we have got as far as completely ansi'fing the code yet, never mind using C-9X features. It might be a worthwhile project to make that file use C-9X when available, and only then grovel deep inside systems for older compilers, but basically it is a case of if it ain't broke, don't fix it. -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]exact integral types
C99 has integer types that have an exact width. For instance, uint32_t is an unsigned integer of 32 bit width. This would put the burden of making the right width integer types on the c library as opposed to the x include. I think that, if possible, getting rid of architecture magic in the include files would make them more understandable and possibly easier to port to other architectures. Also, Xmd.h, and presumably other headers, mix #ifdef symbol and #if defined(symbol) directives. It is kinda sloppy. On Wednesday 16 October 2002 04:03 pm, Marc Aurele La France wrote: On Wed, 16 Oct 2002, Warren Turkal wrote: Why does X not use the exact integral types in its typedefs? For instance, typedef uint32_t CARD32; instead of all the magic in Xmd.h? These are the ISO C 9X integer types aren't they ? I don't think we have got as far as completely ansi'fing the code yet, never mind using C-9X features. It might be a worthwhile project to make that file use C-9X when available, and only then grovel deep inside systems for older compilers, but basically it is a case of if it ain't broke, don't fix it. In the Xmd.h file, would it be okay to change the preprocessor directives to #if define(symbol) and such? Please post exactly what you have in mind (and what problem you're trying solve) and we'll see. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]bdf docs in docbook
I have the bdf docs in docbook if anyone is interested. I am thinking about converting some other docs, like the xlibs. Is there any point in doing this. Warren -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]exact integral types
Why does X not use the exact integral types in its typedefs? For instance, typedef uint32_t CARD32; instead of all the magic in Xmd.h? Thanks, Warren -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]exact integral types
In the Xmd.h file, would it be okay to change the preprocessor directives to #if define(symbol) and such? Warren On Wednesday 16 October 2002 03:37 am, Dr Andrew C Aitchison wrote: On Wed, 16 Oct 2002, Warren Turkal wrote: Why does X not use the exact integral types in its typedefs? For instance, typedef uint32_t CARD32; instead of all the magic in Xmd.h? These are the ISO C 9X integer types aren't they ? I don't think we have got as far as completely ansi'fing the code yet, never mind using C-9X features. It might be a worthwhile project to make that file use C-9X when available, and only then grovel deep inside systems for older compilers, but basically it is a case of if it ain't broke, don't fix it. -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
