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