merge XFree86 4.3.0.1 to -CURRENT

1 files changed, 84 insertions, 70 deletions

diff --git a/README.sgml b/README.sgml
index 0fa0032..58d11ce 100644
--- a/README.sgml
+++ b/README.sgml
@@ -1,77 +1,93 @@
-<!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 SiS Users
-<author> Xavier Ducoin (<it>xavier@rd.lectra.fr</it>)
-<date> 27 February 1998
+<title>Information for SiS Users
+<author>Juanjo Santamarta (<email>santamarta@ctv.es</email>)
+<date>5 March 2000
+
+<ident>
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/SiS.sgml,v 3.7 2000/03/06 22:59:24 dawes Exp $
+</ident>
 
 <!-- Table of contents -->
 <toc>
 
 <sect> Introduction <p>
 
-This driver was primarily written for the SiS86c201.  It also works
-on the 202 and the 205 chips.  Support for other SiS products is
-not available in XFree86 release 3.3.2.  Drivers for the 5597/8 are
-currently under development and should be available in the next release.
+This driver was primarily written for the SiS6326 and SiS530 by Alan Hourihane.
+It also works on 5597/5598 chips, and probably on older SiS862X5 family.
 
-The driver supports many advanced features.  These include:
+The driver supports :
 <itemize>
   <item>Linear Addressing
   <item>8/15/16/24 bits per pixel
   <item>Fully programmable clocks are supported
-  <item>H/W cursor support
-  <item>BitBLT acceleration of many operations
+  <item>H/W acceleration and cursor support
   <item>XAA support (XFree86 Acceleration Architecture)
 </itemize>
 
+<!-- this is incorrect
 <sect> Supported chips <p>
 
-<descrip>
-<tag>SiS 86c201</tag>
-	(External hardware clock)
-<tag>SiS 86c202, SiS 86c205</tag>
-	(Internal clock synthesizer)
-</descrip>
+<quote>
+SiS 530, SiS 86c2x5, SiS 5597/5598, SiS 6326
+</quote>
+
+This driver needs linear framebuffer support in the card. Because this 
+SiS 86C201 and 86C202 based cards don't work with this driver.
 
 Color expansion is not supported by the engine in 16M-color graphic mode.
+-->
 
 <sect> XF86Config Options <p>
 
-The following options are of particular interest for the SiS 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 for the SiS
+driver. Each of them must be specified in the Device section of the
+XF86Config file for this card.
 
 <descrip>
-<tag>Option &dquot;noaccel&dquot;</tag>
-	By default the XAA (XFree86 Acceleration Architecture) is used.
-	This option will disable the use of the XAA and will enable the old
-	BitBlt acceleration operations. (see below).
-<tag>Option &dquot;hw_clocks&dquot;</tag>
-	On chips 86c202 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 of using this option (manufacturer
-	dependent).
-<tag>Option &dquot;sw_cursor&dquot, &dquot;hw_cursor&dquot;</tag>
+<tag>Option "SetMclk"</tag>
+        This option lets you to modify the memory clocking of your card.
+    (only for 5597 and 6326) Modifying the memory timings can destroy the 
+	device, but usually the only ill effects of overclocking is to 
+	have some noise an drawing errors, but BE CAREFUL. Usually a little 
+	increment can improve the drawing speed, and allows also higher dotclocks. 
+	The server reports default memclock on starting messages, so take it
+	as a base. Units are in KHZ.
+<tag>Option "DacSpeed"</tag>
+        This option lets you to modify the maximum allowed dotclock).	
+<tag>Option "sw_cursor", "hw_cursor"</tag>
 	The default is for using the hardware cursor.
