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: Wed Oct 20 23:00:24 PDT 1999
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.5. It is based on X11R6.3pl2 and was released in August 1999. See the Release Notes for more info.
The newest available version of SuperProbe is 2.20. 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.5/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.5/. 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.5/doc/.
If you need XFree86 binaries in RPM format (or any other vendor-specific package format) you will need to contact your OS vendor. The XFree86 Project only supplies binaries in the vendor-independent ".tgz" (gzipped tar) format (and ".zip" for OS/2).
The 4.0 release, with significant changes, is being worked on. It is not known at this point when it will be released. Work-in-progress snapshots of this release are being made available from http://www.XFree86.org/snapshots/
XFree86-3.3.6 is planned for the fourth quarter 1999.
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.5/ 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 occasionally 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.
There is some work being done to create a free port of XFree86 to Microsoft Windows. However, in the mean time, 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.
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, for now, you'll have to buy one. See 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 response from us, if you include the full output of the server.
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 volunteer 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.5/Config.html), and the manual pages XF86Config(4/5) and xvidtune(1).
A list of video cards and the X servers they require can be found at http://www.xfree86.org/cardlist.html. If you don't find an entry for your card or chipset in that list, check the Chipset Support section below to see if it is mentioned there.
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.5 release, has more capabilities and works properly
with the server extension (XFree86-VidModeExtension)
included in the 3.3.5 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.5 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.
This should not be a problem with XFree86 3.3.2 and later.
For earlier versions running under Linux, the solution is to get gpm-1.13 (or later), run it 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.
This is a long-standing problem with all those client programs. It is NOT a problem in XFree86.
Technical details: it is caused by a relatively new feature of XFree86 (24bpp modes with 24bpp pixmaps) that is very poorly understood by many client authors: they assume 32bpp pixmaps instead of asking the XFree86 server for those details. Others (like Netscape) do ask for the pixmap size, but since they don't support 24bpp pixmaps, they fall back to using 1bpp (monochrome) pixmaps...
The current public versions of XFree86 can only support a 1:1 mapping between the framebuffer depth and the pixmap depth. Some commercial Xservers support 32bpp pixmaps in 24bpp modes, and hence they present an interface to client programs that happens to match their assumptions. XFree86 4.0 will also support this feature.
There are two possible solutions to this right now:
If you have a card with 8MB of video memory, first try telling the X server that there is only 4MB present by adding the following line to the Device section of your config file:
Videoram 4096If you have a 4MB card, or if the above line doesn't help, try adding the following line to the Device section:
Option "nolinear"A drawback with this option is that colour depths higher than 8bpp can't be used, but that is better than nothing.
If you see problems when moving windows with KDE, try the following:
Option "no_pixmap_cache"These problems should be fixed in the next release.
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.
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.3 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 Xlib.tgz
part of the
XFree86 binary distributions produced by The XFree86 Project.
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 something 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 (eg, startx <& logfile.txt). 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 NetBSD `wscons' code had a bug where text would still be output to a virtual terminal even if the VT was in graphics/X mode. Try leaving a VT free (that is, not running a getty) for your X server, which should help by allowing the X server to use a VT that nothing else is using.
The X server tends to be a critical process for the smooth operation of a workstation, and as such has a good reason to operate at elevated priority (negative nice value).
Running with the X server at a priority around -10 (on Linux) improves overall system responsiveness vastly. This can be accomplished using the "nice" command.
notes:
The chipsets supported by XFree86 3.3.5 are listed in the README file. The list is available via the WWW at: http://www.XFree86.org/3.3.5/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.5 release includes a driver for the Matrox Millennium, Millennium II, Mystique, Millennium G200, Mytique G200 and Productiva G100 cards. This driver is part of the XF86_SVGA server. Do not attempt to use the XF98_MGA server unless you really do have one of the Japanese PC98 architecture computers. If you want to know why, see the PC98 question.
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 this chip (such as the STB Horizon 64) are not supported.
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.
An accelerated server supporting these chips is available as part of XFree86-3.3.5. The bug in XFree86-3.3.3 that made your clock run slower after using this server has been fixed. Note: it is necessary to reboot between running the buggy version and the fixed version so that the OS can reinitialise the timers.
An initial server supporting the V1000 and V2x00 chipsets is available as part of XFree86-3.3.3. Work on acceleration is slowly making progress, but not finished, yet.
At this point most AGP cards with supported chipsets are known to work.
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.
Of course, the operating system itself can use the VESA BIOS while booting before it switches into protected mode. This is what is done with vesafb in recent Linux kernels. See below for details.
Boards based on Intel i740 chips are now supported in XFree86 release 3.3.5.
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.
XFree86-3.3.5 supports all these chipsets as part of the SVGA server. Please note that S3 Savage3D support was not tested and Savage4 support is currently restricted to Linux and the Intel Platform.
as a quick workaround for XFree86 3.3.3.1 to 3.3.5 you can specify
ChipID 0x8a10
VideoRam 4096
in the device section or compile your own server from XFree86 3.3.5 sources
using the following patch:
--- xc/programs/Xserver/hw/xfree86/vga256/drivers/s3v/regs3v.h~ Mon Sep 6 10:47:18 1999
+++ xc/programs/Xserver/hw/xfree86/vga256/drivers/s3v/regs3v.h Fri Sep 24 14:39:18 1999
@@ -421,7 +421,7 @@
/* Wait until Command FIFO is empty */
#define WaitCommandEmpty() do { int loop=0; mem_barrier(); \
- if (s3vPriv.chip == S3_ViRGE_GX2 || s3vPriv.chip == S3_ViRGE_MX || s3vPriv.chip == S3_ViRGE_MXP) \
+ if (S3_ViRGE_GX2_SERIES(s3vPriv.chip) || S3_ViRGE_MX_SERIES(s3vPriv.chip)) \
while ((!(((((mmtr)s3vMmioMem)->subsys_regs.regs.adv_func_cntl)) & 0x400)) && (loop++<MAXLOOP)); \
else if (S3_TRIO_3D_SERIES(s3vPriv.chip)) \
while (((IN_SUBSYS_STAT() & 0x5f00) != 0x5f00) && (loop++<MAXLOOP)); \
Boards based on those two chipsets are now supported in the current XFree86 release 3.3.5.
For an improved server for those see below the question regarding newer SiS chipsets.
Support has been added in this release for the blade3d and cyberblade chipset.
Support for some of the Voodoo boards has been added to the 3.3.5 release. The work of Daryll Strauss has been integrated in this release but you might want to directly check his server at http://glide.xxedgexx.com/3DfxRPMS_vb_glibc.html.
First, you need to get the XFree86 3.3.5 Mach64 server if you don't already have it. It should automatically detect the ATI chips available up to the time of its release (July 1999), except for all Rage128 cards (like the Fury). See below for Rage128 support. One exception from this is the Rage Pro LT chipset, as the server doesn't support the LCD with that chipset. A fix for this problem is known and will be included in XFree86-3.3.5.
Well, there is. If you are running Linux and the card is VBE-2.0 compliant in hardware. Unfortunately even today many new cards are not. But if yours is, then you can setup a late version of the Linux kernel (anything newer than 2.1.119 should do) with vesafb and use the XF86_FBDev server with it. Anthony D'Amico has a nice introduction how to do this at http://www.uno.edu/~adamico/banshee/, where he describes how to get the Banshee to work. Note that the section there about installing the XF68_FBDev X server can be omitted. Instead use the XF86_FBDev that is provided as part of XFree86 3.3.5. This works in a very similar way for other VBE-2.0 compliant cards as well.
SuSE has made available a Linux binary of a Rage128 server called XFCom_Rage128. You can get this server at the XSuSE website. As with all previous XFCom servers, sources for this server will be included in the next XFree86 release.
SuSE has made available a Linux binary of a SiSserver called XFCom_SiS. You can get this server at the XSuSE website. As with all previous XFCom servers, sources for this server will be included in the next XFree86 release.
This section includes a list of problems found since the release of XFree86 3.3.5.
Due to a small oops in the build process of the Linux-ix86-glibc2 binaries there were incorrect tar files available for download for about the first 48 hours after the release of XFree86-3.3.5. The problem has been rectified, now.
there is a slight incompatibility between SuSE and some other distributions. This has been fixed with glibc-2.1 based distributions, but is still visible in glibc-2.0 binaries built on SuSE-6.1 (as are the Linux-ix86-glibc2 binaries). As a workaround, please install the following library on your system:
ftp://ftp.suse.com/pub/suse/i386/update/6.1/a1/regframe.rpm
A copy of this is available as
"ftp://ftp.xfree86.org/XFree86/3.3.5/binaries/Linux-ix86-glibc/regframe.rpm
Now edit (as root) the file /etc/ld.so.preload (or create it in case it does not exist). The first line contains a (space separated) list of libraries to pre-load before program execution. Add /lib/libregframe.so to that list (or write /lib/libregframe.so in the first line in case you are creating this file).
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.
Check that you have a current BIOS version on your G100 card. Version 1.3 is said to have the problem, version 1.5 is said to fix the problem.
Disable the "panel stretch" or "enlarge panel" or "panel extend" feature in the Laptop BIOS. Do not use the vesafb Linux kernel module. With these two changes the server should work ok (you might need Option "cyber_shadow", too).
This is is a silly oversight in the sources. More than 16MB are not supported on Matrox boards. But as long as you are talking about 2D X server, more than 16MB are not really useful, so this restriction is not a real problem. It will be fixed in the next version, anyway.
In the meantime, please set the video memory to 16MB using the entry
VideoRAM 16384in the Device Section of the XF86Config file.
This problem is not fatal: the flickering or streaking is only transitional, i.e. while something changes on the display (moving windows around for example).
The driver fails to prohibit video modes that are beyond the card's capabilities. This happens at high color depths (24 and 32bpp) in combination with high pixel clocks.
Your options:
All of these options require changes to the XF86Config file. You can also restart the configuration tool (XF86Setup or xf86config) and reduce the vertical refresh limit of your monitor until XFree86 selects a mode that is still OK, but that has some side-effects. It's better to just throw out the modelines from the XF86Config file that cause problems.
Note that this is a hardware limitation of your video card that XFree86 just happens to ignore. A similar mode in any other operating system would not work either (but is mostly not allowed by the drivers).
Send comments regarding this page to (XFree86@XFree86.Org)