readme.ati.sgml

x.org上有关ati系列显卡最新驱动

This is the default behaviour.
If this option is negated, the cursor may lag the mouse when the X server is
very busy.<p>
<sect1>Option <it>``shadowfb''</it><p>
If this option is enabled, the driver will cause the CPU to do each drawing
operation first into a shadow frame buffer in system virtual memory and then
copy the result into video memory.
If this option is not active, the CPU will draw directly into video memory.
Enabling this option is beneficial for those systems where reading from video
memory is, on average, slower than the corresponding read/modify/write
operation in system virtual memory.
This is normally the case for PCI or AGP adapters, and, so, this option is
enabled by default.
For other bus types, the default behaviour is to disable this option.<p>
Note that, due to various limitations, this option is forcibly disabled when a
linear video memory aperture is not enabled, when the frame buffer depth is
less than 8, or when acceleration is used.<p>
<sect1>Option <it>``dpms''</it><p>
This option enables the driver's support for VESA's Display Power Management
Specification.<p>
<sect1>Option <it>``backingstore''</it><p>
This is not specifically a driver option.
It is used to enable the server's support for backing store, a mechanism by
which pixel data for occluded window regions is remembered by the server
thereby alleviating the need to send expose events to X clients when the data
needs to be redisplayed.<p>
<sect1>MemBase <it>address</it><p>
This specification is only effective for non-PCI Mach64 adapters, and is used
to override the CPU address at which the adapter will map its video memory.
Normally, for non-PCI adapters, this address is set by a DOS install utility
provided with the adapter.
The MemBase option can also be used to enable the linear aperture in those
cases where ATI's utility was not, or can not be, used.<p>
For PCI and AGP adapters, this address is determined at system bootup according
to the PCI Plug'n'Play specification which arbitrates the resource requirements
of most devices in the system.
This means the driver can not easily change the linear aperture address.<p>
<sect1>Option <it>``ReferenceClock''</it> ``frequency''<p>
This option is only applicable to non-Intel platforms, where an adapter BIOS is
not available to the driver.
The option specifies the reference frequency used by the adapter's clock
generator.
The default is 14.318 MHz, and other typical values are 28.636, or 29.5 MHz.<p>
<sect1>ClockChip <it>``name''</it><p>
This option is only applicable to non-Intel platforms, where an adapter BIOS is
not available to the driver, and the driver cannot reliably determine whether
the clock generator the adapter uses is a variant of an ATI 18818 (a.k.a.
ICS 2595) or an unsupported clock generator.
The only values that are acted upon are <it>``ATI 18818-0''</it> or
<it>``ATI 18818-1''</it>.
From this specification, the driver derives a reference divider of 43 or 46
(respectively) for use in clock programming calculations.
The driver's default behaviour, in this case, is to assume an unsupported clock
generator, which means it will treat it as a fixed-frequency clock generator,
as described under the heading <bf>``Clocks for unsupported programmable clock
generators''</bf> above.<p>
<sect>Video modes<p>
Mode timings can be derived from the information in X's doc subdirectory.
However, it is no longer required to specify such timings in an xorg.conf's
``Monitor'' section(s), if only standard mode timings are to be used.
The server automatically inserts VESA standard mode timings in every
``Monitor'' section, and these modes will be checked first for mode constraints
(monitor sync tolerances, video memory size, etc.).<p>
Furthermore, it is also no longer required to specify mode names in ``Display''
subsections.
Should no mode names be specified (or those specified do not yield a usable
mode), the server will automatically select as a default resolution the largest
usable mode, whether or not the chosen mode is specified in the corresponding
``Monitor'' section.<p>
For a digital flat panel, any sync tolerances should be removed from the
corresponding ``Monitor'' section.
The driver will automatically calculate these from the mode that is active on
server entry.
The driver also inserts timings for a mode called <it>"Native panel mode"</it>
that represents the panel's native resolution.<p>
<sect>Known problems and limitations<p>
There are several known problems or limitations related to the ATI
driver.
They include:<p>
<itemize>
<item>When using a Mach64's accelerator CRTC, the virtual resolution must be
less than 8192 pixels wide.
The VGA CRTC further limits the virtual resolution width to less than 4096
pixels, or to less than 2048 pixels for adapters based on 18800-x's (with 256kB
of memory) and on Mach64 integrated controllers.
These are hardware limits that cannot be circumvented.
<item>Virtual resolutions requiring more than 1MB of video memory (256kB in the
monochrome case) are not supported by the VGA CRTC on 88800GX and 88800CX
adapters.
This is a hardware limit that cannot be circumvented.
<item>Due to hardware limitations, doublescanned modes are not supported by the
accelerator CRTC in 88800GX, 88800CX, 264CT and 264ET adapters.
<item>The ``VScan'' modeline parameter is only supported when using the VGA
CRTC.
<item>Interlaced modes are not supported on 18800-x and 28800-x adapters when
using a virtual resolution that is 2048 pixels or wider.
When using a 18800-x with 256kB of video memory in 256-colour modes, this limit
is reduced to 1024.
This is yet another hardware limitation that cannot be circumvented.
<item>Video memory banking does not work in monochrome and 16-colour modes on
18800-x adapters.
This appears to be another hardware limit, but this conclusion cannot be
confirmed at this time.
The driver's default behaviour in this case is to limit video memory to 256kB.
<item>Video memory corruption can still occur during mode switches on 18800-x
adapters.
Symptoms of this problem include garbled fonts on return to text mode, and
various effects (snow, dashed lines, etc) on initial entry into a graphics
mode.
In the first case, the workaround is to use some other means of restoring the
text font.
On Linux, this can be accomplished with the kbd or svgalib packages.
In the second case, <htmlurl name="xrefresh(1)" url="xrefresh.1.html">
will usually clean up the image.
No complete solution to this problem is currently known.
It appears this corruption occurs due to either video memory bandwidth or
RAMDAC limitations, and so the driver will limit mode clocks to 40MHz.
<item>There is some controversy over what the maximum allowed clock frequency
should be on 264xT and 3D Rage adapters.
For now, clocks will, by default, be limited to 80MHz, 135MHz, 170MHz, 200MHz
or 230MHz, depending on the specific controller.
This limit can only be increased (up to a driver-calculated absolute maximum)
through the DACSpeed specification in xorg.conf.
Be aware however that doing so is untested and might damage the adapter.
<item>Except as in the previous items, clocks are limited to 80MHz on most
adapters, although many are capable of higher frequencies.
This will eventually be fixed in a future release.
<item>The use of a laptop's hot-keys to switch displays while this driver is
active can cause lockups and/or other woes, and is therefore not recommended.
It is not currently possible to solve this problem.<p>
<item>In situations where the driver is to simultaneously display on both a
panel and a CRT, the same image will be seen on both.
In particular, this means the CRT must be able to synchronise with the timings
of the panel's native resolution.
This is quite evident when the panel has ``odd-ball'' dimensions, such as
1400x1050, a resolution not commonly possible on CRTs or projection
equipment.<p>
Also, the display of independent images on the panel and CRT is not currently
implemented, and might never be, pending resolution of the previous item.<p>
</itemize>
Support for the following will be added in a future release:
<itemize>
<item>Mach32's accelerator CRTC.
This support is the first step towards accelerated support for Mach32's,
Mach8's, 8514/A's and other clones.
<item>Colour depth greater than 8 on non-integrated controllers, where
permitted by the hardware.
<item>Mach32, Mach8 and 8514/A Draw Engines.
<item>Hardware cursors where implemented by hardware.
This has already been done for Mach64 integrated controllers.
<item>TVOut, i.e. the ability to use a television screen as a monitor.
<item>Motion Video, i.e. displaying an asynchronous data stream (TV signal,
DVD, etc.) in a window or full-screen.
<item>3D operations.
</itemize>
<sect>Reporting problems<p>
If you are experiencing problems that are not already recorded in this
document, first ensure that you have the latest current release of this driver
and the Xorg X server.
Check the server's log (usually found in /var/log/Xorg.0.log) and <htmlurl
name="ftp://ftp.freedesktop.org/pub/Xorg"
url="ftp://ftp.freedesktop.org/pub/Xorg"> if you are uncertain.<p>
Secondly, please check Xorg's doc directory for additional information.<p>
Thirdly, a scan through the comp.windows.x.i386unix and comp.os.linux.x
newsgroups, the xorg mailing list archives at <htmlurl
name="http://lists.freedesktop.org/mailman/listinfo/xorg"
url="http://lists.freedesktop.org/mailman/listinfo/xorg">, and
the Xorg bug database at <htmlurl
name="https://bugs.freedesktop.org/enter_bug.cgi?product=xorg"
url="https://bugs.freedesktop.org/enter_bug.cgi?product=xorg">
can also prove useful in resolving problems.<p>
If you are still experiencing problems, you can send <it>non-HTMLised</it>
e-mail to <email>[e-mail]</email>.
Please be as specific as possible when describing the problem(s), and include
an <it>unedited</it> copy of the server's log and the xorg.conf file used.<p>
<sect>Driver history<p>
The complete history of the driver is rather cloudy.
The following is more than likely to be incomplete and inaccurate.<p>
Apparently, Per Lindqvist first got a driver working with an early ATI adapter
under X386 1.1a.
This original driver might have actually been based on a non-functional ATI
driver written by Thomas Roell (currently of Xi Graphics).<p>
Then Doug Evans added support for the ATI VGA Wonder XL, trying in the process
to make the driver work with all other ATI adapters available at the time.<p>
Rik Faith obtained the X11R4 driver from Doug Evans in the summer of 1992 and
ported the code to the X386 part of X11R5.
This subsequently became part of XFree86.<p>
Marc Aurele La France took over development and maintenance of the driver
in the fall of 1993 after Rik got rid of his VGA Wonder adapter.<p>
<sect>Driver versions<p>
Due to the introduction of loadable drivers in XFree86 4.0, it has become
necessary to track driver versions separately.
Driver releases use the following version numbering scheme.<p>
Version 1 of this driver is the one I inherited from Rik Faith.
This is the version found in XFree86 2.0 and 2.1.<p>
Version 2 is my first rewrite of this code which only ended up being a
partially unsuccessful attempt at generalising the driver for all VGA Wonder,
Mach32, and early Mach64 adapters.
Various releases of this version of the driver can be found in XFree86 2.1.1,
3.1, 3.1.1 and 3.1.2.<p>
Version 3 represents my second rewrite (although a rather lame one as rewrites
go).
Into version 3, I introduced clock programming for Mach64 adapters and merged
in the old ati_test debugging tool.
This is the version found in XFree86 3.2, 3.3 and 3.3.1.<p>
Version 4 is a rather major restructuring of version 3, which became larger
than I could comfortably handle in one source file.
This is the version found in XFree86 3.3.2, 3.3.3, 3.3.3.1, 3.3.3.2, 3.3.4,
3.3.5 and 3.3.6.<p>
Version 5 is an almost complete restructuring of version 4 to fit in the newer
driver API of XFree86 4.0 and later.<p>
The introduction of version 6 is a first swipe at porting the driver to
non-Intel architectures.<p>
</article>