SGI VW 540, fbdev and pot pourii of faults and evidence..:-)

SGI VW 540, fbdev and pot pourii of faults and evidence..:-)

[phil]

	Hi Folks,

I have presented below a small list of "features" with the SGI kernel
driver for fbdev (no particular order) , and would like to know if any of
the symptoms, indicate general frame buffer problems, or specific hardware
implementation issues.

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.

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?



2.In X(4.01)  all video modes (800x600,1024x768,1280x1024,1600x1200) work
in 8 bit and 16 bit colour.

In Depth 24 (-fbbpp 32) , 1280x1024 is stable, but tinted green.

In Depth 24 (-fbbpp 32) , 1600x1200 is "shivering, left-right", and
tinted green.


	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?


	Kind Regards

	PHiL

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

[James Simmons]

> 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 :-)

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

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

----------------------------------------------------------------------------
Innovation, innovate, and the concept of doing what everyone else did 20
years ago are registered trademarks of Microsoft Corporation. Other
buzzwords, euphemisms, and blatant lies are trademarks of their respective
owners.

James Simmons  [jsimmons@linux-fbdev.org]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

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

[philloc]

	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

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

[Shrijeet Mukherjee]

On Wed, 9 Aug 2000 philloc@tigger.ccs.ornl.gov wrote:

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

So just to make the statement sound right. SGI never officially supported
linux on the Visual Workstation 320. The current line of the Visual
Workstation family, the 230, 330 and 530 all do and will support highly
accelerated OpenGL under linux.

>
>	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
>:-)
>

Actually a "port" is not that simple. The real problem for opening up the
driver port that we worked on, is that there are critical parts of SGI
driver mode IP in there that we are not ready to open source at this
point. Given that, the software is the best "spec" and documentation we
have at this point .. this is a real issue.

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

I remember there being some issue about stuff being ABGR or some strange
format in some cases, which was screwing things up. Is this happening only
under WindowMaker or was it Enlightenment .. some window manager was
causing problems since it used X BLT's ..


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

Hope this helps some. 

-- 
--------------------------------------------------------------------------
Shrijeet Mukherjee,    		        MTS Advanced Graphics, SGI
http://reality.sgi.com/shm_engr     	phone: 650-933-5312
email: shm@sgi.com, shrijeet@hotmail.com
--------------------------------------------------------------------------
Where there is a will, there is a way. If a way cannot be found, 
it is the will that is suspect ..                                   -- shm 

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

[Shrijeet Mukherjee]

On Wed, 9 Aug 2000 philloc@tigger.ccs.ornl.gov wrote:

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

So just to make the statement sound right. SGI never officially supported
linux on the Visual Workstation 320. The current line of the Visual
Workstation family, the 230, 330 and 530 all do and will support highly
accelerated OpenGL under linux.

>
>	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
>:-)
>

Actually a "port" is not that simple. The real problem for opening up the
driver port that we worked on, is that there are critical parts of SGI
driver mode IP in there that we are not ready to open source at this
point. Given that, the software is the best "spec" and documentation we
have at this point .. this is a real issue.

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

I remember there being some issue about stuff being ABGR or some strange
format in some cases, which was screwing things up. Is this happening only
under WindowMaker or was it Enlightenment .. some window manager was
causing problems since it used X BLT's ..


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

Hope this helps some. 

-- 
--------------------------------------------------------------------------
Shrijeet Mukherjee,    		        MTS Advanced Graphics, SGI
http://reality.sgi.com/shm_engr     	phone: 650-933-5312
email: shm@sgi.com, shrijeet@hotmail.com
--------------------------------------------------------------------------
Where there is a will, there is a way. If a way cannot be found, 
it is the will that is suspect ..                                   -- shm 

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

[Alan Cox]

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

Try getting the sources for the 3d driver and graphics components on their
current workstation.

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

gzip -d <vmlinuz >vmlinux should be fine.

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

[Alan Cox]

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

Try getting the sources for the 3d driver and graphics components on their
current workstation.

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

gzip -d <vmlinuz >vmlinux should be fine.

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

[Andy Isaacson]

On Wed, Aug 09, 2000 at 07:17:02PM -0400, James Simmons wrote:
> > 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 :-)

SGI never did support the Visual Workstation 540 and 320 in Linux.
There did exist some code, but it was never a formal SGI product.

On Wed, Aug 09, 2000 at 07:28:07PM -0400, philloc@tigger.ccs.ornl.gov wrote:
> 	Anyone from SGI care to comment on why SGI has not released the
> specs to reasonable attention, since they are unable to help port? 

I don't speak for SGI, but in the past I think they said that the
specs basically do not exist in a releasable form.  Basically, the
hardware developers and software developers worked in the same hallway
and the development was of the form "hey Joe, how do I program the
zapbot to do foobaz?"

OK, maybe that's not quite accurate, but the result is that there are
no plans to release specs.

-andy
-- 
Andy Isaacson <adi@mr-happy.com> http://web.mr-happy.com/~adi/
I want to buy your broken laptop! http://web.mr-happy.com/~adi/laptop.html

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

[James Simmons]

> On Wed, Aug 09, 2000 at 07:28:07PM -0400, philloc@tigger.ccs.ornl.gov wrote:
> > 	Anyone from SGI care to comment on why SGI has not released the
> > specs to reasonable attention, since they are unable to help port? 
> 
> I don't speak for SGI, but in the past I think they said that the
> specs basically do not exist in a releasable form.  Basically, the
> hardware developers and software developers worked in the same hallway
> and the development was of the form "hey Joe, how do I program the
> zapbot to do foobaz?"

Actually you are right. The lack of docs internally in SGI has caused this
problem. This also has had the bad side effect of when they lose a
critical employee then no one else has a clue on how it program it. You
have to start from scratch. 

