qbit/xenocara
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
f3920c2652
xenocara/driver/xf86-video-chips/README.sgml

1085 lines
48 KiB
Plaintext
Raw Normal View History

Importing xf86-video-chips 1.1.1
2006-11-26 13:01:26 -07:00
<!DOCTYPE linuxdoc PUBLIC "-//Xorg//DTD linuxdoc//EN"[
<!ENTITY % defs SYSTEM "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>)
<date> 1st January 2001
<ident>
</ident>
<!-- 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
<quote><verb>
Section "Device"
Identifier "Chips and Technologies - Pipe A"
Driver "chips"
BusID "PCI:0:20:0"
Screen 0
EndSection
Section "Device"
Identifier "Chips and Technologies - Pipe B"
Driver "chips"
BusID "PCI:0:20:0"
Screen 1
EndSection
Section "Screen"
Identifier "Screen 0"
Device "Chips and Technologies - Pipe A"
Monitor "generic LCD"
SubSection "Display"
Depth 16
Modes "1024x768"
EndSubsection
EndSection
Section "Screen"
Identifier "Screen 1"
Device "Chips and Technologies - Pipe B"
Monitor "generic CRT"
SubSection "Display"
Depth 16
Modes "1024x768"
EndSubsection
EndSection
Section "ServerLayout"
Identifier "Main Layout"
Screen "Screen 0"
Screen "Screen 1" RightOf "Screen 0"
InputDevice "Mouse1" "CorePointer"
InputDevice "Keyboard1" "CoreKeyboard"
EndSection
</verb></quote>
The device section must include the PCI BusID. This can be found from the
log file of a working single-head installation. For instance, the line
<quote><verb>
(--) PCI:*(0:20:0) C&amp;T 69030 rev 97, Mem @ 0xed000000/24
</verb></quote>
appears for the case above. Additionally, the "<tt>Screen</tt>" option
must appear in the device section. It should be noted that if a flat
panel is used, this it must be allocated to "<tt>Screen 0</tt>".
The server can then be started with the "<tt>+xinerama</tt>" option
as follows
<quote><verb>
startx -- +xinerama
</verb></quote>
For more information, read the Xinerama documentation.
It should be noted that the dual channel display options of the 69030
require the use of additional memory bandwidth, as each display channel
independently accesses the video memory. For this reason, the maximum
colour depth and resolution that can be supported in a dual channel mode
will be reduced compared to a single display channel mode. However, as
the driver does not prevent you from using a mode that will exceed the
memory bandwidth of the 69030, but a warning like
<quote><verb>
(WW) Memory bandwidth requirements exceeded by dual-channel
(WW) mode. Display might be corrupted!!!
</verb></quote>
If you see such display corruption, and you have this warning, your choices
are to reduce the refresh rate, colour depth or resolution, or increase the
speed of the memory clock with the the "<tt>SetMClk</tt>" option described
above. Note that increasing the memory clock also has its own problems as
described above.
<sect> The Full Story on Clock Limitations <p>
There has been much confusion about exactly what the clock limitations
of the Chips and Technologies chipsets are. Hence I hope that this
section will clear up the misunderstandings.
In general there are two factors determining the maximum dotclock.
There is the limit of the maximum dotclock the video processor can handle,
and there is another limitation of the available memory bandwidth. The
memory bandwidth is determined by the clock used for the video memory.
For chipsets incapable of colour depths greater that 8bpp like the 65535,
the dotclock limit is solely determined by the highest dotclock the video
processor is capable of handling. So this limit will be either 56MHz or
68MHz for the 655xx chipsets, depending on what voltage they are driven
with, or 80MHz for the 64200 WinGine machines.
The 6554x and 64300 WinGine chipsets are capable of colour depths of 16
or 24bpp. However there is no reliable way of probing the memory clock
used in these chipsets, and so a conservative limit must be taken for
the dotclock limit. In this case the driver divides the video processors
dotclock limitation by the number of bytes per pixel, so that the
limitations for the various colour depths are
<verb>
8bpp 16bpp 24bpp
64300 85 42.5 28.33
65540/65545 3.3v 56 28 18.67
65540/65545 5v 68 34 22.67
65546/65548 80 40 26.67
</verb>
For a CRT or TFT screen these limitations are conservative and the user
might safely override them with the "<tt>DacSpeed</tt>" option to some
extent. However these numbers take no account of the extra bandwidth
needed for DSTN screens.
For the HiQV series of chips, the memory clock can be successfully probed.
Hence you will see a line like
<verb>
(--) CHIPS(0): Probed memory clock of 40.090 MHz
</verb>
in your startx log file. Note that many chips are capable of higher
memory clocks than actually set by BIOS. You can use the "<tt>SetMClk</tt>"
option in your xorg.conf file to get a higher MClk. However some
video ram, particularly EDO, might not be fast enough to handle this,
resulting in drawing errors on the screen. The formula to determine the
maximum usable dotclock on the HiQV series of chips is
<verb>
Max dotclock = min(MaxDClk, 0.70 * 8 * MemoryClk / (BytesPerPixel +
(isDSTN == TRUE ? 1 : 0)))
</verb>
if you chips is a 69030 or 69000 or
<verb>
Max dotclock = min(MaxDClk, 0.70 * 4 * MemoryClk / (BytesPerPixel +
(isDSTN == TRUE ? 1 : 0)))
</verb>
otherwise. This effectively means that there are two limits on the
dotclock. One the overall maximum, and another due to the available
memory bandwidth of the chip. The 69030 and 69000 have a 64bit memory
bus and thus transfer 8 bytes every clock thus (hence the 8), while
the other HiQV chipsets are 32bit and transfer 4 bytes per clock cycle
(hence the 4). However, after accounting for the RAS/CAS signaling
only about 70% of the bandwidth is available. The whole thing is
divided by the bytes per pixel, plus an extra byte if you are using a
DSTN. The extra byte with DSTN screens is used for the frame
buffering/acceleration in these screens. So for the various Chips and
Technologies chips the maximum specifications are
<verb>
Max DClk MHz Max Mem Clk MHz
65550 rev A 3.3v 80 38
65550 rev A 5v 110 38
65550 rev B 95 50
65554 94.5 55
65555 110 55
68554 110 55
69000 135 83
69030 170 100
</verb>
Note that all of the chips except the 65550 rev A are 3.3v only. Which
is the reason for the drop in the dot clock. Now the maximum memory clock
is just the maximum supported by the video processor, not the maximum
supported by the video memory. So the value actually used for the memory
clock might be significantly less than this maximum value. But assuming your
memory clock is programmed to these maximum values the various maximum dot
clocks for the chips are
<verb>
------CRT/TFT------- --------DSTN--------
8bpp 16bpp 24bpp 8bpp 16bpp 24bpp
65550 rev A 3.3v 80 53.2 35.47 53.2 35.47 26.6
65550 rev A 5v 106.2 53.2 35.47 53.2 35.47 26.6
65550 rev B 95 70 46.67 70 46.67 35.0
65554 94.5 77 51.33 77 51.33 38.5
65555 110 77 51.33 77 51.33 38.5
68554 110 77 51.33 77 51.33 38.5
69000 135 135 135 135 135 116.2
69030 170 170 170 170 170 140
</verb>
If you exceed the maximum set by the memory clock, you'll get corruption
on the screen during graphics operations, as you will be starving the
HW BitBlt engine of clock cycles. If you are driving the video memory
too fast (too high a MemClk) you'll get pixel corruption as the data
actually written to the video memory is corrupted by driving the memory
too fast. You can probably get away with exceeding the Max DClk at 8bpp
on TFT's or CRT's by up to 10% or so without problems, it will just generate
more heat, since the 8bpp clocks aren't limited by the available memory
bandwidth.
If you find you truly can't achieve the mode you are after with the default
clock limitations, look at the options "<tt>DacSpeed</tt>" and
"<tt>SetMClk</tt>". Using these should give you all the capabilities
you'll need in the server to get a particular mode to work. However use
caution with these options, because there is no guarantee that driving the
video processor beyond it capabilities won't cause damage.
<sect> Troubleshooting <p>
<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 by removing the "<tt>HWcursor</tt>"
option.
<tag> The cursor hot-spot isn't at the same point as the cursor</tag>
With modes on the 6555x machines that are stretched to fill the
flat panel, the H/W cursor is not correspondingly stretched. This
is a small and long-standing bug in the current server. You can
avoid this by either using the "<tt>NoStretch</tt>" option or
removing the <tt>HWcursor</tt>" option.
<tag> The lower part of the screen is corrupted</tag>
Many DSTN screens use the top of video ram to implement a frame
accelerator. This reduces the amount of video ram available to
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>UseModeline</tt>" and perhaps also the "<tt>FixPanelSize</tt>"
options to reprogram the LCD panel timings to sensible values.
<tag> `Wavy' screen.</tag>
Horizontal waving or jittering of the whole screen, continuously
(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 one of the XAA acceleration options
discussed above. Check that the BIOS settings are OK; in particular,
disable caching of 0xa0000-0xaffff. Disabling hidden DRAM refresh
may also help.
<tag> Hang as the first text is appearing on the screen on SVR4 machines.</tag>
This problem has been reported under UnixWare 1.x, but not tracked
down. It doesn't occur under UnixWare 2.x and only occurs on the
HiQV series of chips. It might affect some other SVR4 operating
systems as well. The workaround is to turn off the use of CPU to
screen acceleration with the
"<tt>XaaNoCPUToScreenColorExapndFill</tt>" option.
<tag> Crash, hang, or trash on the screen after a graphics operation.</tag>
This may be related to a bug in one of the accelerated
functions, or a problem with the BitBLT engine. Try the
"<tt>NoAccel</tt>" or one of the XAA acceleration options
discussed above. Also check the BIOS settings. It is also possible
that with a high dot clock and depth on a large screen there is
very little bandwidth left for using the BitBLT engine. Try
reducing the clock.
<tag> Chipset is not detected.</tag>
Try forcing the chipset to a type that is most similar to what
you have.
<tag>The screen is blank when starting X</tag>
One possible cause of this problem with older linux kernels is that
the "APM_DISPLAY_BLANK" option didn't work correct. Either upgrade
your kernel or rebuild it with the "APM_DISPLAY_BLANK" option
disabled. If the problem remains, or you aren't using linux, a
CRT/LCD or switch to and from the virtual console will often fix it.
<tag> Textmode is not properly restored</tag>
This has been reported on some configurations. Many laptops
use the programmable clock of the 6554x chips at the console.
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
linux kernels are compiled with the "APM_DISPLAY_BLANK" option.
As mentioned before, try disabling this option.
<tag> I can't display 640x480 on my 800x600 LCD</tag>
The problem here is that the flat panel needs timings that
are related to the panel size, and not the mode size. There is
no facility in the current Xservers to specify these values,
and so the server attempts to read the panel size from the
chip. If the user has used the "<tt>UseModeline</tt>" or
"<tt>FixPanelSize</tt>" options the panel timings are derived
from the mode, which can be different than the panel size. Try
deleting theses options from xorg.conf 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 remove the "<tt>HWcursor</tt>"
option. The server will then allow the mode to occupy the whole
640x480 LCD.
<tag> After a suspend/resume my screen is messed up</tag>
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>LcdCenter</tt>"
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
"<tt>FixPanelSize</tt>" can be used to force the modeline values into
the panel size registers. Two machines that are known to have this
problem are the "<tt>HP OmniBook 5000</tt>" and the "<tt>NEC Versa
4080</tt>".
<tag> My TFT screen has a reddish tint in 24bpp mode</tag>
For 6554x chipsets the server assumes that the TFT bus width is
24bits. If this is not true then the screen will appear to have a
reddish tint. This can be fixed by using the "<tt>18BitBus</tt>"
option. Note that the reverse is also true. If the "<tt>18BitBus</tt>"
is used and the TFT bus width is 24bpp, then the screen will appear
reddish. Note that this option only has an effect on TFT screens.
<tag> SuperProbe won't work with my chipset</tag>
At least one non-PCI bus system with a HiQV chipset has been found to
require the "<tt>-no_bios</tt>" option for SuperProbe to correctly
detect the chipset with the factory default BIOS settings. The server
itself can correctly detect the chip in the same situation.
<tag> My 690xx machine lockups when using the "<tt>MMIO</tt>" option</tag>
The 690xx MMIO mode has been implemented entirely from the manual
as I don't have the hardware to test it on. At this point no testing
has been done and it is entirely possible that the "<tt>MMIO</tt>
option will lockup your machine. You have been warned! However if
you do try this option and are willing to debug it, I'd like to hear
from you.
<tag> My TrueColor windows are corrupted when using the "<tt>Overlay</tt>" option </tag>
Chips and Technologies specify that the memory clock used with the
multimedia engine running should be lower than that used without. As
use of the HiQV chipsets multimedia engine was supposed to be for
things like zoomed video overlays, its use was supposed to be
occasional and so most machines have their memory clock set to a value
that is too high for use with the "<tt>Overlay</tt>" option. So with
the "<tt>Overlay</tt>" option, using the "<tt>SetMClk</tt>" option to
reduce the speed of the memory clock is recommended.
<tag> The mpeg video playing with the XVideo extension has corrupted colours </tag>
The XVideo extension has only recently been added to the chips driver.
Some YUV to RGB colour have been noted at 15 and 16 bit colour depths.
However, 8 and 24 bit colour depths seem to work fine.
<tag> My ct69030 machine locks up when starting X</tag>
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 the ct69030
to a dual channel mode by default, X will lockup hard at this
point. The solution is to use the BIOS setup to change to a single
display channel mode, ensuring that both the IOSS and MSS registers
are set to a single channel mode. Work is underway to fix this.
<tag> I can't start X-windows with 16, 24 or 32bpp</tag>
Firstly, is your machine capable of 16/24/32bpp with the mode
specified. Many LCD displays are incapable of using a 24bpp
mode. Also you need at least a 65540 to use 16/24bpp and at least a
65550 for 32bpp. The amount of memory used by the mode will be
doubled/tripled/quadrupled. The correct options to start the server
with these modes are
<verb>
startx -- -depth 16 5-6-5 RGB ('64K color', XGA)
startx -- -depth 15 5-5-5 RGB ('Hicolor')
startx -- -depth 24 8-8-8 RGB truecolor
</verb>
or with the HiQV series of chips you might try
<verb>
startx -- -depth 24 -fbbpp 32 8-8-8 RGB truecolor
</verb>
however as X11R&relvers; allows 32bpp pixmaps to be
used with framebuffers operating in 24bpp, this mode of operating
will cost performance for no gain in functionality.
Note that the "<tt>-bpp</tt>" option has been removed
and replaced with a "<tt>-depth</tt>" and "<tt>-fbbpp</tt>"
option because of the confusion between the depth and number of
bits per pixel used to represent to framebuffer and the pixmaps
in the screens memory.
</descrip>
A general problem with the server that can manifested in many way such
as drawing errors, wavy screens, etc is related to the programmable
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. Alternatively, using the
"<tt>CRTClkIndx</tt>" or "<tt>FPClkIndx</tt>" option with HiQV chips might
also help.
For other screen drawing related problems, try the "<tt>NoAccel</tt>" or
one of the XAA acceleration options discussed above. A useful trick for
all laptop computers is to switch between LCD/CRT (usually with something
like Fn-F5), if the screen is having problems.
If you are having driver-related problems that are not addressed by this
document, or if you have found bugs in accelerated functions, you can
try contacting the Xorg team (the current driver maintainer can be
reached at <email>eich@freedesktop.org</email>).
<sect> Disclaimer <p>
The Xorg X server, allows the user to do damage to their hardware with
software with old monitors which may not tolerate bad display settings.
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 X server 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.
</article>
Reference in New Issue Copy Permalink