Re: [9fans] Monitor timings - shb, ehb, vrs, etc.

Re: [9fans] Monitor timings - shb, ehb, vrs, etc.

[Russ Cox]

To learn about monitor timings I recommend Eric Raymond's
XFree86 Video Timings HOWTO, which can be found at 
http://www.linuxdoc.org/HOWTO/XFree86-Video-Timings-HOWTO/
among other places.  Another alternative is to find a
monitor that is similar and use that entry.  The cm751u
and cm801u entries look very close to your 
1600x1200, 93.8kHz, 75Hz line.

On a related note, but one probably not relevant to you,
here is a guide to writing vga drivers, which may be of
interest to some on this list.

Russ

The following is a sort of theory of operation for aux/vga and the
kernel vga drivers.

--- aux/vga and basic kernel drivers

Aux/vga consists of a number of modules each of which conforms to an
interface called a Ctlr.  The Ctlr provides functions snarf, options,
init, load, and dump, which are explained in more detail below.  Video
cards are internally represented as just a collection of Ctlrs.  When
we want to run one of the functions (snarf, etc.)  on the whole card,
we run it on each Ctlr piece in turn.

In the beginning of aux/vga, it was common for video cards to mix and
match different VGA controller chips, RAMDACs, clock generators, and
sometimes even hardware cursors.  The original use for vgadb was to
provide a recipe for how to deal with each card.  The ordering in the
ctlr sections was followed during initialization, so that if you said
	ctlr
		0xC0076="Tseng Laboratories, Inc. 03/04/94 V8.00N"
		link=vga
		clock=ics2494a-324
		ctlr=et4000-w32p
		ramdac=stg1602-135
when aux/vga wanted to run, say, snarf on this card it would call the
snarf routines for the vga, ics2494a, et4000, and stg1602 Ctlrs, in
that order.  The special Ctlrs vga and ibm8514 take care of the
generic VGA register set and the extensions to that register set
introduced by the IBM 8514 chip.  Pretty much all graphics cards these
days still use the VGA register set with some extensions.  The only
exceptions currently in vgadb are the Ticket to Ride IV and the
Neomagic (both LCD cards).  The S3 line of chips tends to have the IBM
8514 extensions.

This "mix and match" diversity has settled down a bit, with one chip
now usually handling everything.  As a result, vgadb entries have
become a bit more formulaic, usually listing only the vga link, a
controller, and a hardware cursor.  For example:
	ctlr
		0xC0039="CL-GD540"
		link=vga
		ctlr=clgd542x
		hwgc=clgd542xhwgc

On to the controller functions themselves.  The functions mentioned
earlier are supposed to do the following.

void snarf(Vga *vga, Ctlr *ctlr)
	Read the ctlr's registers into memory, storing them
	either in the vga structure (if there is an appropriate
	place) or into a privately allocated structure, a pointer
	to which can be stored in vga->private [sic]. 
	[The use of vga->private rather than ctlr->private betrays
	the fact that private data has only been added after we got
	down to having cards with basically a single controller.]

void options(Vga *vga, Ctlr *ctlr)
	This step prepares to edit the in-memory copy of the
	registers to implement the mode given in vga->mode.
	It's really the first half of init, and is often empty.
	Basically, something goes here if you need to influence
	one of the other init routines and can't depend on being
	called before it.  For example, the virge Ctlr rounds
	the pixel line width up to a multiple of 16 in its options routine.
	This is necessary because the vga Ctlr uses the pixel line
	width.  If we set it in virge.init, vga.init would already
	have used the wrong value.

void init(Vga *vga, Ctlr *ctlr)
	Edit the in-memory copy of the registers to implement
	the mode given in vga->mode.

void load(Vga *vga, Ctlr *ctlr)
	Write all the ctlr's registers, using the in-memory values.
	This is the function actually used to switch modes.

void dump(Vga *vga, Ctlr *ctlr)
	Print (to the Biobuf stdout) a description of all the
	in-memory controller state.  This includes the in-memory
	copy of the registers but often includes other calculated
	state like the intended clock frequencies, etc.

Now we have enough framework to explain what aux/vga does.  It's
easiest to present it as a commented recipe.

