XFree86 4.3.0.1xf86-4_3_0_1PRE_xf86-4_3_0_1

1 files changed, 666 insertions, 204 deletions

diff --git a/README.sgml b/README.sgml
index 2bce190..4edd1cf 100644
--- a/README.sgml
+++ b/README.sgml
@@ -1,36 +1,61 @@
-<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN">
+<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN"[
+<!ENTITY % defs SYSTEM "defs.ent"> %defs;
+]>
  
 <article>
 
 <!-- Title information -->
 <title> Information for Chips and Technologies Users
-<author> David Bateman (<it>dbateman@ee.uts.edu.au</it>),
-         Egbert Eich (<it>Egbert.Eich@Physik.TH-Darmstadt.DE</it>)
-<date> 28th July 1997
+<author> David Bateman (<email>dbateman@club-internet.fr</email>),
+         Egbert Eich (<email>eich@xfree86.org</email>)
+<date> 1st January 2001
+
+<ident>
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/chips.sgml,v 3.38 2001/10/01 13:44:02 eich Exp $
+</ident>
 
 <!-- Table of contents -->
 <toc>
 
 <sect> Introduction <p>
 
-The Chips and Technologies range of chips are primarily manufactured
-for use in laptop computers, where their power conservation circuitry
-is of importance. They can however be found in a few "<tt>Green</tt>"
-video cards for desktop machines. This release of XFree includes 
-support for 
+With the release of XFree86 version &relvers;, the Chips and Technologies
+driver has been extensively rewritten and contains many new features.
+This driver must be considered work in progress, and those users
+wanting stability are encouraged to use the older XFree86 3.3.x
+versions. However this version of the Chips and Technologies driver
+has many new features and bug fixes that might make users prefer
+to use this version. These features include
 
 <itemize>
-<item>Linear Addressing
-<item>16/ 24 bits per pixel
-<item>Fully programmable clocks are supported
-<item>H/W cursor support
-<item>BitBLT acceleration of many operations using XAA
+<item>The long standing black/blue screen problem that some people have
+	had should be fixed.
+<item>Hardware/Software cursor switching on the fly, that should fix
+	many of the known hardware cursor problems.
+<item>Gamma correction at all depths and DirectColor visuals for depths of
+	15 or greater with the HiQV series of chipsets.
+<item>Supports PsuedoColor overlays on 16bpp TrueColor screens for HiQV.
+<item>Supports YUV colour space conversion with the XVideo extension.
+<item>32bpp pixmaps while using a framebuffer in 24bpp packed pixel mode.
+<item>Heaps more acceleration.
+<item>1/4bpp support.
+<item>Multihead
+<item>Much more...
 </itemize>
 
-Most of the Chips and Technologies chipsets are supported by this driver
-to some degree.
+This document attempts to discuss the features of this driver, the
+options useful in configuring it and the known problems. Most of the
+Chips and Technologies chipsets are supported by this driver to some
+degree.
 
 <sect> Supported Chips <p>
+
+The Chips and Technologies chipsets supported by this driver have one
+of three basic architectures. A basic architecture, the WinGine architecture
+which is a modification on this basic architecture and a completely new
+HiQV architecture.
+
+<sect1>Basic architecture<p>
 <descrip>
 <tag>ct65520</tag>
 	(Max Ram: 1Mb, Max Dclk: 68MHz@5V)
@@ -67,12 +92,33 @@ to some degree.
 	This chip is similar to the 65545, but it also includes XRAM support
 	and supports the higher dot clocks of the 65546. 
 	(Max Ram: 1Mb, Max Dclk: 80MHz)
+</descrip>
+
+<sect1>WinGine architecture<p>
+<descrip>
+<tag>ct64200</tag>
+	This chip, also known as the WinGine, is used in video cards
+        for desktop systems. It often uses external DAC's and programmable
+	clock chips to supply additional functionally. None of these are
+	currently supported within the driver itself, so many cards will only
+	have limited support. Linear addressing is not supported for this
+	card in the driver.
+	(Max Ram: 2Mb, Max Dclk: 80MHz)
+<tag>ct64300</tag>
+	This is a more advanced version of the WinGine chip, with specification
+	very similar to the 6554x series of chips. However there are many
+	differences at a register level. A similar level of acceleration to
+	the 65545 is included for this driver.
+	(Max Ram: 2Mb, Max Dclk: 80MHz)
+</descrip>
+
+<sect1>HiQV Architecture<p>
+<descrip>
 <tag>ct65550</tag>
-	This chip started a completely new architecture to previous ct655xx
-	chips. It includes many new features, including improved BitBLT
-	support (24bpp color expansion, wider maximum pitch, etc), Multimedia
+	This chip includes many new features, including improved BitBLT
+	support (24bpp colour expansion, wider maximum pitch, etc), Multimedia
 	unit (video capture, zoom video port, etc) and 24bpp uncompressed true
-	color (i.e 32bpp mode). Also memory mapped I/O is possible on all bus
+	colour (i.e 32bpp mode). Also memory mapped I/O is possible on all bus
 	configurations. 
 	(Max Ram: 2Mb, Max Dclk: 80MHz@3.3V,100MHz@5V)
 <tag>ct65554</tag>
@@ -90,75 +136,62 @@ to some degree.
 	serial link allows an LCD screens to be located up to 100m from the 
 	video processor. Expect to see this chip soon in LCD desktop machines
 	(Max Ram: 4Mb, Max Dclk: 110MHz@3.3V)
-<tag>ct64200</tag>
-	This chip, also known as the WinGine, is used in video cards
-        for desktop systems. It often uses external DAC's and programmable
-	clock chips to supply additional functionally. None of these are
-	currently supported within the driver itself, so many cards will only
-	have limited support. Linear addressing is not supported for this
-	card in the driver.
-	(Max Ram: 2Mb, Max Dclk: 80MHz)
-<tag>ct64300</tag>
-	This is a more advanced version of the WinGine chip, with specification
-	very similar to the 6554x series of chips. However there are many
-	difference at a register level. A similar level of acceleration to
-	the 65545 is included for this driver.
-	(Max Ram: 2Mb, Max Dclk: 80MHz)
+<tag>ct69000</tag>
+	Similar to the 65555 but incorporates 2Mbytes of SGRAM on chip. It is
+	the first Chips and Technologies chipset where all of the registers
+	are accessible through MMIO, rather than just the BitBlt registers.
+	(Max Ram: 2Mb Only, Max Dclk: 130MHz@3.3V)
+<tag>ct69030</tag>
+	Similar to the 69000 but incorporates 4Mbytes of SGRAM on chip and has
+	faster memory and pixel clock limits. Also includes a second display
+	channel so that the CRT can display independently of the LCD.
+	(Max Ram: 4Mb Only, Max Dclk: 170MHz@3.3V)
 </descrip>
 
+
 <sect> XF86Config Options <p>
 