[OT]. This actually happend to M$ as well. One person wrote they entire
registery for win95. He left the company and when it came time to port it
to win2000 no one understood how it worked. So they had to rewrite it from
scratch. 

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

[Shrijeet Mukherjee]

On Tue, 22 Aug 2000, James Simmons wrote:

JS>> I don't speak for SGI, but in the past I think they said that the
JS>> specs basically do not exist in a releasable form.  Basically, the
JS>> hardware developers and software developers worked in the same hallway
JS>> and the development was of the form "hey Joe, how do I program the
JS>> zapbot to do foobaz?"
JS>
JS>Actually you are right. The lack of docs internally in SGI has caused this
JS>problem. This also has had the bad side effect of when they lose a
JS>critical employee then no one else has a clue on how it program it. You
JS>have to start from scratch. 
JS>

Well as I have tried to explain in the past the situation is not as cut
and dry as all that. For most hardware systems, well written driver code
is a good place to start. (in fact al of the internal port to linux for
the 320 was done without formal docs, or the engg's to talk to)

The real problem is that the 320 gfx family uses a SGI style
high-performance which is different from the AGP style approach that the
other guys use. Porting this to linux .. or more than knowing how the
hardware works .. since we need to port a very complicated mechanism, for
which linux may not have obvious and ready replacements.

On top of that .. there are potentially Intellectual Property issues with
the management style. Thus the concerns with just releasing the specs.

Since this is a recurring question, are there people on this list that are
personally motivated to try and port this system over ?

Std Disclaimer: I am not speaking for SGI .. all opinions expressed here
and mine and mine alone.

Thanx

-- 
--------------------------------------------------------------------------
Shrijeet Mukherjee,    		        Advanced Graphics, SGI
http://reality.sgi.com/shm_engr     	phone: 650-933-5312
email: shm@sgi.com, shrijeet@hotmail.com
--------------------------------------------------------------------------
Where there is a will, there is a way. If a way cannot be found, 
it is the will that is suspect ..                                   -- shm 

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

[Shrijeet Mukherjee]

On Tue, 22 Aug 2000, James Simmons wrote:

JS>> I don't speak for SGI, but in the past I think they said that the
JS>> specs basically do not exist in a releasable form.  Basically, the
JS>> hardware developers and software developers worked in the same hallway
JS>> and the development was of the form "hey Joe, how do I program the
JS>> zapbot to do foobaz?"
JS>
JS>Actually you are right. The lack of docs internally in SGI has caused this
JS>problem. This also has had the bad side effect of when they lose a
JS>critical employee then no one else has a clue on how it program it. You
JS>have to start from scratch. 
JS>

Well as I have tried to explain in the past the situation is not as cut
and dry as all that. For most hardware systems, well written driver code
is a good place to start. (in fact al of the internal port to linux for
the 320 was done without formal docs, or the engg's to talk to)

The real problem is that the 320 gfx family uses a SGI style
high-performance which is different from the AGP style approach that the
other guys use. Porting this to linux .. or more than knowing how the
hardware works .. since we need to port a very complicated mechanism, for
which linux may not have obvious and ready replacements.

On top of that .. there are potentially Intellectual Property issues with
the management style. Thus the concerns with just releasing the specs.

Since this is a recurring question, are there people on this list that are
personally motivated to try and port this system over ?

Std Disclaimer: I am not speaking for SGI .. all opinions expressed here
and mine and mine alone.

Thanx

-- 
--------------------------------------------------------------------------
Shrijeet Mukherjee,    		        Advanced Graphics, SGI
http://reality.sgi.com/shm_engr     	phone: 650-933-5312
email: shm@sgi.com, shrijeet@hotmail.com
--------------------------------------------------------------------------
Where there is a will, there is a way. If a way cannot be found, 
it is the will that is suspect ..                                   -- shm 

Re: [linux-fbdev] SGI VW 540, fbdev... and other stuff

[Ehab Fares]

On Tue, 22 Aug 2000, Shrijeet Mukherjee wrote:
> Well as I have tried to explain in the past the situation is not as cut
> and dry as all that. For most hardware systems, well written driver code
> is a good place to start. (in fact al of the internal port to linux for
> the 320 was done without formal docs, or the engg's to talk to)
> 
> The real problem is that the 320 gfx family uses a SGI style
> high-performance which is different from the AGP style approach that the
> other guys use. Porting this to linux .. or more than knowing how the
> hardware works .. since we need to port a very complicated mechanism, for
> which linux may not have obvious and ready replacements.
> 
> On top of that .. there are potentially Intellectual Property issues with
> the management style. Thus the concerns with just releasing the specs.
> 
> Since this is a recurring question, are there people on this list that are
> personally motivated to try and port this system over ?
> 
We are using a 540 system with the top configuration (4 processors, 2GB Ram and
the flat panel 1600SW). We are certainly motivated to get linux and the
X-Server working  poperly. As already posted in this mailing list the X-server
is not the only problem. I therefore would suggest to start collecting all the
problems that should be solved and look for people interested in working on
the port.  

The problems we have are:
1) new kernels simply wouldn'[t boot the machine. I got the machine working
with  the 2.2.10 patched kernel. All the four processors are working.
2) We have only 960 MB Ram of the installed 2GB working.
3) strange behaviour of the keyboard.
4) the parallel port is not working. (we haven't tested the rest of the ports)
5) very poor X performance with hangs every now and then which is probably
because of the X-Server.

Are there other people having similar or other problems and interested in
solving them? Is there anyone who have the experience or knowledge of that
system (and linux) who can help?

I personally would like to help but need some information and
details as I'm not a kernel hacker. 

Ehab.