SGI O2: working framebuffer/X11 modes?

SGI O2: working framebuffer/X11 modes?

[Michael Joosten]

Hello,

this actually not really a SGI MIPS question, but a rather one about the
SGI 320 VisWS, which is a dual PIII thing, but it shares a lot of the
framebuffer code (sgivwfb.c) with the O2 one (gbefb.c) - and I'm 
writing this on an O2 with IRIX.

We've still have such a beast here, and I'm trying to set up a baseline
of required patches for current kernels in order to get a running
configuration out of the box. Because gbefb was derived from sgivwfb
somewhen back in 2002, it is therefore quite interesting to see how
things are going on the MIPS side, as both gfx hardware implementations
are supposed to be very similar (the visws one using hardware from O2
GBE). 

Currently, the only VisWS mode that works under X11 is Depth 15bit,
using the 2 byte/16bit ARGB5 mode in sgivwfb.c, with 1280x1024 
or higher with the 1600sw LCD panel. Surprisingly, Depth 16 in
/etc/X11/xorg.conf is not completely OK anymore, perhaps due 
to problems with the transparency bit. Anything else like 24 
or 8 bit looks decidedly odd, and hard to read at all. 
Namely 24/32bit is completely broken, the width of the
display is only 2/3 of the screen, though timing is still OK. 

Back to the question: What mode(s) are usable on a Linux O2? 
Did 24bit work at ANY time on the O2?

Kind regards, Michael
-- 
Michael Joosten, SBS C-LAB, joost@c-lab.de
Fuerstenallee 11, 33094 Paderborn, Germany
Phone: +49 5251 606127, Fax: +49 5251 606065
C-LAB is a cooperation of University Paderborn & SIEMENS

Re: SGI O2: working framebuffer/X11 modes?

[Stephen P. Becker]

> We've still have such a beast here, and I'm trying to set up a baseline
> of required patches for current kernels in order to get a running
> configuration out of the box.

Prior to the 2.6.15-rc1 import into linux-mips git, X was only useable 
if some variant of the gbefb patch at 
http://home.tal.org/~milang/o2/patches/ was used.  The symptom was that 
the X server would start and appear to be running, but you would only 
have a black screen as the output.  There was the additional oddity that 
even with this patch applied, X would do the old black screen thing for 
anybody with greater than 256mb, but less than 768mb of RAM (introduced 
by the ip32 full memory patch which went into the linux-mips tree in the 
past year or so).  In 2.6.15, now we only need the following change for 
X to work, and there seems to be no restrictions on the amount of RAM 
under which X will run:

--- drivers/video/gbefb.c.orig  2005-11-22 09:26:05 -0500
+++ drivers/video/gbefb.c       2005-11-22 08:16:58 -0500
@@ -1244,7 +1244,7 @@
                           (void *)gbe_tiles.cpu, gbe_tiles.dma);
         release_mem_region(GBE_BASE, sizeof(struct sgi_gbe));
         iounmap(gbe);
-       gbefb_remove_sysfs(dev);
+       gbefb_remove_sysfs(&p_dev->dev);
         framebuffer_release(info);

         return 0;

Another oddity which has plagued gbefb on O2 is that allocating more 
than 4mb of memory to gbefb causes it to fail outright.  The kernel will 
boot and userland comes up, but the framebuffer never initializes.


> Currently, the only VisWS mode that works under X11 is Depth 15bit,
> using the 2 byte/16bit ARGB5 mode in sgivwfb.c, with 1280x1024 
> or higher with the 1600sw LCD panel.

Interesting, because everything I have heard from folks who have tried 
to use 1600sw with their O2s say that it doesn't work at all.  In any 
case, X runs just fine at every single resolution I have tried, 
including 640x480, 800x600, 1024x768, and 1280x1024.  Basically, if you 
have a working framebuffer at any particular resolution (I usually pass 
it at boot time via something like video=gbefb:1280x1024-16@85), X will 
run at that resolution, no problem, since we are just using the fbdev X 
driver.