-The following options are of particular interest to the Chips
-and Technologies driver.  Each of them must be specified in the
-`svga' driver section of the XF86Config file, within the Screen
-subsections of the depths to which they are applicable (you can enable
-options for all depths by specifying them in the Device section).
+The following options are of particular interest to the Chips and
+Technologies driver. It should be noted that the options are case
+insensitive, and that  white space and "_" characters are ignored.
+There are therefore a wide variety of possible forms for all options.
+The forms given below are the preferred forms.
+
+Options related to drivers can be present in the Screen, Device and
+Monitor sections and the Display subsections.  The order of precedence
+is Display, Screen, Monitor, Device. 
 
 <descrip>
 <tag>
-Option &dquot;noaccel&dquot;
+Option "NoAccel"
 </tag>
         This option will disable the use of any accelerated functions.
         This is likely to help with some problems related to DRAM
         timing, high dot clocks, and bugs in accelerated functions, at
         the cost of performance (which will still be reasonable on VLB/PCI).
 <tag>
-Option &dquot;no_bitblt&dquot; (Chips 65545 and later)
-</tag>
-        This option will disable the use of the BitBLT engine which the
-	65545 and above have. If you can use the  "<tt>noaccel</tt>" option
-	to correct a problem, then this option might be better to use.
-	It still allows the use of generic speedups.
-<tag>
-Option &dquot;xaa_no_color_exp&dquot; (Chips 65545 and later)
-</tag>
-	This option will have the effect of disabling the use
-	of monochrome colour expansion. In particular this effects
-	text and bitmaps. It is useful for problems related to image writes,
-	and possible acceleration problems. In general this will result in
-	a reduced performance. Note that this option replaces the 
-	"<tt>no_imageblt</tt>" option used in XFree 3.2.
-<tag>
-Option &dquot;xaa_benchmark&dquot; (Chips 65545 and later)
-</tag>
-	Turns on the XAA acceleration benchmarks. Information regarding
-	what graphics primitives are accelerated and their relatives
-	speeds will be printed when the X server starts.
-<tag>
-videoram 1024 (or another value)
+VideoRam 1024 (or another value)
 </tag>
         This option will override the detected amount of video memory,
         and pretend the given amount of memory is present on the card.
-	Note that many ct655xx chips only allow up to 1Mb of videoram,
-	and the amount should be correctly detected.
 <tag>
-Option &dquot;nolinear&dquot; (Chips 65530 and later)
+Option "NoLinear"
+</tag>
+	By default linear addressing is used on all chips where it
+	can be set up automatically. The exception is for depths of
+	1 or 4bpp where linear addressing is turned off by default.
+	It is possible to turn the linear addressing off with this
+	option. Note that H/W acceleration is only supported with
+	linear addressing.
+<tag>
+Option "Linear"
 </tag>
-	By default linear addressing is used on all ct655xx chips.
-	However this might be broken in some implementations. It
-	is possible to turn the linear addressing off with this
-	option. Note that H/W acceleration and 16/24bpp are only
-	supported with linear addressing.
+	When the chipset is capable of linear addressing and it has
+	been turned off by default, this option can be used to turn it
+	back on. This is useful for the 65530 chipset where the base
+	address of the linear framebuffer must be supplied by the user,
+	or at depths 1 and 4bpp. Note that linear addressing at 1 and 4bpp
+	is not guaranteed to work correctly.
 <tag>
 MemBase 0x03b00000 (or a different address)
 </tag>
@@ -170,18 +203,28 @@ MemBase 0x03b00000 (or a different address)
 	to suit. Note that for the 65530 this is required as the
 	base address can't be correctly probed.
 <tag>
-Option &dquot;sw_cursor&dquot; (Chips 65545 and later)
+Option "HWcursor"
+</tag>
+	For chipsets that support hardware cursors, this option enforces
+	their use, even for cases that are known to cause problems on some
+	machines. Note that it is overridden by the "<tt>SWcursor</tt>"
+	option. Hardware cursors effectively speeds all graphics operations
+	as the job of ensuring that the cursor remains on top is now given
+	to the hardware. It also reduces the effect of cursor flashing during
+	graphics operations.
+<tag>
+Option "SWcursor"
 </tag>
-        This disables use of the hardware cursor provided by the chip.
-        Try this if the cursor seems to have problems. 
+	This disables use of the hardware cursor provided by the chip.
+	Try this if the cursor seems to have problems. 
 <tag>
-Option &dquot;STN&dquot;
+Option "STN"
 </tag>
 	The server is unable to differentiate between SS STN 
  	and TFT displays. This forces it to identify the display
 	as a SS STN rather than a TFT.
 <tag>
-Option &dquot;use_modeline&dquot;
+Option "UseModeline"
 </tag>
 	The flat panel timings are related to the panel size and not the
 	size of the mode specified in XF86Config. For this reason the
@@ -190,7 +233,7 @@ Option &dquot;use_modeline&dquot;
 	recalculated from the modeline with this option. However the panel
 	size will still be probed.
 <tag>
-Option &dquot;fix_panel_size&dquot;
+Option "FixPanelSize"
 </tag>
 	For some machines the LCD panel size is incorrectly probed from
 	the registers. This option forces the LCD panel size to be
@@ -198,28 +241,30 @@ Option &dquot;fix_panel_size&dquot;
 	use of a mode that is a different size than the panel. Before
 	using this check that the server reports an incorrect panel
 	size. This option can be used in conjunction with the option
-	&dquot;use_modeline&dquot; to program all the panel timings using
+	"UseModeline" to program all the panel timings using
 	the modeline values.
 <tag>
-Option &dquot;no_stretch&dquot;
+Option "NoStretch"
 </tag>
 	When the size of the mode used is less than the panel size, the
 	default behaviour of the server is to stretch the mode in an attempt
 	to fill the screen. A "<tt>letterbox</tt>" effect with no stretching
 	can be achieved using this option.
 <tag>
-Option &dquot;lcd_center&dquot;
+Option "LcdCenter"
 </tag>
 	When the size of the mode used is less than the panel size, the
 	default behaviour of the server is to align the left hand edge of
 	the display with the left hand edge of the screen. Using this option
 	the mode can be centered in the screen. This option is reported to
-	have problems with some machines at 16/24bpp, the effect of which
+	have problems with some machines at 16/24/32bpp, the effect of which
 	is that the right-hand edge of the mode will be pushed off the screen.
 <tag>
-Option &dquot;hw_clocks&dquot; (Chips 65535 and later)
+Option "HWclocks"
 </tag>
-	On chips 65535 and later, the default is to use the programmable
+	For the chips either using the WinGine or basic architectures, the
+	chips generates a number of fixed clocks internally. With the chips
+	65535 and later or the 64300, the default is to use the programmable
 	clock for all clocks. It is possible to use the fixed clocks
 	supported by the chip instead by using this option. Typically
 	this will give you some or all of the clocks 25.175, 28.322,
@@ -229,77 +274,88 @@ Option &dquot;hw_clocks&dquot; (Chips 65535 and later)
 	"<tt>TextClockFreq</tt>" option), as many flat panels will need a
 	dot clock different than the default to synchronise. The
 	programmable clock makes this option obsolete and so it's use
-	isn't recommended.
+	isn't recommended. It is completely ignored for HiQV chipsets.
 <tag>
-Option &dquot;use_vclk1&dquot; (Chips 65550 and later)
+TextClockFreq 25.175
+</tag>
+	Except for the HiQV chipsets, it is impossible for the server to read
+	the value of the currently used frequency for the text console when
+	using programmable clocks. Therefore the server uses a default value of
+	25.175MHz as the text console clock. For some LCDs, in particular
+	DSTN screens, this clock will be wrong. This allows the user to
+	select a different clock for the server to use when returning to
+	the text console.
+<tag>
+Option "FPClock8"   "65.0MHz"
+Option "FPClock16"  "65.0MHz"
+Option "FPClock24"  "65.0MHz"
+Option "FPClock32"  "65.0MHz"
+</tag>
+	In general the LCD panel clock should be set independently of the
+	modelines supplied. Normally the chips BIOS set the flat panel
+	clock correctly and so the default behaviour with HiQV chipset is
+	to leave the flat panel clock alone, or force it to be 90% of the
+	maximum allowable clock if the current panel clock exceeds the
+	dotclock limitation due to a depth change. This option allows the user
+	to force the server the reprogram the flat panel clock independently
+	of the modeline with HiQV chipset. The four options are for 8bpp or
+	less, 16, 24 or 32bpp LCD panel clocks, where the options above set
+	the clocks to 65MHz.
+<tag>
+Option "CRTClkIndx" "2"
+Option "FPClkIndx" "1"
 </tag>
 	The HiQV series of chips have three programmable clocks. The
 	first two are usually loaded with 25.175 and 28.322MHz for
 	VGA backward compatibility, and the third is used as a fully
 	programmable clock. On at least one system (the Inside 686 LCD/S
-	single board computer) the third clock is unusable. This option
-	forces the use of VClk1 as the programmable clock.
+	single board computer) the third clock is unusable. These options
+	can be used to force a particular clock index to be used
 <tag>
-TextClockFreq 25.175
+Option "MMIO"
 </tag>
-	It is impossible for the server to read the value of the currently
-	used frequency for the text console from the chip with the ct6554x
-	series of chips. Therefore the server uses a default value of
-	25.175MHz as the text console clock. For some LCDs, in particular
-	DSTN screens, this clock will be wrong. This allows the user to
-	select a different clock for the server to use when returning to
-	the text console.
+	This has a different effect depending on the hardware on which it
+	is used. For the 6554x machines MMIO is only used to talk to the
+	BitBLT engine and is only usable with  PCI buses. It is enabled
+	by default for 65545 machines since the blitter	can not be used
+	otherwise. The HiQV series of chipsets must use MMIO with their
+	BitBLT engines, and so this is enabled by default.
 <tag>
-Option &dquot;mmio&dquot;
+Option "FullMMIO"
 </tag>
-        This enables the use of memory-mapped I/O to talk to the BitBLT
-        engine. By default memory-mapped I/O is not enabled on the
-	6554x series of chips, and is only usable on 6554x's with PCI
-	buses. This option has no effect when not using the BitBLT engine
-	(e.g. when using "<tt>no_bitblt</tt>"), or for the 65550 which can
-	only use MMIO for access to the BitBLT engine. On 65545 PCI
-	machines MMIO is enabled by default because the blitter can not
-	be used otherwise.
+	The 690xx chipsets can use MMIO for all communications with the
+	video processor. So using this option on a 690xx chipset forces
+	them to use MMIO for all communications. This only makes sense
+	when the 690xx is on a PCI bus so that normal PIO can be disabled.
 <tag>
-Option &dquot;suspend_hack&dquot;
+Option "SuspendHack"
 </tag>
-	This option sets the centering and stretching to the bios
+	This option sets the centering and stretching to the BIOS
 	default values. This can fix suspend/resume problems on some
-	machines. It overrides the options &dquot;lcd_center&dquot; 
-	and &dquot;no_stretch&dquot;.
+	machines. It overrides the options "LcdCenter" 
+	and "NoStretch".
 <tag>
-Option &dquot;use_18bit_bus&dquot;  (Chips 65540/45/46/48)
+Option "18bitBus"  (Chips 65540/45/46/48)
 </tag>
 	For 24bpp on TFT screens, the server assumes that a 24bit bus
 	is being used. This can result in a reddish tint to 24bpp mode.
 	This option, selects an 18 bit TFT bus. For other depths this
 	option has no effect.
 <tag>
-Chipset &dquot;ct65546&dquot; (or some other chip)
+Chipset "ct65546" (or some other chip)
 </tag>
 	It is possible that the chip could be misidentified, particular
 	due to interactions with other drivers in the server. It is
 	possible to force the server to identify a particular chip with
 	this option.
 <tag>
-Option &dquot;sync_on_green&dquot; (Chips 65550/54/55 and 68554)
+Option "SyncOnGreen"
 </tag>
 	Composite sync on green. Possibly useful if you wish to use an
-	old workstation monitor. The 65550/54 internal RAMDAC's support
+	old workstation monitor. The HiQV internal RAMDAC's supports
 	this mode of operation, but whether a particular machine does
 	depends on the manufacturer. 
 <tag>
-Option &dquot;fast_dram&dquot; (Chips 65550/54/55 and 68554)
-</tag>
-	This option sets the internal memory clock (MCLK) registers to 38MHz.
-	The default value programmed by the BIOS is usually OK, but some
-	machines can accept a faster MClk to achieve a better performance.
-	One machine known to work well with this option is the Toshiba 720CDT.
-	Note that newer machines often have an MClk greater than 38MHz, and
-	so this option might actually slower the machine down. This option
-	is generally not recommended and is superseded by the
-	"<tt>Set_MemClk</tt>" option.
-<tag>
 DacSpeed 80.000
 </tag>
 	The server will limit the maximum dotclock to a value as specified
@@ -309,12 +365,119 @@ DacSpeed 80.000
 	prefer. Use caution with this option, as driving the video processor
 	beyond its specifications might cause damage.
 <tag>
-Set_MemClk 38.000 (Chips 65550/54/55 and 68554)
+Option "SetMClk" "38.000MHz"
+Option "SetMClk" "38000kHz"
+</tag>
+	This option sets the internal memory clock (MCLK) registers of HiQV
+	chipsets to 38MHz or some other value. Use caution as excess heat
+	generated by the video processor if its specifications are exceeded
+	might cause damage. However careful use of this option might boost
+	performance. This option might also be used to reduce the speed of
+	the memory clock to preserve power in modes that don't need the full
+	speed of the memory to work correctly. This option might also be
+	needed to reduce the speed of the memory clock with the
+	"<tt>Overlay</tt>" option. 
+<tag>
+Option "RGBbits"  "8"
+</tag>
+	By default it is assumed that there are 6 significant bits in the
+	RGB representation of the colours in 4bpp and above. If the colours
+	seem darker than they should be, perhaps your ramdac is has 8
+	significant bits. This option forces the server to assume that there
+	are 8 significant bits.
+<tag>
+Option "ShowCache"
+</tag>
+	This is a debugging option and general users have no need of it.
+	Using this option, when the virtual desktop is scrolled away from
+	the zero position, the pixmap cache becomes visible. This is useful
+	to see that pixmaps, tiles, etc have been properly cached.
+<tag>
+Option "ShadowFB"
+</tag>
+	This option is only useful when acceleration can't be used and linear
+	addressing can be used. With this option all of the graphics are
+	rendered into a copy of the framebuffer that is keep in the main memory
+	of the computer, and the screen is updated from this copy. In this
+	way the expensive operation of reading back to contents of the screen
+	is never performed and the performance is improved. Because the
+	rendering is all done into a virtual framebuffer acceleration can not
+	be used.
+<tag>
+Option "NoTMED"
+</tag>
+	The new TMED DSTN dithering scheme available on recent HiQV chipsets
+	gives improved performance. However, some machines appear to have this
+	feature incorrectly setup. If you have <tt>snow</tt> on your DSTN
+	LCD, try using this option. This option is only relevant for chipsets
+	more recent than the ct65555 and only when used with a DSTN LCD.
+<tag>
+Option "Overlay"
+</tag>
+	The HiQV chipsets contain a multimedia engine that allow a 16bpp
+	window to be overlayed on the screen. This driver uses this capability
+	to include a 16bpp framebuffer on top of an 8bpp framebuffer. In this
+	way PseudoColor and TrueColor visuals can be used on the same screen.
+	XFree86 believes that the 8bpp framebuffer is overlayed on the 16bpp
+	framebuffer. Therefore to use this option the server must be started
+	in either 15 or 16bpp depth. Also the maximum size of the desktop 
+	with this option is 1024x1024, as this is the largest window that the
+	HiQV multimedia engine can display. Note that this option using the
+	multimedia engine to its limit, and some manufacturers have set a
+	default memory clock that will cause pixel errors with this option.
+	If you get pixel error with this option try using the
+	"<tt>SetMClk</tt>" option to slow the memory clock. It should also
+	be noted that the XVideo extension uses the same capabilities of the
+	HiQV chipsets as the Overlays. So using this option disables the
+	XVideo extension.
+<tag>
+Option "ColorKey" "255" 
+</tag>
+	Normally the colour transparency key for the overlay is the 8bpp lookup
+	table entry 255. This might cause troubles with some applications, and
+	so this option allows the colour transparency key to be set to some
+	other value. Legal values are 2 to 255 inclusive.
+<tag>
+Option "VideoKey" "255" 
 </tag>
-	This option sets the internal memory clock (MCLK) registers to 38MHz
-	or some other value. Use caution as excess heat generated by
-	the video processor if its specifications are exceeded might cause
-	damage. However careful use of this option might boost performance.
+	This sets the default pixel value for the YUV video overlay key. Legal
+	values for this key are depth dependent. That is from 0 to 255 for
+	8bit depth, 0 to 32,767 for 15bit depth, etc. This option might be used
+	if the default video overlay key causes problems.
+<tag>
+Option "DualRefresh"
+</tag>
+	The 69030 chipset has independent display channels, that can be
+	configured to support independent refresh rates on the flat panel
+	and on the CRT. The default behaviour is to have both the flat panel
+	and the CRT use the same display channel and thus the same refresh
+	rate. This option forces the two display channels to be used, giving
+	independent refresh rates. 
+<tag>
+Option "Crt2Memory" "2048" 
+</tag>
+	The ct69030 supports dual-head display. By default the two display
+	share equally the available memory. This option forces the second
+	display to take a particular amount of memory. Please read the
+	section below about dual-head display.
+<tag>
+Option "XaaNoScreenToScreenCopy",
+Option "XaaNoSolidFillRect",
+Option "XaaNoSolidHorVertLine",
+Option "XaaNoMono8x8PatternFillRect",
+Option "XaaNoColor8x8PatternFillRect",
+Option "XaaNoCPUToScreenColorExpandFill", 
+Option "XaaNoScreenToScreenColorExpandFill",
+Option "XaaNoImageWriteRect",
+Option "XaaNoImageReadRect",
+Option "XaaNoPixmapCache",
+Option "XaaNoOffscreenPixmaps" 
+</tag>
+	These option individually disable the features of the XAA acceleration
+	code that the Chips and Technologies driver uses. If you have a problem
+	with the acceleration and these options will allow you to isolation 
+	the problem. This information will be invaluable in debugging any
+	problems.
 </descrip>
 
 <sect> Modelines <p>
@@ -332,18 +495,17 @@ driver you'll needed to considered several points
 	attempt to round-up the virtual X dimension to a multiple of 64,
 	but leave the virtual resolution untouched. This might further
 	reduce the available memory.
-<tag> * 16/24 Bits Per Pixel </tag>
-		Chips later than the ct65540 are capable of supporting
-	Hi-Color and True-Color modes. These are implemented in the current
+<tag> * 16/24/32 Bits Per Pixel </tag>
+		Hi-Color and True-Color modes are implemented in the
 	server. The clocks in the 6554x series of chips are internally
 	divided by 2 for 16bpp and 3 for 24bpp, allowing one modeline to
 	be used at all depths.  The effect of this is that the maximum
 	dot clock visible to the user is a half or a third of the value
-	at 8bpp. The 6555x series of chips doesn't need to use additional
+	at 8bpp. The HiQV series of chips doesn't need to use additional
 	clock cycles to display higher depths, and so the same modeline
 	can be used at all depths, without needing to divide the clocks.
-	Also 16/24 bpp modes will need 2 or 3 times respectively more video
-	ram.
+	Also 16/24/32 bpp modes will need 2 , 3 or 4 times respectively more
+	video ram.
 <tag> * Frame Acceleration</tag>
 		Many DSTN screens use frame acceleration to improve the
 	performance of the screen. This can be done by using an external
@@ -357,12 +519,24 @@ driver you'll needed to considered several points
 	(800x600 panel) and 157287 bytes (1024x768 panel).
 <tag> * H/W Acceleration </tag>
 		The H/W cursor will need 1kB for the 6554x and 4kb for the
-	65550. On the 64300 chips the H/W cursors is stored in registers and
+	65550. On the 64300 chips the H/W cursor is stored in registers and
 	so no allowance is needed for the H/W cursor. In addition to this
 	many graphics operations are speeded up using a
 	"<tt>pixmap cache</tt>". Leaving too little memory available for
 	the cache will only have a detrimental effect on the graphics
 	performance.
+<tag> * PseudoColor Overlay </tag>
+		If you use the "<tt>overlay</tt>" option, then there are
+	actually two framebuffers in the video memory. An 8bpp one and a
+	16bpp one. The total memory requirements in this mode of operation
+	is therefore similar to a 24bpp mode. The overlay consumes memory
+	bandwidth, so that the maximum dotclock will be similar to a 24bpp
+	mode.
+<tag> * XVideo extension* </tag>
+		Like the overlays, the Xvideo extension uses a part of the
+	video memory for a second framebuffer. In this case enough memory
+	needs to be left for the largest unscaled video window that will be 
+	displayed.
 <tag> * VESA like modes </tag>
 		We recommend that you try and pick a mode that is similar
 	to a standard VESA mode. If you don't a suspend/resume or LCD/CRT
@@ -374,7 +548,15 @@ driver you'll needed to considered several points
 	more memory bandwidth for use in the drawing operations. Some
 	users prefer to use clocks that are defined by their BIOS. This
 	has the advantage that the BIOS will probably restore the clock
-	they specified after a suspend/resume or LCD/CRT switch.
+	they specified after a suspend/resume or LCD/CRT switch. For a
+	complete discussion on the dot clock limitations, see the next
+	section.
+<tag> * Dual-head display </tag>
+		Dual-head display has two effects on the modelines. Firstly,
+	the memory requirements of both heads must fit in the available
+	memory. Secondly, the memory bandwidth of the video processor is
+	shared between the two heads. Hence the maximum dot-clock might 
+	need to be limited.
 </descrip>
 
 The driver is capable of driving both a CRT and a flat panel
@@ -384,34 +566,267 @@ mode chosen. For this reason it is recommended to use one of the programs
 that automatically generate XF86Config files, such as "<tt>xf86config</tt>"
 or "<tt>XF86Setup</tt>".
 
-However there are many machines, particular those with 800x600 screen or
-larger, that need to reprogram the panel timings. The reason for this is
-that the manufacturer has used the panel timings to get a standard EGA
-mode to work on flat panel, and these same timings don't work for an SVGA
-mode. For these machines the "<tt>use_modeline</tt>" and/or possibly the
-"<tt>fix_panel_size</tt>" option might be needed. Some machines that 
-are known to need these options include.
+However there are many older machines, particularly those with 800x600
+screen or larger, that need to reprogram the panel timings. The reason
+for this is that the manufacturer has used the panel timings to get a
+standard EGA mode to work on flat panel, and these same timings don't
+work for an SVGA mode. For these machines the "<tt>UseModeline</tt>"
+and/or possibly the "<tt>FixPanelSize</tt>" option might be needed. Some
+machines that are known to need these options include.
 
 <quote><verb>
 Modeline "640x480@8bpp"	  25.175  640  672  728  816   480  489  501  526
 Modeline "640x480@16bpp"  25.175  640  672  728  816   480  489  501  526
-Options: "use_modeline"
+Options: "UseModeline"
 Tested on a Prostar 8200, (640x480, 65548, 1Mbyte)
 </verb></quote>
 
 <quote><verb>
 Modeline "800x600@8bpp"	  28.322  800  808  848  936   600  600  604  628
-Options: "fix_panel_size", "use_modeline"
+Options: "FixPanelSize", "UseModeline"
 Tested on a HP OmniBook 5000CTS (800x600 TFT, 65548, 1Mbyte)
 </verb></quote>
 
 <quote><verb>
 Modeline "800x600@8bpp"	  30.150  800  896  960 1056   600  600  604  628
-Options: "fix_panel_size", "use_modeline"
-Test on a Zeos Meridan 850c (800x600 DSTN, 65545, 1Mbyte)
+Options: "FixPanelSize", "UseModeline"
+Tested on a Zeos Meridan 850c (800x600 DSTN, 65545, 1Mbyte)
+</verb></quote>
+
+The IBM PC110  works best with a 15MHz clock (Thanks to Alan Cox):
+<quote><verb>
+Modeline "640x480"        15.00   640  672  728  816   480  489  496  526
+Options: "TextClockFreq" "15.00"
+IBM PC110 (65535, Citizen L6481L-FF DSTN) 
+</verb></quote>
+
+The NEC Versa 4080 just needs the "FixPanelSize" option. To the best of my
+knowledge no machine with a HiQV needs the "UseModeline" or "FixPanelSize"
+options.
+
+<sect> Dual Display Channel<p>
+
+XFree86 releases later than 4.1.0 support dual-channel display on the ct69030. 
+This support can be used to give a single display image on two screen with
+different refresh rates, or entirely different images on the two displays.
+
+Dual refresh rate display can be selected with the "<tt>DualRefresh</tt>"
+option described above. However to use the dual-head support is slightly
+more complex. Firstly, the ct69030 chipset must be installed on a PCI bus. This
+is a driver limitation that might be relaxed in the future. In addition the
+device, screen and layout sections of the "<tt>XF86Config</tt>" must be
+correctly configured. A sample of an incomplete "<tt>XF86Config</tt>" is
+given below
+
+<quote><verb>
+Section "Device"
+    Identifier  "Chips and Technologies - Pipe A"
+    Driver      "chips"
+    BusID       "PCI:0:20:0"
+    Screen      0
+EndSection
+
+Section "Device"
+    Identifier  "Chips and Technologies - Pipe B"
+    Driver      "chips"
+    BusID       "PCI:0:20:0"
+    Screen      1
+EndSection
+
+Section "Screen"
+    Identifier  "Screen 0"
+    Device      "Chips and Technologies - Pipe A"
+    Monitor     "generic LCD"
+
+    SubSection "Display"
+        Depth           16
+        Modes           "1024x768"
+    EndSubsection
+EndSection
+
+Section "Screen"
+    Identifier  "Screen 1"
+    Device      "Chips and Technologies - Pipe B"
+    Monitor     "generic CRT"
+
+    SubSection "Display"
+        Depth           16
+        Modes           "1024x768"
+    EndSubsection
+EndSection
+
+Section "ServerLayout"
+    Identifier  "Main Layout"
+    Screen      "Screen 0"
+    Screen      "Screen 1" RightOf "Screen 0"
+    InputDevice "Mouse1" "CorePointer"
+    InputDevice "Keyboard1" "CoreKeyboard"
+EndSection
+</verb></quote>
+
+The device section must include the PCI BusID. This can be found from the
+log file of a working single-head installation. For instance, the line 
+
+<quote><verb>
+(--) PCI:*(0:20:0) C&amp;T 69030 rev 97, Mem @ 0xed000000/24
 </verb></quote>
 
-The NEC Versa 4080 just needs the "fix_panel_size" option.
+appears for the case above. Additionally, the "<tt>Screen</tt>" option
+must appear in the device section. It should be noted that if a flat 
+panel is used, this it must be allocated to "<tt>Screen 0</tt>".
+
+The server can then be started with the "<tt>+xinerama</tt>" option
+as follows
+
+<quote><verb>
+startx -- +xinerama
+</verb></quote>
+
+For more information, read the Xinerama documentation.
+
+It should be noted that the dual channel display options of the 69030 
+require the use of additional memory bandwidth, as each display channel
+independently accesses the video memory. For this reason, the maximum
+colour depth and resolution that can be supported in a dual channel mode
+will be reduced compared to a single display channel mode. However, as
+the driver does not prevent you from using a mode that will exceed the
+memory bandwidth of the 69030, but a warning like
+
+<quote><verb>
+(WW) Memory bandwidth requirements exceeded by dual-channel
+(WW)    mode. Display might be corrupted!!!
+</verb></quote>
+
+If you see such display corruption, and you have this warning, your choices
+are to reduce the refresh rate, colour depth or resolution, or increase the
+speed of the memory clock with the the "<tt>SetMClk</tt>" option described
+above. Note that increasing the memory clock also has its own problems as
+described above.
+
+<sect> The Full Story on Clock Limitations <p>
+
+There has been much confusion about exactly what the clock limitations
+of the Chips and Technologies chipsets are. Hence I hope that this
+section will clear up the misunderstandings. 
+
+In general there are two factors determining the maximum dotclock.
+There is the limit of the maximum dotclock the video processor can handle, 
+and there is another limitation of the available memory bandwidth. The 
+memory bandwidth is determined by the clock used for the video memory.
+For chipsets incapable of colour depths greater that 8bpp like the 65535,
+the dotclock limit is solely determined by the highest dotclock the video
+processor is capable of handling. So this limit will be either 56MHz or
+68MHz for the 655xx chipsets, depending on what voltage they are driven
+with, or 80MHz for the 64200 WinGine machines.
+
+The 6554x and 64300 WinGine chipsets are capable of colour depths of 16
+or 24bpp. However there is no reliable way of probing the memory clock
+used in these chipsets, and so a conservative limit must be taken for
+the dotclock limit. In this case the driver divides the video processors
+dotclock limitation by the number of bytes per pixel, so that the
+limitations for the various colour depths are
+
+<verb>
+                        8bpp    16bpp   24bpp
+64300                   85      42.5    28.33
+65540/65545 3.3v        56      28      18.67
+65540/65545 5v          68      34      22.67
+65546/65548             80      40      26.67
+</verb>
+
+For a CRT or TFT screen these limitations are conservative and the user
+might safely override them with the "<tt>DacSpeed</tt>" option to some
+extent. However these numbers take no account of the extra bandwidth 
+needed for DSTN screens. 
+
+For the HiQV series of chips, the memory clock can be successfully probed.
+Hence you will see a line like
+
+<verb>
+(--) CHIPS(0): Probed memory clock of  40.090 MHz
+</verb>
+
+in your startx log file. Note that many chips are capable of higher
+memory clocks than actually set by BIOS. You can use the "<tt>SetMClk</tt>"
+option in your XF86Config file to get a higher MClk. However some
+video ram, particularly EDO, might not be fast enough to handle this,
+resulting in drawing errors on the screen. The formula to determine the
+maximum usable dotclock on the HiQV series of chips is
+
+<verb>
+Max dotclock = min(MaxDClk,  0.70  * 8 * MemoryClk / (BytesPerPixel + 
+                (isDSTN == TRUE ? 1 : 0)))
+</verb>
+
+if you chips is a 69030 or 69000 or
+
+<verb>
+Max dotclock = min(MaxDClk,  0.70  * 4 * MemoryClk / (BytesPerPixel + 
+                (isDSTN == TRUE ? 1 : 0)))
+</verb>
+
+
+otherwise. This effectively means that there are two limits on the
+dotclock. One the overall maximum, and another due to the available
+memory bandwidth of the chip.  The 69030 and 69000 have a 64bit memory
+bus and thus transfer 8 bytes every clock thus (hence the 8), while
+the other HiQV chipsets are 32bit and transfer 4 bytes per clock cycle
+(hence the 4). However, after accounting for the RAS/CAS signaling
+only about 70% of the bandwidth is available. The whole thing is
+divided by the bytes per pixel, plus an extra byte if you are using a
+DSTN. The extra byte with DSTN screens is used for the frame
+buffering/acceleration in these screens. So for the various Chips and
+Technologies chips the maximum specifications are
+
+<verb>
+                    Max DClk MHz      Max Mem Clk MHz
+65550 rev A 3.3v          80                38 
+65550 rev A 5v           110                38
+65550 rev B               95                50
+65554                     94.5              55
+65555                    110                55
+68554                    110                55
+69000                    135                83
+69030                    170               100
+</verb>
+
+Note that all of the chips except the 65550 rev A are 3.3v only. Which
+is the reason for the drop in the dot clock. Now the maximum memory clock
+is just the maximum supported by the video processor, not the maximum
+supported by the video memory. So the value actually used for the memory
+clock might be significantly less than this maximum value. But assuming your
+memory clock is programmed to these maximum values the various maximum dot
+clocks for the chips are
+
+<verb>
+                        ------CRT/TFT-------    --------DSTN--------
+                        8bpp    16bpp   24bpp   8bpp    16bpp   24bpp
+65550 rev A 3.3v        80      53.2    35.47   53.2    35.47   26.6
+65550 rev A 5v          106.2   53.2    35.47   53.2    35.47   26.6
+65550 rev B             95      70      46.67   70      46.67   35.0
+65554                   94.5    77      51.33   77      51.33   38.5
+65555                   110     77      51.33   77      51.33   38.5
+68554                   110     77      51.33   77      51.33   38.5
+69000                   135    135     135     135     135     116.2
+69030                   170    170     170     170     170     140
+</verb>
+
+If you exceed the maximum set by the memory clock, you'll get corruption
+on the screen during graphics operations, as you will be starving the
+HW BitBlt engine of clock cycles. If you are driving the video memory
+too fast (too high a MemClk) you'll get pixel corruption as the data
+actually written to the video memory is corrupted by driving the memory
+too fast. You can probably get away with exceeding the Max DClk at 8bpp
+on TFT's or CRT's by up to 10% or so without problems, it will just generate
+more heat, since the 8bpp clocks aren't limited by the available memory
+bandwidth.
+
+If you find you truly can't achieve the mode you are after with the default
+clock limitations, look at the options "<tt>DacSpeed</tt>" and 
+"<tt>SetMClk</tt>". Using these should give you all the capabilities
+you'll need in the server to get a particular mode to work. However use
+caution with these options, because there is no guarantee that driving the
+video processor beyond it capabilities won't cause damage.
 
 <sect> Troubleshooting <p>
 
@@ -421,13 +836,14 @@ The NEC Versa 4080 just needs the "fix_panel_size" option.
 	the cursor to be redrawn as a white box, when the mode is changed.
 	This can be fixed by moving the cursor to a different region,
 	switching to the console and back again, or if it is too annoying
-	the H/W cursor can be disabled with the "<tt>sw_cursor</tt>" option.
+	the H/W cursor can be disabled by removing the "<tt>HWcursor</tt>"
+	option.
 <tag> The cursor hot-spot isn't at the same point as the cursor</tag>
  	With modes on the 6555x machines that are stretched to fill the
 	flat panel, the H/W cursor is not correspondingly stretched. This
 	is a small and long-standing bug in the current server. You can
-	avoid this by either using the "<tt>no_stretch</tt>" or
-	<tt>sw_cursor</tt>" options.
+	avoid this by either using the "<tt>NoStretch</tt>" option or
+	removing the <tt>HWcursor</tt>" option.
 <tag> The lower part of the screen is corrupted</tag>
 	Many DSTN screens use the top of video ram to implement a frame
 	accelerator. This reduces the amount of video ram available to
@@ -445,7 +861,7 @@ The NEC Versa 4080 just needs the "fix_panel_size" option.
         and frequency combination. For LCD modes, it is possible that your
 	LCD panel requires different panel timings at the text console than
 	with a graphics mode. In this case you will need the
-	"<tt>use_modeline</tt>" and perhaps also the "<tt>fix_panel_size</tt>"
+	"<tt>UseModeline</tt>" and perhaps also the "<tt>FixPanelSize</tt>"
 	options to reprogram the LCD panel timings to sensible values.
 <tag> `Wavy' screen.</tag>
         Horizontal waving or jittering of the whole screen, continuously
