Compiling SGI O2 video formats
This page was originally written by Stuart Levy, but the original link is down.
vfc(video format compiler) lets you compile
.vfsvideo-format source files into
.vfofiles, 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
.vfofiles in the appropriate place,
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
1.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.
1. 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
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:
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)
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.
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, email@example.com