1.  We sniff around in the BIOS memory looking for a match to
any of the strings given in vgadb.  (In the future, we intend also to
use the PCI configuration registers to identify cards.)

2.  Having identified the card and thus made the list of controller
structures, we snarf the registers and, if the -p flag was
given, dump them.

3.  If the -i or -l flag is given, aux/vga then locates the desired
mode in the vgadb and copies it into the vga structure.  It then does
any automatic frequency calculations if they need doing.  (See the
discussion of defaultclock in vgadb(6).)

For a good introduction to video modes, read Eric Raymond's XFree86
Video Timings HOWTO, which, although marked as obsolete for XFree86,
is still a good introduction to what's going on between the video card
and the monitor.
http://www.linuxdoc.org/HOWTO/XFree86-Video-Timings-HOWTO/

4.  Having copied the vgadb mode parameters into the vga structure,
aux/vga calls the options and then the init routines to twiddle the
in-memory registers appropriately.

5.  Now we are almost ready to switch video modes.  We dump the
registers to stdout if we're being verbose.

6.  We tell the kernel (via the "type" vga ctl message) what sort of
video card to look for.  Specifically, the kernel locates the named
kernel vga driver and runs its enable function.

7.  If we're using a frame buffer in direct-mapped linear mode (see
the section below), we express this intent with a "linear" vga ctl
message.  In response, the kernel calls the vga driver's linear
function.  This should map the video memory into the kernel's address
space.  Conventionally, it also creates a named memory segment for use
with segattach so that uesr-level programs can get at the video
memory.  If there is a separate memory-mapped i/o space, it too is
mapped and named.  These segments are only used for debugging,
specifically for debugging the hardware acceleration routines from
user space before putting them into the kernel.

8.  We tell the kernel the layout of video memory in a "size" ctl
message.  The arguments are the screen image resolution and the pixel
channel format string.

9.  Everything is set; we disable the video card, call the loads to
actally set the real registers, and reenable the card.

At this point there should be a reasonable picture on the screen.  It
will be of random memory contents and thus could be mostly garbage,
but there should be a distinct image on the screen rather than, say,
funny changing patterns due to having used an incorrect sync
frequency.

10.  We write "drawinit" into #v/vgactl, which will initialize the
screen and make console output from now on appear on the graphics
screen instead of being written to the CGA text video memory (as has
been happening).  This calls the kernel driver's drawinit function,
whose only job is to initialize hardware accelerated fills and scrolls
and hardware blanking if desired.

11.  We write "hwgc <hwgcname>" into #v/vgactl, which calls the enable
function on the named kernel hwgc driver.  (Plan 9 does not yet support
software graphics cursors.)

12.  We set the actual screen size with an "actualsize" ctl message.
The virtual screen size (which was used in the "size" message in step
8) controls how the video memory is laid out; the actual screen size
is how much fits on your monitor at a time.  Virtual screen size is
sometimes larger than actual screen size, either to implement panning
(which is really confusing and not recommended) or to round pixel
lines up to some boundary, as is done on the ViRGE and Matrox cards.
The only reason the kernel needs to know the actual screen size is to
make sure the mouse cursor stays on the actual screen.

13.  If we're being verbose, we dump the vga state again.

--- hardware acceleration and blanking

Hardware drawing acceleration is accomplished by calling the
kernel-driver-provided fill and scroll routines rather than
doing the memory operations ourselves.  For >8-bit pixel depths,
hardware acceleration is noticeably needed.  For typical Plan 9
applications, accelerating fill and scroll has been fast enough that we haven't
worried about doing anything else.  

The kernel driver's drawinit function should sniff the card
and decide whether it can use accelerated fill and scroll functions.
If so, it fills in the scr->fill and scr->scroll function pointers
with functions that implement the following:

int fill(VGAscr *scr, Rectangle r, ulong val);
	Set every pixel in the given rectangle to val.
	Val is a bit pattern already formatted for the screen's
	pixel format (rather than being an RGBA quadruple).
	Do not return until the operation has completed
	(meaning video memory has been updated).
	Usually this means a busy wait looping for a bit
	in some status register.  Although slighty inefficient,
	the net effect is still much faster than doing the work 
	ourselves.  It's a good idea to break out of the busy
	loop after a large number of iterations, so that
	if the driver or the card gets confused we don't
	lock up the system waiting for the bit.  Look at
	any of the accelerated drivers for the conventional
	method.
	
int scroll(VGAscr *scr, Rectangle r, Rectangle sr);
	Set the pixels in rectangle r with the pixels in sr.
	r and sr are allowed to overlap, and the correct
	thing must be done, just like memmove.
	Like fill, scroll must not return until the operation
	has completed.

Russ Cox <rsc@plan9.bell-labs.com> has a user-level scaffold
for testing fill and scroll routines before putting them into
the kernel.  You can mail him for them.

Finally, drawinit can set scr->blank to a hardware blanking
function.  On 8-bit displays we can set the colormap to all
black to get a sort of blanking, but for true-color displays
we need help from the hardware.

int blank(VGAscr *vga, int isblank);
	If isblank is set, blank the screen.  Otherwise, restore it.
	Implementing this function on CRT-based cards is known to
	mess up the registers coming out of the blank.
	We've had better luck with LCD-based cards although
	still not great luck.  But there it is.

--- linear mode and soft screens

In the bad old days, the entire address space was only 1MB, but video
memory (640x480x1) was only 37.5kB, so everything worked out.  It got
its own 64kB segment and everyone was happy.  When screens got deeper
and then bigger, the initial solution was to use the 64kB segment as a
window onto a particular part of video memory.  The offset of the
window was controlled by setting a register on the card.  This works
okay but is a royal pain, especially if you're trying to copy from one
area of the screen to another and they don't fit in the same window.
When we are forced to cope with cards that require accessing memory
through the 64kB window, we allocate our own copy of the screen (a
so-called soft screen) in normal RAM, make changes there, and then
flush the changed portions of memory to video RAM through the window.
To do this, we call the kernel driver-provided page routine:

int pageset(VGAscr *scr, int page);
	Set the base offset of the video window to point
	page*64kB into video memory.

With the advent of 32-bit address spaces, we can map all of video
memory and avoid the soft screen.  We call this running the card
in linear mode, because the whole video memory is mapped linearly
into our address space.  Aux/vga is in charge of deciding
whether to do this.  (In turn, aux/vga more or less respects
vgadb, which controls it by having or not having "linear=1" in
the controller entry.)  If not, aux/vga doesn't do anything special,
and we use a soft screen.  If so, aux/vga writes "linear" and
an address space size into vgactl in step #7 above.  In response
the kernel calls the kernel driver's linear function, whose
job was described in step #7.

Most drivers only implement one or the other interface: if you've
got linear mode, you might as well use it and ignore the paging
capabilties of the card.  Paging is typically implemented only
when necessary.

--- from here

If you want to write a VGA driver, it's fairly essential that you get
documentation for the video chipset.  In a pinch, you might be able to
get by with the XFree86 driver for the chipset instead.  (The NVidia
driver was written this way.)  Another alternative is to use
documentation for a similar but earlier chipset and then tweak
registers until you figure out what is different.  (The SuperSavage
parts of the virge driver got written this way, starting with the
Savage4 parts, which in turn were written by referring to the Savage4
documentation and the Virge parts.)

Even if you do get documentation, the XFree86 driver is good to
have to double check.  Sometimes the documentation is incomplete,
misleading, or just plain wrong, whereas the XFree86 drivers, 
complicated beasts though they are, are known to work most of the time.

Another useful method for making sure you understand what is going on
is dumping the card's registers under another system like XFree86 or
Microsoft Windows.  The Plan 9 updates page contains an ANSI/POSIX
port of aux/vga that is useful only for dumping registers on various
systems.  It has been used under Linux, FreeBSD, and Windows 95/98.
It's not clear what to do on systems like Windows NT or Windows 2000
that both have reasonable memory protection and are hardware
programmer-unfriendly.

If you're going to write a driver, it's much easier with a real
Plan 9 network or at least with a do-everything cpu/auth/file server
terminal, so that you can have an editor and compiler going on a
usable machine while you continually frotz and reboot the machine
with the newfangled video card.  Booting this latter machine from
the network rather than its own disk makes life easier for you
(you don't have to explicitly copy aux/vga from the compiling machine to
the testing machine) and doesn't wreak havoc on the testing machine's
local kfs.

It's nice sometimes to have a command-line utility to poke
at the vga registers you care about.  We have one that perhaps
we can clean up and make available.  Otherwise, it's not hard
to roll your own.

The first step in writing an aux/vga driver is to write the
snarf and dump routines for the controller.  Then you can
run aux/vga -p and see whether the values you are getting
match what you expect from the documentation you have.

A good first resolution to try to get working is 640x480x8,
as it can use one of the standard clock modes rather than
require excessive clock fiddling.

/sys/src/cmd/aux/vga/template.c is a template for a new
vga controller driver.  There is no kernel template 
but any of the current drivers is a decent template.
/sys/src/9/pc/vga3dfx.c is the smallest one that supports
linear addressing mode.

Re: [9fans] Monitor timings - shb, ehb, vrs, etc.

[paurea]

Russ Cox writes:
 > From: "Russ Cox" <rsc@plan9.bell-labs.com>
 > Subject: Re: [9fans] Monitor timings - shb, ehb, vrs, etc.
 > Date: Mon, 11 Feb 2002 10:18:25 -0500
 > 
 > To learn about monitor timings I recommend Eric Raymond's
 > XFree86 Video Timings HOWTO, which can be found at 
 > http://www.linuxdoc.org/HOWTO/XFree86-Video-Timings-HOWTO/
 > among other places.  Another alternative is to find a
 > monitor that is similar and use that entry.  The cm751u
 > and cm801u entries look very close to your 
 > 1600x1200, 93.8kHz, 75Hz line.
 > 
 > On a related note, but one probably not relevant to you,
 > here is a guide to writing vga drivers, which may be of
 > interest to some on this list.
 > 
 > Russ
 > 
 > The following is a sort of theory of operation for aux/vga and the
 > kernel vga drivers.

Thanks a lot!!! this makes me very happy!!!. I was doing this guide myself while 
fighting with my SiS630 driver... This will (hopefully) speed up my programming.

-- 
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"

Re: [9fans] Monitor timings - shb, ehb, vrs, etc.

[Jason Gurtz]

On Wed, 13 Feb 2002 paurea@gsyc.escet.urjc.es wrote:

> Thanks a lot!!! this makes me very happy!!!. I was doing this guide
> myself while fighting with my SiS630 driver... This will (hopefully)
> speed up my programming.

O, please continue :)  My amptron PM-586LMR will not boot with a Matrox Millenium II.  Mach64's fair better by the BIOS, but the one (MACH64 215CT22200) dumps the kernel.  The other (Rage II PCI+DVD) which I added in to the vgadb, almost works but the screen is split into a few columns, the number of wich depends on the color depth (less is better).

~Jason

--

[9fans] Monitor timings - shb, ehb, vrs, etc.

[Joel Salomon]

I've seen this issue mentioned on the newsgroup archives again &
again, but never with  a real solution.  I'd like to use high
resolution (1600x1200) with my monitor, but that res isn't mentioned
in vgadb. vgadb(6) lists numbers to implement a resolution: shb, ehb,
vrs, etc, then says "The values given for shb, ehb, ht, vrs, vre, vt,
hsync, and vsync are beyond the scope of this manual page. See the
book by Ferraro for details." :-(

My monitor came with a list of resolutions and horizoontal and
vertical refesh rates. My question is: how do I get from this table to
the list of shb, ehb, vrs, etc. that vgadb wants?

If this is non-trivial but there is some one out there who can
generate these numbers, my monitor is a Hyundai P910+ with timings as
folows:
resolution    Horiz.(khz)   Vertical refresh(Hz)
720x400         31.5            70
640x480         31.5            60
640x480         63.7           120
800x600         53.7            85
1152x864        67.5            75
1024x768        68.7            85
1024x768        81.8           100
1280x1024       79.9            75
1280x1024       91.1            85
1600x1200       93.8            75
1600x1200      106.3            85