readme.ati

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

  5.13.  Option ``shadowfb''

  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.

  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.


  5.14.  Option ``dpms''

  This option enables the driver's support for VESA's Display Power
  Management Specification.



  5.15.  Option ``backingstore''

  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.


  5.16.  MemBase address

  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.

  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.


  5.17.  Option ``ReferenceClock''  ``frequency''

  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.


  5.18.  ClockChip ``name''

  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 ``ATI 18818-0'' or
  ``ATI 18818-1''.  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 ``Clocks for unsupported programmable clock generators''
  above.


  6.  Video modes

  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.).

  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.


  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 "Native panel mode" that
  represents the panel's native resolution.


  7.  Known problems and limitations

  There are several known problems or limitations related to the ATI
  driver.  They include:


  +o  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.

  +o  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.

  +o  Due to hardware limitations, doublescanned modes are not supported
     by the accelerator CRTC in 88800GX, 88800CX, 264CT and 264ET
     adapters.

  +o  The ``VScan'' modeline parameter is only supported when using the
     VGA CRTC.

  +o  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.

  +o  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.

  +o  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, xrefresh(1) 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.

  +o  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.

  +o  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.

  +o  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.


  +o  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.

     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.


     Support for the following will be added in a future release:

  +o  Mach32's accelerator CRTC.  This support is the first step towards
     accelerated support for Mach32's, Mach8's, 8514/A's and other
     clones.

  +o  Colour depth greater than 8 on non-integrated controllers, where
     permitted by the hardware.

  +o  Mach32, Mach8 and 8514/A Draw Engines.

  +o  Hardware cursors where implemented by hardware.  This has already
     been done for Mach64 integrated controllers.

  +o  TVOut, i.e. the ability to use a television screen as a monitor.

  +o  Motion Video, i.e. displaying an asynchronous data stream (TV
     signal, DVD, etc.) in a window or full-screen.

  +o  3D operations.

  8.  Reporting problems

  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 ftp://ftp.freedesktop.org/pub/Xorg
  if you are uncertain.

  Secondly, please check Xorg's doc directory for additional
  information.

  Thirdly, a scan through the comp.windows.x.i386unix and
  comp.os.linux.x newsgroups and the xorg mailing list using your
  favourite archiving service can also prove useful in resolving
  problems.

  If you are still experiencing problems, you can send me non-HTMLised
  e-mail at  <[e-mail]>.  Please be as specific as possible when
  describing the problem(s), and include an unedited copy of the
  server's log and the xorg.conf file used.


  9.  Driver history

  The complete history of the driver is rather cloudy.  The following is
  more than likely to be incomplete and inaccurate.
  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).

  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.

  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.

  I (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.


  10.  Driver versions

  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.

  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.

  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.

  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.

  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.

  Version 5 is an almost complete restructuring of version 4 to fit in
  the newer driver API of XFree86 4.0 and later.

  The introduction of version 6 is a first swipe at porting the driver
  to non-Intel architectures.