R6.6 is the Xorg base-lineXORG-MAIN

1 files changed, 619 insertions, 0 deletions

diff --git a/README.sgml b/README.sgml
new file mode 100644
index 0000000..2bce190
--- /dev/null
+++ b/README.sgml
@@ -0,0 +1,619 @@
+<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN">
+ 
+<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
+
+<!-- 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 
+
+<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
+</itemize>
+
+Most of the Chips and Technologies chipsets are supported by this driver
+to some degree.
+
+<sect> Supported Chips <p>
+<descrip>
+<tag>ct65520</tag>
+	(Max Ram: 1Mb, Max Dclk: 68MHz@5V)
+<tag>ct65525</tag>
+        This chip is basically identical to the 65530. It has the same
+	ID and is identified as a 65530 when probed. See ct65530 for
+	details.
+<tag>ct65530</tag>
+	This is a very similar chip to the 65520. However it additionally
+	has the ability for mixed 5V and 3.3V operation and linear addressing
+	of the video memory.
+	(Max Ram: 1Mb, Max Dclk: 56MHz@3.3V, 68MHz@5V)
+<tag>ct65535</tag>
+	This is the first chip of the ct655xx series to support fully
+	programmable clocks. Otherwise it has the the same properties
+	as the 65530.
+<tag>ct65540</tag>
+	This is the first version of the of the ct655xx that was capable
+	of supporting Hi-Color and True-Color. It also includes a fully
+	programmable dot clock and supports all types of flat panels.
+	(Max Ram: 1Mb, Max Dclk: 56MHz@3.3V, 68MHz@5V)
+<tag>ct65545</tag>
+	The chip is very similar to the 65540, with the addition of H/W
+	cursor, pop-menu acceleration, BitBLT and support of PCI Buses.
+	PCI version also allow all the BitBLT and H/W cursor registers
+	to be memory mapped 2Mb above the Base Address.
+	(Max Ram: 1Mb, Max Dclk: 56MHz@3.3V,68MHz@5V)
+<tag>ct65546</tag>
+	This chip is specially manufactured for Toshiba, and so documentation
+	is not widely available. It is believed that this is really just a
+	65545 with a higher maximum dot-clock of 80MHz.
+	(Max Ram: 1Mb?, Max Dclk: 80MHz?)
+<tag>ct65548</tag>
+	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)
+<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
+	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
+	configurations. 
+	(Max Ram: 2Mb, Max Dclk: 80MHz@3.3V,100MHz@5V)
+<tag>ct65554</tag>
+	This chip is similar to the 65550 but has a 64bit memory bus as 
+	opposed to a 32bit bus. It also has higher limits on the maximum
+	memory and pixel clocks
+	(Max Ram: 4Mb, Max Dclk: 100MHz@3.3V)
+<tag>ct65555</tag>
+	Similar to the 65554 but has yet higher maximum memory and pixel
+	clocks. It also includes a new DSTN dithering scheme that improves
+	the performance of DSTN screens.
+	(Max Ram: 4Mb, Max Dclk: 110MHz@3.3V)
+<tag>ct68554</tag>
+	Similar to the 65555 but also incorporates "PanelLink" drivers. This
+	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)
+</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).
+
+<descrip>
+<tag>
+Option &dquot;noaccel&dquot;
+</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)
+</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)
+</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.
+<tag>
+MemBase 0x03b00000 (or a different address)
+</tag>
+        This sets the physical memory base address of the linear
+        framebuffer. Typically this is probed correctly, but if
+	you believe it to be mis-probed, this option might help.
+	Also for non PCI machines specifying this force the linear base
+	address to be this value, reprogramming the video processor
+	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)
+</tag>
+        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;
+</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;
+</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
+	default behaviour of the server is to use the panel timings already
+	installed in the chip. The user can force the panel timings to be
+	recalculated from the modeline with this option. However the panel
+	size will still be probed.
+<tag>
+Option &dquot;fix_panel_size&dquot;
+</tag>
+	For some machines the LCD panel size is incorrectly probed from
+	the registers. This option forces the LCD panel size to be
+	overridden by the modeline display sizes. This will prevent the
+	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
+	the modeline values.
+<tag>
+Option &dquot;no_stretch&dquot;
+</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;
+</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
+	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)
+</tag>
+	On chips 65535 and later, 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,
+	31.000 and 36.000MHz. The current programmable clock will be
+	given as the last clock in the list. On a cold-booted system this
+	might be the appropriate value to use at the text console (see the 
+	"<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.
+<tag>
+Option &dquot;use_vclk1&dquot; (Chips 65550 and later)
+</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.
+<tag>
+TextClockFreq 25.175
+</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.
+<tag>
+Option &dquot;mmio&dquot;
+</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.
+<tag>
+Option &dquot;suspend_hack&dquot;
+</tag>
+	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;.
+<tag>
+Option &dquot;use_18bit_bus&dquot;  (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)
+</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)
+</tag>
+	Composite sync on green. Possibly useful if you wish to use an
+	old workstation monitor. The 65550/54 internal RAMDAC's support
+	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
+	by the manufacturer. This might make certain modes impossible
+	to obtain with a reasonable refresh rate. Using this option the
+	user can override the maximum dot-clock and specify any value they
+	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)
+</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.
+</descrip>
+
+<sect> Modelines <p>
+
+When constructing a modeline for use with the Chips and Technologies
+driver you'll needed to considered several points
+
+<descrip>
+<tag> * Virtual Screen Size </tag>
+		It is the virtual screen size that determines the amount
+	of memory used by a mode. So if you have a virtual screen size
+	set to 1024x768 using a 800x600 at 8bpp, you use 768kB for the
+	mode. Further to this some of the XAA acceleration requires that
+	the display pitch is a multiple of 64 pixels. So the driver will
+	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
+	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
+	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.
+<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
+	frame buffer, or incorporating the framebuffer at the top of video
+	ram depending on the particular implementation. The Xserver assumes
+	that the framebuffer, if used, will be at the top of video ram.
+	The amount of ram required for the framebuffer will vary depending
+	on the size of the screen, and will reduce the amount of video
+	ram available to the modes. Typical values for the size of the
+	framebuffer will be 61440 bytes (640x480 panel), 96000 bytes
+	(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
+	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> * 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
+	switch might mess up the screen. This is a problem with the video
+	BIOS not knowing about all the funny modes that might be selected.
+<tag> * Dot Clock </tag>
+		For LCD screens, the lowest clock that gives acceptable
+	contrast and flicker is usually the best one. This also gives
+	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.
+</descrip>
+
+The driver is capable of driving both a CRT and a flat panel
+display. In fact the timing for the flat panel are dependent on the
+specification of the panel itself and are independent of the particular
+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.
+
+<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"
+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"
+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)
+</verb></quote>
+
+The NEC Versa 4080 just needs the "fix_panel_size" option.
+
+<sect> Troubleshooting <p>
+
+<descrip>
+<tag> The cursor appears as a white box, after switching modes</tag>
+	There is a known bug in the H/W cursor, that sometimes causes
+	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.
+<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.
+<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
+	the modes. The server doesn't prevent the user from specifying
+	a mode that will use this memory, it prints a warning on the console.
+	The effect of this problem will be that the lower part of the screen
+	will reside in the same memory as the frame accelerator and will
+	therefore be corrupt. Try reducing the amount of memory consumed
+	by the mode.
+<tag> There is a video signal, but the screen doesn't sync.</tag>
+        You are using a mode that your screen cannot handle. If it is a
+        non-standard mode, maybe you need to tweak the timings a bit. If
+        it is a standard mode and frequency that your screen should be
+        able to handle, try to find different timings for a similar mode
+        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>"
+	options to reprogram the LCD panel timings to sensible values.
+<tag> `Wavy' screen.</tag>
+        Horizontal waving or jittering of the whole screen, continuously
+        (independent from drawing operations).  You are probably using a
+        dot clock that is too high (or too low); it is also possible that
+	there is interference with a close MCLK. Try a lower dot clock.
+	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.
+<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.
+<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.
+<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.
+<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.
+	It is not always possible to find out the setting that is
+	used for this clock if BIOS has written the MClk after the
+	VClk. Hence the server assumes a 25.175MHz clock at the
+	console. This is correct for most modes, but can cause some
+	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.
+<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
+	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>
+	There is a bug in the 6554x's H/W cursor for modes that are
+	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>"
+	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>
+	During a suspend/resume, the BIOS controls what is read and 
+	written back to the registers. If the screen is using a mode
+	that BIOS doesn't know about, then there is no guarantee that
+	it will be resumed correctly. For this reason a mode that is
+	as close to VESA like as possible should be selected. It is also
+	possible that the VGA palette can be affected by a suspend/resume.
+	Using an 8bpp, the colour will then be displayed incorrectly. This
+	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>"
+	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
+	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
+	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
+<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
+</verb>
+	Note that there is currently no "<tt>-bpp 32</tt>" mode in the Xserver,
+	although the 65550 is capable of this.
+</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
+  clock. Many potential programmable clock register setting are unstable.
+  However luckily there are many different clock register setting that
+  can give the same or very similar clocks. The clock code can be fooled
+  into giving a different and perhaps more stable clock by simply changing
+  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.
+
+  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.
+
+  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>,
+  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.
+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
+OFF!!
+
+<sect> Acknowledgement <p>
+
+The authors of this software wish to acknowledge the support
+supplied by Chips and Technologies during the development of this
+software.
+
+<sect> Authors <p>
+
+<tt>Major Contributors</tt> (In no particular order)
+<itemize>
+<item>Nozomi Ytow
+<item>Egbert Eich
+<item>David Bateman
+<item>Xavier Ducoin
+</itemize>
+
+<tt>Contributors</tt> (In no particular order)
+<itemize>
+<item>Ken Raeburn
+<item>Shigehiro Nomura
+<item>Marc de Courville
+<item>Adam Sulmicki
+<item>Jens Maurer
+</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>
+
+</article>