SGI: hinv

Ah, well I'm actually using Slackware so of course the networking bits in the xserver are fine...

I've probably misunderstood that reply (and if so, most of this thread)...... have you been trying to feed a 2@ display format through the DM5?

For that to work the DM5 would have to include the necessary logic to reassemble a split dual-channel-display format back into a single display image (there's only *one* DVI-out port on the DM5).

While both frequently mention the DCD, neither the Discreet and SGI manuals ever mention using a 2@ display format. I think it's likely the only role the DCD plays is to provide a digital signal for the DM5 (which why with the IP35 systems that have planar DVI ports Discreet says you can use a Gefen DVI splitter instead of a DCD).

Since you were using the connection diagram from SGI's version of the DM5 manual, I figured you'd long ago tried the matching software configuration (for graphics and video) listed in Chapter 3 and found it didn't work. If you have, my apologies for yet again beating that dead horse.

On the very remote chance you missed it: That'd still require a monitor able sync to a 1920x1154@30Hz signal.

If it produces a display through the DVI-out port on the DM5, you'd still have to do some custom coding to use that mega-buck DM2-VBoB-DM5 combo for something other than a glorified DVI pass through (which is why I suggested the more-mega-bucks-needed Discreet route *and* the no-additional-bucks-needed monitor-connected-directly-to-DCD alternative).

Yes I have tried getting the DM5 to kick in using dmconf, never with any success though, it always says "Error reading VPro format" despite the fact that I always use one of the formats listed in /usr/gfx/ucode/STINGRAY/cmb, which, at least as far as I can tell, are the ones you're supposed to use.

Originally I thought the DM5 must be wired up with the smarts to rebuild the 2@ format back into something comprehensible to a single monitor, which it then dumped out to its lone DVI out port. The reason I thought that is because the DM5 gets its input from the DCD outputs and I assumed (for no good reason apparantly) that if you weren't in a 2@ format the DCD wouldn't do anything, that it was basically turned off. I still think that kind of makes sense but at this point I don't know what to think.

The DCD always works, but if you don't feed it a 2@ format that it can separate into two contiguous screens, you get a Ricochet Rabbit mess

Seems to me I did some non-approved stuff with mine a long time ago tho, and it was possible to do things you aren't supposed to.

The DCD works just fine without the presence of a 2@ format - you're presented with a practical example every time you boot a DCD-equipped Octane.

With IRIX running, if you connect three monitors (to the 13W3 and both DVI ports) and load a standard non-DCD format, all three monitors will display the same image. If you take into account the inherent differences between the 13W3's analog signal and the digital signal on the DVI ports, the quality of the images will be the same. bitcpy posted a photo of three monitors connected to his DCD-equipped VPro. He wasn't using a 2@ format; all three monitors display an identical image: viewtopic.php?f=3&t=16727561&start=15#p7358665
While I was working out the details of how I wanted to configure OpenGL MultiPipe on a dual V12/DCD O350 (it took a while), I had monitors attached to the DVI ports of both the DCDs and wasn't using 2@ formats. Never experienced any display issues, anomalies, or Magilla Gorilla rabbits .
It would have been nice of them to have included at least a little more detail in the dmconf man page.

Just to further complicate the issue, sample combination files for the VPro Graphics Compositor are also stored in /usr/gfx/ucode/STINGRAY/cmb directory (you can see that same path structure in this illustration from the Compositor Manual ). Here's the contents of /usr/gfx/ucode/STINGRAY/cmb on my DCD/DM2-equipped Octane2: The Compositor combines the output of multiple VPros as "tiles" in a smaller single display. Unless your version of the directory looks different, any combination files that include the word "tiles" were very likely intended for use with the Compositor. If you did inadvertently use a combination file intended for a Compositor it might explain the 'error reading VPro format' messages you saw.

Indeed the contents of that directory are the same on my Octane, funny that one of the files is a symlink. And I get the same error if I try a file that tiles or a file that doesn't tile:


I agree the dmconf man page is so sparse as to leave the command basically undocumented. None of this makes sense, SGI had their foot in the door of the broadcast media industry, what happened? NBC went in hook line and sinker with this hardware and used it to broadcast the entire Seoul Olympics, which, if you screw that up, man do you look bad. But it worked. I mean, it was pretty much a crowning success, right? SGI and NBC did press releases about its greatness. And so did Discreet, per their hardware that we've been referencing in lo these many threads. So who out-competed them in this arena? Or did they just abandon it in yet another of their utterly misguided strategy realignments?

Sounds like it can't 'read' the VPro format because it doesn't know where it is (or because it's broken - /usr/gfx/ucode/STINGRAY/cmb/1280x1024_96s.cmb appears in fm as a text file instead of a binary). Have you tried including the full path?

In any case I wouldn't use the the 1280x1024_96s in the Stingray cmb directory; not only because it's broken/not a binary, but it appears to have been prepared to produce a stereo display for use with a crystal eyes stereo emitter/glasses (the trailing "s" in the file name is typically used to designate a stereo format), and stereo or not, 1280x1024 probably isn't going to work when you're calling for a 1080i video format.

It isn't really discussed in the dmconf man page, but if if they were intended for the DM5 (instead of the Compositor), any files that have a .cmb extension have already been "combined" into a DM5-compatible format, so trying to re-use them as the VPro format in dmconf likely wouldn't work. I suspect the read-between-the lines is that you'd have to call a not-previously-combined VPro format (with a ".vfo" file extension), then read-between-the-lines again and load saved .cmb combination files with setmon.

Even if it means you have to call ssh to the rescue (allegedly dmconf configurations can also be cleared with a reboot), I'd try the syntax in the 1920x1154 example in the DM5 manual (with the addition of a full path for the graphics format). There's a 1920x1154_30f in the VPro format directory (/usr/gfx/ucode/ODSY/vof/1920x1154_30f.vfo). If it turns out dmconf is picky about file paths, you may have to try it with and without the .vfo extension:

Come to think of it, you are probably right. Since I normally have a 2@ format loaded and back when I originally got it and had this problem (flashy-flashy on the center channel) it may have come with a 2@ format loaded. So that would mean that as long as you weren't using it to do anything, the dcd doesn't do flashy-flashy on the base output. But as soon as you want to expand the screenestate, center channel becomes ping ping piiiing.

Duplicate displays is probably useful to someone ... not sure whom, but someone

Ha ha well crap, as I mentioned I don't know diddly about broadcast video and as I also mentioned I'm pretty sure one of the SGI documents I saw on techpubs said don't even try using this hardware unless you're a world's leading expert perched in a CNN distribution center sending out video that's enlightening the masses...

Alright, let me take action on these suggestions and I'll post back more status when there's more status to post back...

A "top" screenshot of my Octane right after bootup, the only user applications running are dtterm and xv (to make the screenshot), by contrast my dual-Xeon Tyan Tiger S2668, built the same year as my Octane, running Slackware 14 with a custom kernel 3.6.0 that has everything turned off that's not specific to the resident hardware has 85 processes after boot. To which I say that's an IRIX win and a Linux fail...