@@ -455,32 +871,34 @@ The NEC Versa 4080 just needs the "fix_panel_size" option.
 	For CRT's you can also try to tweak the mode timings; try increasing
         the second horizontal value somewhat.
 <tag> Crash or hang after start-up (probably with a black screen).</tag>
-        Try the "<tt>noaccel</tt>" or "<tt>no_bitblt</tt>" options. Check
-        that the BIOS settings are OK; in particular, disable caching of
-        0xa0000-0xaffff. Disabling hidden DRAM refresh may also help.
+        Try the "<tt>NoAccel</tt>" or one of the XAA acceleration options
+	discussed above. Check that the BIOS settings are OK; in particular,
+	disable caching of 0xa0000-0xaffff. Disabling hidden DRAM refresh
+	may also help.
 <tag> Hang as the first text is appearing on the screen on SVR4 machines.</tag>
         This problem has been reported under UnixWare 1.x, but not tracked
         down. It doesn't occur under UnixWare 2.x and only occurs on the
         HiQV series of chips. It might affect some other SVR4 operating
         systems as well. The workaround is to turn off the use of CPU to
-        screen acceleration with the "<tt>xaa_no_color_exp</tt>" option.
+        screen acceleration with the
+	"<tt>XaaNoCPUToScreenColorExapndFill</tt>" option.
 <tag> Crash, hang, or trash on the screen after a graphics operation.</tag>
         This may be related to a bug in one of the accelerated
         functions, or a problem with the BitBLT engine. Try the
