Интерактивная система просмотра системных руководств (man-ов)
svgalib.chips (7)
>> svgalib.chips (7) ( Linux man: Макропакеты и соглашения )
NAME
svgalib.chips - Information for Chips and Technologies Users
TABLE OF CONTENTS
Information for Chips and Technologies Users
David Bateman <dbateman@eng.uts.edu.au>
23nd May 1997
0. Introduction
1. libvga.config options
2. Unsupported Chips and Technologies chipsets
3. Known bugs
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
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
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.
1. libvga.config OPTIONS
The first thing to note is that the option parser for
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
libvga.config(5)
options
that are of particular interest to Chips and Technologies users. Normally
this configuration file can be found at
/etc/vga/libvga.config.
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.
VertRefresh MIN MAX
Similar to the above, but this sets the LCD or CRT's vertical refresh
rate in Hz.
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.
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
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.
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.
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.
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
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.
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.
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
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.
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.
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.
Center ENABLE/DISABLE or Stretch ENABLE/DISABLE
The default behaviour of
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
Center DISABLE
might follow a
Center ENABLE
in the config file. Only the last option takes effect.
2. UNSUPPORTED CHIPS AND TECHNOLOGIES CHIPSETS
The 64200 and 64300 chips are unsupported. However by specifying the
chipset in your
libvga.config
as either a
chipset C&T 3 2048
Use 65535 for a 64200 assuming 2M of video ram, or
chipset C&T 7 2048
Use 65548 for a 64300 assuming 2Mb of video ram
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.
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.
