Initial. Don't... just don't ask.
This commit is contained in:
Ryan McGrath
commit
00bae13bba
586 changed files with 129057 additions and 0 deletions
1266
doc/man7/svgalib.7
Normal file
1266
doc/man7/svgalib.7
Normal file
File diff suppressed because it is too large
Load diff
249
doc/man7/svgalib.chips.7
Normal file
249
doc/man7/svgalib.chips.7
Normal file
|
|
@ -0,0 +1,249 @@
|
|||
.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>.
|
||||
312
doc/man7/svgalib.et4000.7
Normal file
312
doc/man7/svgalib.et4000.7
Normal file
|
|
@ -0,0 +1,312 @@
|
|||
.TH svgalib.et4000 7 "31 July 1997" "Svgalib (>= 1.2.11)" "Svgalib User Manual"
|
||||
.SH NAME
|
||||
svgalib.et4000, libvga.et4000 \- Information for Tseng ET4000 users
|
||||
|
||||
.SH TABLE OF CONTENTS
|
||||
.B NOTE: The ET4000 register layout changed stepping from
|
||||
.B svgalib 0.98 to 0.99. See 8. Problems below first
|
||||
|
||||
|
||||
.BR 1. " Basics of ET4000 cards"
|
||||
.br
|
||||
.BR 2. " How to configure " svgalib (7)
|
||||
.br
|
||||
.BR 3. " Creating card dependent register values"
|
||||
.br
|
||||
.BR 4. " Defining new modes"
|
||||
.br
|
||||
.BR 5. " Redefining standard modes"
|
||||
.br
|
||||
.BR 6. " Available examples"
|
||||
.br
|
||||
.BR 7. " ET4000/W32 support"
|
||||
.br
|
||||
.BR 8. " Problems"
|
||||
.br
|
||||
.BR 9. " Using dynamic loading with other cards"
|
||||
|
||||
.SH 1. BASICS OF ET4000 CARDS
|
||||
|
||||
Basicly all ET4000 cards are equal, some are even more equal ...
|
||||
|
||||
The Chipset is well documented (by Tseng Labs and eg. the vgadoc2.zip)
|
||||
and all graphics functions can be used the same way on different cards
|
||||
(including the ET4000/W32 based ones). There are three important points
|
||||
to be kept in mind:
|
||||
|
||||
.TP
|
||||
.B a.)
|
||||
amount of available, the organisation and timing of video memory
|
||||
.TP
|
||||
.B b.)
|
||||
type and capabilities of the DAC
|
||||
.TP
|
||||
.B c.)
|
||||
available oscillator frequencies
|
||||
.P
|
||||
|
||||
.BR svgalib (7)
|
||||
will check the available video memory during startup. This
|
||||
should work on all DRAM cards. If there are any problems concerning
|
||||
VRAM equipped cards, please tell us about.
|
||||
|
||||
By now we found is no reliable way to detect the memory organisation/
|
||||
timing and the DAC type/capabilities. Most modern card use a frequency
|
||||
synthizier and provide the following pixel frequencies (in MHz):
|
||||
|
||||
.RS
|
||||
.B 50.350 56.644 65.0 72.0 80.0 89.8 63.0 75.0
|
||||
.RE
|
||||
|
||||
Checking older ET4000 cards we found a wide spread range of available
|
||||
frequencies. Since the video timing is based on the pixel frequency,
|
||||
the required register values are card dependent.
|
||||
|
||||
.SH 2. HOW TO CONFIGURE SVGALIB
|
||||
|
||||
.BR svgalib (7)
|
||||
has a somewhat 'standard' registers set that may work with
|
||||
modern ET4000 cards. If
|
||||
.BR svgalib (7)
|
||||
fails on your machine or you have
|
||||
a HiColor dac, you need to configure your
|
||||
.BR svgalib (7).
|
||||
|
||||
The
|
||||
.BR svgalib (7)
|
||||
may use hard linked or dynamical linked register values.
|
||||
If you use hard linked values, the binary will be smaller and start
|
||||
up faster but might fail on other machines.
|
||||
|
||||
Compiling the
|
||||
.BR svgalib (7)
|
||||
with DYNAMIC defined (see
|
||||
.IR Makefile.cfg )
|
||||
will set up dynamic register loading. Otherwise the value from
|
||||
.I svgalib/et4000.regs
|
||||
will be hard linked.
|
||||
|
||||
The dynamic configuration will be read from
|
||||
.I /etc/vga/libvga.et4000
|
||||
which is an ASCII file (see
|
||||
.I Makefile.cfg
|
||||
for exact naming). If you have
|
||||
a working et4000.regs for your system just copy this file to
|
||||
.IR /etc/vga/libvga.et4000 " or link " /etc/vga/libvga.et4000
|
||||
to your
|
||||
.I svgalib/et4000.regs
|
||||
file.
|
||||
|
||||
The actual scanner/parser will handle the following entries:
|
||||
|
||||
.TP
|
||||
.B #define DAC_TYPE <integer>
|
||||
Overwrite the DAC detection
|
||||
.TP
|
||||
.B #define <MODE1> <MODE2>
|
||||
Enable MODE1 using MODE2 registers, eg. 64K modes like 32K modes
|
||||
.TP
|
||||
.B #define <MODE> DISABLE_MODE
|
||||
do not use MODE (eg. from vgadrv)
|
||||
.TP
|
||||
.B char <MODE><strg>[..] = {<integer>, <integer>, ... };
|
||||
register definition
|
||||
.PP
|
||||
with
|
||||
|
||||
.B "<MODE> ::= 'g'<decimal>x<decimal>x<color><ignored>"
|
||||
.br
|
||||
.B "<integer> ::= <decimal>|<hex>"
|
||||
.br
|
||||
.B "<hex> ::= '0x'<hexdigit>{<hexdigit>}"
|
||||
.br
|
||||
.B "<decimal> ::= ['+'|'-']<digit>{<digit>}"
|
||||
.br
|
||||
.B "<hexdigit>::= <digit>|'a..f'|'A..F'"
|
||||
.br
|
||||
.B "<digit> ::= '0..9'"
|
||||
.br
|
||||
.B "<color> ::= '2'|'16'|'256'|'32k'|'32K'|'64k'|'64K'|'16M'"
|
||||
.br
|
||||
.B "<strg> ::= <empty>|[(<alpha>|'_'){<digit>|<alpha>|'_'}]"
|
||||
.br
|
||||
.B "<alpha> ::= 'a..z'|'A..Z'"
|
||||
|
||||
C style comments will be skipped. See the
|
||||
.I et4000/
|
||||
subdirectory of the svgalib distribution for examples.
|
||||
|
||||
.SH 3. CREATING CARD DEPENDENT REGISTER VALUES
|
||||
|
||||
You may create a
|
||||
.I et4000.regs on your own with the
|
||||
.IR tseng3.exe
|
||||
program. This DOS program and its source is included in the svgalib
|
||||
distribution.
|
||||
|
||||
Just boot MS-DOS and start
|
||||
|
||||
.B tseng3 et4000.reg
|
||||
|
||||
The
|
||||
.I tseng3.exe
|
||||
will measure the video timing for each available mode.
|
||||
Check the
|
||||
.I et4000.regs
|
||||
file against your monitor documentation and
|
||||
disable all non conformant modes, eg.
|
||||
|
||||
.B #define g1024x768x256_regs DISABLE_MODE
|
||||
.br
|
||||
.B /*
|
||||
.br
|
||||
.B static unsigned char g1024x768x256_regs[71] = {
|
||||
.br
|
||||
.B ...
|
||||
.br
|
||||
.B };
|
||||
.br
|
||||
.B */
|
||||
|
||||
will disable the 1024x768x256 mode. You
|
||||
.B mustn't
|
||||
disable the 640x480x256 mode!
|
||||
|
||||
Your
|
||||
.I et4000.regs
|
||||
.I must define the following symbols (register values
|
||||
or
|
||||
.BR "#define ... DISABLE_MODE" )
|
||||
for hard linking:
|
||||
|
||||
.BR g320x200x32K_regs ", " g640x400x256_regs ", " g640x480x256_regs ", "
|
||||
.BR g640x480x32K_regs ", " g640x480x16M_regs ", " g800x600x16_regs ", "
|
||||
.BR g800x600x256_regs ", " g800x600x32K_regs ", " g1024x768x16_regs ", "
|
||||
.BR g1024x768x256_regs ", and " g1280x1024x16_regs .
|
||||
|
||||
and all 64K modes handled like 32K modes by the driver:
|
||||
|
||||
.B #define g320x200x64K_regs g320x200x32K_regs
|
||||
.br
|
||||
.B #define g640x480x64K_regs g640x480x32K_regs
|
||||
.br
|
||||
.B #define g800x600x64K_regs g800x600x32K_regs
|
||||
|
||||
You may omit every unusable mode in
|
||||
.IR /usr/lib/libvga.et4000 .
|
||||
|
||||
.SH 4. DEFINING NEW MODES
|
||||
|
||||
All standard
|
||||
.BR svgalib (7)
|
||||
modes may be selected by the mode constants
|
||||
defined in
|
||||
.B #include<vga.h>
|
||||
(eg.
|
||||
.BR G320x200x16 ).
|
||||
You may define new modes on
|
||||
your own. Just use dynamic register loading and add the register
|
||||
definition of the new mode. Your program may determine the related
|
||||
modenumber by checking the vga_getmodeinfo(1..vga_lastmodenumber()).
|
||||
|
||||
Most ET4000 cards provide 640x350 and 640x400 graphics modes. The
|
||||
.I tseng3.exe
|
||||
generates the related register sets. You may also use
|
||||
.BR dumpreg (1)
|
||||
from an X window to grab you favourite X graphics mode.
|
||||
The X mode normaly isn't usable directly. See
|
||||
.I cardex.w32
|
||||
for an example and
|
||||
.I et4000.c
|
||||
for a brief description of et4000 registers (both files are included in the
|
||||
svgalib distribution).
|
||||
|
||||
.SH 5. REDEFINING STANDARD MODES
|
||||
|
||||
Using dynamic register loading you may redefine any standard VGA
|
||||
mode except of TEXT and 640x480x16. Just add the ET4000 specific
|
||||
register set to
|
||||
.IR /etc/vga/et4000.regs .
|
||||
|
||||
.SH 6. AVAILABLE EXAMPLES
|
||||
|
||||
In the
|
||||
.I et4000/
|
||||
subdir of teh svgalib distribution you'll find some sample register sets:
|
||||
|
||||
.TP
|
||||
.B cardex.w32
|
||||
Cardex ET4000/W32 card, Music TrueColor DAC
|
||||
.TP
|
||||
.B speedstar+
|
||||
SpeedSTAR PLUS card, Normal DAC
|
||||
.TP
|
||||
.B orchid.pdII
|
||||
Orchid Prodesigner II
|
||||
.PP
|
||||
|
||||
.SH 7. ET4000/W32 SUPPORT
|
||||
|
||||
The actual driver seems to be ET4000/W32 compatible. Tell us about
|
||||
any problems (and solutions). If you've got any information about
|
||||
the ET4000/W32 blitter, we would be pleased to receive it.
|
||||
|
||||
.SH 8. PROBLEMS
|
||||
|
||||
As mentioned before, the DAC detection isn't very reliable.
|
||||
.BR vgatest (6)
|
||||
should print equal screens in 256 color and HiColor/TrueColor modes.
|
||||
You may have to edit your
|
||||
.I libvga.et4000
|
||||
register file by hand to setup the correct DAC.
|
||||
|
||||
The
|
||||
.I tseng3.exe
|
||||
may fail due to incompatible mode numbering. You might use
|
||||
a VESA driver (eg. tlivesa.com from VPIC 6.0) or edit and recompile
|
||||
the
|
||||
.IR tseng3.exe .
|
||||
|
||||
Newer ET4000 chipsets (eg. W32 and W32i) allow up to 32 clock
|
||||
frequencies. Two additional register values were added just before the
|
||||
old extened register value. The new registers are CRTC/30h and CRTC/31h.
|
||||
The old register set had 71 values, the new growed to 73.
|
||||
You may update your old register set by hand:
|
||||
|
||||
.IP -
|
||||
run the dumpreg program, remember the first two values from last
|
||||
data line.
|
||||
.IP -
|
||||
edit your libvga:
|
||||
.RS
|
||||
for each mode
|
||||
.RS
|
||||
change the number of register values from 71 to 73
|
||||
.br
|
||||
add the values from dumreg output at front of last data line
|
||||
.RE
|
||||
.RE
|
||||
.IP -
|
||||
run .BR vgatest (6)
|
||||
to check the new register set
|
||||
|
||||
.SH 9. USING DYNAMIC LOADING WITH OTHER CARDS
|
||||
|
||||
The dynamical register loading may be used in other drivers.
|
||||
Since hard linked register values work fine for Cirrus and Trident
|
||||
cards, we didn't include this feature.
|
||||
|
||||
|
||||
.SH FILES
|
||||
.I /etc/vga/libvga.config
|
||||
.br
|
||||
.I /etc/vga/libvga.et4000
|
||||
|
||||
.SH SEE ALSO
|
||||
.BR svgalib (7),
|
||||
.BR libvga.config (5).
|
||||
|
||||
.SH AUTHOR
|
||||
This documentation for the ET4000 registers was provided by Hartmut Schirmer.
|
||||
However, it was slightly reformatted by Michael Weller
|
||||
<eowmob@exp-math.uni-essen.de>.
|
||||
336
doc/man7/svgalib.faq.7
Normal file
336
doc/man7/svgalib.faq.7
Normal file
|
|
@ -0,0 +1,336 @@
|
|||
.TH svgalib.faq 7 "10 Jun 1999" "Svgalib 1.4.1" "Svgalib User Manual"
|
||||
.SH NAME
|
||||
svgalib.faq \- frequently asked questions about svgalib
|
||||
|
||||
.SH INTRODUCTION
|
||||
I (Matan Ziv-Av), added/changed some of the answers in this file, so some
|
||||
answers are mine, and some are Michael's.
|
||||
|
||||
List of (recently) frequently asked questions about svgalib. Esp. about
|
||||
it's status and future. Please note that as of now all answers are just
|
||||
written by me, Michael Weller <eowmob@exp-math.uni-essen.de>. I'd like
|
||||
this to change. So email your suggestion (best of all: question and the
|
||||
answer).
|
||||
|
||||
Also, most questions deal with the status and future and my ideas about
|
||||
it. Necessarily they contain my own private opinions on this. People may
|
||||
disagree and I'm sure I don't have the best ideas about it or may even
|
||||
be completely wrong. I don't want to force anyone to agree with me.
|
||||
|
||||
Also, I was asked about MY opinions, so I'm just presenting them here.
|
||||
|
||||
.SH CONTENTS
|
||||
.TP
|
||||
.B Q 1)
|
||||
I want to write some svgalib application. Where is the documentation?
|
||||
.TP
|
||||
.B Q 2)
|
||||
My board is not supported. What now?
|
||||
.TP
|
||||
.B Q 3)
|
||||
I get:
|
||||
|
||||
.B You must be the owner of the current console to use svgalib.
|
||||
.br
|
||||
.B Not running in a graphics capable console, and unable to find one.
|
||||
|
||||
However, though logged in not directly from the linux console, I
|
||||
am the owner of the console.
|
||||
.TP
|
||||
.B Q 4)
|
||||
Is svgalib dead?
|
||||
.TP
|
||||
.B Q 5)
|
||||
There are so many Xfree drivers, why not just use them.
|
||||
.TP
|
||||
.B Q 6)
|
||||
Why not just use the VGA BIOS?.
|
||||
.TP
|
||||
.B Q 7)
|
||||
What about GGI?
|
||||
.TP
|
||||
.B Q 8)
|
||||
Why not just use X11?
|
||||
.TP
|
||||
.B Q 9)
|
||||
Now, again, what about the future of svgalib?
|
||||
.TP
|
||||
.B Q 10)
|
||||
Ok, just for completeness, what are your plans about svgalib anyway?
|
||||
.TP
|
||||
.B Q 11)
|
||||
Nice plan. But will it become true?
|
||||
.PP
|
||||
|
||||
.SH THE QUESTIONS
|
||||
.SS Q 1)
|
||||
I want to write some svgalib application. Where is the documentation?
|
||||
|
||||
.SS A a)
|
||||
Well, did you really look at everything? The
|
||||
.I 0-README
|
||||
file in the top
|
||||
level directory contains all function prototypes and explanations on
|
||||
how to call them.
|
||||
|
||||
Yes, the documentation is short and/or confusing. Sorry, English is
|
||||
not my native tongue. Many people complain and want to write some
|
||||
better documentation. You are welcome to do so! However, up to now,
|
||||
either people found the documentation sufficient once they looked at
|
||||
the correct files or they just gave up. At least, I never heard from
|
||||
these people again.
|
||||
|
||||
Also, svgalib comes with source. If in doubt: read it.
|
||||
|
||||
Finally: Linux distributions include svgalib, but not the source and
|
||||
README's (or hide them so good noone finds them). Well, no problem,
|
||||
get full svgalib source, demos, readme's from svgalib-*.tar.gz on
|
||||
any Linux FTP server in your vicinity. Even if you don't dare to install
|
||||
or compile it, it contains the readme's.
|
||||
|
||||
Oh yes, there are some simple demos in the
|
||||
.I demos/ subdir. They should
|
||||
get you started.
|
||||
|
||||
When someone writes
|
||||
.BR man (1)
|
||||
manual pages, a distribution might just install
|
||||
them. Please do not complain, write them, mail them to me.
|
||||
|
||||
.SS A b)
|
||||
Finally, I, Michael Weller wrote the manpages. Looking at
|
||||
.BR svgalib (7)
|
||||
should get you started. Additions and corrections are still welcome, of course.
|
||||
|
||||
.SS Q 2)
|
||||
My board is not supported. What now?
|
||||
|
||||
.SS A)
|
||||
Simple:
|
||||
|
||||
.TP
|
||||
.B a)
|
||||
Contact the maintainers (see other README's) and check out if
|
||||
someone is working on a driver.
|
||||
|
||||
.TP
|
||||
.B b)
|
||||
If so, contact them if you like and announce you'd be willing to
|
||||
test things or even help coding.
|
||||
|
||||
.TP
|
||||
.B c)
|
||||
If not, write a driver. Get as many docs on your card as you can,
|
||||
then read and understand the internals of svgalib (again read the
|
||||
README's carefully!).
|
||||
.PP
|
||||
|
||||
Please understand that this is a free project. I will not go and buy
|
||||
a similar card and write a driver for you. I already wrote support for
|
||||
the hardware I have! I just do this as a hobby. Because I don't get
|
||||
paid for this I can not just buy card & docu and spend much much time
|
||||
supporting whatever graphics card on earth exists.
|
||||
|
||||
Also read below on the future of svgalib.
|
||||
|
||||
If you don't feel able to write a driver for whatever reason, please
|
||||
do not complain if other people don't do it for you (because you are
|
||||
not better than they are).
|
||||
|
||||
.SS Q 3)
|
||||
I get:
|
||||
|
||||
.B You must be the owner of the current console to use svgalib.
|
||||
.br
|
||||
.B Not running in a graphics capable console, and unable to find one.
|
||||
|
||||
However, though logged in not directly from the linux console, I
|
||||
am the owner of the console.
|
||||
|
||||
.SS A)
|
||||
Alas, some programs use their suid root privilege and become a full
|
||||
root owned process. svgalib thinks they are run by root which does
|
||||
not own the current console.
|
||||
Defining
|
||||
.B ROOT_VC_SHORTCUT
|
||||
in
|
||||
.I Makefile.cfg
|
||||
and recompiling will allow
|
||||
svgalib to allocate a new VC. However, it will allow any person which
|
||||
is able to exec that program to start in on a new console. Even if not
|
||||
logged in from the console at all. Thus, for security, you need to
|
||||
explicitly enable that root feature.
|
||||
|
||||
.SS Q 4)
|
||||
Is svgalib dead?
|
||||
|
||||
.SS A)
|
||||
This question comes up frequently esp. in recent times.
|
||||
|
||||
The answer is, of course, no.
|
||||
|
||||
.SS Q 5)
|
||||
There are so many Xfree drivers, why not just use them.
|
||||
|
||||
.SS A)
|
||||
Well, actually much of the code in there is actually already used by
|
||||
svgalib. Xfree coders worked on svgalib and vice versa. But honestly, do
|
||||
not expect that a driver from Xfree can just be used for svgalib. The
|
||||
internal structures of Xfree and svgalib (and GGI) are just too
|
||||
different. As a source of knowledge and for one or the other subroutine,
|
||||
the Xfree sources are invaluable however.
|
||||
|
||||
.SS Q 6)
|
||||
Why not just use the VGA BIOS?.
|
||||
|
||||
.SS A)
|
||||
Actually, we do. There is now, thanks to Josh Vanderhoof, a VESA driver.
|
||||
The VESA driver does not work on all cards, even though it should.
|
||||
It does not even work on all cards where vbetest works. If vbetest does
|
||||
not work it means the bios writers assumed it would always run in DOS, and
|
||||
used tricks (for delay, etc.) that can't work under Linux. If vbetest works,
|
||||
but the VESA driver does not, I (Matan Ziv-Av) believe it is due to the
|
||||
following reason:
|
||||
The driver use VESA function 4 (save/restore video state). This function
|
||||
can't be used in a singletasking environment (DOS) and as such, some bios
|
||||
writers failed to implement it properly, and all the tests (which are run
|
||||
under DOS) failed to discover this.
|
||||
|
||||
The VESA driver does work with many cards though.
|
||||
|
||||
.SS Q 7)
|
||||
What about GGI?
|
||||
|
||||
.SS A)
|
||||
Yes, GGI. Another long story. At first: Yes, I like the idea of an
|
||||
in kernel graphics driver. I like it very much. And, yes, this is a
|
||||
bit weird because I am the svgalib maintainer and a working GGI will make
|
||||
svgalib obsolete. Again, I already said above: I did not invent svgalib
|
||||
nor do I promote it as
|
||||
.B the
|
||||
solution (now compare this to GGI). It just
|
||||
does what it does and works for me and some other people.
|
||||
|
||||
I liked this idea so much, I even started coding a frame buffer device
|
||||
once. After a short time, other people came out with the GGI idea. Right
|
||||
from their beginning they claimed to be the only source of wisdom. I
|
||||
tried to join our efforts, but failed. In general we have the same
|
||||
goals (read the GGI project pages for that).
|
||||
|
||||
Anyhow, at that time a flame war started. I don't really know why. I
|
||||
don't see I did anything else than offering my opinions, work and
|
||||
experience. But that should be judged by others.
|
||||
|
||||
Well, after some time I stopped bothering them. I was satisfied to learn
|
||||
later though that they actually came up with some conclusions I proposed
|
||||
first but weeks or months later. But let us leave the past alone.
|
||||
|
||||
.PP
|
||||
When intending to contribute to svgalib, you should think about what you
|
||||
really want. I don't see that GGI is becoming available soon. GGI people
|
||||
told me the opposite again and again, ok, I still don't see it. Still
|
||||
out of a sudden, everything might be GGI infested, so you might consider
|
||||
contributing to GGI instead.
|
||||
|
||||
With svgalib you might be able to use your fruits earlier. And anyone
|
||||
(with supported hardware) can just use it right away without reinstalling kernel/X11
|
||||
what else (maybe being unable to use something he did before).
|
||||
|
||||
.SS Q 8)
|
||||
Why not just use X11?
|
||||
|
||||
Yes, this is what many people say. This is the common Unix way to do it.
|
||||
X does it.
|
||||
|
||||
But X has some drawbacks:
|
||||
|
||||
.IP i)
|
||||
It uses many resources. Admittedly this is becoming of lesser
|
||||
importance now, where you can run a sensible X11 Linux system on
|
||||
8MB (16 MB for heaven like performance) which is the absolute minimum
|
||||
to get a simple text editor running under M$ windows.
|
||||
|
||||
Still, an advantage of Linux is the ability to use old hardware for
|
||||
mission critical background jobs on the net
|
||||
(servers/routers/firewalls) on low price or otherwise even unusable
|
||||
hardware.
|
||||
|
||||
.IP ii)
|
||||
X has a nice API with draw commands for any kind of 'command oriented'
|
||||
screen output. I mean with that: Select a color, draw a line, polygon,
|
||||
etc.
|
||||
|
||||
This imposes a bunch of overhead. If you just want access to the
|
||||
screen memory, it slows things down as hell. If you want just to use
|
||||
above's draw commands, it is ok!
|
||||
|
||||
.IP iii)
|
||||
One can now circumvent the API restrictions by getting direct
|
||||
screen access using a special Xfree extension. Basically Xfree just
|
||||
setups the screen and gives you shared memory access to the screen
|
||||
memory. IMHO, this is not much different from the shared memory X11
|
||||
extension by MIT (which is probably why it was added so easily).
|
||||
Still it needs quite some overhead, at least when the card does not
|
||||
allow for a linear frame buffer.
|
||||
|
||||
However, you cannot change screen modes and rez as easily. This is
|
||||
IMHO THE drawback of X. For a picture viewer, you want 256 color
|
||||
high/true color modes on a per picture basis (also, insert any other
|
||||
application you like: movie viewers, a special game, a drawing
|
||||
program). Also, you want a small picture use a low rez s.t. it does
|
||||
not appear as a thumbnail, maybe use a high rez mode for a huge
|
||||
picture which you don't want to use on a permanent basis because
|
||||
it flickers like hell (and you don't want to use a panning virtual
|
||||
desktop too, I hated them at best).
|
||||
|
||||
This latter restriction can of course be circumvented by enlarging
|
||||
the picture. But this will need much time for a picture viewer
|
||||
already and certainly too much for smooth video or game animations.
|
||||
|
||||
.IP iv)
|
||||
Finally, the problem how X11 itself accesses the screen is not solved.
|
||||
Security is usually no concern because X11 does it, is a trusted
|
||||
executable and a firewall between applications and the hardware.
|
||||
|
||||
Alas, there might be security holes, also the stability and
|
||||
performance issues (IRQ driven accelerator queue, CPU support for
|
||||
VGA memory paging) still exist, though one can expect an Xserver
|
||||
to be a generally well coded application.
|
||||
|
||||
.SS Q 9)
|
||||
Now, again, what about the future of svgalib?
|
||||
|
||||
For console graphics, svgalib is still the only solution for most people,
|
||||
and as such it should go on for a while. Compared to the other console
|
||||
graphics options (kgi and kernel fb device), writing svgalib driver is the
|
||||
simplest (at least, this is my experience), and so it makes sense to believe
|
||||
that svgalib will work on all cards where there is someone interested enough
|
||||
in that support.
|
||||
|
||||
.SS Q 10)
|
||||
Ok, just for completeness, what are your plans about svgalib anyway?
|
||||
|
||||
First, make svgalib cooperate nicely with kernel fb device. Then (and it should
|
||||
be very similiar) make svgalib work on a secondary vga card.
|
||||
|
||||
A rewrite of the code for memory handling and virtual console handling is necessary
|
||||
for the previous goals, but is also necessary in itself, and so will be done
|
||||
also.
|
||||
|
||||
I do intend to maintain complete binary compatibility, so that older programs
|
||||
will go on working.
|
||||
|
||||
As internal changes are made, the drivers have to be changed as well. For some
|
||||
of the older drivers (ali, ark, ati, et3000, et4000, gvga, oak), I no longer get
|
||||
any reports, so I don't know if they still work. Some features are also lost,
|
||||
for example, linear frame buffer on non-PCI cards. This should not be a very
|
||||
big problem, as users with such cards can go on using 1.3.1, as most changes
|
||||
are not applicable for older machines.
|
||||
|
||||
.SH SEE ALSO
|
||||
.BR svgalib (7),
|
||||
.BR libvga.config (5).
|
||||
|
||||
.SH AUTHOR
|
||||
This file was written by Michael Weller <eowmob@exp-math.uni-essen.de>,
|
||||
And later changed by Matan Ziv-Av.
|
||||
876
doc/man7/svgalib.mach32.7
Normal file
876
doc/man7/svgalib.mach32.7
Normal file
|
|
@ -0,0 +1,876 @@
|
|||
.TH svgalib.mach32 7 "1 August 1997" "Svgalib (>= 1.2.11)" "Svgalib User Manual"
|
||||
.SH NAME
|
||||
svgalib.mach32 \- Information on the Mach32 chipset driver
|
||||
|
||||
.SH TABLE OF CONTENTS
|
||||
.BR " 0. " "Introduction"
|
||||
.br
|
||||
.BR " 1. " "Specifying pixel clocks"
|
||||
.br
|
||||
.BR " 2. " "Copyrights"
|
||||
.br
|
||||
.BR " 3. " "The mach32info utility"
|
||||
.br
|
||||
.BR " 4. " "Third party cards"
|
||||
.br
|
||||
.BR " 5. " "Logical linewidth"
|
||||
.br
|
||||
.BR " 6. " "Noisy video signals"
|
||||
.br
|
||||
.BR " 7. " "The configuration EEPROM"
|
||||
.br
|
||||
.BR " 8. " "EEPROM woes"
|
||||
.br
|
||||
.BR " 9. " "The Mach32Eeprom command"
|
||||
.br
|
||||
.BR "10. " "Setup of the memory aperture (linear framebuffer)"
|
||||
.br
|
||||
.BR "11. " "Accelerator support and other weird features"
|
||||
.br
|
||||
.BR "12. " "Ramdacs"
|
||||
.br
|
||||
.BR "13. " "Meaning of the detection message from svgalib"
|
||||
.br
|
||||
.BR "14. " "Conclusions"
|
||||
|
||||
.SH 0. INTRODUCTION
|
||||
The driver should allow you to use any of the graph-modes
|
||||
your Mach32 card supports. Note that there is no support for
|
||||
<8bpp modes and that I won't ever implement that because I don't see
|
||||
any reason for doing so. All standard VGA-modes are supported, of course
|
||||
(by using the standard VGA driver routines).
|
||||
|
||||
If you configured your Mach32 for a memory aperture and it is
|
||||
at least as big as the memory of your card (that is, not a 1MB
|
||||
memory aperture for a 2MB card) support for linear frame buffer
|
||||
access of svgalib is given.
|
||||
|
||||
Auto detection of the Mach32 seems not to work on all cards. That's
|
||||
really strange since I got the code from the X people. It should be OK
|
||||
regardless of my docs. Well, I fixed that (hopefully). Actually
|
||||
the bug was found by Daniel Lee Jackson (djackson@ichips.intel.com).
|
||||
(Thanks again.. It was so silly... I would have never found it)
|
||||
If you still have problems just put a chipset Mach32 in your config file.
|
||||
|
||||
.SH 1. SPECIFYING PIXEL CLOCKS
|
||||
.B WARNING!
|
||||
The Mach32 driver needs to know correct clock frequencies for graceful
|
||||
DAC configuration. Wrong clocks may damage your card! However, this version
|
||||
contains code for automatic clock detection. Since clock detection is time
|
||||
critical, please do it on a completely idle system. Then put the printed
|
||||
out
|
||||
.B clocks
|
||||
line in your
|
||||
.BR libvga.config (5)
|
||||
file.
|
||||
|
||||
The driver tries to do this for you.
|
||||
After that, you can restart whatever svgalib program you used and you are
|
||||
set. If you already put a
|
||||
.B clocks
|
||||
line in your config by hand, comment it
|
||||
out to have the driver check your clocks.
|
||||
|
||||
Since clock probing is time critical, values differ from time to time, you
|
||||
may try it multiple times and see which values seem to be most exact. You
|
||||
can also compare them with the standard clock chips for Mach32 cards in
|
||||
.BR libvga.config (5)).
|
||||
|
||||
The clock probing relies on the 7th clock being 44.9MHz as this is what Xfree does.
|
||||
If this is not true (and it is not always), probing is hosed. See
|
||||
.BR libvga.config (5)
|
||||
for a list of the
|
||||
.B clocks
|
||||
used by common svgalib cards.
|
||||
|
||||
.SH 2. COPYRIGHTS
|
||||
Some tiny routines are copied from Xfree86. The clock detection code is almost
|
||||
just copied. So I repeat the copyright statements for these parts here:
|
||||
|
||||
Copyright 1992 by Orest Zborowski <obz@Kodak.com>
|
||||
.br
|
||||
Copyright 1993 by David Wexelblat <dwex@goblin.org>
|
||||
|
||||
Permission to use, copy, modify, distribute, and sell this software and its
|
||||
documentation for any purpose is hereby granted without fee, provided that
|
||||
the above copyright notice appear in all copies and that both that
|
||||
copyright notice and this permission notice appear in supporting
|
||||
documentation, and that the names of Orest Zborowski and David Wexelblat
|
||||
not be used in advertising or publicity pertaining to distribution of
|
||||
the software without specific, written prior permission. Orest Zborowski
|
||||
and David Wexelblat make no representations about the suitability of this
|
||||
software for any purpose. It is provided "as is" without express or
|
||||
implied warranty.
|
||||
|
||||
.B Orest Zborowski and David Wexelblat disclaim all warranties with regard
|
||||
.B to this software, including all implied warranties of merchantability and
|
||||
.B fitness, in no event shall Orest Zborowski or David Wexelblat be liable
|
||||
.B for any special, indirect or consequential damages or any damages
|
||||
.B whatsoever resulting from loss of use, data or profits, whether in an
|
||||
.B action of contract, negligence or other tortious action, arising out of
|
||||
.B or in connection with the use or performance of this software.
|
||||
|
||||
Copyright 1990,91 by Thomas Roell, Dinkelscherben, Germany.
|
||||
.br
|
||||
Copyright 1993 by Kevin E. Martin, Chapel Hill, North Carolina.
|
||||
|
||||
Permission to use, copy, modify, distribute, and sell this software and its
|
||||
documentation for any purpose is hereby granted without fee, provided that
|
||||
the above copyright notice appear in all copies and that both that
|
||||
copyright notice and this permission notice appear in supporting
|
||||
documentation, and that the name of Thomas Roell not be used in
|
||||
advertising or publicity pertaining to distribution of the software without
|
||||
specific, written prior permission. Thomas Roell makes no representations
|
||||
about the suitability of this software for any purpose. It is provided
|
||||
"as is" without express or implied warranty.
|
||||
|
||||
.B Thomas Roell, Kevin E. Martin, and Rickard E. Faith disclaim all
|
||||
.B warranties with regard to this software, including all implied
|
||||
.B warranties of merchantability and fitness, in no event shall the authors
|
||||
.B be liable for any special, indirect or consequential damages or any
|
||||
.B damages whatsoever resulting from loss of use, data or profits, whether
|
||||
.B in an action of contract, negligence or other tortious action, arising
|
||||
.B out of or in connection with the use or performance of this software.
|
||||
|
||||
Author: Thomas Roell, roell@informatik.tu-muenchen.de
|
||||
|
||||
Rewritten for the 8514/A by Kevin E. Martin (martin@cs.unc.edu)
|
||||
.br
|
||||
Modified for the Mach-8 by Rickard E. Faith (faith@cs.unc.edu)
|
||||
.br
|
||||
Rewritten for the Mach32 by Kevin E. Martin (martin@cs.unc.edu)
|
||||
|
||||
And here is my own copyright:
|
||||
|
||||
This driver is free software; you can redistribute it and/or
|
||||
modify it without any restrictions. This library is distributed
|
||||
in the hope that it will be useful, but without any warranty.
|
||||
|
||||
Copyright 1994 by Michael Weller
|
||||
|
||||
Email addresses as of this writing:
|
||||
|
||||
eowmob@exp-math.uni-essen.de mat42b@spi.power.uni-essen.de
|
||||
|
||||
.B Michael Weller disclaims all warranties with regard
|
||||
.B to this software, including all implied warranties of merchantability and
|
||||
.B fitness, in no event shall Michael Weller be liable
|
||||
.B for any special, indirect or consequential damages or any damages
|
||||
.B whatsoever resulting from loss of use, data or profits, whether in an
|
||||
.B action of contract, negligence or other tortious action, arising out of
|
||||
.B or in connection with the use or performance of this software.
|
||||
|
||||
.SH 3. THE MACH32INFO UTILITY
|
||||
The
|
||||
.BR mach32info (6)
|
||||
utility or demo reads out all configuration registers and the configuration
|
||||
EEPROM of your Mach32 card. If
|
||||
there is a problem with the particular card you have, compile
|
||||
and run the utility in the
|
||||
.I mach32/
|
||||
directory of the svgalib distribution and send it's stdout to me
|
||||
This might also be useful if you need a lot of options (e.g. clocks on new models?) to
|
||||
get it to work so that this can be done automatically in future versions.
|
||||
|
||||
.SH 4. THIRD PARTY CARDS
|
||||
I got a few reports about AST systems with onboard Mach32.
|
||||
They do feature an incompatible EEPROM setup, but I think I got around
|
||||
that. Nevertheless the Mach32 chipset driver doesn't work out of the box
|
||||
on any AST system I heard of.
|
||||
|
||||
Since original ATI Mach32 demos and tools don't work as well, I've to claim
|
||||
that the Mach32 on these AST systems does not conform to ATI's Mach32 docs.
|
||||
Fortunately, Vernon C. Hoxie <vern@zebra.alphacdc.com> found a work around
|
||||
after years (really!) of investigating. AST Mach32 seems to work now. The work around was
|
||||
also submitted to Xfree and will be incorporated to allow running it on the
|
||||
AST hardware too in recent versions. Please read on the
|
||||
.B misc_ctl
|
||||
command below.
|
||||
|
||||
Dell users should have a look at the
|
||||
.BR "vendor" ", " ramdac ", and " svgaclocks
|
||||
commands below (if they have problems with the default settings).
|
||||
|
||||
.SS Commands to support third party cards
|
||||
I had to learn that those cards seem
|
||||
to use not only non standard clocks for the Mach32, but also for the included
|
||||
SVGA. However, since people often like to use proprietary, non standard VGA
|
||||
(read 80x25) textmodes, the Mach32 driver has to set the included SVGA to
|
||||
a VGA compatible clock frequency. Otherwise svgalib has problems using plain VGA
|
||||
modes. This screws VGA modes up if these clocks have different values on third
|
||||
party Mach32 cards.
|
||||
|
||||
.TP
|
||||
.BI "svgaclocks " n
|
||||
with
|
||||
.I n
|
||||
a number between
|
||||
.BR 0 " and " 31
|
||||
to select the svga clocks to be used in vga
|
||||
modes. The bits of
|
||||
.I n
|
||||
refer to specific ATI register bits to complicated to
|
||||
explain here. Even if I would, I can't tell which clocks they would select
|
||||
on your third party card (which is the actual problem)
|
||||
|
||||
.B svgaclocks 9
|
||||
is the default setting and correct for original ATI cards.
|
||||
|
||||
Often
|
||||
.B svgaclocks 0
|
||||
(Dell cards) works.
|
||||
.TP
|
||||
.B svgaclocks keep
|
||||
is special in that the
|
||||
driver will not touch any SVGA timings. This requires the Mach32 SVGA part to
|
||||
be in a VGA compatible mode when the svgalib application is started, that is,
|
||||
you must use 80x25 (maybe 80x50) console textmodes.
|
||||
.PP
|
||||
|
||||
As I mentioned already,
|
||||
Vernon C. Hoxie <vern@zebra.alphacdc.com> really seems to have located the reason
|
||||
for the Mach32 AST problems. Any access to
|
||||
.B MISC_CTL
|
||||
locks up the card & system. Fortunately
|
||||
.B MISC_CTL
|
||||
is only used for some DAC fine tuning (actually the setting you can
|
||||
fine tune with the
|
||||
.B blank
|
||||
command) which is only of barely noticable effect to the screen.
|
||||
|
||||
The following configuration commands exist to support AST cards:
|
||||
|
||||
.TP
|
||||
.B misc_ctl keep-off
|
||||
Do not dare to touch MISC_CTL.
|
||||
.TP
|
||||
.B misc_ctl use
|
||||
Use it for fine tuning of the Ramdac setup (default).
|
||||
.PP
|
||||
|
||||
Finally, for your convenience there exist:
|
||||
|
||||
.PD 0
|
||||
.TP
|
||||
.B vendor ati
|
||||
.TP
|
||||
.B vendor dell
|
||||
.TP
|
||||
.B vendor ast
|
||||
.PD
|
||||
These are macros that expand to settings for
|
||||
.BR svgaclocks ", " ramdac ", " misc_ctl ", and " mach32eeprom
|
||||
that are usually correct for ATI, Dell, AST cards. Be aware
|
||||
that they really work like macros. That is, they override any setting
|
||||
of
|
||||
.BR svgaclocks ", " ramdac ", " misc_ctl ", and " mach32eeprom
|
||||
made before them and individual aspects will be changed by a following
|
||||
.BR svgaclocks ", " ramdac ", " misc_ctl ", and " mach32eeprom
|
||||
command.
|
||||
|
||||
Note that the
|
||||
.B mach32eeprom ignore
|
||||
required for some Dell cards requires
|
||||
you to include explicit timings for Mach32 modes other than 640x480x256.
|
||||
The
|
||||
.I mach32/mach32.std-modes
|
||||
file in the svgalib distribution contains recommendations for modes from ATI.
|
||||
|
||||
I heard about a bug in some ATI chipsets returning wrong memory amounts
|
||||
configs. (But cannot confirm that)
|
||||
|
||||
You can enforce correct chipset identification from the configuration file:
|
||||
|
||||
.TP
|
||||
.BI "chipset Mach32 " "chiptype memory"
|
||||
where
|
||||
.I chiptype
|
||||
is the sum of at exactly one value from each of the following two groups
|
||||
|
||||
.PD 0
|
||||
.RS
|
||||
.TP
|
||||
.B 128
|
||||
use no memory aperture.
|
||||
.TP
|
||||
.B 160
|
||||
use a 1MB memory aperture.
|
||||
.TP
|
||||
.B 192
|
||||
use a 4MB memory aperture.
|
||||
.TP
|
||||
.B 0
|
||||
choose size for the memory aperture automatically.
|
||||
.PD
|
||||
.PP
|
||||
and
|
||||
|
||||
.PD 0
|
||||
.TP
|
||||
.B 16
|
||||
Ramdac is of type 0 (ATI68830)
|
||||
.TP
|
||||
.B 17
|
||||
Ramdac is of type 1 (IMS-G173, SC11486)
|
||||
.TP
|
||||
.B 18
|
||||
Ramdac is of type 2 (ATI68875, TLC34075)
|
||||
.TP
|
||||
.B 19
|
||||
Ramdac is of type 3 (INMOS176, INMOS178)
|
||||
.TP
|
||||
.B 20
|
||||
Ramdac is of type 4 (Bt481, Bt482)
|
||||
.TP
|
||||
.B 21
|
||||
Ramdac is of type 5 (ATI68860)
|
||||
.TP
|
||||
.B 0
|
||||
Ramdac type is queried from Mach32 chip.
|
||||
.PD 1
|
||||
.RE
|
||||
|
||||
.IP
|
||||
.I memory
|
||||
is the amount of videomemory in KB.
|
||||
.PP
|
||||
Note that the type of the ramdac can be set more conveniently with the
|
||||
.B ramdac
|
||||
command.
|
||||
|
||||
.SH 5. LOGICAL LINEWIDTH
|
||||
At least my VRAM card seems to be very peculiar about logical
|
||||
linewidths. From my experience a multiple of 64 pels is needed.
|
||||
Your mileage may vary. Use the config file options to adjust it
|
||||
and tell me if your card needs a different value. Include the name and
|
||||
model number of the card and what the correct numbers should be. This
|
||||
is so that I can correct the auto configuration of the driver.
|
||||
|
||||
If some svgalib application has problems, note that you can
|
||||
force the logical linewidth to the default value from the
|
||||
configfile. Probably this will lead to glitches in some 800x600
|
||||
resolutions. You can
|
||||
.B inhibit
|
||||
these resolutions from the configfile
|
||||
as well. Apropos glitches, I found no guidelines as to what clockrates
|
||||
to use due to memory restrictions. I adjusted the driver, such that
|
||||
I get a stable pic in all resolutions. However sometimes the screen
|
||||
is disturbed by heavy video memory accesses. If you don't like that,
|
||||
reduce the clocks used with the maxclock16 or maxclock24 command, resp.
|
||||
This may of course lead to none of the predefined modes being used.
|
||||
Then you can try to define your own mode via the define command.
|
||||
|
||||
.SH 6. NOISY VIDEO SIGNALS
|
||||
If you get some flicker or heavy noise on your screen, some fine tuning may
|
||||
be needed. My docs didn't give me hints as to what each card can stand.
|
||||
Especially DRAM cards may give problems (I've VRAM). In that case, use the
|
||||
fine tuning config commands and send me your results along with the output
|
||||
of
|
||||
.BR mach32info (6).
|
||||
Then I can include them in my next release.
|
||||
|
||||
.SS Fine-tuning configuration commands
|
||||
|
||||
First you should think about the
|
||||
.B maxclock*
|
||||
configuration commands to reduce pixel clocks used for each color depth.
|
||||
|
||||
Especially important for DRAM cards is the video FIFO depth used to queue
|
||||
memory values for writing to the screen. Here is a command to set this
|
||||
value for the 8bpp modes:
|
||||
|
||||
.TP
|
||||
.BI "vfifo8 " number
|
||||
where
|
||||
.I number is in range
|
||||
.BR 0 " - " 15 .
|
||||
The default is now 6.
|
||||
|
||||
Since vfifo is of some impact to the speed of the card, tell me the
|
||||
lowest setting that satisfies your card.
|
||||
|
||||
For 16/24/32 modes, there are non-zero values preset from internal tables and
|
||||
the EEPROM, however you can enforce minimal vfifo values with:
|
||||
.PP
|
||||
.BI "vfifo16 " number
|
||||
.br
|
||||
.BI "vfifo24 " number
|
||||
.br
|
||||
.BI "vfifo32 " number
|
||||
|
||||
.TP
|
||||
.BI "blank " number
|
||||
where
|
||||
.I number
|
||||
is
|
||||
.BI "4 * " pixel_delay " + " blank_adjust
|
||||
where
|
||||
.IR pixel_delay " and " blank_adjust
|
||||
are in range
|
||||
.BR 0 " .. " 3 .
|
||||
.I pixel_delay
|
||||
delays pixels before they are sent to the DAC and
|
||||
.I blank_adjust
|
||||
adjusts the blank pulse for type 2 DAC's.
|
||||
.B blank
|
||||
should be set correctly for each DAC type automatically.
|
||||
So use it only as a last resort.
|
||||
|
||||
.TP
|
||||
.BI "latch " number
|
||||
where
|
||||
.I number
|
||||
is the sum of zero or more of the following numbers:
|
||||
.RS
|
||||
.TP
|
||||
.B 128
|
||||
VRAM serial delay latch enable, DRAM latch bits 63 - 0 enable.
|
||||
.TP
|
||||
.B 4096
|
||||
Latch video memory data.
|
||||
.TP
|
||||
.B 8192
|
||||
Memory data delay latch enable for data bits 63 - 0.
|
||||
.TP
|
||||
.B 16384
|
||||
Memory full clock pulse enable.
|
||||
.RE
|
||||
.IP
|
||||
Default is to switch all settings on (they are on on my card by default anyway).
|
||||
.PP
|
||||
|
||||
Note that these commands may vanish again once they are no longer needed for
|
||||
debugging purposes.
|
||||
|
||||
There is no 320x200 mode in the EEPROM of the Mach32 at all, however
|
||||
I defined one in the default configuration file for you. This is the best
|
||||
thing I could get up on my card/screen. Note that it will probably
|
||||
have big borders on your screen, and black lines in between the pixel lines.
|
||||
This is because of the lack of low clocks < 16MHz on the Mach32 and the
|
||||
lack of a line doubling mode as VGA has. The Mach32 is not intended
|
||||
for such low resolutions. If you find a better mode or have an idea,
|
||||
please let me know. You can also just remove my timings from the
|
||||
default configuration file.
|
||||
|
||||
.SH 7. THE CONFIGURATION EEPROM
|
||||
Ah yes, about the EEPROM, I figured out how to read out the Mach32
|
||||
EEPROM. I did it by disassembling the BIOS routine mentioned in the
|
||||
docs. I then redid it in C. The driver will use everything it finds
|
||||
there.
|
||||
|
||||
Use the Mach32 install tools (they should have reached you together with
|
||||
your Mach32 VGA card) to setup your card/monitor combo correctly.
|
||||
The
|
||||
.B monitors
|
||||
setting from the config file (or default of 35kHz or something)
|
||||
will be obeyed by the driver nevertheless (for safety!).
|
||||
|
||||
As you probably know already, accessing the EEPROM causes some screen
|
||||
flickering. If this annoys you (or even worse your monitor) have a look
|
||||
at the
|
||||
.B mach32eeprom
|
||||
command described below. This allows you to put the data from the
|
||||
EEPROM into a file and which can be read whenever it is required.
|
||||
|
||||
Don't even think about changing the contents of the file. (There is
|
||||
an easily faked checksum in it.). Anyway the driver ensures (hopefully)
|
||||
that no damage can be caused.
|
||||
|
||||
Also, if some mode is not well aligned on your screen or you don't like
|
||||
it's sync frequency, consider using the Mach32 install utility (setup for
|
||||
custom monitor) and set one up interactively. If there is no valid faster
|
||||
(higher VSYNC) standard mode given in the EEPROM the driver will use
|
||||
that mode. You will find that this is fun compared with calculating video
|
||||
timings for
|
||||
.IR /etc/XF86Config " or " /etc/vga/libvga.config .
|
||||
|
||||
However the install utility does restrict the maximum pixel depth for
|
||||
custom modes sometimes unneeded hard and the driver obeys that.
|
||||
(Hmm.. actually it should be smart enough to decide itself which pixel
|
||||
depth it can use in that mode.)
|
||||
Since the standard modes are usually only slightly shifted to one side
|
||||
a file with the configuration commands representing the standard modes is given
|
||||
in
|
||||
.I mach32/mach32.std-modes
|
||||
in the svgalib distribution. You can use these as a starting point.
|
||||
|
||||
But here are some real problems:
|
||||
|
||||
.SH 8. EEPROM WOES
|
||||
I got 2 reports of people having problems with incorrect EEPROM checksums.
|
||||
Both had motherboards with onboard Mach32 VGA's from AST. I guessed a checksum
|
||||
algorithm from those reports and put this in the code in addition to the
|
||||
standard ATI style. Still I got a report of someone whose EEPROM was completely
|
||||
empty. If you have problems with checksums send me the output of
|
||||
.BR mach32info (6)
|
||||
and I'll see what I can do.
|
||||
|
||||
By default svgalib writes a complaining message and ignores the contents.
|
||||
You can have svgalib ignore the checksum and contents with the configuration command
|
||||
|
||||
.B mach32eeprom ignore
|
||||
|
||||
Then you can decide to use the partial info that is still in it. Use
|
||||
|
||||
.B mach32eeprom ignore usetimings
|
||||
|
||||
to use the videomodes that are defined in the EEPROM (if no better modes are
|
||||
known by the driver). This is usually safe, because the driver knows
|
||||
which modes are safe for your hardware (if
|
||||
.BR clocks ", " monitor " and " ramdac
|
||||
are configured correctly). You can also allow the driver to use the
|
||||
configuration for the linear frame buffer in the EEPROM:
|
||||
|
||||
.B mach32eeprom ignore useaperture
|
||||
|
||||
or
|
||||
|
||||
.B mach32eeprom ignore usetimings useaperture
|
||||
|
||||
However I discourage this because the driver will just enable what the EEPROM
|
||||
says about the aperture. Use
|
||||
.BR mach32info (6)
|
||||
to check the address it will choose is safe. It might be
|
||||
better to use
|
||||
.B setuplinear
|
||||
to set up a 4MB aperture at a free address range.
|
||||
|
||||
.SH 9. THE MACH32EEPROM COMMAND
|
||||
The
|
||||
.B mach32eeprom
|
||||
allows to work around these problems. Here is the complete description for this
|
||||
configuration command.
|
||||
|
||||
.TP
|
||||
.BI "mach32eeprom " filename
|
||||
The
|
||||
.I filename
|
||||
has to begin with a "/".
|
||||
|
||||
Unfortunately reading the EEPROM causes annoying
|
||||
screen flickering and is slow.
|
||||
To avoid this, specify a
|
||||
.I filename
|
||||
from which to read the contents of the
|
||||
EEPROM.
|
||||
|
||||
If the file cannot be read, the EEPROM is read out and the file
|
||||
is created. There is a very simple checksum put into this file. Although
|
||||
it can easily be fooled, don't change the file except you know
|
||||
.B very, very
|
||||
well what you are doing.
|
||||
|
||||
Also, as long as the file exists, changes in the
|
||||
Mach32's EEPROM are ignored. Delete the file to recreate an updated
|
||||
version on next use of svgalib. You should ensure that the permissions of
|
||||
the file don't allow normal users to change it. (This may happen if umask
|
||||
has a bad value when svgalib creates the file).
|
||||
|
||||
Example:
|
||||
|
||||
.B mach32eeprom /etc/vga/mach32.eeprom
|
||||
|
||||
.PP
|
||||
|
||||
Due to problems with some boards this command got
|
||||
heavily expanded:
|
||||
|
||||
.TP
|
||||
.BI "mach32eeprom " subcommand1 " [" subcommand2 "...]"
|
||||
At least one
|
||||
.I subcommand
|
||||
is needed. Valid
|
||||
.I subcommands
|
||||
are:
|
||||
|
||||
.RS
|
||||
.TP
|
||||
.B ignore
|
||||
Don't complain about checksum and don't use any EEPROM contents.
|
||||
.TP
|
||||
.B useaperture
|
||||
Use the configuration for the memoryaperture given in the EEPROM.
|
||||
.TP
|
||||
.B usetimings
|
||||
Use videomodes found in the EEPROM of the board.
|
||||
.TP
|
||||
.B nofile
|
||||
Forget about any filename that maybe was already configured.
|
||||
Don't read a file, don't create one.
|
||||
.TP
|
||||
.BI "file " filename
|
||||
Newstyle form to specify the
|
||||
.IR filename ;
|
||||
On contrary to the
|
||||
.BI "mach32eeprom " filename
|
||||
form it can be mixed with any other
|
||||
mach32eeprom subcommand.
|
||||
.TP
|
||||
.B updatefile
|
||||
Don't read the file, always read the EEPROM (except when
|
||||
.B ignore
|
||||
is given) and create an
|
||||
uptodate image of the EEPROM.
|
||||
.TP
|
||||
.B keepfile
|
||||
Disable all previous updatefile commands.
|
||||
.TP
|
||||
.B compatible
|
||||
Fall back to default behavior: If checksum on the EEPROM data is not ok, use nothing of the
|
||||
configuration data. If it is ok, configure everything as specified in the EEPROM.
|
||||
.RE
|
||||
.IP
|
||||
The subcommands are intended to be used together and are performed in the order
|
||||
specified. For example:
|
||||
|
||||
.B mach32eeprom ignore useaperture usetimings
|
||||
|
||||
will ignore the checksum of your EEPROM, but use its contents.
|
||||
Order is vital! So:
|
||||
|
||||
.B mach32eeprom useaperture usetimings ignore
|
||||
|
||||
won't use any configuration from your EEPROM. Be careful with the
|
||||
.B useaperture
|
||||
subcommand. Please see the
|
||||
.B EEPROM WOES
|
||||
section. Note that any non
|
||||
understood
|
||||
.I subcommand
|
||||
will terminate the
|
||||
.B mach32eeprom
|
||||
command silently! Use only one
|
||||
.I subcommand
|
||||
per
|
||||
.B mach32eeprom
|
||||
command to avoid this.
|
||||
|
||||
The
|
||||
.B mach32eeprom
|
||||
command is usually not allowed in the environment variable
|
||||
.BR SVGALIB_CONFIG .
|
||||
|
||||
.SH 10. SETUP OF THE MEMORY APERTURE (LINEAR FRAMEBUFFER)
|
||||
|
||||
Due to poor design, Xfree86 insists on setting up the aperture itself. It
|
||||
doesn't reset the original settings at a VC switch once it runs. You
|
||||
should not start X for the first time after a boot as long as an svgalib
|
||||
application is running. This will result in pre X values being restored at a VC
|
||||
switch by svgalib. If you use svgalib and XF86_Mach32 together, run X first or
|
||||
at least do not start it while any svgalib appl. is still running. After X was
|
||||
started once you can use svgalib and X in all combinations w/o any problems. Xfree
|
||||
uses whatever address is given in
|
||||
the
|
||||
.B MEM_CFG
|
||||
Mach32 register for a 4MB aperture, even if the aperture is not already enabled and
|
||||
the value in this register is pointless garbage. This is IMHO
|
||||
a dangerous bug as some systems may work only with a 1MB aperture.
|
||||
|
||||
However, usage of a correct EEPROM circumvents any such problems. If you
|
||||
cannot use that, use
|
||||
.B mach32info (6)
|
||||
to find the address in
|
||||
.B MEM_CFG.
|
||||
Then,
|
||||
.BR "if it is a senseable setting for your system" ,
|
||||
enable a 4MB aperture at that address with
|
||||
.BR setuplinear .
|
||||
Ensure that no other card or memory uses the address range you choose.
|
||||
|
||||
.SH 11. ACCELERATOR SUPPORT AND OTHER WEIRD FEATURES
|
||||
This version now has support for all accelerator functions of svgalib.
|
||||
However they were intended for use with the cirrus chips. It may happen
|
||||
that at runtime they find they cannot emulate the function actually
|
||||
requested. Then you should disable the corresponding blit function
|
||||
(at least for that application) with the blit config command.
|
||||
|
||||
Data transfer between the host and the Mach32 is normally via I/O. This
|
||||
proved to be pretty slow. If a big enough aperture is available, a simple
|
||||
memory copy is used instead. This is usually much faster. You can change
|
||||
which method is used with the blit command. This I/O option affects only
|
||||
.BR vga_imageblt (3).
|
||||
The other functions are incredible fast.
|
||||
|
||||
For type 2 DACS, there is support for 8 bit per color (instead of the normal 6)
|
||||
in the RGB triple in the color lookup table of the 256 color modes. This
|
||||
can be enabled by an application, if it supports it. The
|
||||
.BR testaccel (6)
|
||||
demo uses it if supported by your hardware.
|
||||
You can use
|
||||
.BR vga_ext_set (3)
|
||||
to use it from your programs.
|
||||
|
||||
.SH 12. RAMDACS
|
||||
Mach32 Ramdacs are specified by a type in range 1 .. 5. This type can be
|
||||
queried from the Mach32 and then specifies how to set up the ramdac. A list
|
||||
of actual hardware chips used for each type exists, but is not of much use. The
|
||||
Mach32 will return a type and the ramdac will be completely hardware compatible to
|
||||
one of the given type.
|
||||
|
||||
Type 1 and 4 Dacs need different clock frequencies for high colormodes.
|
||||
For 32K/64K colormodes the frequencies have to be doubled and for
|
||||
16M colors (type 4 only) they have to be tripled. I followed the ATI scheme
|
||||
and did this internally. However this means that for 32K/64K you can use
|
||||
only clocks for which the doubled frequencies can be generated as well.
|
||||
|
||||
This is no hard restriction as the 16 clocks of the Mach32 can be divided by 2.
|
||||
Thus if you setup some mode yourself try to use one of the divided clocks in
|
||||
your timings and I can use the undivided clocks internally.
|
||||
|
||||
It is a real restriction for 16M colors. ATI themself only supports 25MHz
|
||||
(640x480) here by use of a 75MHz clock. Depending on your clock chip other
|
||||
values may be usable as well. Even the doubled/tripled clocks have to be less
|
||||
than the magic 80 MHz. However the driver does all this itself. It may just
|
||||
happen that some of the predefined or one of your handmade mode-timings
|
||||
can't be used because the clock that is used cannot be doubled/tripled.
|
||||
Even though there is already some tolerance in the driver you may fix that by
|
||||
slighty changing the clock values that you set with the
|
||||
.B clocks
|
||||
command. But
|
||||
note that this will as well affect the ability of the driver to calculate
|
||||
video timings and thus it ability to check the monitor and DAC safety
|
||||
restrictions.
|
||||
|
||||
In addition (in complete contrast to my original ATI docs) RAMDAC 4 does not support
|
||||
RGB with blue byte first but only with red first. This required special handling and me
|
||||
adding a bunch of functions to all modules of svgalib and vgagl. The added functions are
|
||||
of lower performance than the usual functions. However most data has to be completely
|
||||
mangled, so I doubt that it can be done much faster. Sorry.
|
||||
|
||||
Of course, I might have
|
||||
forgotten to port some parts or even confused things. About bugs in the gl and drawing
|
||||
libs, please ask Harm.
|
||||
But then, I'm able to emulate a BGR ramdac on my card, so I should
|
||||
even be able to reproduce your problems.
|
||||
|
||||
Recently I hear often about type 6 ramdacs in non ATI Mach32 cards. There exists
|
||||
no info about these dacs, thus I cannot support them. The driver assumes unknown
|
||||
DACs can stand up to 80MHz in 256 color clut modes and does not touch the
|
||||
ramdac (that is, assumes it is in the 256 color mode already)
|
||||
|
||||
To get rid of the warning message you can use the
|
||||
|
||||
.TP
|
||||
.BI "ramdac " n
|
||||
configuration command. It allows to explicitly set the type of the dac to
|
||||
.I n
|
||||
(in range
|
||||
.BR 0 " to " 5).
|
||||
.B Ramdac 3
|
||||
is the most dumbest ramdac possible, s.t. you can use
|
||||
it without any fear for your hardware.
|
||||
.TP
|
||||
.B ramdac dumb
|
||||
is equivalent to
|
||||
.BR "ramdac 3" .
|
||||
.TP
|
||||
.B ramdac auto
|
||||
switches back to the default autodetection.
|
||||
.SH 13. MEANING OF THE DETECTION MESSAGE FROM SVGALIB
|
||||
Some programs (which do not switch it off) will show a
|
||||
|
||||
.BI "Using Mach32 " version " (" size "M at " adr "M (" how "), " mem "K mem, DAC " dactype )
|
||||
|
||||
line. This will show up in
|
||||
.BR testlinear (6)
|
||||
etc but will probably scroll away when you use
|
||||
.BR vgatest (6).
|
||||
In this line:
|
||||
|
||||
.TP
|
||||
.I version
|
||||
is the version of the driver (as of my counting, not the svgalib
|
||||
version).
|
||||
.TP
|
||||
.I size
|
||||
is the size of the memory aperture. It can be
|
||||
.BR 1 " or " 4 " (" 1
|
||||
will lead to not using the linear aperture if your card has more than 1MB
|
||||
memory, however applications can still use the 1MB aperture and page
|
||||
the video memory through it in 1MB steps).
|
||||
.I size
|
||||
can also be
|
||||
.B no
|
||||
if no aperture is setup at all.
|
||||
.TP
|
||||
.I adr
|
||||
is the base address of the aperture in MB.
|
||||
.TP
|
||||
.I how
|
||||
is
|
||||
.B autodetect
|
||||
if the aperture was setup this way already when the
|
||||
program started. It is
|
||||
.B setup
|
||||
when the the setting was enforced with a
|
||||
.B setuplinear
|
||||
configuration command. It is
|
||||
.B EEPROM
|
||||
when no aperture was detected,
|
||||
but parameters to set it up were found in the EEPROM.
|
||||
.TP
|
||||
.I mem
|
||||
is the amount of memory the card reported to have.
|
||||
.TP
|
||||
.I dactype
|
||||
is the type of the DAC that was detected.
|
||||
|
||||
If a special ramdac type was set with the
|
||||
.B ramdac
|
||||
command a
|
||||
.B (set)
|
||||
will be displayed after
|
||||
.IR dactype .
|
||||
.PP
|
||||
|
||||
If
|
||||
.IR mem ", " dactype
|
||||
and/or the chipset were enforced with
|
||||
.B chipset from the configuration file
|
||||
or
|
||||
.BR vga_setchipsetandfeatures (3)
|
||||
a
|
||||
.B forced
|
||||
will be appended to the line.
|
||||
|
||||
.SH 14. CONCLUSIONS
|
||||
A final word: I have an ATI ULTRA PRO/2MB/EISA with a Type 2 DAC.
|
||||
My monitor is an EIZO F550i-M. Everything I tried works on it like
|
||||
a charm. However, I couldn't try it with other machines myself and esp.
|
||||
other DAC's. Fortunately the Type 2 DAC is the worst to code. So I
|
||||
will probably have gotten the other DAC's right. But please be warned!
|
||||
|
||||
I did my very best to code the driver to support the other DAC's by
|
||||
just reading the docs.
|
||||
.B But i can't give any definitive guarantee for
|
||||
.B it to work or even not damaging your hardware. So please be careful!
|
||||
|
||||
Note that you will have to set the environment variable
|
||||
.B SVGALIB_MACH32
|
||||
to
|
||||
.B ILLTRYIT
|
||||
if your DAC is not type 0, 2, 3 or 4. This will of course change
|
||||
if no one with a DAC equal to 1 or 5 has serious problems. If you have
|
||||
a different DAC, making patches to support your card will be much more
|
||||
helpful instead of just complaining.
|
||||
If you have a different DAC that works well tell me as well such that I
|
||||
can remove the need for SVGALIB_MACH32 in the next release. Still, even
|
||||
now, after years, I got no reports of a Mach32 card with a type 1 or 5
|
||||
ramdac. Go figure.
|
||||
|
||||
Thank you for your audience and wishes you will enjoy this driver,
|
||||
.br
|
||||
Michael.
|
||||
.SH FILES
|
||||
.I /etc/vga/libvga.config
|
||||
.br
|
||||
.I /etc/vga/mach32.eeprom
|
||||
|
||||
.SH SEE ALSO
|
||||
.BR svgalib (7),
|
||||
.BR libvga.config (5),
|
||||
.BR mach32info (6).
|
||||
|
||||
.SH AUTHOR
|
||||
The Mach32 driver and this documentation was written by
|
||||
Michael Weller <eowmob@exp-math.uni-essen.de>.
|
||||
267
doc/man7/threedkit.7
Normal file
267
doc/man7/threedkit.7
Normal file
|
|
@ -0,0 +1,267 @@
|
|||
.TH threedkit 7 "2 Aug 1997" "Svgalib (>= 1.2.11)" "Svgalib User Manual"
|
||||
.SH NAME
|
||||
threedkit \- a set of functions for 3D support.
|
||||
|
||||
.SH DESCRIPTION
|
||||
The 3dkit consists mainly of the following triangle functions
|
||||
.BR gl_striangle (3),
|
||||
.BR gl_swtriangle (3),
|
||||
.BR gl_triangle (3),
|
||||
.BR gl_trigetcolorlookup (3),
|
||||
.BR gl_trisetcolorlookup (3),
|
||||
.BR gl_trisetdrawpoint (3),
|
||||
.BR gl_wtriangle (3).
|
||||
|
||||
Beware, these functions are not a direct part of the svgalib library.
|
||||
Instead their source is part of svgalib and can be found in the
|
||||
.I threeDkit/
|
||||
subdirectory of the original svgalib distribution. However, it is not
|
||||
installed in the system by default, s.t. it is unclear where you can find it
|
||||
if your svgalib was installed by some
|
||||
linux distribution.
|
||||
|
||||
In case of any such problem, simply get an svgalib distribution from the net. You even
|
||||
don't need to install it. Just
|
||||
.B make
|
||||
in the
|
||||
.I threeDkit/
|
||||
subdirectory. As of this writing,
|
||||
.I svgalib-1.2.12.tar.gz
|
||||
is the latest version and can be retrieved by ftp from
|
||||
.IR "sunsite.unc.edu" " at " "/pub/Linux/libs/graphics"
|
||||
and
|
||||
.IR "tsx-11.mit.edu" " at " "/pub/linux/sources/libs"
|
||||
which will most probably be mirrored by a site close to you.
|
||||
|
||||
The functions are defined in the
|
||||
.IR tri.o " and " triangl.o
|
||||
files (or their resp. sources) which you must link to your program.
|
||||
|
||||
.SH EXPLANATION ON 3DKIT.C
|
||||
This is main engine for 3D rendering.
|
||||
|
||||
Program flow:
|
||||
|
||||
.TP
|
||||
.B 1.
|
||||
The function called from outside of
|
||||
.I 3dkit.c
|
||||
is
|
||||
.BR TD_drawsolid .
|
||||
This first calculates the rotation matrix from the camera
|
||||
rotation angles (see below for more details).
|
||||
It then allocates memory for the temporary array
|
||||
.Itemp
|
||||
for
|
||||
holding temporary coords in subsequently called functions.
|
||||
It also sorts the surfaces from furthest to closest; according
|
||||
to the distance of the centre grid-point of each surface from
|
||||
the camera.
|
||||
|
||||
It also establishes whether
|
||||
.B ROTATE_OBJECT
|
||||
option is on
|
||||
and zero's the camera position if so --- this is for displaying the
|
||||
object at the screen centre like in a 3D CAD package, as
|
||||
apposed to virtual reality where the object can be anywhere
|
||||
and the actual camera position can move.
|
||||
|
||||
In the case of
|
||||
.B ROTATE_OBJECT
|
||||
being on, although the camera position
|
||||
is zero, some distance has to be placed between the camera and the
|
||||
object (or else it would appear to be infinitely large on the
|
||||
screen). This is done using the variable
|
||||
.I s_cam
|
||||
which is
|
||||
initialized to
|
||||
.I distance
|
||||
which is set by the calling application.
|
||||
It then loops through each surface (ordering them in the way they
|
||||
were just sorted --- i.e. according to
|
||||
.I sortarray
|
||||
indexing) and
|
||||
calls one of five graphic routines to write the 3D surface to the
|
||||
hardware.
|
||||
|
||||
.TP
|
||||
.B 2.
|
||||
Assume that
|
||||
.B TD_drawsolid
|
||||
then calls
|
||||
.BR TD_drawmesh .
|
||||
Here, each surface
|
||||
grid point is first
|
||||
.BR TD_translate 'd
|
||||
into a 2D screen point and stored in
|
||||
the
|
||||
.I temp
|
||||
array. There are obviously w(idth)*h(eight) points in the
|
||||
grid.
|
||||
|
||||
Following, each line from the 2D temp array is drawn on the screen.
|
||||
To draw the surface, the corner wishbone (two lines) from each grid
|
||||
square is drawn while advancing across and the down. After completing
|
||||
the scan, the furthest two edges of the surface must then be filled
|
||||
in, vis.:
|
||||
_ _ _ _ _ _
|
||||
.br
|
||||
|_|_|_|_|_|_
|
||||
.br
|
||||
|_|_|_|_|_|_
|
||||
.br
|
||||
|_|_|_|_|_|_
|
||||
.br
|
||||
|_|_|_|_|_|_
|
||||
.br
|
||||
|_|_|_|_|_|_
|
||||
.br
|
||||
| | | | | |
|
||||
|
||||
To understand the object rotation, a knowledge of matrix
|
||||
multiplication is required. I once derived a camera rotation
|
||||
before I learned matrix computation. It amounted to the same
|
||||
thing, but was unnecessarily complicated to optimise.
|
||||
|
||||
.TP
|
||||
.B 3.
|
||||
.B TD_translate
|
||||
called from
|
||||
.B TD_drawmesh
|
||||
(and others) converts from
|
||||
the 3D grid point coordinate to the 2D screen coordinate using:
|
||||
.B (a)
|
||||
the three camera position coordinates, (or the single camera
|
||||
distance value,
|
||||
.IR s_cam ,
|
||||
if
|
||||
.B ROTATE_OBJECT
|
||||
is set), and
|
||||
.B (b)
|
||||
the three camera rotation angles. However, the three camera rotation
|
||||
angles have already been converted into a rotation matrix when
|
||||
.B TD_calc_rotation_matrix
|
||||
was called by
|
||||
.BR TD_draw_solid .
|
||||
|
||||
To convert from a 3D coordinate to a 2D screen coordinate,
|
||||
the camera position (or more correctly, the position of the object
|
||||
from the camera) must first be added to each of the 3D grid coordinates.
|
||||
If the user has chosen to use 32 bit values for the discription
|
||||
of the surface, then these must be right shifted to the same size
|
||||
as the 16 bit case.
|
||||
|
||||
.IR x ", " y " and " z
|
||||
now hold the 3D position of the
|
||||
object relative to the camera centre (or in these terms, the
|
||||
centre of the video screen
|
||||
.B RIGHT ON
|
||||
the screen). The vector
|
||||
.BI [ "x y z" ]
|
||||
must
|
||||
now be multiplied by the rotation matrix. The
|
||||
.I xt
|
||||
value must also have the camera distance,
|
||||
.IR s_cam ,
|
||||
added to it in case the
|
||||
.B ROTATE_CAMERA
|
||||
is set (in which case
|
||||
.IR x_cam ", " y_cam " and " z_cam
|
||||
(the camera position)
|
||||
will be zero and instead
|
||||
.I s_cam
|
||||
will have a value to provide the necessary object-camera distance). A test is
|
||||
also made as to whether this
|
||||
value is zero or negative. In the case, the point is too close to the
|
||||
camera, or behind the camera, and must not be drawn.
|
||||
|
||||
After the multiplication, the resulting vector
|
||||
.BI [ "xt yt zt" ]
|
||||
has been rotated
|
||||
to be aligned with screen. The vector is now adjusted for perspective
|
||||
by dividing the
|
||||
.IR yt " and " zt
|
||||
values (horizontal and vertical
|
||||
respectively) by the
|
||||
.I xt
|
||||
value (into the screen). Division is done
|
||||
by
|
||||
.B muldiv64
|
||||
because the intermediate product is larger
|
||||
than 32 bits.
|
||||
.IR xscale " and " yscale
|
||||
are factors that scale the image to size.
|
||||
.IR posx " and " posy
|
||||
is just the centre of the screen, or more precisely:
|
||||
|
||||
The exact position of the pinhole camera viewing the object.
|
||||
|
||||
.TP
|
||||
.B 4.
|
||||
.B TD_calc_rotation_matrix
|
||||
calculates the nine entries of the 3 by 3
|
||||
matrix used in
|
||||
.BR TD_translate .
|
||||
In order that only integer arithmetic
|
||||
is performed, these values are stored and used as integers. Since this
|
||||
matrix's entries are always between -1 and +1, they have to be
|
||||
integer left shifted to give them accuracy.
|
||||
.B TD_MULCONSTANT
|
||||
scales them
|
||||
to sufficient bits of accuracy before they are converted to integers.
|
||||
|
||||
This also means that results (of multiplications with them) have
|
||||
to be scaled down by the same amount. This scaling is inherent in the
|
||||
final multiplication and division
|
||||
.RB ( muldiv64 )
|
||||
done in the
|
||||
.B TD_translate
|
||||
function, so an extra division is not consumed.
|
||||
|
||||
The rotation matrix effectively rotates the vector by the Eulerian angles
|
||||
.IR alpha ", " beta " and " gamma .
|
||||
These angles represent successive rotations about
|
||||
each of the 3D axes. You can test which angles do what by looking at
|
||||
the calling application. Their precise definitions are not
|
||||
all that important since you can get the keyboard to do the right thing
|
||||
with a little trial and error.
|
||||
|
||||
.PP
|
||||
Intrisics of drawing non-transparent surfaces...
|
||||
|
||||
to be continued ?!
|
||||
|
||||
.SH SEE ALSO
|
||||
.BR vgagl (7),
|
||||
.BR svgalib (7),
|
||||
.BR gl_striangle (3),
|
||||
.BR gl_swtriangle (3),
|
||||
.BR gl_triangle (3),
|
||||
.BR gl_trigetcolorlookup (3),
|
||||
.BR gl_trisetcolorlookup (3),
|
||||
.BR gl_trisetdrawpoint (3),
|
||||
.BR gl_wtriangle (3),
|
||||
.BR plane (6),
|
||||
.BR wrapdemo (6).
|
||||
|
||||
.SH AUTHOR
|
||||
This manual page was edited by Michael Weller <eowmob@exp-math.uni-essen.de>. The
|
||||
demos, the initial documentation and the whole threedkit stuff was done by
|
||||
Paul Sheer <psheer@icon.co.za>.
|
||||
|
||||
Paper mail:
|
||||
.RS
|
||||
Paul Sheer
|
||||
.br
|
||||
P O BOX 890507
|
||||
.br
|
||||
Lyndhurst
|
||||
.br
|
||||
Johannesburg 2106
|
||||
.br
|
||||
South Africa
|
||||
.RE
|
||||
|
||||
Donations (by check or postal order) will be appreciated and will encourage
|
||||
further development of this software. However this is strictly on a voluntary
|
||||
basis where this software falls under the GNU LIBRARY GENERAL PUBLIC LICENSE.
|
||||
401
doc/man7/vgagl.7
Normal file
401
doc/man7/vgagl.7
Normal file
|
|
@ -0,0 +1,401 @@
|
|||
.TH vgagl 7 "2 Aug 1997" "Svgalib (>= 1.2.11)" "Svgalib User Manual"
|
||||
.SH NAME
|
||||
vgagl \- a fast framebuffer-level graphics library based ion svgalib
|
||||
.SH TABLE OF CONTENTS
|
||||
|
||||
.BR 0. " Introduction"
|
||||
.br
|
||||
.BR 1. " How to use vgagl"
|
||||
.br
|
||||
.BR 2. " Description of vgagl functions"
|
||||
.br
|
||||
.BR 3. " Macros defined in vgagl.h"
|
||||
|
||||
.SH 0. INTRODUCTION
|
||||
|
||||
This is a fast framebuffer-level graphics library for linear 1, 2, 3 and 4
|
||||
byte-per-pixel modes (256-color, hicolor, truecolor). It uses a limited
|
||||
number of functions from svgalib (libvga) for low-level hardware
|
||||
communication (the library is included in the svgalib shared image).
|
||||
|
||||
In particular,
|
||||
.BR svgalib (7)
|
||||
maps the 64K VGA frame buffer window, and this library
|
||||
directly addresses the buffer. For SVGA modes that use more than 64K of
|
||||
screen memory, SVGA paging is required when writing to the physical screen;
|
||||
this is done automatically for most functions (at a certain cost).
|
||||
|
||||
Alternatively, any number of virtual screens of any type in system memory can
|
||||
be used, which can then be copied to the physical screen. There is also
|
||||
support for 4 bytes per pixel framebuffers (and copying them to a 3 bytes per
|
||||
pixel context), and limited planar 256 color mode support (copyscreen,
|
||||
aligned putbox).
|
||||
|
||||
The planar 256 color modes (available on all VGA cards) can now be used
|
||||
with a virtual screen, which is copied to the physical screen (with optional
|
||||
page-flipping).
|
||||
|
||||
Bitmaps are raw, with one (or more) bytes per pixel (like pixmaps in X),
|
||||
stored in row-major order. They are usually manipulated with the getbox
|
||||
and putbox functions.
|
||||
|
||||
.B vgagl
|
||||
does also make use of the graphic cards accelerator
|
||||
(if it is supported)
|
||||
in some situations.
|
||||
|
||||
A graphics context is just a structure that holds the size of the associated
|
||||
graphics screen, how it is organized, clipping status etc. You can define a
|
||||
custom virtual (system memory) graphics context of any size with the
|
||||
setcontextvirtual function. All operations work on the current context.
|
||||
|
||||
Any questions, bug-reports, additions, suggestions etc. are welcome.
|
||||
|
||||
.SH 1. HOW TO USE VGAGL
|
||||
Programs that use
|
||||
.B vgagl
|
||||
must
|
||||
.BR "#include <vgagl.h>" .
|
||||
Linking must be done with
|
||||
.BR "-lvgagl -lvga" .
|
||||
|
||||
Functions in the
|
||||
.B vgagl
|
||||
library have the prefix
|
||||
.BR gl_* .
|
||||
To initialize
|
||||
.BR vgagl ,
|
||||
the graphics context must be set. Example:
|
||||
|
||||
.RS
|
||||
.B vga_setmode(G320x200x256);
|
||||
.br
|
||||
.B gl_setcontextvga(G320x200x256);
|
||||
.RE
|
||||
|
||||
In this example, the context is set to the physical screen. The context can
|
||||
be saved (only the screen type, not the contents) into a variable, e.g.
|
||||
|
||||
.RS
|
||||
.B GraphicsContext physicalscreen;
|
||||
.br
|
||||
.B gl_getcontext(&physicalscreen).
|
||||
.RE
|
||||
|
||||
To define a virtual screen in system memory, use
|
||||
.BR gl_setcontextvgavirtual (3):
|
||||
|
||||
.RS
|
||||
.B gl_setcontextvgavirtual(G320x200x256)
|
||||
.RE
|
||||
|
||||
which allocates space for a screen identical to 320x200x256 graphics mode,
|
||||
and makes this virtual screen the current graphics context.
|
||||
|
||||
The virtual screen can now be copied to the physical screen as follows:
|
||||
|
||||
.RS
|
||||
.B gl_copyscreen(&physicalscreen);
|
||||
.RE
|
||||
|
||||
Note that with a virtual screen in system memory, it is possible to add
|
||||
fast X-Window support to a program, using MITSHM to copy the framebuffer
|
||||
to the screen window.
|
||||
|
||||
.SH 2. DESCRIPTION OF VGAGL FUNCTIONS
|
||||
.PD 0
|
||||
.SS Context management
|
||||
.TP
|
||||
.BR gl_getcontext "(3), " currentcontext (3)
|
||||
get the current graphics contents..
|
||||
.TP
|
||||
.BR gl_setcontext (3)
|
||||
set a previously saved context.
|
||||
.TP
|
||||
.BR gl_setcontextvga (3)
|
||||
set the context to the physical screen.
|
||||
.TP
|
||||
.BR gl_setcontextvgavirtual (3)
|
||||
set the context to a virtual mode.
|
||||
.TP
|
||||
.BR gl_setcontextvirtual (3)
|
||||
define a virtual context.
|
||||
.TP
|
||||
.BR gl_allocatecontext (3)
|
||||
allocate a graphics context.
|
||||
.TP
|
||||
.BR gl_freecontext (3)
|
||||
free a virtual screen.
|
||||
.TP
|
||||
.BR gl_setcontextwidth "(3), " gl_setcontextheight (3)
|
||||
set the dimension of a context.
|
||||
|
||||
.SS Drawing primitives
|
||||
.TP
|
||||
.BR gl_clearscreen (3)
|
||||
clear the screen.
|
||||
.TP
|
||||
.BR gl_rgbcolor (3)
|
||||
return pixel value corresponding to an rgb color.
|
||||
.TP
|
||||
.BR gl_setpixel "(3), " gl_setpixelrgb (3)
|
||||
draw a pixel.
|
||||
.TP
|
||||
.BR gl_getpixel (3)
|
||||
return the color of a pixel.
|
||||
.TP
|
||||
.BR gl_getpixelrgb (3)
|
||||
store color components of a pixel.
|
||||
.TP
|
||||
.BR gl_hline (3)
|
||||
draw a horizontal line.
|
||||
.TP
|
||||
.BR gl_line (3)
|
||||
draw a line.
|
||||
.TP
|
||||
.BR gl_circle (3)
|
||||
draw a circle.
|
||||
.TP
|
||||
.BR gl_fillbox (3)
|
||||
fill a rectangular area.
|
||||
|
||||
.SS Copying of screen buffers and page flipping
|
||||
.TP
|
||||
.BR gl_copyscreen (3)
|
||||
copy the screen contents of contexts.
|
||||
.TP
|
||||
.BR gl_setscreenoffset (3)
|
||||
set a memory offset for copyscreen.
|
||||
.TP
|
||||
.BR gl_setdisplaystart (3)
|
||||
set the start of the screen are displayed.
|
||||
.TP
|
||||
.BR gl_enablepageflipping (3)
|
||||
enables automatic page flipping.
|
||||
|
||||
.SS Clipping
|
||||
.TP
|
||||
.BR gl_disableclipping (3)
|
||||
disables clipping.
|
||||
.TP
|
||||
.BR gl_enableclipping (3)
|
||||
enables clipping.
|
||||
.TP
|
||||
.BR gl_setclippingwindow (3)
|
||||
set the clipping window.
|
||||
|
||||
.SS Text drawing primitives
|
||||
.TP
|
||||
.BR gl_setfont (3)
|
||||
set the text font to be used.
|
||||
.TP
|
||||
.BR gl_setfontcolors (3)
|
||||
set the font colors.
|
||||
.TP
|
||||
.BR gl_expandfont (3)
|
||||
expand a packed pixel font.
|
||||
.TP
|
||||
.BR gl_colorfont (3)
|
||||
change the color of a font.
|
||||
.TP
|
||||
.BR gl_setwritemode (3)
|
||||
set the font writemode flags.
|
||||
.TP
|
||||
.BR gl_write "(3), " gl_writen (3)
|
||||
write a text string.
|
||||
.TP
|
||||
.BR gl_printf (3)
|
||||
formatted output to the graphics screen.
|
||||
.TP
|
||||
.BR gl_font8x8 (3)
|
||||
a packed 8x8 pixel font.
|
||||
|
||||
.SS Pix- and Bitmap drawing
|
||||
.TP
|
||||
.BR gl_getbox (3)
|
||||
copy a rectangular pixmap from the screen to a buffer.
|
||||
.TP
|
||||
.BR gl_copybox (3)
|
||||
copy a rectangular screen area.
|
||||
.TP
|
||||
.BR gl_copyboxfromcontext (3)
|
||||
copy rectangular area from another context.
|
||||
.TP
|
||||
.BR gl_copyboxtocontext (3)
|
||||
copy a rectangular area to another context.
|
||||
.TP
|
||||
.BR gl_putbox (3)
|
||||
copy a pixmap to a rectangular area.
|
||||
.TP
|
||||
.BR gl_putboxpart (3)
|
||||
copy a partial pixmap to a rectangular area.
|
||||
.TP
|
||||
.BR gl_putboxmask (3)
|
||||
copy a masked pixmap to a rectangular area.
|
||||
.TP
|
||||
.BR gl_putboxmaskcompiled (3)
|
||||
copy a compiled masked pixmap to a rectangular area.
|
||||
.TP
|
||||
.BR gl_compileboxmask (3)
|
||||
compress a masked bitmap.
|
||||
.TP
|
||||
.BR gl_compiledboxmasksize (3)
|
||||
compute the size of a compiled masked box.
|
||||
.TP
|
||||
.BR gl_scalebox (3)
|
||||
scale a pixmap.
|
||||
|
||||
.SS Palette handling
|
||||
.TP
|
||||
.BR gl_getpalettecolor "(3), " gl_getpalettecolors "(3), " gl_getpalette (3)
|
||||
read the color palette.
|
||||
.TP
|
||||
.BR gl_setpalettecolor "(3), " gl_setpalettecolors "(3), " gl_setpalette (3)
|
||||
set the color palette.
|
||||
.TP
|
||||
.BR gl_setrgbpalette (3)
|
||||
set a 256-color RGB palette.
|
||||
|
||||
.SS Triangle primitives from threeDkit
|
||||
.TP
|
||||
.BR gl_striangle (3)
|
||||
draw a solid colored triangle.
|
||||
.TP
|
||||
.BR gl_triangle (3)
|
||||
draw a triangle with interpolated colors.
|
||||
.TP
|
||||
.BR gl_swtriangle (3)
|
||||
draw a solid pixmap mapped on a triangle.
|
||||
.TP
|
||||
.BR gl_wtriangle (3)
|
||||
draw a shadowed pixmap mapped on a triangle.
|
||||
.TP
|
||||
.BR gl_trisetcolorlookup "(3), " gl_trigetcolorlookup (3)
|
||||
manages a color lookup table for shadowing.
|
||||
.TP
|
||||
.BR gl_trisetdrawpoint (3)
|
||||
set a triangle drawing function.
|
||||
.PD
|
||||
.SH 3. MACROS DEFINED IN VGAGL.H:
|
||||
.TP
|
||||
.B WIDTH
|
||||
The width in pixels of the current graphics context.
|
||||
.TP
|
||||
.B HEIGHT
|
||||
Height in pixels.
|
||||
.TP
|
||||
.B BYTESPERPIXEL
|
||||
Number of bytes per pixel (1, 2, 3 or 4).
|
||||
.TP
|
||||
.B BYTEWIDTH
|
||||
Width of a scanline in bytes.
|
||||
.TP
|
||||
.B COLORS
|
||||
Number of colors.
|
||||
.TP
|
||||
.B BITSPERPIXEL
|
||||
Number of significant color bits.
|
||||
.TP
|
||||
.B VBUF
|
||||
Address of the framebuffer.
|
||||
.TP
|
||||
.B __clip
|
||||
Clipping flag.
|
||||
|
||||
.PD 0
|
||||
.TP
|
||||
.B __clipx1
|
||||
.TP
|
||||
.B __clipy1
|
||||
Top-left corner of clipping window.
|
||||
.PD
|
||||
|
||||
.PD 0
|
||||
.TP
|
||||
.B __clipx2
|
||||
.TP
|
||||
.B __clipy2
|
||||
.PD
|
||||
Bottom-right corner of clipping window.
|
||||
|
||||
.SH BUGS
|
||||
For three bytes per pixel (true color) modes, it is possible that
|
||||
pixels cross a SVGA segment boundary. This should be correctly
|
||||
handled by most functions, but you never know. It can be avoided by using a logical
|
||||
scanline length that is a divisor of 65536 (a power of 2), like 1024
|
||||
(as opposed to 960) for 320x200 and 2048 (1920) for 640x480. For
|
||||
800x600, this is impractical (4096 as opposed to 2400 doesn't fit in
|
||||
2MB). Alternatively, avoid those functions by using a virtual screen.
|
||||
|
||||
.SH SEE ALSO
|
||||
.BR svgalib (7),
|
||||
.BR libvga.config (5),
|
||||
.BR testgl (6),
|
||||
.BR threedkit (7),
|
||||
.BR currentcontext (3),
|
||||
.BR gl_allocatecontext (3),
|
||||
.BR gl_circle (3),
|
||||
.BR gl_clearscreen (3),
|
||||
.BR gl_colorfont (3),
|
||||
.BR gl_compileboxmask (3),
|
||||
.BR gl_compiledboxmasksize (3),
|
||||
.BR gl_copybox (3),
|
||||
.BR gl_copyboxfromcontext (3),
|
||||
.BR gl_copyboxtocontext (3),
|
||||
.BR gl_copyscreen (3),
|
||||
.BR gl_disableclipping (3),
|
||||
.BR gl_enableclipping (3),
|
||||
.BR gl_enablepageflipping (3),
|
||||
.BR gl_expandfont (3),
|
||||
.BR gl_fillbox (3),
|
||||
.BR gl_font8x8 (3),
|
||||
.BR gl_freecontext (3),
|
||||
.BR gl_getbox (3),
|
||||
.BR gl_getcontext (3),
|
||||
.BR gl_getpalette (3),
|
||||
.BR gl_getpalettecolor (3),
|
||||
.BR gl_getpalettecolors (3),
|
||||
.BR gl_getpixel (3),
|
||||
.BR gl_getpixelrgb (3),
|
||||
.BR gl_hline (3),
|
||||
.BR gl_line (3),
|
||||
.BR gl_putbox (3),
|
||||
.BR gl_putboxmask (3),
|
||||
.BR gl_putboxmaskcompiled (3),
|
||||
.BR gl_putboxpart (3),
|
||||
.BR gl_rgbcolor (3),
|
||||
.BR gl_scalebox (3),
|
||||
.BR gl_setclippingwindow (3),
|
||||
.BR gl_setcontext (3),
|
||||
.BR gl_setcontextheight (3),
|
||||
.BR gl_setcontextvga (3),
|
||||
.BR gl_setcontextvgavirtual (3),
|
||||
.BR gl_setcontextvirtual (3),
|
||||
.BR gl_setcontextwidth (3),
|
||||
.BR gl_setdisplaystart (3),
|
||||
.BR gl_setfont (3),
|
||||
.BR gl_setfontcolors (3),
|
||||
.BR gl_setpalette (3),
|
||||
.BR gl_setpalettecolor (3),
|
||||
.BR gl_setpalettecolors (3),
|
||||
.BR gl_setpixel (3),
|
||||
.BR gl_setpixelrgb (3),
|
||||
.BR gl_setrgbpalette (3),
|
||||
.BR gl_setscreenoffset (3),
|
||||
.BR gl_setwritemode (3),
|
||||
.BR gl_striangle (3),
|
||||
.BR gl_swtriangle (3),
|
||||
.BR gl_triangle (3),
|
||||
.BR gl_trigetcolorlookup (3),
|
||||
.BR gl_trisetcolorlookup (3),
|
||||
.BR gl_trisetdrawpoint (3),
|
||||
.BR gl_write (3),
|
||||
.BR gl_writen (3),
|
||||
.BR gl_wtriangle (3).
|
||||
|
||||
.SH AUTHOR
|
||||
There are many authors of svgalib. This page was edited by
|
||||
Michael Weller <eowmob@exp-math.uni-essen.de>.
|
||||
The original documentation and most of
|
||||
.B vgagl
|
||||
was done by Harm Hanemaayer <H.Hanemaayer@inter.nl.net> though.
|
||||
Loading…
Add table
Add a link
Reference in a new issue