-        "<tt>noaccel</tt>" or "<tt>no_bitblt</tt>" options. Also check the
-	BIOS settings. It is also possible that with a high dot clock and
-	depth on a large screen there is very little bandwidth left for using
-	the BitBLT engine. Try reducing the clock.
+        "<tt>NoAccel</tt>" or one of the XAA acceleration options
+	discussed above. Also check the BIOS settings. It is also possible
+	that with a high dot clock and depth on a large screen there is
+	very little bandwidth left for using the BitBLT engine. Try
+	reducing the clock.
 <tag> Chipset is not detected.</tag>
         Try forcing the chipset to a type that is most similar to what
         you have.
 <tag>The screen is blank when starting X</tag>
-	One possible cause of this problem is if the kernel has been 
-	compiled with the "APM_DISPLAY_BLANK" option. It appears that
-	this option doesn't work as specified and can cause the Xserver
-	to blank when starting X. In all cases the kernel should be compiled
-	without this option. If the problem remains a CRT/LCD or switch to
-	and from the virtual console will often fix it.
+	One possible cause of this problem with older linux kernels is that
+	the "APM_DISPLAY_BLANK" option didn't work correct. Either upgrade
+	your kernel or rebuild it with the "APM_DISPLAY_BLANK" option
+	disabled. If the problem remains, or you aren't using linux, a
+	CRT/LCD or switch to and from the virtual console will often fix it.
 <tag> Textmode is not properly restored</tag>
         This has been reported on some configurations. Many laptops
 	use the programmable clock of the 6554x chips at the console.
