I believe a substantial portion of the "driver" layer will actually be in X / userland - which doesn't have any public driver APIs and for which the source has never been leaked (to the best of my knowledge). So nobody's tried, and best of luck!

Plus, most video cards don't have proper open-source drivers even *with* fully-documented APIs and full source around (those APIs and source being godawful might have a lot to do with it, but video drivers are definitely not trivial in any way).

I suspect compiling X.org might not actually be too horribly difficult. You'd just have to set it up to use IRIX's PCI libraries, and you'd be in the business for any pure-userland (so no hardware 3D) supported PCI video card with modesetting support (so not many). UltimateVision even used XFree86, so it's clearly not an impossible task - too bad the X license didn't require them to release their source.

Xservers are hard even when you have intimate knowledge of the hardware. Metrolink (when they were still in business) used to argue that xserver programming is even more difficult than kernel programming

Project:Temporarily lost at sea...Plan:World domination! Or something...

vishnu wrote:Xservers are hard even when you have intimate knowledge of the hardware. Metrolink (when they were still in business) used to argue that xserver programming is even more difficult than kernel programming

I believe it! I've never developed with Xserver, but it seems odd to me that the device drivers aren't abstracted from the server itself to facilitate easy development. If we could figure out a way to develop PCI display card drivers it'd give a lot of additional life to Origin Desksides, Octanes, Fuels, Tezros, etc etc. I'm definitely still interested in investigating this when my quals are over. Anyone else interested in looking into the possibility?

evil ppc wrote: If we could figure out a way to develop PCI display card drivers it'd give a lot of additional life to Origin Desksides, Octanes, Fuels, Tezros, etc etc. I'm definitely still interested in investigating this when my quals are over. Anyone else interested in looking into the possibility?

Honestly, evil, why do you say that ? The weak point of all those computers is not the graphics. The weak point is the not so great cpu. And even if you do think that 128 megs of memory is not enough, it would be a lot easier to hack the V10 cards to support 512 megs than to deal with a complete X server, then try to find pci graphics cards that would be worth a poop. If you are really concerned about graphics in the Tezro and Fuel, jump into hacking the V10.

Then deal with the O2 prom, which would give us a 900 mhz cpu in an O2. THAT would be lovely.

There's lots of useful projects to take on. Please don't waste your energies on something that would not be very useful. We don't have enough programmer people to waste their efforts on less than realistic projects..

hamei wrote:Then deal with the O2 prom, which would give us a 900 mhz cpu in an O2. THAT would be lovely.

There's lots of useful projects to take on. Please don't waste your energies on something that would not be very useful. We don't have enough programmer people to waste their efforts on less than realistic projects..

I thought the Holy Grail was still USB block device support.

A bugless FireWire driver would be nice as well.

And while we're dreaming, how about boot support for SAS/SATA? In the dream we've got ARCS source, right?

I suppose a OGL2/3/4 layer that supports the "new" stuff with CPU redirects would be good, if we're talking graphics, but I'd prefer a GL/DGL plug in for other machines (so earlier SGI software works on non-SGI remote X servers).

hamei wrote:Then deal with the O2 prom, which would give us a 900 mhz cpu in an O2. THAT would be lovely.

There's lots of useful projects to take on. Please don't waste your energies on something that would not be very useful. We don't have enough programmer people to waste their efforts on less than realistic projects..

I thought the Holy Grail was still USB block device support.

A bugless FireWire driver would be nice as well.

And while we're dreaming, how about boot support for SAS/SATA? In the dream we've got ARCS source, right?

I suppose a OGL2/3/4 layer that supports the "new" stuff with CPU redirects would be good, if we're talking graphics, but I'd prefer a GL/DGL plug in for other machines (so earlier SGI software works on non-SGI remote X servers).

I know we definitely have a long list of dreams! The USB dream seems fairly practical. Has anyone worked on that?

hamei wrote: The weak point of all those computers is not the graphics. The weak point is the not so great cpu.

CPU speed doesn't seem to be a major showstopper when you run software designed/intended for the SGI/MIPS platform.

The rub seems to be when you need to use software not designed/intended for use on the SGI/MIPS platform. For me a web browser would be number one on that list. The version of Netscape that shipped on the IRIX install disks is barely functional <and I'm being overly generous suggesting barely functional>. It's only a matter of time before FireFox2 joins Netscape as having no practical value as a general purpose web browser.

For those of us who still use SGI as their primary computing platform, when FireFox2 looses functionality it will largely relegate SGI hardware to irrelevance/gee-whiz status <that Tezro sure looks dusty, think I'll fire it up and play with Maya or Flame for a while>.

While faster processors are an attractive proposition, adding processors is a reasonably viable alternative to single CPU performance - especially considering how well IRIX handles multiple CPU systems <and the ever-decreasing price of SGI MP hardware>.

eMGee wrote:There is IEEE-1394a FireWire support for the latter, but don't ask how. It's extremely poor. I have a 500 GB disk, only like 128 GB of it is addressable/recognized for some reason.

That has almost certainly nothing to do with IRIX, but with the 1394-IDE bridge in the external drive enclosure though. Older IDE controllers had a 40bit limitation (~ 128GB). Some motherboards/controllers/enclosures need a firmware update, others will never support 48bit addressing. FireWire (or actually, the SBP2 protocol layer) doesn't have any 128GB limitations.

There used to be some stability issues with Firewire in IRIX -- you could crash the system with fsr for example. I believe there's a patch for that. Also, IRIX doesn't like it at all if you connect a disk after the system is up and running. That too would crash the system, I believe. It's been a while since I last used a FireWire disk (Lacie d2 quadra, 500GB, all of it usable) on a MIPS/SGI system.

To accentuate the special identity of the IRIS 4D/70, Silicon Graphics' designers selected a new color palette. The machine's coating blends dark grey, raspberry and beige colors into a pleasing harmony. (IRIS 4D/70 Superworkstation Technical Report)

SAQ wrote:And while we're dreaming, how about boot support for SAS/SATA? In the dream we've got ARCS source, right?

I haven't tried it, but why wouldn't that work? As far as my O300 is concerned, its SATA hard drive is just another SCSI disk, at least if hinv is to be believed.

Because by the time you get to hinv it's already booted. It needs to see the sata disk from the prom, before booting, to be able to boot from it.

Booting from scsi doesn't seem too big a drawback to me tho. All SGI computers since the Indigo have very convenient scsi setups. A 36 gb 10 or 15k scsi disk for the system and a big sata disk for data is very practical.