<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Known problems and limitations</TITLE>
</HEAD>
<BODY BGCOLOR="#efefef" TEXT="black" LINK="blue" VLINK="#551A8B" ALINK="red">

<A HREF="ati.html"><EM>ATI Adapters README file</EM></A>
 <b>:</b> <EM>Known problems and limitations</EM><BR>
<b>Previous:</b> <A HREF="ati5.html"><EM>XF86Config specifications</EM></A><BR>
<b>Next:</b> <A HREF="ati7.html"><EM>Reporting problems</EM></A>


<HR NOSHADE>
  <H2><A NAME="15"></A>6. Known problems and limitations</H2>
<p>There are several known problems or limitations related to the XFree86 ATI
driver.
They include:</p>
<p>
<ul>
<li>A number of system lockups and blank screens have been reported when
using PCI Mach64 adapters.
The great majority of these problems have been found to be due to system
aspects that are unrelated to this driver.
As of this writing, these problems can be divided into three general areas:<p>Improper mouse protocol specification with some recent mice.
Try different protocol specifications or another mouse.</p>
<p>A system conflict with APM.
This problem is Linux-specific.
There is a bug in kernels 2.0.31 or earlier that prevents proper APM operation.
Upgrade to a more recent kernel or disable APM support.</p>
<p>The TV port on some Mach64 adapters needs to be disabled using an ATI utility
that might or might not be supplied with the adapter.
This problem is currently under investigation.</p>
</li>
<li>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's (with 256kB
of memory) and on Mach64 integrated controllers.
These are hardware limits that cannot be circumvented.</li>
<li>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.</li>
<li>Due to hardware limitations, doublescanned modes are not supported by the
accelerator CRTC in 88800GX, 88800CX, 264CT and 264ET adapters.</li>
<li>Monochrome interlaced modes are not supported on 18800-x and 28800-x when
using a virtual resolution that is 2048 pixels or wider.
This is yet another hardware limitation that cannot be circumvented.</li>
<li>Video memory banking does not work in monochrome and 16-colour modes on
18800 and 18800-1 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.</li>
<li>The default mode does not work on the more recent Mach64 adapters.
This problem is caused by the driver's attempt to use an incorrect dot clock
for the mode.
This will be fixed in a future release by reading the programmable clock
generator's registers to determine the actual clock used by the mode.</li>
<li>Most XFree86 servers assume that the video state on entry to the server
is a text mode.
This assumption is known to cause problems on operating systems which invoke
the server from a graphics mode.
DBCS versions of OS/2, primarily used in Asia, are examples of such operating
systems.
The solution, for now, is to somehow coerce the OS to invoke the server from a
text mode.
This driver has been changed to simply assume the mode on entry uses the
adapter's VGA CRTC (in text or graphics modes).
While this action alleviates the problem somewhat, it does not completely solve
it, as the server could still be invoked from an accelerator mode.
To properly fix this problem for all XFree86 servers is a large project, and
will probably not get done anytime soon.</li>
<li>Video memory corruption can still occur during mode switches on 18800 and
18800-1 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, xrefresh(1) will usually clean up the image.
No solution to this problem is currently known.</li>
<li>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 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 XF86Config.
Be aware however that doing so is untested and might damage the adapter.</li>
<li>Except as in the previous item, clocks are limited to 80MHz on most
adapters, although many are capable of higher frequencies.
This will be fixed in a future release.</li>
</ul>

Support for the following will be added in a future release:
<ul>
<li>Mach32 accelerator's CRTC.
This support is the first step towards accelerated support for Mach32's,
Mach8's, 8514/A's and other clones.</li>
<li>Colour depth greater than 8, where permitted by the hardware.</li>
<li>Mach64, Mach32, Mach8 and 8514/A Draw Engines.</li>
<li>Hardware cursors.</li>
</ul>

Support, through this driver, for 3D acceleration, "TV in a window" and video
capture, as implemented in some ATI adapters, is still in exploratory stages.
There is currently no framework within an XFree86 server for these functions,
although one is in development.
Also, ATI has not yet released a register-level specification for these, except
under non-disclosure agreements.</p>

 <HR NOSHADE>
<A HREF="ati.html"><EM>ATI Adapters README file</EM></A>
 <b>:</b> <EM>Known problems and limitations</EM><BR>
<b>Previous:</b> <A HREF="ati5.html"><EM>XF86Config specifications</EM></A><BR>
<b>Next:</b> <A HREF="ati7.html"><EM>Reporting problems</EM></A>



</BODY>
</HTML>
