diff options
Diffstat (limited to 'xc/programs/Xserver/hw/xfree86/doc')
60 files changed, 4599 insertions, 3187 deletions
diff --git a/xc/programs/Xserver/hw/xfree86/doc/BUILD b/xc/programs/Xserver/hw/xfree86/doc/BUILD index 9431f9016..902468864 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/BUILD +++ b/xc/programs/Xserver/hw/xfree86/doc/BUILD @@ -2,7 +2,7 @@ David Dawes, Matthieu Herrb - 27 May 2001 + 26 February 2003 Abstract @@ -17,62 +17,76 @@ We highly recommend using gcc to build XFree86, but it generally also builds with the native compiler for each platform; -1. How to get the XFree86 4.2.0 source - -There are a few starting points for getting the XFree86 source. One option -is to start directly with the XFree86 4.2.0 source distribution. In this -case, the procedure is as follows: - - o The XFree86 source is contained in files X420src-1.tgz, X420src-2.tgz - and X420src-3.tgz. These can be found at - ftp://ftp.xfree86.org/pub/XFree86/4.2.0/source/ and similar locations on - XFree86 mirror sites. X420src-2.tgz contains the fonts and documenta- - tion source. X420src-3.tgz contains the hardcopy documentation. - X420src-1.tgz contains everything else. If you don't need the docs or - fonts you can get by with only X420src-1.tgz. +1. How to get the XFree86 4.3.0 source + +The recommended way of getting the XFree86 4.3.0 source is to get it directly +from the XFree86 CVS repository. There are several ways of doing that, and +they are described at our CVS web page <URL:http://www.xfree86.org/cvs/> The +CVS tag for this release is "xf-4_3_0", and the tag for the maintenance +branch for this release is "xf-4_3-branch". + +Another method of getting the XFree86 4.3.0 source is to either download the +4.3.0 source tarballs from the XFree86 ftp site. The procedure for this is +as follows: + + o The XFree86 4.3.0 source is contained in the files X430src-1.tgz, + X430src-2.tgz, X430src-3.tgz, X430src-4.tgz, X430src-5.tgz, + X430src-6.tgz and X430src-7.tgz. These can be found at + ftp://ftp.xfree86.org/pub/XFree86/4.3.0/source/ and similar locations on + XFree86 mirror sites. X430src-4.tgz and X430src-5.tgz contains the + fonts. X430src-6.tgz contains the documentation source. X430src-7.tgz + contains the hardcopy documentation. X430src-1.tgz, X430src-2.tgz and + X430src-3.tgz contains everything else. If you don't need the docs or + fonts you can get by with only X430src-1.tgz, X430src-2.tgz and + X430src-3.tgz. o Extract each of these files by running the following from a directory on a filesystem containing enough space (the full source requires around - 270MB, and a similar amount is required in addition to this for the com- + 305MB, and a similar amount is required in addition to this for the com- piled binaries): - gzip -d < X420src-1.tgz | tar vxf - + gzip -d < X430src-1.tgz | tar vxf - - gzip -d < X420src-2.tgz | tar vxf - + gzip -d < X430src-2.tgz | tar vxf - - gzip -d < X420src-3.tgz | tar vxf - + gzip -d < X430src-3.tgz | tar vxf - - o If the release is not a full release, it is available as a patch against - the previous full release in the - ftp://ftp.xfree86.org/pub/XFree86/4.2.0/patches/ directory. Get the - patch file from there and apply it by running the following command: + gzip -d < X430src-4.tgz | tar vxf - - cd the directory containing the xc directory + gzip -d < X430src-5.tgz | tar vxf - - gzip -d < file | patch -s -p0 -E + gzip -d < X430src-6.tgz | tar vxf - - Look for special patching instructions in the Release Notes. + gzip -d < X430src-7.tgz | tar vxf - -Another option is to get the source by anonymous CVS or CVSup. See -http://www.xfree86.org/cvs/ for details on the different procedure available. +Alternatively, if you already have a pristine copy of the XFree86 4.2.0 +source, you can download patches from +ftp://ftp.xfree86.org/pub/XFree86/4.3.0/patches/ that will allow you to con- +vert it to 4.3.0. Information about which patch files to download and how to +apply them can be found in the "How to get XFree86" section of the README for +this release. -All method will produce one main source directory called xc. +All methods will produce one main source directory called xc. 2. Configuring the source before building -It is recommended that you start the configuration process by going to the -xc/config/cf directory, and copying the file xf86site.def to host.def. Then -read through the host.def file (which is heavily commented), and set any -parameters that you want for your configuration. You can usually find out -what the default settings are by checking the .cf file(s) relevant to your -OS. +In most cases it shouldn't be necessary to configure anything before build- +ing. + +If you do want to make configuration changes, it is recommended that you +start by going to the xc/config/cf directory, and copying the file +xf86site.def to host.def. Then read through the host.def file (which is +heavily commented), and set any parameters that you want for your configura- +tion. You can usually find out what the default settings are by checking the +.cf file(s) relevant to your OS. -Unlike previous versions, imake can now automatically detect and set the var- -ious OS*Version parameters, so you shouldn't need to enter those settings -explicitly. +A general rule to follow is to only change things that you understand and +have a good reason to change. It is easy to create build problems by chang- +ing the default configuration. Many of the configuration parameters are doc- +umented in xc/config/cf/README. -If you are using just the X420src-1.tgz part of the source dist, you will -need to define BuildFonts to NO. +If you are using just the X430src-1.tgz, X430src-2.tgz and X430src-3.tgz +parts of the source dist, you will need to define BuildFonts to NO. 3. Using a shadow directory of symbolic links for the build @@ -85,11 +99,11 @@ during the build, which has the following benefits: trol of CVS. o It is possible to build XFree86 for several different Operating System - or architectures from the same sources, shared by NFS. + or architectures from the same sources, shared by read-only NFS mounts. o It is possible to build XFree86 with different configuration options, - just by putting a real copyhost.def in each build tree and by customiz- - ing it separately in each build tree. + just by putting a real copy of the host.def file in each build tree and + by customizing it separately in each build tree. To make a shadow directory of symbolic links, use the following steps: @@ -100,7 +114,7 @@ To make a shadow directory of symbolic links, use the following steps: mkdir build - o use the lndircommand to make the shadow tree: + o use the "lndir" command to make the shadow tree: lndir ../xc @@ -118,16 +132,24 @@ from the XFree86 sources by running the following commands: cp lndir some directory in your PATH +From time to time there may be some stale links in the build tree, for exam- +ple, when files in the source tree are removed or renamed. These can be +cleaned up by running the "cleanlinks" script from the build directory (see +the cleanlinks(1) manual page). Rarely there will be changes that will +require the build tree to be re-created from scratch. A symptom of this can +be mysterious build problems. The best solution for this is to remove the +build tree, and then re-create it using the steps outlined above. + 4. Building and installing the distribution Before building the distribution, read through the OS-specific README file in xc/programs/Xserver/hw/xfree86/doc that is relevant to you. Once those OS- specific details have been taken care of, go your build directory (either the -xc directory or the shadow tree created before) and run ``make World'' with -the BOOTSTRAPCFLAGS set as described in the OS-specific README (if necessary, -but most systems supported by XFree86 don't need BOOTSTRAPCFLAGS). It is -advisable to redirect stdout and stderr to World.Log so that you can track -down problems that might occur during the build. +xc directory or the shadow tree created before) and run "make World" with the +BOOTSTRAPCFLAGS set as described in the OS-specific README (if necessary, but +most systems supported by XFree86 don't need BOOTSTRAPCFLAGS). It is advis- +able to redirect stdout and stderr to World.Log so that you can track down +problems that might occur during the build. With Bourne-like shells (Bash, the Korn shell, zsh, etc.) use a command like: @@ -143,9 +165,27 @@ You can follow the progress of the build by running: in a terminal. -When the build is finished, you should check World.Log to see if there were -any problems. If there weren't any then you can install the binaries. To do -the install, run ``make install'' and ``make install.man''. Make sure you +When the build is finished, you should check the World.Log file to see if +there were any problems. If there weren't any then you can install the bina- +ries. By default the "make World" process will ignore errors and build as +much as possible. If there were problems and they are not corrected at this +stage, the installation process will fail. To restart the build process +after correcting the problems, just run 'make'. If Imakefiles or part of the +build configuration was changed as part of correcting the problem, either re- +run "make World", or run "make Everything". + +If you would prefer "make World" to exit at the first error, run it in the +following way instead of the way described above: + +for Bourne-like shells: + + make WORLDOPTS= World > World.log 2>&1 + +for C-shell variants: + + make WORLDOPTS= World >& World.log + +To do the install, run "make install" and "make install.man". Make sure you have enough space in /usr/X11R6 for the install to succeed. If you want to install on a filesystem other than /usr, make a symbolic link to /usr/X11R6 before installing. @@ -167,7 +207,7 @@ drivers installed: make Makefile make Makefiles - make includes + make includes make depend make @@ -176,7 +216,7 @@ drivers installed: There are some other useful targets defined in the top level Makefileof XFree86: - o Everything after a make World, make Everythingdoes everything a make + o Everything after a make World, make Everything does everything a make World does, except the cleaning of the tree. It is a way to quickly rebuild the tree after a source patch, but it is not 100% bullet proof. There are cases were it is better to force a full build by using make @@ -206,9 +246,9 @@ XFree86: o VerifyOS displays the detected operating system version. If the numbers shown do not match your system, you probably need to set them manually - in host.def and report the problem to XFree86@XFree86.org. + in host.def and report the problem to <XFree86@XFree86.org>. - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/BUILD.sgml,v 3.6 2001/11/15 17:32:16 dawes Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/BUILD.sgml,v 3.11 2003/02/27 01:17:36 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/BUILD,v 3.7 2001/11/15 17:37:21 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/BUILD,v 3.16 2003/02/27 01:44:03 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/DESIGN b/xc/programs/Xserver/hw/xfree86/doc/DESIGN index 8f6970083..3e073c820 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/DESIGN +++ b/xc/programs/Xserver/hw/xfree86/doc/DESIGN @@ -2,7 +2,7 @@ The XFree86 Project, Inc - Last modified 18 May 2002 + Last modified 2003 January 22 NOTE: This is a DRAFT document, and the interfaces described here are subject to change without notice. @@ -1509,8 +1509,6 @@ XF86Config file to the devices: SymTabPtr chipsets, PciChipsets *PCIchipsets, - GDevPtr *devList, int numDevs, - GDevPtr *devList, int numDevs, DriverPtr drvp, int **foundEntities) @@ -1666,17 +1664,27 @@ able at the driver level: Two helper functions are provided to aid configuring entities: ScrnInfoPtr xf86ConfigPciEntity(ScrnInfoPtr pScrn, + int scrnFlag, int entityIndex, + PciChipsets *p_chip, + resList res, EntityProc init, + EntityProc enter, EntityProc leave, + pointer private) + ScrnInfoPtr xf86ConfigIsaEntity(ScrnInfoPtr pScrn, + int scrnFlag, int entityIndex, + IsaChipsets *i_chip, resList res, EntityProc init, + EntityProc enter, EntityProc leave, + pointer private) These functions are used to register the non-relocatable @@ -1694,8 +1702,8 @@ Two helper functions are provided to aid configuring entities: pointer private) They are passed the entity index and a pointer to a pri- - vate scratch area. This are can be set up during Probe() - and its address can be passed to xf86ConfigIsaEntity() + vate scratch area. This can be set up during Probe() and + its address can be passed to xf86ConfigIsaEntity() and xf86ConfigPciEntity() as the last argument. These two helper functions make use of several core functions that are avail- @@ -1724,12 +1732,12 @@ able at the driver level: 9.3.2 PreInit Phase -During this phase the remaining resource should be registered. PreInit() -should call xf86GetEntityInfo() To obtain a pointer to an EntityInfoRec for +During this phase the remaining resources should be registered. PreInit() +should call xf86GetEntityInfo() to obtain a pointer to an EntityInfoRec for each entity it is able to drive and check if any resource are listed in its resources field. If resources registered in the Probe phase have been -rejected in the post-Probe phase (resources == NULL), then the driver should -decide if it can continue without using these or if it should fail. +rejected in the post-Probe phase (resources is non-NULL), then the driver +should decide if it can continue without using these or if it should fail. EntityInfoPtr xf86GetEntityInfo(int entityIndex) @@ -1742,10 +1750,8 @@ Several functions are provided to simplify resource registration: Bool xf86IsEntityPrimary(int entityIndex) This function returns TRUE if the entity referenced by - entityIndex is the display device that primary display - device (i.e., the one initialised at boot time and used - in text mode). - + entityIndex is the primary display device (i.e., the one + initialised at boot time and used in text mode). Bool xf86IsScreenPrimary(int scrnIndex) This function returns TRUE if the primary entity is reg- @@ -1784,10 +1790,11 @@ The primary function for registration of resources is: resPtr xf86ReallocatePciResources(int entityIndex, resPtr pRes) This function takes a list of PCI resources that need to - be reallocated and returns a list of the reallocated - resource. This list needs to be passed to xf86Register- - Resources() again to be registered with the broker. If - the reallocation fails, NULL is returned. + be reallocated and returns NULL when all relocations are + successful. xf86RegisterResources() should be called + again to register the relocated resources with the bro- + ker. If the reallocation fails, a list of the resources + that could not be relocated is returned. Two functions are provided to obtain a resource range of a given type: @@ -1804,7 +1811,7 @@ Two functions are provided to obtain a resource range of a given type: avoided within the window can be supplied. On failure a zero-length range of type ResEnd will be returned. - resRange xf86GetSparse(long type, memType fixed_bits, + resRange xf86GetSparse(long type, memType fixed_bits, memType decode_mask, memType address_mask, @@ -1835,14 +1842,14 @@ xf86FixPciResource() can be used to do this: parameter contains the number of the PCI base register that needs to be fixed (0-5, and 6 for the BIOS base reg- ister). The size is specified by the alignment. Since - PCI resources need to span an integral range of the size - 2^n the alignment also specifies the number of addresses - that will be decoded. If the driver specifies a type - mask it can override the default type for PCI resources - which is ResShared. The resource broker needs to know - that to find a matching resource range. This function - should be called before calling xf86RegisterResources(). - The return value is TRUE when the function succeeds. + PCI resources need to span an integral range of size 2^n, + the alignment also specifies the number of addresses that + will be decoded. If the driver specifies a type mask it + can override the default type for PCI resources which is + ResShared. The resource broker needs to know that to + find a matching resource range. This function should be + called before calling xf86RegisterResources(). The + return value is TRUE when the function succeeds. Bool xf86CheckPciMemBase(pciVideoPtr pPci, memType base) @@ -1853,13 +1860,16 @@ xf86FixPciResource() can be used to do this: config file) matches an actual value allocated to a device. -The driver may replace the generic access control functions for an entity by -it's own ones. This is done with the xf86SetAccessFuncs(): +The driver may replace the generic access control functions for an entity. +This is done with the xf86SetAccessFuncs(): void xf86SetAccessFuncs(EntityInfoPtr pEnt, + xf86SetAccessFuncPtr funcs, - xf86SetAccessFuncPtr oldFuncs) with: + xf86SetAccessFuncPtr oldFuncs) + + with: typedef struct { xf86AccessPtr mem; @@ -1876,27 +1886,27 @@ it's own ones. This is done with the xf86SetAccessFuncs(): access functions are the same it is assumed that I/O can not be controlled independently. If memory and I/O have to be controlled together all three values should be the - same. If a non NULL value is passed as fifth argument it + same. If a non NULL value is passed as third argument it is interpreted as an address where to store the old - access record. If the fifth argument is NULL it will be + access record. If the third argument is NULL it will be assumed that the generic access should be enabled before replacing the access functions. Otherwise it will be disabled. The driver may enable them itself using the - returned values. It should do this from his replacement + returned values. It should do this from its replacement access functions as the generic access may be disabled by the common level on certain occasions. If replacement functions are specified they must control all resources of the specific type registered for the entity. -To find out if specific resource range is conflicting with another resource -the xf86ChkConflict() function may be used: +To find out if a specific resource range conflicts with another resource the +xf86ChkConflict() function may be used: memType xf86ChkConflict(resRange *rgp, int entityIndex) This function checks if the resource range rgp of for the specified entity conflicts with with another resource. - If it a conflict is found, the address of the start of - the conflict is returned. The return value is zero when + If a conflict is found, the address of the start of the + conflict is returned. The return value is zero when there is no conflict. The OPERATING state properties of previously registered fixed resources can @@ -2049,42 +2059,42 @@ Next, the higher level functions that most drivers would use. The OptionInfoRec is defined as follows: - typedef struct { - double freq; - int units; - } OptFrequency; - - typedef union { - unsigned long num; - char * str; - double realnum; - Bool bool; - OptFrequency freq; - } ValueUnion; - - typedef enum { - OPTV_NONE = 0, - OPTV_INTEGER, - OPTV_STRING, /* a non-empty string */ - OPTV_ANYSTR, /* Any string, including an empty one */ - OPTV_REAL, - OPTV_BOOLEAN, - OPTV_FREQ - } OptionValueType; - - typedef enum { - OPTUNITS_HZ = 1, - OPTUNITS_KHZ, - OPTUNITS_MHZ - } OptFreqUnits; - - typedef struct { - int token; - const char* name; - OptionValueType type; - ValueUnion value; - Bool found; - } OptionInfoRec, *OptionInfoPtr; + typedef struct { + double freq; + int units; + } OptFrequency; + + typedef union { + unsigned long num; + char * str; + double realnum; + Bool bool; + OptFrequency freq; + } ValueUnion; + + typedef enum { + OPTV_NONE = 0, + OPTV_INTEGER, + OPTV_STRING, /* a non-empty string */ + OPTV_ANYSTR, /* Any string, including an empty one */ + OPTV_REAL, + OPTV_BOOLEAN, + OPTV_FREQ + } OptionValueType; + + typedef enum { + OPTUNITS_HZ = 1, + OPTUNITS_KHZ, + OPTUNITS_MHZ + } OptFreqUnits; + + typedef struct { + int token; + const char* name; + OptionValueType type; + ValueUnion value; + Bool found; + } OptionInfoRec, *OptionInfoPtr; OPTV_FREQ can be used for options values that are fre- quencies. These values are a floating point number with @@ -2109,11 +2119,12 @@ Next, the higher level functions that most drivers would use. of options that isn't marked as used. This is intended to show options that the driver hasn't recognised. It would normally be called near the end of the Chip- - ScreenInit() function, but only when - serverGeneration == 1. + ScreenInit() function, but only when serverGenera- + tion == 1. + + OptionInfoPtr xf86TokenToOptinfo(const OptionInfoRec *table, - OptionInfoPtr xf86TokenToOptinfo(const OptionInfoRec *table, int - token) + int token) Returns a pointer to the OptionInfoRec in table with a token field matching token. Returns NULL if no match is @@ -2443,7 +2454,7 @@ remove all removable FBArea allocations. Initialization of the XFree86 framebuffer manager is done via - Bool xf86InitFBManager(ScreenPtr pScreen, BoxPtr FullBox) + Bool xf86InitFBManager(ScreenPtr pScreen, BoxPtr FullBox) FullBox represents the area of the framebuffer that the manager is allowed to manage. This is typically a box with a width of pScrn->displayWidth and a @@ -2529,7 +2540,7 @@ use the colormap layer, a driver calls the xf86HandleColormaps() function. LOCO *colors, VisualPtr pVisual) - LoadPalette() is a driver-provide function for loading a + LoadPalette() is a driver-provided function for loading a colormap into hardware. colors is the array of RGB val- ues that represent the full colormap. indices is a list of index values into the colors array. These indices @@ -2895,6 +2906,7 @@ passing a list of XF86VideoAdaptorPtr pointers to the following function: Bool xf86XVScreenInit( ScreenPtr pScreen, + XF86VideoAdaptorPtr *adaptPtrs, int num) @@ -3105,6 +3117,7 @@ The XF86VideoAdaptorRec: visible. typedef int (* PutVideoFuncPtr)( ScrnInfoPtr pScrn, + short vid_x, short vid_y, short drw_x, short drw_y, short vid_w, short vid_h, short drw_w, short drw_h, @@ -3125,6 +3138,7 @@ The XF86VideoAdaptorRec: turn on the video. typedef int (* PutStillFuncPtr)( ScrnInfoPtr pScrn, + short vid_x, short vid_y, short drw_x, short drw_y, short vid_w, short vid_h, short drw_w, short drw_h, @@ -3135,6 +3149,7 @@ The XF86VideoAdaptorRec: place only one frame from the stream on the screen. typedef int (* GetVideoFuncPtr)( ScrnInfoPtr pScrn, + short vid_x, short vid_y, short drw_x, short drw_y, short vid_w, short vid_h, short drw_w, short drw_h, @@ -3147,6 +3162,7 @@ The XF86VideoAdaptorRec: rect without reading from an area larger than requested. typedef int (* GetStillFuncPtr)( ScrnInfoPtr pScrn, + short vid_x, short vid_y, short drw_x, short drw_y, short vid_w, short vid_h, short drw_w, short drw_h, @@ -3158,6 +3174,7 @@ The XF86VideoAdaptorRec: put stream. typedef void (* StopVideoFuncPtr)(ScrnInfoPtr pScrn, + pointer data, Bool cleanup) This indicates the driver should stop displaying the @@ -3178,6 +3195,7 @@ The XF86VideoAdaptorRec: Atom attribute,INT32 value, pointer data) typedef int (* GetPortAttributeFuncPtr)(ScrnInfoPtr pScrn, + Atom attribute,INT32 *value, pointer data) A port may have particular attributes such as hue, satu- @@ -3214,6 +3232,7 @@ The XF86VideoAdaptorRec: Bool motion, short vid_w, short vid_h, short drw_w, short drw_h, + unsigned int *p_w, unsigned int *p_h, pointer data) QueryBestSize provides the client with a way to query @@ -3225,6 +3244,7 @@ The XF86VideoAdaptorRec: important that the driver provide this function. typedef int (* PutImageFuncPtr)( ScrnInfoPtr pScrn, + short src_x, short src_y, short drw_x, short drw_y, short src_w, short src_h, short drw_w, short drw_h, @@ -3443,6 +3463,10 @@ unresolved symbols can be controlled by the caller of the loader. Typically the caller identifies which symbols can safely remain unresolved and which cannot. +NOTE: Now that ISO-C allows pointers to functions and pointers to data to +have different internal representations, some of the following interfaces +will need to be revisited. + 17.2 Semi-private Loader Interface The following is the semi-private loader interface that is available to the @@ -3601,8 +3625,7 @@ XFree86 common layer. An optional pointer to a variable holding the major part or the error code. When provided, - it *errmaj is filled in when LoadModule() - fails. + *errmaj is filled in when LoadModule() fails. errmin @@ -3615,7 +3638,8 @@ XFree86 common layer. dle mod. All child modules are also unloaded recur- sively. This function must not be used to directly unload modules that are child modules (i.e., those that - have been loaded with LoadSubModule()). + have been loaded with the LoadSubModule() described + below). 17.3 Module Requirements @@ -3851,7 +3875,7 @@ server, and may also be used from within modules. This function unloads the module with handle module. If that module itself has children, they are also unloaded. - It is like LoadModule(), except that it is safe to use + It is like UnloadModule(), except that it is safe to use for unloading child modules. pointer LoaderSymbol(const char *symbol) @@ -3904,7 +3928,9 @@ server, and may also be used from within modules. solved symbols with the loader. When LoaderCheckUnre- solved() is run it won't generate warnings for symbols registered in this way unless they were also registered - as required symbols. + as required symbols. The function takes one or more NULL + terminated lists of symbols. The end of the argument + list is indicated by a NULL argument. void LoaderRefSymbols(const char *sym0, ...) @@ -4084,11 +4110,11 @@ improve the consistency of driver behaviour. If scrnIndex is negative, this function behaves exactly like xf86Msg(). NOTE: This function can only be used after the ScrnIn- - foRec and its name field have been allocated. That means - that it can not be used before the END of the ChipProbe() - function. Prior to that, use xf86Msg(), providing the - driver's name explicitly. No screen number can be sup- - plied at that point. + foRec and its name field have been allocated. Normally, + this means that it can not be used before the END of the + ChipProbe() function. Prior to that, use xf86Msg(), pro- + viding the driver's name explicitly. No screen number + can be supplied at that point. xf86DrvMsgVerb(int scrnIndex, MessageType type, int verb, @@ -4359,9 +4385,9 @@ the helpers. linePitches - List of supported line pitches supported by the - driver. This is optional and should be NULL - when not used. + List of line pitches supported by the driver. + This is optional and should be NULL when not + used. minPitch @@ -4667,11 +4693,11 @@ the helpers. void xf86PrintModes(ScrnInfoPtr scrp) This function prints out the virtual size setting, and - the line pitch being used. It also prints out one line - for each mode being used, including its pixel clock, hor- - izontal sync rate, refresh rate, and whether it is inter- - laced or multiscan. - + the line pitch being used. It also prints out two lines + for each mode being used. The first line includes the + mode's pixel clock, horizontal sync rate, refresh rate, + and whether it is interlaced, doublescanned and/or multi- + scanned. The second line is the mode's Modeline. This function is normally called after calling xf86SetCrtcForModes(). @@ -4990,20 +5016,10 @@ WRec. They are defined in vgaHW.h. must be called before attempting to write to those regis- ters. - A macro VGAHW_UNLOCK(base) is also available in vgaHW.h - that does the same thing, and this may be used when the - vgahw module is not loaded (for example, in the Chip- - Probe() function). - void vgaHWLock(vgaHWPtr hwp) This function locks the VGA CRTC[0-7] registers. - A macro VGAHW_LOCK(base) is also available in vgaHW.h - that does the same thing, and this may be used when the - vgahw module is not loaded (for example, in the Chip- - Probe() function). - void vgaHWEnable(vgaHWPtr hwp) This function enables the VGA subsystem. (Note, this @@ -5044,12 +5060,12 @@ WRec. They are defined in vgaHW.h. vgaHWSave() uses the three functions below in the order vgaHWSaveColormap(), vgaHWSaveMode(), vgaHWSaveFonts() to carry out the different save phases. It is undecided at - this stage whether they will be part of the vgahw mod- - ule's public interface or not. + this stage whether they will remain part of the vgahw + module's public interface or not. void vgaHWSaveMode(ScrnInfoPtr pScrn, vgaRegPtr save) - This functions saves the VGA mode registers. They are + This function saves the VGA mode registers. They are saved to the vgaRegRec pointed to by save. The registers saved are: @@ -5063,13 +5079,15 @@ WRec. They are defined in vgaHW.h. Sequencer[0-4] + The number of registers actually saved may be modified by + a prior call to vgaHWSetRegCounts(). + void vgaHWSaveFonts(ScrnInfoPtr pScrn, vgaRegPtr save) - This functions saves the text mode font and text data - held in the video memory. If called while in a graphics - mode, no save is done. The VGA memory window must be - mapped with vgaHWMapMem() before to calling this func- - tion. + This function saves the text mode font and text data held + in the video memory. If called while in a graphics mode, + no save is done. The VGA memory window must be mapped + with vgaHWMapMem() before to calling this function. On some platforms, one or more of the font/text plane saves may be no-ops. This is the case when the plat- @@ -5098,12 +5116,13 @@ WRec. They are defined in vgaHW.h. order vgaHWRestoreFonts(), vgaHWRestoreMode(), vgaHWRe- storeColormap() to carry out the different restore phases. It is undecided at this stage whether they will - be part of the vgahw module's public interface or not. + remain part of the vgahw module's public interface or + not. void vgaHWRestoreMode(ScrnInfoPtr pScrn, vgaRegPtr restore) - This functions restores the VGA mode registers. They are - restore from the data in the vgaRegRec pointed to by + This function restores the VGA mode registers. They are + restored from the data in the vgaRegRec pointed to by restore. The registers restored are: MiscOut @@ -5116,9 +5135,12 @@ WRec. They are defined in vgaHW.h. Sequencer[0-4] + The number of registers actually restored may be modified + by a prior call to vgaHWSetRegCounts(). + void vgaHWRestoreFonts(ScrnInfoPtr pScrn, vgaRegPtr restore) - This functions restores the text mode font and text data + This function restores the text mode font and text data to the video memory. The VGA memory window must be mapped with vgaHWMapMem() before to calling this func- tion. @@ -5163,12 +5185,12 @@ WRec. They are defined in vgaHW.h. This function blanks and unblanks the screen. It is blanked when on is FALSE, and unblanked when on is TRUE. This function is provided for use in cases where the - ScrnInfoRec can't be derived from the ScreenRec, like - probing for clocks. + ScrnInfoRec can't be derived from the ScreenRec (while + probing for clocks, for example). 19.3 VGA Colormap Functions -The vgahw modules uses the standard colormap support (see the Colormap Han- +The vgahw module uses the standard colormap support (see the Colormap Han- dling (section 13., page 1) section. This is initialised with the following function: @@ -5405,8 +5427,6 @@ Drivers must NOT include the following: #define ZZZ_MINOR_VERSION <int> #define ZZZ_PATCHLEVEL <int> - XXX Probably want to remove one of these version. - NOTE: ZZZ_DRIVER_NAME should match the name of the driver module without things like the "lib" prefix, the "_drv" suffix or filename extensions. @@ -6315,23 +6335,16 @@ pScreen->CloseScreen, and finishes by calling it. Define the SaveScreen() function (the screen blanking function). When using the vgahw module, this will typically be: -This function is mandatory. Before modifying any hardware register directly -this function needs to make sure that the Xserver is active by checking if - - pScrn - - is non-NULL and for - - pScrn->vtSema == TRUE - -. - static Bool ZZZSaveScreen(ScreenPtr pScreen, int mode) { return vgaHWSaveScreen(pScreen, mode); } +This function is mandatory. Before modifying any hardware register directly +this function needs to make sure that the Xserver is active by checking if +pScrn is non-NULL and for pScrn->vtSema == TRUE. + 20.3.16 FreeScreen Define the FreeScreen() function. This function is optional. It should be @@ -6351,7 +6364,7 @@ eScreen() function. ZZZFreeRec(xf86Screens[scrnIndex]); } - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml,v 1.49 2002/05/18 20:52:22 herrb Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml,v 1.52 2003/02/25 19:31:00 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/DESIGN,v 1.42 2002/05/18 20:58:41 herrb Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/DESIGN,v 1.47 2003/02/25 21:32:33 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/Imakefile b/xc/programs/Xserver/hw/xfree86/doc/Imakefile index dca78369c..2187c7060 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/Imakefile +++ b/xc/programs/Xserver/hw/xfree86/doc/Imakefile @@ -4,7 +4,7 @@ XCOMM $XConsortium: Imakefile /main/33 1996/10/28 05:12:24 kaleb $ -XCOMM $XFree86: xc/programs/Xserver/hw/xfree86/doc/Imakefile,v 3.80 2002/06/03 21:22:08 dawes Exp $ +XCOMM $XFree86: xc/programs/Xserver/hw/xfree86/doc/Imakefile,v 3.81 2002/12/10 03:54:15 dawes Exp $ #include <Server.tmpl> #include <lnxdoc.rules> @@ -81,11 +81,17 @@ MAINDOCS = LICENSE README /*ReadmeFile(Config)*/ BUILD RELNOTES \ Install Status DESIGN Versions OTHERDOCS = /*VideoModes.doc*/ /*QuickStart.doc*/ /*xinput*/ \ - ReadmeFile(fonts) ReadmeFile(mouse) ReadmeFile(DRI) \ - ReadmeFile(DRIcomp) ReadmeFile(dps) + ReadmeFile(fonts) \ + ReadmeFile(mouse) \ + ReadmeFile(DGA) \ + ReadmeFile(DRI) \ + ReadmeFile(DRIcomp) \ + ReadmeFile(dps) \ + ReadmeFile(XKB-Config) \ + ReadmeFile(XKB-Enhancing) #endif -MISCDOCS = ServersOnly /*LbxproxyOnly*/ $(REPORTFORM) ReadmeFile(DGA) \ +MISCDOCS = ServersOnly /*LbxproxyOnly*/ $(REPORTFORM) \ VideoBoard98 ReadmeFile(rapidaccess) DATABASE = /* modeDB.txt */ /* AccelCards Monitors Devices */ diff --git a/xc/programs/Xserver/hw/xfree86/doc/Install b/xc/programs/Xserver/hw/xfree86/doc/Install index 2a392ebd7..65c0082fa 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/Install +++ b/xc/programs/Xserver/hw/xfree86/doc/Install @@ -1,8 +1,8 @@ - Installation Details for XFree86[tm] 4.2.0 + Installation Details for XFree86[tm] 4.3.0 The XFree86 Project, Inc - 16 January 2002 + 24 February 2003 Abstract @@ -18,13 +18,15 @@ Solaris, etc) are packaged in a platform-independent gzipped tar format (aka "tarballs" identified by the .tgz suffix). Along with the binaries we pro- vide a customized version of the GNU tar utility called "extract" and an installation script. We recommend that these be used to install the bina- -ries. +ries. (The source for this customized version of GNU tar can be found in the +XFree86 CVS repository's "utils" module, and from our ftp site +<URL:ftp://ftp.xfree86.org/pub/XFree86/misc/utils-1.1.0.tgz>.) -2. Downloading the XFree86 4.2.0 binaries +2. Downloading the XFree86 4.3.0 binaries -We provide XFree86 4.2.0 binaries for a range of operating systems at our ftp -site <URL:ftp://ftp.xfree86.org/pub/XFree86/4.2.0/binaries/> and our web site -<URL:http://ftp.xfree86.org/pub/XFree86/4.2.0/binaries/>. Often during +We provide XFree86 4.3.0 binaries for a range of operating systems at our ftp +site <URL:ftp://ftp.xfree86.org/pub/XFree86/4.3.0/binaries/> and our web site +<URL:http://ftp.xfree86.org/pub/XFree86/4.3.0/binaries/>. Often during releases our site is heavily loaded. Instead of downloading directly from us we recommend that instead you use one of our mirror sites. @@ -71,9 +73,9 @@ NOTES: looking soon after the release date. The second possibility is that we won't have it available at all for this release. This is likely if it's still not there about two weeks after the release date. Check here - <URL:http://www.xfree86.org/4.2.0/UPDATES.html> for information about + <URL:http://www.xfree86.org/4.3.0/UPDATES.html> for information about updates to our binary distributions, and here - <URL:http://www.xfree86.org/4.2.0/ERRATA.html> for errata related to + <URL:http://www.xfree86.org/4.3.0/ERRATA.html> for errata related to this release. Once you're run the Xinstall.sh script and found which binary distribution is @@ -133,9 +135,9 @@ NOTES: If you miss some and want to install them later, go to the Manual Installa- tion (section 4., page 1) section. -3. Installing XFree86 4.2.0 using the Xinstall.sh script +3. Installing XFree86 4.3.0 using the Xinstall.sh script -We strongly recommend that our XFree86 4.2.0 binaries be installed using the +We strongly recommend that our XFree86 4.3.0 binaries be installed using the Xinstall.sh script that we provide. There are a lot of steps in the manual installation process, and those steps can vary according to the platform and hardware setup. There is a description of the manual installation process @@ -252,7 +254,7 @@ later that you need it, you can create it easily by running: The next step is to configure the X server. That is covered in detail in an as-yet unwritten document :-(. In the meantime, there are three ways to cre- -ate a basic X server configuration file for XFree86 4.2.0. One is to run the +ate a basic X server configuration file for XFree86 4.3.0. One is to run the xf86config utility. Another is to run the xf86cfg utility. The third option is to use the new -configure X server option: @@ -271,9 +273,9 @@ old XF86_* and/or XF98_* X server binaries from /usr/X11R6/bin. After the X server configuration is done, it may be advisable to reboot, especially if you run xdm (or equivalent) or the font server (xfs). -4. Installing XFree86 4.2.0 manually +4. Installing XFree86 4.3.0 manually -This section contains information about manually installing the XFree86 4.2.0 +This section contains information about manually installing the XFree86 4.3.0 binary distributions. You should only use this method if you know what you're doing. The information here covers some common cases, but not every possible case. It also may not be complete or up to date. Use at your own @@ -378,7 +380,7 @@ Once that's done, the main part of the installation can be done: /sbin/ldconfig -m /usr/X11R6/lib # For FreeBSD, NetBSD, OpenBSD /usr/X11R6/bin/mkfontdir /usr/X11R6/lib/X11/fonts/misc - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Install.sgml,v 1.13 2002/01/16 20:38:44 dawes Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Install.sgml,v 1.17 2003/02/24 17:09:16 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/Install,v 1.14 2002/01/16 20:51:01 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/Install,v 1.21 2003/02/25 05:29:10 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/LICENSE b/xc/programs/Xserver/hw/xfree86/doc/LICENSE index 2e528f285..bf55a7c1f 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/LICENSE +++ b/xc/programs/Xserver/hw/xfree86/doc/LICENSE @@ -2,14 +2,14 @@ The XFree86 Project - January 2002 + February 2003 1. XFree86 License XFree86 code without an explicit copyright is covered by the following copy- right/license: -Copyright (C) 1994-2002 The XFree86 Project, Inc. All Rights Reserved. +Copyright (C) 1994-2003 The XFree86 Project, Inc. All Rights Reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal @@ -618,7 +618,7 @@ For further information, contact: info@urwpp.de or design@bigelowandholmes.com - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/LICENSE.sgml,v 1.11 2002/01/16 20:38:45 dawes Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/LICENSE.sgml,v 1.12 2003/02/24 03:41:16 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/LICENSE,v 1.16 2002/01/16 20:51:01 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/LICENSE,v 1.17 2003/02/24 04:03:20 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/OS2.Notes b/xc/programs/Xserver/hw/xfree86/doc/OS2.Notes index fb95153c9..69b56b002 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/OS2.Notes +++ b/xc/programs/Xserver/hw/xfree86/doc/OS2.Notes @@ -23,10 +23,11 @@ earlier versions, may now no longer work, or work differently. Be aware that for OS/2, XFree86-4.0 is considered to be alpha software. If you want to join the XFree86 developer team, e.g. to add support for cer- -tain hardware, please send a request to BOD@XFree86.org. Please think about -such a step carefully before, though, since much work is involved. Please use -the XFree86-4.0 source code as a test example how to compile the system. The -ability to manage that is a basic requirement for becoming a developer. +tain hardware, please send a request to <BOD@XFree86.org>. Please think +about such a step carefully before, though, since much work is involved. +Please use the XFree86-4.0 source code as a test example how to compile the +system. The ability to manage that is a basic requirement for becoming a +developer. 2. Tools required @@ -221,9 +222,7 @@ installed them. Nor did I install the test subtree. Well, you see, this was quite easy :-) - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/OS2Notes.sgml,v 1.1 2001/06/04 13:50:15 dawes Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/OS2Notes.sgml,v 1.2 2003/01/04 04:20:23 dawes Exp $ - $XConsortium: OS2note.sgml /main/1 1996/02/24 10:08:59 kaleb $ - -$XFree86: xc/programs/Xserver/hw/xfree86/doc/OS2.Notes,v 3.19 2001/06/30 22:58:09 tsi Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/OS2.Notes,v 3.20 2003/01/04 04:28:27 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README b/xc/programs/Xserver/hw/xfree86/doc/README index 34de7b68c..53509ab2d 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/README +++ b/xc/programs/Xserver/hw/xfree86/doc/README @@ -1,47 +1,47 @@ - README for XFree86[tm] 4.2.0 + README for XFree86[tm] 4.3.0 The XFree86 Project, Inc - 16 January 2002 + 26 February 2003 Abstract - XFree86 is the Open Source port of X.Org's X11R6.6 release that - supports several UNIX(R) and UNIX-like (such as Linux, the BSDs and - Solaris x86) operating systems on Intel and other platforms. + XFree86 is an Open Source version of the X Window System that sup- + ports many UNIX(R) and UNIX-like operating systems (such as Linux, + FreeBSD, NetBSD, OpenBSD and Solaris x86) on Intel and other plat- + forms. This version is compatible with X11R6.6. -1. What is XFree86 4.2.0? +1. What is XFree86 4.3.0? -XFree86 4.2.0 is the fifth full release in the XFree86 4 series. +XFree86 4.3.0 is the sixth full release in the XFree86 4.x series. -XFree86 release 4 is a major re-design of the basic architectural underpin- -nings of XFree86's implementation of the original X Consortium's X Server. -This re-design allows for a modular interaction between the hardware drivers -and the XFree86 core X server. With 4.x, upgrades to the X server with new -and unsupported hardware can be easily done and installed without undergoing -the previous process of rebuilding an X server. All that is required is -installing the new driver module and updating the configuration file. +XFree86 4.x is the current XFree86 release series. The first release in this +series was in early 2000. The core of XFree86 4.x is a modular X server. +The 4.3.0 version is a new release that includes additional hardware support, +functional enhancements and bug fixes. Specific release enhancements can be +viewed in the Release Notes. -The road to XFree86 release 4 began as an architectural concept in mid 1997, -with the serious framework being implemented in code the beginning of 1998. -There were several snapshots on the road to 4.0 which are now part of the 4.0 -base release. The 4.2.0 version is an upgrade to 4.1.0, which include more -hardware ports, code enhancements and bug fixes. +Most modern PC video hardware is supported in XFree86 4.3.0, and most PC +video hardware that isn't supported explicitly can be used with the "vesa" +driver. The Driver Status document has a summary of what hardware is sup- +ported in 4.3.0 compared with the old 3.3.x (3.3.6) series. It is a good +idea to check there before upgrading if you are currently running 3.3.6 with +older hardware. -Release 4 also included the long-awaited integration of the DRI (Direct Ren- -dering Infrastructure). This upgrade into the code base gives XFree86 the -abilities of accelerated direct 3-D graphics rendering, used widely in games -and other visualization programs. +XFree86 is produced by The XFree86 Project, Inc, which is a group of mostly +volunteer independent developers. XFree86 is a non-commercial organisation, +and would not be viable without the invaluable development contributions of +volunteers. This release is dedicated to all who have supported and con- +tributed to XFree86 over the last eleven years. -While some driver available in the old 3.3.x release series have not been -converted over to the 4.x series, those required for most modern video hard- -ware are available. Please check the Driver Status document first to see -whether your hardware is supported before upgrading to the 4.x series. +2. Pointers to additional information -Specific release enhancements can be viewed in the Release Notes. - -The XFree86 version numbering system has had some changes as of the 4.0.2 -release. Information about this can be found in the Versions Document. +The documentation for this release can be found online at the XFree86 web +site <URL:http://www.xfree86.org/4.3.0/>. Documentation for the latest +release version can always be found here <URL:http://www.xfree86.org/cur- +rent/>, and documentation for the latest pre-release snapshot can be found +here <URL:http://www.xfree86.org/snapshot/>. Checking those last two links +is a good way of finding out the latest versions available from XFree86. Information about binary distributions and the attendant installation instructions can be found in the Installation Document. @@ -49,134 +49,110 @@ instructions can be found in the Installation Document. Copyright and Licensing information for this release and all XFree86 releases can be found in the License Document. -2. Joining The Team - -2.1 Development - -If you would like to work on the development of XFree86 4, either by helping -with the conversion of our older drivers to the new 4.x design, or assisting -in the addition of new drivers or platforms to the code base then send a -request to join the XFree86 development team -<URL:http://www.xfree86.org:/developer.html>. This will give you direct -access to the latest XFree86 related development topics and discussions. -Include in your note, your name, email address, reason for joining (what you -will work on) and, level of expertise (coder, DRI, core, specific driver) and -area of interest. - -2.2 Documentation - -If instead your interests are on the Documentation side of the Project, or -you want to contribute and are not ready for plunging into the code, you can -join the Documentation Team (those hardy souls responsible for the content -you are reading :-). Amongst the Doc Team's activities are converting our -SGML based documentation into an XML based one and updating and creating -technical documentation used by staff and public. If this sounds interesting -then please send a request to join the XFree86 documentation team -<URL:mailto:signup@xfree86.org>. Include in your note, you name, email -address, reason for joining (what you will work on) and level of expertise -and whether you are interested in the tools or content side of the group. - -3. The Public Mailing Lists - -3.1 Newbie +The XFree86 version numbering system (including historical information) can +be found in the Versions Document. -For those who are new to XFree86 and want to learn more about our Project we -recommend that you join our Newbie list, located at Public Mailing Lists -<URL:http://www.xfree86.org/mailman/listinfo>, where this and other discus- -sions occur with our senior all-volunteer staff. This is great forum to get -introduced to XFree86 and ask for help on how to set up the XServer or -whether your hardware is supported, and why not?, and make suggestions for -future releases of XFree86. This list is supported by our volunteer staff -who needs to know how you are using and interacting with XFree86 and what is -wrong and could be better. Tell them, they want to know! +Additional information may be available at the XFree86 web site +<URL:http://www.xfree86.org/>, and pointers to other information are avail- +able at the XFree86 support page <URL:http://www.xfree86.org/support.html>. -3.2 Announce - -For those who just want to know the release schedule this is a good list to -join. +3. The Public Mailing Lists -3.3 CVS Commit +3.1 CVS Commit For those who want to see what has been committed recently to our CVS reposi- tory this is the list that will show you those updates. This list is updated dynamically every time the repository is updated after the the commit hap- pens. -3.4 Xpert +3.2 Devel + +This list is available for discussions about XFree86 development and for fol- +lowing up well-defined bug reports. Many experienced XFree86 developers are +present on this list. -If instead you are the lone developer who is improving XFree86 on an ad hoc -basis for your particular environment (I want to get my mouse or video card -to work), and need a specific question asked then you should go over to our -Xpert list where such questions are raised and answered by our technical -development staff. Remember you do not have to be a member to write fixes to -our code base and if your changes are discrete and self-contained the volume -of developer mail may just be too noisy. +3.3 XFree86 -Once your work is finished (coded, debugged and documented) please send your -fix to <fixes@XFree86.org>. This will ensure that they are included in -future releases. And thanks! You make this truly an Open group. +This list is available for any discussions and questions related to XFree86. +Support related questions should be sent here. Many experienced XFree86 +developers monitor this list. -4. How to get XFree86 4.2.0 +4. Contributing to XFree86 -XFree86 4.2.0 can be found at the XFree86 ftp server -<URL:ftp://ftp.xfree86.org/pub/XFree86/4.2.0/>, and at mirrors of this +If you have any new work or enhancements/bug fixes for existing work, please +submit them to <fixes@XFree86.org>. This will ensure that they are included +in future releases. For new work, it's usually a good idea to discuss it +first on the <devel@XFree86.org> list. + +5. How to get XFree86 4.3.0 + +XFree86 4.3.0 can be found at the XFree86 ftp server +<URL:ftp://ftp.xfree86.org/pub/XFree86/4.3.0/>, and at mirrors of this server. Information about obtaining and installing binary distributions of this release can be found in the Installation Document. Information about obtaining the release in source form is given below. -The source for version 4.2.0 is split into three tarballs: X420src-1.tgz, -X420src-2.tgz, X420src-3.tgz. The first contains everything except the fonts -and general X11 documentation. It is sufficient for building XFree86 if you -already have a set of fonts. The second contains the fonts and the source -for the general X11 documentation. The third contains the general X11 docu- -mentation in hardcopy format. - -A source patch relative to version 4.1.0 is also available. Because of its -size, it is split into four parts. The patch files are 4.1.0-4.2.0.diff1.gz, -4.1.0-4.2.0.diff2.gz, 4.1.0-4.2.0.diff3.gz and 4.1.0-4.2.0.diff4.gz. There +The source for version 4.3.0 is split into seven tarballs: X430src-1.tgz, +X430src-2.tgz, X430src-3.tgz, X430src-4.tgz, X430src-5.tgz, X430src-6.tgz and +X430src-7.tgz. The first three contain everything except the fonts and gen- +eral X11 documentation. Those three are sufficient for building XFree86 if +you already have a set of fonts. The fourth and fifth contain the fonts. +The sixth contains the source for the general X11 documentation. The seventh +contains the general X11 documentation in hardcopy format. + +A source patch relative to version 4.2.0 is also available. Because of its +size, it is split into four parts. The patch files are 4.2.0-4.3.0.diff1.gz, +4.2.0-4.3.0.diff2.gz, 4.2.0-4.3.0.diff3.gz and 4.2.0-4.3.0.diff4.gz. There is also a tarball that contains some files that have components that can't be -included in a diff. It is 4.2.0.tgz. These patches should be applied to a -clean 4.1.0 source tree, working from the directory containing the xc/ direc- +included in a diff. It is 4.3.0.tgz. These patches should be applied to a +clean 4.2.0 source tree, working from the directory containing the xc/ direc- tory. The patches should be applied by running: - gzip -d < 4.1.0-4.2.0.diff1.gz | patch -p0 -E - gzip -d < 4.1.0-4.2.0.diff2.gz | patch -p0 -E - gzip -d < 4.1.0-4.2.0.diff3.gz | patch -p0 -E - gzip -d < 4.1.0-4.2.0.diff4.gz | patch -p0 -E - - rm -f xc/extras/freetype2/builds/mac/ftlib.prj - rm -fr xc/extras/freetype2/docs/design - rm -fr xc/extras/freetype2/docs/glyphs - rm -fr xc/extras/freetype2/docs/image - rm -fr xc/extras/freetype2/docs/tutorial - rm -f xc/programs/Xserver/hw/darwin/bundle/English.lproj/MainMenu.nib/objects.nib - rm -f xc/programs/Xserver/hw/darwin/bundle/Japanese.lproj/Localizable.strings - rm -f xc/programs/Xserver/hw/darwin/bundle/Japanese.lproj/MainMenu.nib/objects.nib - - gzip -d < 4.2.0.tgz | tar vxf - - -The contrib part of the distribution was folded into the main source tree a -while ago, so a separate contrib tarball is not required. + gzip -d < 4.2.0-4.3.0.diff1.gz | patch -p0 -E + gzip -d < 4.2.0-4.3.0.diff2.gz | patch -p0 -E + gzip -d < 4.2.0-4.3.0.diff3.gz | patch -p0 -E + gzip -d < 4.2.0-4.3.0.diff4.gz | patch -p0 -E + + rm -f xc/doc/hardcopy/Xext/mit-shm.PS.gz + rm -f xc/doc/hardcopy/saver/saver.PS.gz + rm -fr xc/fonts/scaled/Ethiopic + rm -fr xc/fonts/scaled/Meltho + rm -fr xc/programs/Xserver/hw/darwin/bundle + rm -f xc/programs/Xserver/hw/hp/input/drivers/XHPKeymaps + rm -f xc/programs/Xserver/hw/hp/ngle/ngledoblt.o.8.07 + rm -f xc/programs/Xserver/hw/xwin/X.ico + rm -fr xc/programs/xcursorgen/redglass + rm -fr xc/programs/xcursorgen/whiteglass + touch xc/extras/Mesa/src/Trace/tr_attrib.c + touch xc/lib/fontconfig/NEWS + + gzip -d < 4.3.0.tgz | tar vxf - To format the XFree86 documentation use the latest version of our doctools -package available as doctools-1.3.tgz. +package available from the XFree86 CVS repository's "doctools" module, and +from our ftp site <URL:ftp://ftp.xfree86.org/pub/XFree86/misc/doc- +tools-1.3.1.tgz>. -The XFree86 source code can also be accessed via the XFree86 CVS repository. -Information about accessing this can be found at the CVS page +The XFree86 source code for this and all releases/snapshots as well as devel- +opment versions can also be accessed via the XFree86 CVS repository. Infor- +mation about accessing this can be found at the CVS page <URL:http://www.xfree86.org/cvs/> on our web site. It's also possible to browse the XFree86 CVS repository at our CVSWeb server -<URL:http://cvsweb.xfree86.org/>. +<URL:http://cvsweb.xfree86.org/>. The CVS tag for this version is +"xf-4_3_0". The CVS tag for the stable branch for this release is +"xf-4_3-branch". To check out the latest development version, don't specify +any tag. -5. Reporting Bugs +6. Reporting Bugs Bugs should be reported to <XFree86@XFree86.org>. Before reporting bugs, -please check the X server log file, which can be found at +please check the XFree86 server log file, which can be found at /var/log/XFree86.0.log on most platforms. If you can't resolve the problem yourself, send the entire log file with your bug report but not the operating system core dump. Do not edit the log file as our developers use it to reproduce and debug your problem. - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/README.sgml,v 3.119 2002/01/16 19:40:48 dawes Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/README.sgml,v 3.134 2003/02/27 01:19:32 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/README,v 3.116 2002/01/16 20:51:01 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README,v 3.129 2003/02/27 02:16:18 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.DECtga b/xc/programs/Xserver/hw/xfree86/doc/README.DECtga index 5a723281a..8a7f3fdd9 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/README.DECtga +++ b/xc/programs/Xserver/hw/xfree86/doc/README.DECtga @@ -6,7 +6,7 @@ 1. DEC 21030 - o The DEC 21030 is supported by XFree86 4.2.0. The driver is now par- + o The DEC 21030 is supported by XFree86 4.3.0. The driver is now par- tially accelerated. The built-in graphics on the Multia is supported in 8-plane mode, and PCI cards with 8 or 16 MB framebuffers are supported in 24-plane mode. TGA2 (aka PowerStorm 3D30/4D20) cards are not cur- @@ -65,4 +65,4 @@ Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DECtga.sgml,v 3.9 2000/03/06 22:59:23 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.DECtga,v 3.19 2001/11/15 17:37:21 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.DECtga,v 3.24 2003/02/24 04:03:21 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.DRI b/xc/programs/Xserver/hw/xfree86/doc/README.DRI index 689b6d1c7..66a5a5ff8 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/README.DRI +++ b/xc/programs/Xserver/hw/xfree86/doc/README.DRI @@ -30,7 +30,7 @@ tive owners. 2. Introduction -With XFree86 4.0 and the Direct Rendering Interface (DRI), hardware acceler- +With XFree86 4.x and the Direct Rendering Interface (DRI), hardware acceler- ated 3D graphics can be considered a standard feature on Linux workstations. Support for other operating systems, such as FreeBSD, is underway. @@ -39,9 +39,9 @@ which may occur. Readers should have a basic understanding of Linux, X and OpenGL. See the resources section at the end for more documentation and software downloads. -This document does not cover compilation or installation of XFree86 4.0. It +This document does not cover compilation or installation of XFree86 4.x. It is assumed that you've already installed a Linux distribution which includes -XFree86 4.0 or that you're an experienced Linux developer who has compiled +XFree86 4.x or that you're an experienced Linux developer who has compiled the DRI for himself. DRI download, compilation and installation instructions can be found at http://dri.sourceforge.net/DRIcompile.html @@ -72,7 +72,7 @@ performance. See the DRI Compilation Guide for details. 3.2 Graphics Hardware -XFree86 4.0 (or later versions) includes 3D acceleration for the following +XFree86 4.2 (or later versions) includes 3D acceleration for the following graphics hardware: o 3dfx, supported on Intel x86, AMD and Alpha: @@ -104,7 +104,7 @@ graphics hardware: o Matrox G400 - o Intel i810 (motherboard chipset) + o Intel i810/i815/i830 (motherboard chipsets) o i810 @@ -112,6 +112,10 @@ graphics hardware: o i810e + o i815 + + o i830 + o ATI Rage 128, supported on Intel x86, AMD and Alpha: o Rage Fury @@ -139,6 +143,16 @@ graphics hardware: o Radeon 32MB SDR PCI (Alpha-based systems) + o Radeon 7000, M6 (RV100) + + o Radeon 7200 (R100) + + o Radeon 7500, M7 (RV200) + + o Radeon 8500, 9100 (R200) + + o Radeon 9000, M9 (RV250) + o 3Dlabs, supported on Intel x86 and AMD: o Oxygen GMX 2000 (MX/Gamma based). Note: this driver is no longer @@ -271,10 +285,10 @@ that you are in fact using 3D acceleration. 8.1 libGL.so Your OpenGL program must link with the libGL.so.1.2 library provided by -XFree86 4.0. The libGL.so.1.2 library contains a GLX protocol encoder for -indirect/remote rendering and DRI code for accessing hardware drivers. In -particular, be sure you're not using libGL.so from another source such as -Mesa or the Utah GLX project. +XFree86. The libGL.so.1.2 library contains a GLX protocol encoder for indi- +rect/remote rendering and DRI code for accessing hardware drivers. In par- +ticular, be sure you're not using libGL.so from another source such as Mesa +or the Utah GLX project. Unless it was built in a special way, the libGL.so library does not contain any 3D hardware driver code. Instead, libGL.so dynamically loads the appro- @@ -1237,7 +1251,7 @@ demo programs is available from http://dri.sourceforge.net/res.phtml o In the future there may be IHV and Linux vendor support resources for the DRI. - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DRI.sgml,v 1.27 2002/01/07 22:05:57 dawes Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DRI.sgml,v 1.29 2003/02/17 03:57:29 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.DRI,v 1.19 2002/01/07 22:07:16 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.DRI,v 1.21 2003/02/17 04:04:07 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.DRIcomp b/xc/programs/Xserver/hw/xfree86/doc/README.DRIcomp index b1e97f2bd..1e9773ccc 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/README.DRIcomp +++ b/xc/programs/Xserver/hw/xfree86/doc/README.DRIcomp @@ -30,59 +30,55 @@ tive owners. 2. Introduction -This document describes how to download, compile and install the DRI project. -The DRI provides 3D graphics hardware acceleration for the XFree86 project. -This information is intended for experienced Linux developers. Beginners are +This document describes how to download, compile and install the DRI. The +DRI provides 3D graphics hardware acceleration for the XFree86 project. This +information is intended for experienced Linux developers. Beginners are probably better off installing precompiled packages. Edits, corrections and updates to this document may be mailed to <brian@tung- -stengrahpics.com>. +stengraphics.com>. + +Last updated on 13 February 2002 by Brian Paul. 3. Prerequisites You'll need the following: + o An installation of XFree86 4.1 or later. The DRI tree has been pruned + down to minimize its size. But in order to build the DRI tree you need + to have recent X header files, etc. already installed. If you don't + have XFree86 4.1 (or later) installed you can probably install it from + RPMs (or another package format). Or, you can download XFree86 as + sources and compile/install it yourself. + o At least 200MB of free disk space. If you compile for debugging (the -g option) then you'll need about 600MB. o GCC compiler and related tools. - o ssh (secure shell) for registered developer downloading of the DRI - source tree + o ssh (secure shell) if you're a DRI developer and don't want to use + anonymous CVS download. - o A recent Linux Kernel. See below for details. + o A 2.4.x Linux Kernel. See below for details. o FreeBSD support is not currently being maintained and may not work. The DRI 3D drivers generally work on systems with Intel or AMD CPUs. How- -ever, there is limited support for Alpha and PowerPC support is underway. - -For 3dfx Voodoo3 hardware, you'll also need: - - o Glide3 headers and runtime library if you want to use the 3dfx driver. - These can be obtained from linux.3dfx.com. - - o A recent Linux 2.4.x kernel. AGP support is not required. +ever, limited support for Alpha and PowerPC support is underway. -For Matrox G200/G400 hardware, you'll also need: +For 3dfx Voodoo hardware, you'll also need the Glide3 runtime library +(libglide3-v3.so for Voodoo3 or libglide3-v5.so for Voodoo4/5). These can be +downloaded from the DRI website. You can compile them yourself, but it's +often a painful process. - o A recent Linux 2.4.x kernel with AGP support. - -For Intel i810 hardware, you'll also need: - - o A recent Linux 2.4.x kernel with AGP support. - -For ATI Rage 128 and Radeon hardware, you'll also need: - - o A recent Linux 2.4.x kernel with AGP support. +For Matrox G200/G400, Intel i810/i830 or ATI Rage128/Radeon hardware, you'll +also need AGP support in your Linux kernel, either built-in or as a loadable +module. 4. Linux Kernel Preparation -The DRI project closely tracks Linux kernel development. Since the internal -Linux data structures might change in the 2.4 Linux kernel, it's important to -use the most recent Linux kernel and not an old, intermediate development -release. As of this writing (Jan 2001), 2.4.0 is the most recent version of -Linux which the DRI is synchronized to. +Only the Linux 2.4.x kernels are currently supported by the DRI hardware +drivers. 2.5.x kernels may work, but aren't tested. Most of the DRI drivers require AGP support and using Intel Pentium III SSE optimizations also requires an up-to-date Linux kernel. Configuring your @@ -188,10 +184,9 @@ should be used and enable them where appropriate. 5.1 Intel Pentium III Features -The Pentium III SSE (Katmai) instructions are used in optimized vertex trans- -formation functions in the Mesa-based DRI drivers. On Linux, SSE requires a -recent kernel (such as 2.4.0-test11 or later) both at compile time and run- -time. +The Pentium III SSE instructions are used in optimized vertex transformation +functions in the Mesa-based DRI drivers. On Linux, SSE requires a recent +kernel (such as 2.4.0-test11 or later) both at compile time and runtime. 5.2 AMD 3DNow! Features @@ -225,9 +220,8 @@ The host.def file is explained below. 6. Downloading the XFree86/DRI CVS Sources -The DRI project is hosted by VA Linux Systems' SourceForge. The DRI source -code, which is a subset of the XFree86 source tree, is kept in a CVS reposi- -tory there. +The DRI project is hosted by SourceForge. The DRI source code, which is a +subset of the XFree86 source tree, is kept in a CVS repository there. The DRI CVS sources may be accessed either anonymously or as a registered SourceForge user. It's recommended that you become a registered SourceForge @@ -341,7 +335,6 @@ The default host.def file will look something like this: #define LinuxDistribution LinuxRedHat #define DefaultCCOptions -ansi GccWarningOptions -pipe #define BuildXF86DRI YES - #define HasGlide3 YES /* Optionally turn these on for debugging */ /* #define GlxBuiltInTdfx YES */ /* #define GlxBuiltInMga YES */ @@ -351,24 +344,26 @@ The default host.def file will look something like this: #define SharedLibFont NO The ProjectRoot variable specifies where the XFree86 files will be installed. -You probably don't want to use /usr/X11R6/ because that would overwrite your -default X files. The following is recommended: - - #define ProjectRoot /usr/X11R6-DRI +We recommend installing the DRI files over your existing XFree86 installation +- it's generally safe to do and less error-prone. This policy is different +than what we used to recommend. -Especially note the XF86CardDrivers line to be sure your driver is listed. +If XFree86 4.x is not installed in /usr/X11R6/ you'll have to add the follow- +ing to the host.def file: -If you have 3dfx hardware be sure that the Glide 3x headers are installed in -/usr/include/glide3/ and that the Glide 3x library is installed at -/usr/lib/libglide3.so. + #define ProjectRoot pathToYourXFree86installation -If you do not have 3dfx hardware comment out the HasGlide3 line in host.def. +Note the XF86CardDrivers line to be sure your card's driver is listed. If you want to enable 3DNow! optimizations in Mesa and the DRI drivers, you should add the following: #define MesaUse3DNow YES +You don't have to be using an AMD processor in order to enable this option. +The DRI will look for 3DNow! support and runtime and only enable it if appli- +cable. + If you want to enable SSE optimizations in Mesa and the DRI drivers, you must upgrade to a Linux 2.4.x kernel. Mesa will verify that SSE is supported by both your processor and your operating system, but to build Mesa inside the @@ -377,20 +372,20 @@ you enable SSE optimizations with an earlier version of the Linux kernel in /usr/src/linux, Mesa will not compile. You have been warned. If you do have a 2.4.x kernel, you should add the following: - #define MesaUseKatmai YES + #define MesaUseSSE YES 8.3 Compilation To compile the complete DRI tree: cd ~/DRI-CVS/build/xc/ - make World >& World.LOG + make World >& world.log Or if you want to watch the compilation progress: cd ~/DRI-CVS/build/xc/ - make World >& World.LOG & - tail -f World.LOG + make World >& world.log & + tail -f world.log With the default compilation flags it's normal to get a lot of warnings dur- ing compilation. @@ -403,7 +398,7 @@ work with XFree86/DRI. 8.4 Check for compilation errors -Using your text editor, examine World.LOG for errors by searching for the +Using your text editor, examine world.log for errors by searching for the pattern ***. Verify that the DRI kernel module(s) for your system were built: @@ -435,7 +430,7 @@ first. 8.5 DRI kernel module installation -The DRI kernel modules are in ~/DRI-CVS/build/xc/pro- +The DRI kernel modules will be in ~/DRI-CVS/build/xc/pro- grams/Xserver/hw/xfree86/os-support/linux/drm/kernel/. To load the appropriate DRM module in your running kernel you can either use @@ -450,110 +445,54 @@ Note that some DRM modules require that the agpgart module be loaded first. 9. Normal Installation and Configuration -Most users will want to install the new X server and use it instead of the -original X server. This section explains how to do that. We assume that the -user is upgrading from XFree86 3.3.x. +Most users will want to install the new X server and use it in place of their +old X server. This section explains how to do that. Developers, on the other hand, may just want to test the X server without actually installing it as their default server. If you want to do that, skip to the next section. -9.1 X Installation +9.1 Installation -You'll need to run as root to do the following commands: +Here are the installation commands: su - -As mentioned above, the installation directory is specified by the Project- -Root variable in the host.def file. Create that directory now if it doesn't -already exist, then run the install commands: - - mkdir /usr/X11R6-DRI cd ~/DRI-CVS/build/xc make install -9.2 Linker configuration - -Edit your /etc/ld.so.conf file and put /usr/X11R6-DRI/lib as the first line. -Then run: - - ldconfig - -This will ensure that you use the new X libraries when you run X programs. - -9.3 Update Locale Information - -To update your X locale information do the following: - - cd ~/DRI-CVS/build/xc/nls - ../config/util/xmkmf -a - make - make install +9.2 Update the XF86Config File -This will prevent a locale error message from being printed when you run Xlib -programs. +You may need to edit your XF86Config file to enable the DRI. The config file +is usually installed as /etc/X11/XF86Config-4. See the DRI User Guide for +details, but basically, you need to load the "glx" and "dri" modules and add +a "DRI" section. -9.4 Setup Miscellaneous Files - -Issue the following commands: - - cd /usr/X11R6-DRI/lib/X11 - ln -s /usr/X11R6/lib/X11/rgb.txt . - ln -s /usr/X11R6/lib/X11/fonts . - ln -s /usr/X11R6/lib/X11/app-defaults . - -This will allow applications to use the fonts and resources that they used in -the past. - -9.5 Disable the Old X Server and Enable the New One - -Assuming that an installation of XFree86 3.3.x is present, we need to disable -the old 3.3.x X server and enable the new 4.0.x X server. +On the DRI web site, in the resources section, you'll find example XF86Config +files for a number of graphics cards. These configuration files also setup +DRI options so it's highly recommended that you look at these examples. -Issue the following commands: +The XFree86 4.x server can generate a basic configuration file itself. Sim- +ply do this: cd /usr/X11R6/bin - mv Xwrapper Xwrapper.old - rm X - ln -s /usr/X11R6-DRI/bin/XFree86 X - -This will cause the new X server to be used instead of the original one. - -9.6 Create the XF86Config File - -Configuration files for XFree86 3.3.x will not work with XFree86 4.0.x. - -The new 4.0.x server can generate a basic configuration file itself. Simply -do this: - - cd /usr/X11R6-DRI/bin ./XFree86 -configure A file named /root/XF86Config.new will be created. It should allow you to try your X server but you'll almost certainly have to edit it. For example, you should add HorizSync and VertRefresh options to the Monitor section and Modes options to the Screen section. Also, the ModulePath option in the -Files section should be set to /usr/X11R6-DRI/lib/modules. - -On the DRI web site, in the resources section, you'll find example XF86Config -files for a number of graphics cards. These configuration files also setup -DRI options so it's highly recommended that you look at these examples. - -In any case, your new XF86Config file should be placed in /etc/X11/XF86Con- -fig-4. This configuration file will be recognized by the 4.0.x server but -not by 3.3.x servers. You can instead name it /etc/X11/XF86Config but -that'll overwrite your old config file, which you may want to preserve. +Files section should be set to /usr/X11R6/lib/modules. -9.7 Start the New X Server +9.3 Start the New X Server The new X server should be ready to use now. Start your X server in your -usual manner. Typically, the startx command is used: +usual manner. Often times the startx command is used: startx 10. Testing the Server Without Installing It -As mentioned at the start of section 8, developers may want to simply run the +As mentioned at the start of section 9, developers may want to simply run the X server without installing it. This can save some time and allow you to keep a number of X servers available for testing. @@ -563,7 +502,7 @@ As described in the preceding section, you'll need to create a configuration file for the new server. Put the XF86Config file in your ~/DRI- CVS/build/xc/programs/Xserver directory. -Be sure the ModulePath option is set correctly. +Be sure the ModulePath option in your XF86Config file is set correctly. 10.2 A Startup Script @@ -598,7 +537,7 @@ At this point your X server should be up and running with hardware-acceler- ated direct rendering. Please read the DRI User Guide for information about trouble shooting and how to use the DRI-enabled X server for 3D applications. - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DRIcomp.sgml,v 1.16 2002/01/07 22:05:57 dawes Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DRIcomp.sgml,v 1.19 2002/11/26 01:05:50 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.DRIcomp,v 3.13 2002/01/07 22:07:16 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.DRIcomp,v 3.16 2002/11/26 02:24:01 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.Darwin b/xc/programs/Xserver/hw/xfree86/doc/README.Darwin index 802b208d7..41741ad2a 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/README.Darwin +++ b/xc/programs/Xserver/hw/xfree86/doc/README.Darwin @@ -66,7 +66,7 @@ Developers' Tools. If you don't feel the need to live on the cutting edge, you can save some time and effort by using the precompiled binaries available on the XFree86 -FTP server at <URL:ftp://ftp.xfree86.org/pub/XFree86/4.2.0/binaries/>. Fol- +FTP server at <URL:ftp://ftp.xfree86.org/pub/XFree86/4.3.0/binaries/>. Fol- low the instructions in the Install document to install it. This will create two new directory trees, /usr/X11R6 and /etc/X11 For Mac OS X Quartz support, download the optional Xquartz.tgz tarball. With Quartz support, the XDarwin @@ -187,4 +187,4 @@ Good luck! Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Darwin.sgml,v 1.9 2001/12/13 07:09:05 torrey Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.Darwin,v 1.8 2001/12/20 00:15:41 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.Darwin,v 1.13 2003/02/24 04:03:21 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.LynxOS b/xc/programs/Xserver/hw/xfree86/doc/README.LynxOS index a70b064bd..d5baef983 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/README.LynxOS +++ b/xc/programs/Xserver/hw/xfree86/doc/README.LynxOS @@ -1,4 +1,4 @@ - README for XFree86 4.2.0 on LynxOS + README for XFree86 4.3.0 on LynxOS Thomas Mueller @@ -13,19 +13,19 @@ ments as well as many bug fixes. See the Copyright Notice. -The sources for XFree86 4.2.0 are available by anonymous ftp from: +The sources for XFree86 4.3.0 are available by anonymous ftp from: -ftp://ftp.XFree86.org/pub/XFree86/4.2.0 +ftp://ftp.XFree86.org/pub/XFree86/4.3.0 Binaries of XFree86 for LynxOS x86 are available from: -ftp://ftp.XFree86.org/pub/XFree86/4.2.0/binaries/LynxOS +ftp://ftp.XFree86.org/pub/XFree86/4.3.0/binaries/LynxOS A list of mirror sites is provided by ftp://ftp.XFree86.org/pub/XFree86/MIR- RORS The binaries on the FTP site were built on the latest released LynxOS version -at the time XFree86 4.2.0 was released. In this case it is `LynxOS x86 +at the time XFree86 4.3.0 was released. In this case it is `LynxOS x86 3.0.1'. Because of changes made to the object format they don't run on LynxOS versions earlier than 3.0.0. @@ -37,7 +37,7 @@ this OS release was not available long enough for serious testing `LynxOS 3.1.0' support has to be considered to be in `alpha state'. Initial tests were performed on LynxOS x86 only! -XFree86 4.2.0 supports LynxOS on the x86 and on the PowerPC platform. X +XFree86 4.3.0 supports LynxOS on the x86 and on the PowerPC platform. X servers are currently available only on the x86 platform. The X server may work with some PowerPC platforms supported by LynxOS though this has not (yet) been thoroughly tested. @@ -163,7 +163,7 @@ to 3.5 X Server debug diagnostics output and other VT peculiarities Output made by the XFree86 X on its stdout or stderr will be lost after the -server switches to graphics mode. The XFree86 4.2.0 server stores its output +server switches to graphics mode. The XFree86 4.3.0 server stores its output in /usr/adm/XFree86.n.log (where n is the screen number). When the X server is running output made to other consoles will be lost. @@ -266,4 +266,4 @@ duplicate entries: Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/LynxOS.sgml,v 3.20 2000/06/17 00:27:32 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.LynxOS,v 3.30 2001/11/15 17:37:22 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.LynxOS,v 3.35 2003/02/24 04:03:21 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.NetBSD b/xc/programs/Xserver/hw/xfree86/doc/README.NetBSD index a07cccd2a..c4616f1cf 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/README.NetBSD +++ b/xc/programs/Xserver/hw/xfree86/doc/README.NetBSD @@ -1,23 +1,24 @@ - README for XFree86 4.2.0 on NetBSD + README for XFree86 4.3.0 on NetBSD Rich Murphey, David Dawes, Marc Wandschneider, Mark Weaver, Matthieu Herrb - Last modified on: 16 January 2002 + Last modified on: 9 November 2002 1. What and Where is XFree86? -XFree86 is the Open Source port of X.Org's X11R6.6 release that supports sev- -eral UNIX(R) and UNIX-like (such as Linux, the BSDs and Solaris x86) operat- -ing systems on Intel and other platforms. +XFree86 is an Open Source version of the X Window System that supports sev- +eral UNIX(R) and UNIX-like operating systems (such as Linux, the BSDs and +Solaris x86) on Intel and other platforms. This version is compatible with +X11R6.6. See the Copyright Notice. The sources for XFree86 are available by anonymous ftp from: -ftp://ftp.XFree86.org/pub/XFree86/4.2.0 +ftp://ftp.XFree86.org/pub/XFree86/4.3.0 -Binaries for NetBSD 1.4 and later are available from: -ftp://ftp.XFree86.org/pub/XFree86/4.2.0/binaries/NetBSD +Binaries for NetBSD 1.5 and later are available from: +ftp://ftp.XFree86.org/pub/XFree86/4.3.0/binaries/NetBSD A list of mirror sites is provided by http://www.xfree86.org/MIRRORS.shtml @@ -33,7 +34,7 @@ if you have comments or suggestions about this file and we'll revise it. 3. New OS dependent features -See the Release Notes for non-OS dependent new features in XFree86 4.2.0. +See the Release Notes for non-OS dependent new features in XFree86 4.3.0. 3.1 New OS dependent features in 4.2.0 @@ -111,7 +112,7 @@ the xvidtune utility. 5.1 About mouse configuration -XFree86 4.2.0 has support for the mouse driver included in the wscons console +XFree86 4.3.0 has support for the mouse driver included in the wscons console driver introduced by NetBSD 1.4. Specify ``wsmouse'' as the protocol and ``/dev/wsmouse0'' as the device in /etc/X11/XF86Config if you're using NetBSD 1.4 or later with a PS/2 mouse. @@ -229,14 +230,14 @@ By default NetBSD include the BSD 4.4 kernel security feature that disable access to the /dev/mem device when in multi-users mode. But XFree86 servers can take advantage (or require) linear access to the display memory. -Most XFree86 4.2.0 card drivers require linear memory access. There are two +Most XFree86 4.3.0 card drivers require linear memory access. There are two ways to allow XFree86 to access linear memory: The first way is to disable the kernel security feature by adding ``option INSECURE'' in the kernel configuration file and build a new kernel. The second way is to install the aperture driver, included in source form in -xc/programs/Xserver/hw/xfree86/etc/apNetBSD.shar in the XFree86 4.2.0 source +xc/programs/Xserver/hw/xfree86/etc/apNetBSD.shar in the XFree86 4.3.0 source distribution. Unpack it in a new directory of your choice by running: sh apNetBSD.shar @@ -374,10 +375,11 @@ __bsdi__ for BSD/386. 10. Thanks Many thanks to all people who contributed to make XFree86 work on *BSD, in -particular, David Dawes, Pace Willison, Amancio Hasty, Christoph Robitschko, -Nate Williams, Rod Grimes, Jack Velte and Michael Smith. +particular: David Dawes, Todd Fries, Rod Grimes, Charles Hannum, Amancio +Hasty, Christoph Robitschko, Matthias Scheler, Michael Smith, Ignatios Sou- +vatzis, Jack Velte, Nate Williams and Pace Willison. - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/NetBSD.sgml,v 3.63 2002/01/16 22:35:18 herrb Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/NetBSD.sgml,v 3.68 2003/02/16 17:21:11 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.NetBSD,v 3.80 2002/01/16 22:37:23 herrb Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.NetBSD,v 3.87 2003/02/24 04:03:22 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.OpenBSD b/xc/programs/Xserver/hw/xfree86/doc/README.OpenBSD index 32a30b90d..e96c9cbe6 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/README.OpenBSD +++ b/xc/programs/Xserver/hw/xfree86/doc/README.OpenBSD @@ -1,29 +1,30 @@ - README for XFree86 4.2.0 on OpenBSD + README for XFree86 4.3.0 on OpenBSD Matthieu Herrb - Last modified on: 16 January 2002 + Last modified on: 9 November 2002 1. What and Where is XFree86? -XFree86 is the Open Source port of X.Org's X11R6.6 release that supports sev- -eral UNIX(R) and UNIX-like (such as Linux, the BSDs and Solaris x86) operat- -ing systems on Intel and other platforms. +XFree86 is an Open Source version of the X Window System that supports sev- +eral UNIX(R) and UNIX-like operating systems (such as Linux, the BSDs and +Solaris x86) on Intel and other platforms. This version is compatible with +X11R6.6. See the Copyright Notice. -The sources for XFree86 4.2.0 are available by anonymous ftp from: +The sources for XFree86 4.3.0 are available by anonymous ftp from: -ftp://ftp.XFree86.org/pub/XFree86/4.2.0 +ftp://ftp.XFree86.org/pub/XFree86/4.3.0 -Binaries for OpenBSD/i386 3.0 and later are available from: +Binaries for OpenBSD/i386 3.2 and later are available from: -ftp://ftp.XFree86.org/pub/XFree86/4.2.0/binaries/OpenBSD +ftp://ftp.XFree86.org/pub/XFree86/4.3.0/binaries/OpenBSD A list of mirror sites is provided by http://www.xfree86.org/MIRRORS.shtml XFree86 also builds on other OpenBSD architectures. See section Building on -other architectures (section 8.2, page 1) for details. +other architectures (section 8., page 1) for details. 2. Bug Reports for This Document @@ -32,21 +33,25 @@ if you have comments or suggestions about this file and we'll revise it. 3. New OS dependent features -See the Release Notes for non-OS dependent new features in XFree86 4.2.0. +See the Release Notes for non-OS dependent new features in XFree86 4.3.0. -3.1 New OS dependent features in 4.2 +3.1 New OS related features in 4.3 - o Support for OpenBSD/macppc on the ATI Rage128 based Power Macintosh. + o Support for some VGA cards on OpenBSD/alpha + +3.2 New OS dependent features in 4.2 + + o Support for OpenBSD/macppc on the ATI Rage128 based Power Macintoshes. o Support for building clients on OpenBSD/sparc64. -3.2 New OS dependent features in 4.0.3 +3.3 New OS dependent features in 4.0.3 o Support for the wscons console driver in post 2.8 OpenBSD. o A fix for multi-threaded libraries support. -3.3 New OS dependent features in 4.0.2 +3.4 New OS dependent features in 4.0.2 o Support for the OpenBSD ports tree, @@ -57,7 +62,7 @@ See the Release Notes for non-OS dependent new features in XFree86 4.2.0. o startx now creates an Xauthority magic cookie for the display. -3.4 New OS dependent features in 4.0.1 +3.5 New OS dependent features in 4.0.1 o Several features from the OpenBSD X11 tree were merged into xdm: @@ -76,21 +81,21 @@ See the Release Notes for non-OS dependent new features in XFree86 4.2.0. o The Xsun server can be built again on OpenBSD/sparc. -3.5 New OS dependent features in 4.0 +3.6 New OS dependent features in 4.0 o Multi-thread safe libraries are built by default on OpenBSD 2.6 and later, o Preliminary APM support. -3.6 New OS dependent features in 3.9.18 +3.7 New OS dependent features in 3.9.18 o Support for USB mices has been added on OpenBSD. o Soft-booting secondary cards through the int10 BIOS interface is now possible using the x86emu real mode emulator. -3.7 New OS dependent features in 3.9.17 +3.8 New OS dependent features in 3.9.17 o Silken mouse is supported for serial mices, and, under post 2.6 OpenBSD- current for PS/2 mices. @@ -128,7 +133,7 @@ the xvidtune utility. 5.1 About mouse configuration -XFree86 4.2.0 has support for the mouse driver included in the new wscons +XFree86 4.3.0 has support for the mouse driver included in the new wscons console driver introduced by OpenBSD-2.9. Specify ``wsmouse'' as the proto- col and ``/dev/wsmouse0'' as the device in /etc/X11/XF86Config if you're using OpenBSD-2.9 or later with a PS/2 or USB mouse. @@ -171,7 +176,6 @@ directory as described in the xinit and startx man pages. To make sure X support is enabled under OpenBSD, the following line must be in your config file in /sys/arch/i386/conf: - option XSERVER option APERTURE 7.1 Console drivers @@ -217,60 +221,42 @@ in /etc/rc.securelevel. OpenBSD supports System V shared memory. If XFree86 detects this support in your kernel, it will support the MIT-SHM extension. -To add support for system V shared memory to your kernel add the lines: - - # System V-like IPC - options SYSVMSG - options SYSVSEM - options SYSVSHM - -to your kernel config file. - 8. Rebuilding the XFree86 Distribution You should configure the distribution by editing xc/config/cf/host.def before compiling. To compile the sources, invoke ``make World'' in the xc directory." -8.1 Console drivers - -XFree86 has a configuration option to select the console drivers to use in -host.def: - - o if you're using pccons only put: - - #define XFree86ConsoleDefines -DPCCONS_SUPPORT - - o if you're using pcvt only put: +Note that OpenBSD project now has its own source tree, based on the XFree86 +source tree, with some local modifications. You may want to start with this +tree to rebuild from sources. The OpenBSD XF4 source tree is available by +anoncvs from all OpenBSD anoncvs servers. See http://www.openbsd.org/anon- +cvs.html for details on anoncvs. - #define XFree86ConsoleDefines -DPCVT_SUPPORT +XFree86 also compiles on other OpenBSD architectures. -If you don't define XFree86ConsoleDefines in host.def the pccons and pcvt -drivers will be supported by default. +8.1 XFree86 on OpenBSD/alpha -Native support for the wscons console driver found on OpenBSD/macppc and on -OpenBSD/i386 2.9 and later is built by adding: +The XFree86 server is known to work on some VGA cards in alpha machines that +support BWX I/O, with OpenBSD 3.2 and higher. - #define XFree86ConsoleDefines -DWSCONS_SUPPORT +The following cards have been successfully tested for now: -to xc/config/host.def before rebuilding the server. + o 3DLabs Permedia 2 (8, 15, 16 and 24 bits depth) -For the i386, you should include both pcvt and wscons support in order to use -the pcvt compatibility mode of wscons: + o ATI Rage Pro (works with 'Option "NoAccel"') - #define XFree86ConsoleDefines -DPCVT_SUPPORT -DWSCONS_SUPPORT + o Cirrus Logic CL5430 (works with 'Option "NoAccel"') -8.2 Building on other architectures + o Cirrus Logic GD5446 (8, 16 and 24 bits depth) -XFree86 also compiles on other OpenBSD architectures. + o Matrox MGA 2064 (8, 16 and 24 bits depth) -Note that OpenBSD project now has its own source tree, based on the XFree86 -source tree, with some local modifications. You may want to start with this -tree to rebuild from sources. The OpenBSD XF4 source tree is available by -anoncvs from all OpenBSD anoncvs servers. See http://www.openbsd.org/anon- -cvs.html for details on anoncvs. +Note that this version of XFree86 doesn't work on TGA cards. The version +shipped with OpenBSD 3.1 and higher includes an OS-specific driver wsfb that +is used to support TGA cards. -8.2.1 XFree86 on OpenBSD/macppc +8.2 XFree86 on OpenBSD/macppc The XFree86 server is currently known to work on the G4 Macs and new iBooks with ATI Rage 128 cards running OpenBSD 3.0 or later. Other machines are @@ -280,17 +266,22 @@ it. Use xf86config to build a /etc/X11/XF86Config file before starting the server for the first time. -Tou configure the keyboard, the protocol should be specified as wskbd and the -device as /dev/wskbd0. Using a wsmux device as the keyboard device doesn't -work (yet). Use macintosh as XkbModel. - For the Titanium Powerbook G4, you can try the following mode line in /etc/X11/XF86Config to match the flat panel resolution: - Modeline "1152x768" 78.741 1152 1173 1269 1440 768 769 772 800 +HSync +VSync + Modeline "1152x768" 64.995 1152 1213 1349 1472 768 771 777 806 -HSync -VSync + +8.3 XFree86 on OpenBSD/sparc + +OpenBSD 3.2 on sparc switched to the wscons device driver and now uses the OS +specific wsfb driver in the XFree86 server. This driver is not included in +XFree86 4.3. Please use the version shipped with OpenBSD instead. + +8.4 XFree86 on OpenBSD/sparc64 -You need to set securelevel to -1 in the /etc/rc.securelevel configuration -file to run XFree86 on OpenBSD/macppc. +This version of XFree68 only has support for X clients on OpenBSD/sparc64. +Note that the version shipped with OpenBSD also has support for the X server +on both SBus and PCI based machines. 9. Building New X Clients @@ -303,10 +294,11 @@ whatis /usr/X11R6/man''. 10. Thanks Many thanks to all people who contributed to make XFree86 work on *BSD, in -particular, David Dawes, Pace Willison, Amancio Hasty, Christoph Robitschko, -Nate Williams, Rod Grimes, Jack Velte and Michael Smith. +particular: David Dawes, Todd Fries, Rod Grimes, Charles Hannum, Amancio +Hasty, Christoph Robitschko, Matthias Scheler, Michael Smith, Ignatios Sou- +vatzis, Jack Velte, Nate Williams and Pace Willison. - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/OpenBSD.sgml,v 1.24 2002/01/16 22:35:17 herrb Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/OpenBSD.sgml,v 1.30 2003/02/25 19:31:01 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.OpenBSD,v 1.30 2002/01/16 22:37:23 herrb Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.OpenBSD,v 1.38 2003/02/25 21:32:34 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.SCO b/xc/programs/Xserver/hw/xfree86/doc/README.SCO index 9bdb000df..f5f87481e 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/README.SCO +++ b/xc/programs/Xserver/hw/xfree86/doc/README.SCO @@ -2,129 +2,85 @@ J. Kean Johnston (jkj@sco.com) - 21 May 2001 - -1. Binary Distribution - -The following files are provided in the binary distribution: - - README.SCO - This file. - - gunzip.Z - The GNU uncompress utility. - - *X312Xdoc.tgz - The XFree86 specific documentation. - - X312Mono.tgz - The Mono server - - X312VG16.tgz - The 16 colour VGA server - - X312SVGA.tgz - The Super VGA server - - X312S3.tgz - The S3 server - - X3128514.tgz - The 8514 server - - X312AGX.tgz - The AGX server - - X312Mc32.tgz - The Mach 32 server - - X312Mc64.tgz - The Mach 64 server - - X312Mc8.tgz - The Mach 8 server - - X312P9k.tgz - The P9000 server - - *X312cfg.tgz - The local configuration files for xdm/fs/xinit. - - *X312bin.tgz - The bin directory, contains most executables. - - *X312lib.tgz - The shared and unshared libraries. - - *X312fnt1.tgz - 75dpi and misc fonts. - - X312fnt2.tgz - 100dpi and Speedo fonts. - - *X312inc.tgz - The X11 include files. - - X312man.tgz - The formatted man pages. - - X312lkit.tgz - The server link kit (all drivers + PEX). - - X312util.tgz - Lots of PD utilities provided as is. - - X312pex.tgz - All files relating to PEX including libraries and - header files. The LinkKit is required to obtain - servers capable of running PEX. - -To obtain a minimum XFree86 installation you will require the archives marked -with a `*' above, the server binary best suited to your machine and option- -ally "gunzip.Z". All the files are compressed with "gzip" except of course -"gunzip.Z" which is compressed using the conventional compress program. - -To install the XFree86 binaries just follow these steps. - - 1. Obtain the files you require. - - The rest of this procedure must be done as root. If you do not run the - extraction as root the permissions on the files will not be correct. - For example, the `X' server is s-bit root and will not function cor- - rectly if extracted as an ordinary user. - - 2. create a directory /usr/X11R6, permissions 755 should do nicely. - - 3. cd /usr/X11R6 - - 4. extract the archives, for example: - - gunzip < X312bin.tgz | tar xvpf - - - 5. if you have installed man pages see the later section on setting up man - pages. - - 6. Look through /usr/X11R6/lib/X11/doc/INSTALL, especially section 2 on - configuring and using XFree86. This should allow you to get a server - up and running. Before starting the server check in the later section - Before Running XFree86 (section 3., page 1), in this document, to see - if there are any system requirements you have to make for the server to - operate correctly. - -2. Source Distribution - -The SCO port comes as part of the standard XFree86 distribution. Consult the -XFree86 README for more information on the location of sources. - -Please note that as of XFree86 3.2, Only SCO Open Server Release 5 and -onwards are supported. If you are using a previous version of SCO UNIX and -you want to use XFree86, use the 3.1 series, or be prepared for build fail- -ures. - -For people who want and need to look around the source, there are now two -files in ``xc/config/cf''. Firstly, ``sco.cf'' is the old original SCO con- -figuration file, and ``sco5.cf'', which is the currently used configuration -file. + 14 February 2003 + +1. Requirements + +Before you can either compile or execute a binary distribution of XFree86, +the following conditions must be met: + + o Ensure that you are running Release 5.0.4 or later. This is required + because OSS646 is only supported on those platforms. There are no plans + to support XFree86 on earlier releases of OpenServer. + + o Ensure that OSS646, the ``Execution Environment Update'' package is + installed, if appropriate. Check the release notes for that update to + see whether or not your current operating system requires this update. + This supplement will be available to the public in February 2003. + + o Ensure that OSS631, the "Graphics, Web and X11 Libraries" package is + installed. This ships standard with release 5.0.7 and later, and is + only required for 5.0.[456] users. This package will be updated fairly + frequently, and it us always suggested you have the latest possible ver- + sion installed. At some point in the future it may even update the + libraries in 5.0.7, so it is worth checking the release notes for this + supplement. + + o To compile XFree86, you must use the SCO-supported version of the GNU C + Compiler. It is possible that Skunkware versions of the compiler will + work too, but this has not been tested. The ``GNU Development System'' + is available for all releases from (and including) SCO OpenServer + Release 5.0.5. It is provided with the operating system in all versions + from Release 5.0.7, although you need to run ``custom'' to install it + from the media. You can always download the latest latest version of + the GNU Development System from the SCO Web site + <URL:http://www.sco.com>. + + o If you are not using OSR 5.0.7 or later, you need to get an updated con- + sole driver. See <URL:http://www.sco.com> for details on OpenServer + supplements. If you can't or don't want to upgrade your console driver, + XFree86 will still compile, but you may run into problems with some + cards such as the Riva TNT and ATI Rage cards. The problem with the + console driver in 5.0.6A and earlier is that when the X server sets + graphics mode, the driver does not set a status bit, so any text that is + sent directly to /dev/console, such as kernel warning or notice messages + when you access tape drives or NFS notices, will be sent to the console + video memory. This just happens to be slap bang in the middle of + palette data for the Riva TNT, so you get color map corruption. The + updated console driver also has an improved mechanism for allocating + video memory that XFree86 detects at compile time, and it will use it if + it exists. It is STRONGLY recommended that you get the console driver + update. + +2. Compiling XFree86 + +Using the GNU Development System, compiling XFree86 should be fairly +straightforward. Before attempting to compile the system though, you should +make sure that you have met all of the requirements above. To actually start +the compilation, perform the following steps: + + o Copy the unmodified xf86site.def in xc/config/cf to host.def. Edit + host.def and make any changes you think you need. The most useful + options to change are HasTcl, HasTk, HasXdmAuth if you have the file + WrapHelp.c and GccWarningOptions. Due to the nature of OpenServer's + header files, the default options for this last setting are a bit + aggressive, and I recommend you set this option to -Wpointer-arith. + + o Make sure that the official version of the GNU Development System is + first in your PATH. The official version lives in /usr/gnu/bin, and the + Skunkware version (if any) lives in /usr/local/bin. You must ensure that + /usr/gnu/bin appears first in your PATH. + + o Go to the top level of the source tree and execute the command CC=gcc + make World BOOTSTRAPCFLAGS=-DSCO5 2>&1 | tee world.log. This will do a + full build, and send all of the build results to the file world.log. + + o If the build succeeded, install the new server by executing the command + make install 2>&1 | tee install.log as root. This will send the install + results to the file install.log. + + o If you want to install the manual pages, execute the command make + install.man 2>&1 | tee -a install.log as root. 3. Before Running XFree86 @@ -132,76 +88,11 @@ The SCO xterm terminfo description is not compatible with the xterm in the R5 distribution. To use a Bus/Keyboard or PS2 mouse you should configure the mouse drivers -under SCO as above using 'mkdev mouse'. You may then use the OsMouse option -in your XF86Config to specify that XFree86 should use the SCO mouse drivers. -To do this, set the Protocol to "OsMouse" in the Pointer section of your -XF86Config file. You can also use "OsMouse" for your serial mouse, espe- -cially if you are having trouble getting your mouse to work using the XFree86 -mouse drivers. - -If you do not have the SCO TCP/IP package installed do not panic. XFree86 -will work fine without TCP/IP but you will most likely have to do some or all -of these things: - - o Do not worry about errors from the X server complaining about - ``/dev/socksys''. The X server is configured to run on systems with and - without TCP/IP. This error is just pointing out that you do not have - TCP/IP and that this method of connecting to the server has been dis- - abled. - - o Do worry about errors involving ``/dev/spx'' or the ``sco'' connection - type. This means something is wrong with the streams pipes that are - used for connections on the local machine. First be sure that your - server has the ``s-bit'' set. You can do this by running this command - for the X server you are using: - - ls -al /usr/X11R6/bin/XF86_XXXXXX - - The output should contain the `s' character instead of the `x' charac- - ter. For example: - - -rwsr-xr-x 1 root bin 1074060 Jul 24 11:54 XF86_S3 - - is correct while: - - -rwxr-xr-x 1 root bin 1074060 Jul 24 11:54 XF86_S3 - - is not. - - o you may have to install streams into the kernel with ``mkdev streams'' - Check the SCO Manuals for more information on this. - - o you may have to configure some devices in /dev, check in the "Trouble - Shooting" section of this document for the entry which comments on - ``/dev/spx'' and ``Xsco''. - - o Your streams resources may be configured too low. You should check your - streams parameters against the following values, if the are higher then - you do not need to changes them. To check these values, login as root, - change directory to ``/etc/conf/cf.d'' and then run ``./configure''. - - Once you are running configure, choose the ``Streams Data'' option and - step through the entries. Just press <ENTER> at each prompt unless you - want to change a value. The values to look for, and their minimum val- - ues, are: - - NSTREAM 128 - NQUEUE 512 - NBLK4096 4 - NBLK2048 32 - NBLK1024 32 - NBLK512 32 - NBLK256 64 - NBLK128 256 - NBLK64 256 - NBLK16 256 - NBLK4 128 - NUMSP 128 - - You will not normally need to change any of these, if however you do - have to change some, configure will confirm that you want to save the - changes before exiting, and will give you further instructions on - rebuilding the unix kernel. +using 'mkdev mouse'. You may then use the OsMouse option in your XF86Config +to specify that XFree86 should use the SCO mouse drivers. To do this, set +the Protocol to "OsMouse" in the Pointer section of your XF86Config file. +You can also use "OsMouse" for your serial mouse, especially if you are hav- +ing trouble getting your mouse to work using the XFree86 mouse drivers. 4. Switching Consoles @@ -210,17 +101,21 @@ That is, Ctrl-PrntScr takes you to the next console along from the one X is running on. If this is the last console it will take you to console 1. Ctrl- Alt-FXX, where XX is a function key between F1 and F12 will switch you to the console number assigned to that function key. F1 corresponds to tty01 (or -console 1), F2 corresponds to tty02 (or console 2) etc. Those interested in -modifying the console switching should look in xc/pro- -grams/Xserver/hw/xfree86/common/xf86Events.c. +console 1), F2 corresponds to tty02 (or console 2) etc. + +Unlike the SCO X server, the "kill me now" key is Alt+Ctrl+Backspace. This +does not ask for confirmation, it simply kills the X server as immediately as +possible. Use with extreme caution. This may cause applications to termi- +nate in an unpredictable way. You can set the DontZap option in the Server- +Flags section of your XF86Config file to disable this. 5. Setting up Man Pages After compiling the tree, or after installing the binary distribution you can get man to recognise the XFree86 man pages by adding /usr/X11R6/man to the -MANPATH in /etc/default/man, the line should look similar to: +MANPATH in /etc/default/man. The line should look similar to: - MANPATH=/usr/man:/usr/X11R6/man + MANPATH=/usr/man:/usr/gnu/man:/usr/X11R6/man:/usr/local/man This allows all users to view the X man pages. You may change your own MAN- PATH environment variable if you do not want everyone to access the man @@ -228,325 +123,21 @@ pages. By default the man pages are compressed using ``compress'' to conserve space. If you do not want to compress the man pages change CompressManPages to NO in -your ``xf86site.def'' file. Those using the binary distribution can use -``uncompress'' to uncompress the man pages. +your ``host.def'' file. Those using the binary distribution can use ``uncom- +press'' to uncompress the man pages. Binary distributions contain pre-for- +matted versions of all man pages. If you are compiling the server yourself, +you need to have the GNU Tools package installed to get groff, the GNU nroff +replacement, to format the man pages. Use the manroff script to format the +manual pages yourself. 6. Using SCO binaries/servers. XFree86 will accept connections from SCO binaries (R3 upwards) and the SCO R5 server will also accept connections from XFree86 binaries. This means you may mix and match the two if you have ODT. For example you may still use the -Motif window manager (mwm) if you prefer. - -7. Compiling XFree86 under Open Server 5 - -As of GCC version 2.8.0, Open Server is supported. Configure it by using the -following: - - ./configure i486-sco3.2v5.0 - -There is no reason to modify gcc in any way. It compiles cleanly on Open -Server 5. - -SCO Open Server 5.0 is recognised automatically by XFree86. You do not need -to specify any BOOTSTRAPCFLAGS parameters when doing a make World. You can -ignore the warning message about BOOTSTRAPCFLAGS at the very beginning of a -make World. - - 1. Fine tune ``site.def/xf86site.def'' - - Use GCC if you can. XFree should compile with the DevSys cc, but GCC - has better optimizations, and is guaranteed to work. - - 2. SCO Open Server comes with Visual TCL, which is an old (and incompati- - ble) version of TCL. If you want to use XF86Setup you will have to com- - pile Tcl and Tk yourself. Both are supported well on SCO Open Server 5. - Tcl 7.6 and Tk 4.2 are available from ftp://ftp.smli.com/pub/tcl. - - 3. You may want to disable dynamic loading support. Several users have - reported trouble with this. XIE and PEX5 definitely do not work. If you - want to experiment, try enabling this. Please report successes or fail- - ures to me. - - 4. Do not enable the HasSVR3mmapDrv as you may have done in older versions - of SCO. Open Server 5 has full mmap() support, and this is used for - direct frame buffer access. - - 5. If you know you will not ever be using COFF binaries, and you are short - of space, set ForceNormalLib to NO. Doing this will cause only the ELF - versions of the libraries to be built. ``sco5.cf'' sets this to YES by - default, so you must explicitly set it to NO in ``xf86site.def''. All - binaries are compiled in ELF mode to reduce space. - -8. Relevant Documentation - -Some relevant documentation for SCO Users and Developers can be found in the -following files. - - README - the standard XFree86 README (/usr/X11R6/lib/X11/doc) - - README.SVR3 - Although a lot of this readme is based on Interactive a substan- - tial proportion is still relevant. - - All of the VGA/Config documentation. - /usr/X11R6/lib/X11/doc/VideoModes.doc and the README files for - particular video cards. - -9. Known Problems - - o After running the server you may see some strange characters in your - input to the shell. This is due to some unprocessed scancodes and is of - no concern. This will be fixed in a future release. - - o Not all of the applications in /usr/X11R6/bin have been debugged. - -10. Trouble Shooting - - Problem: - - The server does not start up, and I cannot tell what - is going wrong as it did not print any error messages. - - Causes: - - There can be any number of causes why the server - doesn't start. The first step is to find out what the - server has to say. To do this we have to catch the - error output of the server into a file. This output - contains a log of what the server is finding/doing as - it starts up. To get this output run: - - startx 2> /tmp/errs - - The output of the server will now be in "/tmp/errs". - You should look through this output for possible prob- - lems, and then check here in this document for any - references to the problems you are seeing. - - Problem: - - The server starts up, the screen goes blank, and I - never see anything else. It appears that my machine - has hung. - - Causes: - - Again this can have many causes. Most likely your - XF86Config is wrong. You should be able to kill the - server by typing Ctrl-Alt-BackSpace, if it is still - running. If this does not restore your display then - you may have to drive your system blind. Always keep - another login running at the shell prompt so that you - may switch to that screen and run commands even if you - cannot see anything on the screen. Try these things, - usually in the order given: - - o log out of the login where you started ``X'' and - then change consoles. This will cause the SCO - screen switching code to try to reset the card. - - o run ``vidi v80x25'', this command will also try - to set your card into a viewable mode. - - o shutdown the machine cleanly with ``shutdown'' and - try again. - - When first trying to get XFree86 to run, be sure to - use a simple setup. Get 640x480 working first then - move on to higher resolutions. Always trap the output - of the server as shown earlier. Once you have the - valid clocks for your video card (as provided in the - server output), hard code them into your XF86Config as - this will take some strain off your monitor during - XFree86 startup where it usually probes the various - clock frequencies. Getting the ``X'' screen to appear - can be a painfully slow task. Be patient and read as - much of the doco as you can handle. You will get it to - work. - - Problem: - - Fatal server error: - xf86MapVidMem:No class map defined for (XXXXX,XXXXX) - - Causes: - - 1. Your system does not have the correct - /etc/conf/pack.d/cn/class.h, You can confirm this - by editing the file and looking for the string - "SVGA", if it is not there then you should re- - install this file from the "Extended Utilities" - diskettes provided with your OS. If this is not - possible then installing the "dmmap" driver from - the distribution may allow the server to operate - correctly. - - Problem: - - xf86install does not work. - - Causes: - - You should not be running xf86install when using the - XFree86 server under SCO. It is used for Interactive - (ISC) installations. - - Problem: - - The server starts but the screen is not aligned cor- - rectly or is shaky and impossible to view. - - Causes: - - This is most likely due to an incorrect XF86Config - setup. Look for the files README.Config Video- - Modes.doc (in /usr/X11R6/lib/X11/doc with the binary - distribution). These files explains how to fix up your - video modes. - - Problem: - - 1. Can only run a limited number of xterms. - - 2. xterm does not work but other programs like xclock do work. - - Causes: - - Not enough or no pseudo ttys devices are present on - your system. Run "mkdev ptty" and increase the number - of ptty's. - - Problem: - - When running curses/termcap applications in an xterm - the output gets corrupted especially when scrolling. - - Causes: - - 1. You are running an original 1.3 distribution of XFree86. - Update to the latest version (3.2 or greater). - - 2. You have resized the window and not ran "eval `resize`" - before using your application. The SCO operating system - does not support dynamic resizing of xterms fully so this - command must be run after resizing an xterm in order for - curses/termcap applications to operate correctly. - - Problem: - - 1. When starting X it dies with an error "Cannot access a - needed shared library". - - 2. When starting an X application is dies with the above - error. - - Causes: - - 1. You do not have the binaries installed in the correct - directory. Check that they are in /usr/X11R6 - - 2. You have upgraded to a new binary distribution which has a - new version of the shared libraries which are not compati- - ble with your old binaries. To fix this you will need to - re-install the old shared libraries or recompile your - application against the new libraries. - - Problem: - - When linking against the SCO motif library I get an - unresolved external for "XtDisplayStringConversionWarn- - ing" when using gcc. - - Causes: - - The SCO library is compiled with limited length identi- - fiers. To work around this add the following code to - your application when compiling under XFree86 with gcc - and SCO motif. - - #ifdef SCO - void XtDisplayStringConversionWarnin(dpy, from, toType) - Display* dpy; - String from; - String toType; - { XtDisplayStringConversionWarning(dpy, from, toType); } - #endif - - Problem: - - The server fails to run and prints out a line similar - to: - - XFree86: Cannot open /dev/spx for ???? listener: No - such file or directory - - Causes: - - All SCO unix installations appear to have the Streams - pseudo tty driver installed, but not all the devices - are present. - - 1. there should be a /etc/conf/pack.d/sp directory, - - 2. /etc/conf/sdevice.d/sp should have a 'Y' in it. - - 3. You need a file in /etc/conf/node.d which con- - tains something like: - - clone spx c sp - sp X0S c 127 - sp X0R c 126 - sp X1S c 125 - sp X1R c 124 - sp X2S c 123 - sp X2R c 122 - sp X3S c 121 - sp X3R c 120 - sp X4S c 119 - sp X4R c 118 - sp X5S c 117 - sp X5R c 116 - sp X6S c 115 - sp X6R c 114 - sp X7S c 113 - sp X7R c 112 - - if you don't have something like this (maybe called - "Xsco") then create one and that should fix your prob- - lem. As far as I can tell the streams pseudo tty - driver should be there. - - The simplest way to get the devices if you had to cre- - ate this file is to rebuild the kernel and the environ- - ment. If you don't want to do this then: - - touch /etc/.new_unix - cd /etc/conf/bin - ./idmkenv - - and try it out. - -11. Acknowledgements - -Thanks to the Core team for their previous and continuing help with the SCO -work. Many thanks to Stacey Campbell at SCO for all the advice and insights -provided. Thanks to SCO in general for making information available for -XFree86 development. - -Thanks also to Peter Eubert (peter.eubert@iwb.mw.tu-muenchen.dbp.de) and Kent -Hamilton (kenth@stl.scscom.COM) for input on compiling under 3.2.4 systems. -Larry Plona (faxi@world.std.com) and Didier Poirot (dp@chorus.fr) for their -input on xdm and 3.2.4 compilation under 3.1. And of course the beta list -for its input on everything. - -Special thanks to Jerry Whelan (guru@stasi.bradley.edu) for providing an ftp -site for the binary distribution. - - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/SCO.sgml,v 3.18 2001/06/30 22:41:48 tsi Exp $ +Panning Motif window manager (pmwm) if you prefer. - $XConsortium: SCO.sgml /main/11 1996/10/23 11:45:55 kaleb $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/SCO.sgml,v 3.22 2003/02/17 18:58:07 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.SCO,v 3.32 2001/06/30 22:58:10 tsi Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.SCO,v 3.34 2003/02/17 18:59:41 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.Solaris b/xc/programs/Xserver/hw/xfree86/doc/README.Solaris index eccf3615c..b02a89c9a 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/README.Solaris +++ b/xc/programs/Xserver/hw/xfree86/doc/README.Solaris @@ -212,11 +212,9 @@ ever a number of ioctl() calls are broken. 6. Bug Notification -Bug reports should be sent to one of the XFree86@XFree86.org, -Xpert@XFree86.org, or Newbie@XFree86.org (depending on your level of com- -fort). +Bug reports should be sent to <XFree86@XFree86.org>. - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Solaris.sgml,v 1.3 2002/01/25 21:55:53 tsi Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Solaris.sgml,v 1.4 2003/01/04 04:20:23 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.Solaris,v 1.3 2002/01/28 22:24:17 tsi Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.Solaris,v 1.4 2003/01/04 04:28:27 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.XKB-Config b/xc/programs/Xserver/hw/xfree86/doc/README.XKB-Config new file mode 100644 index 000000000..a2faba586 --- /dev/null +++ b/xc/programs/Xserver/hw/xfree86/doc/README.XKB-Config @@ -0,0 +1,198 @@ + The XKB Configuration Guide + + Kamil Toman, Ivan U. Pascal + + 25 November 2002 + + Abstract + + This document describes how to configure XFree86 XKB from a user's + point a few. It converts basic configuration syntax and gives also + a few examples. + +1. Overview + +The XKB configuration is decomposed into a number of components. Selecting +proper parts and combining them back you can achieve most of configurations +you might need. Unless you have a completely atypical keyboard you really +don't need to touch any of xkb configuration files. + +2. Selecting XKB Configuration + +The easiest and the most natural way how to specify a keyboard mapping is tu +use rules component. As its name suggests it describes a number of general +rules how to combine all bits and pieces into a valid and useful keyboard +mapping. All you need to do is to select a suitable rules file and then to +feed it with a few parameters that will adjust the keyboard behaviour to ful- +fill your needs. + +The parameters are: + + o XkbRules - files of rules to be used for keyboard mapping composition + + o XkbModel - name of model of your keyboard type + + o XkbLayout - layout(s) you intend to use + + o XkbVariant - variant(s) of layout you intend to use + + o XkbOptions - extra xkb configuration options + +The proper rules file depends on your vendor. In reality, the commonest file +of rules is xfree86. For each rules file there is a description file named +<vendor-rules>.lst, for instance xfree86.lst which is located in xkb configu- +ration subdirectory rules (for example /etc/X11/xkb/rules). + +2.1 Basic Configuration + +Let's say you want to configure a PC style America keyboard with 104 keys as +described in xfree86.lst. It can be done by simply writing several lines from +below to you XFree86 configuration file (often found as /etc/X11/XF86Config-4 +or /etc/X11/XF86Config): + + Section "InputDevice" + Identifier "Keyboard1" + Driver "Keyboard" + + Option "XkbModel" "pc104" + Option "XkbLayout" "us" + Option "XKbOptions" "" + EndSection + +The values of parameters XkbModel and XkbLayout are really not surprising. +The parameters XkbOptions has been explicitly set to empty set of parameters. +The parameter XkbVariant has been left out. That means the default variant +named basic is loaded. + +Of course, this can be also done at runtime using utility setxkbmap. Shell +command loading the same keyboard mapping would look like: + + setxkbmap -rules xfree86 -model pc104 -layout us -option "" + +The configuration and the shell command would be very analogical for most +other layouts (internationalized mappings). + +2.2 Advanced Configuration + +Since XFree86 4.3.x you can use multi-layouts xkb configuration. What does +it mean? Basically it allows to load up to four different keyboard layouts at +a time. Each such layout would reside in its own group. The groups (unlike +complete keyboard remapping) can be switched very fast from one to another by +a combination of keys. + +Let's say you want to configure your new Logitech cordless desktop keyboard, +you intend to use three different layouts at the same time - us, czech and +german (in this order), and that you are used to Alt-Shift combination for +switching among them. + +Then the configuration snippet could look like this: + + Section "InputDevice" + Identifier "Keyboard1" + Driver "Keyboard" + + Option "XkbModel" "logicordless" + Option "XkbLayout" "us,cz,de" + Option "XKbOptions" "grp:alt_shift_toggle" + EndSection + +Of course, this can be also done at runtime using utility setxkbmap. Shell +command loading the same keyboard mapping would look like: + + setxkmap -rules xfree86 -model logicordless -layout "us,cz,de" \ + -option "grp:alt_shift_toggle" + +2.3 Even More Advanced Configuration + +Okay, let's say you are more demanding. You do like the example above but you +want it to change a bit. Let's imagine you want the czech keyboard mapping to +use another variant but basic. The configuration snippet then changes into: + + Section "InputDevice" + Identifier "Keyboard1" + Driver "Keyboard" + + Option "XkbModel" "logicordless" + Option "XkbLayout" "us,cz,de" + Option "XkbVariant" ",bksl," + Option "XKbOptions" "grp:alt_shift_toggle" + EndSection + +That's seems tricky but it is not. The logic for settings of variants is the +same as for layouts, that means the first and the third variant settings are +left out (set to basic), the second is set to bksl (a special variant with an +enhanced definition of the backslash key). + +Analogically, the loading runtime will change to: + + setxkmap -rules xfree86 -model logicordless -layout "us,cz,de" \ + -variant ",bksl," -option "grp:alt_shift_toggle" + +2.4 Basic Global Options + +See rules/*.lst files. + +3. Direct XKB Configuration + +Generally, you can directly prescribe what configuration of each of basic xkb +components should be used to form the resulting keyboard mapping. This +method is rather "brute force". You precisely need to know the structure and +the meaning of all of used configuration components. + +This method also exposes all xkb configuration details directly into XFree86 +configuration file which is a not very fortunate fact. In rare occasions it +may be needed, though. So how does it work? + +3.1 Basic Components + +There are five basic components used to form a keyboard mapping: + + o key codes - a translation of the scan codes produced by the keyboard + into a suitable symbolic form + + o types - a specification of what various combinations of modifiers pro- + duce + + o key symbols - a translation of symbolic key codes into actual symbols + + o geometry - a description of physical keyboard geometry + + o compatibility maps - a specification of what action should each key pro- + duce in order to preserve compatibility with XKB-unware clients + +3.2 Example Configuration + +Look at the following example: + + Section "InputDevice" + Identifier "Keyboard0" + Driver "Keyboard" + + Option "XkbKeycodes" "xfree86" + Option "XkbTypes" "default" + Option "XkbSymbols" "en_US(pc104)+de+swapcaps" + Option "XkbGeometry" "pc(pc104)" + Option "XkbCompat" "basic+pc+iso9995" + EndSection + +This configuration sets the standard XFree86 default interpretation of key- +board keycodes, sets the default modificator types. The symbol table is com- +posed of extended US keyboard layout in its variant for pc keyboards with 104 +keys plus all keys for german layout are redefined respectively. Also the +logical meaning of Caps-lock and Control keys is swapped. The standard key- +board geometry (physical look) is set to pc style keyboard with 104 keys. The +compatibility map is set to allow basic shifting, to allow Alt keys to be +interpreted and also to allow iso9995 group shifting. + +4. Keymap XKB Configuration + +It is the formerly used way to configure xkb. The user included a special +keymap file which specified the direct xkb configuration. This method has +been obsoleted by previously described rules files which are far more flexi- +ble and allow simpler and more intuitive syntax. It is preserved merely for +compatibility reasons. Avoid using it if it is possible. + + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/XKB-Config.sgml,v 1.2 2003/02/25 19:31:02 dawes Exp $ + + +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.XKB-Config,v 1.2 2003/02/25 21:32:35 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.XKB-Enhancing b/xc/programs/Xserver/hw/xfree86/doc/README.XKB-Enhancing new file mode 100644 index 000000000..0c5a0b5fb --- /dev/null +++ b/xc/programs/Xserver/hw/xfree86/doc/README.XKB-Enhancing @@ -0,0 +1,511 @@ + How to further enhance XKB configuration + + Kamil Toman, Ivan U. Pascal + + 25 November 2002 + + Abstract + + This guide is aimed to relieve one's labour to create a new (inter- + nationalized) keyboard layout. Unlike other documents this guide + accents the keymap developer's point of view. + +1. Overview + +The developer of a new layout should read the xkb protocol specification (The +X Keyboard Extension: Protocol Specification <URL:http://www.x- +docs.org/XKB/XKBproto.pdf>) at least to clarify for himself some xkb-specific +terms used in this document and elsewhere in xkb configuration. Also it shows +wise to understand how the X server and a client digest their keyboard inputs +(with and without xkb). + +A useful source is also Ivan Pascal's text about xkb configuration +<URL:http://www.tsu.ru/~pascal/en/xkb> often referenced throughout this docu- +ment. + +Note that this document covers only enhancements which are to be made to +XFree86 version 4.3.x and above. + +2. The Basics + +At the startup (or at later at user's command) X server starts its xkb key- +board module extension and reads data from a compiled configuration file. + +This compiled configuration file is prepared by the program xkbcomp which +behaves altogether as an ordinary compiler (see man xkbcomp). Its input are +human readable xkb configuration files which are verified and then composed +into a useful xkb configuration. Users don't need to mess with xkbcomp them- +selves, for them it is invisible. Usually, it is started upon X server +startup. + +As you probably already know, the xkb configuration consists of five main +modules: + + Keycodes + Tables that defines translation from keyboard scan codes into + reasonable symbolic names, maximum, minimum legal keycodes, sym- + bolic aliases and description of physically present LED-indica- + tors. The primary sence of this component is to allow definitions + of maps of symbols (see below) to be independent of physical key- + board scancodes. There are two main naming conventions for sym- + bolic names (always four bytes long): + + o names which express some traditional meaning like <SPCE> + (stands for space bar) or + + o names which express some relative positioning on a key- + board, for example <AE01> (an exclamation mark on US key- + boards), on the right there are keys <AE02>, <AE03> etc. + + Types + Types describe how the produced key is changed by active modi- + fiers (like Shift, Control, Alt, ...). There are several prede- + fined types which cover most of used combinations. + + Compat + Compatibility component defines internal behaviour of modifiers. + Using compat component you can assign various actions (elabo- + rately described in xkb specification) to key events. This is + also the place where LED-indicators behaviour is defined. + + Symbols + For i18n purposes, this is the most important table. It defines + what values (=symbols) are assigned to what keycodes (represented + by their symbolic name, see above). There may be defined more + than one value for each key and then it depends on a key type and + on modifiers state (respective compat component) which value will + be the resulting one. + + Geometry + Geometry files aren't used by xkb itself but they may be used by + some external programs to depict a keyboard image. + +All these components have the files located in xkb configuration tree in sub- +directories with the same names (usually in /usr/lib/X11/xkb). + +3. Enhancing XKB Configuration + +Most of xkb enhancements concerns a need to define new output symbols for the +some input key events. In other words, a need to define a new symbol map (for +a new language, standard or just to feel more comfortable when typing text). + +What do you need to do? Generally, you have to define following things: + + o the map of symbols itself + + o the rules to allow users to select the new mapping + + o the description of the new layout + +First of all, it is good to go through existing layouts and to examine them +if there is something you could easily adjust to fit your needs. Even if +there is nothing similar you may get some ideas about basic concepts and used +tricks. + +3.1 Levels And Groups + +Since XFree86 4.3.0 you can use multi-layout concept of xkb configuration. +Though it is still in boundaries of xkb protocol and general ideas, the +keymap designer must obey new rules when creating new maps. In exchange we +get a more powerful and cleaner configuration system. + +Remember that it is the application which must decide which symbol matches +which keycode according to effective modifier state. The X server itself +sends only an input event message to. Of course, usually the general inter- +pretation is processed by Xlib, Xaw, Motif, Qt, Gtk and similar libraries. +The X server only supplies its mapping table (usually upon an application +startup). + +You can think of the X server's symbol table as of a irregular table where +each keycode has its row and where each combination of modifiers determines +exactly one column. The resulting cell then gives the proper symbolic value. +Not all keycodes need to bind different values for different combination of +modifiers. <ENTER> key, for instance, usually doesn't depend on any modi- +fiers so it its row has only one column defined. + +Note that in XKB there is no prior assumption that certain modifiers are +bound to certain columns. By editing proper files (see keytypes (section 4.2, +page 1)) this mapping can be changed as well. + +Unlike the original X protocol the XKB approach is far more flexible. It is +comfortable to add one additional XKB term - group. You can think of a group +as of a vector of columns per each keycode (naturally the dimension of this +vector may differ for different keycodes). What is it good for? The group is +not very useful unless you intend to use more than one logically different +set of symbols (like more than one alphabet) defined in a single mapping +table. But then, the group has a natural meaning - each symbol set has its +own group and changing it means selecting a different one. XKB approach +allows up to four different groups. The columns inside each group are called +(shift) levels. The X server knows the current group and reports it together +with modifier set and with a keycode in key events. + +To sum it up: + + o for each keycode XKB keyboard map contains up to four one-dimensional + tables - groups (logically different symbol sets) + + o for each group of a keycode XKB keyboard map contains some columns - + shift levels (values reached by combinations of Shift, Ctrl, Alt, ... + modifiers) + + o different keycodes can have different number of groups + + o different groups of one keycode can have different number of shift lev- + els + + o the current group number is tracked by X server + +It is clear that if you sanely define levels, groups and sanely bind modi- +fiers and associated actions you can have simultaneously loaded up to four +different symbol sets where each of them would reside in its own group. + +The multi-layout concept provides a facility to manipulate xkb groups and +symbol definitions in a way that allows almost arbitrary composition of pre- +defined symbol tables. To keep it fully functional you have to: + + o define all symbols only in the first group + + o (re)define any modifiers with extra care to avoid strange (anisometric) + behaviour + +4. Defining New Layouts + +See Some Words About XKB internals <URL:http://www.tsu.ru/~pas- +cal/en/xkb/internals.html> for explanation of used xkb terms and problems +addressed by XKB extension. + +See Common notes about XKB configuration files language +<URL:http://www.tsu.ru/~pascal/en/xkb/gram-common.html> for more precise +explanation of syntax of xkb configuration files. + +4.1 Predefined XKB Symbol Sets + +If you are about to define some European symbol map extension, you might want +to use on of four predefined latin alphabet layouts. + +Okay, let's assume you want extend an existing keymap and you want to over- +ride a few keys. Let's take a simple U.K. keyboard as an example (defined in +pc/gb): + + partial default alphanumeric_keys + xkb_symbols "basic" { + include "pc/latin" + + name[Group1]="Great Britain"; + + key <AE02> { [ 2, quotedbl, twosuperior, oneeighth ] }; + key <AE03> { [ 3, sterling, threesuperior, sterling ] }; + key <AC11> { [apostrophe, at, dead_circumflex, dead_caron] }; + key <TLDE> { [ grave, notsign, bar, bar ] }; + key <BKSL> { [numbersign, asciitilde, dead_grave, dead_breve ] }; + key <RALT> { type[Group1]="TWO_LEVEL", + [ ISO_Level3_Shift, Multi_key ] }; + + modifier_map Mod5 { <RALT> }; + }; + +It defines a new layout in basic variant as an extension of common latin +alphabet layout. The layout (symbol set) name is set to "Great Britain". +Then there are redefinitions of a few keycodes and a modifiers binding. As +you can see the number of shift levels is the same for <AE02>, <AE03>, +<AC11>, <TLDE> and <BKSL> keys but it differs from number of shift levels of +<RALT>. + +Note that the <RALT> key itself is a binding key for Mod5 and that it serves +like a shift modifier for LevelThree, together with Shift as a multi-key. It +is a good habit to respect this rule in a new similar layout. + +Okay, you could now define more variants of your new layout besides basic +simply by including (augmenting/overriding/...) the basic definition and +altering what may be needed. + +4.2 Key Types + +The differences in the number of columns (shift levels) are caused by a dif- +ferent types of keys (see the types definition in section basics). Most key- +codes have implicitly set the keytype in the included "pc/latin" file to +"FOUR_LEVEL_ALPHABETIC". The only exception is <RALT> keycode which is +explicitly set "TWO_LEVEL" keytype. + +All those names refer to pre-defined shift level schemes. Usually you can +choose a suitable shift level scheme from default types scheme list in proper +xkb component's subdirectory. + +The most used schemes are: + + ONE_LEVEL + The key does not depend on any modifiers. The symbol from first + level is always chosen. + + TWO_LEVEL + The key uses a modifier Shift and may have two possible values. + The second level may be chosen by Shift modifier. If Lock modi- + fier (usually Caps-lock) applies the symbol is further processed + using system-specific capitalization rules. If both Shift+Lock + modifier apply the symbol from the second level is taken and cap- + italization rules are applied (and usually have no effect). + + ALPHABETIC + The key uses modifiers Shift and Lock. It may have two possible + values. The second level may be chosen by Shift modifier. When + Lock modifier applies, the symbol from the first level is taken + and further processed using system-specific capitalization rules. + If both Shift+Lock modifier apply the symbol from the first level + is taken and no capitalization rules applied. This is often + called shift-cancels-caps behaviour. + + THREE_LEVEL + Is the same as TWO_LEVEL but it considers an extra modifier - + LevelThree which can be used to gain the symbol value from the + third level. If both Shift+LevelThree modifiers apply the value + from the third level is also taken. As in TWO_LEVEL, the Lock + modifier doesn't influence the resulting level. Only Shift and + LevelThree are taken into that consideration. If the Lock modi- + fier is active capitalization rules are applied on the resulting + symbol. + + FOUR_LEVEL + Is the same as THREE_LEVEL but unlike LEVEL_THREE if both + Shift+LevelThree modifiers apply the symbol is taken from the + fourth level. + + FOUR_LEVEL_ALPHABETIC + Is similar to FOUR_LEVEL but also defines shift-cancels-caps + behaviour as in ALPHABETIC. If Lock+LevelThree apply the symbol + from the third level is taken and the capitalization rules are + applied. If Lock+Shift+LevelThree apply the symbol from the + third level is taken and no capitalization rules are applied. + + KEYPAD + As the name suggest this scheme is primarily used for numeric + keypads. The scheme considers two modifiers - Shift and NumLock. + If none of modifiers applies the symbol from the first level is + taken. If either Shift or NumLock modifiers apply the symbol from + the second level is taken. If both Shift+NumLock modifiers apply + the symbol from the first level is taken. Again, shift-cancels- + caps variant. + + FOUR_LEVEL_KEYPAD + Is similar to KEYPAD scheme but considers also LevelThree modi- + fier. If LevelThree modifier applies the symbol from the third + level is taken. If Shift+LevelThree or NumLock+LevelThree apply + the symbol from the fourth level is taken. If all Shift+Num- + Lock+LevelThree modifiers apply the symbol from the third level + is taken. This also, shift-cancels-caps variant. + +Besides that, there are several schemes for special purposes: + + PC_BREAK + It is similar to TWO_LEVEL scheme but it considers the Control + modifier rather than Shift. That means, the symbol from the sec- + ond level is chosen by Control rather than by Shift. + + PC_SYSRQ + It is similar to TWO_LEVEL scheme but it considers the Alt modi- + fier rather than Shift. That means, the symbol from the second + level is chosen by Alt rather than by Shift. + + CTRL+ALT + The key uses modifiers Alt and Control. It may have two possible + values. If only one modifier (Alt or Control) applies the symbol + from the first level is chosen. Only if both Alt+Control modi- + fiers apply the symbol from the second level is chosen. + + SHIFT+ALT + The key uses modifiers Shift and Alt. It may have two possible + values. If only one modifier (Alt or Shift) applies the symbol + from the first level is chosen. Only if both Alt+Shift modifiers + apply the symbol from the second level is chosen. + +If needed, special caps schemes may be used. They redefine the standard +behaviour of all *ALPHABETIC types. The layouts (maps of symbols) with keys +defined in respective types then automatically change their behaviour accord- +ingly. Possible redefinitions are: + + o internal + + o internal_nocancel + + o shift + + o shift_nocancel + +None of these schemes should be used directly. They are defined merely for +'caps:' xkb options (used to globally change the layouts behaviour). + +Don't alter any of existing key types. If you need a different behaviour cre- +ate a new one. + +4.2.1 More On Definitions Of Types + +When the XKB software deals with a separate type description it gets a com- +plete list of modifiers that should be taken into account from the 'modi- +fiers=<list of modifiers>' list and expects that a set of 'map[<combination +of modifiers>]=<list of modifiers>' instructions that contain the mapping for +each combination of modifiers mentioned in that list. Modifiers that are not +explicitly listed are NOT taken into account when the resulting shift level +is computed. If some combination is omitted the program (subroutine) should +choose the first level for this combination (a quite reasonable behavior). + +Lets consider an example with two modifiers ModOne and ModTwo: + + type "..." { + modifiers = ModOne+ModTwo; + map[None] = Level1; + map[ModOne] = Level2; + }; + +In this case the map statements for ModTwo only and ModOne+ModTwo are omit- +ted. It means that if the ModTwo is active the subroutine can't found +explicit mapping for such combination an will use the default level i.e. +Level1. + +But in the case the type described as: + + type "..." { + modifiers = ModOne; + map[None] = Level1; + map[ModOne] = Level2; + }; + +the ModTwo will not be taken into account and the resulting level depends on +the ModOne state only. That means, ModTwo alone produces the Level1 but the +combination ModOne+ModTwo produces the Level2 as well as ModOne alone. + +What does it mean if the second modifier is the Lock? It means that in the +first case (the Lock itself is included in the list of modifiers but combina- +tions with this modifier aren't mentioned in the map statements) the internal +capitalization rules will be applied to the symbol from the first level. But +in the second case the capitalization will be applied to the symbol chosen +accordingly to he first modifier - and this can be the symbol from the first +as well as from the second level. + +Usually, all modifiers introduced in 'modifiers=<list of modifiers>' list are +used for shift level calculation and then discarded. Sometimes this is not +desirable. If you want to use a modifier for shift level calculation but you +don't want to discard it, you may list in 'preserve[<combination of modi- +fiers>]=<list of modifiers>'. That means, for a given combination all listed +modifiers will be preserved. If the Lock modifier is preserved then the +resulting symbol is passed to internal capitalization routine regardless +whether it has been used for a shift level calculation or not. + +Any key type description can use both real and virtual modifiers. Since real +modifiers always have standard names it is not necessary to explicitly +declare them. Virtual modifiers can have arbitrary names and can be declared +(prior using them) directly in key type definition: + + virtual_modifiers <comma-separated list of modifiers> ; + +as seen in for example basic, pc or mousekeys key type definitions. + +4.3 Rules + +Once you are finished with your symbol map you need to add it to rules file. +The rules file describes how all the five basic keycodes, types, compat, sym- +bols and geometry components should be composed to give a sensible resulting +xkb configuration. + +The main advantage of rules over formerly used keymaps is a possibility to +simply parameterize (once) fixed patterns of configurations and thus to ele- +gantly allow substitutions of various local configurations into predefined +templates. + +A pattern in a rules file (often located in /usr/lib/X11/xkb/rules) can be +parameterized with four other arguments: Model, Layout, Variant and Options. +For most cases parameters model and layout should be sufficient for choosing +a functional keyboard mapping. + +The rules file itself is composed of pattern lines and lines with rules. The +pattern line starts with an exclamation mark ('!') and describes how will the +xkb interpret the following lines (rules). A sample rules file looks like +this: + + ! model = keycodes + macintosh_old = macintosh + ... + * = xfree86 + + ! model = symbols + hp = +inet(%m) + microsoftpro = +inet(%m) + geniuscomfy = +inet(%m) + + ! model layout[1] = symbols + macintosh us = macintosh/us%(v[1]) + * * = pc/pc(%m)+pc/%l[1]%(v[1]) + + ! model layout[2] = symbols + macintosh us = +macintosh/us[2]%(v[2]):2 + * * = +pc/%l[2]%(v[2]):2 + + ! option = types + caps:internal = +caps(internal) + caps:internal_nocancel = +caps(internal_nocancel) + +Each rule defines what certain combination of values on the left side of +equal sign ('=') results in. For example a (keyboard) model macintosh_old +instructs xkb to take definitions of keycodes from file keycodes/macintosh +while the rest of models (represented by a wild card '*') instructs it to +take them from file keycodes/xfree86. The wild card represents all possible +values on the left side which were not found in any of the previous rules. +The more specialized (more complete) rules have higher precedence than gen- +eral ones, i.e. the more general rules supply reasonable default values. + +As you can see some lines contain substitution parameters - the parameters +preceded by the percent sign ('%'). The first alphabetical character after +the percent sign expands to the value which has been found on the left side. +For example +%l%(v) expands into +cz(bksl) if the respective values on the +left side were cz layout in its bksl variant. More, if the layout resp. vari- +ant parameter is followed by a pair of brackets ('[', ']') it means that xkb +should place the layout resp. variant into specified xkb group. If the brack- +ets are omitted the first group is the default value. + +So the second block of rules enhances symbol definitions for some particular +keyboard models with extra keys (for internet, multimedia, ...) . Other mod- +els are left intact. Similarly, the last block overrides some key type defi- +nitions, so the common global behaviour ''shift cancels caps'' or ''shift +doesn't cancel caps'' can be selected. The rest of rules produces special +symbols for each variant us layout of macintosh keyboard and standard pc sym- +bols in appropriate variants as a default. + +4.4 Descriptive Files of Rules + +Now you just need to add a detailed description to <rules>.xml description +file so the other users (and external programs which often parse this file) +know what is your work about. + +4.4.1 Old Descriptive Files + +The formerly used descriptive files were named <rules>.lst Its structure is +very simple and quite self descriptive but such simplicity had also some cav- +ities, for example there was no way how to describe local variants of layouts +and there were problems with the localization of descriptions. To preserve +compatibility with some older programs, new XML descriptive files can be con- +verted to old format '.lst'. + +For each parameter of rules file should be described its meaning. For the +rules file described above the .lst file could look like: + + ! model + pc104 Generic 104-key PC + microsoft Microsoft Natural + pc98 PC-98xx Series + macintosh Original Macintosh + ... + + ! layout + us U.S. English + cz Czech + de German + ... + + ! option + caps:internal uses internal capitalization. Shift cancels Caps + caps:internal_nocancel uses internal capitalization. Shift doesn't cancel Caps + +And that should be it. Enjoy creating your own xkb mapping. + + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/XKB-Enhancing.sgml,v 1.2 2003/02/25 19:31:02 dawes Exp $ + + +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.XKB-Enhancing,v 1.2 2003/02/25 21:32:35 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.ati b/xc/programs/Xserver/hw/xfree86/doc/README.ati index 1754d0b6a..a7bf1715c 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/README.ati +++ b/xc/programs/Xserver/hw/xfree86/doc/README.ati @@ -40,7 +40,7 @@ able itself to allow other drivers to examine the system. Note that I am currently considering removing the driver's support for generic VGA. If you have any concerns about this, please contact me at -tsi@xfree86.org. +<tsi@xfree86.org>. 2. A note on acceleration @@ -610,7 +610,7 @@ driver. They include: ``odd-ball'' dimensions, such as 1400x1050, a resolution not commonly possible on CRTs or projection equipment. - Also, the display of independant images on the panel and CRT is not cur- + Also, the display of independent images on the panel and CRT is not cur- rently implemented, and might never be, pending resolution of the previ- ous item. @@ -645,8 +645,8 @@ uncertain. Secondly, please check XFree86's doc directory for additional information. Thirdly, a scan through the comp.windows.x.i386unix and comp.os.linux.x news- -groups and the newbie or xpert mailing lists using your favourite archiving -service can also prove useful in resolving problems. +groups and the xfree86 mailing list using your favourite archiving service +can also prove useful in resolving problems. If you are still experiencing problems, you can send me non-HTMLised e-mail at <tsi@xfree86.org>. Please be as specific as possible when describing the @@ -703,7 +703,7 @@ newer driver API of XFree86 4.0 and later. The introduction of version 6 is a first swipe at porting the driver to non- Intel architectures. - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/ati.sgml,v 3.40 2002/02/14 22:08:00 tsi Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/ati.sgml,v 3.43 2003/02/25 19:31:02 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.ati,v 3.60 2002/02/14 22:21:35 tsi Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.ati,v 3.63 2003/02/25 21:32:35 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.chips b/xc/programs/Xserver/hw/xfree86/doc/README.chips index 21aaa651d..1d747be4c 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/README.chips +++ b/xc/programs/Xserver/hw/xfree86/doc/README.chips @@ -7,7 +7,7 @@ 1. Introduction -With the release of XFree86 version 4.2.0, the Chips and Technologies driver +With the release of XFree86 version 4.3.0, the Chips and Technologies driver has been extensively rewritten and contains many new features. This driver must be considered work in progress, and those users wanting stability are encouraged to use the older XFree86 3.3.x versions. However this version of @@ -956,7 +956,7 @@ cause damage. startx -- -depth 24 -fbbpp 32 8-8-8 RGB truecolor - however as XFree86 version 4.2.0 allows 32bpp pixmaps to be used + however as XFree86 version 4.3.0 allows 32bpp pixmaps to be used with framebuffers operating in 24bpp, this mode of operating will cost performance for no gain in functionality. @@ -1030,4 +1030,4 @@ bugs and extensively testing this server. Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/chips.sgml,v 3.38 2001/10/01 13:44:02 eich Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.chips,v 3.38 2001/11/15 17:37:22 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.chips,v 3.43 2003/02/24 04:03:23 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.dps b/xc/programs/Xserver/hw/xfree86/doc/README.dps index 1be1901c8..a07cd88ce 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/README.dps +++ b/xc/programs/Xserver/hw/xfree86/doc/README.dps @@ -164,7 +164,7 @@ Developers. 15 April 1993. [PSWRAP] Display PostScript System. pswrap Reference Manual. 15 April 1993. - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/dps.sgml,v 1.1 2001/03/02 02:45:37 dawes Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/dps.sgml,v 1.2 2003/01/20 03:43:07 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.dps,v 1.3 2001/06/01 18:28:42 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.dps,v 1.4 2003/01/20 04:10:01 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.fonts b/xc/programs/Xserver/hw/xfree86/doc/README.fonts index ab3e6eb99..fb1c1f5fb 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/README.fonts +++ b/xc/programs/Xserver/hw/xfree86/doc/README.fonts @@ -2,31 +2,188 @@ Juliusz Chroboczek, <jch@xfree86.org> - 26 November 2001 + 17 January 2003 1. Introduction -This document describes the support for fonts in XFree86. Section Installing -fonts (section 2., page 1) is aimed at the casual user wishing to install -fonts in the X server; the rest of the document describes the font support in -more detail. - -We only describe font support within the core X protocol. Issues relating to -fonts within the RENDER extension, the GLX (OpenGL) extension or the PEX -extension are outside the scope of this document. +This document describes the support for fonts in XFree86. Installing fonts +(section 2., page 1) is aimed at the casual user wishing to install fonts in +XFree86; the rest of the document describes the font support in more detail. We assume some familiarity with digital fonts. If anything is not clear to -you, please consult Appendix Background (section 6., page 1) at the end of +you, please consult Appendix: Background (section 5., page 1) at the end of this document for background information. +1.1 Two font systems + +XFree86 includes two font systems: the core X11 fonts system, which is pre- +sent in all implementations of X11, and the Xft fonts system, which is not +currently distributed with implementations of X11 that are not based on +XFree86 but will hopefully be included by them in the future + +The core X11 fonts system is directly derived from the fonts system included +with X11R1 in 1987, which could only use monochrome bitmap fonts. Over the +years, it has been more or less happily coerced into dealing with scalable +fonts and rotated glyphs. + +Xft was designed from the start to provide good support for scalable fonts, +and do so efficiently. Unlike the core fonts system, it supports features +such as anti-aliasing and sub-pixel rasterisation. Perhaps more importantly, +it gives applications full control over the way glyphs are rendered, making +fine typesetting and WYSIWIG display possible. Finally, it allows applica- +tions to use fonts that are not installed system-wide for displaying docu- +ments with embedded fonts. + +Xft is not compatible with the core fonts system: usage of Xft requires mak- +ing fairly extensive changes to toolkits (user-interface libraries). While +XFree86 will continue to maintain the core fonts system, toolkit authors are +encouraged to switch to Xft as soon as possible. + 2. Installing fonts -Installing fonts in XFree86 is a two step process. First, you need to create -a font directory that contains all the relevant font files as well as some -index files. You then need to inform the X server of the existence of this -new directory by including it in the font path. +This section explains how to configure both Xft and the core fonts system to +access newly-installed fonts. + +2.1 Configuring Xft + +Xft has no configuration mechanism itself, rather it relies upon the fontcon- +fig library to configure and customize fonts. That library is not specific +to XFree86 or indeed on any particular font output mechanism. This discus- +sion describes how fontconfig, rather than Xft, works. + +2.1.1 Installing fonts in Xft + +Fontconfig looks for fonts in a set of well-known directories that include +all of XFree86's standard font directories (`/usr/X11R6/lib/X11/lib/fonts/*') +by default) as well as a directory called `.fonts/' in the user's home direc- +tory. Installing a font for use by Xft applications is as simple as copying +a font file into one of these directories. + + $ cp lucbr.ttf ~/.fonts/ + +Fontconfig will notice the new font at the next opportunity and rebuild its +list of fonts. If you want to trigger this update from the command line (for +example in order to globally update the system-wide Fontconfig information), +you may run the command `fc-cache'. + + $ fc-cache + +2.1.2 Fine-tuning Xft + +Fontconfig's behaviour is controlled by a set of configuration files: a sys- +tem-wide configuration file, `/etc/fonts/fonts.conf', and a user-specific +file called `.fonts.conf' in the user's home directory (this can be overrid- +den with the `FONTCONFIG_FILE' environment variable). + +Every Fontconfig configuration file must start with the following boiler- +plate: + + <?xml version="1.0"?> + <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> + <fontconfig> + +In addition, every Fontconfig configuration file must end with the following +line: + + </fontconfig> + +The default Fontconfig configuration file includes the directory `~/.fonts/' +in the list of directories searched for font files, and this is where user- +specific font files should be installed. In the unlikely case that a new +font directory needs to be added, this can be done with the following syntax: + + <dir>/usr/local/share/fonts/</dir> + +Another useful option is the ability to disable anti-aliasing (font smooth- +ing) for selected fonts. This can be done with the following syntax: + + <match target="font"> + <test qual="any" name="family"> + <string>Lucida Console</string> + </test> + <edit name="antialias" mode="assign"> + <bool>false</bool> + </edit> + </match> + +Anti-aliasing can be disabled for all fonts by the following incantation: + + <match target="font"> + <edit name="antialias" mode="assign"> + <bool>false</bool> + </edit> + </match> + +Xft supports sub-pixel rasterisation on LCD displays. XFree86 should auto- +matically enable this feature on laptops and when using an LCD monitor con- +nected with a DVI cable; you can check whether this was done by typing + + $ xdpyinfo -ext RENDER | grep sub-pixel + +If this doesn't print anything, you will need to configure Render for your +particular LCD hardware manually; this is done with the following syntax: + + <match target="font"> + <edit name="rgba" mode="assign"> + <const>rgb</const> + </edit> + </match> + +The string `rgb' within the `<const>'...`</const>' specifies the order of +pixel components on your display, and should be changed to match your hard- +ware; it can be one of `rgb (normal LCD screen), `bgr' (backwards LCD +screen), `vrgb' (LCD screen rotated clockwise) or `vbgr' (LCD screen rotated +counterclockwise). + +2.1.3 Configuring applications + +Because most current applications use the core fonts system by default, it is +necessary to explicitly configure them to use Xft. How this is done depends +on the application. + +XTerm can be set to use Xft by using the `-fa' command line option or by set- +ting the `XTerm*faceName' resource: + + XTerm*faceName: Courier + +or + + $ xterm -fa "Courier" + +For applications based on GTK+ 2.0 (including GNOME 2 applications), the +environment variable `GDK_USE_XFT' should be set to `1': -2.1 Installing bitmap fonts + $ export GDK_USE_XFT=1 + +GTK+ 2.2 uses Xft by default. + +For KDE applications, you should select ``Anti-alias fonts'' in the ``Fonts'' +panel of KDE's ``Control Center''. Note that this option is misnamed: it +switches KDE to using Xft but doesn't enable anti-aliasing in case it was +disabled by your Xft configuration file. + +(What about Mozilla?) + +2.1.4 Troubleshooting + +If some Xft-based applications don't seem to notice the changes you are mak- +ing to your configuration files, they may be linked against the XFree86 4.2 +version of Xft. In order to fix the problem, you should relink them against +a current version of Xft; on most systems, it is enough to install the cur- +rent version of the Xft and Fontconfig libraries. + +If, for some reason, you cannot upgrade the shared libraries, please check +the Xft(3) manual page included with XFree86 4.2 for the configuration mecha- +nisms of the previous version of Xft. + +2.2 Configuring the core X11 fonts system + +Installing fonts in the core system is a two step process. First, you need +to create a font directory that contains all the relevant font files as well +as some index files. You then need to inform the X server of the existence +of this new directory by including it in the font path. + +2.2.1 Installing bitmap fonts The XFree86 server can use bitmap fonts in both the cross-platform BDF format and the somewhat more efficient binary PCF format. (XFree86 also supports @@ -39,7 +196,7 @@ e.g. $ bdftopcf courier12.bdf -You may then want to compress the resulting PCF font files: +You will then want to compress the resulting PCF font files: $ gzip courier12.pcf @@ -49,20 +206,19 @@ you wish to make available into a arbitrary directory, say `fonts.dir' by running the command `mkfontdir' (please see the mkfontdir(1) manual page for more information): - $ mkdir /usr/local/share/fonts/bitmap - $ cp *.pcf.gz /usr/local/share/fonts/bitmap - $ cd /usr/local/share/fonts/bitmap - $ mkfontdir + $ mkdir /usr/local/share/fonts/bitmap/ + $ cp *.pcf.gz /usr/local/share/fonts/bitmap/ + $ mkfontdir /usr/local/share/fonts/bitmap/ All that remains is to tell the X server about the existence of the new font -directory; see Section Setting the server font path (section 2.4, page 1). +directory; see Setting the server font path (section 2.2.4, page 1) below. -2.2 Installing scalable fonts +2.2.2 Installing scalable fonts The XFree86 server supports scalable fonts in four formats: Type 1, Speedo, TrueType and CIDFont. This section only applies to the former three; for -information on CIDFonts, please see Section Installing CIDFonts (section 2.3, -page 1) later in this document. +information on CIDFonts, please see Installing CIDFonts (section 2.2.3, page +1) later in this document. Installing scalable fonts is very similar to installing bitmap fonts: you create a directory with the font files, and run `mkfontdir' to create an @@ -70,58 +226,23 @@ index file called `fonts.dir'. There is, however, a big difference: `mkfontdir' cannot automatically recog- nise scalable font files. For that reason, you must first index all the font -files in a file called `fonts.scale'. This file has the same format as a -`fonts.dir' file, and typically looks as follows: - - 4 - cour.pfa -adobe-courier-medium-r-normal-0-0-0-0-p-0-iso8859-1 - cour.pfa -adobe-courier-medium-r-normal-0-0-0-0-p-0-iso8859-2 - couri.pfa -adobe-courier-medium-i-normal-0-0-0-0-p-0-iso8859-1 - couri.pfa -adobe-courier-medium-i-normal-0-0-0-0-p-0-iso8859-2 - -The first line indicates the number of entries in the file. Each line after -the first consists of two fields separated by a space; the first field is the -name of the font file, and the second one is the name under which the font -will appear to the server. This name should obey the X Logical Font Descrip- -tion conventions (see Section The X Logical Font Description (section 6.2, -page 1)). The format of this file is fully described in the mkfontdir(1) -manual page. - -Note that multiple lines may point at the same font file. This is most com- -monly done in order to make a single font available under multiple encodings; -please see Section Fonts and internationalisation (section 4., page 1). - -While it is possible to create the `fonts.scale' file by hand, it is simpler -and more convenient to have it generated automatically. Utilities to perform -this task are available, but are not currently included with XFree86. For -Type 1 fonts, you may use a utility called `type1inst' which is available -from standard Free Software repositories <URL:http://www.ibib- -lio.org/pub/Linux/X11/xutils/> throughout the world. - -For TrueType fonts, you may use `ttmkfdir', available from Joerg Pommnitz's -xfsft page <URL:http://www.joerg-pommnitz.de/TrueType/xfsft.html>. - -After the `fonts.scale' is created, you may run `mkfontdir' as above; this -time, however, you need to create an index of encoding files called `encod- -ings.dir' in addition to the `fonts.dir' file. This is done by using -`mkfontdir' with the `-e' flag: - - $ cd /usr/local/share/fonts/Type1 - $ mkfontdir -e /usr/X11R6/lib/font/encodings - -For more information, please see the mkfontdir(1) manual page and Section -Fonts and internationalisation (section 4., page 1) later in this document. - -2.3 Installing CID-keyed fonts +files in a file called `fonts.scale'. While this can be done by hand, it is +best done by using the `mkfontscale' utility. + + $ mkfontscale /usr/local/share/fonts/Type1/ + $ mkfontdir /usr/local/share/fonts/Type1/ + +Under some circumstances, it may be necessary to modify the `fonts.scale' +file generated by mkfontscale; for more information, please see the mkfont- +dir(1) and mkfontscale(1) manual pages and Core fonts and internationalisa- +tion (section 4.1, page 1) later in this document. + +2.2.3 Installing CID-keyed fonts The CID-keyed font format was designed by Adobe Systems for fonts with large character sets. A CID-keyed font, or CIDFont for short, contains a collec- tion of glyphs indexed by character ID (CID). -Adobe make some sample CIDFonts and a complete set of CMaps available from -O'Reilly's FTP site <URL:ftp://ftp.oreilly.com/pub/examples/nut- -shell/cjkv/adobe/>. - In order to map such glyphs to meaningful indices, Adobe provide a set of CMap files. The PostScript name of a font generated from a CIDFont consists of the name of the CIDFont and the name of the CMap separated by two dashes. @@ -130,8 +251,8 @@ CMap `UniKS-UCS2-H' is called Munhwa-Regular--UniKS-UCS2-H -The CIDFont support in XFree86 requires a very rigid directory structure. -The main directory must be called `CID' (its location defaults to +The CIDFont code in XFree86 requires a very rigid directory structure. The +main directory must be called `CID' (its location defaults to `/usr/X11R6/lib/X11/fonts/CID' but it may be located anywhere), and it should contain a subdirectory for every CID collection. Every subdirectory must contain subdirectories called CIDFont (containing the actual CIDFont files), @@ -157,8 +278,8 @@ filenames: Adobe-Korea1/Munhwa-Regular--UniKS-UCS2-H.cid \ -adobe-munhwa-medium-r-normal--0-0-0-0-p-0-iso10646-1 -(both names on the same line). As above, running `mkfontdir' creates the -`fonts.dir' file: +(both names on the same line). Running `mkfontdir' creates the `fonts.dir' +file: $ cd /usr/local/share/fonts/CID $ mkfontdir @@ -173,11 +294,11 @@ fonts but querying them will take a long time. You should run `mkcfm' again whenever a change is made to any of the CID-keyed fonts, or when the CID- keyed fonts are copied to a machine with a different architecture. -2.4 Setting the server's font path +2.2.4 Setting the server's font path The list of directories where the server looks for fonts is known as the font path. Informing the server of the existence of a new font directory consists -in putting it on the font path. +of putting it on the font path. The font path is an ordered list; if a client's request matches multiple fonts, the first one in the font path is the one that gets used. When match- @@ -195,7 +316,7 @@ You may check the font path of the running server by typing the command $ xset q -2.4.1 Temporary modification of the font path +2.2.4.1 Temporary modification of the font path The `xset' utility may be used to modify the font path for the current ses- sion. The font path is set with the command xset fp; a new element is added @@ -205,34 +326,36 @@ to the front with xset +fp, and added to the end with xset fp+. For example, $ xset fp+ /usr/local/fonts/bitmap Conversely, an element may be removed from the front of the font path with -`xset -fp', and removed from the end with `xset fp-'. +`xset -fp', and removed from the end with `xset fp-'. You may reset the font +path to its default value with `xset fp default'. For more information, please consult the xset(1) manual page. -2.4.2 Permanent modification of the font path +2.2.4.2 Permanent modification of the font path -The default font path (the one used just after server startup) is specified -in the X server's `XF86Config' file. It is computed by appending all the -directories mentioned in the `FontPath' entries of the `Files' section in the -order in which they appear. +The default font path (the one used just after server startup or after `xset +fp default') is specified in the X server's `XF86Config' file. It is com- +puted by appending all the directories mentioned in the `FontPath' entries of +the `Files' section in the order in which they appear. FontPath "/usr/local/fonts/Type1" ... FontPath "/usr/local/fonts/bitmap" -For more information, please consult the `XF86Config'(5) manual page. +For more information, please consult the XF86Config(5) manual page. -2.5 Troubleshooting +2.2.5 Troubleshooting If you seem to be unable to use some of the fonts you have installed, the first thing to check is that the `fonts.dir' files are correct and that they -are readable by the server. If this doesn't help, it is quite possible that +are readable by the server (the X server usually runs as root, beware of NFS- +mounted font directories). If this doesn't help, it is quite possible that you are trying to use a font in a format that is not supported by your server. -XFree86 supports the BDF, PCF, SNF, Type 1, Speedo, TrueType and CIDFont font -formats. However, not all XFree86 servers come with all the font backends -configured in. +XFree86 supports the BDF, PCF, SNF, Type 1, Speedo, TrueType, OpenType and +CIDFont font formats. However, not all XFree86 servers come with all the +font backends configured in. On most platforms, the XFree86 servers are modular: the font backends are included in modules that are loaded at runtime. The modules to be loaded are @@ -247,13 +370,15 @@ follows: o "bitmap": bitmap fonts (`*.bdf', `*.pcf' and `*.snf'); - o "type1": Type 1 fonts (`*.pfa' and `*.pfb') and CIDFonts; + o "freetype": TrueType fonts (`*.ttf' and `*.ttc'), OpenType fonts + (`*.otf' and `*.otc') and Type 1 fonts (`*.pfa' and `*.pfb'); - o "speedo": Bitstream Speedo fonts (`*.spd'); + o "type1": alternate Type 1 backend (`*.pfa' and `*.pfb') and CIDFont + backend; - o "freetype": TrueType fonts (`*.ttf' and `*.ttc'); + o "xtt": alternate TrueType backend (`*.ttf' and `*.ttc'); - o "xtt": alternate TrueType backend (`*.ttf' and `*.ttc'). + o "speedo": Bitstream Speedo fonts (`*.spd'). Please note that the argument of the `Load' directive is case-sensitive. @@ -261,15 +386,15 @@ Please note that the argument of the `Load' directive is case-sensitive. 3.1 Standard bitmap fonts -The Sample Implementation of X11 comes with a large number of bitmap fonts, -including the `fixed' family, and bitmap versions of Courier, Times and Hel- -vetica. In the SI, these fonts are provided in the ISO 8859-1 encoding (ISO -Latin Western-European). +The Sample Implementation of X11 (SI) comes with a large number of bitmap +fonts, including the `fixed' family, and bitmap versions of Courier, Times, +Helvetica and some members of the Lucida family. In the SI, these fonts are +provided in the ISO 8859-1 encoding (ISO Latin Western-European). In XFree86, a number of these fonts are provided in Unicode-encoded font files instead. At build time, these fonts are split into font files encoded -according to legacy encodings, a process which enables us to provide the -standard fonts in a number of regional encodings with no duplication of work. +according to legacy encodings, a process which allows us to provide the stan- +dard fonts in a number of regional encodings with no duplication of work. For example, the font file @@ -281,7 +406,7 @@ with XLFD is a Unicode-encoded version of the standard `fixed' font with added support for the Latin, Greek, Cyrillic, Georgian, Armenian, IPA and other scripts -plus numerous technical symbols. It contains over 2800 glyphs, covering all +plus numerous technical symbols. It contains over 2800 glyphs, covering all characters of ISO 8859 parts 1-5, 7-10, 13-15, as well as all European IBM and Microsoft code pages, KOI8, WGL4, and the repertoires of many other char- acter sets. @@ -290,29 +415,14 @@ This font is used at build time for generating the font files 6x13-ISO8859-1.bdf 6x13-ISO8859-2.bdf - 6x13-ISO8859-3.bdf - 6x13-ISO8859-4.bdf - 6x13-ISO8859-5.bdf - 6x13-ISO8859-7.bdf - 6x13-ISO8859-8.bdf - 6x13-ISO8859-9.bdf - 6x13-ISO8859-10.bdf - 6x13-ISO8859-13.bdf + ... 6x13-ISO8859-15.bdf 6x13-KOI8-R.bdf with respective XLFDs -misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-1 - -misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-2 - -misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-3 - -misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-4 - -misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-5 - -misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-7 - -misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-8 - -misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-9 - -misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-10 - -misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-13 + ... -misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-15 -misc-fixed-medium-r-normal--13-120-75-75-c-60-koi8-r @@ -320,10 +430,6 @@ The standard short name `fixed' is normally an alias for -misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-1 -(The conversion of the standard fonts to Unicode was mainly performed by -Markus Kuhn. Markus is a man of taste, which makes his use of Perl in the -conversion process somewhat surprising.) - 3.2 The ClearlyU Unicode font family The ClearlyU family of fonts provides a set of 12 pt, 100 dpi proportional @@ -361,10 +467,6 @@ standard. The Ligature font contains ligatures for various scripts that may be useful for improved presentation of text. -(The ClearlyU family was designed by Mark Leisher. Mark's usage of the -foundry name mutt predates the mailer of the same name, but he won't say -more.) - 3.3 Standard scalable fonts XFree86 includes all the scalable fonts distributed with X11R6. @@ -403,7 +505,7 @@ and reside in the font files XFree86 includes Speedo versions of the Bitstream Courier and Charter fonts. In order to use these fonts, you should ensure that your X server is loading -the `Speedo' font backend; see Section Troubleshooting (section 2.5, page 1). +the `Speedo' font backend; see Troubleshooting (section 2.2.5, page 1). These fonts cover all of ISO 8859-1 and almost all of ISO 8859-2. They have XLFD name @@ -435,12 +537,12 @@ TrueType version have glyphs covering the basic ASCII Unicode range, the Latin 1 range, as well as the Extended Latin range and some additional punc- tuation characters. In particular, these fonts include all the glyphs needed for ISO 8859 parts 1, 2, 3, 4, 9, 13 and 15, as well as all the glyphs in the -Adobe Standard encoding and the Windows 3.1 character set. +Adobe Standard encoding and the Windows 3.1 character set. The glyph coverage of the Type 1 versions is somewhat reduced, and only cov- ers ISO 8859 parts 1, 2 and 15 as well as the Adobe Standard encoding. -The Luxi fonts are original designs by Kris Holmes and Charles Bigelow. Luxi +The Luxi fonts are original designs by Kris Holmes and Charles Bigelow. Luxi fonts include seriffed, sans serif, and monospaced styles, in roman and oblique, and normal and bold weights. The fonts share stem weight, x-height, capital height, ascent and descent, for graphical harmony. @@ -463,14 +565,18 @@ For more information, please contact <design@bigelowandholmes.com> or An earlier version of the Luxi fonts was made available under the name Lucidux. This name should no longer be used due to trademark uncertainties, -and all traces of the Lucidux name have been removed from this version of -XFree86. +and all traces of the Lucidux name have been removed from XFree86. + +4. More about core fonts -4. Fonts and internationalisation +This section describes XFree86-specific enhancements to the core X11 fonts +system. -The scalable font backends (Type 1, Speedo and TrueType) can now automati- -cally re-encode fonts to the encoding specified in the XLFD in fonts.dir. -For example, a fonts.dir file can contain entries for the Type 1 Courier font +4.1 Core fonts and internationalisation + +The scalable font backends (Type 1, Speedo and TrueType) can automatically +re-encode fonts to the encoding specified in the XLFD in `fonts.dir'. For +example, a `fonts.dir' file can contain entries for the Type 1 Courier font such as cour.pfa -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1 @@ -479,7 +585,7 @@ such as which will lead to the font being recoded to ISO 8859-1 and ISO 8859-2 respectively. -4.1 The fontenc layer +4.1.1 The fontenc layer Three of the scalable backends (Type 1, Speedo, and the FreeType TrueType backend) use a common fontenc layer for font re-encoding. This allows these @@ -488,10 +594,9 @@ locales independently of font type. Please note: the X-TrueType (X-TT) backend does not use the fontenc layer, but instead uses its own method for font reencoding. If you are only inter- -ested in X-TT you may want to skip to Section Using Symbol Fonts (section -4.5, page 1), as the intervening information does not apply to X-TT. X-TT -itself is described in more detail in Section X-TrueType (section 5.2, page -1). +ested in X-TT you may want to skip to Using Symbol Fonts (section 4.1.5, page +1), as the intervening information does not apply to X-TT. X-TT itself is +described in more detail in X-TrueType (section 4.2.3, page 1). In the fontenc layer, an encoding is defined by a name (such as iso8859-1), possibly a number of aliases (alternate names), and an ordered collection of @@ -531,7 +636,7 @@ include: o koi8-u: KOI8 Ukrainian (see RFC 2319); - o koi8-ru: KOI8 Russian/Ukrainian + o koi8-ru: KOI8 Russian/Ukrainian; o koi8-uni: KOI8 ``Unified'' (Russian, Ukrainian, and Byelorussian); @@ -547,60 +652,61 @@ directory with fonts.dir!) for a file named `encodings.dir'. If found, this file is scanned for the requested encoding, and the relevant encoding defini- tion file is read in. The `mkfontdir' utility, when invoked with the `-e' option followed by the name of a directory containing encoding files, can be -used to automatically build `encodings.dir' files. See the mkfontdir(1) man- -ual page for more details. +used to automatically build `encodings.dir' files. Please see the mkfont- +dir(1) manual page for more details. A number of encoding files for common encodings are included with XFree86. -Information on writing new encoding files can be found in Section Format of -encodings directory files (section 4.3, page 1) and Format of encoding files -(section 4.4, page 1) later in this document. +Information on writing new encoding files can be found in Format of encodings +directory files (section 4.1.3, page 1) and Format of encoding files (section +4.1.4, page 1) later in this document. + +4.1.2 Backend-specific notes about fontenc + +4.1.2.1 The FreeType backend -4.2 Backend-specific notes about fontenc +For TrueType and OpenType fonts, the FreeType backend scans the mappings in +order. Mappings with a target of PostScript are ignored; mappings with a +TrueType or Unicode target are checked against all the cmaps in the file. +The first applicable mapping is used. -4.2.1 Type 1 +For Type 1 fonts, the FreeType backend first searches for a mapping with a +target of PostScript. If one is found, it is used. Otherwise, the backend +searches for a mapping with target Unicode, which is then composed with a +built-in table mapping codes to glyph names. Note that this table only cov- +ers part of the Unicode code points that have been assigned names by Adobe. -The Type 1 backend first searches for a mapping with a target of PostScript. -If one is found, it is used. Otherwise, the backend searches for a mapping -with target Unicode, which is then composed with a built-in table mapping -codes to glyph names. Note that this table only covers part of the Unicode -code points that have been assigned names by Adobe. +Specifying an encoding value of adobe-fontspecific for a Type 1 font disables +the encoding mechanism. This is useful with symbol and incorrectly encoded +fonts (see Incorrectly encoded fonts (section 4.1.6, page 1) below). -If neither a PostScript or Unicode mapping is found, the backend defaults to +If a suitable mapping is not found, the FreeType backend defaults to ISO 8859-1. -Specifying an encoding value of adobe-fontspecific disables the encoding -mechanism. This is useful with symbol and incorrectly encoded fonts (see -Section Incorrectly encoded fonts (section 4.6, page 1) below). +4.1.2.2 Type 1 -The Type 1 backend currently limits all encodings to 8-bit codes. +The Type 1 backend behaves similarly to the FreeType backend with Type 1 +fonts, except that it limits all encodings to 8-bit codes. -4.2.2 Speedo +4.1.2.3 Speedo The Speedo backend searches for a mapping with a target of Unicode, and uses it if found. If none is found, the backend defaults to ISO 8859-1. The Speedo backend limits all encodings to 8-bit codes. -4.2.3 The FreeType TrueType backend - -The TrueType backend scans the mappings in order. Mappings with a target of -PostScript are ignored; mappings with a TrueType or Unicode target are -checked against all the cmaps in the file. The first applicable mapping is -used. - -If you are writing an encoding file to be used with the TrueType backend, you -should ensure that mappings are mentioned in decreasing order of preference. - -4.3 Format of encoding directory files +4.1.3 Format of encoding directory files In order to use a font in an encoding that the font backend does not know -about, you need to have an `encodings.dir' file in the same directory as the -font file used. The `encodings.dir' file has a similar format to -`fonts.dir'. Its first line specifies the number of encodings, while every -successive line has two columns, the name of the encoding, and the name of -the encoding file; this can be relative to the current directory, or abso- -lute. Every encoding name should agree with the encoding name defined in the -encoding file. For example, +about, you need to have an `encodings.dir' file either in the same directory +as the font file used or in a system-wide location +(`/usr/X11R6/lib/X11/fonts/encodings/' by default). + +The `encodings.dir' file has a similar format to `fonts.dir'. Its first line +specifies the number of encodings, while every successive line has two +columns, the name of the encoding, and the name of the encoding file; this +can be relative to the current directory, or absolute. Every encoding name +should agree with the encoding name defined in the encoding file. For exam- +ple, 3 mulearabic-0 /usr/X11R6/lib/X11/fonts/encodings/mulearabic-0.enc @@ -616,7 +722,7 @@ pressed or gzipped. The `encoding.dir' files are best maintained by the `mkfontdir' utility. Please see the mkfontdir(1) manual page for more information. -4.4 Format of encoding files +4.1.4 Format of encoding files The encoding files are ``free form,'' i.e. any string of whitespace is equiv- alent to a single space. Keywords are parsed in a non-case-sensitive manner, @@ -635,7 +741,6 @@ possibly its alternate names (aliases): STARTENCODING mulearabic-0 ALIAS arabic-0 - ALIAS something-else The name of the encoding and its aliases should be suitable for use in an XLFD font name, and therefore contain exactly one dash `-'. @@ -755,7 +860,7 @@ In order to make future extensions to the format possible, lines starting with an unknown keyword are silently ignored, as are mapping sections with an unknown target. -4.5 Using symbol fonts +4.1.5 Using symbol fonts Type 1 symbol fonts should be installed using the adobe-fontspecific encod- ing. @@ -768,21 +873,21 @@ microsoft-cp1252, or, for older fonts, microsoft-win3.1. In order to guarantee consistent results (especially between Type 1 and True- Type versions of the same font), it is possible to define a special encoding for a given font. This has already been done for the ZapfDingbats font; see -the file encodings/adobe-dingbats.enc. +the file `encodings/adobe-dingbats.enc'. -4.6 Hints about using badly encoded fonts +4.1.6 Hints about using badly encoded fonts A number of text fonts are incorrectly encoded. Incorrect encoding is some- times done by design, in order to make a font for an exotic script appear -like an ordinary Western text font. It is often the result of the font -designer's laziness or incompetence; for some reason, most people seem to -find it easier to invent idiosyncratic glyph names rather than follow the -Adobe glyph list. +like an ordinary Western text font on systems which are not easily extended +with new locale data. It is often the result of the font designer's laziness +or incompetence; for some reason, most people seem to find it easier to +invent idiosyncratic glyph names rather than follow the Adobe glyph list. There are two ways of dealing with such fonts: using them with the encoding they were designed for, and creating an ad hoc encoding file. -4.6.1 Using fonts with the designer's encoding +4.1.6.1 Using fonts with the designer's encoding In the case of Type 1 fonts, the font designer can specify a default encod- ing; this encoding is requested by using the `adobe-fontspecific' encoding in @@ -796,48 +901,42 @@ are designed with either Microsoft or Apple platforms in mind, so one of `microsoft-symbol', `microsoft-cp1252', `microsoft-win3.1', or `apple-roman' should yield reasonable results. -4.6.2 Specifying an ad hoc encoding file +4.1.6.2 Specifying an ad hoc encoding file It is always possible to define an encoding file to put the glyphs in a font in any desired order. Again, see the `encodings/adobe-dingbats.enc' file to see how this is done. -4.6.3 Specifying font aliases +4.1.6.3 Specifying font aliases By following the directions above, you will find yourself with a number of fonts with unusual names --- with encodings such as `adobe-fontspecific', `microsoft-win3.1' etc. In order to use these fonts with standard applica- tions, it may be useful to remap them to their proper names. -This is done by writing a `fonts.alias' file. The format of this file is sim- -ilar to the format of the `fonts.dir' file, except that it maps XLFD names to -XLFD names. A `fonts.alias' file might look as follows: +This is done by writing a `fonts.alias' file. The format of this file is very +simple: it consists of a series of lines each mapping an alias name to a font +name. A `fonts.alias' file might look as follows: - 1 "-ogonki-alamakota-medium-r-normal--0-0-0-0-p-0-iso8859-2" \ "-ogonki-alamakota-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific" (both XLFD names on a single line). The syntax of the `fonts.alias' file is -precisely described in the mkfontdir(1) manual page. - -5. Additional notes about TrueType support +more precisely described in the mkfontdir(1) manual page. -This version of XFree86 comes with two TrueType backends, FreeType (module -`freetype', formerly known as xfsft) and X-TrueType (module `xtt'). These -two backends are not compatible: only one of them can be used at any one -time. +4.2 Additional notes about scalable core fonts -In order to use the FreeType backend, please check that the `Module' section -of your `XF86Config' file contains a line that reads +The FreeType backend (module `freetype', formerly known as xfsft) is able to +deal with both TrueType and Type 1 fonts. This puts it in conflict with the +X-TT and Type 1 backends respectively. - Load "freetype" +If both the FreeType and the Type 1 backends are loaded, the FreeType backend +will be used for Type 1 fonts. If both the FreeType and X-TT backends are +loaded, X-TT will be used for TrueType fonts. -In order to use the X-TrueType backend, replace the line in your XF86Config -file that loads the freetype module with a line that reads +4.2.1 Delayed glyph rasterisation - Load "xtt" - -Both TrueType backends delay glyph rasterisation up to the time at which a +Both FreeType and X-TT delay glyph rasterisation up to the time at which a glyph is first used. For this reason, they only provide an approximate value for the ``average width'' font property. @@ -852,13 +951,15 @@ font really to be a character-cell font. You are encouraged to make use of this optimisation when useful, but be warned that not all monospaced fonts are character-cell fonts. -5.1 The FreeType TrueType backend +4.2.2 About the FreeType backend -The FreeType backend (formerly xfsft) is a backend based on the FreeType -library (see the FreeType web site <URL:http://www.freetype.org/>) and has -support for the ``fontenc'' style of internationalisation (see Section The -fontenc layer (section 4.1, page 1)). This backend supports TrueType Font -files (`*.ttf') and TrueType Collections (`*.ttc'). +The FreeType backend (formerly xfsft) is a backend based on version 2 of the +FreeType library (see the FreeType web site <URL:http://www.freetype.org/>) +and has support for the ``fontenc'' style of internationalisation (see The +fontenc layer (section 4.1.1, page 1)). This backend supports TrueType font +files (`*.ttf'), OpenType font files (`*.otf'), TrueType Collections +(`*.ttc'), OpenType Collections (`*.otc') and Type 1 font files (`*.pfa' and +`*.pfb'). In order to access the faces in a TrueType Collection file, the face number must be specified in the fonts.dir file before the filename within colons. @@ -869,20 +970,18 @@ For example, refers to face 2 in the `mincho.ttc' TrueType Collection file. The FreeType backend uses the fontenc layer in order to support recoding of -fonts; this was described in Section The fontenc layer (section 4.1, page 1) -and especially Section FreeType-specific notes about fontenc (section 4.2.3, -page 1) earlier in this document. +fonts; this was described in The fontenc layer (section 4.1.1, page 1) and +especially FreeType-specific notes about fontenc (section 4.1.2.1, page 1) +earlier in this document. -5.2 The X-TrueType TrueType backend +4.2.3 About the X-TrueType TrueType backend -The `X-TrueType' backend is another backend based on the FreeType library. -X-TrueType doesn't use the `fontenc' layer for managing font encodings, but -instead uses its own database of encodings. However, X-TrueType includes a -large number of encodings, and any encoding you need is likely to be present -in X-TrueType. +The `X-TrueType' backend is a backend based on version 1 of the FreeType +library. X-TrueType doesn't use the `fontenc' layer for managing font encod- +ings, but instead uses its own database of encodings. -X-TrueType extends the `fonts.dir' syntax with a number of options, known as -`TTCap'. A `TTCap' entry follows the general syntax +X-TrueType extends the `fonts.dir' syntax with a number of options, collec- +tively known as `TTCap'. A `TTCap' entry follows the general syntax :option=value: @@ -897,47 +996,48 @@ cho.ttc' is specified using: More information on the TTCap syntax, and on X-TrueType in general, may be found on the X-TrueType home page <URL:http://x-tt.dsl.gr.jp/>. -6. Appendix: background and terminology +5. Appendix: background and terminology -6.1 Characters and glyphs +5.1 Characters and glyphs A computer text-processing system inputs keystrokes and outputs glyphs, small pictures that are assembled on paper or on a computer screen. Keystrokes and glyphs do not, in general, coincide: for example, if the system does generate -ligatures, then to the two keystrokes <f><i> will typically correspond a sin- -gle glyph. Similarly, if the system shapes Arabic glyphs in a reasonable -manner, then multiple different glyphs may correspond to a single keystroke. +ligatures, then to the sequence of two keystrokes <f><i> will typically cor- +respond a single glyph. Similarly, if the system shapes Arabic glyphs in a +vaguely reasonable manner, then multiple different glyphs may correspond to a +single keystroke. The complex transformation rules from keystrokes to glyphs are usually fac- -tored into two simpler transformations, going through the intermediary of -characters. You may want to think of characters as the basic unit of data -that is stored e.g. in the buffer of your text editor. While the definition -of a character is intrinsically application-specific, a number of standard- -ised collections of characters have been defined. +tored into two simpler transformations, from keystrokes to characters and +from characters to glyphs. You may want to think of characters as the basic +unit of text that is stored e.g. in the buffer of your text editor. While +the definition of a character is intrinsically application-specific, a number +of standardised collections of characters have been defined. A coded character set is a set of characters together with a mapping from integer codes --- known as codepoints --- to characters. Examples of coded character sets include US-ASCII, ISO 8859-1, KOI8-R, and JIS X 0208(1990). -A coded character set need not use 8 bit integers to index characters. Many -early mainframes used 6 bit character sets, while 16 bit (or more) character +A coded character set need not use 8 bit integers to index characters. Many +early systems used 6 bit character sets, while 16 bit (or more) character sets are necessary for ideographic writing systems. -6.2 Font files, fonts, and XLFD +5.2 Font files, fonts, and XLFD Traditionally, typographers speak about typefaces and founts. A typeface is a particular style or design, such as Times Italic, while a fount is a molten-lead incarnation of a given typeface at a given size. -Digital fonts come in font files. A font file contains all the information -necessary for generating glyphs of a given typeface, and applications using -font files may access glyph information in an arbitrary order. +Digital fonts come in font files. A font file contains the information nec- +essary for generating glyphs of a given typeface, and applications using font +files may access glyph information in an arbitrary order. Digital fonts may consist of bitmap data, in which case they are said to be bitmap fonts. They may also consist of a mathematical description of glyph shapes, in which case they are said to be scalable fonts. Common formats for scalable font files are Type 1 (sometimes incorrectly called ATM fonts or -PostScript fonts), Speedo and TrueType. +PostScript fonts), TrueType and Speedo. The glyph data in a digital font needs to be indexed somehow. How this is done depends on the font file format. In the case of Type 1 fonts, glyphs @@ -945,33 +1045,38 @@ are identified by glyph names. In the case of TrueType fonts, glyphs are indexed by integers corresponding to one of a number of indexing schemes (usually Unicode --- see below). -The X11 system uses the data in font file to generate font instances, which -are collections of glyphs at a given size indexed according to a given encod- -ing. +The X11 core fonts system uses the data in a font file to generate font +instances, which are collections of glyphs at a given size indexed according +to a given encoding. -X11 font instances are usually specified using a notation known as the X Log- -ical Font Description (XLFD). An XLFD starts with a dash `-', and consists -of fourteen fields separated by dashes, for example +X11 core font instances are usually specified using a notation known as the X +Logical Font Description (XLFD). An XLFD starts with a dash `-', and con- +sists of fourteen fields separated by dashes, for example: - -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1 + -adobe-courier-medium-r-normal--12-120-75-75-m-70-iso8859-1 Or particular interest are the last two fields `iso8859-1', which specify the font instance's encoding. +A scalable font is specified by an XLFD which contains zeroes instead of some +fields: + + -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1 + X11 font instances may also be specified by short name. Unlike an XLFD, a short name has no structure and is simply a conventional name for a font -instance. Two short names are of particular interest, as they are handled -specially by the server, and the server will not start if font instances with -these names cannot be opened. These are `fixed', which specifies the fall- -back font to use when the requested font cannot be opened, and `cursor', -which specifies the set of glyphs to be used by the mouse pointer. +instance. Two short names are of particular interest, as the server will not +start if font instances with these names cannot be opened. These are +`fixed', which specifies the fallback font to use when the requested font +cannot be opened, and `cursor', which specifies the set of glyphs to be used +by the mouse pointer. -Short names are usually implemented as aliases to XLFDs; the `fixed' and -`cursor' aliases are defined in +Short names are usually implemented as aliases to XLFDs; the standard `fixed' +and `cursor' aliases are defined in /usr/X11R6/lib/X11/font/misc/fonts.alias -6.3 Unicode +5.3 Unicode Unicode (<URL:http://www.unicode.org>) is a coded character set with the goal of uniquely identifying all characters for all scripts, current and histori- @@ -980,34 +1085,46 @@ it is often possible to use it as such. Unicode is an open character set, meaning that codepoint assignments may be added to Unicode at any time (once specified, though, an assignment can never -be changed). For this reason, a Unicode font will be sparse, and only define -glyphs for a subset of the character registry of Unicode. +be changed). For this reason, a Unicode font will be sparse, meaning that it +only defines glyphs for a subset of the character registry of Unicode. The Unicode standard is defined in parallel with the international standard -ISO 10646. Assignments in the two standards are always equivalent, and this -document uses the terms Unicode and ISO 10646 interchangeably. +ISO 10646. Assignments in the two standards are always equivalent, and we +often use the terms Unicode and ISO 10646 interchangeably. -When used in X11, Unicode-encoded fonts should have the last two fields of -their XLFD set to `iso10646-1'. +When used in the X11 core fonts system, Unicode-encoded fonts should have the +last two fields of their XLFD set to `iso10646-1'. -7. References +6. References XFree86 comes with extensive documentation in the form of manual pages and -typeset documents. Before installing fonts, you really should read the -mkfontdir(1) manual page; other manual pages of interest include X(1), -Xserver(1), xset(1), xlsfonts(1) and showfont(1). In addition, you may want -to read the X Logical Font Description document, by Jim Flowers, which is -provided in the file `xc/doc/xlfd.PS.Z'. +typeset documents. Before installing fonts, you really should read the font- +config(3) and mkfontdir(1) manual pages; other manual pages of interest +include X(7), Xserver(1), xset(1), Xft(3), xlsfonts(1) and showfont(1). In +addition, you may want to read the X Logical Font Description document, by +Jim Flowers, which is provided in the file `xc/doc/xlfd.PS.Z'. + +The latest released version of the XFree86 documentation (including this doc- +ument and all manual pages) is available as current XFree86 documentation +<URL:http://www.xfree86.org/current/>. The comp.fonts FAQ <URL:http://www.netmeg.net/faq/computers/fonts/>, which is unfortunately no longer being maintained, contains a wealth of information about digital fonts. +Xft and Fontconfig are described on Keith Packard's Fontconfig site +<URL:http://www.fontconfig.org>. + The xfsft home page <URL:http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/> has been superseded by this document, and is now obsolete; you may however -still find some of the information it contains useful. Joerg Pommnitz' xfsft -page <URL:http://www.joerg-pommnitz.de/TrueType/xfsft.html> is the canonical -source for the `ttmkfdir' utility. +still find some of the information that it contains useful. Joerg Pommnitz' +xfsft page <URL:http://www.joerg-pommnitz.de/TrueType/xfsft.html> is the +canonical source for the `ttmkfdir' utility, which is the ancestor of +mkfontscale. + +The author's software pages <URL:http://www.pps.jussieu.fr/~jch/software/> +might or might not contain related scribbles and development versions of +software. The documentation of X-TrueType is available from the X-TrueType home page <URL:http://x-tt.dsl.gr.jp/>. @@ -1015,15 +1132,15 @@ The documentation of X-TrueType is available from the X-TrueType home page A number of East-Asian CIDFonts are available from O'Reilly's FTP site <URL:ftp://ftp.oreilly.com/pub/examples/nutshell/cjkv/adobe/>. -The Unicode consortium site <URL:http://www.unicode.org> may be of interest. -But you are more likely to find what you need on Markus Kuhn's UTF-8 and Uni- -code FAQ <URL:http://www.cl.cam.ac.uk/~mgk25/unicode.html>. +While the Unicode consortium site <URL:http://www.unicode.org> may be of +interest, you are more likely to find what you need in Markus Kuhn's UTF-8 +and Unicode FAQ <URL:http://www.cl.cam.ac.uk/~mgk25/unicode.html>. The IANA RFC documents, available from a number of sites throughout the -world, often provide interesting information about character set issues; my -favourite is RFC 373. +world, often provide interesting information about character set issues; see +for example RFC 373. - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/fonts.sgml,v 1.15 2001/12/17 19:25:36 dawes Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/fonts.sgml,v 1.20 2003/01/20 03:43:07 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.fonts,v 1.19 2001/12/20 00:15:41 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.fonts,v 1.22 2003/01/20 04:10:01 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.mouse b/xc/programs/Xserver/hw/xfree86/doc/README.mouse index cd71b3e2c..653b026de 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/README.mouse +++ b/xc/programs/Xserver/hw/xfree86/doc/README.mouse @@ -2,11 +2,11 @@ Kazutaka Yokota - 9 February 2000 + 17 December 2002 1. Introduction -This document describes mouse support in XFree86 4.2.0. +This document describes mouse support in XFree86 4.3.0. Mouse configuration has often been mysterious task for novice users. How- ever, once you learn several basics, it is straightforward to write the mouse @@ -311,7 +311,7 @@ the guidelines below. o IntelliMouse - o Logictech + o Logitech o Microsoft @@ -451,6 +451,33 @@ inch, if possible: Not all mice and OSs can support this option. This option can be set in the XF86Setup program. +5.4 Drag Lock Buttons + +Some people find it difficult or inconvenient to hold a trackball button +down, while at the same time moving the ball. Drag lock buttons simulate the +holding down of another button. When a drag lock button is first pressed, +its target buttons is "locked" down until the second time the lock button is +released, or until the button itself is pressed and released. This allows the +starting of a drag, the movement of the trackball, and the ending of the drag +to be separate operations. + + Option "DragLockButtons" "W X Y Z" + +This option consists of pairs of buttons. Each lock button number is followed +by the number of the button that it locks. In the above, button number "W" is +a drag lock button for button "X" and button number "Y" is a drag lock button +for button "Z". + +It may not be desirable to use multiple buttons as drag locks. Instead, a +"master drag lock button" may be defined. A master drag lock button acts as a +"META" key. After a master lock button is released, the next button pressed +is "locked" and not released until the second time the real button is +released. + + Option "DragLockButtons" "M" + +Since button "M" is unpaired it is a master drag lock button. + 6. Mouse Gallery In all of the examples below, it is assumed that /dev/mouse is a link to the @@ -520,10 +547,10 @@ detection: Option "Protocol" "Auto" -6.3 Kensington Thinking Mouse (serial, PS/2) +6.3 Kensington Thinking Mouse and Kensington Expert Mouse (serial, PS/2) -This mouse has four buttons. Thinking Mouse supports the PnP COM device -specification. +These mice have four buttons. The Kensington Expert Mouse is really a track- +ball. Both Thinking mice support the PnP COM device specification. To use this mouse as a serial device: @@ -925,7 +952,40 @@ have the following InputDevice section. The movement of the first wheel is mapped to the button 4 and 5. The second wheel's movement will be reported as the buttons 6 and 7. - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/mouse.sgml,v 1.11 2000/03/01 00:25:23 dawes Exp $ +The Kensington Expert mouse is really a trackball. It has 4 buttons arranged +in a rectangle around the ball. + + Section "InputDevice" + Identifier "DLB" + Driver "mouse" + Option "Protocol" "ThinkingMousePS/2" + Option "Buttons" "3" + Option "Emulate3Buttons" + Option "Device" "/dev/mouse" + Option "DragLockButtons" "2 1 4 3" + EndSection + +In this example, button 2 is a drag lock button for button number 1, and but- +ton 4 is a drag lock button for button 3. Since button 2 is above button 1 +and button 4 is above button 3 in the layout of this trackball, this is rea- +sonable. + +Because button 2 is being used as a drag lock, it can not be used as an ordi- +nary button. However, it can be activated by using the "Emulate3Buttons" fea- +ture. However, some people my be unable to press two buttons at the same +time. They may prefer the following InputDevice section which defines button +4 as a master drag lock button, and leaves button 2 free for ordinary use. + + Section "InputDevice" + Identifier "MasterDLB" + Driver "mouse" + Option "Protocol" "ThinkingMousePS/2" + Option "Buttons" "3" + Option "Device" "/dev/mouse" + Option "DragLockButtons" "4" + EndSection + + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/mouse.sgml,v 1.13 2002/12/17 20:55:22 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.mouse,v 1.13 2001/11/15 17:37:23 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.mouse,v 1.20 2003/02/24 04:03:24 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.neomagic b/xc/programs/Xserver/hw/xfree86/doc/README.neomagic index ae3b2b005..7cd1b9d30 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/README.neomagic +++ b/xc/programs/Xserver/hw/xfree86/doc/README.neomagic @@ -184,7 +184,7 @@ age your LCD. 8. Authors -Jens Owen jens@precisioninsight.com Kevin E. Martin kevin@precisionin- +Jens Owen jens@tungstengraphics.com Kevin E. Martin kevin@precisionin- sight.com This driver was donated to The XFree86 Project by Precision Insight, Inc. @@ -195,4 +195,4 @@ http://www.precisioninsight.com Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/neomagic.sgml,v 1.1 1999/08/23 06:59:39 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.neomagic,v 1.3 2000/03/01 01:48:26 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.neomagic,v 1.4 2002/10/30 12:52:10 alanh Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.newport b/xc/programs/Xserver/hw/xfree86/doc/README.newport index 9e63ccca0..ca392ea52 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/README.newport +++ b/xc/programs/Xserver/hw/xfree86/doc/README.newport @@ -2,41 +2,47 @@ Guido Günther - 16 January 2002 + 24 February 2003 1. Supported Hardware -This is an unaccelerated driver for the SGI Indy's newport cards. Both the -8bit and 24bit versions are tested and working. +This is an unaccelerated driver for the SGI newport cards (a.k.a. XL) as +found in the SGI Indy and Indigo2. Both the 8bit and 24bit versions are +tested and working. 2. Features - o support for 8 and 24 bit pixel depths + o Support for 8 and 24 bit pixel depths -3. Notes + o Hardware cursor support to reduce flicker - o X -configure does not generate a XF86Config file +3. Notes - o Restoration of the console fails on some variants of the newport (Cmap - revision C) + o X -configure does not generate a XF86Config file. - o There's only a 1280x1024 mode + o There's only a 1280x1024 mode. 4. Configuration The driver auto-detects all device information necessary to initialize the -card. The only lines you need in the "Device" section of your XF86Config -file are: +card on the Indy. The only lines you need in the "Device" section of your +XF86Config file are: Section "Device" Identifier "SGI newport" Driver "newport" EndSection +Indigo2 users have to use the BusID option as documented below. + However, if you have problems with auto-detection, you can specify: o bitplanes - number of physical bitplanes (8 or 24) + o HWCursor - enable or disable hardware cursor + + o BusID - set this to "1" on the Indigo2 XL + 5. Authors o Guido Guenther <agx@sigxcpu.org> @@ -54,7 +60,7 @@ However, if you have problems with auto-detection, you can specify: o all the guys who wrote the newport_con linux kernel code - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/newport.sgml,v 1.4 2002/01/16 18:21:04 dawes Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/newport.sgml,v 1.6 2003/02/25 19:31:02 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.newport,v 1.5 2002/01/16 20:51:03 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.newport,v 1.7 2003/02/25 21:32:35 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.s3virge b/xc/programs/Xserver/hw/xfree86/doc/README.s3virge index 7e1909d69..fe1ba8a26 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/README.s3virge +++ b/xc/programs/Xserver/hw/xfree86/doc/README.s3virge @@ -6,11 +6,10 @@ 1. Supported hardware -The s3virge driver in XFree86 4.2.0 supports the S3 ViRGE, ViRGE DX, GX, GX2, +The s3virge driver in XFree86 4.3.0 supports the S3 ViRGE, ViRGE DX, GX, GX2, MX, MX+, and VX chipsets. It also supports Trio3D and Trio3D/2x chips. A majority of testing is done on ViRGE DX chips, making them the most stable to -date. This release has some stabilization fixes for MX, GX2 and Trio3D, and -XVideo support for MX and GX2. +date. This release has added support for doublescan modes on DX. This driver is moderately stable, however please use caution with any new install. Please report any problems to <XFree86@XFree86.org> using the @@ -24,11 +23,15 @@ appropriate bug report sheet. o supports resolutions up to 2048x2048 - o supports color depths of 8, 15, 16, 24. + o supports color depths of 8, 15, 16 and 24 o full use of video card memory for acceleration caching when visible framebuffer leaves extra memory + o XVideo on DX, GX, GX2, MX, MX+ and Trio3D/2X at depth 16 and 24 + + o Doublescan modes on DX, possibly others (untested) + 3. Configuration: The driver auto-detects RAM size, RAMDAC and ClockChip. Do not bother putting @@ -43,9 +46,8 @@ options. 5. Support: For support with XFree86 video drivers please refer to our web site at -XFree86 <URL:http://www.XFree86.org>. The web page has a bug reporting form -available. For problems not addressed in the web page please contact our -support email address <XFree86@XFree86.org> +XFree86 <URL:http://www.XFree86.org>. For problems not addressed in the web +page please contact our support email address <XFree86@XFree86.org> 6. Authors @@ -59,7 +61,7 @@ support email address <XFree86@XFree86.org> o Kevin Brosius <cobra@compuserve.com> - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/s3virge.sgml,v 1.5 2001/12/21 21:01:57 dawes Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/s3virge.sgml,v 1.6 2003/02/13 03:21:33 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.s3virge,v 1.9 2002/01/07 22:07:16 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.s3virge,v 1.15 2003/02/24 04:03:24 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/RELNOTES b/xc/programs/Xserver/hw/xfree86/doc/RELNOTES index 6c5d6cebb..5e5d93bbe 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/RELNOTES +++ b/xc/programs/Xserver/hw/xfree86/doc/RELNOTES @@ -1,222 +1,203 @@ - Release Notes for XFree86[tm] 4.2.0 + Release Notes for XFree86[tm] 4.3.0 The XFree86 Project, Inc - 17 January 2002 + 26 February 2003 Abstract This document contains some information about features present in - XFree86 4.2.0 and their status. + XFree86 4.3.0 and their status. 1. Introduction to the 4.x Release Series XFree86 4.0 was the first official release of the new XFree86 4 series. The -current release (4.2.0) is the latest in that series. XFree86 4 represents a +current release (4.3.0) is the latest in that series. XFree86 4 represents a significant redesign of the XFree86 X server. Not all of the hardware -drivers from 3.3.x have been ported to 4.x yet, but conversely, 4.x has some -hardware support not present in 3.3.x. Our Driver Status document summarizes -how the hardware driver support compares between 3.3.6 and 4.2.0. Please -check there first before downloading 4.2.0. +drivers from 3.3.x have been ported to 4.x yet, but conversely, 4.x has sup- +port for a lot of hardware that is not supported in 3.3.x. Our Driver Status +document summarizes how the hardware driver support compares between 3.3.6 +and 4.3.0. Please check there first before downloading 4.3.0. The 4.0.1 release introduced a new graphical configuration tool, "xf86cfg", -and a text mode interface was added to it for the 4.0.2 release. It is work -in progress, but definitely worth trying out. The trusty old text-based tool -"xf86config" can also be used for generating X server config files. In addi- -tion to these tools, we've been working on a configuration tool that is -built-in to the X server. It is included in the release, and it works well -for some hardware. To try it out, just run (as root) "XFree86 -configure". +and a text mode interface was added to it for the 4.0.2 release. It is the +preferred configuration tool provided by with XFree86. The trusty old text- +based tool "xf86config" can also be used for generating X server config +files. In addition to these tools, the XFree86 server has some built in +capabilities for generating a base config file. This works well for most +hardware, and in most cases is the easiest way to get an initial config file. +To try it out, just run (as root): + + XFree86 -configure + Each of these configuration options will give you a reasonable starting point for a suitable configuration file. We've put some effort into documenting -the 4.2.0 config file format, and you can find that information in the -XF86Config manual page. Check that, the driver manual pages and the related -documentation for further information. +the 4.3.0 config file format, and you can find that information in the +XF86Config manual page. Check there and the driver-specific manual pages and +the related documentation for further information. References to this +driver-specific information can be found in the tables below (section 3., +page 1). + +We have plans to make the configuration file optional in a future release. +The XFree86 server is close to being able to automatically determine a com- +plete base configuration for most popular hardware configurations. Before you go to download and install the binary distributions for this release, please have a quick read through the Installation Document. It may save you some time and help you figure out which of the binary releases you need. -The next section describes what is new in the latest version (4.2.0) compared -with the previous full release (4.1.0). The other sections below describe +The next section describes what is new in the latest version (4.3.0) compared +with the previous full release (4.2.0). The other sections below describe some of the new features and changes between 3.3.x and 4.0. There are lot's of new features, and we definitely don't have enough space to cover them all here. -2. Summary of new features in 4.2.0. +2. Summary of new features in 4.3.0. 2.1 Video Driver Enhancements - o An s3 driver is added, which provides support for many of the older - non-ViRGE and non-Savage S3 chipsets. - - o Some vmware driver problems are fixed, and the driver is updated to - take advantage of VMWare Workstation 3.0 features. These include - improved hardware cursor handling and support for 8 bit emulation. - - o Support added for Trident *BladeXP chipsets (currently not-acceler- - ated). - - o Xv support added for Trident TGUI series chips (not 9440 though). - - o Support added for the older Trident chipsets again for ISA/VLBus (not - tested) - - o Support added to the glint driver for 3DLabs Permedia4, GLINT R4 and - Gamma 2 chipsets. + o ATI Radeon 9x00 2D support added, and 3D support added for the Radeon + 8500, 9000, 9100, and M9. The 3D support for the Radeon now includes + hardware TCL. - o Support added to the i810 driver for Intel i830 (tested on Linux only). + o Support added to the i810 driver for Intel 845G, 852GM, 855GM and 865G + integrated graphics chipsets, including 2D, 3D (DRI) and XVideo. Sup- + port for the 830M has been improved, and XVideo support added. - o Support added to the ATI radeon driver for Radeon 7500 (2D and 3D), - Radeon 8500 (2D only), and Rage128ProII. + o National Semiconductor SC1x00, GX1, and GX2 chipset support added with + the "nsc" driver. - o Support added for the Matrox G550 support. This included dual-head - support. + o Support added for the NVIDIA nForce2 integrated graphics, GeForce 4, + and GeForce FX. - o Support added for NVIDIA nForce integrated graphics. + o Major SiS driver updates for some of the latest chipsets. Unfortu- + nately the SiS 3D driver has had to be disabled because no one has yet + taken up the challenge to port it to Mesa 4.x. - o The NVIDIA nv driver now has preliminary powerpc support for the NV11 - and NV20. + o The s3virge driver now has support for double scan modes on the DX + (with XVideo disabled). - o Support added to the NVIDIA nv driver for interlaced modes on hardware - that supports this, and support for resolutions higher than 1600x1200. + o Updates to the savage driver, including fixing problems with the + TwisterK, and problems with incorrect memory size detection. - o Fixes for the savage driver on 64-bit platforms, XVideo support for the - SuperSavage, and other savage driver updates. + o 2D acceleration added for the Trident CyberBladeXP/Ai1 chipsets. - o The ATI r128 driver now uses the CCE DMA engine for 2D acceleration - when direct rendering is enabled, which reduces context switching over- - head and improves stability and performance for XVideo and some 2D oper- - ations. + o Support for big endian architectures has been added to the C&T driver. - o The fbdev driver now supports rotation. - - o Various updates to the apm, ark, chips (C&T), cirrus, i128, neomagic, - newport, s3virge, siliconmotion, sis, tdfx, tseng, vesa, and vga - drivers. + o Various updates and bug fixes have been made to most other drivers. 2.2 Input Driver Enhancements - o The mouse driver now has support for mouse wheel emulation. - - o The mouse driver can now handle replug events on Linux for PS/2 mice. - - o The "Min/Max X/Y Position" options in the elographics and mutouch - drivers are changed to "Min/Max X/Y" to be consistent with the other - input drivers. - - o Linux USB keyboard access is fixed when no PS/2 controller is present. + o The mouse driver now has automatic protocol detection for PS/2 mice. - o Added calcomp input driver. - - o Added DMC input driver. - - o Added hyperpen input driver. + o Several new input drivers have been added, including tek4957, jamstudio + (js_x), fpit, palmax, and ur98 (Linux only). 2.3 X Server and Extension Updates - o Resynced with X.Org's X11R6.6. - - o Mesa updated to the post-3.4.2 3.4 branch version as of November 2001. - - o DRI drivers resynced with the latest from the DRI project. - - o Various updates to the Xft library. - - o The DEC-XTRAP extension is now available. - - o The PEX and XIE extensions are no longer built/distributed by default. - - o A security problem related to glyph clipping for large origins is - fixed. + o Support for the RandR extension has been partially integrated into the + XFree86 server, providing support for resizing the root window at run- + time. - o An i810 XvMC (motion compensation) driver is now available (Linux - only). + o The Mesa version used for OpenGL® 1.3 and DRI driver support has been + updated to 4.0.4. - o A fatal bug XVideo Xineramification bug is fixed. + o The XFree86 server's hot keys (including those for switching modes and + virtual terminals) can now be configured via XKB. Previously they were + hard coded. An X server configuration option has been added to allow + the VT switching hot keys to be disabled. 2.4 Client and Library Updates - o FreeType2 updated to version 2.0.6. + o An Xcursor library providing support for alpha blended (ARGB) and ani- + mated cursors. Two Xcursor themes are provided (redglass and white- + glass), as well as the default "core" theme (the traditional cursors). - o Added libGL man pages. + o Xterm updated to patch level 173, including the following bugfixes: - o Xload now has support for displaying the load of remote hosts. + o Fix two infinite loops (special cases of mouse hilite tracking, + DECUDK parsing). - o Xterm updated to patch level 165. + o Make repainting of the 256-color example work properly. - o SuperProbe is removed. + o Modify parser tables to improve detection of malformed control + sequences, making xterm behave more like a real DEC terminal. - o Sample xtrap clients added. - -2.5 I18N and Font Updates + o Fix a problem with the blinking cursor which occasionally caused + xterm to pause until a key was pressed. - o New Luxi scalable fonts (TrueType and Type 1) from Bigelow & Holmes. - These fonts are original designs by Kris Holmes and Charles Bigelow. - See below (section 4.22, page 1) for further information. + o Fix improper parsing of multiple items in the ttyModes resource. - o More locale/international keyboards supported. + and the following improvements: - o Modularized I18N support in Xlib is included from X11R6.6. + o Modify xterm to invoke luit. - o A problem that caused bdftopcf to sometimes write corrupted fonts is - fixed. + o Add simple session management client capabilities. - o Some problem with Xlib's handling of CTEXT and multi-byte characters - are fixed. + o Add a modifyCursorKeys resource to control how the shift- and sim- + ilar modifiers are used to make a cursor escape sequence. - o The fontenc layer is updated, and the fontenc library is now installed - and available for other applications. + o Check if the printerCommand resource string is empty, and use this + to allow the user to disable printer function. - o Improvements to the input method framework in Xlib for UTF-8 locales. + o Sort the options list which is displayed in help- and syntax-mes- + sages at runtime to simplify maintenance. - o A filter called ``luit'' is added, which provides locale and ISO 2022 - support to any Unicode terminal, notably xterm. Use of luit is still - experimental in this release. +2.5 I18N and Font Updates -2.6 OS Support Updates + o FreeType2 updated to version 2.1.1. - o Build problems on both QNX4 and QNX6 are fixed. + o The "freetype" X server font backend has undergone a partial rewrite. + The new version is based on FreeType 2, and handles TrueType (including + OpenType/TTF), OpenType/CFF and Type 1 fonts. The old "type1" backend + is now deprecated, and is only used for CIDFonts by default. - o VT switching problems with the i810 driver on FreeBSD are worked - around. + o A new utility called "mkfontscale", which builds fonts.scale files, has + been added. - o Problems building modules with some enhanced versions of gcc are fixed. + o The Xft library has undergone a major restructuring, and is now split + into fontconfig (which deals with font discovery and configuration and + is independent from X), and Xft itself (which uses fontconfig and deals + with font rasterisation and rendering. The format of the Xft font con- + figuration files has changed in an incompatible manner. - o Lots of updates for Darwin/Mac OS X, including: + o Support has been added to the Xft library to do rendering with the core + X11 protocol. This allows clients using this library to render to X + servers that don't have support for the RENDER extension. - o On Mac OS X, a new rootless mode is added to the XDarwin X server. - This allows X clients to display windows on the Aqua desktop. + o There has been a significant reworking of the XKB support to allow + multi-layout configurations. Multi-layout configurations provide a + flexible way of supporting multiple language layouts and switching + between them. - o Xinerama support added to XDarwin +2.6 OS Support Updates - o With XDarwin in full screen mode, the depth, size, and refresh - rate can now be chosen to be different from the settings used by - Aqua. + o Updates for Darwin/Mac OS X, including: - o GLX support added for Darwin and Mac OS X with software rendering. + o Indirect GLX acceleration added. - o Keymap setup in XDarwin is improved, particularly for interna- - tional keyboards. + o Smaller memory footprint and faster 2-D drawing in rootless mode. - o In addition to English and Japanese, the XDarwin user interface is - now localized in Dutch, French, German, Spanish, and Korean. + o Full screen mode now uses shadowfb for much faster 2-D drawing. - o Lots of Cygwin support updates. + o Native fonts can be used on MacOS X. - o Support added for OpenBSD/powerpc. + o Various Cygwin support updates, including an experimental rootless X + server for Cygwin/XFree86. - o Build support added for Linux on IBM S/390. + o AMD x86-64 support (primarily for Linux so far) has been added. - o Removed stale support for Amoeba and Minix. + o Support added for OpenBSD/sparc64. - o Client-side support added for sparc64 on NetBSD and OpenBSD. + o Major OS/2 support updates. - o Support added for building the X server on Linux/m68k. + o Major SCO OpenServer updates. - o Support added for building on Linux/arm32. + o Multi-head support has been added for 460GX-based Itanium systems, and + for ZX1-based Itanium2 systems. - o Updates to Linux/mips support. + o Experimental support for SunOS/Solaris on UltraSPARC systems. A more complete list of changes can be found in the CHANGELOG that is part of the XFree86 source tree. It can also be viewed online at our CVSweb server @@ -227,49 +208,50 @@ grams/Xserver/hw/xfree86/CHANGELOG?rev=HEAD>. 3.1 Video Drivers -XFree86 4.2.0 includes the following video drivers: - -+--------------+--------------------------+----------------------------------+ -|Driver Name | Description | Further Information | -+--------------+--------------------------+----------------------------------+ -|apm | Alliance Pro Motion | README.apm | -|ark | Ark Logic | | -|ati | ATI | README.ati, README.r128, r128(4) | -|chips | Chips & Technologies | README.chips, chips(4) | -|cirrus | Cirrus Logic | | -|cyrix (*) | Cyrix MediaGX | README.cyrix | -|fbdev | Linux framebuffer device | fbdev(4) | -|glide | Glide2x (3Dfx) | glide(4) | -|glint | 3Dlabs, TI | glint(4) | -|i128 | Number Nine | README.I128, i128(4) | -|i740 | Intel i740 | README.i740 | -|i810 | Intel i810 | README.i810, i810(4) | -|imstt | Integrated Micro Solns | | -|mga | Matrox | mga(4) | -|neomagic | NeoMagic | neomagic(4) | -|newport (-) | SGI Newport | README.newport, newport(4) | -|nv | NVIDIA | nv(4) | -|rendition | Rendition | README.rendition, rendition(4) | -|s3 | S3 (not ViRGE or Savage) | | -|s3virge | S3 ViRGE | README.s3virge, s3virge(4) | -|savage | S3 Savage | savage(4) | -|siliconmotion | Silicon Motion | siliconmotion(4) | -|sis | SiS | README.SiS | -|sunbw2 (+) | Sun bw2 | | -|suncg14 (+) | Sun cg14 | | -|suncg3 (+) | Sun cg3 | | -|suncg6 (+) | Sun GX and Turbo GX | | -|sunffb (+) | Sun Creator/3D, Elite 3D | | -|sunleo (+) | Sun Leo (ZX) | | -|suntcx (+) | Sun TCX | | -|tdfx | 3Dfx | | -|tga | DEC TGA | README.DECtga | -|trident | Trident | trident(4) | -|tseng | Tseng Labs | | -|vesa | VESA | vesa(4) | -|vga | Generic VGA | vga(4) | -|vmware | VMWare guest OS | vmware(4) | -+--------------+--------------------------+----------------------------------+ +XFree86 4.3.0 includes the following video drivers: + ++--------------+--------------------------+---------------------------------------------+ +|Driver Name | Description | Further Information | ++--------------+--------------------------+---------------------------------------------+ +|apm | Alliance Pro Motion | README.apm | +|ark | Ark Logic | | +|ati | ATI | README.ati, README.r128, r128(4), radeon(4) | +|chips | Chips & Technologies | README.chips, chips(4) | +|cirrus | Cirrus Logic | | +|cyrix (*) | Cyrix MediaGX | README.cyrix | +|fbdev | Linux framebuffer device | fbdev(4) | +|glide | Glide2x (3Dfx) | glide(4) | +|glint | 3Dlabs, TI | glint(4) | +|i128 | Number Nine | README.I128, i128(4) | +|i740 | Intel i740 | README.i740 | +|i810 | Intel i8xx | README.i810, i810(4) | +|imstt | Integrated Micro Solns | | +|mga | Matrox | mga(4) | +|neomagic | NeoMagic | neomagic(4) | +|newport (-) | SGI Newport | README.newport, newport(4) | +|nsc | National Semiconductor | nsc(4) | +|nv | NVIDIA | nv(4) | +|rendition | Rendition | README.rendition, rendition(4) | +|s3 | S3 (not ViRGE or Savage) | | +|s3virge | S3 ViRGE | README.s3virge, s3virge(4) | +|savage | S3 Savage | savage(4) | +|siliconmotion | Silicon Motion | siliconmotion(4) | +|sis | SiS | README.SiS, sis(4) | +|sunbw2 (+) | Sun bw2 | | +|suncg14 (+) | Sun cg14 | | +|suncg3 (+) | Sun cg3 | | +|suncg6 (+) | Sun GX and Turbo GX | | +|sunffb (+) | Sun Creator/3D, Elite 3D | | +|sunleo (+) | Sun Leo (ZX) | | +|suntcx (+) | Sun TCX | | +|tdfx | 3Dfx | tdfx(4) | +|tga | DEC TGA | README.DECtga | +|trident | Trident | trident(4) | +|tseng | Tseng Labs | | +|vesa | VESA | vesa(4) | +|vga | Generic VGA | vga(4) | +|vmware | VMWare guest OS | vmware(4) | ++--------------+--------------------------+---------------------------------------------+ Drivers marked with (*) are present in a preliminary form in this release, but are not complete and/or stable yet. @@ -281,40 +263,49 @@ Drivers marked with (-) are for Linux/mips only. Darwin/Mac OS X uses IOKit drivers and does not use the module loader drivers listed above. Further information can be found in README.Darwin. -XFree86 4.2.0 includes the following input drivers: +XFree86 4.3.0 includes the following input drivers: 3.2 Input Drivers - +------------+--------------------+---------------------+ - |Driver Name | Description | Further Information | - +------------+--------------------+---------------------+ - |calcomp | Calcomp | | - |citron | Citron | citron(4) | - |digitaledge | DigitalEdge | | - |dmc | DMC | dmc(4) | - |dynapro | Dynapro | | - |elographics | EloGraphics | | - |hyperpen | HyperPen | | - |keyboard | generic keyboards | keyboard(4) | - |microtouch | MicroTouch | | - |mouse | most mouse devices | mouse(4) | - |mutouch | MicroTouch | | - |penmount | PenMount | | - |spaceorb | SpaceOrb | | - |summa | SummaGraphics | | - |void | dummy device | void(4) | - |wacom | Wacom tablets | wacom(4) | - +------------+--------------------+---------------------+ + +------------+----------------------------------+---------------------+ + |Driver Name | Description | Further Information | + +------------+----------------------------------+---------------------+ + |calcomp | Calcomp | | + |citron | Citron | citron(4) | + |digitaledge | DigitalEdge | | + |dmc | DMC | dmc(4) | + |dynapro | Dynapro | | + |elographics | EloGraphics | | + |elographics | EloGraphics | | + |fpit | Fujitsu Stylistic Tablet PCs | fpit(4) | + |hyperpen | HyperPen | | + |js_x | JamStudio pentablet | js_x(4) | + |kbd | generic keyboards (alternate) | kbd(4) | + |keyboard | generic keyboards | keyboard(4) | + |microtouch | MicroTouch | | + |mouse | most mouse devices | mouse(4) | + |mutouch | MicroTouch | | + |palmax | Palmax PD1000/PD1100 | palmax(4) | + |penmount | PenMount | | + |spaceorb | SpaceOrb | | + |summa | SummaGraphics | | + |tek4957 | Tektronix 4957 tablet | tek4957(4) | + |ur98(*) | Union Reality UR-F98 headtracker | ur98(4) | + |void | dummy device | void(4) | + |wacom | Wacom tablets | wacom(4) | + +------------+----------------------------------+---------------------+ + +Drivers marked with (*) are available for Linux only. 4. Overview of XFree86 4.x. Unlike XFree86 3.3.x where there are multiple X server binaries, each of -which drive different hardware, XFree86 4.2.0 has a single X server binary +which drive different hardware, XFree86 4.3.0 has a single X server binary called XFree86. This binary can either have one or more video drivers linked in statically, or, more usually, dynamically load the video drivers and other modules that are needed. -XFree86 4.2.0 has X server support for most UNIX(R) and UNIX-like operating +XFree86 4.3.0 has X server support for most UNIX(R) and UNIX-like operating systems on Intel/x86 platforms, plus support for Linux on Alpha, PowerPC, IA-64, Sparc, and Mips platforms, and for Darwin on PowerPC. Work on support for additional architectures and operating systems is in progress, and is @@ -336,7 +327,7 @@ they do not need to be recompiled for every different operating system. In the future we plan to take advantage of this to provide more frequent driver module updates in between major releases. -The loader in version 4.2.0 has support for Intel (x86), Alpha and PowerPC +The loader in version 4.3.0 has support for Intel (x86), Alpha and PowerPC platforms. It also has preliminary support for Sparc platforms. The X server makes use of modules for video drivers, X server extensions, @@ -442,7 +433,7 @@ ual page for more comprehensive information: The new option AllowDeactivateGrabs allows deactivating any active grab with the key sequence Ctrl+Alt+Keypad-Divide and the new option Allow- - ClosedownGrabs allows closing the conection to the grabbing client with + ClosedownGrabs allows closing the connection to the grabbing client with the key sequence Ctrl+Alt+Keypad-Multiply. Note that these options are off by default as they allow users to remove the grab used by screen saver/locker programs. @@ -517,8 +508,8 @@ ual page for more comprehensive information: Option "BlankTime" "5" EndSection - See the XF86Config man page for a more detailed explanation of the for- - mat of the new ServerLayout section. + See the XF86Config(5) man page for a more detailed explanation of the + format of the new ServerLayout section. The config file search patch has been extended, with the directories /etc/X11 and /usr/X11R6/etc/X11 being added. The full search path details are docu- @@ -684,7 +675,7 @@ Known problems: 4.7 DGA version 2 -DGA 2.0 is included in 4.2.0, but is not implemented by all drivers. Prelim- +DGA 2.0 is included in 4.3.0, but is not implemented by all drivers. Prelim- inary documentation for the client libraries can be found in the README.DGA document. A good degree of backwards compatibility with version 1.0 is pro- vided. @@ -753,7 +744,7 @@ anti-aliased text and geometric objects as well as perform translucent image overlays and other image operations not possible with the core X rendering system. -XFree86 4.2.0 provides a partial implementation of Render sufficient for +XFree86 4.3.0 provides a partial implementation of Render sufficient for drawing anti-aliased text and image composition. Still to be implemented are geometric primitives and affine transformation of images. @@ -784,31 +775,16 @@ XFree86 to use an existing FreeType installation. The Xft library uses a configuration file, XftConfig, which contains informa- tion about which directories contain font files and also provides a sophisti- cated font aliasing mechanism. Documentation for that file is included in -the Xft man page. +the Xft(3) man page. 4.11.2 FreeType support in Xft -XFree86 4.2.0 includes sources for FreeType version 2.0.6, and, by default, +XFree86 4.3.0 includes sources for FreeType version 2.1.1, and, by default, they are built and installed automatically. -If you prefer, you can configure XFree86 4.2.0 to use an existing Freetype2 -installation by telling XFree86 not to build the internal copy and indicating -where that external version has been installed. Edit (or create) con- -fig/cf/host.def to include: - - o #define BuildFreetype2Library NO - - o #define Freetype2Dir /usr/local - -Note that XFree86 assumes you'll be using a release FreeType no older than -version 2.0.1. Early FreeType version 2 releases used a different header -file installation and aren't compatible with XFree86. Instructions for build- -ing and installing FreeType can be found in the INSTALL file included with -the FreeType release. - 4.11.3 Application Support For Anti-Aliased Text -Only three applications have been modified in XFree86 4.2.0 to work with the +Only three applications have been modified in XFree86 4.3.0 to work with the Render extension and the Xft and FreeType libraries to provide anti-aliased text. Xterm, xditview and x11perf. Migration of other applications may occur in future releases. @@ -837,120 +813,31 @@ The xgamma utility makes use of this feature. Compatibility with the 3.3.x version of the extension is provided. The missing parts of this extension and some new features should be completed in a future release. -4.13 Xaw - -Two versions of the Xaw library are provided with XFree86 4.x. A version with -bug fixes and a few binary compatible improvements and a new version with -several new features. - -New features: - - o A displayList resource is available to all Xaw widgets. It basically - consists of a list of drawing commands, fully described in the Xaw(3) - manual page, that enables a integration of Xaw programs with the new - window/desktop managers that allows for configurable themes. - - o Some new actions were added to all Xaw widgets, to allow more config- - urable control of the widgets, and to allow setting resources at run - time. - - o Since Xpm was integrated into XFree86, programs linked with the new Xaw - library will also link with Xpm. This allows for color background - pixmaps, and also for shaped widgets. - - o The text widget is the widget that will present more changes. These - include: - - o Block cursor. - - o Compile time limit of 16384 undo/redo levels (that will automati- - cally grow if the text is not saved when this mark is reached). - - o Overwrite mode. - - o Text killed is inserted in a kill ring list, this text is not for- - gotten, pressing M-y allows traversing the kill ring list. - - o International support for latin languages is available even if the - international resource is not set. Users will need to properly set - the locale environment to make complete use of this feature. - - o A better multiply interface is provided. Pressing C-u,<number> - (where number can be negative) allows passing parameters for text - actions. - - o Text can be formatted to have left, right, center or full justifi- - cation. - - o Text indentation support is also available. - -Bug fixes: - - o The simple menu widget geometry management code was improved to solve - problems with menu entries not visible in the screen. - - o The form widget geometry code was changed to solve problems with integer - round problems in the child widgets geometry when resizing the parent - form widget. - - o Several bugs were fixed in the text code, while some code was rewritten - from scratch. - -4.14 Xpm - -Version 3.4k of the Xpm (X pixmap) library is now integrated into XFree86. - -4.15 xedit - -Xedit have been changed to use most of the new features added to the new ver- -sion of the Xaw library, and some xedit only features were added. Emacs users -will find that several of the emacs key bindings work with the new version of -xedit. These include: - - o File name tab completion. Including a Emacs dired like window, that will - be shown when there are more than one match, when C-x,d is pressed, or - when a directory name is specified. - - o An unlimited number of files can be edited at the same time. Including - multiple views of the same or different files. - - o The line number of the cursor position is always visible. It can also be - customized to show the column number, the position offset and the cur- - rent size of the file. - - o There is an autoReplace resource, that enables automatic text replace- - ment at the time text is typed. This feature is useful to create simple - macros, or to correct common spelling errors. - - o A fully featured ispell interface is also available. This interface is - expected to provide most of the features of the terminal interface of - the ispell program, with some extra features that include: - - o A compile time limit of 16 undo levels. +4.13 xedit - o Terse mode switch. +Xedit has several new features, including: - o Dictionary change. + o An embedded lisp interpreter that allows easier extension of the editor. - o The interface also checks for repeated words. + o Several new syntax highlight modes, and indentation rules for C and + Lisp. - o A first tentative to add programming modes was done. Currently, there is - one mode: + o Flexible search/replace interface that allows regex matches. - o C-mode: this mode is expected to be stable, and fully usable. + o Please refer to xedit(1) for more details. -4.16 Font support +4.14 Font support Details about the font support in XFree86 4.x can be found in the README.fonts document. -4.17 TrueType support +4.15 TrueType support XFree86 4.x comes with two TrueType backends, known as `xfsft' (the "freetype" module) and `X-TrueType' (the "xtt" module). Both of these back- ends are based on the FreeType library. -4.18 CID font support +4.16 CID font support Support for CID-keyed fonts is included in XFree86 4.x. The CID-keyed font format was designed by Adobe Systems <URL:http://www.adobe.com> for fonts @@ -958,7 +845,7 @@ with large character sets. The CID-keyed font support in XFree86 was donated by SGI <URL:http://www.sgi.com>. See the LICENSE document for a copy of the CID Font Code Public License. -4.19 Internationalisation of the scalable font backends +4.17 Internationalisation of the scalable font backends XFree86 4.x has a ``fontenc'' layer to allow the scalable font backends to use a common method of font re-encoding. This re-encoding makes it possible @@ -967,14 +854,14 @@ layer is used by the Type1 and Speedo backends and the `xfsft' version of the TrueType backend. The `X-TrueType' version of the TrueType backend uses a different re-encoding method based on loadable encoding modules. -4.20 Large font optimisation +4.18 Large font optimisation The glyph metrics array, which all the X clients using a particular font have access to, is placed in shared memory, so as to reduce redundant memory con- sumption. For non-local clients, the glyph metrics array is transmitted in a compressed format. -4.21 Unicode/ISO 10646 support +4.19 Unicode/ISO 10646 support What is included in 4.x: @@ -1007,7 +894,7 @@ What is included in 4.x: o Both the xfsft (the "freetype" module) and the X-TrueType (the "xtt" module) TrueType font backends support Unicode-encoded fonts. -4.22 Luxi fonts from Bigelow and Holmes +4.20 Luxi fonts from Bigelow and Holmes XFree86 now includes the ``Luxi'' family of Type 1 fonts and TrueType fonts. This family consists of the fonts ``Luxi Serif'', ``Luxi Sans'' and @@ -1032,7 +919,7 @@ as well as in the License document. For further information, please contact <design@bigelowandholmes.com> or <info@urwpp.de>, or consult the URW++ web site <URL:http://www.urwpp.de>. -4.23 Directory rearrangements +4.21 Directory rearrangements Some changes to the installed XFree86 directory structure have been imple- mented for 4.x. One important change is a modified search path for the X @@ -1043,7 +930,7 @@ location pointing to the new location. Some run-time generated files are now located under the appropriate subdirectories of /var, again with the relevant symbolic links in the old location. - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/RELNOTES.sgml,v 1.71 2002/01/21 19:01:35 dawes Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/RELNOTES.sgml,v 1.81 2003/02/27 00:45:05 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/RELNOTES,v 3.105 2002/01/22 22:26:10 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/RELNOTES,v 3.115 2003/02/27 01:44:03 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/Status b/xc/programs/Xserver/hw/xfree86/doc/Status index afa704489..04834e7ef 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/Status +++ b/xc/programs/Xserver/hw/xfree86/doc/Status @@ -1,24 +1,23 @@ - Driver Status for XFree86[tm] 4.2.0 + Driver Status for XFree86[tm] 4.3.0 The XFree86 Project, Inc - 16 January 2002 + 23 February 2003 Abstract This document provides information about the status of the driver - and hardware support in XFree86 4.2.0 compared with that in XFree86 + and hardware support in XFree86 4.3.0 compared with that in XFree86 3.3.6. Please send updates for this document to - <fixes@xfree86.org>. Please do not send requests for information - or support to that address (they will not be answered). + <XFree86@XFree86.org>. 1. Introduction This document contains one section per vendor (organised alphabetically) for -each chipset family that is supported in XFree86 3.3.6 or XFree86 4.2.0. It +each chipset family that is supported in XFree86 3.3.6 or XFree86 4.3.0. It includes information about the status of the drivers and the hardware they support, including a comparison of the level of support between versions -3.3.6 and 4.2.0. Unless otherwise stated, hardware is classified as "sup- +3.3.6 and 4.3.0. Unless otherwise stated, hardware is classified as "sup- ported" if its driver provides basic 2D support. Support for additional fea- tures may or may not be present. @@ -27,9 +26,9 @@ XF86_SVGA server, which has a set of driver modules that are built into it at compile time. In other cases, X servers for specific chips (or families of chips) are provided (such as XF86_AGX, XF86_Mach64, etc.). -In XFree86 4.2.0, there is only one X server, called "XFree86", which can +In XFree86 4.3.0, there is only one X server, called "XFree86", which can load driver modules at runtime. Thus there is no specific mention of a -server binary when 4.2.0 is discussed; only the XFree86 server is used. +server binary when 4.3.0 is discussed; only the XFree86 server is used. Third-party vendors (often the manufacturers of various video chipsets) may provide their own drivers for the XFree86 server, but these third-party mod- ules are beyond the scope of this document. @@ -45,7 +44,7 @@ architectures known to work on (e.g., Alpha, PPC), etc. Support (including acceleration) for Voodoo Banshee and Voodoo3 cards is provided by the XF86_SVGA server with the tdfx driver. - 4.2.0: + 4.3.0: Support for Voodoo Graphics and Voodoo2 chips is provided by the "glide" driver (this requires version 2.x of the Glide library, which is not part of the XFree86 distribution). @@ -54,9 +53,9 @@ architectures known to work on (e.g., Alpha, PPC), etc. Voodoo4, and Voodoo5 is provided by the "tdfx" driver. Summary: - All hardware supported in 3.3.6 is also supported in 4.2.0. The + All hardware supported in 3.3.6 is also supported in 4.3.0. The Voodoo Graphics, Voodoo2, Voodoo4, and Voodoo5 are supported only - in 4.2.0. + in 4.3.0. 3. 3Dlabs @@ -66,16 +65,16 @@ architectures known to work on (e.g., Alpha, PPC), etc. RAMDACs), Permedia with IBM RGB526 RAMDAC, and Permedia 2, 2a, 2v is provided by the XF86_3DLabs server. - 4.2.0: + 4.3.0: Support (including acceleration) for the Permedia series (includ- ing 1, 2, 2a, 2v, 3, and 4) and GLINT series (including 300SX, 500TX, MX, R3 and R4) with the Gamma, Gamma2 or Delta coprocessor is provided by the "glint" driver. Summary: - All hardware supported in 3.3.6 is also supported in 4.2.0. The + All hardware supported in 3.3.6 is also supported in 4.3.0. The Permedia 3, Permedia 4, GLINT R3, GLINT R4 and Gamma2 are sup- - ported only in 4.2.0. + ported only in 4.3.0. 4. Alliance @@ -83,15 +82,15 @@ architectures known to work on (e.g., Alpha, PPC), etc. Support (including acceleration) for the AT24, AP6422, AT3D is provided by the XF86_SVGA server with the apm driver. - 4.2.0: + 4.3.0: Support (including acceleration) for the AT24, AT25 and AT3D is provided by the "apm" driver. This driver currently has only incomplete support for the AP6422. Summary: - The AP6422 is supported in 3.3.6 but not fully in 4.2.0. All - other hardware supported in 3.3.6 is also supported in 4.2.0. - The AT25 is supported only in 4.2.0. + The AP6422 is supported in 3.3.6 but not fully in 4.3.0. All + other hardware supported in 3.3.6 is also supported in 4.3.0. + The AT25 is supported only in 4.3.0. 5. ARK Logic @@ -100,12 +99,12 @@ architectures known to work on (e.g., Alpha, PPC), etc. and ARK2000MT is provided by the XF86_SVGA server with the ark driver. - 4.2.0: + 4.3.0: Support (including acceleration) for the ARK1000PV, ARK2000PV, and ARK2000MT is provided by the "ark" driver. Summary: - All hardware supported in 3.3.6 is also supported in 4.2.0. + All hardware supported in 3.3.6 is also supported in 4.3.0. 6. ATI @@ -123,13 +122,13 @@ architectures known to work on (e.g., Alpha, PPC), etc. driver. Accelerated support is provided for the Rage 128 chips by the XF86_SVGA server with the r128 driver. - 4.2.0: + 4.3.0: Accelerated support is provided for Mach64, Rage, Rage 128 and Radeon chips by the "ati" driver, as is unaccelerated support for all of the others except the Mach8 and some early Mach32 chips. Summary: - All hardware supported in 3.3.6 is also supported in 4.2.0 except + All hardware supported in 3.3.6 is also supported in 4.3.0 except for Mach8 and some old Mach32 chips. 7. Avance Logic @@ -141,12 +140,12 @@ architectures known to work on (e.g., Alpha, PPC), etc. the others. These drivers reportedly work, but they have no maintainer. - 4.2.0: + 4.3.0: No Avance Logic chips are supported because the old drivers have not been ported. Summary: - No Avance Logic chips are supported in 4.2.0. + No Avance Logic chips are supported in 4.3.0. 8. Chips and Technologies @@ -155,13 +154,13 @@ architectures known to work on (e.g., Alpha, PPC), etc. 65545, 65546, 65548, 65550, 65554, 65555, 68554, 69000, 64200 and 64300 is provided by the XF86_SVGA server with the chips driver. - 4.2.0: + 4.3.0: Support (accelerated) for the 65520, 65525, 65530, 65535, 65540, 65545, 65546, 65548, 65550, 65554, 65555, 68554, 69000, 64200 and 64300 is provided by the "chips" driver. Summary: - All hardware supported in 3.3.6 is also supported in 4.2.0. + All hardware supported in 3.3.6 is also supported in 4.3.0. 9. Cirrus Logic @@ -173,13 +172,13 @@ architectures known to work on (e.g., Alpha, PPC), etc. 7541, 7542, 7543, 7548, 7555 and 7556 is provided by the XF86_SVGA server with the cirrus driver. - 4.2.0: + 4.3.0: Support (accelerated) for the Alpine (5430, 5434, 5436, 5446, 5480, 7548), and Laguna (5462, 5464, 5465) chips is provided by the "cirrus" driver. Summary: - The following chips are supported in 3.3.6 but not in 4.2.0: + The following chips are supported in 3.3.6 but not in 4.3.0: 6410, 6412, 6420, 6440, 5420, 5422, 5424, 5426, 5428, 5429, 6205, 6215, 6225, 6235, 7541, 7542, 7543, 7555 and 7556. @@ -195,7 +194,7 @@ architectures known to work on (e.g., Alpha, PPC), etc. 24 plane 3D chips (on Alpha platforms) is provided by the XF86_TGA server. - 4.2.0: + 4.3.0: No support exists for the Compaq AVGA (its driver hasn't been ported). @@ -204,8 +203,8 @@ architectures known to work on (e.g., Alpha, PPC), etc. the "tga" driver. Summary: - No Compaq AVGA chips are supported in 4.2.0. DEC TGA support is - equivalent in both 3.3.6 and 4.2.0. + No Compaq AVGA chips are supported in 4.3.0. DEC TGA support is + equivalent in both 3.3.6 and 4.3.0. 11. Cyrix @@ -213,13 +212,13 @@ architectures known to work on (e.g., Alpha, PPC), etc. Support (accelerated) for the Cyrix MediaGX is provided by the XF86_SVGA server with the cyrix driver. - 4.2.0: - The 3.3.6 driver has been ported to 4.2.0, including acceleration + 4.3.0: + The 3.3.6 driver has been ported to 4.3.0, including acceleration support, and is provided by the "cyrix" driver. Feedback is wanted. Summary: - Cyrix MediaGX users are encouraged to test its support in 4.2.0. + Cyrix MediaGX users are encouraged to test its support in 4.3.0. 12. Epson @@ -227,12 +226,12 @@ architectures known to work on (e.g., Alpha, PPC), etc. Support (accelerated) for the Epson SPC8110 is provided by the XF86_SVGA server with the spc8100 driver. - 4.2.0: + 4.3.0: No Epson chips are supported, because the old driver has not been ported. Summary: - No Epson chips are supported in 4.2.0. + No Epson chips are supported in 4.3.0. 13. Genoa @@ -242,12 +241,12 @@ architectures known to work on (e.g., Alpha, PPC), etc. because we don't have any recent test reports, and this driver has no maintainer. - 4.2.0: + 4.3.0: No Genoa chips are supported, because the old driver has not been ported. Summary: - No Genoa chips are supported in 4.2.0. + No Genoa chips are supported in 4.3.0. 14. IBM @@ -262,7 +261,7 @@ architectures known to work on (e.g., Alpha, PPC), etc. Support for the IBM XGA-2 chip is provided by the XF86_AGX server. - 4.2.0: + 4.3.0: Support for the standard IBM VGA chip (and compatibles) is pro- vided by the "vga" driver. @@ -271,7 +270,7 @@ architectures known to work on (e.g., Alpha, PPC), etc. Summary: The standard VGA core is supported in both versions, but there is - no support for the 8514/A or XGA-2 in 4.2.0. + no support for the 8514/A or XGA-2 in 4.3.0. 15. IIT @@ -279,12 +278,12 @@ architectures known to work on (e.g., Alpha, PPC), etc. Support (accelerated) for the AGX-016, AGX-015 and AGX-014 is provided by the XF86_AGX server. - 4.2.0: + 4.3.0: No IIT chips are supported, because the old driver has not been ported. Summary: - No IIT chips are supported in 4.2.0. + No IIT chips are supported in 4.3.0. 16. Integrated Micro Solutions (IMS) @@ -292,12 +291,12 @@ architectures known to work on (e.g., Alpha, PPC), etc. Support (accelerated) for the IMS Twin Turbo 128 and Twin Turbo 3D is provided by the XF86_SVGA server with the imstt driver. - 4.2.0: + 4.3.0: Support (accelerated) for the IMS Twin Turbo 128 and Twin Turbo 3D is provided by the "imstt" driver. Summary: - All hardware supported in 3.3.6 is also supported in 4.2.0. + All hardware supported in 3.3.6 is also supported in 4.3.0. 17. Intel @@ -308,19 +307,22 @@ architectures known to work on (e.g., Alpha, PPC), etc. requires the agpgart.o kernel module in order to use modes that require more than 1MB of video memory. - 4.2.0: + 4.3.0: Support (accelerated) for the Intel i740 is provided by the - "i740" driver, and support for the Intel i810 (including - i810-dc100 and i810e), i815, and i830 is provided by the "i810" - driver. The "i810" driver is currently supported only on Linux - and FreeBSD (4.1 and later), and requires AGP GART kernel sup- - port. + "i740" driver, and support for the Intel integrated graphics + chipsets i810, i810-dc100, i810e, i815, 830M, 845G, 852GM, 855GM + and 865G is provided by the "i810" driver. The i810 and i815 + chipsets require kernel-level AGP GART support (available on + Linux, FreeBSD, and some other BSDs). The 830M and later can be + used without AGP GART support, but it is required for full func- + tionality. Summary: The i740 and and original i810 are supported in both versions, - but the i810 is supported only on Linux/x86 and recent - FreeBSD/i386 platforms at present. Support for later versions of - the i810 chipset, such as the i815, exists only in 4.2.0. + but the i810/i815 is supported only on Linux, FreeBSD, and some + recent NetBSD/OpenBSD versions at present. platforms at present. + Support for later versions of the i810 chipset, such as the i815, + and for the 830M and later exists only in 4.3.0. 18. Matrox @@ -329,14 +331,14 @@ architectures known to work on (e.g., Alpha, PPC), etc. (Mystique), MGA2164W (Millennium II) (PCI and AGP), G100, G200 and G400 is provided by the XF86_SVGA server with the mga driver. - 4.2.0: + 4.3.0: Support (accelerated) for the MGA2064W (Millennium I), MGA1064SG (Mystique), MGA2164W (Millennium II) (PCI and AGP), G100, G200, G400, G450, and G550 is provided by the "mga" driver. Summary: - All hardware supported in 3.3.6 is also supported in 4.2.0. The - G450 and G550 are supported only in 4.2.0. + All hardware supported in 3.3.6 is also supported in 4.3.0. The + G450 and G550 are supported only in 4.3.0. 19. Micronix, Inc. (MX) @@ -346,88 +348,94 @@ architectures known to work on (e.g., Alpha, PPC), etc. is unknown because we don't have any recent test reports, and this driver has no maintainer. - 4.2.0: + 4.3.0: No MX chips are supported, because the old driver has not been ported. Summary: - No MX chips are supported in 4.2.0. + No MX chips are supported in 4.3.0. -20. NCR +20. National Semiconductor + + 4.3.0: + Support for the SC1x00, GX1, and GX2 is provided by the "nsc" + driver. + +21. NCR 3.3.6: Support for the old NCR 77C22 and 77C22E chips is provided by the XF86_SVGA server and the ncr77c22 driver. The status of this support is unknown because we don't have any recent test reports. - 4.2.0: + 4.3.0: No NCR chips are supported, because the old driver has not been ported. Summary: - No NCR chips are supported in 4.2.0. + No NCR chips are supported in 4.3.0. -21. NeoMagic +22. NeoMagic 3.3.6: Support (accelerated) for the NeoMagic NM2070, NM2090, NM2093, NM2097, NM2160 and NM2200 chipsets is provided by the XF86_SVGA server with the neo driver. - 4.2.0: + 4.3.0: Support (accelerated) for the NeoMagic NM2070, NM2090, NM2093, NM2097, NM2160, NM2200, NM2230, NM2360 and NM2380 chipsets is provided by the "neomagic" driver. Summary: - All hardware supported in 3.3.6 is also supported in 4.2.0. The - NM2230 and later chips are supported only in 4.2.0. + All hardware supported in 3.3.6 is also supported in 4.3.0. The + NM2230 and later chips are supported only in 4.3.0. -22. NVIDIA +23. NVIDIA 3.3.6: Support (accelerated) for the NV1, Riva 128, 128ZX, TNT, TNT2 (Ultra, Vanta, M64), GeForce (DDR, 256) and Quadro is provided by the XF86_SVGA server and the nv driver. - 4.2.0: + 4.3.0: Support (accelerated) for the Riva 128, 128ZX, TNT, TNT2 (Ultra, Vanta, M64), GeForce (DDR, 256), Quadro, GeForce2 (GTS, Ultra, MX), GeForce3, and Quadro2 is provided by the "nv" driver. Summary: All chipsets supported in 3.3.6 except the NV1 are also supported - in 4.2.0. Support for the newer chips listed above (starting - with the GeForce2) is available only in 4.2.0. + in 4.3.0. Support for the newer chips listed above (starting + with the GeForce2) is available only in 4.3.0. -23. Number Nine +24. Number Nine 3.3.6: Support (accelerated) for the Imagine 128, Ticket 2 Ride, Revolu- tion 3D and Revolution IV is provided by the XF86_I128 server. - 4.2.0: + 4.3.0: Support (accelerated) for the Imagine 128, Ticket 2 Ride, Revolu- tion 3D and Revolution IV is provided by the "i128" driver. Summary: - All hardware supported in 3.3.6 is also supported in 4.2.0. + All hardware supported in 3.3.6 is also supported in 4.3.0. -24. Oak Technologies, Inc. +25. Oak Technologies, Inc. 3.3.6: Support for the OTI067, OTI077, and OTI087 (the latter with some acceleration) is provided by the XF86_SVGA server and the oak driver. - 4.2.0: + 4.3.0: No Oak chips are supported, because the old driver has not been ported. Summary: - No Oak chips are supported in 4.2.0. + No Oak chips are supported in 4.3.0. -25. Paradise/Western Digital +26. Paradise/Western Digital 3.3.6: Support for the Paradise PVGA1 and the Western Digital WD90C00, @@ -436,14 +444,14 @@ architectures known to work on (e.g., Alpha, PPC), etc. port for some of these chipsets is uncertain because we don't have any recent test reports, and this driver has no maintainer. - 4.2.0: + 4.3.0: No Paradise/Western Digital chips are supported, because the old driver has not been ported. Summary: - No Paradise/Western Digital chips are supported in 4.2.0. + No Paradise/Western Digital chips are supported in 4.3.0. -26. RealTek +27. RealTek 3.3.6: Support for the RealTek RTG3106 is provided by the XF86_SVGA @@ -451,27 +459,27 @@ architectures known to work on (e.g., Alpha, PPC), etc. unknown because we don't have any recent test reports, and this driver has no maintainer. - 4.2.0: + 4.3.0: No RealTek chips are supported, because the old driver has not been ported. Summary: - No RealTek chips are supported in 4.2.0. + No RealTek chips are supported in 4.3.0. -27. Rendition/Micron +28. Rendition/Micron 3.3.6: Support for the Verite 1000, 2100 and 2200 is provided by the XF86_SVGA server with the rendition driver. - 4.2.0: + 4.3.0: Support for the Verite 1000, 2100 and 2200 is provided by the "rendition" driver. Summary: - All hardware supported in 3.3.6 is also supported in 4.2.0. + All hardware supported in 3.3.6 is also supported in 4.3.0. -28. S3 +29. S3 3.3.6: Support (accelerated) for the S3 911, 924, 801, 805, 928, 864, @@ -486,7 +494,7 @@ architectures known to work on (e.g., Alpha, PPC), etc. Savage4, and Savage2000, is provided by the XF86_SVGA server with the s3_savage driver on some OSes (Linux, *BSD). - 4.2.0: + 4.3.0: Support (accelerated) for the 964 (revisions 0 and 1), 968, Trio32, Trio64, Trio64, Trio64V+, Trio64UV+, Aurora64V+, Trio64V2, and PLATO/PX is provided by the "s3" driver (however, @@ -500,61 +508,62 @@ architectures known to work on (e.g., Alpha, PPC), etc. yet been ported. Summary: - All hardware supported in 3.3.6 is also supported in 4.2.0 except + All hardware supported in 3.3.6 is also supported in 4.3.0 except for the 911, 924, 801, 805, 928, 864, and 868, and versions of the 964 and 968 that do not use the RAMDAC chips listed above. - The SuperSavage chipset is supported only in 4.2.0. + The SuperSavage chipset is supported only in 4.3.0. -29. Silicon Graphics, Inc. (SGI) +30. Silicon Graphics, Inc. (SGI) 3.3.6: No SGI hardware is supported in 3.3.6. - 4.2.0: + 4.3.0: Unaccelerated support for the SGI Indy's Newport (a.k.a. "XL") cards is provided by the "newport" driver. Summary: - SGI hardware is supported only in 4.2.0. + SGI hardware is supported only in 4.3.0. -30. Silicon Integrated Systems (SiS) +31. Silicon Integrated Systems (SiS) 3.3.6: Support (accelerated) for the SiS 86C201, 86C202, 86C205, 86C215, 86C225, 5597, 5598, 6326, 530, 620, 300, 630 and 540 is provided by the XF86_SVGA server with the sis driver. - 4.2.0: - Support (accelerated) for the SiS - 530, 620, 6326 is provided by the "sis" driver. The 630, 300, - and 540 are also supported, but this code is new and there are - some problems with it in this version. + 4.3.0: + Support (accelerated) for the SiS 5597, 5598, 6326, 530, 620, + 300, 540, 630, 730, 315, 550, 650, 651 and 740 is provided by the + "sis" driver. The Xabre (SiS 330) might be supported by this is + completely untested. Summary: - Support for the 86C201, 86C202, 86C205, 86C215, 86C225, 5597 and - 5598 is currently only available in 3.3.6. + Support for the 86C201, 86C202, 86C205, 86C215 and 86C225 is cur- + rently only available in 3.3.6. Support for some newer chipsets + is only available in 4.3.0. -31. Silicon Motion, Inc. +32. Silicon Motion, Inc. 3.3.6: Support (accelerated) for the Lynx, LynxE, Lynx3D, LynxEM, LynxEM+ and Lynx3DM chips is provided by the XF86_SVGA server with the smi driver. - 4.2.0: + 4.3.0: Support (accelerated) for the Lynx, LynxE, Lynx3D, LynxEM, LynxEM+ and Lynx3DM chips is provided by the "siliconmotion" driver. Summary: - All hardware supported in 3.3.6 is also supported in 4.2.0. + All hardware supported in 3.3.6 is also supported in 4.3.0. -32. Sun Microsystems +33. Sun Microsystems 3.3.6: No Sun hardware is supported in 3.3.6. - 4.2.0: + 4.3.0: Sun BW2 framebuffers are supported by the "sunbw2" driver. Sun CG3 framebuffers are supported by the "suncg3" driver. Sun CG6 framebuffers are supported by the "suncg6" driver. Sun CG14 @@ -564,9 +573,9 @@ architectures known to work on (e.g., Alpha, PPC), etc. framebuffers are supported by the "suntcx" driver. Summary: - Sun hardware is supported only in 4.2.0. + Sun hardware is supported only in 4.3.0. -33. Trident Microsystems +34. Trident Microsystems 3.3.6: Support (accelerated where the chip supports it) for the @@ -579,7 +588,7 @@ architectures known to work on (e.g., Alpha, PPC), etc. CyberBlade/DSTN/i7, CyberBlade/i1, and CyberBlade/i7 is provided by the XF86_SVGA server with the tvga8900 driver. - 4.2.0: + 4.3.0: Support (accelerated where the chip supports it) for the TVGA8900B, TVGA8900C, TVGA8900CL, TVGA9000, TVGA9000i, TVGA9100B, TVGA9200CXr, TVGA8900D, TGUI9440AGi, TGUI9660, TGUI9680, ProVidia @@ -593,9 +602,7 @@ architectures known to work on (e.g., Alpha, PPC), etc. Summary: The following (older) chipsets are supported in 3.3.6 and not in - 4.2.0: TVGA8200LX, TVGA8800CS, TVGA8900B, TVGA8900C, TVGA8900CL, - TVGA9000, TVGA9000i, TVGA9100B, TVGA9200CXr, TGUI9400CXi, - TGUI9420, and TGUI9430DGi. + 4.3.0: TVGA8200LX, TVGA8800CS, TGUI9420, TGUI9430DGi. The TVGA8900B, TVGA8900C, TVGA8900CL, TVGA9000, TVGA9000i, TVGA9100B, TVGA9200CXr, TGUI9400CXi, TGUI9440AGi, TGUI9660, @@ -603,12 +610,12 @@ architectures known to work on (e.g., Alpha, PPC), etc. Blade3D, Cyber9320, Cyber9382, Cyber9385, Cyber9388, Cyber9397, Cyber9397/DVD, CyberBlade/DSTN/i1, CyberBlade/DSTN/i7, CyberBlade/i1 and CyberBlade/i7 are supported in both 3.3.6 and - 4.2.0. + 4.3.0. The CyberBlade/Ai1, CyberBlade/DSTN/Ai1, CyberBlade/e4, - CyberBladeXP, and BladeXP are supported only in 4.2.0. + CyberBladeXP, and BladeXP are supported only in 4.3.0. -34. Tseng Labs +35. Tseng Labs 3.3.6: Support for the ET3000 is provided by the XF86_SVGA server with @@ -618,16 +625,16 @@ architectures known to work on (e.g., Alpha, PPC), etc. driver. Support (accelerated) for the ET4000/W32 series and the ET6000 is also provided by the deprecated XF86_W32 server. - 4.2.0: + 4.3.0: Support for the ET4000AX, and accelerated support for the ET4000/W32, ET4000/W32i, ET4000/W32p, ET6000 and ET6100 is pro- vided by the "tseng" driver. Summary: - All cards supported by 3.3.6 are also supported by 4.2.0 except + All cards supported by 3.3.6 are also supported by 4.3.0 except for the old ET3000. -35. Video 7 +36. Video 7 3.3.6: Support for the Video 7 chipset is provided by the XF86_SVGA @@ -635,28 +642,28 @@ architectures known to work on (e.g., Alpha, PPC), etc. unknown because we don't have any recent test reports, and this driver has no maintainer. - 4.2.0: + 4.3.0: No Video 7 chips are supported, because the old driver has not been ported. Summary: - No Video 7 chips are supported in 4.2.0. + No Video 7 chips are supported in 4.3.0. -36. Weitek +37. Weitek 3.3.6: Support (accelerated) for the P9000 is provided by the XF86_P9000 server and accelerated support for the P9100 is provided by the XF86_SVGA server with the p9x00 driver. - 4.2.0: + 4.3.0: No Weitek chips are supported, because the old drivers have not been ported. Summary: - No Weitek chips are supported in 4.2.0. + No Weitek chips are supported in 4.3.0. - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Status.sgml,v 1.37 2002/01/16 20:38:45 dawes Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Status.sgml,v 1.43 2003/02/25 16:32:41 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/Status,v 1.29 2002/01/16 20:51:04 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/Status,v 1.40 2003/02/25 21:32:35 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/Versions b/xc/programs/Xserver/hw/xfree86/doc/Versions index 382183cf4..f1491b2fd 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/Versions +++ b/xc/programs/Xserver/hw/xfree86/doc/Versions @@ -2,7 +2,7 @@ The XFree86 Project, Inc - 16 January 2002 + 23 February 2003 Abstract @@ -16,9 +16,9 @@ As of the release of version 4.0.2 in December 2000, XFree86 has three release branches. First is trunk of the CVS repository. This is the main development stream, where all new work and work for future releases is done. -Second is the stable bugfix branch for the latest full release (4.2.0). It +Second is the stable bugfix branch for the latest full release (4.3.0). It is created around the time of the release. The branch for this one is called -"xf-4_2-branch". Fixes for bugs found in the release will be added to this +"xf-4_3-branch". Fixes for bugs found in the release will be added to this branch (as well as the trunk), and updates to this release (if any) will be cut from this branch. Similar stable branches are present for previous full releases. @@ -28,21 +28,21 @@ While this branch is not actively being maintained, it does include some important post-3.3.6 bug fixes and security updates. Relevant security updates in particular are usually back-ported to this branch. -XFree86 is planning to make full releases from the main development stream -approximately every six months, in late May and November of each year. The -feature freezes for these releases will be 1 April and 1 October respec- -tively. These are target dates, not a binding commitment. How effectively -these dates can be met will depend to a large degree on the resource avail- -able to XFree86. Full releases consist of full source code tarballs, plus -full binary distributions for a range of supported platforms. Update/bugfix -releases will be made on an as-required basis, depending also on the avail- -ability of resources. Update/bugfix releases will not be full releases, and -will consist of source code patches, plus binary updates to be layered on top -of the previous full release. - -The next full release will be version 4.3.0, tentatively scheduled for late -May 2002. There is no scheduled update release. If there is one, the ver- -sion will be 4.2.1. +XFree86 is planning to make full releases from the main development stream at +regular intervals in the 6-12 month range. The feature freezes for these +releases will usually be 2-3 months before the release dates. This general +plan is a goal, not a binding commitment. The actual release intervals and +dates will depend to a large degree on the resource available to XFree86. +Full releases consist of full source code tarballs, plus full binary distri- +butions for a range of supported platforms. Update/bugfix releases will be +made on an as-required basis, depending also on the availability of +resources, and will generally be limited to serious bug and security fixes. +New features will not usually be added in update releases. Update/bugfix +releases will not be full releases, and will consist of source code patches, +plus binary updates to be layered on top of the previous full release. + +The next full release will be version 4.4.0. There is no scheduled update +release, but if one is needed, the version will be 4.3.1. Aside from actual releases, snapshots of the active release branches are tagged in the CVS repository from time to time. Each such snapshot has an @@ -338,7 +338,7 @@ VendorRelease information can be interpreted. } } - Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Versions.sgml,v 1.2 2002/01/16 20:38:45 dawes Exp $ + Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Versions.sgml,v 1.4 2003/02/24 03:41:23 dawes Exp $ -$XFree86: xc/programs/Xserver/hw/xfree86/doc/Versions,v 1.3 2002/01/16 20:51:04 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/Versions,v 1.7 2003/02/24 04:03:25 dawes Exp $ diff --git a/xc/programs/Xserver/hw/xfree86/doc/man/Imakefile b/xc/programs/Xserver/hw/xfree86/doc/man/Imakefile index 74b2ab03e..614c73249 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/man/Imakefile +++ b/xc/programs/Xserver/hw/xfree86/doc/man/Imakefile @@ -1,4 +1,4 @@ -XCOMM $XFree86: xc/programs/Xserver/hw/xfree86/doc/man/Imakefile,v 3.7 2002/10/12 16:06:43 herrb Exp $ +XCOMM $XFree86: xc/programs/Xserver/hw/xfree86/doc/man/Imakefile,v 3.8 2002/12/22 00:46:53 dawes Exp $ MANDIR = $(LIBMANDIR) MANSUFFIX = $(LIBMANSUFFIX) @@ -25,5 +25,5 @@ InstallManPageAliases(XF86Misc,$(MANDIR),XF86MiscQueryExtension XF86MiscQueryVer InstallManPageLong(XF86VM,$(MANDIR),XF86VidMode) #if ExpandManNames -InstallManPageAliases(XF86VidMode,$(MANDIR),XF86VidModeQueryExtension XF86VidModeQueryVersion XF86VidModeGetModeLine XF86VidModeGetAllModeLines XF86VidModeDeleteModeLine XF86VidModeModModeLine XF86VidModeSwitchMode XF86VidModeSwitchToMode XF86VidModeLockModeSwitch XF86VidModeGetMonitor XF86VidModeGetViewPort XF86VidModeSetViewPort XF86VidModeValidateModeLine XF86VidModeSetClientVersion XF86VidModeGetDotClocks XF86VidModeGetGamma XF86VidModeSetGamma XF86VidModeSetGammaRamp XF86VidModeGetGammaRamp XF86VidModeGetGammaRampSize) +InstallManPageAliases(XF86VidMode,$(MANDIR),XF86VidModeQueryExtension XF86VidModeQueryVersion XF86VidModeGetModeLine XF86VidModeGetAllModeLines XF86VidModeDeleteModeLine XF86VidModeModModeLine XF86VidModeSwitchMode XF86VidModeSwitchToMode XF86VidModeLockModeSwitch XF86VidModeGetMonitor XF86VidModeGetViewPort XF86VidModeSetViewPort XF86VidModeValidateModeLine XF86VidModeSetClientVersion XF86VidModeGetDotClocks XF86VidModeGetGamma XF86VidModeSetGamma XF86VidModeSetGammaRamp XF86VidModeGetGammaRamp XF86VidModeGetGammaRampSize XF86VidModeGetPermissions) #endif diff --git a/xc/programs/Xserver/hw/xfree86/doc/man/XF86DGA.man b/xc/programs/Xserver/hw/xfree86/doc/man/XF86DGA.man index b4c98f739..e8b1a7b33 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/man/XF86DGA.man +++ b/xc/programs/Xserver/hw/xfree86/doc/man/XF86DGA.man @@ -1,5 +1,5 @@ .\" Copyright (c) 1996 The XFree86 Project -.\" $XFree86: xc/programs/Xserver/hw/xfree86/doc/man/XF86DGA.man,v 3.8 2001/02/07 22:35:22 tsi Exp $ +.\" $XFree86: xc/programs/Xserver/hw/xfree86/doc/man/XF86DGA.man,v 3.9 2002/12/22 00:46:53 dawes Exp $ .\" $TOG: XF86DGA.man /main/9 1997/11/11 12:08:52 kaleb $ .\" .de ZN @@ -195,7 +195,7 @@ The function returns the lowest numbered error and event values assigned to the extension. .SH SEE ALSO -XFree86(1), XF86Config(4/5) +XFree86(1), XF86Config(__filemansuffix__) .SH AUTHORS Jon Tombs, Harm Hanemaayer, Mark Vojkovich. diff --git a/xc/programs/Xserver/hw/xfree86/doc/man/XF86Misc.man b/xc/programs/Xserver/hw/xfree86/doc/man/XF86Misc.man index b225dc8ef..f9f9891ca 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/man/XF86Misc.man +++ b/xc/programs/Xserver/hw/xfree86/doc/man/XF86Misc.man @@ -4,7 +4,7 @@ .\" .\" Copyright (c) 1996 Joe Moss, The XFree86 Project .\" -.\" $XFree86: xc/programs/Xserver/hw/xfree86/doc/man/XF86Misc.man,v 3.11 2001/02/07 22:35:22 tsi Exp $ +.\" $XFree86: xc/programs/Xserver/hw/xfree86/doc/man/XF86Misc.man,v 3.12 2002/12/22 00:46:54 dawes Exp $ .de ZN .ie t \fB\^\\$1\^\fR\\$2 .el \fI\^\\$1\^\fP\\$2 @@ -210,7 +210,7 @@ Keyboard types .IP \fBMF_\fP* 1i Mouse flags .SH "SEE ALSO" -xset(1) +xset(1), XF86Config(__filemansuffix__) .SH AUTHORS Joe Moss and David Dawes, The XFree86 Project, Inc. diff --git a/xc/programs/Xserver/hw/xfree86/doc/man/XF86VM.man b/xc/programs/Xserver/hw/xfree86/doc/man/XF86VM.man index cccca39f4..c7d83f242 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/man/XF86VM.man +++ b/xc/programs/Xserver/hw/xfree86/doc/man/XF86VM.man @@ -4,7 +4,7 @@ .\" .\" .\" Copyright (c) 1996 Joe Moss, The XFree86 Project -.\" $XFree86: xc/programs/Xserver/hw/xfree86/doc/man/XF86VM.man,v 3.11 2002/10/12 16:06:43 herrb Exp $ +.\" $XFree86: xc/programs/Xserver/hw/xfree86/doc/man/XF86VM.man,v 3.12 2002/12/22 00:46:54 dawes Exp $ .\" .de ZN .ie t \fB\^\\$1\^\fR\\$2 @@ -12,7 +12,7 @@ .. .TH XF86VIDMODE 3X11 __vendorversion__ "X FUNCTIONS" .SH NAME -XF86VidModeQueryExtension, XF86VidModeQueryVersion, XF86VidModeSetClientVersion, XF86VidModeGetModeLine, XF86VidModeGetAllModeLines, XF86VidModeDeleteModeLine, XF86VidModeModModeLine, XF86VidModeValidateModeLine, XF86VidModeSwitchMode, XF86VidModeSwitchToMode, XF86VidModeLockModeSwitch, XF86VidModeGetMonitor, XF86VidModeGetViewPort, XF86VidModeSetViewPort, XF86VidModeGetDotClocks, XF86VidModeGetGamma, XF86VidModeSetGamma, XF86VidModeGetGammaRamp, XF86VidModeSetGammaRamp, XF86VidModeGetGammaRampSize \- XFree86-VidMode extension interface functions +XF86VidModeQueryExtension, XF86VidModeQueryVersion, XF86VidModeSetClientVersion, XF86VidModeGetModeLine, XF86VidModeGetAllModeLines, XF86VidModeDeleteModeLine, XF86VidModeModModeLine, XF86VidModeValidateModeLine, XF86VidModeSwitchMode, XF86VidModeSwitchToMode, XF86VidModeLockModeSwitch, XF86VidModeGetMonitor, XF86VidModeGetViewPort, XF86VidModeSetViewPort, XF86VidModeGetDotClocks, XF86VidModeGetGamma, XF86VidModeSetGamma, XF86VidModeGetGammaRamp, XF86VidModeSetGammaRamp, XF86VidModeGetGammaRampSize, XF86VidModeGetPermissions \- XFree86-VidMode extension interface functions .SH SYNTAX .nf .LP @@ -404,10 +404,12 @@ XF86VidModeGetGamma, XF86VidModeSetGamma, XF86VidModeSetGammaRamp, XF86VidModeGetGammaRamp, +XF86VidModeGetGammaRampSize, and -XF86VidModeGetGammaRampSize -functions need to be documented. +XF86VidModeGetPermissions +functions need to be documented. In the meantime, check the source +code for information about how to use them. .SH SEE ALSO -XFree86(1), XF86Config(4/5), xvidtune(1) +XFree86(1), XF86Config(__filemansuffix__), xvidtune(1) .SH AUTHORS Kaleb Keithley, Jon Tombs, David Dawes, and Joe Moss diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/BUILD.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/BUILD.sgml index fe47754b5..f2f3bfa1e 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/BUILD.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/BUILD.sgml @@ -5,7 +5,11 @@ <article> <title>Building XFree86 from a Source Distribution <author>David Dawes, Matthieu Herrb -<Date>27 May 2001 +<Date>26 February 2003 + +<ident> +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/BUILD.sgml,v 3.11 2003/02/27 01:17:36 dawes Exp $ +</ident> <abstract> This document describes how to build XFree86 from the <bf>source</bf> @@ -27,35 +31,53 @@ We highly recommend using gcc to build XFree86, but it generally also builds with the native compiler for each platform; <sect>How to get the XFree86 &relvers; source - <p> -There are a few starting points for getting the XFree86 source. One option -is to start directly with the XFree86 &fullrelvers; source -distribution<![ %updaterel; [ and updating it to &relvers; with a source -patch]]>. In this -case, the procedure is as follows: + +The recommended way of getting the XFree86 &relvers; source is to +get it directly from the XFree86 CVS repository. There are several +ways of doing that, and they are described at our <url name="CVS web page" +url="http://www.xfree86.org/cvs/"> The CVS tag for this release is +"<tt>&reltag;</tt>", and the tag for the maintenance branch for this +release is "<tt>&relbranchtag;</tt>". + +<![ %notsnapshot; [ +Another method of getting the XFree86 &relvers; source is to +either download the &fullrelvers; source tarballs from the XFree86 ftp +site<![ %updaterel; [ and the source patch that updates &fullrelvers; to +&relvers]]>. The procedure for this is as follows: <itemize> - <item>The XFree86 source is contained in files - <tt>X&fullsrcvers;src-1.tgz</tt>, <tt>X&fullsrcvers;src-2.tgz</tt> - and <tt>X&fullsrcvers;src-3.tgz</tt>. These can be found at + <item>The XFree86 &fullrelvers; source is contained in the files + <tt>X&fullsrcvers;src-1.tgz</tt>, <tt>X&fullsrcvers;src-2.tgz</tt>, + <tt>X&fullsrcvers;src-3.tgz</tt>, <tt>X&fullsrcvers;src-4.tgz</tt>, + <tt>X&fullsrcvers;src-5.tgz</tt>, <tt>X&fullsrcvers;src-6.tgz</tt> + and <tt>X&fullsrcvers;src-7.tgz</tt>. These can be found at <htmlurl name="ftp://ftp.xfree86.org/pub/XFree86/&fullrelvers;/source/" url="ftp://ftp.xfree86.org/pub/XFree86/&fullrelvers;/source/"> and similar locations on XFree86 mirror sites. - <tt>X&fullsrcvers;src-2.tgz</tt> contains the fonts and - documentation source. <tt>X&fullsrcvers;src-3.tgz</tt> contains - the hardcopy documentation. <tt>X&fullsrcvers;src-1.tgz</tt> - contains everything else. If you don't need the docs or fonts - you can get by with only <tt>X&fullsrcvers;src-1.tgz</tt>. + <tt>X&fullsrcvers;src-4.tgz</tt> and + <tt>X&fullsrcvers;src-5.tgz</tt> contains the fonts. + <tt>X&fullsrcvers;src-6.tgz</tt> contains the documentation + source. <tt>X&fullsrcvers;src-7.tgz</tt> contains the hardcopy + documentation. <tt>X&fullsrcvers;src-1.tgz</tt>, + <tt>X&fullsrcvers;src-2.tgz</tt> and + <tt>X&fullsrcvers;src-3.tgz</tt> contains everything else. If + you don't need the docs or fonts you can get by with only + <tt>X&fullsrcvers;src-1.tgz</tt>, <tt>X&fullsrcvers;src-2.tgz</tt> + and <tt>X&fullsrcvers;src-3.tgz</tt>. <item>Extract each of these files by running the following from a directory on a filesystem containing enough space (the full source requires - around 270MB, and a similar amount is required in addition to this + around 305MB, and a similar amount is required in addition to this for the compiled binaries): <quote><tt> gzip -d < X&fullsrcvers;src-1.tgz | tar vxf -<newline> gzip -d < X&fullsrcvers;src-2.tgz | tar vxf -<newline> gzip -d < X&fullsrcvers;src-3.tgz | tar vxf -<newline> + gzip -d < X&fullsrcvers;src-4.tgz | tar vxf -<newline> + gzip -d < X&fullsrcvers;src-5.tgz | tar vxf -<newline> + gzip -d < X&fullsrcvers;src-6.tgz | tar vxf -<newline> + gzip -d < X&fullsrcvers;src-7.tgz | tar vxf -<newline> </tt></quote> <![ %updaterel; [ @@ -71,34 +93,64 @@ case, the procedure is as follows: gzip -d < &fullrelvers;-&relvers;.diff.gz | patch -s -p0 -E </tt> </quote> - Look for special patching instructions in the <htmlurl name="Release - Notes" url="http://www.xfree86.org/&relvers;/RELNOTES.html">. + Look for special patching instructions in the "How to get XFree86" + section of the <htmlurl name="README" url="README.html"> for + this release. ]]> </itemize> -Another option is to get the source by anonymous CVS or CVSup. -See <htmlurl name="http://www.xfree86.org/cvs/" -url="http://www.xfree86.org/cvs/"> for details on the different -procedure available. +<![ %fullrel; [ +Alternatively, if you already have a pristine copy of the XFree86 +&prevfullrelvers; source, you can download patches from +<htmlurl name="ftp://ftp.xfree86.org/pub/XFree86/&relvers;/patches/" +url="ftp://ftp.xfree86.org/pub/XFree86/&relvers;/patches/"> that will allow +you to convert it to &relvers;. Information about which patch files to +download and how to apply them can be found in the "How to get XFree86" +section of the <htmlurl name="README" url="README.html"> for this release. +]]> All methods will produce one main source directory called <tt>xc</tt>. +]]> + +<![ %snapshot; [ +<p> +The source for the XFree86 &relvers; snapshot is available from the XFree86 +CVS repository. See See <htmlurl name="http://www.xfree86.org/cvs/" +url="http://www.xfree86.org/cvs/"> for details. The tag for this snapshot +is "&reltag;". To get the current development version, don't specify any +tag. +]]> + <sect>Configuring the source before building <p> -It is recommended that you start the configuration process by going to the -<tt>xc/config/cf</tt> directory, and copying the file <tt>xf86site.def</tt> -to <tt>host.def</tt>. Then read through the <tt>host.def</tt> file -(which is heavily commented), and set any parameters that you want for -your configuration. You can usually find out what the default settings -are by checking the <tt>.cf</tt> file(s) relevant to your OS. - -Unlike previous versions, imake can now automatically detect and set -the various <bf>OS*Version</bf> parameters, so you shouldn't need to -enter those settings explicitly. - -If you are using just the <tt>X&srcvers;src-1.tgz</tt> part of the -source dist, you will need to define <bf>BuildFonts</bf> to +In most cases it shouldn't be necessary to configure anything before building. + +If you do want to make configuration changes, it is recommended that +you start by going to the <tt>xc/config/cf</tt> directory, and copying +the file <tt>xf86site.def</tt> to <tt>host.def</tt>. Then read through +the <tt>host.def</tt> file (which is heavily commented), and set any +parameters that you want for your configuration. You can usually find +out what the default settings are by checking the <tt>.cf</tt> file(s) +relevant to your OS. + +A general rule to follow is to only change things that you understand +and have a good reason to change. It is easy to create build problems +by changing the default configuration. Many of the configuration +parameters are documented in <tt>xc/config/cf/README</tt>. + +<!-- +There's also +a section <ref name="below" id="config_params"> with information about +some configuration settings. +--> + +<![ %notsnapshot; [ +If you are using just the <tt>X&srcvers;src-1.tgz</tt>, +<tt>X&srcvers;src-2.tgz</tt> and <tt>X&srcvers;src-3.tgz</tt> parts of +the source dist, you will need to define <bf>BuildFonts</bf> to <bf>NO</bf>. +]]> <sect>Using a shadow directory of symbolic links for the build <p> @@ -110,10 +162,11 @@ unmodified during the build, which has the following benefits: date, the update process is not disturbed by foreign files not under the control of CVS. <item>It is possible to build XFree86 for several different Operating -System or architectures from the same sources, shared by NFS. +System or architectures from the same sources, shared by read-only NFS +mounts. <item>It is possible to build XFree86 with different configuration -options, just by putting a real copy<tt>host.def</tt> in each build -tree and by customizing it separately in each build tree. +options, just by putting a real copy of the <tt>host.def</tt> file in +each build tree and by customizing it separately in each build tree. </itemize> <p> To make a shadow directory of symbolic links, use the following steps: @@ -125,15 +178,16 @@ not mandatory. cd <em>the directory containing the </em>xc<em>directory</em><newline> mkdir build </tt></quote> -<item>use the <tt>lndir</tt>command to make the shadow tree: +<item>use the "<tt>lndir</tt>" command to make the shadow tree: <quote><tt> lndir ../xc </tt></quote> Note that you can refer to the <tt>xc</tt> directory with an absolute path if needed. <p> -See the <htmlurl name="lndir(1) manual page" -url="http://www.xfree86.org/&relvers;/lndir.1.html"> for details. +See the <htmlurl name="lndir(1)" +url="http://www.xfree86.org/&relvers;/lndir.1.html"> manual page for +details. </itemize> If <tt>lndir</tt> is not already installed on your system, you can build it manually from the XFree86 sources by running the following @@ -144,6 +198,15 @@ make -f Makefile.ini lndir<newline> cp lndir <em>some directory in your PATH</em> </tt></quote> +From time to time there may be some stale links in the build tree, for +example, when files in the source tree are removed or renamed. These can +be cleaned up by running the "<tt>cleanlinks</tt>" script from the build +directory (see the <htmlurl name="cleanlinks(1)" url="cleanlinks.1.html"> +manual page). Rarely there will be changes that will require the build +tree to be re-created from scratch. A symptom of this can be mysterious +build problems. The best solution for this is to remove the build tree, +and then re-create it using the steps outlined above. + <sect>Building and installing the distribution <p> Before building the distribution, read through the OS-specific <tt/README/ @@ -151,7 +214,7 @@ file in <tt>xc/programs/Xserver/hw/xfree86/doc</tt> that is relevant to you. Once those OS-specific details have been taken care of, go your build directory (either the <tt/xc/ directory or the shadow tree created before) and -run ``<tt/make World/'' with the <bf/BOOTSTRAPCFLAGS/ +run "<tt/make World/" with the <bf/BOOTSTRAPCFLAGS/ set as described in the OS-specific README (if necessary, but most systems supported by XFree86 don't need <bf/BOOTSTRAPCFLAGS/). It is advisable to redirect stdout and stderr to <tt/World.Log/ so that you @@ -172,15 +235,34 @@ tail -f World.log </tt></quote> in a terminal. <p> -When the build is finished, you should check <tt/World.Log/ to see -if there were any problems. If there weren't any then you can install -the binaries. -To do -the install, run ``<tt/make -install/'' and ``<tt/make install.man/''. Make sure you have enough -space in <tt>/usr/X11R6</tt> for the install to succeed. If you want -to install on a filesystem other than <tt>/usr</tt>, make a symbolic -link to <tt>/usr/X11R6</tt> before installing. +When the build is finished, you should check the <tt/World.Log/ file to +see if there were any problems. If there weren't any then you can +install the binaries. By default the "make World" process will ignore +errors and build as much as possible. If there were problems and they +are not corrected at this stage, the installation process will fail. +To restart the build process after correcting the problems, just +run 'make'. If Imakefiles or part of the build configuration was +changed as part of correcting the problem, either re-run "make World", +or run "make Everything". + +If you would prefer "make World" to exit at the first error, run it in the +following way instead of the way described above: + +for Bourne-like shells: +<quote><tt> +make WORLDOPTS= World > World.log 2>&1 +</tt></quote> +for C-shell variants: +<quote><tt> +make WORLDOPTS= World >& World.log +</tt></quote> + +To do the install, run "<tt/make install/" and "<tt/make install.man/". +Make sure you have enough space in <tt>/usr/X11R6</tt> for the install +to succeed. If you want to install on a filesystem other than +<tt>/usr</tt>, make a symbolic link to <tt>/usr/X11R6</tt> before +installing. + <sect>Reconfiguring the server (source distribution) <p> @@ -199,7 +281,7 @@ wish to build. Also, change the driver lists to suit your needs. <tscreen><verb> make Makefile make Makefiles - make includes + make includes make depend make </verb></tscreen> @@ -210,7 +292,7 @@ wish to build. Also, change the driver lists to suit your needs. <tt>Makefile</tt>of XFree86: <itemize> <item><bf/Everything/ after a <tt>make World</tt>, <tt>make -Everything</tt>does everything a <tt>make World</tt> does, except the +Everything</tt> does everything a <tt>make World</tt> does, except the cleaning of the tree. It is a way to quickly rebuild the tree after a source patch, but it is not 100% bullet proof. There are cases were it is better to force a full build by using <tt>make World</tt>. @@ -245,12 +327,15 @@ produced by <tt>make includes</tt>. <item><bf/VerifyOS/ displays the detected operating system version. If the numbers shown do not match your system, you probably need to set them manually in <tt>host.def</tt> and report the problem to -XFree86@XFree86.org. +<email>XFree86@XFree86.org</email>. </itemize> -<verb> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/BUILD.sgml,v 3.7 2002/09/04 03:31:10 dawes Exp $ -</verb> +<!-- +<sect>Various Configuration settings<label id="config_params"> +<p> + +Fill in this section. +--> </article> diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml index 3310d3437..322ab00e0 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml @@ -27,7 +27,7 @@ <title>XFree86 X server ``New Design'' (DRAFT) <author>The XFree86 Project, Inc -<date>Last modified 18 May 2002 +<date>Last modified 2003 January 22 @@ -36,7 +36,7 @@ <ident> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml,v 1.49 2002/05/18 20:52:22 herrb Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml,v 1.52 2003/02/25 19:31:00 dawes Exp $ </ident> @@ -369,31 +369,31 @@ mechanism for this. cards. Currently HOST-PCI bridges are not yet handled by RAC as they require specific drivers. -<sect2>Entity +<sect2>Entity <p> The smallest independently addressable unit on a system bus is referred to as an entity. So far we know ISA and PCI entities. PCI entities can be located on the PCI bus by an unique ID consisting of the bus, card and function number. - + <sect2>Resource <p> - + ``Resource'' refers to a range of memory or I/O addresses an entity can decode. - + If a device is capable of disabling this decoding the resource is called sharable. For PCI devices a generic method is provided to control resource decoding. Other devices will have to provide a device specific function to control decoding. - + If the entity is capable of decoding this range at a different location this resource is considered relocatable. Resources which start at a specific address and occupy a single continuous range are called block resources. - + Alternatively resource addresses can be decoded in a way that they satisfy the conditions: <quote><verb> @@ -645,13 +645,13 @@ is what &s.code;InitOutput()&e.code; does: Allocate a &s.code;ScrnInfoRec&e.code; for each active instance of the hardware found, and fill in the basic information, including the - other driver entry points. This is best done with the - &s.code;xf86ConfigIsaEntity()&e.code; helper function for ISA - instances or &s.code;xf86ConfigPciEntity()&e.code; for PCI instances. + other driver entry points. This is best done with the + &s.code;xf86ConfigIsaEntity()&e.code; helper function for ISA + instances or &s.code;xf86ConfigPciEntity()&e.code; for PCI instances. These functions allocate a &s.code;ScrnInfoRec&e.code; for active entities. Optionally &s.code;xf86AllocateScreen()&e.code; function may also be used to allocate the &s.code;ScrnInfoRec&e.code;. - Any of these functions take care of initialising fields to defined + Any of these functions take care of initialising fields to defined ``unused'' values. Claim the entities for each instance of the hardware found. This @@ -851,12 +851,12 @@ is what &s.code;InitOutput()&e.code; does: Modules may be loaded at any point in this function, and all modules that the driver will need must be loaded before the end - of this function. Either the &s.code;xf86LoadSubModule()&e.code; - or the &s.code;xf86LoadDrvSubModule()&e.code; function should be - used to load modules depending on whether a - &s.code;ScrnInfoRec&e.code; has been set up. A driver may unload - a module within this function if it was only needed temporarily, - and the &s.code;xf86UnloadSubModule()&e.code; function should be used + of this function. Either the &s.code;xf86LoadSubModule()&e.code; + or the &s.code;xf86LoadDrvSubModule()&e.code; function should be + used to load modules depending on whether a + &s.code;ScrnInfoRec&e.code; has been set up. A driver may unload + a module within this function if it was only needed temporarily, + and the &s.code;xf86UnloadSubModule()&e.code; function should be used to do that. Otherwise there is no need to explicitly unload modules because the loader takes care of module dependencies and will unload submodules automatically if/when the driver module is @@ -950,7 +950,7 @@ is what &s.code;InitOutput()&e.code; does: <quote><p> Unloads the module referenced by &s.code;module&e.code;. &s.code;module&e.code; should be a pointer returned previously - by &s.code;xf86LoadSubModule()&e.code; or + by &s.code;xf86LoadSubModule()&e.code; or &s.code;xf86LoadDrvSubModule()&e.code; . </quote> @@ -1871,7 +1871,6 @@ XF86Config file to the devices: <quote><p> &s.code;int xf86MatchPciInstances(const char *driverName, int vendorID, &f.indent;SymTabPtr chipsets, PciChipsets *PCIchipsets, - &f.indent;GDevPtr *devList, int numDevs, &f.indent;GDevPtr *devList, int numDevs, DriverPtr drvp, &f.indent;int **foundEntities)&e.code; <quote><p> @@ -2046,26 +2045,26 @@ available at the driver level: Two helper functions are provided to aid configuring entities: <quote><p> - &s.code;ScrnInfoPtr xf86ConfigPciEntity(ScrnInfoPtr pScrn, - &f.indent;int scrnFlag, int entityIndex, - &f.indent;PciChipsets *p_chip, - &f.indent;resList res, EntityProc init, - &f.indent;EntityProc enter, EntityProc leave, + &s.code;ScrnInfoPtr xf86ConfigPciEntity(ScrnInfoPtr pScrn, + &f.indent;int scrnFlag, int entityIndex, + &f.indent;PciChipsets *p_chip, + &f.indent;resList res, EntityProc init, + &f.indent;EntityProc enter, EntityProc leave, &f.indent;pointer private)&e.code; <p> - &s.code;ScrnInfoPtr xf86ConfigIsaEntity(ScrnInfoPtr pScrn, - &f.indent;int scrnFlag, int entityIndex, + &s.code;ScrnInfoPtr xf86ConfigIsaEntity(ScrnInfoPtr pScrn, + &f.indent;int scrnFlag, int entityIndex, &f.indent;IsaChipsets *i_chip, - &f.indent;resList res, EntityProc init, - &f.indent;EntityProc enter, EntityProc leave, + &f.indent;resList res, EntityProc init, + &f.indent;EntityProc enter, EntityProc leave, &f.indent;pointer private)&e.code; <quote><p> These functions are used to register the non-relocatable resources for an entity, and the optional entity-specific &s.code;Init&e.code;, &s.code;Enter&e.code; and &s.code;Leave&e.code; functions. Usually the list of fixed resources is obtained from the Isa/PciChipsets lists. However an additional list of - resources may be passed. Generally this is not required. - For active entities a &s.code;ScrnInfoRec&e.code; is allocated + resources may be passed. Generally this is not required. + For active entities a &s.code;ScrnInfoRec&e.code; is allocated if the &s.code;pScrn&e.code; argument is &s.code;NULL&e.code;. The return value is &s.code;TRUE&e.code; when successful. The init, enter, leave @@ -2077,9 +2076,9 @@ The </quote> They are passed the entity index and a pointer to a private scratch - area. This are can be set up during &s.code;Probe()&e.code; and + area. This can be set up during &s.code;Probe()&e.code; and its address can be passed to - &s.code;xf86ConfigIsaEntity()&e.code; + &s.code;xf86ConfigIsaEntity()&e.code; and &s.code;xf86ConfigPciEntity()&e.code; as the last argument. </quote> @@ -2118,13 +2117,13 @@ available at the driver level: <sect2>PreInit Phase <p> -During this phase the remaining resource should be registered. +During this phase the remaining resources should be registered. &s.code;PreInit()&e.code; should call &s.code;xf86GetEntityInfo()&e.code; -To obtain a pointer to an &s.code;EntityInfoRec&e.code; for each entity +to obtain a pointer to an &s.code;EntityInfoRec&e.code; for each entity it is able to drive and check if any resource are listed in its &s.code;resources&e.code; field. If resources registered in the Probe phase have been rejected in the post-Probe phase -(&s.code;resources == NULL&e.code;), then the driver should +(&s.code;resources&e.code; is non-&s.code;NULL&e.code;), then the driver should decide if it can continue without using these or if it should fail. <quote><p> @@ -2142,9 +2141,8 @@ Several functions are provided to simplify resource registration: &s.code;Bool xf86IsEntityPrimary(int entityIndex)&e.code; <quote><p> This function returns &s.code;TRUE&e.code; if the entity referenced - by &s.code;entityIndex&e.code; is the display device that primary - display device (i.e., the one initialised at boot time and used - in text mode). + by &s.code;entityIndex&e.code; is the primary display device (i.e., + the one initialised at boot time and used in text mode). </quote> @@ -2193,10 +2191,12 @@ The primary function for registration of resources is: &s.code;resPtr xf86ReallocatePciResources(int entityIndex, resPtr pRes)&e.code; <quote><p> This function takes a list of PCI resources that need to be - reallocated and returns a list of the reallocated resource. This - list needs to be passed to &s.code;xf86RegisterResources()&e.code; again to be - registered with the broker. If the reallocation fails, &s.code;NULL&e.code; is - returned. + reallocated and returns &s.code;NULL&e.code when all relocations are + successful. + &s.code;xf86RegisterResources()&e.code; should be called again to + register the relocated resources with the broker. + If the reallocation fails, a list of the resources that could not be + relocated is returned. </quote> </quote> @@ -2216,7 +2216,7 @@ Two functions are provided to obtain a resource range of a given type: type &s.code;ResEnd&e.code; will be returned. </quote> - &s.code;resRange xf86GetSparse(long type, memType fixed_bits, + &s.code;resRange xf86GetSparse(long type, memType fixed_bits, &f.indent;memType decode_mask, memType address_mask, &f.indent;resPtr avoid)&e.code; <quote><p> @@ -2248,7 +2248,7 @@ The function &s.code;xf86FixPciResource()&e.code; can be used to do this: register that needs to be fixed (&s.code;0-5&e.code;, and &s.code;6&e.code; for the BIOS base register). The size is specified by the alignment. Since PCI resources need to span an - integral range of the size &s.code;2^n&e.code; the alignment also + integral range of size &s.code;2^n&e.code;, the alignment also specifies the number of addresses that will be decoded. If the driver specifies a type mask it can override the default type for PCI resources which is &s.code;ResShared&e.code;. The resource @@ -2270,13 +2270,15 @@ The function &s.code;xf86FixPciResource()&e.code; can be used to do this: </quote> </quote> -The driver may replace the generic access control functions for an entity -by it's own ones. This is done with the &s.code;xf86SetAccessFuncs()&e.code;: +The driver may replace the generic access control functions for an entity. +This is done with the &s.code;xf86SetAccessFuncs()&e.code;: <quote><p> - &s.code;void xf86SetAccessFuncs(EntityInfoPtr pEnt, + &s.code;void xf86SetAccessFuncs(EntityInfoPtr pEnt, &f.indent;xf86SetAccessFuncPtr funcs, &f.indent;xf86SetAccessFuncPtr oldFuncs)&e.code; + <quote><p> with: + </quote> <verb> typedef struct { @@ -2295,13 +2297,13 @@ by it's own ones. This is done with the &s.code;xf86SetAccessFuncs()&e.code;: combined access functions are the same it is assumed that I/O can not be controlled independently. If memory and I/O have to be controlled together all three values should be the same. If a - non &s.code;NULL&e.code; value is passed as fifth argument it is + non &s.code;NULL&e.code; value is passed as third argument it is interpreted as an address where to store the old access record. - If the fifth argument is &s.code;NULL&e.code; it will be assumed + If the third argument is &s.code;NULL&e.code; it will be assumed that the generic access should be enabled before replacing the access functions. Otherwise it will be disabled. The driver may enable them itself using the returned values. It should do this - from his replacement access functions as the generic access may + from its replacement access functions as the generic access may be disabled by the common level on certain occasions. If replacement functions are specified they must control all resources of the specific type registered for the entity. @@ -2309,14 +2311,14 @@ by it's own ones. This is done with the &s.code;xf86SetAccessFuncs()&e.code;: </quote> </quote> -To find out if specific resource range is conflicting with another +To find out if a specific resource range conflicts with another resource the &s.code;xf86ChkConflict()&e.code; function may be used: <quote><p> &s.code;memType xf86ChkConflict(resRange *rgp, int entityIndex)&e.code; <quote><p> This function checks if the resource range &s.code;rgp&e.code; of for the specified entity conflicts with with another resource. - If it a conflict is found, the address of the start of the conflict + If a conflict is found, the address of the start of the conflict is returned. The return value is zero when there is no conflict. </quote> @@ -2503,44 +2505,44 @@ Next, the higher level functions that most drivers would use. The &s.code;OptionInfoRec&e.code; is defined as follows: - <verb> - typedef struct { - double freq; - int units; - } OptFrequency; - - typedef union { - unsigned long num; - char * str; - double realnum; - Bool bool; - OptFrequency freq; - } ValueUnion; - - typedef enum { - OPTV_NONE = 0, - OPTV_INTEGER, - OPTV_STRING, /* a non-empty string */ - OPTV_ANYSTR, /* Any string, including an empty one */ - OPTV_REAL, - OPTV_BOOLEAN, - OPTV_FREQ - } OptionValueType; - - typedef enum { - OPTUNITS_HZ = 1, - OPTUNITS_KHZ, - OPTUNITS_MHZ - } OptFreqUnits; - - typedef struct { - int token; - const char* name; - OptionValueType type; - ValueUnion value; - Bool found; - } OptionInfoRec, *OptionInfoPtr; - </verb> + <verb> + typedef struct { + double freq; + int units; + } OptFrequency; + + typedef union { + unsigned long num; + char * str; + double realnum; + Bool bool; + OptFrequency freq; + } ValueUnion; + + typedef enum { + OPTV_NONE = 0, + OPTV_INTEGER, + OPTV_STRING, /* a non-empty string */ + OPTV_ANYSTR, /* Any string, including an empty one */ + OPTV_REAL, + OPTV_BOOLEAN, + OPTV_FREQ + } OptionValueType; + + typedef enum { + OPTUNITS_HZ = 1, + OPTUNITS_KHZ, + OPTUNITS_MHZ + } OptFreqUnits; + + typedef struct { + int token; + const char* name; + OptionValueType type; + ValueUnion value; + Bool found; + } OptionInfoRec, *OptionInfoPtr; + </verb> &s.code;OPTV_FREQ&e.code; can be used for options values that are frequencies. These values are a floating point number with an @@ -2572,7 +2574,9 @@ Next, the higher level functions that most drivers would use. </quote> - &s.code;OptionInfoPtr xf86TokenToOptinfo(const OptionInfoRec *table, int token)&e.code; + &s.code;OptionInfoPtr xf86TokenToOptinfo(const OptionInfoRec *table, + &f.indent;int token)&e.code; + <quote><p> Returns a pointer to the &s.code;OptionInfoRec&e.code; in &s.code;table&e.code; with a token field matching @@ -2712,7 +2716,7 @@ The following include files are typically required by video drivers: &s.code;"compiler.h"&e.code; </quote> Note: in drivers, this must be included after &s.code;"xf86_ansic.h"&e.code;. - + Drivers that need to access PCI vendor/device definitions need this: <quote> &s.code;"xf86PciInfo.h"&e.code; @@ -2778,7 +2782,7 @@ The following include files are typically required by video drivers: &s.code;"xf86fbman.h"&e.code; </quote> </quote> - + Non-driver modules should include &s.code;"xf86_ansic.h"&e.code; to get the correct wrapping of ANSI C/libc functions. @@ -2801,7 +2805,7 @@ included implicitly by "xf86_ansic.h". Management of offscreen video memory may be handled by the XFree86 framebuffer manager. Once the offscreen memory manager is running, drivers or extensions may allocate, free or resize areas of offscreen -video memory using the following functions (definitions taken from +video memory using the following functions (definitions taken from &s.code;xf86fbman.h&e.code;): <code> @@ -2948,7 +2952,7 @@ will remove all removable &s.code;FBArea&e.code; allocations. Initialization of the XFree86 framebuffer manager is done via <quote> - &s.code;Bool xf86InitFBManager(ScreenPtr pScreen, BoxPtr FullBox)&e.code; + &s.code;Bool xf86InitFBManager(ScreenPtr pScreen, BoxPtr FullBox)&e.code; </quote> &s.code;FullBox&e.code; represents the area of the framebuffer that the @@ -3024,9 +3028,9 @@ To use the colormap layer, a driver calls the reload the colormap automatically after mode switches. This is useful for when the driver is resetting the - hardware during mode switches and + hardware during mode switches and corrupting or erasing the hardware - palette. + palette. </quote> @@ -3045,15 +3049,15 @@ To use the colormap layer, a driver calls the The colormap layer normally reloads the palette after VT enters so it is not necessary for the driver to save and restore the palette when switching VTs. The driver must, however, still save the - initial palette during server start up and restore it during - server exit. + initial palette during server start up and restore it during + server exit. </quote> &s.code;void LoadPalette(ScrnInfoPtr pScrn, int numColors, int *indices, &f.indent;LOCO *colors, VisualPtr pVisual)&e.code; <quote><p> - &s.code;LoadPalette()&e.code; is a driver-provide function for + &s.code;LoadPalette()&e.code; is a driver-provided function for loading a colormap into hardware. &s.code;colors&e.code; is the array of RGB values that represent the full colormap. &s.code;indices&e.code; is a list of index values into the colors @@ -3138,29 +3142,29 @@ passing them to DGAInit. /** The DGAModeRec **/ typedef struct { - int num; + int num; DisplayModePtr mode; - int flags; + int flags; int imageWidth; int imageHeight; int pixmapWidth; - int pixmapHeight; - int bytesPerScanline; - int byteOrder; - int depth; + int pixmapHeight; + int bytesPerScanline; + int byteOrder; + int depth; int bitsPerPixel; unsigned long red_mask; unsigned long green_mask; unsigned long blue_mask; int viewportWidth; int viewportHeight; - int xViewportStep; + int xViewportStep; int yViewportStep; - int maxViewportX; + int maxViewportX; int maxViewportY; - int viewportFlags; - int offset; - unsigned char *address; + int viewportFlags; + int offset; + unsigned char *address; int reserved1; int reserved2; } DGAModeRec, *DGAModePtr; @@ -3198,7 +3202,7 @@ typedef struct { &s.code;DGA_PIXMAP_AVAILABLE&e.code; <quote><p> - Indicates that Xlib may be used on the framebuffer. + Indicates that Xlib may be used on the framebuffer. This flag will usually be set unless the driver wishes to prohibit this for some reason. @@ -3211,12 +3215,11 @@ typedef struct { </quote> </quote> - &s.code;imageWidth&nl; imageHeight&e.code; <quote><p> - These are the dimensions of the linear framebuffer + These are the dimensions of the linear framebuffer accessible by the client. </quote> @@ -3245,7 +3248,7 @@ typedef struct { &s.code;depth&e.code; <quote><p> The depth of the framebuffer in this mode. - + </quote> &s.code;bitsPerPixel&e.code; @@ -3274,15 +3277,15 @@ typedef struct { &s.code;xViewportStep&nl; yViewportStep&e.code; <quote><p> - The granularity of x and y viewport positions that - the driver supports in this mode. + The granularity of x and y viewport positions that + the driver supports in this mode. </quote> &s.code;maxViewportX&nl; maxViewportY&e.code; <quote><p> - The maximum viewport position supported by the + The maximum viewport position supported by the driver in this mode. </quote> @@ -3298,7 +3301,7 @@ typedef struct { </quote> &s.code;DGA_FLIP_RETRACE&e.code; <quote<p> - The driver supports viewport changes at retrace. + The driver supports viewport changes at retrace. </quote> </quote> @@ -3306,7 +3309,7 @@ typedef struct { &s.code;offset&e.code; <quote><p> The offset into the linear framebuffer that corresponds to - pixel (0,0) for this mode. + pixel (0,0) for this mode. </quote> @@ -3322,9 +3325,9 @@ typedef struct { typedef struct { Bool (*OpenFramebuffer)( - ScrnInfoPtr pScrn, + ScrnInfoPtr pScrn, char **name, - unsigned char **mem, + unsigned char **mem, int *size, int *offset, int *extra @@ -3335,20 +3338,20 @@ typedef struct { int (*GetViewport)(ScrnInfoPtr pScrn); void (*Sync)(ScrnInfoPtr); void (*FillRect)( - ScrnInfoPtr pScrn, - int x, int y, int w, int h, + ScrnInfoPtr pScrn, + int x, int y, int w, int h, unsigned long color ); void (*BlitRect)( - ScrnInfoPtr pScrn, - int srcx, int srcy, - int w, int h, + ScrnInfoPtr pScrn, + int srcx, int srcy, + int w, int h, int dstx, int dsty ); void (*BlitTransRect)( - ScrnInfoPtr pScrn, - int srcx, int srcy, - int w, int h, + ScrnInfoPtr pScrn, + int srcx, int srcy, + int w, int h, int dstx, int dsty, unsigned long color ); @@ -3496,11 +3499,10 @@ as described later in this document and passing a list of <quote> &s.code;Bool xf86XVScreenInit( - &f.indent;ScreenPtr pScreen, + &f.indent;ScreenPtr pScreen, &f.indent;XF86VideoAdaptorPtr *adaptPtrs, &f.indent;int num)&e.code; </quote> - After doing this, the extension will report video adaptors as being available, providing the data in their respective @@ -3516,13 +3518,13 @@ The &s.code;XF86VideoAdaptorRec&e.code;: <quote><p> <verb> typedef struct { - unsigned int type; + unsigned int type; int flags; char *name; int nEncodings; - XF86VideoEncodingPtr pEncodings; + XF86VideoEncodingPtr pEncodings; int nFormats; - XF86VideoFormatPtr pFormats; + XF86VideoFormatPtr pFormats; int nPorts; DevUnion *pPortPrivates; int nAttributes; @@ -3544,7 +3546,7 @@ typedef struct { Each adaptor will have its own XF86VideoAdaptorRec. The fields are as follows: - + &s.code;type&e.code; <quote><p> This can be any of the following flags OR'd together. @@ -3552,7 +3554,7 @@ typedef struct { &s.code;XvInputMask&e.code; &s.code;XvOutputMask&e.code; <quote><p> - These refer to the target drawable and are similar to a Window's + These refer to the target drawable and are similar to a Window's class. &s.code;XvInputMask&e.code; indicates that the adaptor can put video into a drawable. &s.code;XvOutputMask&e.code; indicates that the adaptor can get video from a drawable. @@ -3596,7 +3598,7 @@ typedef struct { &s.code;VIDEO_INVERT_CLIPLIST&e.code; <quote><p> This indicates that the video driver requires the clip - list to contain the regions which are obscured rather + list to contain the regions which are obscured rather than the regions which are are visible. </quote> @@ -3683,7 +3685,7 @@ typedef struct { &s.code;nImages&nl; pImages&e.code; <quote><p> - The number of &s.code;XF86ImageRecs&e.code; supported by the adaptor + The number of &s.code;XF86ImageRecs&e.code; supported by the adaptor and a pointer to the array of &s.code;XF86ImageRecs&e.code;. The &s.code;XF86ImageRec&e.code; is described later on. @@ -3701,8 +3703,8 @@ typedef struct { <enum> <item>&s.code;PutVideo&e.code;, &s.code;PutStill&e.code; and - the image routines &s.code;PutImage&e.code; and - &s.code;QueryImageAttributes&e.code; are not required when the + the image routines &s.code;PutImage&e.code; and + &s.code;QueryImageAttributes&e.code; are not required when the adaptor type does not contain &s.code;XvInputMask&e.code;. <item>&s.code;GetVideo&e.code; and &s.code;GetStill&e.code; @@ -3725,7 +3727,7 @@ typedef struct { With the exception of &s.code;QueryImageAttributes&e.code;, these functions should return &s.code;Success&e.code; if the operation was - completed successfully. They can return &s.code;XvBadAlloc&e.code; + completed successfully. They can return &s.code;XvBadAlloc&e.code; otherwise. &s.code;QueryImageAttributes&e.code; returns the size of the XvImage queried. @@ -3737,14 +3739,14 @@ typedef struct { by &s.code;drw_x&e.code;, &s.code;drw_y&e.code;, &s.code;drw_w&e.code; and &s.code;drw_h&e.code; in the Get/Put function. The boxes are in screen coordinates, are guaranteed - not to overlap and an empty region will never be passed. + not to overlap and an empty region will never be passed. If the driver has specified &s.code;VIDEO_INVERT_CLIPLIST&e.code;, &s.code;clipBoxes&e.code; will indicate the areas of the primitive - which are obscured rather than the areas visible. + which are obscured rather than the areas visible. </quote> - &s.code;typedef int (* PutVideoFuncPtr)( ScrnInfoPtr pScrn, + &s.code;typedef int (* PutVideoFuncPtr)( ScrnInfoPtr pScrn, &f.indent;short vid_x, short vid_y, short drw_x, short drw_y, &f.indent;short vid_w, short vid_h, short drw_w, short drw_h, &f.indent;RegionPtr clipBoxes, pointer data )&e.code; @@ -3764,17 +3766,17 @@ typedef struct { </quote> - &s.code;typedef int (* PutStillFuncPtr)( ScrnInfoPtr pScrn, + &s.code;typedef int (* PutStillFuncPtr)( ScrnInfoPtr pScrn, &f.indent;short vid_x, short vid_y, short drw_x, short drw_y, &f.indent;short vid_w, short vid_h, short drw_w, short drw_h, &f.indent;RegionPtr clipBoxes, pointer data )&e.code; <quote><p> This is same as &s.code;PutVideo&e.code; except that the driver should place only one frame from the stream on the screen. - + </quote> - &s.code;typedef int (* GetVideoFuncPtr)( ScrnInfoPtr pScrn, + &s.code;typedef int (* GetVideoFuncPtr)( ScrnInfoPtr pScrn, &f.indent;short vid_x, short vid_y, short drw_x, short drw_y, &f.indent;short vid_w, short vid_h, short drw_w, short drw_h, &f.indent;RegionPtr clipBoxes, pointer data )&e.code; @@ -3786,7 +3788,7 @@ typedef struct { </quote> - &s.code;typedef int (* GetStillFuncPtr)( ScrnInfoPtr pScrn, + &s.code;typedef int (* GetStillFuncPtr)( ScrnInfoPtr pScrn, &f.indent;short vid_x, short vid_y, short drw_x, short drw_y, &f.indent;short vid_w, short vid_h, short drw_w, short drw_h, &f.indent;RegionPtr clipBoxes, pointer data )&e.code; @@ -3797,7 +3799,7 @@ typedef struct { </quote> - &s.code;typedef void (* StopVideoFuncPtr)(ScrnInfoPtr pScrn, + &s.code;typedef void (* StopVideoFuncPtr)(ScrnInfoPtr pScrn, &f.indent;pointer data, Bool cleanup)&e.code; <quote><p> This indicates the driver should stop displaying the video. @@ -3816,14 +3818,14 @@ typedef struct { &s.code;typedef int (* SetPortAttributeFuncPtr)(ScrnInfoPtr pScrn, &f.indent;Atom attribute,INT32 value, pointer data)&e.code; - &s.code;typedef int (* GetPortAttributeFuncPtr)(ScrnInfoPtr pScrn, + &s.code;typedef int (* GetPortAttributeFuncPtr)(ScrnInfoPtr pScrn, &f.indent;Atom attribute,INT32 *value, pointer data)&e.code; <quote><p> A port may have particular attributes such as hue, saturation, brightness or contrast. Xv clients set and - get these attribute values by sending attribute strings - (Atoms) to the server. Such requests end up at these + get these attribute values by sending attribute strings + (Atoms) to the server. Such requests end up at these driver functions. It is recommended that the driver provide at least the following attributes mentioned in the Xv client library docs: @@ -3849,7 +3851,7 @@ typedef struct { &s.code;typedef void (* QueryBestSizeFuncPtr)(ScrnInfoPtr pScrn, &f.indent;Bool motion, short vid_w, short vid_h, - &f.indent;short drw_w, short drw_h, + &f.indent;short drw_w, short drw_h, &f.indent;unsigned int *p_w, unsigned int *p_h, pointer data)&e.code; <quote><p> &s.code;QueryBestSize&e.code; provides the client with a way @@ -3864,23 +3866,23 @@ typedef struct { </quote> - &s.code;typedef int (* PutImageFuncPtr)( ScrnInfoPtr pScrn, + &s.code;typedef int (* PutImageFuncPtr)( ScrnInfoPtr pScrn, &f.indent;short src_x, short src_y, short drw_x, short drw_y, &f.indent;short src_w, short src_h, short drw_w, short drw_h, &f.indent;int image, char *buf, short width, short height, &f.indent;Bool sync, RegionPtr clipBoxes, pointer data )&e.code; <quote><p> This is similar to &s.code;PutStill&e.code; except that the - source of the video is not a port but the data stored in a system - memory buffer at &s.code;buf&e.code;. The data is in the format - indicated by the &s.code;image&e.code; descriptor and represents a + source of the video is not a port but the data stored in a system + memory buffer at &s.code;buf&e.code;. The data is in the format + indicated by the &s.code;image&e.code; descriptor and represents a source of size &s.code;width&e.code; by &s.code;height&e.code;. If &s.code;sync&e.code; is TRUE the driver should not return from this function until it is through reading the data from &s.code;buf&e.code;. Returning when &s.code;sync&e.code; is TRUE indicates that it is safe for the data at &s.code;buf&e.code; to be replaced, freed, or modified. - + </quote> &s.code;typedef int (* QueryImageAttributesFuncPtr)( ScrnInfoPtr pScrn, @@ -3893,17 +3895,17 @@ typedef struct { the size and corrected width and height are needed. In that case &s.code;pitches&e.code; and &s.code;offsets&e.code; are NULL. The size of the memory required for the image is returned - by this function. The &s.code;width&e.code; and + by this function. The &s.code;width&e.code; and &s.code;height&e.code; of the requested image can be altered by the driver to reflect format limitations (such as component - sampling periods that are larger than one). If + sampling periods that are larger than one). If &s.code;pitches&e.code; and &s.code;offsets&e.code; are not NULL, these will be arrays with as many elements in them as there are planes in the &s.code;image&e.code; format. The driver should specify the pitch (in bytes) of each scanline in the particular plane as well as the offset to that plane (in bytes) from the beginning of the image. - + </quote> </quote> @@ -3928,12 +3930,12 @@ typedef struct { </quote> -The XF86VideoFormatRec: +The XF86VideoFormatRec: <quote><p> <verb> typedef struct { - char depth; + char depth; short class; } XF86VideoFormatRec, *XF86VideoFormatPtr; </verb> @@ -3961,10 +3963,10 @@ typedef struct { </verb> Each adaptor may have an array of these advertising the attributes - for its ports. Currently defined flags are &s.code;XvGettable&e.code; - and &s.code;XvSettable&e.code; which may be OR'd together indicating that - attribute is ``gettable'' or ``settable'' by the client. The - &s.code;min&e.code; and &s.code;max&e.code; field specify the valid range + for its ports. Currently defined flags are &s.code;XvGettable&e.code; + and &s.code;XvSettable&e.code; which may be OR'd together indicating that + attribute is ``gettable'' or ``settable'' by the client. The + &s.code;min&e.code; and &s.code;max&e.code; field specify the valid range for the value. &s.code;Name&e.code; is a text string describing the attribute by name. @@ -3978,21 +3980,21 @@ typedef struct { int id; int type; int byte_order; - char guid[16]; + char guid[16]; int bits_per_pixel; int format; int num_planes; /* for RGB formats */ int depth; - unsigned int red_mask; - unsigned int green_mask; - unsigned int blue_mask; + unsigned int red_mask; + unsigned int green_mask; + unsigned int blue_mask; /* for YUV formats */ unsigned int y_sample_bits; unsigned int u_sample_bits; - unsigned int v_sample_bits; + unsigned int v_sample_bits; unsigned int horz_y_period; unsigned int horz_u_period; unsigned int horz_v_period; @@ -4001,7 +4003,7 @@ typedef struct { unsigned int vert_v_period; char component_order[32]; int scanline_order; -} XF86ImageRec, *XF86ImagePtr; +} XF86ImageRec, *XF86ImagePtr; </verb> XF86ImageRec describes how video source data is laid out in memory. @@ -4010,23 +4012,23 @@ typedef struct { &s.code;id&e.code; <quote><p> This is a unique descriptor for the format. It is often good to - set this value to the FOURCC for the format when applicable. + set this value to the FOURCC for the format when applicable. </quote> &s.code;type&e.code; <quote><p> - This is &s.code;XvRGB&e.code; or &s.code;XvYUV&e.code;. + This is &s.code;XvRGB&e.code; or &s.code;XvYUV&e.code;. </quote> &s.code;byte_order&e.code; <quote><p> - This is &s.code;LSBFirst&e.code; or &s.code;MSBFirst&e.code;. + This is &s.code;LSBFirst&e.code; or &s.code;MSBFirst&e.code;. </quote> &s.code;guid&e.code; <quote><p> This is the Globally Unique IDentifier for the format. When - not applicable, all characters should be NULL. + not applicable, all characters should be NULL. </quote> &s.code;bits_per_pixel&e.code; @@ -4038,7 +4040,7 @@ typedef struct { &s.code;format&e.code; <quote><p> - This is &s.code;XvPlanar&e.code; or &s.code;XvPacked&e.code;. + This is &s.code;XvPlanar&e.code; or &s.code;XvPacked&e.code;. </quote> &s.code;num_planes&e.code; @@ -4083,7 +4085,7 @@ typedef struct { &s.code;component_order&e.code; <quote><p> - Uppercase ascii characters representing the order that + Uppercase ascii characters representing the order that samples are stored within packed formats. For planar formats this represents the ordering of the planes. Unused characters in the 32 byte string should be set to NULL. @@ -4091,12 +4093,12 @@ typedef struct { &s.code;scanline_order&e.code; <quote><p> - This is &s.code;XvTopToBottom&e.code; or &s.code;XvBottomToTop&e.code;. + This is &s.code;XvTopToBottom&e.code; or &s.code;XvBottomToTop&e.code;. </quote> Since some formats (particular some planar YUV formats) may not be completely defined by the parameters above, the guid, when -available, should provide the most accurate description of the +available, should provide the most accurate description of the format. </quote> @@ -4132,6 +4134,10 @@ and the action to be taken for unresolved symbols can be controlled by the caller of the loader. Typically the caller identifies which symbols can safely remain unresolved and which cannot. +NOTE: Now that ISO-C allows pointers to functions and pointers to data to +have different internal representations, some of the following interfaces +will need to be revisited. + <sect1>Semi-private Loader Interface <p> @@ -4277,7 +4283,7 @@ typedef struct { specified and matches. </quote> - &s.code;patchlevel&e.code; + &s.code;patchlevel&e.code; <quote><p> The module's patchlevel must be no less than this value. This comparison @@ -4286,20 +4292,20 @@ typedef struct { specified and matches. </quote> - &s.code;abiclass&e.code; + &s.code;abiclass&e.code; <quote><p> String must match the module's abiclass string. </quote> - &s.code;abiversion&e.code; + &s.code;abiversion&e.code; <quote><p> Must be consistent with the module's abiversion (major equal, minor no older). </quote> - &s.code;moduleclass&e.code; + &s.code;moduleclass&e.code; <quote><p> String must match the module's moduleclass string. @@ -4311,7 +4317,7 @@ typedef struct { &s.code;errmaj&e.code; <quote><p> An optional pointer to a variable holding the major - part or the error code. When provided, it + part or the error code. When provided, &s.code;*errmaj&e.code; is filled in when &s.code;LoadModule()&e.code; fails. @@ -4331,7 +4337,8 @@ typedef struct { This function unloads the module referred to by the handle mod. All child modules are also unloaded recursively. This function must not be used to directly unload modules that are child modules (i.e., - those that have been loaded with &s.code;LoadSubModule()&e.code;). + those that have been loaded with the &s.code;LoadSubModule()&e.code; + described below). </quote> </quote> @@ -4361,7 +4368,7 @@ typedef struct { CARD32 abiversion; /* ABI version */ const char * moduleclass; /* module class */ CARD32 checksum[4]; /* contains a digital signature of the */ - /* version info structure */ + /* version info structure */ } XF86ModuleVersionInfo; </verb> @@ -4547,15 +4554,15 @@ as and maybe used by the &s.code;SetupProc&e.code; if it calls other loader functions that require a reference to it. The remaining arguments are those that were passed to the - &s.code;LoadModule()&e.code; (or &s.code;LoadSubModule()&e.code;), - and are described above. When the &s.code;SetupProc&e.code; is - successful it must return a non-&s.code;NULL&e.code; value. The - loader checks this, and if it is &s.code;NULL&e.code; it unloads - the module and reports the failure to the caller of - &s.code;LoadModule()&e.code;. If the &s.code;SetupProc&e.code; - does things that need to be undone when the module is unloaded, - it should define a &s.code;TearDownProc&e.code;, and return a - pointer that the &s.code;TearDownProc&e.code; can use to undo what + &s.code;LoadModule()&e.code; (or &s.code;LoadSubModule()&e.code;), + and are described above. When the &s.code;SetupProc&e.code; is + successful it must return a non-&s.code;NULL&e.code; value. The + loader checks this, and if it is &s.code;NULL&e.code; it unloads + the module and reports the failure to the caller of + &s.code;LoadModule()&e.code;. If the &s.code;SetupProc&e.code; + does things that need to be undone when the module is unloaded, + it should define a &s.code;TearDownProc&e.code;, and return a + pointer that the &s.code;TearDownProc&e.code; can use to undo what has been done. When a module is loaded multiple times, the &s.code;SetupProc&e.code; @@ -4603,7 +4610,7 @@ the server, and may also be used from within modules. <quote><p> This function unloads the module with handle &s.code;module&e.code;. If that module itself has children, they are also unloaded. It is - like &s.code;LoadModule()&e.code;, except that it is safe to use + like &s.code;UnloadModule()&e.code;, except that it is safe to use for unloading child modules. </quote> @@ -4644,9 +4651,9 @@ the server, and may also be used from within modules. &s.code;LoadSubModule()&e.code;. If any symbols registered in this way are found to be unresolved when &s.code;LoaderCheckUnresolved()&e.code; is called then - &s.code;LoaderCheckUnresolved()&e.code; will report a failure. The - function takes one or more &s.code;NULL&e.code; terminated lists of - symbols. The end of the argument list is indicated by a + &s.code;LoaderCheckUnresolved()&e.code; will report a failure. + The function takes one or more &s.code;NULL&e.code; terminated + lists of symbols. The end of the argument list is indicated by a &s.code;NULL&e.code; argument. </quote> @@ -4668,6 +4675,9 @@ the server, and may also be used from within modules. with the loader. When &s.code;LoaderCheckUnresolved()&e.code; is run it won't generate warnings for symbols registered in this way unless they were also registered as required symbols. + The function takes one or more &s.code;NULL&e.code; terminated + lists of symbols. The end of the argument list is indicated by a + &s.code;NULL&e.code; argument. </quote> @@ -4874,10 +4884,11 @@ strongly encouraged to improve the consistency of driver behaviour. NOTE: This function can only be used after the &s.code;ScrnInfoRec&e.code; and its &s.code;name&e.code; field - have been allocated. That means that it can not be used before - the END of the &s.code;ChipProbe()&e.code; function. Prior to - that, use &s.code;xf86Msg()&e.code;, providing the driver's name - explicitly. No screen number can be supplied at that point. + have been allocated. Normally, this means that it can not be + used before the END of the &s.code;ChipProbe()&e.code; function. + Prior to that, use &s.code;xf86Msg()&e.code;, providing the + driver's name explicitly. No screen number can be supplied at + that point. </quote> @@ -5180,7 +5191,7 @@ be catered for the by the helpers. </quote> &s.code;linePitches&e.code; <quote><p> - List of supported line pitches supported by the driver. + List of line pitches supported by the driver. This is optional and should be &s.code;NULL&e.code; when not used. @@ -5447,7 +5458,7 @@ be catered for the by the helpers. to be programmed in the chip when it has a programmable clock, or the clock that will be picked from the clocks list when it is not a programmable one. Thus: - + &s.code;mode->SynthClock = &f.indent;(mode->Clock * ClockMulFactor) / ClockDivFactor&e.code; @@ -5483,9 +5494,10 @@ be catered for the by the helpers. &s.code;void xf86PrintModes(ScrnInfoPtr scrp)&e.code; <quote><p> This function prints out the virtual size setting, and the line - pitch being used. It also prints out one line for each mode being - used, including its pixel clock, horizontal sync rate, refresh - rate, and whether it is interlaced or multiscan. + pitch being used. It also prints out two lines for each mode being + used. The first line includes the mode's pixel clock, horizontal sync + rate, refresh rate, and whether it is interlaced, doublescanned and/or + multi-scanned. The second line is the mode's Modeline. This function is normally called after calling &s.code;xf86SetCrtcForModes()&e.code;. @@ -5767,7 +5779,7 @@ programming the standard VGA registers, and for handling VGA colourmaps. #define VGA_NUM_GFX 9 #define VGA_NUM_ATTR 21 </verb></quote> - + </quote> &s.code;Bool vgaHWCopyReg(vgaRegPtr dst, vgaRegPtr src)&e.code; @@ -5864,22 +5876,12 @@ programming the standard VGA registers, and for handling VGA colourmaps. This function unlocks the VGA &s.code;CRTC[0-7]&e.code; registers, and must be called before attempting to write to those registers. - A macro &s.code;VGAHW_UNLOCK(base)&e.code; is also available in - &s.code;vgaHW.h&e.code; that does the same thing, and this may be - used when the vgahw module is not loaded (for example, in the - &s.code;ChipProbe()&e.code; function). - </quote> &s.code;void vgaHWLock(vgaHWPtr hwp)&e.code; <quote><p> This function locks the VGA &s.code;CRTC[0-7]&e.code; registers. - A macro &s.code;VGAHW_LOCK(base)&e.code; is also available in - &s.code;vgaHW.h&e.code; that does the same thing, and this may be - used when the vgahw module is not loaded (for example, in the - &s.code;ChipProbe()&e.code; function). - </quote> &s.code;void vgaHWEnable(vgaHWPtr hwp)&e.code; @@ -5922,14 +5924,14 @@ programming the standard VGA registers, and for handling VGA colourmaps. below in the order &s.code;vgaHWSaveColormap()&e.code;, &s.code;vgaHWSaveMode()&e.code;, &s.code;vgaHWSaveFonts()&e.code; to carry out the different save phases. It is undecided at this - stage whether they will be part of the vgahw module's public + stage whether they will remain part of the vgahw module's public interface or not. </quote> &s.code;void vgaHWSaveMode(ScrnInfoPtr pScrn, vgaRegPtr save)&e.code; <quote><p> - This functions saves the VGA mode registers. They are saved to + This function saves the VGA mode registers. They are saved to the &s.code;vgaRegRec&e.code; pointed to by &s.code;save&e.code;. The registers saved are: @@ -5941,11 +5943,14 @@ programming the standard VGA registers, and for handling VGA colourmaps. Sequencer[0-4]&e.code; </quote> + The number of registers actually saved may be modified by a prior call + to &s.code;vgaHWSetRegCounts()&e.code;. + </quote> &s.code;void vgaHWSaveFonts(ScrnInfoPtr pScrn, vgaRegPtr save)&e.code; <quote><p> - This functions saves the text mode font and text data held in the + This function saves the text mode font and text data held in the video memory. If called while in a graphics mode, no save is done. The VGA memory window must be mapped with &s.code;vgaHWMapMem()&e.code; before to calling this function. @@ -5982,13 +5987,13 @@ programming the standard VGA registers, and for handling VGA colourmaps. &s.code;vgaHWRestoreMode()&e.code;, &s.code;vgaHWRestoreColormap()&e.code; to carry out the different restore phases. It is undecided at this stage whether they will - be part of the vgahw module's public interface or not. + remain part of the vgahw module's public interface or not. </quote> &s.code;void vgaHWRestoreMode(ScrnInfoPtr pScrn, vgaRegPtr restore)&e.code; <quote><p> - This functions restores the VGA mode registers. They are restore + This function restores the VGA mode registers. They are restored from the data in the &s.code;vgaRegRec&e.code; pointed to by &s.code;restore&e.code;. The registers restored are: @@ -6000,11 +6005,14 @@ programming the standard VGA registers, and for handling VGA colourmaps. Sequencer[0-4]&e.code; </quote> + The number of registers actually restored may be modified by a prior call + to &s.code;vgaHWSetRegCounts()&e.code;. + </quote> &s.code;void vgaHWRestoreFonts(ScrnInfoPtr pScrn, vgaRegPtr restore)&e.code; <quote><p> - This functions restores the text mode font and text data to the + This function restores the text mode font and text data to the video memory. The VGA memory window must be mapped with &s.code;vgaHWMapMem()&e.code; before to calling this function. @@ -6063,8 +6071,8 @@ programming the standard VGA registers, and for handling VGA colourmaps. &s.code;on&e.code; is &s.code;FALSE&e.code;, and unblanked when &s.code;on&e.code; is &s.code;TRUE&e.code;. This function is provided for use in cases where the &s.code;ScrnInfoRec&e.code; - can't be derived from the &s.code;ScreenRec&e.code;, like probing - for clocks. + can't be derived from the &s.code;ScreenRec&e.code; (while probing + for clocks, for example). </quote> </quote> @@ -6072,7 +6080,7 @@ programming the standard VGA registers, and for handling VGA colourmaps. <sect1>VGA Colormap Functions <p> - The vgahw modules uses the standard colormap support (see the + The vgahw module uses the standard colormap support (see the <ref id="cmap" name="Colormap Handling"> section. This is initialised with the following function: @@ -6278,7 +6286,7 @@ visible symbols. &s.code;"compiler.h"&e.code; </quote> Note: in drivers, this must be included after &s.code;"xf86_ansic.h"&e.code;. - + Drivers that need to access PCI vendor/device definitions need this: <quote> &s.code;"xf86PciInfo.h"&e.code; @@ -6370,8 +6378,6 @@ visible symbols. #define ZZZ_PATCHLEVEL <int> </code> <p> - XXX Probably want to remove one of these version. -<p> NOTE: &s.code;ZZZ_DRIVER_NAME&e.code; should match the name of the driver module without things like the "lib" prefix, the "_drv" suffix or filename extensions. @@ -6548,10 +6554,10 @@ zzzSetup(pointer module, pointer opts, int *errmaj, int *errmin) it is zeroed, and if the allocation fails the server exits. <p> NOTE: - When allocating structures from inside the driver which are defined - on the common level it is important to initialize the structure to - zero. - Only this guarantees that the server remains source compatible to + When allocating structures from inside the driver which are defined + on the common level it is important to initialize the structure to + zero. + Only this guarantees that the server remains source compatible to future changes in common level structures. <code> @@ -6655,7 +6661,7 @@ ZZZProbe(DriverPtr drv, int flags) */ /* test if PCI bus present */ if (xf86GetPciVideoInfo()) { - + numUsed = xf86MatchPciInstances(ZZZ_NAME, PCI_VENDOR_ZZZ, ZZZChipsets, ZZZPciChipsets, devSections, numDevSections, drv, &usedChips); @@ -6663,7 +6669,7 @@ ZZZProbe(DriverPtr drv, int flags) for (i = 0; i < numUsed; i++) { ScrnInfoPtr pScrn = NULL; if ((pScrn = xf86ConfigPciEntity(pScrn, flags, usedChips[i], - ZZZPciChipsets, NULL, NULL, + ZZZPciChipsets, NULL, NULL, NULL, NULL, NULL))) { /* Allocate a ScrnInfoRec */ pScrn->driverVersion = VERSION; @@ -6695,10 +6701,10 @@ ZZZProbe(DriverPtr drv, int flags) devSections, numDevSections, &usedChips); for (i = 0; i < numUsed; i++) { ScrnInfoPtr pScrn = NULL; - if ((pScrn = xf86ConfigIsaEntity(pScrn, flags, usedChips[i], - ZZZIsaChipsets, NULL, NULL, NULL, + if ((pScrn = xf86ConfigIsaEntity(pScrn, flags, usedChips[i], + ZZZIsaChipsets, NULL, NULL, NULL, NULL, NULL))) { - pScrn->driverVersion = VERSION; + pScrn->driverVersion = VERSION; pScrn->driverName = ZZZ_DRIVER_NAME; pScrn->name = ZZZ_NAME; pScrn->Probe = ZZZProbe; @@ -7353,7 +7359,7 @@ ZZZCloseScreen(int scrnIndex, ScreenPtr pScreen) { ScrnInfoPtr pScrn = xf86Screens[scrnIndex]; if (pScrn->vtSema) { - ZZZRestore(pScrn); + ZZZRestore(pScrn); ZZZUnmapMem(pScrn); } pScrn->vtSema = FALSE; @@ -7369,11 +7375,6 @@ ZZZCloseScreen(int scrnIndex, ScreenPtr pScreen) blanking function). When using the vgahw module, this will typically be: -This function is mandatory. Before modifying any hardware register directly -this function needs to make sure that the Xserver is active by checking -if <code>pScrn</code> is non-NULL and for <code>pScrn->vtSema == TRUE</code>. - - <code> static Bool ZZZSaveScreen(ScreenPtr pScreen, int mode) @@ -7382,6 +7383,11 @@ ZZZSaveScreen(ScreenPtr pScreen, int mode) } </code> + This function is mandatory. Before modifying any hardware register + directly this function needs to make sure that the Xserver is active + by checking if &s.code;pScrn&e.code; is non-NULL and for + &s.code;pScrn->vtSema == TRUE&e.code;. + <sect2>FreeScreen <p> diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/DRI.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/DRI.sgml index 15722d3c1..b6c6d51ec 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/DRI.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/DRI.sgml @@ -13,7 +13,7 @@ <date>15 June 2001 <ident> - $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DRI.sgml,v 1.28 2002/02/22 21:45:13 dawes Exp $ + $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DRI.sgml,v 1.29 2003/02/17 03:57:29 dawes Exp $ </ident> <toc> @@ -148,6 +148,11 @@ <item>Radeon SDR AGP <item>Radeon DDR AGP <item>Radeon 32MB SDR PCI (Alpha-based systems) + <item>Radeon 7000, M6 (RV100) + <item>Radeon 7200 (R100) + <item>Radeon 7500, M7 (RV200) + <item>Radeon 8500, 9100 (R200) + <item>Radeon 9000, M9 (RV250) </itemize> <item>3Dlabs, supported on Intel x86 and AMD: <itemize> diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/DRIcomp.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/DRIcomp.sgml index 46bc98d5d..5d47ed51a 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/DRIcomp.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/DRIcomp.sgml @@ -13,7 +13,7 @@ <date>21 April 2001 <ident> - $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DRIcomp.sgml,v 1.17 2002/02/22 21:45:13 dawes Exp $ + $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DRIcomp.sgml,v 1.19 2002/11/26 01:05:50 dawes Exp $ </ident> <toc> @@ -209,7 +209,7 @@ <sect1>Intel Pentium III Features <p> - The Pentium III SSE (Katmai) instructions are used in + The Pentium III SSE instructions are used in optimized vertex transformation functions in the Mesa-based DRI drivers. On Linux, SSE requires a recent kernel (such as 2.4.0-test11 @@ -432,7 +432,7 @@ <bf>will not compile</bf>. You have been warned. If you do have a 2.4.x kernel, you should add the following: <verb> - #define MesaUseKatmai YES + #define MesaUseSSE YES </verb> <p> diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/Imakefile b/xc/programs/Xserver/hw/xfree86/doc/sgml/Imakefile index af193d934..3b81cfb69 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/Imakefile +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/Imakefile @@ -3,7 +3,7 @@ XCOMM $XConsortium: Imakefile /main/16 1996/10/28 05:13:04 kaleb $ -XCOMM $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Imakefile,v 3.80 2002/06/03 21:22:09 dawes Exp $ +XCOMM $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Imakefile,v 3.83 2003/02/26 21:59:44 dawes Exp $ #include <Server.tmpl> #include <lnxdoc.rules> @@ -20,8 +20,9 @@ RELNOTES=RELNOTES.sgml SGMLDEPENDS = defs.ent MANSGMLDEPENDS = mdefs.ent INDEXLIST = README.sgml $(RELNOTES) Status.sgml LICENSE.sgml Install.sgml \ - DESIGN.sgml Versions.sgml \ + BUILD.sgml DESIGN.sgml Versions.sgml \ mouse.sgml fonts.sgml DRI.sgml DRIcomp.sgml dps.sgml \ + XKB-Config.sgml XKB-Enhancing.sgml \ Darwin.sgml isc.sgml LynxOS.sgml NetBSD.sgml OpenBSD.sgml \ OS2Notes.sgml SCO.sgml Solaris.sgml \ apm.sgml ati.sgml chips.sgml cyrix.sgml DECtga.sgml \ @@ -130,6 +131,8 @@ LinuxDocTarget(xinput) LinuxDocReadmeTarget(DRI) LinuxDocReadmeTarget(DRIcomp) LinuxDocReadmeTarget(dps) +LinuxDocReadmeTarget(XKB-Config) +LinuxDocReadmeTarget(XKB-Enhancing) SGMLMANDEFS=-D__drivermansuffix__='"$(DRIVERMANSUFFIX)"' \ -D__filemansuffix__='"$(FILEMANSUFFIX)"' \ @@ -165,3 +168,7 @@ FORMATTEDDIR = .. UpdateFormattedDoc(RELNOTES,$(TOP)) #endif +/* Update the README files in xc/programs/xkbcomp */ +UpdateFormattedDocLong(README.XKB-Config,$(PROGRAMSRC)/xkbcomp,README.config) +UpdateFormattedDocLong(README.XKB-Enhancing,$(PROGRAMSRC)/xkbcomp,README.enhancing) + diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/Install.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/Install.sgml index f24c95c3b..fd2cf4be8 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/Install.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/Install.sgml @@ -6,10 +6,10 @@ <title>Installation Details for XFree86™ &relvers; <author>The XFree86 Project, Inc -<date>16 January 2002 +<date>24 February 2003 <ident> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Install.sgml,v 1.13 2002/01/16 20:38:44 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Install.sgml,v 1.17 2003/02/24 17:09:16 dawes Exp $ </ident> <abstract> @@ -26,12 +26,21 @@ This document contains information about installing the XFree86 binaries as provided by The XFree86 Project. <p> -The XFree86 binaries that we provide for UNIX-like OS's (Linux, the BSDs, -Solaris, etc) are packaged in a platform-independent gzipped tar format (aka -"tarballs" identified by the <tt>.tgz</tt> suffix). Along with the -binaries we provide a customized version of the GNU tar utility called -"extract" and an installation script. We recommend that these be -used to install the binaries. +The XFree86 binaries that we provide for UNIX-like OS's (Linux, the +BSDs, Solaris, etc) are packaged in a platform-independent gzipped tar +format (aka "tarballs" identified by the <tt>.tgz</tt> suffix). Along +with the binaries we provide a customized version of the GNU tar utility +called "extract" and an installation script. We recommend that these +be used to install the binaries. (The source for this customized version +of GNU tar can be found in the XFree86 CVS repository's "utils" module, +and from our <url name="ftp site" +url="ftp://ftp.xfree86.org/pub/XFree86/misc/utils-&utilsvers;.tgz">.) + +<![ %snapshot [ +<p> +Note: for snapshot releases like this one, binaries are only available for +a small number of platforms. +]]> <sect>Downloading the XFree86 &relvers; binaries @@ -43,7 +52,7 @@ XFree86 &relvers; is an update release. The most recent full release Information about downloading and installing &fullrelvers; can be found in the installation document for that version, which can be found on the <url name="XFree86 web site" -url="http://www.xfree86.org/pub/XFree86/&fullrelvers/Install.html">. +url="http://www.xfree86.org/&fullrelvers/Install.html">. ]]> We provide XFree86 &relvers; <![ %updaterel [update ]]>binaries for a range @@ -129,12 +138,12 @@ distribution. Once you're run the <tt>Xinstall.sh</tt> script and found which binary <![ %updaterel; [update ]]>distribution is suitable for your system, -download the necessary files. The <![ %fullrel [twelve (12)]]><![ +download the necessary files. The <![ %fullbinaries [twelve (12)]]><![ %updaterel [four (4)]]> mandatory files for all installations are listed below. If you have not downloaded all of the files, the installer script will complain. -<![ %fullrel [ +<![ %fullbinaries [ <quote><verb> 1. Xinstall.sh The installer script 2. extract The utility for extracting tarballs @@ -167,14 +176,14 @@ NOTES: version called <tt>extract.exe</tt> instead. This should fix the problem. (This is not a DOS/Windows executable.) -<![ %fullrel [ +<![ %fullbinaries [ <item>A few distributions don't have or require the <tt>Xvar.tgz</tt> tarball. If it is present in the <tt>binaries</tt> sub-directory for your platform, then it is required. ]]> <item>The Darwin/Mac OS X distribution doesn't have or require the - <![ %fullrel [<tt>Xmod.tgz</tt>]]><![ %updaterel + <![ %fullbinaries [<tt>Xmod.tgz</tt>]]><![ %updaterel [<tt>Xdrivers.tgz</tt>]]> tarball. <item>Some distributions may have additional mandatory tarballs. @@ -182,7 +191,7 @@ NOTES: </itemize> -<![ %fullrel [ +<![ %fullbinaries [ The following eleven (11) tarballs are optional. You should download the ones you want to install. @@ -221,7 +230,7 @@ script to install this update. Older versions may not be able to do it correctly.]]> There are a lot of steps in the manual installation process, and those steps can vary -according to the platform and hardware setup. <![ %fullrel [There is a description of +according to the platform and hardware setup. <![ %fullbinaries [There is a description of the manual installation process for the most common cases <ref id="manual-install" name="below">.]]> @@ -253,7 +262,7 @@ be a problem, you should exit your X session, including stopping xdm or equivalent if it is running, before continuing. If you ignore this warning and run into problems, well, you were warned! -<![ %fullrel [If you have an existing X installation, you]]> +<![ %fullbinaries [If you have an existing X installation, you]]> <![ %updaterel [You ]]> will be warned that proceeding with this installation will overwrite it. Only those things that are @@ -274,7 +283,7 @@ script may remove some old files or directories that would get in the way of the new installation. It will list which files/directories have been removed. If none are listed, then none were removed. -<![ %fullrel [ +<![ %fullbinaries [ The next step when installing over an existing version is to check for existing configuration files. As of XFree86 version 3.9.18, the run-time configuration files are installed by default under <tt>/etc/X11</tt> @@ -375,7 +384,7 @@ operation of the new X server, you can safely remove the old After the X server configuration is done, it may be advisable to reboot, especially if you run xdm (or equivalent) or the font server (xfs). -<![ %fullrel [ +<![ %fullbinaries [ <sect>Installing XFree86 &relvers; manually<label id="manual-install"> <p> This section contains information about manually installing the XFree86 diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/LICENSE.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/LICENSE.sgml index 4f271a325..d928d7c66 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/LICENSE.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/LICENSE.sgml @@ -5,10 +5,10 @@ <article> <title>Licenses</title> <author>The XFree86 Project</author> -<date>January 2002</date> +<date>February 2003</date> <ident> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/LICENSE.sgml,v 1.11 2002/01/16 20:38:45 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/LICENSE.sgml,v 1.12 2003/02/24 03:41:16 dawes Exp $ </ident> <sect>XFree86 License @@ -17,7 +17,7 @@ XFree86 code without an explicit copyright is covered by the following copyright/license: <p> -Copyright (C) 1994-2002 The XFree86 Project, Inc. All Rights Reserved. +Copyright (C) 1994-2003 The XFree86 Project, Inc. All Rights Reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/NetBSD.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/NetBSD.sgml index 4b670edee..b94384236 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/NetBSD.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/NetBSD.sgml @@ -9,10 +9,10 @@ David Dawes, Marc Wandschneider, Mark Weaver, Matthieu Herrb -<Date>Last modified on: 16 January 2002 +<Date>Last modified on: 9 November 2002 <ident> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/NetBSD.sgml,v 3.63 2002/01/16 22:35:18 herrb Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/NetBSD.sgml,v 3.68 2003/02/16 17:21:11 dawes Exp $ </ident> <toc> @@ -20,18 +20,20 @@ $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/NetBSD.sgml,v 3.63 2002/01/16 <sect>What and Where is XFree86? <p> -XFree86 is the Open Source port of X.Org's X11R6.6 release that supports -several UNIX(R) and UNIX-like (such as Linux, the BSDs and Solaris x86) -operating systems on Intel and other platforms. +XFree86 is an Open Source version of the X Window System that supports +several UNIX(R) and UNIX-like operating systems (such as Linux, the BSDs +and Solaris x86) on Intel and other platforms. This version is compatible +with X11R6.6. See the <htmlurl url="COPYRIGHT.html" name="Copyright Notice">. +<![ %notsnapshot [ The sources for XFree86 are available by anonymous ftp from: <htmlurl name="ftp://ftp.XFree86.org/pub/XFree86/&relvers;" url="ftp://ftp.XFree86.org/pub/XFree86/&relvers;"> -Binaries for NetBSD 1.4 and later are available from: +Binaries for NetBSD 1.5 and later are available from: <htmlurl name="ftp://ftp.XFree86.org/pub/XFree86/&relvers;/binaries/NetBSD" url="ftp://ftp.XFree86.org/pub/XFree86/&relvers;/NetBSD"> @@ -39,6 +41,7 @@ url="ftp://ftp.XFree86.org/pub/XFree86/&relvers;/NetBSD"> A list of mirror sites is provided by <htmlurl name="http://www.xfree86.org/MIRRORS.shtml" url="http://www.xfree86.org/MIRRORS.shtml"> +]]> XFree86 also builds on other NetBSD architectures. See section @@ -145,7 +148,7 @@ sample file installed as <tt>/usr/X11R6/lib/X11/XF86Config.eg</tt>, which can be used as a starting point. For details about the <tt/XF86Config/ file format, refer to the -<em>XF86Config(5)</em> manual page. +<em><htmlurl name="XF86Config(5)" url="XF86Config.5.html"></em> manual page. Once you've set up a XF86Config file, you can fine tune the video modes with the <tt>xvidtune</tt> utility. @@ -466,8 +469,18 @@ and <bf/__bsdi__/ for BSD/386. <sect> Thanks <p> Many thanks to all people who contributed to make XFree86 work on -*BSD, in particular, <bf/David Dawes/, -<bf/Pace Willison/, <bf/Amancio Hasty/, <bf/Christoph Robitschko/, -<bf/Nate Williams/, <bf/Rod Grimes/, <bf/Jack Velte/ and <bf/Michael Smith/. +*BSD, in particular: +<bf/David Dawes/, +<bf/Todd Fries/, +<bf/Rod Grimes/, +<bf/Charles Hannum/, +<bf/Amancio Hasty/, +<bf/Christoph Robitschko/, +<bf/Matthias Scheler/, +<bf/Michael Smith/, +<bf/Ignatios Souvatzis/, +<bf/Jack Velte/, +<bf/Nate Williams/ and +<bf/Pace Willison/. </article> diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/OS2Notes.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/OS2Notes.sgml index 832e9f63a..6bdc7d1cf 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/OS2Notes.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/OS2Notes.sgml @@ -5,6 +5,10 @@ <author>Holger Veit <date>Last modified March 8th, 2000 +<ident> +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/OS2Notes.sgml,v 1.2 2003/01/04 04:20:23 dawes Exp $ +</ident> + <toc> <sect>Preface @@ -27,11 +31,11 @@ have worked in earlier versions, may now no longer work, or work differently. Be aware that for OS/2, XFree86-4.0 is considered to be alpha software. If you want to join the XFree86 developer team, e.g. to add support for -certain hardware, please send a request to BOD@XFree86.org. Please -think about such a step carefully before, though, since much work is -involved. Please use the XFree86-4.0 source code as a test example how -to compile the system. The ability to manage that is a basic requirement -for becoming a developer. +certain hardware, please send a request to <email>BOD@XFree86.org</email>. +Please think about such a step carefully before, though, since much work +is involved. Please use the XFree86-4.0 source code as a test example +how to compile the system. The ability to manage that is a basic +requirement for becoming a developer. <sect>Tools required @@ -201,14 +205,5 @@ Well, you see, this was quite easy :-) -<verb> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/OS2Notes.sgml,v 1.1 2001/06/04 13:50:15 dawes Exp $ - - - - - -$XConsortium: OS2note.sgml /main/1 1996/02/24 10:08:59 kaleb $ -</verb> </article> diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/OpenBSD.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/OpenBSD.sgml index 2586aa5e3..142ae16a3 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/OpenBSD.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/OpenBSD.sgml @@ -6,10 +6,10 @@ <title>README for XFree86 &relvers; on OpenBSD <author> Matthieu Herrb -<Date>Last modified on: 16 January 2002 +<Date>Last modified on: 9 November 2002 <ident> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/OpenBSD.sgml,v 1.24 2002/01/16 22:35:17 herrb Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/OpenBSD.sgml,v 1.30 2003/02/25 19:31:01 dawes Exp $ </ident> <toc> @@ -18,18 +18,20 @@ $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/OpenBSD.sgml,v 1.24 2002/01/16 <sect>What and Where is XFree86? <p> -XFree86 is the Open Source port of X.Org's X11R6.6 release that supports -several UNIX(R) and UNIX-like (such as Linux, the BSDs and Solaris x86) -operating systems on Intel and other platforms. +XFree86 is an Open Source version of the X Window System that supports +several UNIX(R) and UNIX-like operating systems (such as Linux, the BSDs +and Solaris x86) on Intel and other platforms. This version is compatible +with X11R6.6. See the <htmlurl url="COPYRIGHT.html" name="Copyright Notice">. +<![ %notsnapshot [ The sources for XFree86 &relvers; are available by anonymous ftp from: <htmlurl name="ftp://ftp.XFree86.org/pub/XFree86/&relvers;" url="ftp://ftp.XFree86.org/pub/XFree86/&relvers;"> -Binaries for OpenBSD/i386 3.0 and later are available from: +Binaries for OpenBSD/i386 3.2 and later are available from: <htmlurl name="ftp://ftp.XFree86.org/pub/XFree86/&relvers;/binaries/OpenBSD" url="ftp://ftp.XFree86.org/pub/XFree86/&relvers;/binaries/OpenBSD"> @@ -37,6 +39,7 @@ url="ftp://ftp.XFree86.org/pub/XFree86/&relvers;/binaries/OpenBSD"> A list of mirror sites is provided by <htmlurl name="http://www.xfree86.org/MIRRORS.shtml" url="http://www.xfree86.org/MIRRORS.shtml"> +]]> <p> @@ -56,11 +59,17 @@ this file and we'll revise it. See the <htmlurl url="RELNOTES.html" name="Release Notes"> for non-OS dependent new features in XFree86 &relvers;. +<sect1>New OS related features in 4.3 +<p> +<itemize> +<item>Support for some VGA cards on OpenBSD/alpha +</itemize> + <sect1>New OS dependent features in 4.2 <p> <itemize> <item>Support for OpenBSD/macppc on the ATI Rage128 based -Power Macintosh. +Power Macintoshes. <item>Support for building clients on OpenBSD/sparc64. </itemize> @@ -149,7 +158,7 @@ which can be used as a starting point. For details about the <tt/XF86Config/ file format, refer to the -<em>XF86Config(5)</em> manual page. +<em><htmlurl name="XF86Config(5)" url="XF86Config.5.html"></em> manual page. Once you've set up a XF86Config file, you can fine tune the video modes with the <tt>xvidtune</tt> utility. @@ -211,7 +220,6 @@ To make sure X support is enabled under OpenBSD, the following line must be in your config file in <tt>/sys/arch/i386/conf</tt>: <tscreen> - option XSERVER option APERTURE </tscreen> @@ -267,62 +275,12 @@ OpenBSD supports System V shared memory. If XFree86 detects this support in your kernel, it will support the MIT-SHM extension. -To add support for system V shared memory to your kernel add the -lines: - -<tscreen><verb> - # System V-like IPC - options SYSVMSG - options SYSVSEM - options SYSVSHM -</verb></tscreen> - -to your kernel config file. - <sect> Rebuilding the XFree86 Distribution You should configure the distribution by editing <tt>xc/config/cf/host.def</tt> before compiling. To compile the sources, invoke ``<tt/make World/'' in the xc directory. -<sect1>Console drivers<label id="console-drivers"> - -<p> -XFree86 has a configuration option to select the console -drivers to use in <tt/host.def/: -<itemize> -<item> if you're using pccons only put: -<tscreen><verb> - #define XFree86ConsoleDefines -DPCCONS_SUPPORT -</verb></tscreen> -<item>if you're using pcvt only put: -<tscreen><verb> - #define XFree86ConsoleDefines -DPCVT_SUPPORT -</verb></tscreen> -</itemize> -If you don't define <bf/XFree86ConsoleDefines/ in <tt/host.def/ the -pccons and pcvt drivers will be supported by default. - -<p> -Native support for the wscons console driver found on -OpenBSD/macppc and on OpenBSD/i386 2.9 and later is built -by adding: -<tscreen><verb> - #define XFree86ConsoleDefines -DWSCONS_SUPPORT -</verb></tscreen> -to <tt>xc/config/host.def</tt> before rebuilding the server. - -For the i386, you should include both pcvt and wscons support in order -to use the pcvt compatibility mode of wscons: -<tscreen><verb> - #define XFree86ConsoleDefines -DPCVT_SUPPORT -DWSCONS_SUPPORT -</verb></tscreen> - - -<sect1>Building on other architectures<label id="otherarch"> - -<p> -XFree86 also compiles on other OpenBSD architectures. <p> Note that OpenBSD project now has its own source tree, based on @@ -332,7 +290,29 @@ source tree is available by anoncvs from all OpenBSD anoncvs servers. See <htmlurl url="http://www.openbsd.org/anoncvs.html" name="http://www.openbsd.org/anoncvs.html"> for details on anoncvs. -<sect2>XFree86 on OpenBSD/macppc +<label id="otherarch"> + +<p> +XFree86 also compiles on other OpenBSD architectures. +<sect1>XFree86 on OpenBSD/alpha +<p> +The XFree86 server is known to work on some VGA cards in alpha +machines that support BWX I/O, with OpenBSD 3.2 and higher. +<p> +The following cards have been successfully tested for now: +<itemize> +<item>3DLabs Permedia 2 (8, 15, 16 and 24 bits depth) +<item>ATI Rage Pro (works with 'Option "NoAccel"') +<item>Cirrus Logic CL5430 (works with 'Option "NoAccel"') +<item>Cirrus Logic GD5446 (8, 16 and 24 bits depth) +<item>Matrox MGA 2064 (8, 16 and 24 bits depth) +</itemize> +<p> +Note that this version of XFree86 doesn't work on TGA cards. The +version shipped with OpenBSD 3.1 and higher includes an OS-specific +driver <em/wsfb/ that is used to support TGA cards. + +<sect1>XFree86 on OpenBSD/macppc <p> The XFree86 server is currently known to work on the G4 Macs and new iBooks with ATI Rage 128 cards running OpenBSD 3.0 or later. @@ -341,22 +321,26 @@ lack some kernel support for it. <p> Use xf86config to build a /etc/X11/XF86Config file before starting the server for the first time. -<p> -Tou configure the keyboard, the protocol should be specified as -<bf/wskbd/ and the device as <tt>/dev/wskbd0</tt>. -Using a wsmux device as the keyboard device doesn't work (yet). Use -<bf/macintosh/ as XkbModel. <p> For the Titanium Powerbook G4, you can try the following mode line in <tt>/etc/X11/XF86Config</tt> to match the flat panel resolution: <tscreen><verb> -Modeline "1152x768" 78.741 1152 1173 1269 1440 768 769 772 800 +HSync +VSync +Modeline "1152x768" 64.995 1152 1213 1349 1472 768 771 777 806 -HSync -VSync </verb></tscreen> + +<sect1>XFree86 on OpenBSD/sparc +<p> +OpenBSD 3.2 on sparc switched to the wscons device driver and now uses +the OS specific <em/wsfb/ driver in the XFree86 server. This driver is +not included in XFree86 4.3. Please use the version shipped with +OpenBSD instead. + +<sect1>XFree86 on OpenBSD/sparc64 <p> -You need to set <tt/securelevel/ to -1 in the -<tt>/etc/rc.securelevel</tt> -configuration file to run XFree86 on OpenBSD/macppc. +This version of XFree68 only has support for X clients on +OpenBSD/sparc64. Note that the version shipped with OpenBSD also has +support for the X server on both SBus and PCI based machines. <sect>Building New X Clients @@ -372,8 +356,18 @@ pages you should update <tt/whatis.db/ by running ``<tt>makewhatis <sect> Thanks <p> Many thanks to all people who contributed to make XFree86 work on -*BSD, in particular, <bf/David Dawes/, -<bf/Pace Willison/, <bf/Amancio Hasty/, <bf/Christoph Robitschko/, -<bf/Nate Williams/, <bf/Rod Grimes/, <bf/Jack Velte/ and <bf/Michael Smith/. +*BSD, in particular: +<bf/David Dawes/, +<bf/Todd Fries/, +<bf/Rod Grimes/, +<bf/Charles Hannum/, +<bf/Amancio Hasty/, +<bf/Christoph Robitschko/, +<bf/Matthias Scheler/, +<bf/Michael Smith/, +<bf/Ignatios Souvatzis/, +<bf/Jack Velte/, +<bf/Nate Williams/ and +<bf/Pace Willison/. </article> diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/README.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/README.sgml index 1c3a3becf..eb115af83 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/README.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/README.sgml @@ -13,17 +13,18 @@ <title>README for XFree86&tm; &relvers; <author>The XFree86 Project, Inc -<date>16 January 2002 +<date>26 February 2003 <ident> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/README.sgml,v 3.120 2002/09/09 16:04:22 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/README.sgml,v 3.134 2003/02/27 01:19:32 dawes Exp $ </ident> <abstract> -XFree86 is the Open Source port of X.Org's X11R6.6 release that supports -several UNIX(R) and UNIX-like (such as Linux, the BSDs and Solaris x86) -operating systems on Intel and other platforms. +XFree86 is an Open Source version of the X Window System that supports +many UNIX(R) and UNIX-like operating systems (such as Linux, FreeBSD, +NetBSD, OpenBSD and Solaris x86) on Intel and other platforms. This +version is compatible with X11R6.6. </abstract> @@ -36,7 +37,7 @@ operating systems on Intel and other platforms. XFree86 &relvers; is the &whichupdaterel; update to &fullrelvers;, the &whichfullrel; full release in the <![ %earlyrel; [new]]> -XFree86 4 series. +XFree86 4.x series. Update releases are taken from a stable/maintenance branch. They are designed to be installed on top of the full release that they are @@ -48,166 +49,123 @@ stability. <![ %fullrel [ XFree86 &relvers; is the &whichfullrel; full release in the <![ %earlyrel; [new]]> -XFree86 4 series. +XFree86 4.x series. ]]> -<p> -XFree86 release 4 is a major re-design of the basic architectural -underpinnings of XFree86's implementation of the original X Consortium's -X Server. This re-design allows for a modular interaction between the -hardware drivers and the XFree86 core X server. With 4.x, upgrades to -the X server with new and unsupported hardware can be easily done and -installed without undergoing the previous process of rebuilding an X -server. All that is required is installing the new driver module and -updating the configuration file. - -The road to XFree86 release 4 began as an architectural concept in mid -1997, with the serious framework being implemented in code the beginning -of 1998. There were several snapshots on the road to 4.0 which are now -part of the 4.0 base release. -<![ %fullrel [The &relvers; version is an upgrade to -&prevrelvers;, which include more hardware ports, code enhancements and -bug fixes.]]> - -Release 4 also included the long-awaited integration of the DRI (Direct -Rendering Infrastructure). This upgrade into the code base gives -XFree86 the abilities of accelerated direct 3-D graphics rendering, used -widely in games and other visualization programs. - -While some driver available in the old 3.3.x release series have not -been converted over to the 4.x series, those required for most modern -video hardware are available. Please check the <htmlurl name="Driver -Status document" url="Status.html"> first to see whether your hardware -is supported before upgrading to the 4.x series. +<![ %snapshot [ +XFree86 &relvers; is a pre-release snapshot of XFree86 &nextfullrelvers;. +<![ %relcandidate [ +This snapshot is release candidate &rcnum; for version &nextfullrelvers;. +]]> +Pre-release snapshots are provided for beta testing. You should only install +snapshots if you're comfortable dealing with possibly unstable beta-level +software. If you find problems with this snapshot, you are encouraged +to report your findings to the public XFree86 mailing list: +<email>XFree86@XFree86.org</email>. +XFree86 &relvers; is a feature-complete snapshot of XFree86 +&nextfullrelvers;. +]]> + +<p> +XFree86 4.x is the current XFree86 release series. The first release in +this series was in early 2000. The core of XFree86 4.x is a modular +X server. +<![ %fullrel [The &relvers; version is a new release that includes +additional hardware support, functional enhancements and bug fixes.]]> <![ %haverelnotes [ Specific release enhancements can be viewed in the <htmlurl name="Release Notes" url="RELNOTES.html">. ]]> -The XFree86 version numbering system has had some changes as of the -4.0.2 release. Information about this can be found in the -<htmlurl name="Versions Document" url="Versions.html">. +Most modern PC video hardware is supported in XFree86 &relvers;, and +most PC video hardware that isn't supported explicitly can be used with +the "vesa" driver. The <htmlurl name="Driver Status document" +url="Status.html"> has a summary of what hardware is supported in +&relvers; compared with the old 3.3.x (&legacyvers;) series. It is a +good idea to check there before upgrading if you are currently running +&legacyvers; with older hardware. -Information about binary distributions and the attendant installation -instructions can be found in the <htmlurl name="Installation Document" -url="Install.html">. - -Copyright and Licensing information for this release and all XFree86 -releases can be found in the <htmlurl name="License Document" -url="LICENSE.html">. +XFree86 is produced by The XFree86 Project, Inc, which is a group of +mostly volunteer independent developers. XFree86 is a non-commercial +organisation, and would not be viable without the invaluable development +contributions of volunteers. This release is dedicated to all who have +supported and contributed to XFree86 over the last eleven years. <![ %snapshot [ -<sect>Redistribution of the Snapshots +<sect>Redistribution of Snapshots <p> While the XFree86 <htmlurl name="License" url="LICENSE.html"> doesn't -prohibit vendors and others redistributing binaries of this release, we -don't recommend it. We ask that if you do distribute such binaries, -you make it clear that people using then should contact you for support -and not XFree86. +prohibit vendors and others redistributing binaries of this snapshot +release, we don't recommend including them in production releases. ]]> -<sect>Joining The Team -<sect1> Development +<sect>Pointers to additional information <p> -If you would like to work on the development of XFree86 4, either by -helping with the conversion of our older drivers to the new 4.x design, -or assisting in the addition of new drivers or platforms to the code base -then send a request to <url name="join the XFree86 development team" -url="http://www.xfree86.org/developer.html">. This will give you direct -access to the latest XFree86 related development topics and discussions. -Include in your note, your name, email address, reason for joining (what -you will work on) and, level of expertise (coder, DRI, core, specific -driver) and area of interest. - -</sect1> - +The documentation for this release can be found online at the <url +name="XFree86 web site" url="http://www.xfree86.org/&relvers;/">. +Documentation for the latest release version can always be found <url +name="here" url="http://www.xfree86.org/current/">, and documentation +for the latest pre-release snapshot can be found <url name="here" +url="http://www.xfree86.org/snapshot/">. Checking those last two links +is a good way of finding out the latest versions available from XFree86. -<sect1> Documentation -<p> -If instead your interests are on the Documentation side of the Project, -or you want to contribute and are not ready for plunging into the code, -you can join the Documentation Team (those hardy souls responsible for -the content you are reading :-). Amongst the Doc Team's activities are -converting our SGML based documentation into an XML based one and updating -and creating technical documentation used by staff and public. If this -sounds interesting then please send a request to <url name="join the -XFree86 documentation team" url="mailto:signup@xfree86.org">. -Include in your note, you name, email address, reason for joining (what -you will work on) and level of expertise and whether you are interested -in the tools or content side of the group. +Information about binary distributions and the attendant installation +instructions can be found in the <htmlurl name="Installation Document" +url="Install.html">. -</sect1> -</sect> - -<sect> The Public Mailing Lists -<sect1> Newbie -<p> -For those who are new to XFree86 and want to learn more about our -Project we recommend that you join our Newbie list, located at <url name -= "Public Mailing Lists" url = "http://www.xfree86.org/mailman/listinfo">, -where this and other discussions occur with our senior all-volunteer -staff. This is great forum to get introduced to XFree86 and ask for -help on how to set up the XServer or whether your hardware is supported, -and why not?, and make suggestions for future releases of XFree86. -This list is supported by our volunteer staff who needs to know how you -are using and interacting with XFree86 and what is wrong and could be -better. Tell them, they want to know! +Copyright and Licensing information for this release and all XFree86 +releases can be found in the <htmlurl name="License Document" +url="LICENSE.html">. -</sect1> +The XFree86 version numbering system (including historical information) +can be found in the <htmlurl name="Versions Document" url="Versions.html">. -<sect1> Announce -<p> -For those who just want to know the release schedule -this is a good list to join. +Additional information may be available at the <url +name="XFree86 web site" url="http://www.xfree86.org/">, and pointers to +other information are available at the <url name="XFree86 support page" +url="http://www.xfree86.org/support.html">. -<sect1> CVS Commit +<sect>The Public Mailing Lists +<sect1>CVS Commit <p> For those who want to see what has been committed recently to our CVS repository this is the list that will show you those updates. This list is updated dynamically every time the repository is updated after the the commit happens. -<!-- +<sect1>Devel <p> -A followup to the commit list is the soon to be public, patch archives. -This archive will be available on our web-site and will show what patches -have been submitted and will soon be committed. This is helpful for -people who are interested in a specific area and want to know what work -is happening there. When this goes public we will announce it -on our web site and our Announce mailing list, so keep watching. ---> - +This list is available for discussions about XFree86 development and +for following up well-defined bug reports. Many experienced XFree86 +developers are present on this list. -<sect1> Xpert +<sect1>XFree86 <p> -If instead you are the lone developer who is improving XFree86 on an -ad hoc basis for your particular environment (I want to get my mouse or -video card to work), and need a specific question asked then you should -go over to our Xpert list where such questions are raised and answered -by our technical development staff. Remember you do not have to be a -member to write fixes to our code base and if your changes are discrete -and self-contained the volume of developer mail may just be too noisy. - - -Once your work is finished (coded, debugged and documented) please send -your fix to <email>fixes@XFree86.org</email>. This will ensure that -they are included in future releases. And thanks! You make this truly -an Open group. +This list is available for any discussions and questions related to XFree86. +Support related questions should be sent here. Many experienced XFree86 +developers monitor this list. </sect1> </sect> +<sect>Contributing to XFree86 +<p> +If you have any new work or enhancements/bug fixes for existing work, +please submit them to <email>fixes@XFree86.org</email>. This will ensure +that they are included in future releases. For new work, it's usually +a good idea to discuss it first on the <email>devel@XFree86.org</email> +list. + <sect>How to get XFree86 &relvers; <p> <![ %snapshot; [ XFree86 &relvers; can be found at the <url name="XFree86 ftp server" url="ftp://ftp.xfree86.org/pub/XFree86/snapshots/&relvers;/">, and at -mirrors of this server. This snapshot is available primarily in source -form. Binaries for some platforms may be made available at a later -time. +mirrors of this server. This snapshot is available primarily in binary +form for several popular platforms. ]]> <![ %release; [ @@ -239,13 +197,16 @@ README file for that version, which can be found on the ]]> <![ %fullrel [ -The source for version &fullrelvers; is split into three tarballs: +The source for version &fullrelvers; is split into seven tarballs: <tt>X&fullsrcvers;src-1.tgz</tt>, <tt>X&fullsrcvers;src-2.tgz</tt>, -<tt>X&fullsrcvers;src-3.tgz</tt>. The first contains everything except the -fonts and general X11 documentation. It is sufficient for building -XFree86 if you already have a set of fonts. The second contains the -fonts and the source for the general X11 documentation. The third -contains the general X11 documentation in hardcopy format. +<tt>X&fullsrcvers;src-3.tgz</tt>, <tt>X&fullsrcvers;src-4.tgz</tt>, +<tt>X&fullsrcvers;src-5.tgz</tt>, <tt>X&fullsrcvers;src-6.tgz</tt> and +<tt>X&fullsrcvers;src-7.tgz</tt>. The first three contain everything +except the fonts and general X11 documentation. Those three are sufficient +for building XFree86 if you already have a set of fonts. The fourth +and fifth contain the fonts. The sixth contains the source for the +general X11 documentation. The seventh contains the general X11 +documentation in hardcopy format. <![ %onediff; [ A source patch relative to version &prevfullrelvers; is also available. @@ -346,14 +307,18 @@ gzip -d < &prevfullrelvers;-&fullrelvers;.diff4.gz | patch -p0 -E <![ %difftar; [ <![ %removefiles; [ <tscreen><verb> -rm -f xc/extras/freetype2/builds/mac/ftlib.prj -rm -fr xc/extras/freetype2/docs/design -rm -fr xc/extras/freetype2/docs/glyphs -rm -fr xc/extras/freetype2/docs/image -rm -fr xc/extras/freetype2/docs/tutorial -rm -f xc/programs/Xserver/hw/darwin/bundle/English.lproj/MainMenu.nib/objects.nib -rm -f xc/programs/Xserver/hw/darwin/bundle/Japanese.lproj/Localizable.strings -rm -f xc/programs/Xserver/hw/darwin/bundle/Japanese.lproj/MainMenu.nib/objects.nib +rm -f xc/doc/hardcopy/Xext/mit-shm.PS.gz +rm -f xc/doc/hardcopy/saver/saver.PS.gz +rm -fr xc/fonts/scaled/Ethiopic +rm -fr xc/fonts/scaled/Meltho +rm -fr xc/programs/Xserver/hw/darwin/bundle +rm -f xc/programs/Xserver/hw/hp/input/drivers/XHPKeymaps +rm -f xc/programs/Xserver/hw/hp/ngle/ngledoblt.o.8.07 +rm -f xc/programs/Xserver/hw/xwin/X.ico +rm -fr xc/programs/xcursorgen/redglass +rm -fr xc/programs/xcursorgen/whiteglass +touch xc/extras/Mesa/src/Trace/tr_attrib.c +touch xc/lib/fontconfig/NEWS </verb></tscreen> ]]> <tscreen><verb> @@ -362,34 +327,42 @@ gzip -d < &fullrelvers;.tgz | tar vxf - ]]> ]]> +<!-- <![ %prevrelwasupdate; [ Patches might also be available relative to &prevrelvers;. If so, the instructions for applying them are the same, except that you should start with a clean &prevrelvers; source tree. ]]> - -The contrib part of the distribution was folded into the main source -tree a while ago, so a separate contrib tarball is not required. +--> To format the XFree86 documentation use the latest version of our doctools -package available as <tt>doctools-&doctoolsvers;.tgz</tt>. +package available from the XFree86 CVS repository's "doctools" module, +and from our <url name="ftp site" +url="ftp://ftp.xfree86.org/pub/XFree86/misc/doctools-&doctoolsvers;.tgz">. ]]> <!-- fullrel --> -The XFree86 source code can also be accessed via the XFree86 CVS repository. +The XFree86 source code for this and all releases/snapshots as well as +development versions can also be accessed via the XFree86 CVS repository. Information about accessing this can be found at the <url name="CVS page" url="http://www.xfree86.org/cvs/"> on our web site. It's also possible to browse the XFree86 CVS repository at our <url name="CVSWeb server" -url="http://cvsweb.xfree86.org/">. +url="http://cvsweb.xfree86.org/">. The CVS tag for this version is +"&reltag;". +<![ %notsnapshot [ +The CVS tag for the stable branch for this release is "&relbranchtag;". +]]> +To check out the latest development version, don't specify any tag. + <sect>Reporting Bugs <p> Bugs should be reported to <email>XFree86@XFree86.org</email>. Before -reporting bugs, please check the X server log file, which can be found -at <tt>/var/log/XFree86.0.log</tt> on most platforms. If you can't -resolve the problem yourself, send the entire log file with your bug -report but not the operating system core dump. Do not edit the log -file as our developers use it to reproduce and debug your problem. +reporting bugs, please check the XFree86 server log file, which can be +found at <tt>/var/log/XFree86.0.log</tt> on most platforms. If you +can't resolve the problem yourself, send the entire log file with your +bug report but not the operating system core dump. Do not edit the +log file as our developers use it to reproduce and debug your problem. diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/RELNOTES.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/RELNOTES.sgml index cc5965009..4fb915d06 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/RELNOTES.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/RELNOTES.sgml @@ -6,10 +6,10 @@ <title>Release Notes for XFree86™ &relvers; <author>The XFree86 Project, Inc -<date>17 January 2002 +<date>26 February 2003 <ident> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/RELNOTES.sgml,v 1.71 2002/01/21 19:01:35 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/RELNOTES.sgml,v 1.81 2003/02/27 00:45:05 dawes Exp $ </ident> <abstract> @@ -21,6 +21,8 @@ in XFree86 &relvers; and their status. <toc> +<p> + <sect>Introduction to the 4.x Release Series <p> XFree86 4.0 was the first official release of the new XFree86 4 series. @@ -32,35 +34,39 @@ is the latest full release in that series. The current release (&relvers;) is the latest in that series. ]]> XFree86 -4 represents a significant redesign of the XFree86 X server. -Not all of the hardware drivers from 3.3.x have been ported to 4.x yet, -but conversely, 4.x has some hardware support not present in 3.3.x. -Our <htmlurl name="Driver Status document" url="Status.html"> summarizes -how the hardware driver support compares between &legacyvers; and &relvers;. -Please check there first before downloading &relvers;. +4 represents a significant redesign of the XFree86 X server. Not all +of the hardware drivers from 3.3.x have been ported to 4.x yet, but +conversely, 4.x has support for a lot of hardware that is not supported +in 3.3.x. Our <htmlurl name="Driver Status document" url="Status.html"> +summarizes how the hardware driver support compares between &legacyvers; +and &relvers;. Please check there first before downloading &relvers;. The 4.0.1 release introduced a new graphical configuration tool, "<tt>xf86cfg</tt>", and a text mode interface was added to it for the -4.0.2 release. It is work in progress, but definitely worth trying out. -The trusty old text-based tool "<tt>xf86config</tt>" can also be used -for generating X server config files. In addition to these tools, we've -been working on a configuration tool that is built-in to the X -server. It is included in the release, and it works well for some -hardware. To try it out, just run (as root) "<tt>XFree86 -configure</tt>". +4.0.2 release. It is the preferred configuration tool provided by with +XFree86. The trusty old text-based tool "<tt>xf86config</tt>" can also +be used for generating X server config files. In addition to these +tools, the XFree86 server has some built in capabilities for generating +a base config file. This works well for most hardware, and in most +cases is the easiest way to get an initial config file. To try it out, +just run (as root): + +<tscreen><verb> +XFree86 -configure +</verb></tscreen> + Each of these configuration options will give you a reasonable starting point for a suitable configuration file. We've put some effort into documenting the &relvers; config file format, and you can find that -information in the XF86Config manual page. Check that, the driver manual -pages and the related documentation for further information. +information in the <htmlurl name="XF86Config manual page" +url="XF86Config.5.html">. Check there and the driver-specific manual +pages and the related documentation for further information. References +to this driver-specific information can be found in the <ref id="drivertables" +name="tables below">. -<!-- -Oh, another thing you might notice is that our documentation is rather -patchy. Most of what is present should be in reasonable shape, but -there are gaps. We thought it better to leave out docs that were very -out of date rather than providing inaccurate and misleading information. -We are looking for people to also help fill those gaps in <hint hint -:->. ---> +We have plans to make the configuration file optional in a future release. +The XFree86 server is close to being able to automatically determine +a complete base configuration for most popular hardware configurations. Before you go to download and install the binary distributions for this release, please have a quick read through the <htmlurl @@ -94,38 +100,37 @@ don't have enough space to cover them all here. <p> <itemize> -<item> An s3 driver is added, which provides support for many of the - older non-ViRGE and non-Savage S3 chipsets. -<item> Some vmware driver problems are fixed, and the driver is updated - to take advantage of VMWare Workstation 3.0 features. These - include improved hardware cursor handling and support for 8 bit - emulation. -<item> Support added for Trident *BladeXP chipsets (currently not-accelerated). -<item> Xv support added for Trident TGUI series chips (not 9440 though). -<item> Support added for the older Trident chipsets again for ISA/VLBus (not tested) -<item> Support added to the glint driver for 3DLabs Permedia4, GLINT R4 and - Gamma 2 chipsets. -<item> Support added to the i810 driver for Intel i830 (tested on Linux only). -<item> Support added to the ATI radeon driver for Radeon 7500 (2D and 3D), - Radeon 8500 (2D only), and Rage128ProII. -<item> Support added for the Matrox G550 support. This included dual-head - support. -<item> Support added for NVIDIA nForce integrated graphics. -<item> The NVIDIA nv driver now has preliminary powerpc support for the - NV11 and NV20. -<item> Support added to the NVIDIA nv driver for interlaced modes on - hardware that supports this, and support for resolutions higher - than 1600x1200. -<item> Fixes for the savage driver on 64-bit platforms, XVideo support for the - SuperSavage, and other savage driver updates. -<item> The ATI r128 driver now uses the CCE DMA engine for 2D acceleration - when direct rendering is enabled, which reduces context switching - overhead and improves stability and performance for XVideo and some 2D - operations. -<item> The fbdev driver now supports rotation. -<item> Various updates to the apm, ark, chips (C&T), cirrus, i128, - neomagic, newport, s3virge, siliconmotion, sis, tdfx, tseng, vesa, - and vga drivers. +<item> ATI Radeon 9x00 2D support added, and 3D support added for the + Radeon 8500, 9000, 9100, and M9. The 3D support for the Radeon + now includes hardware TCL. + +<item> Support added to the i810 driver for Intel 845G, 852GM, 855GM + and 865G integrated graphics chipsets, including 2D, 3D (DRI) + and XVideo. Support for the 830M has been improved, and XVideo + support added. + +<item> National Semiconductor SC1x00, GX1, and GX2 chipset support added + with the "nsc" driver. + +<item> Support added for the NVIDIA nForce2 integrated graphics, GeForce 4, + and GeForce FX. + +<item> Major SiS driver updates for some of the latest chipsets. Unfortunately + the SiS 3D driver has had to be disabled because no one has yet + taken up the challenge to port it to Mesa 4.x. + +<item> The s3virge driver now has support for double scan modes on the DX + (with XVideo disabled). + +<item> Updates to the savage driver, including fixing problems with the + TwisterK, and problems with incorrect memory size detection. + +<item> 2D acceleration added for the Trident CyberBladeXP/Ai1 chipsets. + +<item> Support for big endian architectures has been added to the C&T + driver. + +<item> Various updates and bug fixes have been made to most other drivers. </itemize> @@ -133,98 +138,130 @@ don't have enough space to cover them all here. <p> <itemize> -<item> The mouse driver now has support for mouse wheel emulation. -<item> The mouse driver can now handle replug events on Linux for PS/2 mice. -<item> The "Min/Max X/Y Position" options in the elographics and mutouch - drivers are changed to "Min/Max X/Y" to be consistent with the other - input drivers. -<item> Linux USB keyboard access is fixed when no PS/2 controller is present. -<item> Added calcomp input driver. -<item> Added DMC input driver. -<item> Added hyperpen input driver. +<item> The mouse driver now has automatic protocol detection for PS/2 mice. + +<item> Several new input drivers have been added, including tek4957, + jamstudio (js_x), fpit, palmax, and ur98 (Linux only). </itemize> <sect1>X Server and Extension Updates <p> <itemize> -<item> Resynced with X.Org's X11R6.6. -<item> Mesa updated to the post-3.4.2 3.4 branch version as of November 2001. -<item> DRI drivers resynced with the latest from the DRI project. -<item> Various updates to the Xft library. -<item> The DEC-XTRAP extension is now available. -<item> The PEX and XIE extensions are no longer built/distributed by default. -<item> A security problem related to glyph clipping for large origins is fixed. -<item> An i810 XvMC (motion compensation) driver is now available (Linux only). -<item> A fatal bug XVideo Xineramification bug is fixed. +<item> Support for the RandR extension has been partially integrated + into the XFree86 server, providing support for resizing the root + window at run-time. + +<item> The Mesa version used for OpenGL® 1.3 and DRI + driver support has been updated to 4.0.4. + +<item> The XFree86 server's hot keys (including those for switching + modes and virtual terminals) can now be configured via XKB. + Previously they were hard coded. An X server configuration + option has been added to allow the VT switching hot keys to be + disabled. + </itemize> <sect1>Client and Library Updates <p> <itemize> -<item> FreeType2 updated to version 2.0.6. -<item> Added libGL man pages. -<item> Xload now has support for displaying the load of remote hosts. -<item> Xterm updated to patch level 165. -<item> SuperProbe is removed. -<item> Sample xtrap clients added. +<item> An Xcursor library providing support for alpha blended (ARGB) + and animated cursors. Two Xcursor themes are provided (redglass + and whiteglass), as well as the default "core" theme (the traditional + cursors). + +<item> Xterm updated to patch level 173, including the following bugfixes: + <itemize> + <item> Fix two infinite loops (special cases of mouse hilite tracking, + DECUDK parsing). + <item> Make repainting of the 256-color example work properly. + <item> Modify parser tables to improve detection of malformed + control sequences, making xterm behave more like a real + DEC terminal. + <item> Fix a problem with the blinking cursor which occasionally caused + xterm to pause until a key was pressed. + <item> Fix improper parsing of multiple items in the ttyModes resource. + + </itemize> + and the following improvements: + <itemize> + <item> Modify xterm to invoke luit. + <item> Add simple session management client capabilities. + <item> Add a modifyCursorKeys resource to control how the shift- and + similar modifiers are used to make a cursor escape sequence. + <item> Check if the printerCommand resource string is empty, + and use this to allow the user to disable printer function. + <item> Sort the options list which is displayed in help- and + syntax-messages at runtime to simplify maintenance. + </itemize> + </itemize> <sect1>I18N and Font Updates <p> <itemize> -<item> New Luxi scalable fonts (TrueType and Type 1) from Bigelow & - Holmes. - These fonts are original designs by Kris Holmes and Charles Bigelow. - See <ref id="luxi" name="below"> for further information. -<item> More locale/international keyboards supported. -<item> Modularized I18N support in Xlib is included from X11R6.6. -<item> A problem that caused bdftopcf to sometimes write corrupted fonts - is fixed. -<item> Some problem with Xlib's handling of CTEXT and multi-byte - characters are fixed. -<item> The fontenc layer is updated, and the fontenc library is now installed - and available for other applications. -<item> Improvements to the input method framework in Xlib for UTF-8 locales. -<item> A filter called ``luit'' is added, which provides locale and - ISO 2022 support to any Unicode terminal, notably xterm. - Use of luit is still experimental in this release. +<item> FreeType2 updated to version 2.1.1. + +<item> The "freetype" X server font backend has undergone a partial rewrite. + The new version is based on FreeType 2, and handles TrueType + (including OpenType/TTF), OpenType/CFF and Type 1 fonts. The old + "type1" backend is now deprecated, and is only used for CIDFonts + by default. + +<item> A new utility called "mkfontscale", which builds fonts.scale files, + has been added. + +<item> The Xft library has undergone a major restructuring, and is now + split into fontconfig (which deals with font discovery and + configuration and is independent from X), and Xft itself (which + uses fontconfig and deals with font rasterisation and rendering. + The format of the Xft font configuration files has changed in + an incompatible manner. + +<item> Support has been added to the Xft library to do rendering with the + core X11 protocol. This allows clients using this library to + render to X servers that don't have support for the RENDER extension. + +<item> There has been a significant reworking of the XKB support to allow + multi-layout configurations. Multi-layout configurations provide + a flexible way of supporting multiple language layouts and switching + between them. + </itemize> <sect1>OS Support Updates <p> <itemize> -<item> Build problems on both QNX4 and QNX6 are fixed. -<item> VT switching problems with the i810 driver on FreeBSD are worked around. -<item> Problems building modules with some enhanced versions of gcc are fixed. -<item> Lots of updates for Darwin/Mac OS X, including: +<item> Updates for Darwin/Mac OS X, including: <itemize> - <item> On Mac OS X, a new rootless mode is added to the XDarwin - X server. This allows X clients to display windows on - the Aqua desktop. - <item> Xinerama support added to XDarwin - <item> With XDarwin in full screen mode, the depth, size, and refresh - rate can now be chosen to be different from the settings - used by Aqua. - <item> GLX support added for Darwin and Mac OS X with software - rendering. - <item> Keymap setup in XDarwin is improved, particularly for - international keyboards. - <item> In addition to English and Japanese, the XDarwin user - interface is now localized in Dutch, French, German, Spanish, - and Korean. + <item> Indirect GLX acceleration added. + <item> Smaller memory footprint and faster 2-D drawing in rootless + mode. + <item> Full screen mode now uses shadowfb for much faster 2-D drawing. + <item> Native fonts can be used on MacOS X. </itemize> -<item> Lots of Cygwin support updates. -<item> Support added for OpenBSD/powerpc. -<item> Build support added for Linux on IBM S/390. -<item> Removed stale support for Amoeba and Minix. -<item> Client-side support added for sparc64 on NetBSD and OpenBSD. -<item> Support added for building the X server on Linux/m68k. -<item> Support added for building on Linux/arm32. -<item> Updates to Linux/mips support. + +<item> Various Cygwin support updates, including an experimental rootless + X server for Cygwin/XFree86. + +<item> AMD x86-64 support (primarily for Linux so far) has been added. + +<item> Support added for OpenBSD/sparc64. + +<item> Major OS/2 support updates. + +<item> Major SCO OpenServer updates. + +<item> Multi-head support has been added for 460GX-based Itanium systems, + and for ZX1-based Itanium2 systems. + +<item> Experimental support for SunOS/Solaris on UltraSPARC systems. + + </itemize> A more complete list of changes can be found in the CHANGELOG that is @@ -237,7 +274,7 @@ url="http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/CHANGELOG?r <p> --> -<sect>Drivers +<sect>Drivers<label id="drivertables"> <p> <sect1>Video Drivers @@ -255,7 +292,8 @@ XFree86 &relvers; includes the following video drivers: <tabrow><tt>ati</tt><colsep>ATI<colsep><htmlurl name="README.ati" url="ati.html">, <htmlurl name="README.r128" url="r128.html">, <htmlurl - name="r128(4)" url="r128.4.html"></tabrow> + name="r128(4)" url="r128.4.html">, <htmlurl + name="radeon(4)" url="radeon.4.html"></tabrow> <tabrow><tt>chips</tt><colsep>Chips & Technologies<colsep><htmlurl name="README.chips" url="chips.html">, <htmlurl name="chips(4)" url="chips.4.html"></tabrow> @@ -273,7 +311,7 @@ XFree86 &relvers; includes the following video drivers: name="i128(4)" url="i128.4.html"></tabrow> <tabrow><tt>i740</tt><colsep>Intel i740<colsep><htmlurl name="README.i740" url="i740.html"></tabrow> - <tabrow><tt>i810</tt><colsep>Intel i810<colsep><htmlurl + <tabrow><tt>i810</tt><colsep>Intel i8xx<colsep><htmlurl name="README.i810" url="i810.html">, <htmlurl name="i810(4)" url="i810.4.html"></tabrow> <tabrow><tt>imstt</tt><colsep>Integrated Micro Solns<colsep> </tabrow> @@ -284,6 +322,8 @@ XFree86 &relvers; includes the following video drivers: <tabrow><tt>newport</tt> (-)<colsep>SGI Newport<colsep><htmlurl name="README.newport" url="newport.html">, <htmlurl name="newport(4)" url="newport.4.html"></tabrow> + <tabrow><tt>nsc</tt><colsep>National Semiconductor<colsep><htmlurl + name="nsc(4)" url="nsc.4.html"></tabrow> <tabrow><tt>nv</tt><colsep>NVIDIA<colsep><htmlurl name="nv(4)" url="nv.4.html"></tabrow> <tabrow><tt>rendition</tt><colsep>Rendition<colsep><htmlurl @@ -298,7 +338,8 @@ XFree86 &relvers; includes the following video drivers: <tabrow><tt>siliconmotion</tt><colsep>Silicon Motion<colsep><htmlurl name="siliconmotion(4)" url="siliconmotion.4.html"></tabrow> <tabrow><tt>sis</tt><colsep>SiS<colsep><htmlurl - name="README.SiS" url="SiS.html"></tabrow> + name="README.SiS" url="SiS.html">, <htmlurl + name="sis(4)" url="sis.4.html"></tabrow> <tabrow><tt>sunbw2</tt> (+)<colsep>Sun bw2<colsep> </tabrow> <tabrow><tt>suncg14</tt> (+)<colsep>Sun cg14<colsep> </tabrow> <tabrow><tt>suncg3</tt> (+)<colsep>Sun cg3<colsep> </tabrow> @@ -306,7 +347,8 @@ XFree86 &relvers; includes the following video drivers: <tabrow><tt>sunffb</tt> (+)<colsep>Sun Creator/3D, Elite 3D<colsep> </tabrow> <tabrow><tt>sunleo</tt> (+)<colsep>Sun Leo (ZX)<colsep> </tabrow> <tabrow><tt>suntcx</tt> (+)<colsep>Sun TCX<colsep> </tabrow> - <tabrow><tt>tdfx</tt><colsep>3Dfx<colsep> </tabrow> + <tabrow><tt>tdfx</tt><colsep>3Dfx<colsep><htmlurl + name="tdfx(4)" url="tdfx.4.html"></tabrow> <tabrow><tt>tga</tt><colsep>DEC TGA<colsep><htmlurl name="README.DECtga" url="DECtga.html"></tabrow> <tabrow><tt>trident</tt><colsep>Trident<colsep><htmlurl @@ -355,16 +397,29 @@ XFree86 &relvers; includes the following input drivers: name="dmc(4)" url="dmc.4.html"></tabrow> <tabrow><tt>dynapro</tt><colsep>Dynapro<colsep> </tabrow> <tabrow><tt>elographics</tt><colsep>EloGraphics<colsep> </tabrow> + <tabrow><tt>elographics</tt><colsep>EloGraphics<colsep> </tabrow> + <tabrow><tt>fpit</tt><colsep>Fujitsu Stylistic Tablet PCs<colsep><htmlurl + name="fpit(4)" url="fpit.4.html"></tabrow> <tabrow><tt>hyperpen</tt><colsep>HyperPen<colsep> </tabrow> + <tabrow><tt>js_x</tt><colsep>JamStudio pentablet<colsep><htmlurl + name="js_x(4)" url="js_x.4.html"></tabrow> + <tabrow><tt>kbd</tt><colsep>generic keyboards (alternate)<colsep><htmlurl + name="kbd(4)" url="kbd.4.html"></tabrow> <tabrow><tt>keyboard</tt><colsep>generic keyboards<colsep><htmlurl name="keyboard(4)" url="keyboard.4.html"></tabrow> <tabrow><tt>microtouch</tt><colsep>MicroTouch<colsep> </tabrow> <tabrow><tt>mouse</tt><colsep>most mouse devices<colsep><htmlurl name="mouse(4)" url="mouse.4.html"></tabrow> <tabrow><tt>mutouch</tt><colsep>MicroTouch<colsep> </tabrow> + <tabrow><tt>palmax</tt><colsep>Palmax PD1000/PD1100<colsep><htmlurl + name="palmax(4)" url="palmax.4.html"></tabrow> <tabrow><tt>penmount</tt><colsep>PenMount<colsep> </tabrow> <tabrow><tt>spaceorb</tt><colsep>SpaceOrb<colsep> </tabrow> <tabrow><tt>summa</tt><colsep>SummaGraphics<colsep> </tabrow> + <tabrow><tt>tek4957</tt><colsep>Tektronix 4957 tablet<colsep><htmlurl + name="tek4957(4)" url="tek4957.4.html"></tabrow> + <tabrow><tt>ur98(*)</tt><colsep>Union Reality UR-F98 headtracker<colsep><htmlurl + name="ur98(4)" url="ur98.4.html"></tabrow> <tabrow><tt>void</tt><colsep>dummy device<colsep><htmlurl name="void(4)" url="void.4.html"></tabrow> <tabrow><tt>wacom</tt><colsep>Wacom tablets<colsep><htmlurl @@ -372,6 +427,8 @@ XFree86 &relvers; includes the following input drivers: </tabular> </table> +Drivers marked with (*) are available for Linux only. + <sect>Overview of XFree86 4.x. <p> Unlike XFree86 3.3.x where there are multiple X server binaries, each @@ -534,7 +591,7 @@ EndSection The new option <tt>AllowDeactivateGrabs</tt> allows deactivating any active grab with the key sequence <tt>Ctrl+Alt+Keypad-Divide</tt> and the new option <tt>AllowClosedownGrabs</tt> allows closing the - conection to the grabbing client with the key sequence + connection to the grabbing client with the key sequence <tt>Ctrl+Alt+Keypad-Multiply</tt>. Note that these options are off by default as they allow users to remove the grab used by screen saver/locker programs. @@ -617,8 +674,9 @@ Section "ServerLayout" EndSection </verb></quote> -See the XF86Config man page for a more detailed explanation of the format -of the new ServerLayout section. +See the <htmlurl name="XF86Config(5)" url="XF86Config.5.html"> man page +for a more detailed explanation of the format of the new ServerLayout +section. </itemize> @@ -949,33 +1007,15 @@ configuring XFree86 to use an existing FreeType installation. The Xft library uses a configuration file, <tt>XftConfig</tt>, which contains information about which directories contain font files and also provides a sophisticated font aliasing mechanism. Documentation for that -file is included in the Xft man page. +file is included in the <htmlurl name="Xft(3)" url="Xft.3.man"> man page. </sect2> <sect2>FreeType support in Xft <p> -XFree86 &relvers; includes sources for FreeType version 2.0.6, and, by +XFree86 &relvers; includes sources for FreeType version 2.1.1, and, by default, they are built and installed automatically. -<p> - -If you prefer, you can configure XFree86 &relvers; to use an existing -Freetype2 installation by telling XFree86 not to build the internal copy and -indicating where that external version has been installed. Edit (or create) -<tt>config/cf/host.def</tt> to include: - -<itemize> - <item><tt>#define BuildFreetype2Library NO</tt> - <item><tt>#define Freetype2Dir /usr/local</tt> -</itemize> - -Note that XFree86 assumes you'll be using a release FreeType no older than -version 2.0.1. Early FreeType version 2 releases used a different header file -installation and aren't compatible with XFree86. Instructions for building and -installing FreeType can be found in the <tt>INSTALL</tt> file included with -the FreeType release. - </sect2> <sect2>Application Support For Anti-Aliased Text @@ -1024,143 +1064,18 @@ new features should be completed in a future release. <p> --> -<sect1>Xaw -<p> - -Two versions of the Xaw library are provided with XFree86 4.x. A version with -bug fixes and a few binary compatible improvements and a new version with -several new features. - -New features: - -<itemize> - - <item>A <tt>displayList</tt> resource is available to all Xaw widgets. It - basically consists of a list of drawing commands, fully described in - the <tt>Xaw(3)</tt> manual page, that enables a integration of Xaw - programs with the new window/desktop managers that allows for - configurable themes. - - <item>Some new actions were added to all Xaw widgets, to allow more - configurable control of the widgets, and to allow setting resources - at run time. - - <item>Since Xpm was integrated into XFree86, programs linked with the - new Xaw library will also link with Xpm. This allows for color - background pixmaps, and also for shaped widgets. - - <item>The text widget is the widget that will present more changes. These - include: - - <itemize> - - <item>Block cursor. - - <item>Compile time limit of 16384 undo/redo levels (that will - automatically grow if the text is not saved when this mark is - reached). - - <item>Overwrite mode. - - <item>Text killed is inserted in a kill ring list, this text is not - forgotten, pressing <tt>M-y</tt> allows traversing the kill - ring list. - - <item>International support for latin languages is available even - if the <tt>international</tt> resource is not set. Users will - need to properly set the <it>locale</it> environment to make - complete use of this feature. - - <item>A better <tt>multiply</tt> interface is provided. Pressing - <tt>C-u,<number></tt> (where number can be negative) - allows passing parameters for text actions. - - <item>Text can be formatted to have left, right, center or full - justification. - - <item>Text indentation support is also available. - - </itemize> - -</itemize> - -Bug fixes: - -<itemize> - - <item>The simple menu widget geometry management code was improved to solve - problems with menu entries not visible in the screen. - - <item>The form widget geometry code was changed to solve problems with integer - round problems in the child widgets geometry when resizing the parent - form widget. - - <item>Several bugs were fixed in the text code, while some code was rewritten - from scratch. - -</itemize> - -<p> - -<sect1>Xpm -<p> - -Version 3.4k of the Xpm (X pixmap) library is now integrated into XFree86. - <sect1>xedit <p> -Xedit have been changed to use most of the new features added to the new -version of the Xaw library, and some xedit only features were added. Emacs -users will find that several of the emacs key bindings work with the new -version of xedit. These include: - +Xedit has several new features, including: <itemize> - - <item>File name tab completion. Including a <it>Emacs dired</it> like window, - that will be shown when there are more than one match, when - <tt>C-x,d</tt> is pressed, or when a directory name is specified. - - <item>An unlimited number of files can be edited at the same time. Including - multiple views of the same or different files. - - <item>The line number of the cursor position is always visible. It can also - be customized to show the column number, the position offset and the - current size of the file. - - <item>There is an <tt>autoReplace</tt> resource, that enables automatic text - replacement at the time text is typed. This feature is useful to create - simple macros, or to correct common spelling errors. - - <item>A fully featured ispell interface is also available. This interface - is expected to provide most of the features of the terminal interface - of the ispell program, with some extra features that include: - - <itemize> - - <item>A compile time limit of 16 undo levels. - - <item>Terse mode switch. - - <item>Dictionary change. - - <item>The interface also checks for repeated words. - - </itemize> - - <item>A first tentative to add programming modes was done. Currently, there - is one mode: - <itemize> - - <item><bf>C-mode:</bf> this mode is expected to be stable, and fully - usable. - </itemize> - + <item>An embedded lisp interpreter that allows easier extension of the editor. + <item>Several new syntax highlight modes, and indentation rules for C and Lisp. + <item>Flexible search/replace interface that allows regex matches. + <item>Please refer to <tt><htmlurl name="xedit(1)" url="xedit.1.html"></tt> + for more details. </itemize> -<p> - - <!-- <sect>Fonts and Internationalisation <p> diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/SCO.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/SCO.sgml index 17b376a36..b13bde41b 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/SCO.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/SCO.sgml @@ -4,11 +4,11 @@ <!-- TitleS information --> <title>Information for SCO OpenServer Users -<author>J. Kean Johnston (jkj@caldera.com) -<date>22 January 2002 +<author>J. Kean Johnston (jkj@sco.com) +<date>14 February 2003 <ident> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/SCO.sgml,v 3.20 2002/06/03 21:22:09 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/SCO.sgml,v 3.22 2003/02/17 18:58:07 dawes Exp $ </ident> <!-- Table of contents --> @@ -21,23 +21,46 @@ $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/SCO.sgml,v 3.20 2002/06/03 21: Before you can either compile or execute a binary distribution of XFree86, the following conditions must be met: <itemize> - <item>Ensure that you are running Release 5.0.5 or later. This is required + <item>Ensure that you are running Release 5.0.4 or later. This is required because OSS646 is only supported on those platforms. There are no plans to support XFree86 on earlier releases of OpenServer. - <item>Ensure OSS646, the ``Linkers and Libraries Update'' package is + <item>Ensure that OSS646, the ``Execution Environment Update'' package is installed, if appropriate. Check the release notes for that update to see whether or not your current operating system requires this - update. This supplement will be available to the public in March - 2002. - <item>To compile XFree86, you must use the Caldera-supported version of + update. This supplement will be available to the public in February + 2003. + <item>Ensure that OSS631, the "Graphics, Web and X11 Libraries" package + is installed. This ships standard with release 5.0.7 and later, and + is only required for 5.0.[456] users. This package will be updated fairly + frequently, and it us always suggested you have the latest possible + version installed. At some point in the future it may even update the + libraries in 5.0.7, so it is worth checking the release notes for this + supplement. + <item>To compile XFree86, you must use the SCO-supported version of the GNU C Compiler. It is possible that Skunkware versions of the compiler will work too, but this has not been tested. The ``GNU Development System'' is available for all releases from (and including) SCO OpenServer Release 5.0.5. It is provided with the operating system in all versions from Release 5.0.7, although you need to run ``custom'' to install it from the media. You can always download the latest - latest version of the GNU Development System from the Caldera Web - site at <tt>http://www.caldera.com</tt>. + latest version of the GNU Development System from the <url + name="SCO Web site" url="http://www.sco.com">. + <item>If you are not using OSR 5.0.7 or later, you need to get an updated + console driver. See <url url="http://www.sco.com"> for details on + OpenServer supplements. If you can't or don't want to upgrade your + console driver, XFree86 will still compile, but you may run into + problems with some cards such as the Riva TNT and ATI Rage cards. + The problem with the console driver in 5.0.6A and earlier is that + when the X server sets graphics mode, the driver does not set a + status bit, so any text that is sent directly to <tt>/dev/console</tt>, + such as kernel warning or notice messages when you access tape drives + or NFS notices, will be sent to the console video memory. This just + happens to be slap bang in the middle of palette data for the Riva + TNT, so you get color map corruption. The updated console driver + also has an improved mechanism for allocating video memory that + XFree86 detects at compile time, and it will use it if it exists. + It is STRONGLY recommended that you get the console driver update. + </itemize> <sect>Compiling XFree86<p> @@ -71,6 +94,9 @@ To actually start the compilation, perform the following steps: <item>If the build succeeded, install the new server by executing the command <tt>make install 2>&1 | tee install.log</tt> as root. This will send the install results to the file <tt>install.log</tt>. + + <item>If you want to install the manual pages, execute the command + <tt>make install.man 2>&1 | tee -a install.log</tt> as root. </itemize> <sect>Before Running XFree86<p><label id="sec-runxf86"> @@ -79,15 +105,13 @@ The SCO <tt/xterm/ terminfo description is not compatible with the <tt/xterm/ in the R5 distribution.<p> To use a Bus/Keyboard or PS2 mouse you should configure the mouse drivers -under SCO as above using '<tt>mkdev mouse</tt>'. You may then use the -<tt>OsMouse</tt> option -in your XF86Config to specify that XFree86 should use the SCO mouse drivers. -To do this, set the <tt>Protocol</tt> to "<tt>OsMouse</tt>" in the -Pointer section of your -XF86Config file. You can also use "<tt>OsMouse</tt>" for your -serial mouse, -especially if you are having trouble getting your mouse to work using the -XFree86 mouse drivers.<p> +using '<tt>mkdev mouse</tt>'. You may then use the +<tt>OsMouse</tt> option in your <tt>XF86Config</tt> to specify that XFree86 +should use the SCO mouse drivers. To do this, set the <tt>Protocol</tt> to +"<tt>OsMouse</tt>" in the <tt>Pointer</tt> section of your +<tt>XF86Config</tt> file. You can also use "<tt>OsMouse</tt>" for your +serial mouse, especially if you are having trouble getting your mouse to +work using the XFree86 mouse drivers.<p> <sect>Switching Consoles<p> @@ -98,18 +122,24 @@ you to console 1. <tt>Ctrl-Alt-FXX</tt>, where <tt>XX</tt> is a function key between <tt>F1</tt> and <tt>F12</tt> will switch you to the console number assigned to that function key. <tt>F1</tt> corresponds to <tt>tty01</tt> (or console 1), <tt>F2</tt> corresponds to <tt>tty02</tt> -(or console 2) etc. Those interested in modifying the console switching -should look in <tt>xc/programs/Xserver/hw/xfree86/common/xf86Events.c</tt>. +(or console 2) etc.<p> + +Unlike the SCO X server, the "kill me now" key is <tt>Alt+Ctrl+Backspace</tt>. +This does not ask for confirmation, it simply kills the X server as +immediately as possible. Use with extreme caution. This may cause +applications to terminate in an unpredictable way. You can set the +<tt>DontZap</tt> option in the <tt>ServerFlags</tt> section of your +<tt>XF86Config</tt> file to disable this. <sect>Setting up Man Pages<p> After compiling the tree, or after installing the binary distribution you -can get man to recognise the XFree86 man pages by adding +can get <tt>man</tt> to recognise the XFree86 man pages by adding <tt>/usr/X11R6/man</tt> to the <tt>MANPATH</tt> in <tt>/etc/default/man</tt>. The line should look similar to: <tscreen><verb> - MANPATH=/usr/man:/usr/X11R6/man + MANPATH=/usr/man:/usr/gnu/man:/usr/X11R6/man:/usr/local/man </verb></tscreen> This allows all users to view the X man pages. You may change your own <tt>MANPATH</tt> environment variable if you do not want everyone to access the @@ -119,13 +149,17 @@ By default the man pages are compressed using ``<tt>compress</tt>'' to conserve space. If you do not want to compress the man pages change <tt>CompressManPages</tt> to <tt>NO</tt> in your ``<tt>host.def</tt>'' file. Those using the binary distribution can use ``<tt>uncompress</tt>'' -to uncompress the man pages. +to uncompress the man pages. Binary distributions contain pre-formatted +versions of all man pages. If you are compiling the server yourself, you +need to have the GNU Tools package installed to get groff, the GNU +nroff replacement, to format the man pages. Use the <tt>manroff</tt> +script to format the manual pages yourself. <sect>Using SCO binaries/servers.<p> XFree86 will accept connections from SCO binaries (R3 upwards) and the SCO R5 server will also accept connections from XFree86 binaries. This means you may mix and match the two if you have ODT. For example you may -still use the Motif window manager (mwm) if you prefer. +still use the Panning Motif window manager (pmwm) if you prefer. </article> diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/Solaris.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/Solaris.sgml index 97a48f082..8061af855 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/Solaris.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/Solaris.sgml @@ -6,6 +6,10 @@ <author>David Holland, modified by Marc Aurele La France <date>2001 October 01 +<ident> +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Solaris.sgml,v 1.4 2003/01/04 04:20:23 dawes Exp $ +</ident> + <!-- Table of contents --> <toc> @@ -208,10 +212,5 @@ reported!). It might even have broken some aspects of the x86 port.<p> </enum> <sect>Bug Notification<p> -Bug reports should be sent to one of the <bf/XFree86@XFree86.org/, -<bf>Xpert@XFree86.org</bf>, or <bf>Newbie@XFree86.org</bf> (depending on your -level of comfort). -<verb> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Solaris.sgml,v 1.3 2002/01/25 21:55:53 tsi Exp $ -</verb> +Bug reports should be sent to <email>XFree86@XFree86.org</email>. </article> diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/Status.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/Status.sgml index f491a90ed..297c135bb 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/Status.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/Status.sgml @@ -6,10 +6,10 @@ <title>Driver Status for XFree86™ &relvers; <author>The XFree86 Project, Inc -<date>16 January 2002 +<date>23 February 2003 <ident> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Status.sgml,v 1.37 2002/01/16 20:38:45 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Status.sgml,v 1.43 2003/02/25 16:32:41 dawes Exp $ </ident> <abstract> @@ -17,8 +17,7 @@ $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Status.sgml,v 1.37 2002/01/16 This document provides information about the status of the driver and hardware support in XFree86 &relvers; compared with that in XFree86 &legacyvers;. Please send updates for this document to -<email>fixes@xfree86.org</email>. Please do not send requests for -information or support to that address (they will not be answered). +<email>XFree86@XFree86.org</email>. </abstract> @@ -369,17 +368,21 @@ other architectures known to work on (e.g., Alpha, PPC), etc. than 1MB of video memory. <tag>&relvers;:</tag> - Support (accelerated) for the Intel i740 is provided by the "i740" - driver, and support for the Intel i810 (including i810-dc100 and - i810e), i815, and i830 is provided by the "i810" driver. The - "i810" driver is currently supported only on Linux and FreeBSD (4.1 - and later), and requires AGP GART kernel support. + Support (accelerated) for the Intel i740 is provided by the + "i740" driver, and support for the Intel integrated graphics + chipsets i810, i810-dc100, i810e, i815, 830M, 845G, 852GM, 855GM + and 865G is provided by the "i810" driver. The i810 and i815 + chipsets require kernel-level AGP GART support (available on + Linux, FreeBSD, and some other BSDs). The 830M and later can + be used without AGP GART support, but it is required for full + functionality. <tag>Summary:</tag> The i740 and and original i810 are supported in both versions, but - the i810 is supported only on Linux/x86 and recent FreeBSD/i386 - platforms at present. Support for later versions of the i810 - chipset, such as the i815, exists only in &relvers;. + the i810/i815 is supported only on Linux, FreeBSD, and some recent + NetBSD/OpenBSD versions at present. platforms at present. + Support for later versions of the i810 chipset, such as the + i815, and for the 830M and later exists only in &relvers;. </descrip> @@ -420,6 +423,15 @@ other architectures known to work on (e.g., Alpha, PPC), etc. </descrip> +<sect>National Semiconductor +<p> +<descrip> +<tag>&relvers;:</tag> + Support for the SC1x00, GX1, and GX2 is provided by the "nsc" + driver. + +</descrip> + <sect>NCR <p> <descrip> @@ -624,14 +636,15 @@ other architectures known to work on (e.g., Alpha, PPC), etc. by the XF86_SVGA server with the sis driver. <tag>&relvers;:</tag> - Support (accelerated) for the SiS <!-- 86C205, 86C215, 86C225, --> - <!-- 5597, 5598, --> 530, 620, 6326 is provided by the "sis" driver. - The 630, 300, and 540 are also supported, but this code is new and - there are some problems with it in this version. + Support (accelerated) for the SiS 5597, 5598, 6326, 530, 620, + 300, 540, 630, 730, 315, 550, 650, 651 and 740 is provided by + the "sis" driver. The Xabre (SiS 330) might be supported by this + is completely untested. <tag>Summary:</tag> - Support for the 86C201, 86C202, 86C205, 86C215, 86C225, 5597 and 5598 - is currently only available in &legacyvers;. + Support for the 86C201, 86C202, 86C205, 86C215 and 86C225 is + currently only available in &legacyvers;. Support for some + newer chipsets is only available in &relvers;. </descrip> @@ -702,9 +715,7 @@ other architectures known to work on (e.g., Alpha, PPC), etc. <tag>Summary:</tag> The following (older) chipsets are supported in &legacyvers; and - not in &relvers;: TVGA8200LX, TVGA8800CS, TVGA8900B, TVGA8900C, - TVGA8900CL, TVGA9000, TVGA9000i, TVGA9100B, TVGA9200CXr, - TGUI9400CXi, TGUI9420, and TGUI9430DGi. + not in &relvers;: TVGA8200LX, TVGA8800CS, TGUI9420, TGUI9430DGi. The TVGA8900B, TVGA8900C, TVGA8900CL, TVGA9000, TVGA9000i, TVGA9100B, TVGA9200CXr, TGUI9400CXi, TGUI9440AGi, TGUI9660, diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/Versions.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/Versions.sgml index c84307280..4eea959f8 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/Versions.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/Versions.sgml @@ -7,10 +7,10 @@ <title>XFree86 Version Numbering Schemes <author>The XFree86 Project, Inc -<date>16 January 2002 +<date>23 February 2003 <ident> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Versions.sgml,v 1.2 2002/01/16 20:38:45 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Versions.sgml,v 1.4 2003/02/24 03:41:23 dawes Exp $ </ident> <abstract> @@ -31,7 +31,7 @@ main development stream, where all new work and work for future releases is done. Second is the stable bugfix branch for the latest full release -(&relvers;). It is created around the time of the release. The branch +(&fullrelvers;). It is created around the time of the release. The branch for this one is called "<tt>&relbranchtag;</tt>". Fixes for bugs found in the release will be added to this branch (as well as the trunk), and updates to this release (if any) will be cut from this branch. Similar @@ -44,19 +44,21 @@ security updates. Relevant security updates in particular are usually back-ported to this branch. XFree86 is planning to make full releases from the main development -stream approximately every six months, in late May and November of each -year. The feature freezes for these releases will be 1 April and 1 -October respectively. These are target dates, not a binding commitment. -How effectively these dates can be met will depend to a large degree on -the resource available to XFree86. Full releases consist of full source +stream at regular intervals in the 6-12 month range. The feature +freezes for these releases will usually be 2-3 months before the release +dates. This general plan is a goal, not a binding commitment. The +actual release intervals and dates will depend to a large degree on the +resource available to XFree86. Full releases consist of full source code tarballs, plus full binary distributions for a range of supported platforms. Update/bugfix releases will be made on an as-required basis, -depending also on the availability of resources. Update/bugfix releases -will not be full releases, and will consist of source code patches, plus -binary updates to be layered on top of the previous full release. - -The next full release will be version &nextfullrelvers;, tentatively scheduled for late &nextfullreldate;. -There is no scheduled update release. If there is one, the version will be +depending also on the availability of resources, and will generally be +limited to serious bug and security fixes. New features will not usually +be added in update releases. Update/bugfix releases will not be full +releases, and will consist of source code patches, plus binary updates +to be layered on top of the previous full release. + +The next full release will be version &nextfullrelvers;. There is no +scheduled update release, but if one is needed, the version will be &nextupdrelvers;. <!-- diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/XKB-Config.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/XKB-Config.sgml new file mode 100644 index 000000000..564fe03a1 --- /dev/null +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/XKB-Config.sgml @@ -0,0 +1,221 @@ +<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN"> + +<article> +<title>The XKB Configuration Guide +<author>Kamil Toman, Ivan U. Pascal +<date>25 November 2002 + +<ident> +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/XKB-Config.sgml,v 1.2 2003/02/25 19:31:02 dawes Exp $ +</ident> + +<abstract> +This document describes how to configure XFree86 XKB from a user's point +a few. It converts basic configuration syntax and gives also a few examples. +</abstract> + +<toc> + +<p> +<sect>Overview +<p> +The XKB configuration is decomposed into a number of components. Selecting +proper parts and combining them back you can achieve most of configurations +you might need. Unless you have a completely atypical keyboard you really don't +need to touch any of xkb configuration files. + +<sect>Selecting XKB Configuration +<p> +The easiest and the most natural way how to specify a keyboard mapping is +tu use <tt>rules</tt> component. As its name suggests it describes a number of general +rules how to combine all bits and pieces into a valid and useful keyboard +mapping. All you need to do is to select a suitable rules file and then to +feed it with a few parameters that will adjust the keyboard behaviour to +fulfill your needs. +<p> +The parameters are: +<itemize> +<item><tt>XkbRules </tt>- files of rules to be used for keyboard mapping +composition +<item><tt>XkbModel </tt>- name of model of your keyboard type +<item><tt>XkbLayout </tt>- layout(s) you intend to use +<item><tt>XkbVariant </tt>- variant(s) of layout you intend to use +<item><tt>XkbOptions </tt>- extra xkb configuration options +</itemize> +<p> +The proper rules file depends on your vendor. In reality, the commonest +file of rules is <tt>xfree86</tt>. For each rules file there is a description +file named <tt><vendor-rules>.lst</tt>, for instance <tt>xfree86.lst</tt> +which is located in xkb configuration subdirectory <tt>rules</tt> (for example +<tt>/etc/X11/xkb/rules</tt>). + +<sect1>Basic Configuration +<p> +Let's say you want to configure a PC style America keyboard with 104 +keys as described in <tt>xfree86.lst</tt>. It can be done by simply writing +several lines from below to you XFree86 configuration file (often +found as <tt>/etc/X11/XF86Config-4</tt> or <tt>/etc/X11/XF86Config</tt>): +<tscreen><verb> +Section "InputDevice" + Identifier "Keyboard1" + Driver "Keyboard" + + Option "XkbModel" "pc104" + Option "XkbLayout" "us" + Option "XKbOptions" "" +EndSection +</verb></tscreen> +The values of parameters <tt>XkbModel</tt> and <tt>XkbLayout</tt> are really +not surprising. The parameters <tt>XkbOptions</tt> has been explicitly set to +empty set of parameters. The parameter <tt>XkbVariant</tt> has been left out. +That means the default variant named <tt>basic</tt> is loaded. +<p> +Of course, this can be also done at runtime using utility setxkbmap. +Shell command loading the same keyboard mapping would look like: +<tscreen><verb> +setxkbmap -rules xfree86 -model pc104 -layout us -option "" +</verb></tscreen> +The configuration and the shell command would be very analogical +for most other layouts (internationalized mappings). + +<sect1>Advanced Configuration +<p> +Since XFree86 4.3.x you can use multi-layouts xkb configuration. +What does it mean? Basically it allows to load up to four different +keyboard layouts at a time. Each such layout would reside in its +own group. The groups (unlike complete keyboard remapping) can be +switched very fast from one to another by a combination of keys. +<p> +Let's say you want to configure your new Logitech cordless desktop +keyboard, you intend to use three different layouts at the same +time - us, czech and german (in this order), and that you are used +to <tt>Alt-Shift</tt> combination for switching among them. +<p> +Then the configuration snippet could look like this: +<tscreen><verb> +Section "InputDevice" + Identifier "Keyboard1" + Driver "Keyboard" + + Option "XkbModel" "logicordless" + Option "XkbLayout" "us,cz,de" + Option "XKbOptions" "grp:alt_shift_toggle" +EndSection +</verb></tscreen> +Of course, this can be also done at runtime using utility setxkbmap. +Shell command loading the same keyboard mapping would look like: +<tscreen><verb> +setxkmap -rules xfree86 -model logicordless -layout "us,cz,de" \ + -option "grp:alt_shift_toggle" +</verb></tscreen> + + +<sect1>Even More Advanced Configuration +<p> +Okay, let's say you are more demanding. You do like the example +above but you want it to change a bit. Let's imagine you want +the czech keyboard mapping to use another variant but basic. +The configuration snippet then changes into: +<tscreen><verb> +Section "InputDevice" + Identifier "Keyboard1" + Driver "Keyboard" + + Option "XkbModel" "logicordless" + Option "XkbLayout" "us,cz,de" + Option "XkbVariant" ",bksl," + Option "XKbOptions" "grp:alt_shift_toggle" +EndSection +</verb></tscreen> +That's seems tricky but it is not. The logic for settings of variants +is the same as for layouts, that means the first and the third variant +settings are left out (set to <tt>basic</tt>), the second is set to +<tt>bksl</tt> (a special variant with an enhanced definition of the backslash +key). +<p> +Analogically, the loading runtime will change to: +<tscreen><verb> +setxkmap -rules xfree86 -model logicordless -layout "us,cz,de" \ + -variant ",bksl," -option "grp:alt_shift_toggle" +</verb></tscreen> + +<sect1>Basic Global Options +<p> +See rules/*.lst files. + +<!-- + TODO: More detailed descriptions of options. User's often get confused. +--> + +<sect>Direct XKB Configuration +<p> +Generally, you can directly prescribe what configuration of each of basic +xkb components should be used to form the resulting keyboard mapping. +This method is rather "brute force". You precisely need to know the structure +and the meaning of all of used configuration components. +<p> +This method also exposes all xkb configuration details directly into XFree86 +configuration file which is a not very fortunate fact. +In rare occasions it may be needed, though. So how does it work? + +<sect1>Basic Components +<p> +There are five basic components used to form a keyboard mapping: +<itemize> +<item><em>key codes</em> - a translation of the scan codes produced by the + keyboard into a suitable symbolic form + +<item><em>types</em> - a specification of what various combinations of +modifiers produce + +<item><em>key symbols</em> - a translation of symbolic key codes into actual +symbols + +<item><em>geometry</em> - a description of physical keyboard geometry + +<item><em>compatibility maps</em> - a specification of what action should +each key produce in order to preserve compatibility with XKB-unware clients +</itemize> + +<sect1>Example Configuration +<p> +Look at the following example: +<tscreen><verb> +Section "InputDevice" + Identifier "Keyboard0" + Driver "Keyboard" + + Option "XkbKeycodes" "xfree86" + Option "XkbTypes" "default" + Option "XkbSymbols" "en_US(pc104)+de+swapcaps" + Option "XkbGeometry" "pc(pc104)" + Option "XkbCompat" "basic+pc+iso9995" +EndSection +</verb></tscreen> + +This configuration sets the standard XFree86 default interpretation of keyboard +keycodes, sets the default modificator types. The +symbol table is composed of extended US keyboard layout in its +variant for pc keyboards with 104 keys plus all keys +for german layout are redefined respectively. Also the logical +meaning of <tt>Caps-lock</tt> and <tt>Control</tt> keys is swapped. +The standard keyboard geometry (physical look) is set to pc style +keyboard with 104 keys. The compatibility map is set to allow +basic shifting, to allow Alt keys to be interpreted and also +to allow iso9995 group shifting. + +<!-- + TODO: add information about layout shifting: + TODO: us+ru(winkeys):2+de:3 +--> + +<sect>Keymap XKB Configuration +<p> +It is the formerly used way to configure xkb. The user included a special +keymap file which specified the direct xkb configuration. This method +has been obsoleted by previously described rules files which are far +more flexible and allow simpler and more intuitive syntax. It is +preserved merely for compatibility reasons. Avoid using it if it is possible. +<p> + +</article> diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/XKB-Enhancing.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/XKB-Enhancing.sgml new file mode 100644 index 000000000..44bc10f1c --- /dev/null +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/XKB-Enhancing.sgml @@ -0,0 +1,557 @@ +<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN"> + +<article> +<title>How to further enhance XKB configuration +<author>Kamil Toman, Ivan U. Pascal +<date>25 November 2002 + +<ident> +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/XKB-Enhancing.sgml,v 1.2 2003/02/25 19:31:02 dawes Exp $ +</ident> + +<abstract> +This guide is aimed to relieve one's labour to create a new (internationalized) +keyboard layout. Unlike other documents this guide accents the keymap +developer's point of view. +</abstract> + +<toc> + +<p> + +<sect>Overview +<p> +The developer of a new layout should read the xkb +protocol specification (<url url="http://www.x-docs.org/XKB/XKBproto.pdf" +name="The X Keyboard Extension: Protocol Specification">) at least +to clarify for himself some xkb-specific terms used in this document +and elsewhere in xkb configuration. Also it shows wise to understand +how the X server and a client digest their keyboard inputs +(with and without xkb). +<p> +A useful source is also <url url="http://www.tsu.ru/~pascal/en/xkb" name="Ivan +Pascal's text about xkb configuration"> often referenced throughout this +document. + +<p> +Note that this document covers only enhancements which +are to be made to XFree86 version 4.3.x and above. + + +<sect>The Basics +<p> +At the startup (or at later at user's command) X server starts its xkb +keyboard module extension and reads data from a compiled configuration +file. +<p> +This compiled configuration file is prepared by the program <tt>xkbcomp</tt> +which behaves altogether as an ordinary compiler (see <tt>man xkbcomp</tt>). +Its input are human readable xkb configuration files which are verified and +then composed into a useful xkb configuration. Users don't need to mess with +<tt>xkbcomp</tt> themselves, for them it is invisible. Usually, it is started +upon X server startup. +<p> +As you probably already know, the xkb configuration consists of five +main modules: +<descrip> +<tag/Keycodes/ + Tables that defines translation from keyboard scan codes into reasonable + symbolic names, maximum, minimum legal keycodes, symbolic aliases and + description of physically present LED-indicators. The primary sence of + this component is to allow definitions of maps of symbols (see below) + to be independent of physical keyboard scancodes. There are two main + naming conventions for symbolic names (always four bytes long): + <itemize> + <item> names which express some traditional meaning like + <tt><SPCE></tt> (stands for space bar) or + <item> names which express some relative positioning on a keyboard, for + example <tt><AE01></tt> (an exclamation mark on US keyboards), on + the right there are keys <tt><AE02></tt>, <tt><AE03></tt> + etc. + </itemize> + +<tag/Types/ + Types describe how the produced key is changed by active modifiers (like + Shift, Control, Alt, ...). There are several predefined types which + cover most of used combinations. + +<tag/Compat/ + Compatibility component defines internal behaviour of modifiers. Using + compat component you can assign various actions (elaborately described + in xkb specification) to key events. This is also the place where + LED-indicators behaviour is defined. + +<tag/Symbols/ + For i18n purposes, this is the most important table. It defines what + values (=symbols) are assigned to what keycodes (represented by their + symbolic name, see above). There may be defined more than one value + for each key and then it depends on a key type and on modifiers state + (respective compat component) which value will be the resulting one. + +<tag/Geometry/ + Geometry files aren't used by xkb itself but they may be used by some + external programs to depict a keyboard image. +</descrip> +All these components have the files located in xkb configuration tree +in subdirectories with the same names (usually in <tt>/usr/lib/X11/xkb</tt>). + + +<sect>Enhancing XKB Configuration +<p> +Most of xkb enhancements concerns a need to define new output symbols +for the some input key events. In other words, a need to define a new +symbol map (for a new language, standard or just to feel more comfortable +when typing text). +<p> +What do you need to do? Generally, you have to define following things: +<itemize> +<item> the map of symbols itself +<item> the rules to allow users to select the new mapping +<item> the description of the new layout +</itemize> +<p> +First of all, it is good to go through existing layouts and to examine +them if there is something you could easily adjust to fit your needs. +Even if there is nothing similar you may get some ideas about basic +concepts and used tricks. +<p> +<sect1>Levels And Groups +<p> +Since XFree86 4.3.0 you can use <bf>multi-layout</bf> concept of xkb +configuration. +Though it is still in boundaries of xkb protocol and general ideas, the +keymap designer must obey new rules when creating new maps. In exchange +we get a more powerful and cleaner configuration system. +<p> +Remember that it is the application which must decide which symbol +matches which keycode according to effective modifier state. The X server +itself sends only an input event message to. Of course, usually +the general interpretation is processed by Xlib, Xaw, Motif, Qt, Gtk +and similar libraries. The X server only supplies its mapping table +(usually upon an application startup). +<p> +You can think of the X server's symbol table as of a irregular table where each +keycode has its row and where each combination of modifiers determines exactly +one column. The resulting cell then gives the proper symbolic value. Not all +keycodes need to bind different values for different combination of modifiers. +<tt><ENTER></tt> key, for instance, usually doesn't depend on any +modifiers so it its row has only one column defined. +<p> +Note that in XKB there is no prior assumption that certain modifiers are bound +to certain columns. By editing proper files (see <ref id="keytypes">) this +mapping can be changed as well. +<p> +Unlike the original X protocol the XKB approach is far more +flexible. It is comfortable to add one additional XKB term - group. You can +think of a group as of a vector of columns per each keycode (naturally the +dimension of this vector may differ for different keycodes). What is it good +for? The group is not very useful unless you intend to use more than one +logically different set of symbols (like more than one alphabet) defined in a +single mapping table. But then, the group has a natural meaning - each symbol +set has its own group and changing it means selecting a different one. +XKB approach allows up to four different groups. The columns inside each group +are called (shift) levels. The X server knows the current group and reports it +together with modifier set and with a keycode in key events. +<p> +To sum it up: +<p> +<itemize> +<item> for each keycode XKB keyboard map contains up to four one-dimensional + tables - groups (logically different symbol sets) +<item> for each group of a keycode XKB keyboard map contains some columns + - shift levels (values reached by combinations of Shift, Ctrl, Alt, ... + modifiers) +<item> different keycodes can have different number of groups +<item> different groups of one keycode can have different number of shift levels +<item> the current group number is tracked by X server +</itemize> +<p> +It is clear that if you sanely define levels, groups and sanely bind +modifiers and associated actions you can have simultaneously loaded up to +four different symbol sets where each of them would reside in its own group. +<p> +The multi-layout concept provides a facility to manipulate xkb groups +and symbol definitions in a way that allows almost arbitrary composition of +predefined symbol tables. To keep it fully functional you have to: +<itemize> +<item> define all symbols only in the first group +<item> (re)define any modifiers with extra care to avoid strange (anisometric) + behaviour +</itemize> +<p> +<sect>Defining New Layouts +<p> +<!-- + TODO: It may be better to merge IP01 docs and this guide. +--> +See <url url="http://www.tsu.ru/~pascal/en/xkb/internals.html" name="Some Words +About XKB internals"> for explanation of used xkb terms and problems +addressed by XKB extension. +<p> +See <url url="http://www.tsu.ru/~pascal/en/xkb/gram-common.html" name="Common +notes about XKB configuration files language"> for more precise explanation of +syntax of xkb configuration files. +<p> +<sect1>Predefined XKB Symbol Sets +<p> +If you are about to define some European symbol map extension, you might +want to use on of four predefined latin alphabet layouts. +<!-- + TODO: more details + TODO: something similiar for phonetic layouts + TODO: what are pc/pc layouts good for??? +--> +<p> +Okay, let's assume you want extend an existing keymap and you want to override +a few keys. Let's take a simple U.K. keyboard as an example (defined in +<tt>pc/gb</tt>): +<p> +<tscreen><verb> +partial default alphanumeric_keys +xkb_symbols "basic" { + include "pc/latin" + + name[Group1]="Great Britain"; + + key <AE02> { [ 2, quotedbl, twosuperior, oneeighth ] }; + key <AE03> { [ 3, sterling, threesuperior, sterling ] }; + key <AC11> { [apostrophe, at, dead_circumflex, dead_caron] }; + key <TLDE> { [ grave, notsign, bar, bar ] }; + key <BKSL> { [numbersign, asciitilde, dead_grave, dead_breve ] }; + key <RALT> { type[Group1]="TWO_LEVEL", + [ ISO_Level3_Shift, Multi_key ] }; + + modifier_map Mod5 { <RALT> }; +}; +</verb></tscreen> +<!-- + TODO: ref IP01 file syntax TODO: some words about symbolic names like + 'sterling' and also about + TODO: unicode characters (for non-latin alphabets), + TODO: ref to compatibility symbolic names vs. unicode +--> +<p> +It defines a new layout in <tt>basic</tt> variant as an extension of common +latin alphabet layout. The layout (symbol set) name is set to "Great Britain". +Then there are redefinitions of a few keycodes and a modifiers binding. As you +can see the number of shift levels is the same for <tt><AE02></tt>, +<tt><AE03></tt>, <tt><AC11></tt>, <tt><TLDE></tt> and +<tt><BKSL></tt> keys but it differs from number of shift levels of +<tt><RALT></tt>. +<p> +Note that the <tt><RALT></tt> key itself is a binding key for Mod5 and +that it +serves like a shift modifier for LevelThree, together with Shift +as a multi-key. It is a good habit to respect this rule in a new similar +layout. +<p> +Okay, you could now define more variants of your new layout besides +<tt>basic</tt> simply by including (augmenting/overriding/...) the basic +definition and altering what may be needed. + +<sect1>Key Types<label id="keytypes"> +<p> + +The differences in the number of columns (shift levels) are caused by +a different types of keys (see the types definition in section basics). Most +keycodes have implicitly set the keytype in the included +<tt>&dquot;pc/latin&dquot;</tt> file to +<tt>&dquot;FOUR_LEVEL_ALPHABETIC&dquot;</tt>. The only exception is +<tt><RALT></tt> keycode which is explicitly set +<tt>&dquot;TWO_LEVEL&dquot;</tt> keytype. +<p> +All those names refer to pre-defined shift level schemes. Usually you can +choose a suitable shift level scheme from <tt>default</tt> types scheme list +in proper xkb component's subdirectory. +<p> +The most used schemes are: +<descrip> +<tag/ONE_LEVEL/ + The key does not depend on any modifiers. The symbol from first level + is always chosen. + +<tag/TWO_LEVEL/ + The key uses a modifier Shift and may have two possible values. + The second level may be chosen by Shift modifier. If Lock modifier + (usually Caps-lock) applies the symbol is further processed using + system-specific capitalization rules. If both Shift+Lock modifier apply the + symbol from the second level is taken and capitalization rules are applied + (and usually have no effect). + +<tag/ALPHABETIC/ + The key uses modifiers Shift and Lock. It may have two possible + values. The second level may be chosen by Shift modifier. When Lock + modifier applies, the symbol from the first level is taken and further + processed using system-specific capitalization rules. If both Shift+Lock + modifier apply the symbol from the first level is taken and no + capitalization rules applied. This is often called shift-cancels-caps + behaviour. + +<tag/THREE_LEVEL/ + Is the same as TWO_LEVEL but it considers an extra modifier - + LevelThree which can be used to gain the symbol value from the third + level. If both Shift+LevelThree modifiers apply the value from the third + level is also taken. As in TWO_LEVEL, the Lock modifier doesn't influence + the resulting level. Only Shift and LevelThree are taken into that + consideration. If the Lock modifier is active capitalization rules + are applied on the resulting symbol. + +<tag/FOUR_LEVEL/ + Is the same as THREE_LEVEL but unlike LEVEL_THREE if both Shift+LevelThree + modifiers apply the symbol is taken from the fourth level. + +<tag/FOUR_LEVEL_ALPHABETIC/ + Is similar to FOUR_LEVEL but also defines shift-cancels-caps behaviour + as in ALPHABETIC. If Lock+LevelThree apply the symbol from the + third level is taken and the capitalization rules are applied. + If Lock+Shift+LevelThree apply the symbol from the third level is taken + and no capitalization rules are applied. + +<tag/KEYPAD/ + As the name suggest this scheme is primarily used for numeric keypads. + The scheme considers two modifiers - Shift and NumLock. If none + of modifiers applies the symbol from the first level is taken. If either + Shift or NumLock modifiers apply the symbol from the second level is taken. + If both Shift+NumLock modifiers apply the symbol from the first level + is taken. Again, shift-cancels-caps variant. + +<tag/FOUR_LEVEL_KEYPAD/ + Is similar to KEYPAD scheme but considers also LevelThree modifier. + If LevelThree modifier applies the symbol from the third level is taken. + If Shift+LevelThree or NumLock+LevelThree apply the symbol from the fourth + level is taken. If all Shift+NumLock+LevelThree modifiers apply the symbol + from the third level is taken. This also, shift-cancels-caps variant. +</descrip> +<p> +Besides that, there are several schemes for special purposes: +<descrip> +<tag/PC_BREAK/ + It is similar to TWO_LEVEL scheme but it considers the Control + modifier rather than Shift. That means, the symbol from the second level + is chosen by Control rather than by Shift. +<tag/PC_SYSRQ/ + It is similar to TWO_LEVEL scheme but it considers the Alt modifier rather + than Shift. That means, the symbol from the second level + is chosen by Alt rather than by Shift. +<tag/CTRL+ALT/ + The key uses modifiers Alt and Control. It may have two possible + values. If only one modifier (Alt or Control) applies the symbol + from the first level is chosen. Only if both Alt+Control modifiers apply + the symbol from the second level is chosen. +<tag/SHIFT+ALT/ + The key uses modifiers Shift and Alt. It may have two possible values. + If only one modifier (Alt or Shift) applies the symbol + from the first level is chosen. Only if both Alt+Shift modifiers apply + the symbol from the second level is chosen. +</descrip> +<p> +If needed, special <tt>caps</tt> schemes may be used. They redefine the +standard behaviour of all <tt>*ALPHABETIC</tt> types. The layouts (maps of +symbols) with keys defined in respective types then automatically change +their behaviour accordingly. Possible redefinitions are: +<itemize> +<item>internal +<item>internal_nocancel +<item>shift +<item>shift_nocancel +</itemize> +None of these schemes should be used directly. They are defined merely +for <tt>'caps:'</tt> xkb options (used to globally change the layouts +behaviour). +<p> +Don't alter any of existing key types. If you need a different behaviour +create a new one. + +<sect2>More On Definitions Of Types +<p> +When the XKB software deals with a separate type description it gets +a complete list of modifiers that should be taken into account from the +<tt>'modifiers=<list of modifiers>'</tt> list and expects that a set +of <tt>'map[<combination of modifiers>]=<list of modifiers>'</tt> +instructions that contain the mapping for each combination of modifiers +mentioned in that list. Modifiers that are not explicitly listed are NOT taken +into account +when the resulting shift level is computed. +If some combination is omitted the program (subroutine) should choose the first +level for this combination (a quite reasonable behavior). +<p> +Lets consider an example with two modifiers <tt>ModOne</tt> and <tt>ModTwo</tt>: +<tscreen><verb> +type "..." { + modifiers = ModOne+ModTwo; + map[None] = Level1; + map[ModOne] = Level2; +}; +</verb></tscreen> +In this case the map statements for <tt>ModTwo</tt> only and +<tt>ModOne+ModTwo</tt> are omitted. It means that if the <tt>ModTwo</tt> is +active the subroutine can't found explicit mapping for such combination an will +use the <em>default level</em> i.e. Level1. +<p> +But in the case the type described as: +<tscreen><verb> +type "..." { + modifiers = ModOne; + map[None] = Level1; + map[ModOne] = Level2; +}; +</verb></tscreen> +the ModTwo will not be taken into account and the resulting level depends on +the ModOne state only. That means, ModTwo alone produces the Level1 but the +combination ModOne+ModTwo produces the Level2 as well as ModOne alone. +<p> +What does it mean if the second modifier is the Lock? It means that in +the first case (the Lock itself is included in the list of modifiers but +combinations with this modifier aren't mentioned in the map statements) +the internal capitalization rules will be applied to the symbol from the first +level. But in the second case the capitalization will be applied to the symbol +chosen accordingly to he first modifier - and this can be the symbol from the +first as well as from the second level. +<p> +Usually, all modifiers introduced in <tt>'modifiers=<list of +modifiers>'</tt> list are used for shift level calculation and then +discarded. Sometimes this is not desirable. If you want to use a modifier +for shift level calculation but you don't want to discard it, you may +list in '<tt>preserve[<combination of modifiers>]=<list of +modifiers>'</tt>. That means, for a given combination all listed modifiers +will be preserved. If the Lock modifier is preserved then the resulting +symbol is passed to internal capitalization routine regardless whether +it has been used for a shift level calculation or not. +<p> +Any key type description can use both real and virtual modifiers. Since real +modifiers always have standard names it is not necessary to explicitly declare +them. Virtual modifiers can have arbitrary names and can be declared (prior +using them) directly in key type definition: +<tscreen><verb> +virtual_modifiers <comma-separated list of modifiers> ; +</verb></tscreen> +as seen in for example <tt>basic</tt>, <tt>pc</tt> or <tt>mousekeys</tt> key +type definitions. + +<sect1>Rules +<p> +Once you are finished with your symbol map you need to add it +to rules file. The rules file describes how all the +five basic keycodes, types, compat, symbols and geometry components +should be composed to give a sensible resulting xkb configuration. +<p> +The main advantage of rules over formerly used keymaps is a possibility +to simply parameterize (once) fixed patterns of configurations and thus +to elegantly allow substitutions of various local configurations +into predefined templates. +<p> +A pattern in a rules file (often located in +<tt>/usr/lib/X11/xkb/rules</tt>) can be parameterized with four other arguments: +<tt>Model</tt>, <tt>Layout</tt>, <tt>Variant</tt> and <tt>Options</tt>. +For most cases parameters <tt>model</tt> and <tt>layout</tt> should +be sufficient for choosing a functional keyboard mapping. +<p> +The rules file itself is composed of pattern lines and lines with rules. The pattern line starts with an exclamation mark ('<tt>!</tt>') +and describes how will the xkb interpret the following lines (rules). A sample +rules file looks like this: +<tscreen><verb> +! model = keycodes + macintosh_old = macintosh + ... + * = xfree86 + +! model = symbols + hp = +inet(%m) + microsoftpro = +inet(%m) + geniuscomfy = +inet(%m) + +! model layout[1] = symbols + macintosh us = macintosh/us%(v[1]) + * * = pc/pc(%m)+pc/%l[1]%(v[1]) + +! model layout[2] = symbols + macintosh us = +macintosh/us[2]%(v[2]):2 + * * = +pc/%l[2]%(v[2]):2 + +! option = types + caps:internal = +caps(internal) + caps:internal_nocancel = +caps(internal_nocancel) +</verb></tscreen> + +Each rule defines what certain combination of values on the left side +of equal sign ('<tt>=</tt>') results in. For example a (keyboard) model +<tt>macintosh_old</tt> instructs xkb to take definitions of keycodes +from file <tt>keycodes/macintosh</tt> while the rest of models +(represented by a wild card '<tt>*</tt>') instructs it to take them from +file <tt>keycodes/xfree86</tt>. The wild card represents all possible +values on the left side which were not found in any of the previous rules. +The more specialized (more complete) rules have higher precedence than general +ones, i.e. the more general rules supply reasonable default values. +<p> +As you can see some lines contain substitution parameters - the parameters +preceded by the percent sign ('<tt>%</tt>'). The first alphabetical character +after the percent sign expands to the value which has been found on the left +side. For example <tt>+%l%(v)</tt> expands into <tt>+cz(bksl)</tt> if the +respective values on the left side were <tt>cz</tt> layout in its <tt>bksl</tt> +variant. More, if the layout resp. variant parameter is followed by a pair of +brackets ('<tt>[</tt>', '<tt>]</tt>') it means that xkb should <em>place the +layout resp. variant into specified xkb group</em>. If the brackets are omitted +the first group is the default value. +<p> +So the second block of rules enhances symbol definitions for some particular +keyboard models with extra keys (for internet, multimedia, ...) . Other models +are left intact. Similarly, the last block overrides some key type definitions, +so the common global behaviour ''shift cancels caps'' or ''shift doesn't cancel +caps'' can be selected. The rest of rules produces special symbols for each +variant <tt>us</tt> layout of <tt>macintosh</tt> keyboard and standard pc +symbols in appropriate variants as a default. + +<!-- + TODO: more words about group switching (XkbOptions grp:...)? +--> + +<!-- + TODO: user & 3rd party xkb tree? + TODO: better and more complex explanation of rules +--> + +<sect1>Descriptive Files of Rules +<p> +Now you just need to add a detailed description to <tt><rules>.xml</tt> +description file so the other users (and external programs which often parse +this file) know what is your work about. + + +<!-- + TODO: format and semantics +--> + +<sect2>Old Descriptive Files +<p> +The formerly used descriptive files were named <tt><rules>.lst</tt> +Its structure is very simple and quite self descriptive but such simplicity +had also some cavities, for example there was no way how to describe local +variants of layouts and there were problems with the localization of +descriptions. To preserve compatibility with some older programs, +new XML descriptive files can be converted to old format '.lst'. +<p> +For each parameter of rules file should be described its meaning. For the rules +file described above the <tt>.lst</tt> file could look like: +<tscreen><verb> +! model + pc104 Generic 104-key PC + microsoft Microsoft Natural + pc98 PC-98xx Series + macintosh Original Macintosh + ... + +! layout + us U.S. English + cz Czech + de German + ... + +! option + caps:internal uses internal capitalization. Shift cancels Caps + caps:internal_nocancel uses internal capitalization. Shift doesn't cancel Caps + +</verb></tscreen> +<p> +And that should be it. Enjoy creating your own xkb mapping. + +</article> diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/ati.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/ati.sgml index 5ece3380a..53e936943 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/ati.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/ati.sgml @@ -15,7 +15,7 @@ <ident> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/ati.sgml,v 3.40 2002/02/14 22:08:00 tsi Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/ati.sgml,v 3.43 2003/02/25 19:31:02 dawes Exp $ </ident> <abstract> @@ -53,7 +53,7 @@ disable itself to allow other drivers to examine the system.<p> Note that I am currently considering removing the driver's support for generic VGA. If you have any concerns about this, please contact me at -<it>tsi@xfree86.org</it>. +<email>tsi@xfree86.org</email>. <sect>A note on acceleration<p> The meaning of ``acceleration'', as used in this document, needs to be clarified. @@ -534,7 +534,8 @@ mode. In the first case, the workaround is to use some other means of restoring the text font. On Linux, this can be accomplished with the kbd or svgalib packages. -In the second case, xrefresh(1) will usually clean up the image. +In the second case, <htmlurl name="xrefresh(1)" url="xrefresh.1.html"> +will usually clean up the image. No complete solution to this problem is currently known. It appears this corruption occurs due to either video memory bandwidth or RAMDAC limitations, and so the driver will limit mode clocks to 40MHz. @@ -558,7 +559,7 @@ of the panel's native resolution. This is quite evident when the panel has ``odd-ball'' dimensions, such as 1400x1050, a resolution not commonly possible on CRTs or projection equipment.<p> -Also, the display of independant images on the panel and CRT is not currently +Also, the display of independent images on the panel and CRT is not currently implemented, and might never be, pending resolution of the previous item.<p> </itemize> Support for the following will be added in a future release: @@ -585,7 +586,7 @@ name="ftp://ftp.xfree86.org/pub/XFree86" url="ftp://ftp.xfree86.org/pub/XFree86"> if you are uncertain.<p> Secondly, please check XFree86's doc directory for additional information.<p> Thirdly, a scan through the comp.windows.x.i386unix and comp.os.linux.x -newsgroups and the newbie or xpert mailing lists using your favourite archiving +newsgroups and the xfree86 mailing list using your favourite archiving service can also prove useful in resolving problems.<p> If you are still experiencing problems, you can send me <it>non-HTMLised</it> e-mail at <email>tsi@xfree86.org</email>. diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/defs.ent b/xc/programs/Xserver/hw/xfree86/doc/sgml/defs.ent index 18f8f5a27..38a0c2378 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/defs.ent +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/defs.ent @@ -1,40 +1,48 @@ -<!-- $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/defs.ent,v 1.22 2002/01/16 20:38:45 dawes Exp $ --> +<!-- $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/defs.ent,v 1.29 2003/02/27 02:03:07 dawes Exp $ --> <!-- shared entity definitions for the XFree86 documentation --> <!-- XFree86 version string --> -<!ENTITY relvers CDATA "4.2.0"> -<!ENTITY prevrelvers CDATA "4.1.0"> -<!ENTITY fullrelvers CDATA "4.2.0"> -<!ENTITY prevfullrelvers CDATA "4.1.0"> -<!ENTITY nextfullrelvers CDATA "4.3.0"> -<!ENTITY nextfullreldate CDATA "May 2002"> -<!ENTITY nextupdrelvers CDATA "4.2.1"> -<!ENTITY srcvers CDATA "420"> -<!ENTITY prevsrcvers CDATA "410"> -<!ENTITY fullsrcvers CDATA "420"> -<!ENTITY prevfullsrcvers CDATA "410"> -<!ENTITY whichfullrel CDATA "fifth"> +<!ENTITY relvers CDATA "4.3.0"> +<!ENTITY prevrelvers CDATA "4.2.1"> +<!ENTITY fullrelvers CDATA "4.3.0"> +<!ENTITY prevfullrelvers CDATA "4.2.0"> +<!ENTITY nextfullrelvers CDATA "4.4.0"> +<!ENTITY nextfullreldate CDATA "not scheduled"> +<!ENTITY nextupdrelvers CDATA "4.3.1"> +<!ENTITY srcvers CDATA "430"> +<!ENTITY prevsrcvers CDATA "421"> +<!ENTITY fullsrcvers CDATA "430"> +<!ENTITY prevfullsrcvers CDATA "420"> +<!ENTITY whichfullrel CDATA "sixth"> <!ENTITY whichupdaterel CDATA "none"> -<!ENTITY relbranchtag CDATA "xf-4_2-branch"> +<!ENTITY reltag CDATA "xf-4_3_0"> +<!ENTITY relbranchtag CDATA "xf-4_3-branch"> +<!ENTITY rcnum CDATA "0"> <!-- Version of the most recent 3.3.x release --> <!ENTITY legacyvers CDATA "3.3.6"> <!-- doctools version strings --> -<!ENTITY doctoolsvers CDATA "1.3"> +<!ENTITY doctoolsvers CDATA "1.3.1"> + +<!-- utils version strings --> +<!ENTITY utilsvers CDATA "1.1.0"> <!-- These should be set according to which snapshot/release this is --> <!ENTITY % firstsnap 'IGNORE'> -<!ENTITY % latersnap 'INCLUDE'> +<!ENTITY % latersnap 'IGNORE'> <!ENTITY % snapshot 'IGNORE'> +<!ENTITY % notsnapshot 'INCLUDE'> +<!ENTITY % relcandidate 'IGNORE'> <!ENTITY % release 'INCLUDE'> <!ENTITY % firstrel 'IGNORE'> <!ENTITY % earlyrel 'IGNORE'> <!ENTITY % laterrel 'INCLUDE'> <!ENTITY % fullrel 'INCLUDE'> +<!ENTITY % fullbinaries 'INCLUDE'> <!ENTITY % updaterel 'IGNORE'> -<!ENTITY % prevrelwasupdate 'IGNORE'> +<!ENTITY % prevrelwasupdate 'INCLUDE'> <!-- Set this to INCLUDE when references to the RELNOTES are to be included --> <!ENTITY % haverelnotes 'INCLUDE'> diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/dps.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/dps.sgml index b691d7652..77b43410e 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/dps.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/dps.sgml @@ -8,7 +8,7 @@ <author>Juliusz Chroboczek, <email/jch@xfree86.org/ <date>27 February 2001</date> -<ident>$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/dps.sgml,v 1.1 2001/03/02 02:45:37 dawes Exp $</ident> +<ident>$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/dps.sgml,v 1.2 2003/01/20 03:43:07 dawes Exp $</ident> <toc> @@ -111,7 +111,8 @@ The <tt/makepsres/ utility is used for managing PostScript resources. Its basic operation consists in walking recursively a filesystem tree, noting all resources, and then writing out a ``Unix PostScript Resources,'' file, basically a directory of all the resources found. -This utility is documented in the makepsres(1) manual page. +This utility is documented in the <htmlurl name="makepsres(1)" +url="makepsres.1.html"> manual page. The <tt/pswrap/ utility is a stub generator for PostScript clients. Roughly speaking, it takes as its input textual PostScript code, and diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/fonts.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/fonts.sgml index 859801b76..1feab532a 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/fonts.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/fonts.sgml @@ -6,41 +6,216 @@ <title>Fonts in XFree86 <author>Juliusz Chroboczek, <email/jch@xfree86.org/ -<date>29 September 2002</date> +<date>17 January 2003</date> <ident> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/fonts.sgml,v 1.16 2002/10/17 00:49:02 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/fonts.sgml,v 1.20 2003/01/20 03:43:07 dawes Exp $ </ident> <toc> <sect>Introduction -<!-- I hate SGML. What's wrong with texinfo? --> - -<p>This document describes the support for fonts in XFree86. Section -<ref id="sec:installing" name="Installing fonts"> is aimed at the -casual user wishing to install fonts in the X server; the rest of the +<p>This document describes the support for fonts in XFree86. <ref +id="sec:installing" name="Installing fonts"> is aimed at the +casual user wishing to install fonts in XFree86; the rest of the document describes the font support in more detail. -We only describe font support within the core X protocol. Issues -relating to fonts within the RENDER extension, the GLX (OpenGL) -extension or the PEX extension are outside the scope of this document. - We assume some familiarity with digital fonts. If anything is not -clear to you, please consult Appendix <ref id="sec:background" -name="Background"> at the end of this document for background +clear to you, please consult <ref id="sec:background" +name="Appendix: Background"> at the end of this document for background information. -<sect>Installing fonts <label id="sec:installing"> +<sect1>Two font systems + +<p>XFree86 includes two font systems: the core X11 fonts system, which +is present in all implementations of X11, and the Xft fonts system, +which is not currently distributed with implementations of X11 that +are not based on XFree86 but will hopefully be included by them in +the future + +The core X11 fonts system is directly derived from the fonts system +included with X11R1 in 1987, which could only use monochrome bitmap +fonts. Over the years, it has been more or less happily coerced into +dealing with scalable fonts and rotated glyphs. + +Xft was designed from the start to provide good support for scalable +fonts, and do so efficiently. Unlike the core fonts system, it +supports features such as anti-aliasing and sub-pixel rasterisation. +Perhaps more importantly, it gives applications full control over the +way glyphs are rendered, making fine typesetting and WYSIWIG display +possible. Finally, it allows applications to use fonts that are not +installed system-wide for displaying documents with embedded fonts. + +Xft is not compatible with the core fonts system: usage of Xft +requires making fairly extensive changes to toolkits (user-interface +libraries). While XFree86 will continue to maintain the core fonts +system, toolkit authors are encouraged to switch to Xft as soon as +possible. + +<sect>Installing fonts<label id="sec:installing"> + +<p>This section explains how to configure both Xft and the core fonts +system to access newly-installed fonts. + +<sect1>Configuring Xft<label id="sec:configuring-xft"> + +<p>Xft has no configuration mechanism itself, rather it relies upon +the fontconfig library to configure and customize fonts. That library +is not specific to XFree86 or indeed on any particular font output +mechanism. This discussion describes how fontconfig, rather than Xft, +works. + +<sect2>Installing fonts in Xft + +<p>Fontconfig looks for fonts in a set of well-known directories that +include all of XFree86's standard font directories +(`<tt>/usr/X11R6/lib/X11/lib/fonts/*</tt>') by default) as well as a +directory called `<tt>.fonts/</tt>' in the user's home directory. +Installing a font for use by Xft applications is as simple +as copying a font file into one of these directories. +<tscreen><verb> +$ cp lucbr.ttf ~/.fonts/ +</verb></tscreen> +Fontconfig will notice the new font at the next opportunity and rebuild its +list of fonts. If you want to trigger this update from the command +line (for example in order to globally update the system-wide Fontconfig +information), you may run the command `<tt/fc-cache/'. +<tscreen><verb> +$ fc-cache +</verb></tscreen> + +<sect2>Fine-tuning Xft + +<p>Fontconfig's behaviour is controlled by a set of configuration files: a +system-wide configuration file, `<tt>/etc/fonts/fonts.conf</tt>', and +a user-specific file called `<tt>.fonts.conf</tt>' in the user's home +directory (this can be overridden with the `<tt/FONTCONFIG_FILE/' +environment variable). + +Every Fontconfig configuration file must start with the following +boilerplate: +<tscreen><verb> +<?xml version="1.0"?> +<!DOCTYPE fontconfig SYSTEM "fonts.dtd"> +<fontconfig> +</verb></tscreen> +In addition, every Fontconfig configuration file must end with the +following line: +<tscreen><verb> +</fontconfig> +</verb></tscreen> + +The default Fontconfig configuration file includes the directory +`<tt>~/.fonts/</tt>' in the list of directories searched for font +files, and this is where user-specific font files should be installed. +In the unlikely case that a new font directory needs to be added, this +can be done with the following syntax: +<tscreen><verb> +<dir>/usr/local/share/fonts/</dir> +</verb></tscreen> + +Another useful option is the ability to disable anti-aliasing (font +smoothing) for selected fonts. This can be done with the following +syntax: +<tscreen><verb> +<match target="font"> + <test qual="any" name="family"> + <string>Lucida Console</string> + </test> + <edit name="antialias" mode="assign"> + <bool>false</bool> + </edit> +</match> +</verb></tscreen> +Anti-aliasing can be disabled for all fonts by the following incantation: +<tscreen><verb> +<match target="font"> + <edit name="antialias" mode="assign"> + <bool>false</bool> + </edit> +</match> +</verb></tscreen> + +Xft supports sub-pixel rasterisation on LCD displays. XFree86 should +automatically enable this feature on laptops and when using an LCD +monitor connected with a DVI cable; you can check whether this was +done by typing +<tscreen><verb> +$ xdpyinfo -ext RENDER | grep sub-pixel +</verb></tscreen> +If this doesn't print anything, you will need to configure Render for +your particular LCD hardware manually; this is done with the following +syntax: +<tscreen><verb> +<match target="font"> + <edit name="rgba" mode="assign"> + <const>rgb</const> + </edit> +</match> +</verb></tscreen> +The string `<tt/rgb/' within the +`<tt/<const>/'...`<tt></const></tt>' +specifies the order of pixel components on your display, and should be +changed to match your hardware; it can be one of `<tt/rgb/ (normal +LCD screen), `<tt/bgr/' (backwards LCD screen), `<tt/vrgb/' (LCD +screen rotated clockwise) or `<tt/vbgr/' (LCD screen rotated +counterclockwise). + +<sect2>Configuring applications + +<p>Because most current applications use the core fonts system by +default, it is necessary to explicitly configure them to use Xft. +How this is done depends on the application. + +XTerm can be set to use Xft by using the `<tt/-fa/' command line +option or by setting the `<tt/XTerm*faceName/' resource: +<tscreen><verb> +XTerm*faceName: Courier +</verb></tscreen> +or +<tscreen><verb> +$ xterm -fa "Courier" +</verb></tscreen> + +For applications based on GTK+ 2.0 (including GNOME 2 applications), +the environment variable `<tt/GDK_USE_XFT/' should be set to `<tt/1/': +<tscreen><verb> +$ export GDK_USE_XFT=1 +</verb></tscreen> + +GTK+ 2.2 uses Xft by default. + +For KDE applications, you should select ``Anti-alias fonts'' in the +``Fonts'' panel of KDE's ``Control Center''. Note that this option is +misnamed: it switches KDE to using Xft but doesn't enable +anti-aliasing in case it was disabled by your Xft configuration file. -<p>Installing fonts in XFree86 is a two step process. First, you need -to create a <it/font directory/ that contains all the relevant font -files as well as some index files. You then need to inform the X -server of the existence of this new directory by including it in the -<it/font path/. +<it>(What about Mozilla?)</it> -<sect1>Installing bitmap fonts +<sect2>Troubleshooting <label id="sec:troubleshooting-xft"> + +<p>If some Xft-based applications don't seem to notice the changes you +are making to your configuration files, they may be linked against the +XFree86 4.2 version of Xft. In order to fix the problem, you should +relink them against a current version of Xft; on most systems, it is +enough to install the current version of the Xft and Fontconfig +libraries. + +If, for some reason, you cannot upgrade the shared libraries, please +check the <htmlurl name="Xft(3)" url="Xft.3.html"> manual page included +with XFree86 4.2 for the configuration mechanisms of the previous version +of Xft. + +<sect1>Configuring the core X11 fonts system + +<p>Installing fonts in the core system is a two step process. First, +you need to create a <it/font directory/ that contains all the +relevant font files as well as some index files. You then need to +inform the X server of the existence of this new directory by +including it in the <it/font path/. + +<sect2>Installing bitmap fonts <p>The XFree86 server can use bitmap fonts in both the cross-platform BDF format and the somewhat more efficient binary PCF format. @@ -53,7 +228,7 @@ command `<tt/bdftopcf/', <it/e.g./ <tscreen><verb> $ bdftopcf courier12.bdf </verb></tscreen> -You may then want to compress the resulting PCF font files: +You will then want to compress the resulting PCF font files: <tscreen><verb> $ gzip courier12.pcf </verb></tscreen> @@ -62,23 +237,23 @@ After the fonts have been converted, you should copy all the font files that you wish to make available into a arbitrary directory, say `<tt>/usr/local/share/fonts/bitmap/</tt>'. You should then create the index file `<tt/fonts.dir/' by running the command `<tt/mkfontdir/' -(please see the <tt/mkfontdir/(1) manual page for more information): +(please see the <htmlurl name="mkfontdir(1)" url="mkfontdir.1.html"> +manual page for more information): <tscreen><verb> -$ mkdir /usr/local/share/fonts/bitmap -$ cp *.pcf.gz /usr/local/share/fonts/bitmap -$ cd /usr/local/share/fonts/bitmap -$ mkfontdir +$ mkdir /usr/local/share/fonts/bitmap/ +$ cp *.pcf.gz /usr/local/share/fonts/bitmap/ +$ mkfontdir /usr/local/share/fonts/bitmap/ </verb></tscreen> All that remains is to tell the X server about the existence of the -new font directory; see Section <ref id="sec:set-font-path" -name="Setting the server font path">. +new font directory; see <ref id="sec:set-font-path" name="Setting the +server font path"> below. -<sect1>Installing scalable fonts +<sect2>Installing scalable fonts <p>The XFree86 server supports scalable fonts in four formats: Type 1, Speedo, TrueType and CIDFont. This section only applies -to the former three; for information on CIDFonts, please see Section +to the former three; for information on CIDFonts, please see <ref id="sec:cid-fonts" name="Installing CIDFonts"> later in this document. @@ -89,65 +264,26 @@ to create an index file called `<tt/fonts.dir/'. There is, however, a big difference: `<tt/mkfontdir/' cannot automatically recognise scalable font files. For that reason, you must first index all the font files in a file called -`<tt/fonts.scale/'. This file has the same format as a -`<tt/fonts.dir/' file, and typically looks as follows: -<tscreen><verb> -4 -cour.pfa -adobe-courier-medium-r-normal-0-0-0-0-p-0-iso8859-1 -cour.pfa -adobe-courier-medium-r-normal-0-0-0-0-p-0-iso8859-2 -couri.pfa -adobe-courier-medium-i-normal-0-0-0-0-p-0-iso8859-1 -couri.pfa -adobe-courier-medium-i-normal-0-0-0-0-p-0-iso8859-2 -</verb></tscreen> -The first line indicates the number of entries in the file. -Each line after the first consists of two fields separated by a space; -the first field is the name of the font file, and the second one is -the name under which the font will appear to the server. This name -should obey the X Logical Font Description conventions (see Section -<ref id="sec:xlfd" name="The X Logical Font Description">). The -format of this file is fully described in the <tt/mkfontdir/(1) manual -page. - -Note that multiple lines may point at the same font file. This is -most commonly done in order to make a single font available under -multiple encodings; please see Section -<ref id="sec:internationalisation" name="Fonts and internationalisation">. - -While it is possible to create the `<tt/fonts.scale/' file by hand, it -is simpler and more convenient to have it generated automatically. -Utilities to perform this task are available, but are not currently -included with XFree86. For Type 1 fonts, you may use a utility -called `<tt/type1inst/' which is available from -<url url="http://www.ibiblio.org/pub/Linux/X11/xutils/" name="standard -Free Software repositories"> throughout the world. - -For TrueType fonts, you may use `<tt/ttmkfdir/', available from -<url name="Joerg Pommnitz's xfsft page" - url="http://www.joerg-pommnitz.de/TrueType/xfsft.html">. - -After the `<tt/fonts.scale/' is created, you may run `<tt/mkfontdir/' as -above; this time, however, you need to create an index of encoding -files called `<tt>encodings.dir</tt>' in addition to the -`<tt>fonts.dir</tt>' file. This is done by using `<tt/mkfontdir/' with -the `<tt/-e/' flag: -<tscreen><verb> -$ cd /usr/local/share/fonts/Type1 -$ mkfontdir -e /usr/X11R6/lib/font/encodings -</verb></tscreen> -For more information, please see the <tt/mkfontdir/(1) manual page and -Section <ref id="sec:internationalisation" name="Fonts and -internationalisation"> later in this document. - -<sect1>Installing CID-keyed fonts <label id="sec:cid-fonts"> +`<tt/fonts.scale/'. While this can be done by hand, it is best done +by using the `<tt/mkfontscale/' utility. +<tscreen><verb> +$ mkfontscale /usr/local/share/fonts/Type1/ +$ mkfontdir /usr/local/share/fonts/Type1/ +</verb></tscreen> +Under some circumstances, it may be necessary to modify the +`<tt/fonts.scale/' file generated by <tt/mkfontscale/; for more +information, please see the <htmlurl name="mkfontdir(1)" +url="mkfontdir.1.html"> and <htmlurl name="mkfontscale(1)" +url="mkfontscale.1.html"> manual pages and <ref +id="sec:internationalisation" name="Core fonts and internationalisation"> +later in this document. + +<sect2>Installing CID-keyed fonts <label id="sec:cid-fonts"> <p>The CID-keyed font format was designed by Adobe Systems for fonts with large character sets. A CID-keyed font, or CIDFont for short, contains a collection of glyphs indexed by <it/character ID/ (CID). -Adobe make some sample CIDFonts and a complete set of CMaps -available from -<url name="O'Reilly's FTP site" - url="ftp://ftp.oreilly.com/pub/examples/nutshell/cjkv/adobe/">. - In order to map such glyphs to meaningful indices, Adobe provide a set of <it/CMap/ files. The PostScript name of a font generated from a CIDFont consists of the name of the CIDFont and the name of the CMap @@ -158,7 +294,7 @@ called Munhwa-Regular--UniKS-UCS2-H </verb></tscreen> -The CIDFont support in XFree86 requires a very rigid directory +The CIDFont code in XFree86 requires a very rigid directory structure. The main directory must be called `<tt/CID/' (its location defaults to `<tt>/usr/X11R6/lib/X11/fonts/CID</tt>' but it may be located anywhere), and it should contain a subdirectory for every CID @@ -187,7 +323,7 @@ its first column contains PostScript font names with the extension Adobe-Korea1/Munhwa-Regular--UniKS-UCS2-H.cid \ -adobe-munhwa-medium-r-normal--0-0-0-0-p-0-iso10646-1 </verb></tscreen> -(both names on the same line). As above, running `<tt/mkfontdir/' +(both names on the same line). Running `<tt/mkfontdir/' creates the `<tt/fonts.dir/' file: <tscreen><verb> $ cd /usr/local/share/fonts/CID @@ -205,11 +341,11 @@ the CID fonts but querying them will take a long time. You should run fonts, or when the CID-keyed fonts are copied to a machine with a different architecture. -<sect1>Setting the server's font path <label id="sec:set-font-path"> +<sect2>Setting the server's font path <label id="sec:set-font-path"> <p>The list of directories where the server looks for fonts is known as the <it/font path/. Informing the server of the existence of a new -font directory consists in putting it on the font path. +font directory consists of putting it on the font path. The font path is an ordered list; if a client's request matches multiple fonts, the first one in the font path is the one that gets @@ -229,7 +365,7 @@ You may check the font path of the running server by typing the command $ xset q </verb></tscreen> -<sect2>Temporary modification of the font path +<sect3>Temporary modification of the font path <p>The `<tt/xset/' utility may be used to modify the font path for the current session. The font path is set with the command <tt/xset fp/; @@ -242,35 +378,40 @@ $ xset fp+ /usr/local/fonts/bitmap Conversely, an element may be removed from the front of the font path with `<tt/xset -fp/', and removed from the end with `<tt/xset fp-/'. +You may reset the font path to its default value with +`<tt/xset fp default/'. -For more information, please consult the <tt/xset/(1) manual page. +For more information, please consult the <htmlurl name="xset(1)" +url="xset.1.html"> manual page. -<sect2>Permanent modification of the font path +<sect3>Permanent modification of the font path -<p>The default font path (the one used just after server startup) is -specified in the X server's `<tt/XF86Config/' file. It is computed by -appending all the directories mentioned in the `<tt/FontPath/' entries -of the `<tt/Files/' section in the order in which they appear. +<p>The default font path (the one used just after server startup or +after `<tt/xset fp default/') is specified in the X server's +`<tt/XF86Config/' file. It is computed by appending all the +directories mentioned in the `<tt/FontPath/' entries of the +`<tt/Files/' section in the order in which they appear. <tscreen><verb> FontPath "/usr/local/fonts/Type1" ... FontPath "/usr/local/fonts/bitmap" </verb></tscreen> -For more information, please consult the `<tt/XF86Config/'(5) manual -page. +For more information, please consult the <htmlurl name="XF86Config(5)" +url="XF86Config.5.html"> manual page. -<sect1>Troubleshooting <label id="sec:troubleshooting"> +<sect2>Troubleshooting <label id="sec:troubleshooting-core"> <p>If you seem to be unable to use some of the fonts you have installed, the first thing to check is that the `<tt/fonts.dir/' files -are correct and that they are readable by the server. If this doesn't -help, it is quite possible that you are trying to use a font in a -format that is not supported by your server. +are correct and that they are readable by the server (the X server +usually runs as root, beware of NFS-mounted font directories). If +this doesn't help, it is quite possible that you are trying to use a +font in a format that is not supported by your server. -XFree86 supports the BDF, PCF, SNF, Type 1, Speedo, TrueType and -CIDFont font formats. However, not all XFree86 servers come with all -the font backends configured in. +XFree86 supports the BDF, PCF, SNF, Type 1, Speedo, TrueType, OpenType +and CIDFont font formats. However, not all XFree86 servers come with +all the font backends configured in. On most platforms, the XFree86 servers are <it/modular/: the font backends are included in modules that are loaded at runtime. The @@ -286,12 +427,14 @@ distributed with XFree86 is as follows: <itemize> <item> <tt/"bitmap"/: bitmap fonts (`<tt/*.bdf/', `<tt/*.pcf/' and `<tt/*.snf/'); -<item> <tt/"type1"/: Type 1 fonts (`<tt/*.pfa/' and -`<tt/*.pfb/') and CIDFonts; -<item> <tt/"speedo"/: Bitstream Speedo fonts (`<tt/*.spd/'); -<item> <tt/"freetype"/: TrueType fonts (`<tt/*.ttf/' and `<tt/*.ttc/'); +<item> <tt/"freetype"/: TrueType fonts (`<tt/*.ttf/' and +`<tt/*.ttc/'), OpenType fonts (`<tt/*.otf/' and `<tt/*.otc/') and +Type 1 fonts (`<tt/*.pfa/' and `<tt/*.pfb/'); +<item> <tt/"type1"/: alternate Type 1 backend (`<tt/*.pfa/' and +`<tt/*.pfb/') and CIDFont backend; <item> <tt/"xtt"/: alternate TrueType backend (`<tt/*.ttf/' and -`<tt/*.ttc/'). +`<tt/*.ttc/'); +<item> <tt/"speedo"/: Bitstream Speedo fonts (`<tt/*.spd/'). </itemize> Please note that the argument of the `<tt/Load/' directive is case-sensitive. @@ -300,14 +443,15 @@ case-sensitive. <sect1>Standard bitmap fonts -<p>The Sample Implementation of X11 comes with a large number of +<p>The Sample Implementation of X11 (SI) comes with a large number of bitmap fonts, including the `<tt/fixed/' family, and bitmap versions -of Courier, Times and Helvetica. In the SI, these fonts are provided -in the ISO 8859-1 encoding (ISO Latin Western-European). +of Courier, Times, Helvetica and some members of the Lucida family. In +the SI, these fonts are provided in the ISO 8859-1 encoding (ISO +Latin Western-European). In XFree86, a number of these fonts are provided in Unicode-encoded font files instead. At build time, these fonts are split into font -files encoded according to legacy encodings, a process which enables +files encoded according to legacy encodings, a process which allows us to provide the standard fonts in a number of regional encodings with no duplication of work. @@ -321,7 +465,7 @@ with XLFD </verb></tscreen> is a Unicode-encoded version of the standard `<tt/fixed/' font with added support for the Latin, Greek, Cyrillic, Georgian, Armenian, IPA -and other scripts plus numerous technical symbols. It contains over +and other scripts plus numerous technical symbols. It contains over 2800 glyphs, covering all characters of ISO 8859 parts 1-5, 7-10, 13-15, as well as all European IBM and Microsoft code pages, KOI8, WGL4, and the repertoires of many other character sets. @@ -330,29 +474,14 @@ This font is used at build time for generating the font files <tscreen><verb> 6x13-ISO8859-1.bdf 6x13-ISO8859-2.bdf -6x13-ISO8859-3.bdf -6x13-ISO8859-4.bdf -6x13-ISO8859-5.bdf -6x13-ISO8859-7.bdf -6x13-ISO8859-8.bdf -6x13-ISO8859-9.bdf -6x13-ISO8859-10.bdf -6x13-ISO8859-13.bdf +... 6x13-ISO8859-15.bdf 6x13-KOI8-R.bdf </verb></tscreen> with respective XLFDs <tscreen><verb> -misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-1 --misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-2 --misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-3 --misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-4 --misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-5 --misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-7 --misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-8 --misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-9 --misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-10 --misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-13 +... -misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-15 -misc-fixed-medium-r-normal--13-120-75-75-c-60-koi8-r </verb></tscreen> @@ -361,10 +490,6 @@ The standard short name `<tt/fixed/' is normally an alias for -misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-1 </verb></tscreen> -(The conversion of the standard fonts to Unicode was mainly performed -by Markus Kuhn. Markus is a man of taste, which makes his use of Perl -in the conversion process somewhat surprising.) - <sect1>The ClearlyU Unicode font family <p>The ClearlyU family of fonts provides a set of 12 pt, @@ -403,10 +528,6 @@ of the characters in the ISO 10646 standard. The <it/Ligature/ font contains ligatures for various scripts that may be useful for improved presentation of text. -(The ClearlyU family was designed by Mark Leisher. Mark's usage of -the foundry name <it/mutt/ predates the mailer of the same name, but -he won't say more.) - <sect1>Standard scalable fonts <p>XFree86 includes all the scalable fonts distributed with X11R6. @@ -449,8 +570,8 @@ and reside in the font files <p>XFree86 includes Speedo versions of the Bitstream Courier and Charter fonts. In order to use these fonts, you should ensure that -your X server is loading the `<tt/Speedo/' font backend; see Section -<ref id="sec:troubleshooting" name="Troubleshooting">. +your X server is loading the `<tt/Speedo/' font backend; see +<ref id="sec:troubleshooting-core" name="Troubleshooting">. These fonts cover all of ISO 8859-1 and almost all of ISO 8859-2. They have XLFD name @@ -485,14 +606,14 @@ range, the Latin 1 range, as well as the <it/Extended Latin/ range and some additional punctuation characters. In particular, these fonts include all the glyphs needed for ISO 8859 parts 1, 2, 3, 4, 9, 13 and 15, as well as all the glyphs in the Adobe Standard -encoding and the Windows 3.1 character set. +encoding and the Windows 3.1 character set. The glyph coverage of the Type 1 versions is somewhat reduced, and only covers ISO 8859 parts 1, 2 and 15 as well as the Adobe Standard encoding. The Luxi fonts are original designs by Kris Holmes and Charles -Bigelow. Luxi fonts include seriffed, sans serif, and monospaced +Bigelow. Luxi fonts include seriffed, sans serif, and monospaced styles, in roman and oblique, and normal and bold weights. The fonts share stem weight, x-height, capital height, ascent and descent, for graphical harmony. @@ -519,13 +640,18 @@ For more information, please contact An earlier version of the Luxi fonts was made available under the name <em/Lucidux/. This name should no longer be used due to trademark uncertainties, and all traces of the <em/Lucidux/ name have been -removed from this version of XFree86. +removed from XFree86. + +<sect>More about core fonts <label id="sec:more-core"> -<sect>Fonts and internationalisation <label id="sec:internationalisation"> +<p>This section describes XFree86-specific enhancements to the core +X11 fonts system. + +<sect1>Core fonts and internationalisation <label id="sec:internationalisation"> <p>The scalable font backends (Type 1, Speedo and TrueType) can -now automatically re-encode fonts to the encoding specified in the -XLFD in <tt/fonts.dir/. For example, a <tt/fonts.dir/ file can +automatically re-encode fonts to the encoding specified in the +XLFD in `<tt/fonts.dir/'. For example, a `<tt/fonts.dir/' file can contain entries for the Type 1 Courier font such as <tscreen><verb> cour.pfa -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1 @@ -534,7 +660,7 @@ cour.pfa -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-2 which will lead to the font being recoded to ISO 8859-1 and ISO 8859-2 respectively. -<sect1>The <it/fontenc/ layer <label id="sec:fontenc"> +<sect2>The <it/fontenc/ layer <label id="sec:fontenc"> <p>Three of the scalable backends (Type 1, Speedo, and the <it/FreeType/ TrueType backend) use a common <it/fontenc/ layer for @@ -545,10 +671,9 @@ font type. <it/Please note:/ the X-TrueType (X-TT) backend does not use the <it/fontenc/ layer, but instead uses its own method for font reencoding. If you are only interested in X-TT you may want to skip -to Section <ref id="sec:symbol-fonts" name="Using Symbol Fonts">, as +to <ref id="sec:symbol-fonts" name="Using Symbol Fonts">, as the intervening information does not apply to X-TT. X-TT itself is -described in more detail in Section <ref id="sec:X-TT" -name="X-TrueType">. +described in more detail in <ref id="sec:X-TT" name="X-TrueType">. In the <it/fontenc/ layer, an encoding is defined by a name (such as <tt/iso8859-1/), possibly a number of aliases (alternate names), and @@ -576,7 +701,7 @@ redefined. These include: Western-European); <item> <tt/koi8-r/: KOI8 Russian; <item> <tt/koi8-u/: KOI8 Ukrainian (see RFC 2319); -<item> <tt/koi8-ru/: KOI8 Russian/Ukrainian +<item> <tt/koi8-ru/: KOI8 Russian/Ukrainian; <item> <tt/koi8-uni/: KOI8 ``Unified'' (Russian, Ukrainian, and Byelorussian); <item> <tt/koi8-e/: KOI8 ``European,'' ISO-IR-111, or ECMA-Cyrillic; @@ -592,39 +717,47 @@ file named `<tt/encodings.dir/'. If found, this file is scanned for the requested encoding, and the relevant encoding definition file is read in. The `<tt/mkfontdir/' utility, when invoked with the `<tt/-e/' option followed by the name of a directory containing -encoding files, can be used to automatically build -`<tt/encodings.dir/' files. See the <tt/mkfontdir/(1) manual page for -more details. +encoding files, can be used to automatically build `<tt/encodings.dir/' +files. Please see the <htmlurl name="mkfontdir(1)" url="mkfontdir.1.html"> +manual page for more details. A number of encoding files for common encodings are included with XFree86. Information on writing new encoding files can be found in -Section <ref id="sec:format-encoding-directory-files" name="Format of +<ref id="sec:format-encoding-directory-files" name="Format of encodings directory files"> and <ref id="sec:format-encoding-files" name="Format of encoding files"> later in this document. -<sect1>Backend-specific notes about fontenc +<sect2>Backend-specific notes about fontenc + +<sect3>The <it/FreeType/ backend <label id="sec:fontenc-freetype" -<sect2>Type 1 +<p>For TrueType and OpenType fonts, the FreeType backend scans the +mappings in order. Mappings with a target of PostScript are ignored; +mappings with a TrueType or Unicode target are checked against all the +cmaps in the file. The first applicable mapping is used. -<p>The Type 1 backend first searches for a mapping with a target -of PostScript. If one is found, it is used. Otherwise, the -backend searches for a mapping with target Unicode, which is then -composed with a built-in table mapping codes to glyph names. Note -that this table only covers part of the Unicode code points that have -been assigned names by Adobe. +For Type 1 fonts, the FreeType backend first searches for a +mapping with a target of PostScript. If one is found, it is used. +Otherwise, the backend searches for a mapping with target Unicode, +which is then composed with a built-in table mapping codes to glyph +names. Note that this table only covers part of the Unicode code +points that have been assigned names by Adobe. -If neither a PostScript or Unicode mapping is found, the backend -defaults to ISO 8859-1. +Specifying an encoding value of <tt/adobe-fontspecific/ for a +Type 1 font disables the encoding mechanism. This is useful with +symbol and incorrectly encoded fonts (see <ref +id="sec:incorrect-encoding" name="Incorrectly encoded fonts"> below). -Specifying an encoding value of <tt/adobe-fontspecific/ disables -the encoding mechanism. This is useful with symbol and incorrectly -encoded fonts (see Section -<ref id="sec:incorrect-encoding" name="Incorrectly encoded fonts"> -below). +If a suitable mapping is not found, the FreeType backend defaults to +ISO 8859-1. + +<sect3>Type 1 -The Type 1 backend currently limits all encodings to 8-bit codes. +<p>The Type 1 backend behaves similarly to the FreeType backend +with Type 1 fonts, except that it limits all encodings to 8-bit +codes. -<sect2>Speedo +<sect3>Speedo <p>The Speedo backend searches for a mapping with a target of Unicode, and uses it if found. If none is found, the backend defaults to @@ -632,28 +765,19 @@ ISO 8859-1. The Speedo backend limits all encodings to 8-bit codes. -<sect2>The <it/FreeType/ TrueType backend <label id="sec:fontenc-freetype" - -<p>The TrueType backend scans the mappings in order. Mappings with a -target of PostScript are ignored; mappings with a TrueType or Unicode -target are checked against all the cmaps in the file. The first -applicable mapping is used. - -If you are writing an encoding file to be used with the TrueType -backend, you should ensure that mappings are mentioned in decreasing -order of preference. - -<sect1>Format of encoding directory files <label id="sec:format-encoding-directory-files"> +<sect2>Format of encoding directory files <label id="sec:format-encoding-directory-files"> <p>In order to use a font in an encoding that the font backend does -not know about, you need to have an `<tt/encodings.dir/' file in the -same directory as the font file used. The `<tt/encodings.dir/' file -has a similar format to `<tt/fonts.dir/'. Its first line specifies -the number of encodings, while every successive line has two columns, -the name of the encoding, and the name of the encoding file; this can -be relative to the current directory, or absolute. Every encoding -name should agree with the encoding name defined in the encoding file. -For example, +not know about, you need to have an `<tt/encodings.dir/' file either +in the same directory as the font file used or in a system-wide +location (`<tt>/usr/X11R6/lib/X11/fonts/encodings/</tt>' by default). + +The `<tt/encodings.dir/' file has a similar format to +`<tt/fonts.dir/'. Its first line specifies the number of encodings, +while every successive line has two columns, the name of the encoding, +and the name of the encoding file; this can be relative to the current +directory, or absolute. Every encoding name should agree with the +encoding name defined in the encoding file. For example, <tscreen><verb> 3 @@ -670,10 +794,10 @@ If your platform supports it (it probably does), encoding files may be compressed or gzipped. The `<tt/encoding.dir/' files are best maintained by the -`<tt/mkfontdir/' utility. Please see the <tt/mkfontdir/(1) manual -page for more information. +`<tt/mkfontdir/' utility. Please see the <htmlurl name="mkfontdir(1)" +url="mkfontdir.1.html"> manual page for more information. -<sect1>Format of encoding files <label id="sec:format-encoding-files"> +<sect2>Format of encoding files <label id="sec:format-encoding-files"> <p>The encoding files are ``free form,'' <it/i.e./ any string of whitespace is equivalent to a single space. Keywords are parsed in a @@ -693,7 +817,6 @@ encoding, and possibly its alternate names (aliases): <tscreen><verb> STARTENCODING mulearabic-0 ALIAS arabic-0 -ALIAS something-else </verb></tscreen> The name of the encoding and its aliases should be suitable for use in an XLFD font name, and therefore contain exactly one dash `<tt/-/'. @@ -818,7 +941,7 @@ In order to make future extensions to the format possible, lines starting with an unknown keyword are silently ignored, as are mapping sections with an unknown target. -<sect1>Using symbol fonts <label id="sec:symbol-fonts"> +<sect2>Using symbol fonts <label id="sec:symbol-fonts"> <p>Type 1 symbol fonts should be installed using the <tt/adobe-fontspecific/ encoding. @@ -833,22 +956,23 @@ In order to guarantee consistent results (especially between Type 1 and TrueType versions of the same font), it is possible to define a special encoding for a given font. This has already been done for the <tt/ZapfDingbats/ font; see the file -<tt>encodings/adobe-dingbats.enc</tt>. +`<tt>encodings/adobe-dingbats.enc</tt>'. -<sect1>Hints about using badly encoded fonts <label id="sec:incorrect-encoding"> +<sect2>Hints about using badly encoded fonts <label id="sec:incorrect-encoding"> <p>A number of text fonts are incorrectly encoded. Incorrect encoding is sometimes done by design, in order to make a font for an exotic -script appear like an ordinary Western text font. It is often the -result of the font designer's laziness or incompetence; for some -reason, most people seem to find it easier to invent idiosyncratic -glyph names rather than follow the Adobe glyph list. +script appear like an ordinary Western text font on systems which are +not easily extended with new locale data. It is often the result of +the font designer's laziness or incompetence; for some reason, most +people seem to find it easier to invent idiosyncratic glyph names +rather than follow the Adobe glyph list. There are two ways of dealing with such fonts: using them with the encoding they were designed for, and creating an <it/ad hoc/ encoding file. -<sect2>Using fonts with the designer's encoding +<sect3>Using fonts with the designer's encoding <p>In the case of Type 1 fonts, the font designer can specify a default encoding; this encoding is requested by using the @@ -865,13 +989,13 @@ so one of `<tt/microsoft-symbol/', `<tt/microsoft-cp1252/', `<tt/microsoft-win3.1/', or `<tt/apple-roman/' should yield reasonable results. -<sect2>Specifying an <it/ad hoc/ encoding file +<sect3>Specifying an <it/ad hoc/ encoding file <p>It is always possible to define an encoding file to put the glyphs in a font in any desired order. Again, see the `<tt>encodings/adobe-dingbats.enc</tt>' file to see how this is done. -<sect2>Specifying font aliases +<sect3>Specifying font aliases <p>By following the directions above, you will find yourself with a number of fonts with unusual names --- with encodings such as @@ -880,37 +1004,31 @@ to use these fonts with standard applications, it may be useful to remap them to their proper names. This is done by writing a `<tt/fonts.alias/' file. The format of this file -is very simple: it consists of a series of lines each mapping an alias name to a font name. A `<tt/fonts.alias/' file might look as follows: +is very simple: it consists of a series of lines each mapping an alias +name to a font name. A `<tt/fonts.alias/' file might look as follows: <tscreen><verb> "-ogonki-alamakota-medium-r-normal--0-0-0-0-p-0-iso8859-2" \ "-ogonki-alamakota-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific" </verb></tscreen> (both XLFD names on a single line). The syntax of the `<tt/fonts.alias/' file is more precisely described in the -<tt/mkfontdir/(1) manual page. +<htmlurl name="mkfontdir(1)" url="mkfontdir.1.html"> manual page. -<sect>Additional notes about TrueType support +<sect1>Additional notes about scalable core fonts -<p>This version of XFree86 comes with two TrueType backends, -<it/FreeType/ (module `<tt/freetype/', formerly known as <it/xfsft/) and -<it/X-TrueType/ (module `<tt/xtt/'). These two backends are <it/not/ -compatible: only one of them can be used at any one time. +<p>The FreeType backend (module `<tt/freetype/', formerly known +as <it/xfsft/) is able to deal with both TrueType and Type 1 +fonts. This puts it in conflict with the X-TT and Type 1 +backends respectively. -In order to use the <it/FreeType/ backend, please check that the -`<tt/Module/' section of your `<tt/XF86Config/' file contains a line -that reads -<tscreen><verb> -Load "freetype" -</verb></tscreen> +If both the FreeType and the Type 1 backends are loaded, the +FreeType backend will be used for Type 1 fonts. If both the +FreeType and X-TT backends are loaded, X-TT will be used for TrueType +fonts. -In order to use the <it/X-TrueType/ backend, replace the line in your -<tt/XF86Config/ file that loads the <tt/freetype/ module with a -line that reads -<tscreen><verb> - Load "xtt" -</verb></tscreen> +<sect2>Delayed glyph rasterisation -Both TrueType backends delay glyph rasterisation up to the time at +<p>Both FreeType and X-TT delay glyph rasterisation up to the time at which a glyph is first used. For this reason, they only provide an approximate value for the ``average width'' font property. @@ -925,14 +1043,17 @@ trust the font really to be a character-cell font. You are encouraged to make use of this optimisation when useful, but be warned that not all monospaced fonts are character-cell fonts. -<sect1>The <it/FreeType/ TrueType backend +<sect2>About the <it/FreeType/ backend -<p>The <it/FreeType/ backend (formerly <it/xfsft/) is a backend based on -the FreeType library (see <url url="http://www.freetype.org/" -name="the FreeType web site">) and has support for the ``fontenc'' -style of internationalisation (see Section <ref id="sec:fontenc" -name="The fontenc layer">). This backend supports TrueType Font files -(`<tt/*.ttf/') and TrueType Collections (`<tt/*.ttc/'). +<p>The <it/FreeType/ backend (formerly <it/xfsft/) is a backend based +on version 2 of the FreeType library (see <url +url="http://www.freetype.org/" name="the FreeType web site">) and has +support for the ``fontenc'' style of internationalisation (see +<ref id="sec:fontenc" name="The fontenc layer">). This backend +supports TrueType font files (`<tt/*.ttf/'), OpenType font files +(`<tt/*.otf/'), TrueType Collections (`<tt/*.ttc/'), OpenType +Collections (`<tt/*.otc/') and Type 1 font files (`<tt/*.pfa/' and +`<tt/*.pfb/'). In order to access the faces in a TrueType Collection file, the face number must be specified in the fonts.dir file before the filename @@ -943,21 +1064,21 @@ within colons. For example, refers to face 2 in the `<tt/mincho.ttc/' TrueType Collection file. The <it/FreeType/ backend uses the <it/fontenc/ layer in order to -support recoding of fonts; this was described in Section <ref -id="sec:fontenc" name="The fontenc layer"> and especially Section <ref +support recoding of fonts; this was described in <ref +id="sec:fontenc" name="The fontenc layer"> and especially <ref id="sec:fontenc-freetype" name="FreeType-specific notes about fontenc"> earlier in this document. -<sect1>The <it/X-TrueType/ TrueType backend <label id="sec:X-TT"> +<sect2>About the <it/X-TrueType/ TrueType backend <label id="sec:X-TT"> -<p>The `X-TrueType' backend is another backend based on the FreeType -library. X-TrueType doesn't use the `fontenc' layer for managing font -encodings, but instead uses its own database of encodings. However, -X-TrueType includes a large number of encodings, and any encoding you -need is likely to be present in X-TrueType. +<p>The `X-TrueType' backend is a backend based on version 1 of the +FreeType library. X-TrueType doesn't use the `fontenc' layer for +managing font encodings, but instead uses its own database of +encodings. X-TrueType extends the `<tt/fonts.dir/' syntax with a number of options, -known as `TTCap'. A `TTCap' entry follows the general syntax +collectively known as `TTCap'. A `TTCap' entry follows the general +syntax <tscreen><verb> :option=value: </verb></tscreen> @@ -979,29 +1100,28 @@ home page">. <p>A computer text-processing system inputs keystrokes and outputs <it/glyphs/, small pictures that are assembled on paper or on a computer screen. Keystrokes and glyphs do not, in general, coincide: -for example, if the system does generate ligatures, then to the two -keystrokes <<tt/f/><<tt/i/> will typically correspond a -single glyph. Similarly, if the system shapes Arabic glyphs in a -reasonable manner, then multiple different glyphs may correspond to -a single keystroke. +for example, if the system does generate ligatures, then to the +sequence of two keystrokes <<tt/f/><<tt/i/> will typically +correspond a single glyph. Similarly, if the system shapes Arabic +glyphs in a vaguely reasonable manner, then multiple different glyphs +may correspond to a single keystroke. The complex transformation rules from keystrokes to glyphs are usually -factored into two simpler transformations, going through the -intermediary of <it/characters/. You may want to think of characters -as the basic unit of data that is stored <it/e.g./ in the buffer of -your text editor. While the definition of a character is intrinsically -application-specific, a number of standardised collections of -characters have been defined. +factored into two simpler transformations, from keystrokes to +<it/characters/ and from characters to glyphs. You may want to think +of characters as the basic unit of text that is stored <it/e.g./ in +the buffer of your text editor. While the definition of a character +is intrinsically application-specific, a number of standardised +collections of characters have been defined. A <it/coded character set/ is a set of characters together with a mapping from integer codes --- known as <it/codepoints/ --- to characters. Examples of coded character sets include US-ASCII, ISO 8859-1, KOI8-R, and JIS X 0208(1990). -A coded character set need not use 8 bit integers to index -characters. Many early mainframes used 6 bit character sets, while -16 bit (or more) character sets are necessary for ideographic writing -systems. +A coded character set need not use 8 bit integers to index characters. +Many early systems used 6 bit character sets, while 16 bit (or more) +character sets are necessary for ideographic writing systems. <sect1>Font files, fonts, and XLFD <label id="sec:xlfd"> @@ -1010,7 +1130,7 @@ systems. Times Italic, while a fount is a molten-lead incarnation of a given typeface at a given size. -Digital fonts come in <it/font files/. A font file contains all the +Digital fonts come in <it/font files/. A font file contains the information necessary for generating glyphs of a given typeface, and applications using font files may access glyph information in an arbitrary order. @@ -1020,7 +1140,7 @@ to be <it/bitmap fonts/. They may also consist of a mathematical description of glyph shapes, in which case they are said to be <it/scalable fonts/. Common formats for scalable font files are <it/Type 1/ (sometimes incorrectly called <it/ATM fonts/ or -<it/PostScript fonts/), <it/Speedo/ and <it/TrueType/. +<it/PostScript fonts/), <it/TrueType/ and <it/Speedo/. The glyph data in a digital font needs to be indexed somehow. How this is done depends on the font file format. In the case of @@ -1028,31 +1148,36 @@ Type 1 fonts, glyphs are identified by <it/glyph names/. In the case of TrueType fonts, glyphs are indexed by integers corresponding to one of a number of indexing schemes (usually Unicode --- see below). -The X11 system uses the data in font file to generate <it/font -instances/, which are collections of glyphs at a given size indexed -according to a given encoding. +The X11 core fonts system uses the data in a font file to generate +<it/font instances/, which are collections of glyphs at a given size +indexed according to a given encoding. -X11 font instances are usually specified using a notation known as the -<it/X Logical Font Description/ (XLFD). An XLFD starts with a dash -`<tt/-/', and consists of fourteen fields separated by dashes, for -example +X11 core font instances are usually specified using a notation known +as the <it/X Logical Font Description/ (XLFD). An XLFD starts with a +dash `<tt/-/', and consists of fourteen fields separated by dashes, +for example: <tscreen><verb> --adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1 +-adobe-courier-medium-r-normal--12-120-75-75-m-70-iso8859-1 </verb></tscreen> Or particular interest are the last two fields `<tt/iso8859-1/', which specify the font instance's encoding. +A scalable font is specified by an XLFD which contains zeroes instead +of some fields: +<tscreen><verb> +-adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1 +</verb></tscreen> + X11 font instances may also be specified by short name. Unlike an XLFD, a short name has no structure and is simply a conventional name for a font instance. Two short names are of particular interest, as -they are handled specially by the server, and the server will not -start if font instances with these names cannot be opened. These are -`<tt/fixed/', which specifies the fallback font to use when the -requested font cannot be opened, and `<tt/cursor/', which specifies -the set of glyphs to be used by the mouse pointer. +the server will not start if font instances with these names cannot be +opened. These are `<tt/fixed/', which specifies the fallback font to +use when the requested font cannot be opened, and `<tt/cursor/', which +specifies the set of glyphs to be used by the mouse pointer. Short names are usually implemented as aliases to XLFDs; the -`<tt/fixed/' and `<tt/cursor/' aliases are defined in +standard `<tt/fixed/' and `<tt/cursor/' aliases are defined in <tscreen><verb> /usr/X11R6/lib/X11/font/misc/fonts.alias </verb></tscreen> @@ -1068,40 +1193,59 @@ such. Unicode is an <it/open/ character set, meaning that codepoint assignments may be added to Unicode at any time (once specified, though, an assignment can never be changed). For this reason, a -Unicode font will be <it/sparse/, and only define glyphs for a subset -of the character registry of Unicode. +Unicode font will be <it/sparse/, meaning that it only defines glyphs +for a subset of the character registry of Unicode. The Unicode standard is defined in parallel with the international standard ISO 10646. Assignments in the two standards are always -equivalent, and this document uses the terms <it/Unicode/ and +equivalent, and we often use the terms <it/Unicode/ and <it/ISO 10646/ interchangeably. -When used in X11, Unicode-encoded fonts should have the last two -fields of their XLFD set to `<tt/iso10646-1/'. +When used in the X11 core fonts system, Unicode-encoded fonts should +have the last two fields of their XLFD set to `<tt/iso10646-1/'. <sect>References <p>XFree86 comes with extensive documentation in the form of manual -pages and typeset documents. Before installing fonts, you really -should read the <tt/mkfontdir/(1) manual page; other manual pages of -interest include <tt/X/(1), <tt/Xserver/(1), <tt/xset/(1), -<tt/xlsfonts/(1) and <tt/showfont/(1). In addition, you may want to -read the X Logical Font Description document, by Jim Flowers, which is -provided in the file `<tt>xc/doc/xlfd.PS.Z</tt>'. +pages and typeset documents. Before installing fonts, you really should +read the <htmlurl name="fontconfig(3)" url="fontconfig.3.html"> and +<htmlurl name="mkfontdir(1)" url="mkfontdir.1.html"> manual pages; other +manual pages of interest include <htmlurl name="X(7)" url="X.7.html">, +<htmlurl name="Xserver(1)" url="Xserver.1.html">, <htmlurl name="xset(1)" +url="xset.1.html">, <htmlurl name="Xft(3)" url="Xft.3.html">, <htmlurl +name="xlsfonts(1)" url="xlsfonts.1.html"> and <htmlurl name="showfont(1)" +url="showfont.1.html">. In addition, you may want to read the X Logical +Font Description document, by Jim Flowers, which is provided in the file +`<tt>xc/doc/xlfd.PS.Z</tt>'. + +The latest released version of the XFree86 documentation (including +this document and all manual pages) is available as +<url name="current XFree86 documentation" + url="http://www.xfree86.org/current/">. The <url name="comp.fonts FAQ" -url="http://www.netmeg.net/faq/computers/fonts/">, which is -unfortunately no longer being maintained, contains a wealth of -information about digital fonts. + url="http://www.netmeg.net/faq/computers/fonts/">, +which is unfortunately no longer being maintained, contains a wealth +of information about digital fonts. + +Xft and Fontconfig are described on +<url name="Keith Packard's Fontconfig site" + url="http://www.fontconfig.org">. The <url name="xfsft home page" url="http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/"> has been superseded by this document, and is now obsolete; you may -however still find some of the information it contains useful. <url -name="Joerg Pommnitz' xfsft page" -url="http://www.joerg-pommnitz.de/TrueType/xfsft.html"> is the -canonical source for the `<tt/ttmkfdir/' utility. +however still find some of the information that it contains useful. +<url name="Joerg Pommnitz' xfsft page" + url="http://www.joerg-pommnitz.de/TrueType/xfsft.html"> +is the canonical source for the `<tt/ttmkfdir/' utility, which is the +ancestor of <tt/mkfontscale/. + +<url name="The author's software pages" + url="http://www.pps.jussieu.fr/~jch/software/"> +might or might not contain related scribbles and development versions +of software. The documentation of <it/X-TrueType/ is available from <url url="http://x-tt.dsl.gr.jp/" name="the X-TrueType home page">. @@ -1110,15 +1254,14 @@ A number of East-Asian CIDFonts are available from <url name="O'Reilly's FTP site" url="ftp://ftp.oreilly.com/pub/examples/nutshell/cjkv/adobe/">. -The <url url="http://www.unicode.org" name="Unicode consortium site"> -may be of interest. But you are more likely to find what you need on +While the <url url="http://www.unicode.org" name="Unicode consortium site"> +may be of interest, you are more likely to find what you need in Markus Kuhn's <url url="http://www.cl.cam.ac.uk/~mgk25/unicode.html" name="UTF-8 and Unicode FAQ">. The IANA RFC documents, available from a number of sites throughout the world, often provide interesting information about character set -issues; my favourite is RFC 373. +issues; see for example RFC 373. </article> -<!-- Who was it who wrote the Linuxdoc DTD, and was he drunk at the - time ? --> +<!-- Who was it who designed Linuxdoc, and was he drunk at the time? --> diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/index.pre b/xc/programs/Xserver/hw/xfree86/doc/sgml/index.pre index 7dc538a9b..35b97ac29 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/index.pre +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/index.pre @@ -8,10 +8,10 @@ <!-- Title information --> <title>Documentation for XFree86™ version &relvers; <author>The XFree86 Project, Inc -<date>18 January 2002 +<date>27 February 2003 <!-- -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/index.pre,v 1.13 2002/01/15 21:24:46 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/index.pre,v 1.19 2003/02/24 03:41:25 dawes Exp $ --> <p> diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/mouse.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/mouse.sgml index f0d960394..88c647c7f 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/mouse.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/mouse.sgml @@ -5,10 +5,10 @@ <article> <title>Mouse Support in XFree86 <author>Kazutaka Yokota -<date>9 February 2000 +<date>17 December 2002 <ident> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/mouse.sgml,v 1.12 2002/02/22 21:45:13 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/mouse.sgml,v 1.13 2002/12/17 20:55:22 dawes Exp $ </ident> <toc> @@ -493,6 +493,36 @@ counts per inch, if possible: Not all mice and OSs can support this option. This option can be set in the <tt>XF86Setup</tt> program. +<sect1>Drag Lock Buttons <p> +Some people find it difficult or inconvenient to hold a trackball +button down, while at the same time moving the ball. Drag lock buttons +simulate the holding down of another button. When a drag lock button +is first pressed, its target buttons is "locked" down until the +second time the lock button is released, or until the button itself +is pressed and released. This allows the starting of a drag, the movement +of the trackball, and the ending of the drag to be separate operations. + +<verb> + Option "DragLockButtons" "W X Y Z" +</verb> + +This option consists of pairs of buttons. Each lock button number +is followed by the number of the button that it locks. In the above, +button number "W" is a drag lock button for button "X" and button number +"Y" is a drag lock button for button "Z". + +It may not be desirable to use multiple buttons as drag locks. +Instead, a "master drag lock button" may be defined. A master drag +lock button acts as a "META" key. After a master lock button is released, +the next button pressed is "locked" and not released until the +second time the real button is released. + +<verb> + Option "DragLockButtons" "M" +</verb> + +Since button "M" is unpaired it is a master drag lock button. + <sect>Mouse Gallery <p> In all of the examples below, it is assumed that <tt>/dev/mouse</tt> is @@ -571,9 +601,10 @@ mouse detection: Option "Protocol" "Auto" </verb> -<sect1>Kensington Thinking Mouse (serial, PS/2) <p> -This mouse has four buttons. -Thinking Mouse supports the PnP COM device specification. +<sect1>Kensington Thinking Mouse and Kensington Expert Mouse (serial, PS/2) <p> +These mice have four buttons. +The Kensington Expert Mouse is really a trackball. +Both Thinking mice support the PnP COM device specification. <p> To use this mouse as a serial device: <verb> @@ -1032,5 +1063,41 @@ EndSection The movement of the first wheel is mapped to the button 4 and 5. The second wheel's movement will be reported as the buttons 6 and 7. +The Kensington Expert mouse is really a trackball. It has 4 buttons +arranged in a rectangle around the ball. + +<code> +Section "InputDevice" + Identifier "DLB" + Driver "mouse" + Option "Protocol" "ThinkingMousePS/2" + Option "Buttons" "3" + Option "Emulate3Buttons" + Option "Device" "/dev/mouse" + Option "DragLockButtons" "2 1 4 3" +EndSection +</code> +In this example, button 2 is a drag lock button for button +number 1, and button 4 is a drag lock button for button 3. +Since button 2 is above button 1 and button 4 is above button 3 +in the layout of this trackball, this is reasonable. + +Because button 2 is being used as a drag lock, it can not be +used as an ordinary button. However, it can be activated by +using the "Emulate3Buttons" feature. However, some people my +be unable to press two buttons at the same time. They may +prefer the following <tt>InputDevice</tt> section which +defines button 4 as a master drag lock button, and leaves +button 2 free for ordinary use. +<code> +Section "InputDevice" + Identifier "MasterDLB" + Driver "mouse" + Option "Protocol" "ThinkingMousePS/2" + Option "Buttons" "3" + Option "Device" "/dev/mouse" + Option "DragLockButtons" "4" +EndSection +</code> </article> diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/neomagic.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/neomagic.sgml index 6d3698e4e..f7e55ddaf 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/neomagic.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/neomagic.sgml @@ -154,7 +154,7 @@ <sect> Authors <p> - Jens Owen <it>jens@precisioninsight.com</it> + Jens Owen <it>jens@tungstengraphics.com</it> Kevin E. Martin <it>kevin@precisioninsight.com</it> This driver was donated to The XFree86 Project by @@ -165,6 +165,6 @@ url="http://www.precisioninsight.com"> <verb> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/neomagic.sgml,v 1.1 1999/08/23 06:59:39 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/neomagic.sgml,v 1.2 2002/10/30 12:52:10 alanh Exp $ </verb> </article> diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/newport.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/newport.sgml index ff3ae33dc..15791c46a 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/newport.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/newport.sgml @@ -5,38 +5,37 @@ <article> <title>Information for newport Users <author>Guido Günther -<date>16 January 2002 +<date>24 February 2003 <ident> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/newport.sgml,v 1.4 2002/01/16 18:21:04 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/newport.sgml,v 1.6 2003/02/25 19:31:02 dawes Exp $ </ident> <toc> <sect>Supported Hardware <p> -This is an unaccelerated driver for the SGI Indy's newport cards. Both the - 8bit and 24bit versions are tested and working. - +This is an unaccelerated driver for the SGI newport cards (a.k.a. XL) as found +in the SGI Indy and Indigo2. Both the 8bit and 24bit versions are tested and +working. <sect>Features <p> <itemize> - <item> support for 8 and 24 bit pixel depths + <item>Support for 8 and 24 bit pixel depths + <item>Hardware cursor support to reduce flicker </itemize> <sect>Notes <p> <itemize> - <item>X -configure does not generate a XF86Config file - <item>Restoration of the console fails on some variants of the newport - (Cmap revision C) - <item>There's only a 1280x1024 mode + <item>X -configure does not generate a XF86Config file. + <item>There's only a 1280x1024 mode. </itemize> <sect>Configuration <p> The driver auto-detects all device information necessary to -initialize the card. The only lines you need in the "Device" +initialize the card on the Indy. The only lines you need in the "Device" section of your XF86Config file are: <verb> Section "Device" @@ -44,10 +43,13 @@ section of your XF86Config file are: Driver "newport" EndSection </verb> +Indigo2 users have to use the BusID option as documented below. However, if you have problems with auto-detection, you can specify: <itemize> <item>bitplanes - number of physical bitplanes (8 or 24) + <item>HWCursor - enable or disable hardware cursor + <item>BusID - set this to "1" on the Indigo2 XL </itemize> <sect>Authors diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/s3virge.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/s3virge.sgml index 671d11d9e..a85b932aa 100644 --- a/xc/programs/Xserver/hw/xfree86/doc/sgml/s3virge.sgml +++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/s3virge.sgml @@ -8,14 +8,14 @@ <date>19 Dec 2001 <ident> -$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/s3virge.sgml,v 1.5 2001/12/21 21:01:57 dawes Exp $ +$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/s3virge.sgml,v 1.6 2003/02/13 03:21:33 dawes Exp $ </ident> <toc> <sect> Supported hardware <p> -The s3virge driver in XFree86 &relvers; supports the S3 ViRGE, ViRGE DX, GX, GX2, MX, MX+, and VX chipsets. It also supports Trio3D and Trio3D/2x chips. A majority of testing is done on ViRGE DX chips, making them the most stable to date. This release has some stabilization fixes for MX, GX2 and Trio3D, and XVideo support for MX and GX2. +The s3virge driver in XFree86 &relvers; supports the S3 ViRGE, ViRGE DX, GX, GX2, MX, MX+, and VX chipsets. It also supports Trio3D and Trio3D/2x chips. A majority of testing is done on ViRGE DX chips, making them the most stable to date. This release has added support for doublescan modes on DX. This driver is moderately stable, however please use caution with any new install. Please report any problems to <email>XFree86@XFree86.org</email> @@ -28,8 +28,10 @@ using the appropriate bug report sheet. <item>Fully accelerated support for S3 ViRGE family video adapters <item>uses linear frame buffer <item>supports resolutions up to 2048x2048 -<item>supports color depths of 8, 15, 16, 24. +<item>supports color depths of 8, 15, 16 and 24 <item>full use of video card memory for acceleration caching when visible framebuffer leaves extra memory +<item>XVideo on DX, GX, GX2, MX, MX+ and Trio3D/2X at depth 16 and 24 +<item>Doublescan modes on DX, possibly others (untested) </itemize> <sect>Configuration: @@ -46,7 +48,7 @@ page. Please refer to it for additional details about XF86Config options. <sect>Support: <p> -For support with XFree86 video drivers please refer to our web site at <url name="XFree86" url="http://www.XFree86.org">. The web page has a <!-- FAQ and --> bug reporting form available. For problems not addressed in the web page please contact our support email address <email>XFree86@XFree86.org</email> +For support with XFree86 video drivers please refer to our web site at <url name="XFree86" url="http://www.XFree86.org">. For problems not addressed in the web page please contact our support email address <email>XFree86@XFree86.org</email> <sect>Authors <p> |