mirror of
https://github.com/X11Libre/xf86-video-chips.git
synced 2026-03-24 01:24:44 +00:00
README: fix linuxdoc content
defs.ent are located under X11 directory ident tag is not a Linuxdoc tag replace docbook email tag with linuxdoc email tag Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
This commit is contained in:
284
README
284
README
@@ -1,6 +1,6 @@
|
||||
Information for Chips and Technologies Users
|
||||
David Bateman ( <dbateman@club-internet.fr>), Egbert Eich (
|
||||
<eich@freedesktop.org>)
|
||||
David Bateman ( <mailto:dbateman@club-internet.fr>), Egbert
|
||||
Eich ( <mailto:eich@freedesktop.org>)
|
||||
1st January 2001
|
||||
____________________________________________________________
|
||||
|
||||
@@ -25,12 +25,12 @@
|
||||
|
||||
______________________________________________________________________
|
||||
|
||||
[1m1. Introduction[0m
|
||||
1. Introduction
|
||||
|
||||
|
||||
The Chips and Technologies driver release in X11R6.8 came from XFree86
|
||||
The Chips and Technologies driver release in X11R7.5 came from XFree86
|
||||
4.4 rc2; this document was originally included in that release and has
|
||||
been updated modestly to reflect differences between X11R6.8 and
|
||||
been updated modestly to reflect differences between X11R7.5 and
|
||||
XFree86 4.4 rc2.
|
||||
|
||||
With the release of XFree86 version 4.0, the Chips and Technologies
|
||||
@@ -42,29 +42,29 @@
|
||||
use this version. These features include
|
||||
|
||||
|
||||
+o The long standing black/blue screen problem that some people have
|
||||
o The long standing black/blue screen problem that some people have
|
||||
had should be fixed.
|
||||
|
||||
+o Hardware/Software cursor switching on the fly, that should fix many
|
||||
o Hardware/Software cursor switching on the fly, that should fix many
|
||||
of the known hardware cursor problems.
|
||||
|
||||
+o Gamma correction at all depths and DirectColor visuals for depths
|
||||
o Gamma correction at all depths and DirectColor visuals for depths
|
||||
of 15 or greater with the HiQV series of chipsets.
|
||||
|
||||
+o Supports PsuedoColor overlays on 16bpp TrueColor screens for HiQV.
|
||||
o Supports PseudoColor overlays on 16bpp TrueColor screens for HiQV.
|
||||
|
||||
+o Supports YUV colour space conversion with the XVideo extension.
|
||||
o Supports YUV colour space conversion with the XVideo extension.
|
||||
|
||||
+o 32bpp pixmaps while using a framebuffer in 24bpp packed pixel mode.
|
||||
o 32bpp pixmaps while using a framebuffer in 24bpp packed pixel mode.
|
||||
|
||||
+o Heaps more acceleration.
|
||||
o Heaps more acceleration.
|
||||
|
||||
+o 1/4bpp support.
|
||||
o 1/4bpp support.
|
||||
|
||||
+o Multihead
|
||||
o Multihead
|
||||
|
||||
|
||||
+o Much more...
|
||||
o Much more...
|
||||
|
||||
This document attempts to discuss the features of this driver, the
|
||||
options useful in configuring it and the known problems. Most of the
|
||||
@@ -72,7 +72,7 @@
|
||||
degree.
|
||||
|
||||
|
||||
[1m2. Supported Chips[0m
|
||||
2. Supported Chips
|
||||
|
||||
|
||||
The Chips and Technologies chipsets supported by this driver have one
|
||||
@@ -81,58 +81,58 @@
|
||||
completely new HiQV architecture.
|
||||
|
||||
|
||||
[1m2.1. Basic architecture[0m
|
||||
2.1. Basic architecture
|
||||
|
||||
|
||||
[1mct65520[0m
|
||||
ct65520
|
||||
(Max Ram: 1Mb, Max Dclk: 68MHz@5V)
|
||||
|
||||
[1mct65525[0m
|
||||
ct65525
|
||||
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.
|
||||
|
||||
[1mct65530[0m
|
||||
ct65530
|
||||
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)
|
||||
|
||||
[1mct65535[0m
|
||||
ct65535
|
||||
This is the first chip of the ct655xx series to support fully
|
||||
programmable clocks. Otherwise it has the the same properties as
|
||||
the 65530.
|
||||
|
||||
[1mct65540[0m
|
||||
ct65540
|
||||
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)
|
||||
|
||||
[1mct65545[0m
|
||||
ct65545
|
||||
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)
|
||||
|
||||
[1mct65546[0m
|
||||
ct65546
|
||||
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?)
|
||||
|
||||
[1mct65548[0m
|
||||
ct65548
|
||||
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)
|
||||
|
||||
|
||||
|
||||
[1m2.2. WinGine architecture[0m
|
||||
2.2. WinGine architecture
|
||||
|
||||
|
||||
[1mct64200[0m
|
||||
ct64200
|
||||
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
|
||||
@@ -140,7 +140,7 @@
|
||||
only have limited support. Linear addressing is not supported
|
||||
for this card in the driver. (Max Ram: 2Mb, Max Dclk: 80MHz)
|
||||
|
||||
[1mct64300[0m
|
||||
ct64300
|
||||
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
|
||||
@@ -148,10 +148,10 @@
|
||||
Ram: 2Mb, Max Dclk: 80MHz)
|
||||
|
||||
|
||||
[1m2.3. HiQV Architecture[0m
|
||||
2.3. HiQV Architecture
|
||||
|
||||
|
||||
[1mct65550[0m
|
||||
ct65550
|
||||
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
|
||||
@@ -159,30 +159,30 @@
|
||||
I/O is possible on all bus configurations. (Max Ram: 2Mb, Max
|
||||
Dclk: 80MHz@3.3V,100MHz@5V)
|
||||
|
||||
[1mct65554[0m
|
||||
ct65554
|
||||
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)
|
||||
|
||||
[1mct65555[0m
|
||||
ct65555
|
||||
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)
|
||||
|
||||
[1mct68554[0m
|
||||
ct68554
|
||||
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)
|
||||
|
||||
[1mct69000[0m
|
||||
ct69000
|
||||
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)
|
||||
|
||||
[1mct69030[0m
|
||||
ct69030
|
||||
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
|
||||
@@ -190,32 +190,32 @@
|
||||
|
||||
|
||||
|
||||
[1m3. xorg.conf Options[0m
|
||||
3. xorg.conf Options
|
||||
|
||||
|
||||
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.
|
||||
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
|
||||
Monitor sections and the Display subsections. The order of precedence
|
||||
is Display, Screen, Monitor, Device.
|
||||
|
||||
|
||||
[1mOption[0m
|
||||
Option
|
||||
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).
|
||||
|
||||
[1mVideoRam 1024 (or another value)[0m
|
||||
VideoRam 1024 (or another value)
|
||||
This option will override the detected amount of video memory,
|
||||
and pretend the given amount of memory is present on the card.
|
||||
|
||||
[1mOption[0m
|
||||
Option
|
||||
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
|
||||
@@ -223,7 +223,7 @@
|
||||
Note that H/W acceleration is only supported with linear
|
||||
addressing.
|
||||
|
||||
[1mOption[0m
|
||||
Option
|
||||
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
|
||||
@@ -231,7 +231,7 @@
|
||||
depths 1 and 4bpp. Note that linear addressing at 1 and 4bpp is
|
||||
not guaranteed to work correctly.
|
||||
|
||||
[1mMemBase 0x03b00000 (or a different address)[0m
|
||||
MemBase 0x03b00000 (or a different address)
|
||||
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
|
||||
@@ -240,7 +240,7 @@
|
||||
Note that for the 65530 this is required as the base address
|
||||
can't be correctly probed.
|
||||
|
||||
[1mOption[0m
|
||||
Option
|
||||
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 "SWcursor"
|
||||
@@ -249,16 +249,16 @@
|
||||
is now given to the hardware. It also reduces the effect of
|
||||
cursor flashing during graphics operations.
|
||||
|
||||
[1mOption[0m
|
||||
Option
|
||||
This disables use of the hardware cursor provided by the chip.
|
||||
Try this if the cursor seems to have problems.
|
||||
|
||||
[1mOption[0m
|
||||
Option
|
||||
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.
|
||||
|
||||
[1mOption[0m
|
||||
Option
|
||||
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
|
||||
@@ -266,7 +266,7 @@
|
||||
timings to be recalculated from the modeline with this option.
|
||||
However the panel size will still be probed.
|
||||
|
||||
[1mOption[0m
|
||||
Option
|
||||
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
|
||||
@@ -276,13 +276,13 @@
|
||||
"UseModeline" to program all the panel timings using the
|
||||
modeline values.
|
||||
|
||||
[1mOption[0m
|
||||
Option
|
||||
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 "letterbox" effect with no
|
||||
stretching can be achieved using this option.
|
||||
|
||||
[1mOption[0m
|
||||
Option
|
||||
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
|
||||
@@ -291,7 +291,7 @@
|
||||
effect of which is that the right-hand edge of the mode will be
|
||||
pushed off the screen.
|
||||
|
||||
[1mOption[0m
|
||||
Option
|
||||
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
|
||||
@@ -307,7 +307,7 @@
|
||||
use isn't recommended. It is completely ignored for HiQV
|
||||
chipsets.
|
||||
|
||||
[1mTextClockFreq 25.175[0m
|
||||
TextClockFreq 25.175
|
||||
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
|
||||
@@ -316,21 +316,21 @@
|
||||
This allows the user to select a different clock for the server
|
||||
to use when returning to the text console.
|
||||
|
||||
[1mOption[0m
|
||||
Option "FPClock16" "65.0MHz" Option "FPClock24" "65.0MHz"
|
||||
Option "FPClock32" "65.0MHz"" 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.
|
||||
Option
|
||||
Option "FPClock16" "65.0MHz" Option "FPClock24" "65.0MHz" Option
|
||||
"FPClock32" "65.0MHz"" 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.
|
||||
|
||||
[1mOption[0m
|
||||
Option
|
||||
Option "FPClkIndx" "1"" 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
|
||||
@@ -339,45 +339,45 @@
|
||||
clock is unusable. These options can be used to force a
|
||||
particular clock index to be used
|
||||
|
||||
[1mOption[0m
|
||||
Option
|
||||
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
|
||||
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.
|
||||
|
||||
[1mOption[0m
|
||||
Option
|
||||
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.
|
||||
|
||||
[1mOption[0m
|
||||
Option
|
||||
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".
|
||||
|
||||
[1mOption [22mFor 24bpp on TFT screens, the server assumes that
|
||||
Option 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.
|
||||
|
||||
[1mChipset [22mIt is possible that the chip could be
|
||||
Chipset 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.
|
||||
|
||||
[1mOption [22mComposite sync on green. Possibly useful if you
|
||||
Option 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.
|
||||
|
||||
[1mDacSpeed 80.000 [22mThe server will limit the maximum dotclock to a
|
||||
DacSpeed 80.000 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
|
||||
@@ -386,7 +386,7 @@
|
||||
this option, as driving the video processor
|
||||
beyond its specifications might cause damage.
|
||||
|
||||
[1mOption [22mOption "SetMClk" "38000kHz"" This option sets the
|
||||
Option Option "SetMClk" "38000kHz"" 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
|
||||
@@ -400,7 +400,7 @@
|
||||
speed of the memory clock with the "Overlay"
|
||||
option.
|
||||
|
||||
[1mOption [22mBy default it is assumed that there are 6
|
||||
Option 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
|
||||
@@ -408,14 +408,14 @@
|
||||
server to assume that there are 8 significant
|
||||
bits.
|
||||
|
||||
[1mOption [22mThis is a debugging option and general users have
|
||||
Option 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.
|
||||
|
||||
[1mOption [22mThis option is only useful when acceleration
|
||||
Option 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
|
||||
@@ -427,7 +427,7 @@
|
||||
all done into a virtual framebuffer acceleration
|
||||
can not be used.
|
||||
|
||||
[1mOption [22mThe new TMED DSTN dithering scheme available on
|
||||
Option 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 snow on
|
||||
@@ -435,7 +435,7 @@
|
||||
is only relevant for chipsets more recent than
|
||||
the ct65555 and only when used with a DSTN LCD.
|
||||
|
||||
[1mOption [22mThe HiQV chipsets contain a multimedia engine
|
||||
Option 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
|
||||
@@ -459,21 +459,21 @@
|
||||
disables the XVideo extension.
|
||||
|
||||
|
||||
[1mOption [22mNormally the colour transparency key for the
|
||||
Option 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.
|
||||
|
||||
[1mOption [22mThis sets the default pixel value for the YUV
|
||||
Option 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.
|
||||
|
||||
[1mOption [22mThe 69030 chipset has independent display
|
||||
Option 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
|
||||
@@ -482,14 +482,14 @@
|
||||
option forces the two display channels to be
|
||||
used, giving independent refresh rates.
|
||||
|
||||
[1mOption [22mThe ct69030 supports dual-head display. By
|
||||
Option 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.
|
||||
|
||||
[1mOption [22mOption "XaaNoSolidFillRect", Option "XaaNoSolid-
|
||||
Option Option "XaaNoSolidFillRect", Option "XaaNoSolid-
|
||||
HorVertLine", Option "XaaNoMono8x8PatternFill-
|
||||
Rect", Option "XaaNoColor8x8PatternFillRect",
|
||||
Option "XaaNoCPUToScreenColorExpandFill", Option
|
||||
@@ -505,14 +505,14 @@
|
||||
invaluable in debugging any problems.
|
||||
|
||||
|
||||
[1m4. Modelines[0m
|
||||
4. Modelines
|
||||
|
||||
|
||||
When constructing a modeline for use with the Chips and Technologies
|
||||
driver you'll needed to considered several points
|
||||
|
||||
|
||||
[1m* Virtual Screen Size[0m
|
||||
* Virtual Screen Size
|
||||
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.
|
||||
@@ -522,11 +522,11 @@
|
||||
but leave the virtual resolution untouched. This might further
|
||||
reduce the available memory.
|
||||
|
||||
[1m* 16/24/32 Bits Per Pixel[0m
|
||||
* 16/24/32 Bits Per Pixel
|
||||
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
|
||||
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
|
||||
@@ -534,7 +534,7 @@
|
||||
16/24/32 bpp modes will need 2 , 3 or 4 times respectively more
|
||||
video ram.
|
||||
|
||||
[1m* Frame Acceleration[0m
|
||||
* Frame Acceleration
|
||||
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
|
||||
@@ -547,7 +547,7 @@
|
||||
bytes (640x480 panel), 96000 bytes (800x600 panel) and 157287
|
||||
bytes (1024x768 panel).
|
||||
|
||||
[1m* H/W Acceleration[0m
|
||||
* H/W Acceleration
|
||||
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
|
||||
@@ -555,7 +555,7 @@
|
||||
cache". Leaving too little memory available for the cache will
|
||||
only have a detrimental effect on the graphics performance.
|
||||
|
||||
[1m* PseudoColor Overlay[0m
|
||||
* PseudoColor Overlay
|
||||
If you use the "overlay" 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
|
||||
@@ -563,20 +563,20 @@
|
||||
bandwidth, so that the maximum dotclock will be similar to a
|
||||
24bpp mode.
|
||||
|
||||
[1m* XVideo extension*[0m
|
||||
* XVideo extension*
|
||||
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.
|
||||
|
||||
[1m* VESA like modes[0m
|
||||
* VESA like modes
|
||||
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.
|
||||
|
||||
[1m* Dot Clock[0m
|
||||
* Dot Clock
|
||||
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
|
||||
@@ -586,7 +586,7 @@
|
||||
complete discussion on the dot clock limitations, see the next
|
||||
section.
|
||||
|
||||
[1m* Dual-head display[0m
|
||||
* Dual-head display
|
||||
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
|
||||
@@ -629,7 +629,7 @@
|
||||
|
||||
|
||||
|
||||
The IBM PC110 works best with a 15MHz clock (Thanks to Alan Cox):
|
||||
The IBM PC110 works best with a 15MHz clock (Thanks to Alan Cox):
|
||||
|
||||
|
||||
Modeline "640x480" 15.00 640 672 728 816 480 489 496 526
|
||||
@@ -643,11 +643,11 @@
|
||||
"FixPanelSize" options.
|
||||
|
||||
|
||||
[1m5. Dual Display Channel[0m
|
||||
5. Dual Display Channel
|
||||
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
@@ -753,7 +753,7 @@
|
||||
own problems as described above.
|
||||
|
||||
|
||||
[1m6. The Full Story on Clock Limitations[0m
|
||||
6. The Full Story on Clock Limitations
|
||||
|
||||
|
||||
There has been much confusion about exactly what the clock limitations
|
||||
@@ -823,7 +823,7 @@
|
||||
|
||||
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
|
||||
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
|
||||
@@ -887,11 +887,11 @@
|
||||
the video processor beyond it capabilities won't cause damage.
|
||||
|
||||
|
||||
[1m7. Troubleshooting[0m
|
||||
7. Troubleshooting
|
||||
|
||||
|
||||
|
||||
[1mThe cursor appears as a white box, after switching modes[0m
|
||||
The cursor appears as a white box, after switching modes
|
||||
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
|
||||
@@ -899,14 +899,14 @@
|
||||
annoying the H/W cursor can be disabled by removing the
|
||||
"HWcursor" option.
|
||||
|
||||
[1mThe cursor hot-spot isn't at the same point as the cursor[0m
|
||||
The cursor hot-spot isn't at the same point as the cursor
|
||||
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 "NoStretch" option or
|
||||
removing the HWcursor" option.
|
||||
|
||||
[1mThe lower part of the screen is corrupted[0m
|
||||
The lower part of the screen is corrupted
|
||||
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
|
||||
@@ -916,7 +916,7 @@
|
||||
accelerator and will therefore be corrupt. Try reducing the
|
||||
amount of memory consumed by the mode.
|
||||
|
||||
[1mThere is a video signal, but the screen doesn't sync.[0m
|
||||
There is a video signal, but the screen doesn't sync.
|
||||
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
|
||||
@@ -927,22 +927,22 @@
|
||||
the "UseModeline" and perhaps also the "FixPanelSize" options to
|
||||
reprogram the LCD panel timings to sensible values.
|
||||
|
||||
[1m`Wavy' screen.[0m
|
||||
`Wavy' screen.
|
||||
Horizontal waving or jittering of the whole screen, continuously
|
||||
(independent from drawing operations). You are probably using a
|
||||
(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.
|
||||
|
||||
[1mCrash or hang after start-up (probably with a black screen).[0m
|
||||
Crash or hang after start-up (probably with a black screen).
|
||||
Try the "NoAccel" 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.
|
||||
|
||||
[1mHang as the first text is appearing on the screen on SVR4[0m
|
||||
[1mmachines.[0m
|
||||
Hang as the first text is appearing on the screen on SVR4
|
||||
machines.
|
||||
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
|
||||
@@ -950,7 +950,7 @@
|
||||
the use of CPU to screen acceleration with the
|
||||
"XaaNoCPUToScreenColorExapndFill" option.
|
||||
|
||||
[1mCrash, hang, or trash on the screen after a graphics operation.[0m
|
||||
Crash, hang, or trash on the screen after a graphics operation.
|
||||
This may be related to a bug in one of the accelerated
|
||||
functions, or a problem with the BitBLT engine. Try the
|
||||
"NoAccel" or one of the XAA acceleration options discussed
|
||||
@@ -959,11 +959,11 @@
|
||||
little bandwidth left for using the BitBLT engine. Try reducing
|
||||
the clock.
|
||||
|
||||
[1mChipset is not detected.[0m
|
||||
Chipset is not detected.
|
||||
Try forcing the chipset to a type that is most similar to what
|
||||
you have.
|
||||
|
||||
[1mThe screen is blank when starting X[0m
|
||||
The screen is blank when starting X
|
||||
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"
|
||||
@@ -971,7 +971,7 @@
|
||||
linux, a CRT/LCD or switch to and from the virtual console will
|
||||
often fix it.
|
||||
|
||||
[1mTextmode is not properly restored[0m
|
||||
Textmode is not properly restored
|
||||
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
|
||||
@@ -985,7 +985,7 @@
|
||||
kernels are compiled with the "APM_DISPLAY_BLANK" option. As
|
||||
mentioned before, try disabling this option.
|
||||
|
||||
[1mI can't display 640x480 on my 800x600 LCD[0m
|
||||
I can't display 640x480 on my 800x600 LCD
|
||||
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
|
||||
@@ -995,7 +995,7 @@
|
||||
than the panel size. Try deleting theses options from xorg.conf
|
||||
or using an LCD/CRT switch.
|
||||
|
||||
[1mI can't get a 320x240 mode to occupy the whole 640x480 LCD[0m
|
||||
I can't get a 320x240 mode to occupy the whole 640x480 LCD
|
||||
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
|
||||
@@ -1004,7 +1004,7 @@
|
||||
remove the "HWcursor" option. The server will then allow the
|
||||
mode to occupy the whole 640x480 LCD.
|
||||
|
||||
[1mAfter a suspend/resume my screen is messed up[0m
|
||||
After a suspend/resume my screen is messed up
|
||||
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
|
||||
@@ -1015,16 +1015,16 @@
|
||||
displayed incorrectly. This shouldn't affect higher depths, and
|
||||
is fixable with a switch to the virtual console and back.
|
||||
|
||||
[1mThe right hand edge of the mode isn't visible on the LCD[0m
|
||||
The right hand edge of the mode isn't visible on the LCD
|
||||
This is usually due to a problem with the "LcdCenter" option. If
|
||||
this option is removed form xorg.conf, then the problem might go
|
||||
away. Alternatively the manufacturer could have incorrectly
|
||||
programmed the panel size in the EGA console mode. The
|
||||
"FixPanelSize" can be used to force the modeline values into the
|
||||
panel size registers. Two machines that are known to have this
|
||||
problem are the "HP OmniBook 5000" and the "NEC Versa 4080".
|
||||
problem are the "HP OmniBook 5000" and the "NEC Versa 4080".
|
||||
|
||||
[1mMy TFT screen has a reddish tint in 24bpp mode[0m
|
||||
My TFT screen has a reddish tint in 24bpp 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 "18BitBus"
|
||||
@@ -1033,14 +1033,14 @@
|
||||
reddish. Note that this option only has an effect on TFT
|
||||
screens.
|
||||
|
||||
[1mSuperProbe won't work with my chipset[0m
|
||||
SuperProbe won't work with my chipset
|
||||
At least one non-PCI bus system with a HiQV chipset has been
|
||||
found to require the "-no_bios" 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.
|
||||
|
||||
[1mMy 690xx machine lockups when using the[0m
|
||||
My 690xx machine lockups when using the
|
||||
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
|
||||
@@ -1048,7 +1048,7 @@
|
||||
However if you do try this option and are willing to debug it,
|
||||
I'd like to hear from you.
|
||||
|
||||
[1mMy TrueColor windows are corrupted when using the[0m
|
||||
My TrueColor windows are corrupted when using the
|
||||
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
|
||||
@@ -1059,14 +1059,14 @@
|
||||
"SetMClk" option to reduce the speed of the memory clock is
|
||||
recommended.
|
||||
|
||||
[1mThe mpeg video playing with the XVideo extension has corrupted[0m
|
||||
[1mcolours[0m
|
||||
The mpeg video playing with the XVideo extension has corrupted
|
||||
colours
|
||||
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.
|
||||
|
||||
[1mMy ct69030 machine locks up when starting X[0m
|
||||
My ct69030 machine locks up when starting X
|
||||
The ct69030 chipset introduced a new dual channel architecture.
|
||||
In its current form, X can not take advantage of this second
|
||||
display channel. In fact if the video BIOS on the machine sets
|
||||
@@ -1076,7 +1076,7 @@
|
||||
IOSS and MSS registers are set to a single channel mode. Work is
|
||||
underway to fix this.
|
||||
|
||||
[1mI can't start X-windows with 16, 24 or 32bpp[0m
|
||||
I can't start X-windows with 16, 24 or 32bpp
|
||||
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 at
|
||||
@@ -1095,7 +1095,7 @@
|
||||
startx -- -depth 24 -fbbpp 32 8-8-8 RGB truecolor
|
||||
|
||||
|
||||
however as X11R6.8 allows 32bpp pixmaps to be used with frame-
|
||||
however as X11R7.5 allows 32bpp pixmaps to be used with frame-
|
||||
buffers operating in 24bpp, this mode of operating will cost per-
|
||||
formance for no gain in functionality.
|
||||
|
||||
@@ -1126,10 +1126,10 @@
|
||||
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 Xorg team (the current driver maintainer can be
|
||||
reached at <eich@freedesktop.org>).
|
||||
reached at <mailto:eich@freedesktop.org>).
|
||||
|
||||
|
||||
[1m8. Disclaimer[0m
|
||||
8. Disclaimer
|
||||
|
||||
|
||||
The Xorg X server, allows the user to do damage to their hardware with
|
||||
@@ -1140,38 +1140,38 @@
|
||||
screen, TURN THE COMPUTER OFF!!
|
||||
|
||||
|
||||
[1m9. Acknowledgement[0m
|
||||
9. Acknowledgement
|
||||
|
||||
|
||||
The authors of this software wish to acknowledge the support supplied
|
||||
by Chips and Technologies during the development of this software.
|
||||
|
||||
|
||||
[1m10. Authors[0m
|
||||
10. Authors
|
||||
|
||||
|
||||
Major Contributors (In no particular order)
|
||||
|
||||
+o Nozomi Ytow
|
||||
o Nozomi Ytow
|
||||
|
||||
+o Egbert Eich
|
||||
o Egbert Eich
|
||||
|
||||
+o David Bateman
|
||||
o David Bateman
|
||||
|
||||
+o Xavier Ducoin
|
||||
o Xavier Ducoin
|
||||
|
||||
Contributors (In no particular order)
|
||||
|
||||
+o Ken Raeburn
|
||||
o Ken Raeburn
|
||||
|
||||
|
||||
+o Shigehiro Nomura
|
||||
o Shigehiro Nomura
|
||||
|
||||
+o Marc de Courville
|
||||
o Marc de Courville
|
||||
|
||||
+o Adam Sulmicki
|
||||
o Adam Sulmicki
|
||||
|
||||
+o Jens Maurer
|
||||
o Jens Maurer
|
||||
|
||||
We also thank the many people on the net who have contributed by
|
||||
reporting bugs and extensively testing this server.
|
||||
|
||||
11
README.sgml
11
README.sgml
@@ -1,18 +1,15 @@
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//Xorg//DTD linuxdoc//EN"[
|
||||
<!ENTITY % defs SYSTEM "defs.ent"> %defs;
|
||||
<!ENTITY % defs SYSTEM "X11/defs.ent"> %defs;
|
||||
]>
|
||||
|
||||
<article>
|
||||
|
||||
<!-- Title information -->
|
||||
<title> Information for Chips and Technologies Users
|
||||
<author> David Bateman (<email>dbateman@club-internet.fr</email>),
|
||||
Egbert Eich (<email>eich@freedesktop.org</email>)
|
||||
<author> David Bateman (<url url="mailto:dbateman@club-internet.fr">),
|
||||
Egbert Eich (<url url="mailto:eich@freedesktop.org">)
|
||||
<date> 1st January 2001
|
||||
|
||||
<ident>
|
||||
</ident>
|
||||
|
||||
<!-- Table of contents -->
|
||||
<toc>
|
||||
|
||||
@@ -1042,7 +1039,7 @@ video processor beyond it capabilities won't cause damage.
|
||||
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 Xorg team (the current driver maintainer can be
|
||||
reached at <email>eich@freedesktop.org</email>).
|
||||
reached at <url url="mailto:eich@freedesktop.org">).
|
||||
|
||||
<sect> Disclaimer <p>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user