Answers to Frequently Asked Questions about XFree86
XFree86 Frequently Asked Questions
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.
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.
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).
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.
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.
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.
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.
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.
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.
No. The "XF98" servers and related utilities will only work with the
Japanese PC98 architecture computers. This is a Japanese computer standard
that predates the Intel/Microsoft PC98 specification, and the two are
completely unrelated.
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.
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.
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.
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.
In the Screen Section of your XF86Config file (normally near the end of
that file), you may see a
"Virtual" keyword for every screen depth in that
section. Comment that line (prepend a "#") or remove it. In the example below,
the virtual size was 1280x1024,
while the largest mode is 1024x768, so even in that largest mode, you would
need to scroll around the
display.
Section "Screen"
...
Subsection "Display"
Depth 8
Modes "1024x768" "800x600" "640x480"
# Virtual 1280 1024
ViewPort 0 0
EndSubsection
...
If not given in a "Virtual" line in the
XF86Config file, XFree86 will automatically select the largest-resolution mode
as your virtual screen size.
E.g.:
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:
do not use 24bpp modes, but rather 16bpp or 32 bpp modes. 32bpp is best,
but it requires more video memory than 24bpp.
don't use broken X clients. There are patches for Netscape and even
compiled binaries on the net that fix this bug.
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 4096
If 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.
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.
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 Linux kernel version is below than 2.1.79 (this includes ALL 2.0.xx
kernels), and is compiled with the new GCC
2.8.x, XFree86 will always crash and dump a core file.
This is NOT a problem with XFree86, but rather with the Linux kernel. The
problem is in the Linux kernel file
/usr/src/linux/arch/i386/kernel/ioport.c. This file is not compiled
correctly with GCC 2.8.0.
There are a number possible solutions:
compile the entire Linux kernel with an older GCC.
compile it with 2.8.0, but use an ioport.o file compiled with an older
GCC.
replace ioport.c with the ioport.c file from linux kernel 2.1.79 or later
(this works for the 2.0.xx series kernels as well) and rebuild your kernel.
There have been reports that the same problem occurs with some versions of
egcs as well.
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.
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:
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.
Conversion to Bitmaps
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.
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).
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):
When downloading, please note that you will need the source tarball,
which contains installation and usage instructions.
X-TrueType
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).
FreeBSD users will be interested to know that X-TrueType is part of
the `ports' collection.
Xfstt
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:
this can only be done by the root user
other processes may be affected, especially when the server gets a lot
of work from client programs (animation and benchmarks are good examples)
This section contains some notes regarding
various chips for which support is not included in the current servers
and other chipset/card specific notes.
Try using the Mono or VGA16 servers. They should work with
any VGA compatible card (within limits - if you have a programmable
clock chip on the card, your available modes may be severely limited).
They just won't take full advantage of the card's capabilities.
Picking the "Unsupported Card" entry in XF86Setup will configure it to
work with the VGA16 server.
Trade your card in for one that is supported.
Write a driver yourself or find someone you know who is willing
and able to do it. If you choose this option, you should probably
contact us about joining the
development team
(and thus get access to the latest source code)
and about getting any code you write integrated into the next release.
If you are running a recent 2.1.x version of Linux, you can also
use the vesafb driver and the XF68_FBDev server. These are not supported
by XFree86, so don't ask us about any problems you may have using them.
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, Mystique G200, Millennium G400,
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.
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.
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.
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.
Support for all these NVIDIA chipsets is included in XFree86-3.3.5.
This server was partly implemented by NVIDIA and now follows the
Open Source guidelines.
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.
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.
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.
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.
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:
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).
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 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:
reduce the pixel clock for the modes that cause this flickering
reduce the vertical refresh for these modes (basically the same as the
previous suggestion)
reduce color depth (32 - 24 - 16 bpp)
turn off acceleration (unacceptable to most people)
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).