You are already acquainted with ircombine in its GUI mode, you have read its documentation (available from the Insight library -- bark at your local system administrator if it's not there) and now you want (or need perhaps) to use a video mode not supplied with the graphics excecution environment (eoe.sw.gfx) product. This is the place for you.
In order to setup your outputs, you use the program ircombine, which lets you define "combinations" for the outputs. Playing arround with this, you'll probably reach the level where you stare in amazement at two things: the flexibility of the SGI graphics hardware (at least in this particular respect) and the stupidity of the interface.
ircombine wants to have a vfo file which are the way to define video modes. Everything is nicely documented in the "Video Format Compiler Programmer's Guide" (part of the vfc.books product). You start with a vfs file and compile it to a vfo one. You do that with:
$ /usr/sbin/vfc \
-c chip=voc1.def,board=dg4.def \
-a ascii=SOMETHING.vfo \
-o SOMETHING.vfo \
SOMETHING.vfs
just watch out for the chip and board parameters. (TODO: how do you figure out their correct values?). Once you get your video format to compile, copy the resulting vfo file to /usr/gfx/ucode/KONA/dg4/vfo/ (replace the KONA/dg4 bit with whatever is appropiate for your board). Now you can point ircombine to this new video format.
So far, so good. If you are thinkering with your output resolution (or refresh rate, or whatever), you'll probably get sick of loading ircombine and setting up the channels only to find out that the refresh rate is too high and you don't have enough bandwidth to drive all the channels with that format, or that your output devices don't like the resolution you just defined, or ... if you get to that point, you'll be happy to find out that ircombine can be used from the command line, too. A typical invocation of ircombine looks like this:
$ /usr/gfx/ircombine \
-destination eeprom \
-validate numrms=2,numchannels=8,gfxrev=ONYX2_IR \
-global pixeldepth=S,size=2728x1006 \
-channel 0 format=1364x1006_40l.vfo,sourceloc=0+0 \
-channel 1 format=1364x1006_40r.vfo,sourceloc=0+0 \
-channel 2 format=1364x1006_40l.vfo,sourceloc=1364+0 \
-channel 3 format=1364x1006_40r.vfo,sourceloc=1364+0
ircombine(1G) has a nice manpage, but most of the parameters quoted above should be easy to figure out.
And that's pretty much it. It's quite easy once you do it a couple of times.
The bit that might be, oh, not so easy, is the definition of a new video format. An extremely barebones definition file might look like this:
General
{
FieldsPerFrame = 1;
FramesPerSecond = 40;
TotalLinesPerFrame = 1057;
TotalPixelsPerLine = 1700;
ActiveLinesPerFrame = 1006;
ActivePixelsPerLine = 1364;
FormatName = "1364x1006_40";
}
Active Line {
HorizontalFrontPorch = 32 pixels;
HorizontalSync = 272 pixels;
HorizontalBackPorch = 32 pixels;
}
Field
{
Vertical Sync =
{
{
Length = 1.0H;
Low = 0.0 usec;
}
repeat 6
{
Length = 1.0H;
}
}
Vertical Back Porch =
{
{
Length = 1.0H;
High = HorizontalSync;
}
repeat 21
{
Length = 1.0H;
Low = 0.0 usec;
High = HorizontalSync;
}
}
Active =
{
repeat 1006
{
Length = 1.0H;
Low = 0.0 usec;
High = HorizontalSync;
}
}
Vertical Front Porch =
{
repeat 22
{
Length = 1.0H;
Low = 0.0 usec;
High = HorizontalSync;
}
}
}
You should really sit down and read the documentation for the video format compiler. It contains everything you might ever want to know about video formats. If you define a format and vfc that it lacks a signature, sit down and make a drawing of the signal and try to think in terms of what your output device would be looking at if it was fed that signal. Could it be able to identify where a frame begins and where it ends? Could it be able to tell appart the front porch from the sync?
Hint: if your output signal generates images of poor quality, you might want to try with this:
| Field | Variable | Value |
|---|---|---|
| Horizontal Resolution | HR | user defined |
| Horizontal Front Porch | HFP | floor(0.015625 * HR) |
| Horizontal Sync | Hsync | floor(0.125 * HR) |
| Horizontal Back Porch | HBP | floor(0.25 * HR) - HFP - Hsync |
| Horizontal Field Lenght | HFL | HR + HBP + Hsync + HFP |
| Vertical Resolution | VR | user defined |
| Vertical Front Porch | VFP | floor(0.0042 * VR) + 1 |
| Vertical Sync | Vsync | floor(0.0042 * VR) + 1 |
| Vertical Back Porch | VBP | floor(0.05 * VR) - VFP - Vsync |
| Vertical Field Lenght | VFL | VR + VBP + Vsync + VFP |
vfc might complain about the parity (or multiplicity) of some value. Adjunst accordingly.
We have put together a script that does most of the grunt work.
So, you managed to hose up the display and you can't get a signal that your monitor can understand? There are several ways of fixing this:
UNIX is a registered trademark of the Open Group in the United States and other countries. Linux is a registered trademark of Linus Torvalds, a really nice guy.