250 lines
9.1 KiB
Groff
250 lines
9.1 KiB
Groff
|
.TH svgalib.chips 7 "31 July 1997" "Svgalib (>= 1.2.11)" "Svgalib User Manual"
|
||
|
|
.SH NAME
|
||
|
|
svgalib.chips \- Information for Chips and Technologies Users
|
||
|
|
|
||
|
|
.SH TABLE OF CONTENTS
|
||
|
|
|
||
|
|
Information for Chips and Technologies Users
|
||
|
|
.br
|
||
|
|
David Bateman <dbateman@eng.uts.edu.au>
|
||
|
|
.br
|
||
|
|
23nd May 1997
|
||
|
|
|
||
|
|
.BR 0. " Introduction"
|
||
|
|
.br
|
||
|
|
.BR 1. " ""libvga.config"" options"
|
||
|
|
.br
|
||
|
|
.BR 2. " Unsupported Chips and Technologies chipsets"
|
||
|
|
.br
|
||
|
|
.BR 3. " Known bugs"
|
||
|
|
.br
|
||
|
|
|
||
|
|
.SH 0. INTRODUCTION
|
||
|
|
|
||
|
|
This is the really only my first attempt to get a working fully
|
||
|
|
featured driver for the Chips and Technologies chipset to work
|
||
|
|
with
|
||
|
|
.BR svgalib (7).
|
||
|
|
As such the only machine that I know it will work
|
||
|
|
on is my own. If you use this software then at this point I'm still
|
||
|
|
very interested in hearing from you by e-mail. Include full details
|
||
|
|
of your chipset, amount of videoram and whether you have a VL-Bus
|
||
|
|
or PCI bus machine.
|
||
|
|
|
||
|
|
This server was written using the
|
||
|
|
.BR svgalib (7)
|
||
|
|
patch from Sergio and
|
||
|
|
Angelo Masci as a starting point. This version of the code resembled
|
||
|
|
the XFree server code that was used up to XFree 3.1.2. As such it was
|
||
|
|
incapable of programming the clocks, using linear addressing, Hi-Color,
|
||
|
|
True-Color modes or the hardware acceleration. All of these features
|
||
|
|
have since been added to the code. In addition support for the 65525,
|
||
|
|
65535, 65546, 65548, 65550 and 65554 have been included. The 64200 and
|
||
|
|
64300 chips are unsupported, however these chips are very similar to
|
||
|
|
the 6554x chips which are supported.
|
||
|
|
|
||
|
|
At this point this code is only confirmed to work correctly on a
|
||
|
|
65545 VL-Bus machine. However as much of the code was stolen from
|
||
|
|
my experiences with writing code for XFree I hope not to have too
|
||
|
|
many problems with other machines. However if you run this code
|
||
|
|
on a 65545/48 PCI machine or a 65550/54 machine then I am particularly
|
||
|
|
interested in hearing of any success or failure stories.
|
||
|
|
|
||
|
|
.SH 1. """libvga.config""" OPTIONS
|
||
|
|
|
||
|
|
The first thing to note is that the option parser for
|
||
|
|
.BR svgalib (7)
|
||
|
|
is not
|
||
|
|
very robust. Hence if you make some typing mistakes, you can have
|
||
|
|
some very strange effects. I've set out below the
|
||
|
|
.BR libvga.config (5)
|
||
|
|
options
|
||
|
|
that are of particular interest to Chips and Technologies users. Normally
|
||
|
|
this configuration file can be found at
|
||
|
|
.IR /etc/vga/libvga.config.
|
||
|
|
|
||
|
|
.TP
|
||
|
|
.B HorizSync MIN MAX
|
||
|
|
Often LCD panels has very different specifications for the
|
||
|
|
horizontal sync than CRT's do. Hence often you'll need this option,
|
||
|
|
particularly if you are using the XFree like modelines described
|
||
|
|
below. The two floating point numbers specified will set the minimum
|
||
|
|
and maximum allowed horizontal sync in kHz.
|
||
|
|
|
||
|
|
.TP
|
||
|
|
.B VertRefresh MIN MAX
|
||
|
|
Similar to the above, but this sets the LCD or CRT's vertical refresh
|
||
|
|
rate in Hz.
|
||
|
|
|
||
|
|
.TP
|
||
|
|
.B modeline "640x480" 20.00 640 688 704 776 480 480 481 486
|
||
|
|
This option allows you to specify XFree like modelines to use
|
||
|
|
in preference to the in built modelines. Often LCD panels will
|
||
|
|
need very different pixel clocks and timings than CRT's. Hence
|
||
|
|
this option allows you to specify these. Note that the LCD panel
|
||
|
|
timings are related to the panel size and not the mode size.
|
||
|
|
Therefore by default the BIOS setting already uploaded into the
|
||
|
|
registers are used by default. See the "UseModeline" option
|
||
|
|
below if you wish to override these.
|
||
|
|
|
||
|
|
.TP
|
||
|
|
.B chipset C&T 5 1024
|
||
|
|
These option allows the user to specify the chipset to use and
|
||
|
|
the amount of installed memory in kBytes. Currently supported
|
||
|
|
chipsets are
|
||
|
|
|
||
|
|
0 65520
|
||
|
|
1 65525
|
||
|
|
2 65530
|
||
|
|
3 65535
|
||
|
|
4 65540
|
||
|
|
5 65545
|
||
|
|
6 65546
|
||
|
|
7 65548
|
||
|
|
8 65550
|
||
|
|
9 65554
|
||
|
|
|
||
|
|
.TP
|
||
|
|
.B TextClockFreq 25.175
|
||
|
|
One major difference between this code and the previously available
|
||
|
|
support for the Chips and Technologies chipsets is that it supports
|
||
|
|
the use of programmable clocks. Because of the way that the Chips
|
||
|
|
and Technologies chips program the VCO from the registers, there is
|
||
|
|
no way to be sure to recover the previously programmed clock value.
|
||
|
|
Hence the driver assumes that the console clock is 25.175MHz. This
|
||
|
|
will be wrong for many machines. However I have supplied this option
|
||
|
|
to use a different value that might be more suitable for your machine.
|
||
|
|
|
||
|
|
.TP
|
||
|
|
.B nolinear
|
||
|
|
This option disables the use of the linear framebuffer. This might
|
||
|
|
be useful for machines that have broken linear framebuffers. In
|
||
|
|
lar the linear framebuffer doesn't seem to work with the
|
||
|
|
achines.
|
||
|
|
|
||
|
|
.TP
|
||
|
|
.B linear
|
||
|
|
Allow, but don't enforce the use of the linear framebuffer. As this
|
||
|
|
is the default anyway, I don't see that this option is much use.
|
||
|
|
|
||
|
|
.TP
|
||
|
|
.B setuplinear 0xC0000000
|
||
|
|
For VL-Bus machines I expect that the linear framebuffer starting
|
||
|
|
address will be setup correctly. However to get the starting address
|
||
|
|
for PCI machines requires access to the MEMBASE register in the PCI
|
||
|
|
address space. Code to do this doesn't currently exist with
|
||
|
|
.BR svgalib (7),
|
||
|
|
and so I've taken the easy option of just testing a few known PCI
|
||
|
|
starting addresses. For now these are just 0xFE000000, 0xFD000000,
|
||
|
|
0x41000000 and 0xC0000000. If you have a different starting address
|
||
|
|
then the linear framebuffer will be unusable. You might like to report
|
||
|
|
your starting address to me so that I can include it in the probing
|
||
|
|
code, but till then this option can be used to set up the correct
|
||
|
|
address. This option just forces the given address to be the only one
|
||
|
|
probed. It doesn't force the linear framebuffer to be used.
|
||
|
|
|
||
|
|
.TP
|
||
|
|
.B LCDPanelSize 800 600
|
||
|
|
For some machines the LCD panel size is incorrectly probed from
|
||
|
|
the registers. This option forces the LCD panel size to be
|
||
|
|
as specified. If you have a black band down one side of your
|
||
|
|
LCD display you might very well need this option. Also if you
|
||
|
|
are using the option "fix_panel_size" in XFree then this option
|
||
|
|
has a similar effect. This option can be used in conjunction with
|
||
|
|
the option "UseModeline" to program all the panel timings using
|
||
|
|
the modeline values. Two machines that are known to need this
|
||
|
|
option are the HP Omnibook 5000CTS and the NEC Versa 4080
|
||
|
|
800x600 TFT machines.
|
||
|
|
|
||
|
|
.TP
|
||
|
|
.B UseModeline
|
||
|
|
The flat panel timings are related to the panel size and not the
|
||
|
|
size of the mode specified. For this reason the default behaviour
|
||
|
|
of the
|
||
|
|
.BR svgalib (7)
|
||
|
|
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. Two machines that are known to need this option are the
|
||
|
|
HP Omnibook 5000CTS and the Prostar 8200. You are advised to check
|
||
|
|
the README.chips that come with XFree for more details.
|
||
|
|
|
||
|
|
.TP
|
||
|
|
.B NoBitBlt
|
||
|
|
This option disables the use of H/W acceleration. As far as I know
|
||
|
|
the only thing that currently uses the H/W acceleration is libvgagl,
|
||
|
|
so this might not be a problem anyway. However if you see corruption
|
||
|
|
of the graphics on the screen try this option and see if it goes
|
||
|
|
away.
|
||
|
|
|
||
|
|
.TP
|
||
|
|
.B Use18BitBus
|
||
|
|
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 for
|
||
|
|
machines that actually have a 18 bit bus. This option, selects an
|
||
|
|
18 bit TFT bus. Note that using this option with a 24 bit bus machine
|
||
|
|
will similarly discolour the screen. For other depths this option
|
||
|
|
has no effect.
|
||
|
|
|
||
|
|
.TP
|
||
|
|
.BR "Center ENABLE/DISABLE" " or " "Stretch ENABLE/DISABLE"
|
||
|
|
The default behaviour of
|
||
|
|
.BR svgalib (7)
|
||
|
|
is to leave the stretching and
|
||
|
|
centring registers completely alone. However for some machines
|
||
|
|
this might result in poorly placed modes, or modes that don't
|
||
|
|
fill the whole screen. These two options can be used to centre
|
||
|
|
and stretch the mode on the screen. Note that for instance a
|
||
|
|
.B Center DISABLE
|
||
|
|
might follow a
|
||
|
|
.B Center ENABLE
|
||
|
|
in the config file. Only the last option takes effect.
|
||
|
|
|
||
|
|
.SH 2. UNSUPPORTED CHIPS AND TECHNOLOGIES CHIPSETS
|
||
|
|
|
||
|
|
The 64200 and 64300 chips are unsupported. However by specifying the
|
||
|
|
chipset in your
|
||
|
|
.I libvga.config
|
||
|
|
as either a
|
||
|
|
|
||
|
|
.TP
|
||
|
|
.B chipset C&T 3 2048
|
||
|
|
Use 65535 for a 64200 assuming 2M of video ram, or
|
||
|
|
.TP
|
||
|
|
.B chipset C&T 7 2048
|
||
|
|
Use 65548 for a 64300 assuming 2Mb of video ram
|
||
|
|
.PP
|
||
|
|
|
||
|
|
then svgalib can be made to give limited support to these chipsets. Note
|
||
|
|
that the paged addressing mode of the 65548 chip and earlier can only
|
||
|
|
address upto 1Mb of video ram. If the additional memory is needed then
|
||
|
|
linear addressing must be used!! Note that support of the 64xxx chips
|
||
|
|
has not been tested at all, and the above is just a suggestion that I
|
||
|
|
believe will work.
|
||
|
|
|
||
|
|
.SH 3. KNOWN BUGS
|
||
|
|
|
||
|
|
One persistent and annoying bug is that the text mode stretching on
|
||
|
|
LCD displays is not always restored correctly for 65550 and 65554
|
||
|
|
machines. This is to do with the manner in which the extended registers
|
||
|
|
are restored and what is being done with the synchronous reset while
|
||
|
|
the registers are restored. As I don't have a 65550 or 65554 machine
|
||
|
|
of my own on which to test this code, I have been unable to fix this
|
||
|
|
problem. In most circumstances an LCD-CRT switch will restore the
|
||
|
|
LCD stretching to the desired state.
|
||
|
|
|
||
|
|
David.
|
||
|
|
|
||
|
|
.SH FILES
|
||
|
|
.I /etc/vga/libvga.config
|
||
|
|
|
||
|
|
.SH SEE ALSO
|
||
|
|
.BR svgalib (7),
|
||
|
|
.BR libvga.config (5).
|
||
|
|
|
||
|
|
.SH AUTHOR
|
||
|
|
of the driver and this documentation is
|
||
|
|
David Bateman <dbateman@eng.uts.edu.au>.
|
||
|
|
However, it was slightly reformatted by Michael Weller
|
||
|
|
<eowmob@exp-math.uni-essen.de>.
|