Provided by: libsvga1_1.4.3-33_amd64 bug

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.

       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.

       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

       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.

       nolinear
              This  option  disables  the  use of the linear framebuffer. This might be useful for machines that
              have broken linear framebuffers.

       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.

       David.

FILES

       /etc/vga/libvga.config

SEE ALSO

       svgalib(7), libvga.config(5).

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>.

Svgalib (>= 1.2.11)                               31 July 1997                                  svgalib.chips(7)