@@ -491,16 +909,16 @@ The NEC Versa 4080 just needs the "fix_panel_size" option.
 	problems. Usually this is fixed by switching between the LCD
 	and CRT. Alternatively the user can use the "<tt>TextClockFreq</tt>"
 	option described above to select a different clock for the
-	text console. Another possible cause of this problem is if the kernel
-	is compiled with the "APM_DISPLAY_BLANK" option. As mentioned
-	before, this option should be disabled.
+	text console. Another possible cause of this problem is if 
+	linux kernels are compiled with the "APM_DISPLAY_BLANK" option.
+	As mentioned before, try disabling this option.
 <tag> I can't display 640x480 on my 800x600 LCD</tag>
 	The problem here is that the flat panel needs timings that
 	are related to the panel size, and not the mode size. There is
 	no facility in the current Xservers to specify these values,
 	and so the server attempts to read the panel size from the
-	chip. If the user has used the "<tt>use_modeline</tt>" or
-	"<tt>fix_panel_size</tt>" options the panel timings are derived
+	chip. If the user has used the "<tt>UseModeline</tt>" or
+	"<tt>FixPanelSize</tt>" options the panel timings are derived
 	from the mode, which can be different than the panel size. Try
 	deleting theses options	from XF86Config or using an LCD/CRT switch.
 <tag> I can't get a 320x240 mode to occupy the whole 640x480 LCD</tag>
