xserver-xorg-video-chips: Changes to 'upstream-experimental'
.gitignore | 69 +++
COPYING | 157 +++++++
ChangeLog | 84 ----
Makefile.am | 14
README | 286 +++++++-------
README.sgml | 1084 -------------------------------------------------------
configure.ac | 50 +-
man/.gitignore | 2
man/Makefile.am | 59 +-
man/chips.man | 2
src/.gitignore | 6
src/ct_BltHiQV.h | 2
src/ct_driver.c | 226 ++++-------
src/ct_shadow.c | 1
src/ct_video.c | 1
util/.gitignore | 5
16 files changed, 500 insertions(+), 1548 deletions(-)
New commits:
commit 5665714d0de33571d97def69d00d7bfa9e0d5b8a
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date: Fri Jul 23 11:33:37 2010 -0700
xf86-video-chips 1.2.3
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
diff --git a/configure.ac b/configure.ac
index e4fdd5a..bfc0059 100644
--- a/configure.ac
+++ b/configure.ac
@@ -23,7 +23,7 @@
# Initialize Autoconf
AC_PREREQ([2.60])
AC_INIT([xf86-video-chips],
- [1.2.2],
+ [1.2.3],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg],
[xf86-video-chips])
AC_CONFIG_SRCDIR([Makefile.am])
commit a9c2df54a42e168d12c4e342ae9d9cffb23d4313
Author: Gaetan Nadon <memsize@videotron.ca>
Date: Wed Jul 21 16:49:04 2010 -0400
config: add comments for main statements
diff --git a/configure.ac b/configure.ac
index 01e181a..e4fdd5a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -20,18 +20,18 @@
#
# Process this file with autoconf to produce a configure script
+# Initialize Autoconf
AC_PREREQ([2.60])
AC_INIT([xf86-video-chips],
[1.2.2],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg],
[xf86-video-chips])
-
AC_CONFIG_SRCDIR([Makefile.am])
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_AUX_DIR(.)
+# Initialize Automake
AM_INIT_AUTOMAKE([foreign dist-bzip2])
-
AM_MAINTAINER_MODE
# Require X.Org macros 1.8 or later for MAN_SUBSTS set by XORG_MANPAGE_SECTIONS
@@ -40,25 +40,26 @@ m4_ifndef([XORG_MACROS_VERSION],
XORG_MACROS_VERSION(1.8)
XORG_DEFAULT_OPTIONS
-# Checks for programs.
+# Initialize libtool
AC_DISABLE_STATIC
AC_PROG_LIBTOOL
AH_TOP([#include "xorg-server.h"])
+# Define a configure option for an alternate module directory
AC_ARG_WITH(xorg-module-dir,
AS_HELP_STRING([--with-xorg-module-dir=DIR],
[Default xorg module directory [[default=$libdir/xorg/modules]]]),
[moduledir="$withval"],
[moduledir="$libdir/xorg/modules"])
-# Checks for extensions
+# Store the list of server defined optional extensions in REQUIRED_MODULES
XORG_DRIVER_CHECK_EXT(RANDR, randrproto)
XORG_DRIVER_CHECK_EXT(RENDER, renderproto)
XORG_DRIVER_CHECK_EXT(XV, videoproto)
XORG_DRIVER_CHECK_EXT(DPMSExtension, xextproto)
-# Checks for pkg-config packages
+# Obtain compiler/linker options for the driver dependencies
PKG_CHECK_MODULES(XORG, [xorg-server >= 1.0.99.901 xproto fontsproto $REQUIRED_MODULES])
# Checks for libraries.
commit 0e225c6674b61928bd442959ef1c5f67b8ea6271
Author: Gaetan Nadon <memsize@videotron.ca>
Date: Wed Jul 21 16:07:00 2010 -0400
config: replace deprecated use of AC_OUTPUT with AC_CONFIG_FILES
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
diff --git a/configure.ac b/configure.ac
index c20a6b9..01e181a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -104,9 +104,10 @@ AC_SUBST([moduledir])
DRIVER_NAME=chips
AC_SUBST([DRIVER_NAME])
-AC_OUTPUT([
- Makefile
- src/Makefile
- man/Makefile
- util/Makefile
+AC_CONFIG_FILES([
+ Makefile
+ src/Makefile
+ man/Makefile
+ util/Makefile
])
+AC_OUTPUT
commit 02d4b3da8ddb8cb94c3ddba2a436b6b2c6e90a5a
Author: Gaetan Nadon <memsize@videotron.ca>
Date: Wed Jul 21 14:37:41 2010 -0400
config: replace deprecated AC_HELP_STRING with AS_HELP_STRING
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
diff --git a/configure.ac b/configure.ac
index afeb544..c20a6b9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -47,7 +47,7 @@ AC_PROG_LIBTOOL
AH_TOP([#include "xorg-server.h"])
AC_ARG_WITH(xorg-module-dir,
- AC_HELP_STRING([--with-xorg-module-dir=DIR],
+ AS_HELP_STRING([--with-xorg-module-dir=DIR],
[Default xorg module directory [[default=$libdir/xorg/modules]]]),
[moduledir="$withval"],
[moduledir="$libdir/xorg/modules"])
commit 7c22a9399d6ee6a75b178b7727eeca6139038268
Author: Gaetan Nadon <memsize@videotron.ca>
Date: Wed Jul 21 14:05:22 2010 -0400
config: replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
diff --git a/configure.ac b/configure.ac
index 4a89c1e..afeb544 100644
--- a/configure.ac
+++ b/configure.ac
@@ -27,7 +27,7 @@ AC_INIT([xf86-video-chips],
[xf86-video-chips])
AC_CONFIG_SRCDIR([Makefile.am])
-AM_CONFIG_HEADER([config.h])
+AC_CONFIG_HEADERS([config.h])
AC_CONFIG_AUX_DIR(.)
AM_INIT_AUTOMAKE([foreign dist-bzip2])
commit 95f26913d129835596ccf1a1c1b353408fb8c52c
Author: Gaetan Nadon <memsize@videotron.ca>
Date: Wed Jul 21 09:27:42 2010 -0400
config: complete AC_INIT m4 quoting
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
diff --git a/configure.ac b/configure.ac
index 8902ce7..4a89c1e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,9 +22,9 @@
AC_PREREQ([2.60])
AC_INIT([xf86-video-chips],
- 1.2.2,
+ [1.2.2],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg],
- xf86-video-chips)
+ [xf86-video-chips])
AC_CONFIG_SRCDIR([Makefile.am])
AM_CONFIG_HEADER([config.h])
commit 19343524c3c85bd3d5313aca52148950445d56f7
Author: Gaetan Nadon <memsize@videotron.ca>
Date: Tue Jul 20 21:44:57 2010 -0400
config: remove unrequired AC_SUBST([XORG_CFLAGS])
This macro is called by PKG_CHECK_MODULES
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
diff --git a/configure.ac b/configure.ac
index a4f1f0a..8902ce7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -99,7 +99,6 @@ int main() {
AC_MSG_RESULT([$HAVE_INB])
AM_CONDITIONAL(BUILD_UTILS, [test x$HAVE_INB = xyes])
-AC_SUBST([XORG_CFLAGS])
AC_SUBST([moduledir])
DRIVER_NAME=chips
commit 1fcb540b7c08fd1b3b094b3d661d1b6800d4993c
Author: Gaetan Nadon <memsize@videotron.ca>
Date: Tue Jul 20 20:24:42 2010 -0400
config: remove unrequired AC_HEADER_STDC
Autoconf says:
"This macro is obsolescent, as current systems have conforming
header files. New programs need not use this macro".
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
diff --git a/configure.ac b/configure.ac
index bd23616..a4f1f0a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -85,8 +85,6 @@ AC_CHECK_DECL(xf86ConfigIsaEntity,
[#include "xf86.h"])
CFLAGS="$save_CFLAGS"
-# Checks for header files.
-AC_HEADER_STDC
# Checks for functions (often defined as inlines in compiler.h)
AC_MSG_CHECKING([for inb])
commit daf89fba39a18608c8560f635cd91218c7bfcd52
Author: Gaetan Nadon <memsize@videotron.ca>
Date: Tue Jul 20 19:41:30 2010 -0400
config: remove AC_PROG_CC as it overrides AC_PROG_C_C99
XORG_STRICT_OPTION from XORG_DEFAULT_OPTIONS calls
AC_PROG_C_C99. This sets gcc with -std=gnu99.
If AC_PROG_CC macro is called afterwards, it resets CC to gcc.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
diff --git a/configure.ac b/configure.ac
index bef208f..bd23616 100644
--- a/configure.ac
+++ b/configure.ac
@@ -43,7 +43,6 @@ XORG_DEFAULT_OPTIONS
# Checks for programs.
AC_DISABLE_STATIC
AC_PROG_LIBTOOL
-AC_PROG_CC
AH_TOP([#include "xorg-server.h"])
commit 69d9535d6601d0df8de6eae1afb28ea6d8d88dfb
Author: Gaetan Nadon <memsize@videotron.ca>
Date: Tue Jul 20 18:45:18 2010 -0400
config: update AC_PREREQ statement to 2.60
Unrelated to the previous patches, the new value simply reflects
the reality that the minimum level for autoconf to configure
all x.org modules is 2.60 dated June 2006.
ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.60.tar.gz
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
diff --git a/configure.ac b/configure.ac
index 2ac2b64..bef208f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -20,7 +20,7 @@
#
# Process this file with autoconf to produce a configure script
-AC_PREREQ(2.57)
+AC_PREREQ([2.60])
AC_INIT([xf86-video-chips],
1.2.2,
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg],
commit 6d37a83a60fefcb5922c904331d4f8ec1fac0e44
Author: Gaetan Nadon <memsize@videotron.ca>
Date: Tue Jul 20 16:15:29 2010 -0400
config: upgrade to util-macros 1.8 for additional man page support
Use MAN_SUBST now supplied in XORG_MANPAGE_SECTIONS
The value of MAN_SUBST is the same for all X.Org packages.
diff --git a/configure.ac b/configure.ac
index 62820a7..2ac2b64 100644
--- a/configure.ac
+++ b/configure.ac
@@ -34,10 +34,10 @@ AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
-# Require xorg-macros: XORG_DEFAULT_OPTIONS
+# Require X.Org macros 1.8 or later for MAN_SUBSTS set by XORG_MANPAGE_SECTIONS
m4_ifndef([XORG_MACROS_VERSION],
- [m4_fatal([must install xorg-macros 1.3 or later before running autoconf/autogen])])
-XORG_MACROS_VERSION(1.3)
+ [m4_fatal([must install xorg-macros 1.8 or later before running autoconf/autogen])])
+XORG_MACROS_VERSION(1.8)
XORG_DEFAULT_OPTIONS
# Checks for programs.
diff --git a/man/Makefile.am b/man/Makefile.am
index 8f2454b..b3688ce 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -31,25 +31,11 @@ EXTRA_DIST = @DRIVER_NAME@.man
CLEANFILES = $(driverman_DATA)
-SED = sed
-
-# Strings to replace in man pages
-XORGRELSTRING = @PACKAGE_STRING@
- XORGMANNAME = X Version 11
-
-MAN_SUBSTS = \
- -e 's|__vendorversion__|"$(XORGRELSTRING)" "$(XORGMANNAME)"|' \
- -e 's|__xorgversion__|"$(XORGRELSTRING)" "$(XORGMANNAME)"|' \
- -e 's|__xservername__|Xorg|g' \
- -e 's|__xconfigfile__|xorg.conf|g' \
- -e 's|__projectroot__|$(prefix)|g' \
- -e 's|__appmansuffix__|$(APP_MAN_SUFFIX)|g' \
- -e 's|__drivermansuffix__|$(DRIVER_MAN_SUFFIX)|g' \
- -e 's|__adminmansuffix__|$(ADMIN_MAN_SUFFIX)|g' \
- -e 's|__miscmansuffix__|$(MISC_MAN_SUFFIX)|g' \
- -e 's|__filemansuffix__|$(FILE_MAN_SUFFIX)|g'
+
+# String replacements in MAN_SUBSTS now come from xorg-macros.m4 via configure
+
SUFFIXES = .$(DRIVER_MAN_SUFFIX) .man
.man.$(DRIVER_MAN_SUFFIX):
- sed $(MAN_SUBSTS) < $< > $@
+ $(AM_V_GEN)$(SED) $(MAN_SUBSTS) < $< > $@
commit d8ce758f945cd5ec59be14d8d37311413784be59
Author: Gaetan Nadon <memsize@videotron.ca>
Date: Sun Jun 13 16:52:28 2010 -0400
README: discard the sgml version
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
diff --git a/README.sgml b/README.sgml
deleted file mode 100644
index c189e72..0000000
--- a/README.sgml
+++ /dev/null
@@ -1,1081 +0,0 @@
-<!DOCTYPE linuxdoc PUBLIC "-//Xorg//DTD linuxdoc//EN"[
-<!ENTITY % defs SYSTEM "X11/defs.ent"> %defs;
-]>
-
-<article>
-
-<!-- Title information -->
-<title> Information for Chips and Technologies Users
-<author> David Bateman (<url url="mailto:dbateman@club-internet.fr";>),
- Egbert Eich (<url url="mailto:eich@freedesktop.org";>)
-<date> 1st January 2001
-
-<!-- Table of contents -->
-<toc>
-
-<sect> Introduction <p>
-
-The Chips and Technologies driver release in X11R&relvers; came from XFree86
-4.4 rc2; this document was originally included in that release and has been
-updated modestly to reflect differences between X11R&relvers; and XFree86
-4.4 rc2.
-
-With the release of XFree86 version 4.0, 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>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 PseudoColor 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>
-
-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)
-<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)
-</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 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
- 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>
- 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>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> xorg.conf Options <p>
-
-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 "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>
-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.
-<tag>
-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>
- 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>
- 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 "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.
-<tag>
-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 "UseModeline"
-</tag>
- The flat panel timings are related to the panel size and not the
- size of the mode specified in xorg.conf. 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 "FixPanelSize"
-</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
- "UseModeline" to program all the panel timings using
- the modeline values.
-<tag>
-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 "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/24/32bpp, the effect of which
- is that the right-hand edge of the mode will be pushed off the screen.
-<tag>
-Option "HWclocks"
-</tag>
- 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,
- 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. It is completely ignored for HiQV chipsets.
-<tag>
-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. These options
- can be used to force a particular clock index to be used
-<tag>
-Option "MMIO"
-</tag>
- 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 "FullMMIO"
-</tag>
- 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 "SuspendHack"
-</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 "LcdCenter"
- and "NoStretch".
-<tag>
-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 "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 "SyncOnGreen"
-</tag>
- Composite sync on green. Possibly useful if you wish to use an
- old workstation monitor. The HiQV internal RAMDAC's supports
- this mode of operation, but whether a particular machine does
- depends on the manufacturer.
-<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>
-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 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>
-
-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/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 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/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
- 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 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
- 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. 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
-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 xorg.conf files, such as "<tt>xorgconfig</tt>".
-
-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: "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: "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: "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 and X.Org releases later than 6.7.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>xorg.conf</tt>" must be
-correctly configured. A sample of an incomplete "<tt>xorg.conf</tt>" is
-given below
-
Reply to: