Compiling SGI O2 video formats

SGI's vfc (video format compiler) lets you compile .vfs video-format source files into .vfo files, with a variety of screen sizes and scan rates, for at least a couple of kinds of graphics hardware: Infinite Reality and the O2's CRM graphics. You can then install these .vfo files in the appropriate place,
IR: /usr/gfx/ucode/KONA/dg4/vof
O2: /usr/gfx/ucode/CRM/vof

and use   xscreen   or   /usr/gfx/setmon 
to activate them.

See also the companion page on compiling
stereoscopic video formats for the O2.  In this one, I'll just describe some
general information, and how to create high-res monoscopic formats.
Also check out Simon Lok's analog 1600SW .vfs
for driving an SGI flat panel in analog mode, with a multilink adapter instead
of a digital flat panel adapter.

You can pick up this documentation, assorted examples, etc. in one tarball:
see o2-stereo.tar.gz.

To play this game, you need:

vfc, the Video Format Compiler.  If it's installed, running
"versions vfc" will list a handful of entries beginning something like

I  vfc                  02/09/99  Video Format Compiler, 1.0



A video format file (.vfs).  The vfc
installation includes some examples in /usr/gfx/ucode/vfc/vfs,
and of course there are examples included here.
Root access, to be able to write the compiled .vfo file into
/usr/gfx/ucode/CRM/vof, and perhaps also to be able to run
/usr/gfx/setmon -w.


How To

Use vfc (/usr/sbin/vfc) to compile the .vfs file;
see the Makefile in this package, or try (supposing the file was XYZ.vfs):
vfc -i "cc -E" -a ascii=XYZ.info -c chip=/usr/gfx/ucode/vfc/rules/O2_Chip.def,board=/usr/gfx/ucode/vfc/rules/O2_Board.def  -o XYZ.vfo  XYZ.vfs

to yield XYZ.vfo and XYZ.info.

The name of the file isn't actually crucial (on the O2 at least),
though by convention it has the form (see "man setmon"):

xsizexysize_framerate[s|p]

where the optional s indicates a stereo format, and (for the O2),
p indicates a format for the flat-panel display.

Copy XYZ.vfo into the directory /usr/gfx/ucode/CRM/vof/.

If you don't already know it, check the size of the current X server's
managed area, with e.g.

xdpyinfo | grep dimensions

If the new video format's size doesn't exceed the X managed area size
in either dimension, you can try loading it immediately (no need to be root) with:

/usr/gfx/setmon -n formatname

where the formatname is as described above, e.g.

/usr/gfx/setmon -n 1280x1024_72

Note that setmon requires invoking formats by their conventional
name, even if the installed .vfo file has a different name.  Setmon
actually parses the given name, extracting the size and other parameters,
and asks the X server for a video format with those attributes.

To make this the default format for future sessions too, you must be
root; then, use

/usr/gfx/setmon -w formatname



If the new video format's size exceeds the X server's managed area,
you'll need to make it the X server's default format, then restart X.
Prepare for the possibility that the format may be unusable (see below).
When ready, become root and use

/usr/gfx/setmon -w formatname

to make the new format be the default one, which the X server uses
when it's (re-)started, e.g. at boot time.

You can then (after setmon -w) force the X server
to restart; there are several ways to do this, but the simplest is the
Vulcan Death Grip key sequence: press the following four keys and
hold them all down:

Ctrl
Shift
the / key on the keypad (not under the ? key)
the F12 key

The X server will exit, destroying your session (so save any apps you'll want
saved before doing this!).  If the new format works, you should get another
login screen.

In case the new format screws up, you'll need another way to
log into the machine (and become root) without using the graphical console.
A terminal plugged into the tty1 port will do; so will an ethernet
connection, if you can telnet/etc. in and su to root.   You can recover
a usable display mode with e.g.

/usr/gfx/setmon -w 72    (or 75, or 60)

which is shorthand for 1280x1024_72 and etc., as
described in man setmon.

Then, force the X server to stop (if it started at all) and restart;
if the Vulcan Death Grip doesn't do it (it won't if the X server never started), try (as root)

/usr/gfx/stopgfx

/usr/gfx/startgfx






Making your own formats
Try creating your own formats too, based on these examples.

The ACTIVE_LINES, ACTIVE_PIXELS and FPS values should be obvious,
but EXTRA_HBP needs explanation.

For high-res formats, it often seems that the default allotted
horizontal retrace time isn't quite enough for the monitor; the symptom
is that the extreme left edge of the raster will be very bright, and a bit
compressed.  Extending the horizontal back porch (HBP) time seems to
help.  Use the smallest number you can that makes the artifact disappear.

Limitations
The O2 hardware imposes some limits to frame rate, etc.  The ones I know about are:

max (horizontal) line length of 2160 pixels, including horizontal
sync and front/back-porch (from /usr/gfx/ucode/vfs/rules/O2_Chip.def).
This probably limits the ultimate raster width to around 1650-1700 pixels.

max pixel rate of 144 MHz (4 * DACRateMaximum from O2_Board.def).
The compiler doesn't appear to enforce this, so check the
.info file after compiling a format to make sure you're
not overrunning the DAC.  Not sure how serious an error that is, but perhaps
it overheats if overclocked (so an error might not be instantly obvious,
but could do damage eventually).

If the pixel rate is too high, the options seem to be:

reducing the frame rate (FPS), or
reducing the raster width (ACTIVE_PIXELS) or height (ACTIVE_LINES), or
building an interlaced format, perhaps based on
    /usr/gfx/ucode/vfc/vfs/646x486_30i.vfs.

    Don't ask me how to build interlaced formats -- I don't know.



The monitor will impose limitations too.  Be ready to
/usr/gfx/setmon -n 72 if the monitor goes blank,
begins to screech, etc.  Might be wise to alias something simple to that
command in case you can't see to type -- or better, bind an Alt-Fxx key
to f.exec that command in ~/.4Dwmrc.

The 1600x1200_56.* format acts a bit odd: a strip (~190 wide x 38 high)
of the upper left portion of the screen is duplicated at the lower right,
hiding anything that ought to appear in that extreme lower right strip.
The cursor, and contents of the overlay planes, are not duplicated.
If you don't like this, try reducing the resolution a bit.


Octanes
Although SGI doesn't even claim that vfc works on Octanes,
it looks as though the relevant files are supplied.  Furthermore, the
Octane .vfo files all claim to have been compiled with vfc.  Unfortunately,
I haven't found any combination of tweaks to get any .vfs file, even for
non-stereo formats, to compile on the Octane yet.  If anyone succeeds,
I'd love to hear about it.

  Stuart Levy, slevy@ncsa.uiuc.edu