@@ -508,7 +926,7 @@ The NEC Versa 4080 just needs the "fix_panel_size" option.
 	doubled vertically. The lower half of the screen is not accessible.
 	The servers solution to this problem is not to do doubling vertically.
 	Which results in the 320x240 mode only expanded to 640x360. If this
-	is a problem, a work around is to use the "<tt>sw_cursor</tt>"
+	is a problem, a work around is to remove the "<tt>HWcursor</tt>"
 	option. The server will then allow the mode to occupy the whole
 	640x480 LCD.
 <tag> After a suspend/resume my screen is messed up</tag>
@@ -522,36 +940,81 @@ The NEC Versa 4080 just needs the "fix_panel_size" option.
 	shouldn't affect higher depths, and is fixable with a switch to
 	the virtual console and back.
 <tag> The right hand edge of the mode isn't visible on the LCD</tag>
-	This is usually due to a problem with the "<tt>lcd-center</tt>"
+	This is usually due to a problem with the "<tt>LcdCenter</tt>"
 	option. If this option is removed form XF86Config, then the problem
 	might go away. Alternatively the manufacturer could have incorrectly
 	programmed the panel size in the EGA console mode. The
-	"<tt>fix_panel_size</tt>" can be used to force the modeline values into
+	"<tt>FixPanelSize</tt>" can be used to force the modeline values into
 	the panel size registers. Two machines that are known to have this
 	problem are the "<tt>HP OmniBook 5000</tt>" and the "<tt>NEC  Versa
 	4080</tt>".
 <tag> My TFT screen has a reddish tint in 24bpp mode</tag>