-<tag>Option &dquot;no_linear&dquot;</tag>
-	By default linear addressing is used on all 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>Option &dquot;no_bitblt&dquot;</tag>
-	This option will disable the use of all the BitBLT engine.
-	It is useful for problems related to acceleration problems.
-	In general this will result in a reduced performance.
-<tag>Option &dquot;no_imageblt&dquot;</tag>
-	It is useful for problems related to image writing, and possible
-	stipple acceleration problems. In general this will result in a reduced
-	performance.
+<!-- Which of these chips is even supported? -->
+<tag>Option "Turboqueue"</tag>
+	5597/8 and 6326 have the option to extend the engine command queue on
+	VRAM. With extended queue length, the driver only checks queue status 
+	on some color-expansion commands. This gives some performance improvement, 
+	but is possible to lose some commands, corrupting screen output. As the 
+	size of extended command queue is 16-32K, the probability is very low, but
+	exists. The performance gain observed is around 8-10%. Currently, using
+	this option will occasionally freeze the acceleration engine, causing 
+	weird image display.
+<tag>Option "FastVram"</tag>
+        Enables 1 cycle memory access. Try it. Increased memory bandwidth reduces
+	the possibility of glitches and noise on high resolution modes. 
+
+<tag>Option "PciRetry"</tag>
+
+<tag>Option "NoAccel"</tag>
+        Disables various hardware accelerations.
+
+<tag>VideoRAM size</tag> The SiS chips can only directly address 4096K
+        bytes of video RAM.  Some video cards using these chips are
+        shipped with additional video RAM.  The videoRAM must be
+        explicitly limited to 4096 for those cards.  Attempting to use
+        the additional RAM leads to a variety of scrambled screen
+        artifacts.
+
 </descrip>
 
 
@@ -83,35 +99,33 @@ driver you'll need to consider several points:
   <item>H/W Acceleration.  The H/W cursor, and fill operations
 	currently allocate memory of the video ram for there own use.
 	If this is not available these functions will automatically be
-	disabled.
-  <item>Dot Clock
+	disabled. Also, Turboqueue allocate 32k of Vram. 
+  <item>Dot Clock. SiS documents the following video modes to work with 
+        6326. The max dot clock allowable for your 6326 based board depends 
+	also on the memory installed on it. Option FastVram can be needed 
+	for high dot clocks to work. Of course, the memory installed must
+	allow 1 cycle R/W. 
+	<p>
+        SiS recommended video modes for 6326: 
+	<descrip>
+         <tag>640x480 :</tag>4, 8, 15, 16, 24 bpp at 85Hz Non-interlaced
+         <tag>800x600 :</tag>4, 8, 15, 16, 24 bpp at 85Hz Non-interlaced
+         <tag>1024x768 :</tag>4, 8, 15, 16, 24 bpp at 85Hz Non-interlaced
+         <tag>1280x1024 :</tag>4, 8, 15, 16, 24 bpp at 75Hz Non-interlaced
+         <tag>1600x1200 :</tag>4, 8  bpp at 65Hz Non-interlaced
+	</descrip>
 </itemize>
 
 <sect> Troubleshooting <p>
 
-With intensive generation there is a snow phenomenon on the screen.
-Can't remove it even if I used the fifo low/high water mark dumped
-from W95.
+<!-- don't have XF86Setup for 4.0
+The generic VGA driver don't work with 6326, so XF86Setup can't be used
+for this card. Please use xf86config instead.
+-->
 
+Some video modes with high dot-clocks don't work at all, resulting on black 
+screen. Lowering dotclock in that case could solve the problem. 
 
-With intensive generation in 1024x768 65 Mhz sometimes some points (rubbish,
-fuzz... hard to explain) appear in memory, like memory
-violations or memory corruption.
-It looks like an electronic refresh not well done or VClk too near
-the MClk.
-I use the default Mclk set by BIOS.
-It is hard to reproduce this problem (It can take one hour,
-two or more).
-I can't reproduce this problem in 1024x768 75 MHz or 1280x1024 110 MHz
-or 1152x900 95 MHz.
-
-<verb>
-$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/SiS.sgml,v 3.3.2.1 1998/02/27 02:45:24 dawes Exp $
-
-
-
-$Xorg: SiS.sgml,v 1.3 2000/08/17 19:51:05 cpqbld Exp $
-</verb>
+Document based on 3.3 version written by Xavier Ducoin.
 
 </article>
-