linux-mips
[Top] [All Lists]

Re: [linux-fbdev] SGI VW 540, fbdev and pot pourii of faults and evidenc

To: James Simmons <jsimmons@acsu.buffalo.edu>
Subject: Re: [linux-fbdev] SGI VW 540, fbdev and pot pourii of faults and evidence..:-)
From: philloc@tigger.ccs.ornl.gov
Date: Wed, 9 Aug 2000 19:28:07 -0400
Cc: linux-fbdev@vuser.vu.union.edu, linux@cthulhu.engr.sgi.com
In-reply-to: <Pine.LNX.4.10.10008091913570.1534-100000@maxwell.futurevision.com>
Reply-to: i15@ornl.gov
Sender: owner-linux-mips@oss.sgi.com
        Hi,
> 
> > I would also like to ask, if SGI is likely to make the hardware specs OSS
> > (for cobalt etc.), so that those with the skill (this is not my forte, but
> > I will try...), can stabilise this otherwise competent port.
> 
> Nope. SGI no longer supports Visual Workstations with linux. I don't even
> know if they support Visual Workstatiosn period. It would be nice if they
> did release the specs anyways :-)
        They support it on WindozeNT etc... I was toying with the idea of 
running VMware just to see what the X server will do under NT.


        Anyone from SGI care to comment on why SGI has not released the
specs to reasonable attention, since they are unable to help port? 

As complex as the hardware is, the SGI guys did a pretty good job on the
"hacks" they put in, so I am sure the specs would make it a breeze to port
:-)

> 
> > 1. After boot , no matter what video mode one is in, the text console is
> > zippy. After using X (or changing modes using fbset) the text scrolling is
> > *painfully* slow. There is no apparent difference in the kernel mechanism
> > when switching, so is it just the boot state that works?
> 
> Which X server?  Sounds like the X server is doing the naughty.
        Oh not even X. X is fine in fact (with the exception it shivers
and is tinted green in 32bit 1600x1200, and tinted green in 32bit 
1280x1024 , but fine in 8-16bit for all modes).

        The problems is: 

        machine boots. Text scrolling fine, no matter what I set it to
in the kernel (in 8bit colour that is. 16bit and I lose the fonts). If you
then fbset to ANY mode (say 800x600x8), and then do "ls -l", it is very
slow. Now I have stared at the kernel for a bit, and the only thing that
strikes me, is that on boot the frambuffer is initialised etc.., and it is
possible that the hardware is in some sort of "bios" mode, which plays
nice with the framebuffer. After boot, we switch the mode etc... but
something is not tripped, or the kernel/video uses a different set of
routines.

        I suppose I should ask, anyone else see this behaviour?

> 
> >     Empirical observations (i.e. writing known patterns to the
> > /dev/fb0 device) indicate that SGI reverse RGB for 888 format, compared to
> > RGB565. That is red offset=0, green=8,blue=16 rather than red=24 etc.. I
> > have reversed the assignment in the "var" structure (in sgivwfb_set_var )
> > and in setcolreg the offsets are used, but to no effect. What else needs
> > changing?
> 
> Have a patch for this? Can you post it?

        If you want, but it has no effect, as bemusing as that sounds. I
could post the framebuffer test program (generates a framebuffer-file full
of "regular" colours, so you can deduce the settings visually- very nasty
hack).


        Oh BTW, kernel is 2.2.13 with all SGI patches (before they yanked
the OSS site),and a few mods of my own to get it to compile(inthe setup
rotuines).

        Hey as an aside, anyone know how to "uncompress" a "vmlinuz"
kernel to a "vmlinux"? SGI had posted a kernel or 2 , but always in the
"vmlinuz" format. To the best of my knowledge cannot be booted
on the VW 540.

        
        Finally, I looked at rewriting the visw_apic.c code upto 2.4 , to
the new format. It looks do-able, but I know little about this, and I do
not know if anyone else has had a hack yet.


        Cheers for now

        PHiL


<Prev in Thread] Current Thread [Next in Thread>