-	The server assumes that the TFT bus width is 24bits. If this is not
-	true then the screen will appear to have a reddish tint. This can
-	be fixed by using the "<tt>use_18bit_bus</tt>" option. Note that
-	the reverse is also true. If the "<tt>use_18bit_bus</tt>" is used
-	and the TFT bus width is 24bpp, then the screen will appear reddish.
-	Note that this option only has an effect on TFT screens. 
-<tag> I can't start X-windows with 16 or 24bpp</tag>
-	Firstly, is your machine capable of 16/24bpp with the mode
+	For 6554x chipsets the server assumes that the TFT bus width is
+	24bits. If this is not true then the screen will appear to have a
+	reddish tint. This can be fixed by using the "<tt>18BitBus</tt>"
+	option. Note that the reverse is also true. If the "<tt>18BitBus</tt>"
+	is used and the TFT bus width is 24bpp, then the screen will appear
+	reddish. Note that this option only has an effect on TFT screens. 
+<tag> SuperProbe won't work with my chipset</tag>
+	At least one non-PCI bus system with a HiQV chipset has been found to
+	require the "<tt>-no_bios</tt>" option for SuperProbe to correctly
+	detect the chipset with the factory default BIOS settings. The server
+	itself can correctly detect the chip in the same situation.
+<tag> My 690xx machine lockups when using the "<tt>MMIO</tt>" option</tag>
+	The 690xx MMIO mode has been implemented entirely from the manual
+	as I don't have the hardware to test it on. At this point no testing
+	has been done and it is entirely possible that the "<tt>MMIO</tt>
+	option will lockup your machine. You have been warned! However if
+	you do try this option and are willing to debug it, I'd like to hear
+	from you.
+<tag> My TrueColor windows are corrupted when using the "<tt>Overlay</tt>" option </tag>
+	Chips and Technologies specify that the memory clock used with the
+	multimedia engine running should be lower than that used without. As
+	use of the HiQV chipsets multimedia engine was supposed to be for
+	things like zoomed video overlays, its use was supposed to be
+	occasional and so most machines have their memory clock set to a value
+	that is too high for use with the "<tt>Overlay</tt>" option. So with 
+	the "<tt>Overlay</tt>" option, using the "<tt>SetMClk</tt>" option to
+	reduce the speed of the memory clock is recommended.
+<tag> The mpeg video playing with the XVideo extension has corrupted colours </tag>
+	The XVideo extension has only recently been added to the chips driver.
+	Some YUV to RGB colour have been noted at 15 and 16 bit colour depths.
+	However, 8 and 24 bit colour depths seem to work fine.
+<tag> My ct69030 machine locks up when starting XFree86</tag>
+	The ct69030 chipset introduced a new dual channel architecture. In its
+	current form, XFree86 can not take advantage of this second display
+	channel. In fact if the video BIOS on the machine sets the ct69030
+	to a dual channel mode by default, XFree86 will lockup hard at this
+	point. The solution is to use the BIOS setup to change to a single
+	display channel mode, ensuring that both the IOSS and MSS registers
+	are set to a single channel mode. Work is underway to fix this.
+<tag> I can't start X-windows with 16, 24 or 32bpp</tag>
+	Firstly, is your machine capable of 16/24/32bpp with the mode
 	specified. Many LCD displays are incapable of using a 24bpp 
