This document is intended to provide answers to the questions most often received by the XFree86[tm] Project's support team (which can be reached at XFree86@XFree86.org). It is also a source of information more recent than the documentation included with the latest release.
Generally, if the information is already available elsewhere, this document will supply a pointer to the information rather than duplicate it. If you don't have access to the World Wide Web, see the section below entitled "Access via Email".
The XFree86 Project is making the information in this document available free of charge in the hope that it will be of use. However, the authors specifically disclaim any liability for any direct, indirect, or consequential damages arising out of its use.
This document is intended to be a source of up-to-date info regarding XFree86, and as such, may change frequently. Make sure you consult a recent copy, before relying on any information contained herein.
Additionally, this FAQ generally assumes that you are using the latest release and, unless otherwise specified, the information contained herein is likely to not be applicable to other releases. If you are having problems and are not running the latest release, then upgrading is often the answer to your problems. Really. If you have a fairly new card, it is especially important to make sure you are using the latest server release.
The latest version of this document is always available from the XFree86 Web site (http://www.XFree86.org/) or one of its mirrors:
Last modified: Fri Nov 13 01:34:36 PST 1998
vgaset?
XFree86 is a trademark of The XFree86 Project, Inc., a non-profit organization that provides X Window System servers (as well as some supporting materials) for several operating systems on PCs and other microcomputers. The X servers, client programs, documentation, etc. supplied by the XFree86 Project, Inc., are collectively, also known as XFree86. All programs are provided with source code, free of charge.
The XFree86 Project, Inc. is currently funded entirely by donations. If you're interested in making a monetary or equipment donation, see http://www.XFree86.org/donations.html or send Email to BOD@XFree86.org.
A list of current sponsors is available at http://www.XFree86.org/sponsors.html
For more information regarding The XFree86 Project, Inc., see http://www.XFree86.org/corp_profile.html
The latest full release is XFree86 version 3.3.2. It is based on X11R6.3pl2 and was released in March 1998. A patch release, known as 3.3.2.3, was made in July to update some portions of the release. See the Release Notes for more info.
The newest available version of SuperProbe is 2.16. It is included with the latest XFree86 release.
Both SuperProbe and the servers print the version when they start. However, depending on how the server is started, its output may not normally be visible.
The server will display its version number, if you simply type X -showconfig at a shell prompt (even if you haven't configured it for your card and monitor yet).
The primary site for both SuperProbe and the XFree86 servers and clients is ftp.XFree86.org.
A list of mirror sites is available at: http://www.XFree86.org/3.3.2/ftp.html
Please read the README (or RELNOTES) file, in the directory corresponding to your OS, on the XFree86 ftp site or one of its mirrors (see the previous question). It contains a list of the filenames along with their contents. It also lists which files are required and which are optional.
The latest documentation can be found on http://www.XFree86.org/3.3.2/. Many of the XFree86 specific man pages are also available at http://www.XFree86.org/man/. The documentation is also available, in ASCII form, from ftp://ftp.XFree86.org/pub/XFree86/3.3.2/doc/.
The 4.0 release, with significant changes, is being worked on. It is not known at this point when it will be released. A 3.3.3 release, with drivers for new hardware should be released this quarter.
We don't recommend any particular board or manufacturer (although it would be good to support our sponsors, see http://www.XFree86.org/sponsors.html). In general, the S3 based boards have been the best supported, followed by the ATI based cards, however that is no guarantee that any specific board will work. It is probably best to look through the various "README" files at http://www.XFree86.org/3.3.2/ to see which boards are currently supported and pick one of them.
It is also a good idea to buy from some place that has a liberal return policy or will let you try before you buy. Especially since some manufacturers will sometimes change what RAMDAC or other chips are used on a board without changing the name of the board.
We don't know. Benchmarks are just that. Useless numbers trying to capture something that is far too complex to be captured in a number. We may ocasionally comment on the relative speed of different cards, but that is usually the personal opinion of the one who writes the note. In general, The XFree86 Project is not publishing benchmark comparisons, because even if you think that a number like 'xstones' can capture the performance of a card, it is incredibly hard to create fair and comparable numbers.
Yes, the latest release is available for OS/2. This port runs in parallel to the Presentation Manager desktop, similarly to a WinOS/2 fullscreen session (there is no equivalent to a seamless WinOS/2 configuration). See http://borneo.gmd.de/~veit/os2/xf86os2.html for more information.
No work is being done to create a free port of XFree86 to any version of DOS or Windows. If you need to run X on such a platform you'll need to use one of the available commercial servers.
One of the commercial products, X Appeal, is from an XFree86 sponsor and is a port of the XFree86 servers to MS-DOS. They also have a freely available demo version.
A freely available X server for MS-Windows is available from http://tnt.microimages.com/ There is no connection between MicroImages and XFree86; do not send questions regarding their server to us.
X11R6.3 does include some support for MicroSoft Windows NT. However, it is only for building the libraries and some client programs. If you want an X server, you'll have to buy one or use the one mentioned in the previous question.
Although it is technically possible to use multiple PCI-based SVGA cards in the same machine, none of the servers currently support this.
The VGA16 and Mono servers are both capable of running both a VGA compatible card and a non-VGA compatible monochrome card in the same machine.
For XFree86-4.0 we are working on true multi head support.
Some X servers offer multiple visuals as overlays (e.g., 8bpp PseudoColor and 24bpp TrueColor). At this point XFree86 doesn't support Overlays, but we are working on this feature for XFree86-4.0.
Use the bug report form on our WWW server (http://www.XFree86.org/), or send email to XFree86@XFree86.org. Before sending a bug report, make sure you are using the current release of XFree86. In the bug report, include the full server output, details of the XFree86 version, server, description of the problem, and some way of repeating it and most importantly, the full server startup output. Oh, and you'll greatly increase your chances of getting a useful repsonse from us, if you include the full output of the server.
The Board of Directors of the XFree86 Project, Inc. has released a
statement regarding this. The full text is available from:
http://www.XFree86.org/news/pr-980407.html
In addition to being available from the XFree86 web site (as http://www.XFree86.org/FAQ/), this FAQ will be posted at least monthly to comp.windows.x.i386unix, comp.os.linux.x, comp.answers, and news.answers.
It is also available from the XFree86 FTP site (and mirrors) as ftp://ftp.XFree86.org/pub/XFree86/WWW/htdocs/FAQ/index.html - HTML version and ftp://ftp.XFree86.org/pub/XFree86/WWW/htdocs/FAQ/faq.txt - ASCII text version.
This document is maintained by Joe Moss (joe@XFree86.Org) with contributions from other members of the XFree86 support and development teams. Particular thanks go to David Dawes, Dirk Hohndel, and Koen Gadeyne for their contributions.
If you have questions or comments regarding XFree86 do not send them directly to me. They should be Emailed to XFree86@XFree86.org (which will cause a copy to be sent to me, as well as the rest of the XFree86 support team). If you have comments regarding this document itself, then you may send them to me. In particular, if you find incorrect or non-functional URLs or any typos herein, please let me know.
If you only have Email access to the net, you should get a copy of the Accessing the Internet by E-Mail FAQ.
If you're in North or South America, send a message to mail-server@rtfm.mit.edu containing only the line:
send usenet/news.answers/internet-services/access-via-email
in the body of the message.
Elsewhere in the world, send mail to mailbase@mailbase.ac.uk with only this line in the message body:
send lis-iis e-access-inet.txt
This document explains how to retrieve stuff from the WWW, Usenet News, etc. via Email. It also explains how to use ftpmail, which you can use to get the latest version of XFree86.
Many of our sponsors supply hardware, software, and services which may be of interest to users of XFree86 servers. The list of our sponsors (http:/www.XFree86.org/sponsors.html), points to the web sites of many of them.
Here are some pointers to other documentation, regarding subjects related to XFree86, that might be useful to readers of this document. These are not published by the XFree86 Project, Inc. and are included here only for reference. Questions or comments regarding any of these items should be directed to their respective authors.
There is a no such thing as THE config file for
a particular card or monitor. The XF86Config file
you should use is dependent on your card, monitor, operating system,
mouse, keyboard, individual preferences, network setup, available
fonts, etc.
It is not a good idea to exchange XF86Config files. While it may be safe to use certain parts of another's config file, in general, you are better off generating your own.
All of the configuration information we have, is included with the release. You should use one of the included configuration programs, XF86Setup or xf86config. This is explained in the QuickStart Guide.
For further information, you could also read the XFree86 configuration guide (available from http://www.XFree86.org/3.3.2/Config.html), and the manual pages XF86Config(4/5) and xvidtune(1).
Try looking for information on your monitor's capabilities on one of the following Internet sites:
vgaset?Simple. Don't use it!
The xvidtune program, that
is part of the 3.3.2 release, has more capabilities and works properly
with the server extension (XFree86-VidModeExtension)
included in the 3.3.2 servers.
Each release includes the most up-to-date list at the time of release.
If there are any updates after a release, they will be made available as:
ftp://ftp.XFree86.org/pub/XFree86/current/doc/Cards
(if the file is non-existent, i.e. this URL does not work, then
there have not been any updates to the Cards database since the
last release).
It should be installed in /usr/X11R6/lib/X11/Cards.
If you still can't find your card listed, you should check if there is a generic entry for cards using the same chipset as yours. If not, see the Chipset Support section of this document to check on the current status of drivers being written and what you can do if your card is unsupported.
If after all of the above, you still are not sure what to do about configuring your card, you can contact us about it.
This usually is due to incorrect parameters in the Monitor section of the XF86Config file.
If you install XFree86 using the description in the RELNOTES file, you may see an error message from preinst.sh like this:
: command not found
or
var/tnp/preinst.sh systax error near unexpected token 'in
or a number of other strange errors.
In all cases, these could be traced back to downloading this file using a MSWindows-based download program (MS Internet Explorer or any other Windows FTP client).
These programs try to convert this script file to MSDOS text, which breaks it completely. In most FTP clients you can force the program to download in "image" or "binary" mode, which would solve this. Some internet browsers don't allow this, so they can't be used for this.
The best solution is to use a UNIX Internet browser or FTP client: they do the right thing.
If the cursor appears to be horizontally offset by several pixels, it is probably due to the same problems that cause the display to be wrapped around. See item D1 below.
If you are experiencing problems with menus not allowing you to select items, try turning NumLock off.
In X11R6 (and newer), the NumLock key is a modifier. Many clients (X programs) haven't yet been updated to the R6 way of doing things. They need to ignore modifiers when looking for button click/release events.
See the answer to the previous question. You can also upgrade to Tk 4.x which ignores modifiers by default.
The 3.3.2 release is based on X11R6.3 which includes the XKB extension and has it enabled by default. This may cause the mappings of some keys on some keyboards to be different than they were in previous releases.
See the XF86Config man page and the sample XF86Config file for some information on setting the key mappings to your liking.
Alternatively, you can disable the XKB extensions by starting the server with the -kb option or by adding the keyword XkbDisable to your XF86Config file.
Most likely, you've specified the wrong protocol for the mouse. Note that newer Logitech mice do not use the Logitech protocol, but instead use Microsoft (or MouseMan) protocol.
Under Linux, the solution is to get gpm-1.13, run as gpm -t pnp -R, and configure XFree86 for MouseSystems Protocol with /dev/gpmdata as the device.
Run xmodmap -e "pointer = 3 2 1" in an xterm or
put such a command into your .xinitrc file.
See also the xmodmap(1) man page.
For Diamond Stealth Video VRAM: if the server is not recognizing
your card as a Diamond card, add this line to your XF86Config:
Option "Diamond"
If the above does not work or you don't have a Diamond card, try running the xvidtune program and adjusting various settings. In particular, if you have a recent S3 based card, adjust the extra S3-specific settings at the bottom.
Two things influence the virtual desktop size:
Section "Screen"
...
Subsection "Display"
Depth 8
Modes "1024x768" "800x600" "640x480"
# Virtual 1280 1024
ViewPort 0 0
EndSubsection
...
Section "Screen"
...
Subsection "Display"
Depth 8
Modes "1024x768" "800x600" "640x480"
ViewPort 0 0
EndSubsection
...
This will set the virtual screen to 1024x768 in 8bpp mode. If you only want 800x600, remove the "1024x768" Mode from the list above.
In some installations, the first mode in the "Modes" line is the smallest one, as shown below:
...
Modes "640x480" "800x600" "1024x768"
...
In this case, the server will still select 1024x768 as virtual size (the largest mode in the list), but start up with 640x480 (the first mode in the list). This will put you in a "scrolling" mode again. If you want 640x480 without scrolling, remove all the larger modes. If you want the bigger display without the scrolling, use "CTRL ALT +" or "CTRL ALT -" to switch to the larger modes, or re-order the "Modes" line so that the server starts up in the mode you want.
Note that there is such a "Display" Subsection for every color depth, so you may have to repeat the same editing steps several times.
In standard X11R6 (and later), in addition to the fonts in "scalable" formats (i.e. Type1, Speedo), bitmap fonts are scaled. This can have the undesirable effect of scaling a bitmap font, even though a Type1 font is available (if the bitmap font is listed first in the path).
With the 3.2 and later releases of XFree86, you can add the text
:unscaled to the end of any directory in the font path
to turn off scaling of the bitmap fonts in that directory.
This works in both the XF86Config file and the font server's config
file.
While scaling fonts, the server can hang temporarily. If you are requesting a particularly large font, the period during which the server is unresponsive, can be quite noticeable. Font scaling uses floating point math and the effect is particularly obvious, if you do not have a floating point coprocessor (getting one would help immensely).
This problem can be avoided by running the font server (xfs) and indicating in your XF86Config file that the X server should request fonts from the font server. This workaround prevents the X server from temporarily freezing, but doesn't really speed up the time necessary to scale the fonts (so the application requesting the font will still have to wait).
This is most often caused by problems with directly accessing the linear frame-buffer (this often happens with IBM ValuePoint systems, in particular). Try adding Option "nolinear" to the Device section of your XF86Config. If it still occurs, try Option "nomemaccess".
Lockups can also happen, with any server, if the system bus is overclocked. Try some more conservative BIOS settings.
Try adding
Option "xaa_no_color_exp"to your XF86Config file (in the Device section).
No, this message is only a warning and can safely be ignored - assuming it is the only error message.
There is a problem with the /dev/console device file. As root, you can run these commands to fix it:
cd /dev; ./MAKEDEV console
As explained in the XFree86(1) man page, the -bpp option can be specified on the command line when starting the server. You can specify 15 bpp, for 32768 colors, 16 bpp, for 65536 colors, or either 24 or 32 bpp, for 16.7 million colors.
However, the server is rarely started directly. The two most common ways to start the server are with startx and xdm. For example, to start the server in 16 bpp mode from the command line:
startx -- -bpp 16
or to start the server from xdm in 32bpp mode, you would put a line
like the following in the Xservers file
(in the xdm library directory, typically /usr/X11R6/lib/X11/xdm):
:0 local /usr/X11R6/bin/X -bpp 32
All of the above is dependent on the server having support for your card at higher than 8 bpp.
Make sure you don't have a TV cable connected to your card. The Mach64 server doesn't work properly when that cable is connected.
First, you need to get the XFree86 3.3.2 Mach64 server if you don't already have it. It should automatically detect the ATI chips available up to the time of its release (August 1997). There are some cards which don't work correctly with the current version of XFree86. We don't have a solution to that problem at this time.
The most common reason for this is that you have installed the Linux-ix86-glibc binaries when you don't have GNU libc 2 (aka libc 6). The solution is to install the Linux-ix86 binaries, which are the correct ones for most situations.
If your installation of XFree86 3.3/3.3.2 is not complete you may see the following error message when starting an X server:
error opening security policy file /usr/X11R6/lib/X11/xserver/SecurityPolicy
This is a only a warning message, and is mostly harmless. If your server
is failing to startup, this is not the reason. Check the other messages.
The file being referred to is included in the X33lib.tgz (or X332lib.tgz
for XFree86 3.3.2) part of the
XFree86 binary distributions produced by The XFree86 Project. It seems that
some other binary distributions of XFree86 3.3 may be missing this file.
If that is the case, please contact the originators of those distributions
about it.
The X window system is not subject to year2000 problems. Neither is XFree86. See the y2k statement from The Open Group for reference.
Whenever the XFree86 Xserver crashes, dies, ceases to exist or is inaccessible for any reason, you will see this error message. It is a message from an X-client (=any program running on your XFree86 Xserver, for example the window manager) telling you that it tried to connect to your Xserver, but failed to do some for "some" reason.
Quoting only this message in a bug report is therefore utterly useless. Look in the server output for the real reason why the server died. Normally you should see the real error message (=why the server stopped working) a few lines before the "error 111" message.
If you still can't make head or tails of all those messages, make sure to quote the FULL server output in your bug report. It is impossible to provide you with any help, if you just mention the "error 111", as so many people do.
Obtaining the full server output is normally accomplished by redirecting both standard output and standard error to a file while starting the server. On some systems this is done by default.
The XFree86 X servers require root privileges to access the video hardware. In releases prior to 3.3.2 the X servers were installed set-uid root so that normal users could run them with the required privileges. This is a potential security problem, especially given how large and complex the X servers are. One class of such security problems is exploiting the set-uid program with carefully crafted user-supplied data (either on the command line or in the environment). Starting with the 3.3.2 release the XFree86 X servers are installed without the set-uid bit set, and a small wrapper program ``Xwrapper'' which is installed set-uid root is used to start the X server after checking the command line and environment. This does not provide a 100% guarantee that the X servers are not vulnerable to such exploits, but it does reduce the chances of such exploits succeeding. Also, if vulnerabilities are found in the future that the current Xwrapper doesn't catch, we can easily supply an updated version. It is much easier to do that than to provide updated versions of all the X server binaries.
The xinit command (which startx runs) provided with XFree86 3.3.2 and later has been modified to look for an X server called ``Xwrapper'' instead of ``X''. If you don't have Xwrapper installed, you will get an error message from xinit/startx when it tries to start the non-set-uid X server without using the wrapper. The same thing will happen if you do have Xwrapper installed but you have an xserverrc file (usually $HOME/.xserverrc, but it can be any file pointed to by your XSERVERRC environment variable) that references ``X'' instead of ``Xwrapper''. To fix that, edit your xserverrc file and replace ``X'' with ``Xwrapper''. If instead of X you have some other X server name (eg, XF86_SVGA) in your xserverrc file, you will need to create a symbolic link from it to /usr/X11R6/bin/X and replace it with ``Xwrapper'' in your xserverrc file.
We strongly recommend against making the X servers set-uid root because of the potential security implications of doing so. We also recommend running xdm at boot time to handle starting the X server on a multi user system.
Computers using LC displays are more tricky to set up in XFree86 than the ones with a normal (CRT) monitor. This is mainly due to the displays themselves: LCDs basically have a fixed resolution, although some have extra hardware built in that can cope with several different resolutions.
Especially the modelines can be extremely tricky, and each new LCD seems to need its own modeline. Refer to the Linux-laptop homepage for more information and specific help for most common LCD-based computers:
http://www.cs.utexas.edu/users/kharker/linux-laptop
or one of the mirror sites, e.g.
http://physics.open.ac.uk/~rpblake/linux_laptop
Although this page is Linux-oriented, the information on using XFree86 (especially the XF86Config files) is mostly OS-independent.
While XFree86 does not, at the time of writing, natively support TrueType fonts, there is a number of third party solutions. Some information about these options is included below. The XFree86 project is not responsible for any of these; please send any inquiries about them to relevant newsgroups or, eventually, to their authors.
XFree86 is planning to include native support for TrueType fonts in its next major release.
The FreeType library includes in it's `contrib' directory the `ttf2bdf' utility, by Mark Leisher, which can be used to generate bitmap versions of TrueType fonts at any size, resolution, and with any encoding. The generated bitmaps can be used by any X server that supports the BDF format (including XFree86), or converted to PCF.
The FreeType library is available from http://www.freetype.org.
Xfsft, by Mark Leisher and Juliusz Chroboczek, is a font backend based on the FreeType library (see above). Xfsft can be used as a standalone font server, or linked into the X server. Xfsft will automatically reencode fonts to a number of encodings, and new encodings can be provided by the user.
At the time of writing, Xfsft does not delay rasterisation; this makes it unsuitable for fonts with a very large number of glyphs (such as fonts for ideographic scripts).
More information of Xfsft can be found on http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/.
Xfsft (sources, binaries for Linux/Intel/libc5 and Solaris 2.6/Sparc) can be found on Sunsite at UNC ftp://sunsite.unc.edu/pub/Linux/X11/fonts/.
Additionally, you may want to check the additional Linux/Intel/libc6 binaries (including binaries of X servers) provided by Joerg Pomnitz, as well as his supporting utilities (which includes a tool that creates fonts.dir files for directories containing TrueType fonts):
http://www.darmstadt.gmd.de/~pommnitz/
and
http://www.darmstadt.gmd.de/~pommnitz/XF86-xfsft/index.html,
and the FreeBSD/Intel binaries provided by Stephen Montgomery-Smith:
http://math.missouri.edu/~stephen/software/.
When downloading, please note that you will need the source tarball, which contains installation and usage instructions.
X-TrueType, by T. Shiozaki et al., is another backend based on FreeType. It can be run as a standalone font server or linked into the X server. It is, at the time of writing, the only backend that provides delayed rasterisation of glyphs; this makes it particularly suitable for use with ideographic scripts. It will reencode fonts to a fixed, albeit large, set of encodings (new encodings cannot easily be added by the user).
More information on X-TrueType may be found on: http://hawk.ise.chuo-u.ac.jp/student/person/tshiozak/X-TT/index-eng.html.
FreeBSD users will be interested to know that X-TrueType is part of the `ports' collection.
Xfstt, by Herbert Duerr, is a standalone font server with support for TrueType fonts that is not based either on the FreeType library nor on the X11 Sample Implementation code. It is written in C++, but notwithstanding this is more lightweight and easier to compile than the alternatives. It is also very easy to use.
Xfstt reencodes fonts to a fixed set of encodings. It does not delay rasterisation.
Please note that Xfstt only supports one connection at a time, and needs to be recompiled in order to serve a machine with a different byte order.
Some versions of Xfstt under some platforms are rumored to have memory leaks. It is not known whether these rumours are rooted in reality.
Xfstt can be found all over the world, including packages for various common operating systems. This includes Sunsite at UNC: ftp://sunsite.unc.edu/pub/Linux/X11/fonts/.
The chipsets supported by XFree86 3.3.2 are listed in the README file. The list is available via the WWW at: http://www.XFree86.org/3.3.2/README3.html
This section contains some notes regarding various chips for which support is not included in the current servers and other chipset/card specific notes.
If you have a card which is not currently supported, you have these options:
Check this FAQ periodically. When there is a change in the status of a driver that is under development, this FAQ will be updated to reflect the change.
If you are using a card that uses a programmable clock chip which is not supported by the server, you may be able to get a separate program to program the chip for useful clock frequencies.
Sometimes, others make clock programming programs available on the net that can be called by the server. Also, you may be able to use a video card's driver made for MS-Windows or OS/2 to program the clocks and then warm boot the machine and run XFree86.
You should probably use a monitor that is smart enough to reject frequencies that are beyond its specs, if you plan to try something like this.
The XFree86 Project does NOT make any pre-release source code available to anyone except members of the development team. Nor are binaries generally available.
If you have access to some currently unsupported hardware, are willing to actively participate in testing and perhaps debugging a server, and would like to join the development team, then send an email message to XFree86@XFree86.org listing your available hardware and software, as well as any relevant skills you may have.
Often, when there is code being developed for a previously unsupported chipset, a "Call for Beta Testers" will be issued (via a posting to relevant Usenet groups).
The 3.3.2 release includes a driver for the Matrox Millennium, Millennium II, and Mystique cards.
An initial release of a server supporting this chipset is available as XFCom_P9x00 from S.u.S.E.'s X server page for download. Be sure to read the accompanying README.XFCom_P9x00 and use the modified xf86config program for configuration.
An accelerated driver for these chips (used on the Diamond EDGE 3D 2000 & 3000 Series) is included in the 3.3.2 release.
The latest release includes some support for the ProMotion 6422, AT24, AT25 and AT3D.
There is a driver for these chips in the current SVGA server, however it has been reported not to work correctly on all systems. A possible work-around is to treat it as another chip (such as "clgd5428", for a CL-GD7543, or "clgd5436", for a CL-GD7548), using a Chipset line, in which case should probably also disable acceleration (Option "noaccel"). Also, some people have reported success after modifying the 800x600 modeline to use a lower dot clock, or by decreasing some of the horizontal timing parameters.
Boards based on NeoMagic chips are not supported in XFree86, as programming documentation is not available. For users of Linux based machines, Red Hat has made a binary only server XBF_NeoMagic available at their ftp server. Check their ftp server for details.
The source code to this server has been donated to XFree86 and will be included in the next release.
Boards based on this chip (such as the STB Horizon 64) are not supported.
The ViRGE chips are supported in 3.3.2.
Support for cards based on these S3 chipsets is in the current release.
Cards based on the Mach64 original Rage II and the newer Rage II+ chipsets are supported by the current release. Some versions of the cards don't appear to work correctly with the Mach64 server though, and we don't yet have a solution to that problem.
If you needed to add ChipId/ChipRev lines to your XF86Config file when using XFree86 3.3, they can and should be removed when upgrading to XFree86 3.3.2.
Cards based on the Mach64 Rage IIC chipset are supported by the Mach64 server with the option
ChipId 0x4755
in the Section "Device" of the XF86Config file.
Cards based on the Mach64 Rage IILT chipset are supported by the Mach64 server with the option
ChipId 0x4755
in the Section "Device" of the XF86Config file.
The ATI Mach64 VT3 chips are correctly detected by the current Mach64 server. If you needed to add ChipId/ChipRev lines to your XF86Config file when using XFree86 3.3, they can and should be removed when upgrading to XFree86 3.3.2.
The current version of the server needs to map the video memory aperture into the system's address space. Since this requires 4MB of address space and since ISA bus systems can only address a maximum of 16MB, the Mach64 server can not be used on systems with more that 12MB of RAM. See the Mach64 README files for more information regarding the current capabilities of the server.
Until full support for ISA Mach64 cards is added to the Mach64 server (if it ever is), the SVGA server can be used instead.
The S3 server does not work with 911 and 924 cards that only have .5MB of RAM on the video card. Upgrade the card to 1MB.
S.u.S.E. GmbH is making a small family of servers available as binary-only releases for Linux. These include XFCom_3DLabs which is a fully accelerated 2D server for Elsa GLoria-L, GLoria-L/MX, GLoria-S, GLoria Synergy and Winner 2000/Office. Other, similar cards like Diamond Fire GL 1000, GL 1000 PRO and GL 3000, as well as many other Permedia 2 based cards are known to work as well. For more information check the XSuSE page. The sources for this server have been donated back to XFree86 and will be part of a future XFree86 release. Support for the Permedia 2v has recently been added.
The Riva 128 server does not work if the Riva card shares an interrupt with another device in your system. To solve a conflict like that, either change the IRQ settings in the PCI BIOS or try putting the PCI cards in different PCI slots. This is true regardless whether the Riva 128 card is a PCI or an AGP card.
In March 1998 XFree86 finally received some documentation on Rendition's chipsets. We are evaluating the documentation and will be working on a Rendition server.
An early release of this server is now available as XFCom_Rendition at S.u.S.E.'s X server page for download. This server is not yet accelerated, but should work on all Rendition Verite V1000, V2100 and V2200 cards.
XFCom_Cyrix is among the servers that S.u.S.E. GmbH is making available. It is a non-accelerated server for the Cyrix MediaGX CPU. You can find it at the XSuSE page.
XFCom_SiS is among the servers that S.u.S.E. GmbH is making available. It is a server for SiS chipsets including 5597 and 5598. You can find it at the XSuSE page.
At this point some AGP cards are known to work. These include the Riva 128 AGP, the Matrox Millennium II AGP, ATI Rage II AGP cards and others. If you are running into problems with the AGP version of a supported card, please report the problem.
All of the essential functions that would be needed to support an X server can only be used while in the processor's real-mode. In other words, VESA compliance is of no use when using a protected-mode operating system.
Boards based on Intel i740 chips are not supported in XFree86, as programming documentation is not available. For users of Linux based machines, Red Hat has made a binary only server XBF_NeoMagic available at their ftp server. Check their ftp server for details.
No. XFree86 has no chipset documentation for this chipset. No one has stepped up to try and develop such a driver, to begin with. There is no projected timeframe for such a driver, but since development hasn't started yet, it will be a long time before this changes.
We have received the documentation in late August. There is a preliminary server available from the XSuSE page. This server should work on all current G100 and G200 cards. It is known to sometimes misdetect the amount of memory installed, so if you run into problems, check if the reported amount of memory is correct and add the option VideoRam to the Device Section of the XF86Config file if it is not.
The latest version of XFree86 doesn't explicitly support these cards (they're too new), but some users have reported that overriding the memory detection by adding VideoRam 8192 to the Device Section of the XF86Config helps for the ZX cards. (the example is for 8 MB of video memory, other amounts will need different numbers of course).
For the TNT, you'll need a special server from nVidia at http://www.dimension128.smartcom.net XFree86 3.3.3 will support both chips.
Boards based on those two S3 chips are not supported in XFree86. XFree86 has only recently (November 98) received the documentation for these chips, so development is underway. This will take some time. This FAQ will be updated as soon as a server is available.
Boards based on this Voodoo Banshee are not supported in XFree86, as programming documentation is not available. We are working with 3dfx on a solution to solve this problem but haven't been successful, yet.
This section includes a list of problems found since the release of XFree86 3.3. Many of these have been fixed in XFree86 3.3.2.
There is a bug in the I128 server which causes the cursor to be drawn incorrectly. The server binaries for most OSs were updated a couple of weeks after the initial release, so if you have the recent binaries you should no longer see this problem. This problem is fixed in XFree86 3.3.2.
The I128 server has problems with cards using revision 2 of the I128 Series II chip (the screen goes black). Earlier revisions of the Series II don't have this problem. This problem is fixed in XFree86 3.3.2.
The Mach64 server does not automatically detect the newer ATI Rage II+ and Rage Pro chips. See item F14 for a workaround for the Rage II+ and Rage Pro. See item F17 for a workaround for the VT3. This problem is fixed in XFree86 3.3.2.
The ATI driver in the 3.3.2 SVGA server will not work with the ATI Rage IIc, LT Pro or VT4 chips. These should be supported in 3.3.3.
The Cirrus driver selects the wrong clock limit for later revisions of the Cirrus 5434 chip. This problem is fixed in XFree86 3.3.2.
If the server's startup messages have lines like:
(--) S3: There is no defined dot-clock matching mode "800x600"
(--) S3: Removing mode "800x600" from list of valid modes.
check if you have a `Ramdac' line in the Device section of your XF86Config
file. If so, removing that line should fix the problem. This problem is
fixed in XFree86 3.3.2.
Some people have reported a problem with the Millennium driver that causes some screen instability when the cursor shape changes. A possible (not yet confirmed) workaround for this is to disable the HW cursor by adding the following line to the Device section in the XF86Config file:
Option "sw_cursor"
In XFree86 3.3.1 the HW cursor is disabled by default. In 3.3.2 it is
re-enabled by default, because some of the problems were fixed.
The Millennium driver will lock up the whole machine at startup on most SVR4.0 OSs. This problem is fixed in XFree86 3.3.2.
The Millennium II is known to occasionally lock up the system when the server tries to proble the amount of memory installed. The best solution is to hard-code the amount of memory into the XF86Config file with the VideoRam option in the Device Section.
We've had some reports of the Mystique driver locking up for no obvious reason. The cause of this has not been identified, and no workaround is known.
There are some problems with the TGUI acceleration code on 9680 and 9685 chips. A possible workaround is to disable acceleration by adding the following line to the Device section in the XF86Config file:
Option "noaccel"
This problem is fixed in XFree86 3.3.2.
The SVGA server does not detect the new 65555 chip. It should be compatible with the 65554, and the server should work if the following line is added to the Device section of the XF86Config file:
chipset "ct65554"
This problem is fixed in XFree86 3.3.2.
Some servers/drivers will crash with a SEGV at startup on Solaris x86. This is known to happen with the MGA driver (Millennium and Mystique). This problem is fixed in XFree86 3.3.2.
The Linux xterm may exit with the following error message if you don't have a /etc/termcap file:
xterm: unable to find usable termcap entry.
A workaround is to copy /usr/X11R6/lib/X11/etc/xterm.termcap to /etc/termcap.
Before doing this, first make sure that there really is no
/etc/termcap file.
This problem is fixed in XFree86 3.3.2.
The xterm termcap entry has an incorrect entry for `op', which is what disables colour mode. The result is that the background colour gets set to black when this entry is used. This problem is fixed in XFree86 3.3.2.
The terminfo entry does not have this problem.
These problems can usually be fixed by adding the Option "xaa_no_color_exp" to the Device Section in the XF86Config file.
This is a known problem, but there's a workaround. If you explicitly set the chipset to cyber9382, the cyber_shadow option works again.
This is a bug in the 3.3.2 XF86_SVGA server code affecting all ET4000W32p cards with RAMDACs that support pixel multiplexing. All W32p cards that allow 1280x1024 modes with pixel clocks up to 135 MHz fall in this category.
The server should be refusing all modelines that use pixel clocks above 135 MHz, but it doesn't.
A simple workaround is to remove all the modelines from your XF86Config file that use a pixel clock above 135 Mhz (=the first number in the modeline, just after the mode name).
You need to upgrade to XFree86 3.3.2.3. Any older version does not support the GX2. Make sure you use the SVGA server (XF86_SVGA), and not the S3V server (XF86_S3V). On RedHat Linux systems, the RedHat "Xconfigurator" tool incorrectly selects the S3V server for this card.
Send comments regarding this page to Joe Moss (jmoss@ichips.intel.com)