> Surprisingly, Depth 16 in
> /etc/X11/xorg.conf is not completely OK anymore, perhaps due 
> to problems with the transparency bit. Anything else like 24 
> or 8 bit looks decidedly odd, and hard to read at all. 
> Namely 24/32bit is completely broken, the width of the
> display is only 2/3 of the screen, though timing is still OK.

To my knowledge, running X in anything but 15bit depth has never worked 
on O2.  I have attempted to start my O2 up with gbefb running at various 
depths other than 16, and they always fail, defaulting back to 640x480 
at 16bpp (or occasionally even hanging the kernel).  Attempting to force 
some depth in the X config file always screwed things up whenever I 
attempted this.  Furthermore, it seems like the new modular X.org is 
smarter about probing the framebuffer capabilities, and totally ignores 
the depth you specify in xorg.conf, defaulting straight to 15.


> Back to the question: What mode(s) are usable on a Linux O2? 
> Did 24bit work at ANY time on the O2?

Not as far as I can tell.

-Steve

Re: SGI O2: working framebuffer/X11 modes?

[Michael Joosten]

Ups, that was fast...

Stephen P. Becker wrote:

>
> Prior to the 2.6.15-rc1 import into linux-mips git, X was only useable 
> if some variant of the gbefb patch at 
> http://home.tal.org/~milang/o2/patches/ was used.  The symptom was 
> that the X server would start and appear to be running, but you would 
> only have a black screen as the output.  There was the additional 
> oddity that even with this patch applied, X would do the old black 
> screen thing for anybody with greater than 256mb, but less than 768mb 
> of RAM (introduced by the ip32 full memory patch which went into the 
> linux-mips tree in the past year or so).  In 2.6.15, now we only need 
> the following change for X to work, and there seems to be no 
> restrictions on the amount of RAM under which X will run:
> Another oddity which has plagued gbefb on O2 is that allocating more 
> than 4mb of memory to gbefb causes it to fail outright.  The kernel 
> will boot and userland comes up, but the framebuffer never initializes.
>
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.
The sgivwfb driver uses by default 8MB at the highest end of phys 
memory, and increasing it to 16MB hasn't harmed yet.

>
>> Currently, the only VisWS mode that works under X11 is Depth 15bit,
>> using the 2 byte/16bit ARGB5 mode in sgivwfb.c, with 1280x1024 or 
>> higher with the 1600sw LCD panel.
>
>
> Interesting, because everything I have heard from folks who have tried 
> to use 1600sw with their O2s say that it doesn't work at all.

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.

> In any case, X runs just fine at every single resolution I have tried, 
> including 640x480, 800x600, 1024x768, and 1280x1024.  Basically, if 
> you have a working framebuffer at any particular resolution (I usually 
> pass it at boot time via something like video=gbefb:1280x1024-16@85), 
> X will run at that resolution, no problem, since we are just using the 
> fbdev X driver.
>
>
OK, resolution also seems less a problem with the sgivwfb driver (though 
I remember a weirdness with 1024x768), but...

>> Surprisingly, Depth 16 in
>> /etc/X11/xorg.conf is not completely OK anymore, perhaps due to 
>> problems with the transparency bit. Anything else like 24 or 8 bit 
>> looks decidedly odd, and hard to read at all. Namely 24/32bit is 
>> completely broken, the width of the
>> display is only 2/3 of the screen, though timing is still OK.
>
>
> To my knowledge, running X in anything but 15bit depth has never 
> worked on O2.  I have attempted to start my O2 up with gbefb running 
> at various depths other than 16, and they always fail, defaulting back 
> to 640x480 at 16bpp (or occasionally even hanging the kernel).  
> Attempting to force some depth in the X config file always screwed 
> things up whenever I attempted this.  Furthermore, it seems like the 
> new modular X.org is smarter about probing the framebuffer 
> capabilities, and totally ignores the depth you specify in xorg.conf, 
> defaulting straight to 15.
>
...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?). Recent info 
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 ?

Thanks a bunch, Michael

Re: SGI O2: working framebuffer/X11 modes?

[Stephen P. Becker]

> 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.


> Recent info 
> 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?

-Steve