-	mode. Also you need at least a 65540 to use 16/24bpp, and the
-	amount of memory used by the mode will be doubled/tripled. The
-	correct options to start the server with these modes are
+	mode. Also you need at least a 65540 to use 16/24bpp and at least a
+	65550 for 32bpp. The amount of memory used by the mode will be
+	doubled/tripled/quadrupled. The correct options to start the server
+	with these modes are
+
 <verb>
-	  startx -- -bpp 16               5-6-5 RGB ('64K color', XGA)
-	  startx -- -bpp 16 -weight 555   5-5-5 RGB ('Hicolor')
-	  startx -- -bpp 24               8-8-8 RGB truecolor
+	  startx -- -depth 16             5-6-5 RGB ('64K color', XGA)
+	  startx -- -depth 15             5-5-5 RGB ('Hicolor')
+	  startx -- -depth 24             8-8-8 RGB truecolor
 </verb>
-	Note that there is currently no "<tt>-bpp 32</tt>" mode in the Xserver,
-	although the 65550 is capable of this.
-</descrip>
+	or with the HiQV series of chips you might try
+<verb>
+	  startx -- -depth 24 -fbbpp 32   8-8-8 RGB truecolor
+</verb>
+	however as XFree86 version &relvers; allows 32bpp pixmaps to be
+	used with framebuffers operating in 24bpp, this mode of operating
+	will cost performance for no gain in functionality.
 
+	Note that the "<tt>-bpp</tt>" option has been removed
+	and replaced with a "<tt>-depth</tt>" and "<tt>-fbbpp</tt>"
+	option because of the confusion between the depth and number of
+        bits per pixel used to represent to framebuffer and the pixmaps
+        in the screens memory.
+</descrip>
 
   A general problem with the server that can manifested in many way such
   as drawing errors, wavy screens, etc is related to the programmable
@@ -562,23 +1025,26 @@ The NEC Versa 4080 just needs the "fix_panel_size" option.
   the clock value slightly. For example 65.00MHz might be unstable while
   65.10MHz is not. So for unexplained problems not addressed above, please
   try to alter the clock you are using slightly, say in steps of 0.05MHz
-  and see if the problem goes away.
+  and see if the problem goes away. Alternatively, using the
+  "<tt>CRTClkIndx</tt>" or "<tt>FPClkIndx</tt>" option with HiQV chips might
+  also help.
 
-  For other screen drawing related problems, try the "<tt>noaccel</tt>" or
-  "<tt>no_bitblt</tt>" options. A useful trick for all laptop computers is to
-  switch between LCD/CRT (usually with something like Fn-F5), if the
-  screen is having problems.
+
+  For other screen drawing related problems, try the "<tt>NoAccel</tt>" or
+  one of the XAA acceleration options discussed above. A useful trick for
+  all laptop computers is to switch between LCD/CRT (usually with something
+  like Fn-F5), if the screen is having problems.
 
   If you are having driver-related problems that are not addressed by this
   document, or if you have found bugs in accelerated functions, you can
   try contacting the XFree86 team (the current driver maintainer can be
-  reached at <it>dbateman@eng.uts.edu.au</it> or 
-  <it>Egbert.Eich@Physik.TH-Darmstadt.DE)</it>,
+  reached at <email>dbateman@club-internet.fr</email> or 
+  <email>eich@xfree86.org</email>),
   or post in the Usenet newsgroup "<it>comp.windows.x.i386unix</it>".
 
 <sect> Disclaimer <p>
 
-Xfree, allows the user to do damage to their hardware with software.
+XFree86, allows the user to do damage to their hardware with software.
 Although the authors of this software have tried to prevent this, they
 disclaim all responsibility for any damage caused by the software. Use
 caution, if you think the Xserver is frying your screen, TURN THE COMPUTER
@@ -610,10 +1076,6 @@ software.
 </itemize>
 
 We also thank the many people on the net who have contributed by reporting
-bugs and extensively testing this server before its inclusion in XFree 3.2
-
-<verb>
-$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/chips.sgml,v 3.12.2.7 1998/01/31 14:23:27 hohndel Exp $
-</verb>
+bugs and extensively testing this server.
 
 </article>