As just today another old O2 materialized on the trash heap around here,
I actually might try my luck - but it's a R10K O2, IP32.
No luck there, as r10k ip32 still has the cache coherency problem, and
won't run linux.
The sgivwfb driver uses by default 8MB at the highest end of phys
memory, and increasing it to 16MB hasn't harmed yet.
The gbefb driver won't even let you choose more than 8mb, and I think
2mb is the default.
Well, I don't have a 1600sw, and there are some internal patches in the
visws mailing list of Florian Boor who added a I2C self configuration to
the driver, such that entereing the monitor type by kernel cmd line
argument is not necessary anymore.
It would be nice to know if these help out on mips, and if so, they
should probably be contributed to the linux-mips tree. I wish I had a
1600sw with which to tinker.
...different depths produce funny results. Haven't tried 8bit, but 24 is
definitely broken. You can still see something, but barely. So, we can
probably deduce that the other-than-15bit modes were never actually
tested by the original author (some intern then a SGI?).
There was actually a patch for Xfree by the original author of the
sgio2fb driver (Vivien, aka glaurung, wasn't it?) which allowed X to run
properly in 16bpp. However, this patch was lost in a hard drive crash
if I recall.
about the chances to get some hardware docs about the VisWS from SGI
were simply turned down by the astonishing fact that they really dumped
the whole product line: hardware, contracts, subcontractors (developed
the gfx drivers for Win NT) and even documentation. Speak about a deed
(x86 graphics workstations) so awful that nobody at SGI wanted be
remembered about it ?
There are at least a couple of folks on this mailing list who I'm pretty
sure know more about the specifics of this hardware. The only question
is, are they allowed to talk to you about it?