HDTenEightyP/NetNews huggingface dataset:
From: fred@poly2.nist.gov (Frederick R. Phelan Jr.)
Newsgroups: comp.sys.sgi
Subject: GL card for PC
Date: 30 Dec 92 19:48:59 GMT

A few months ago there was a post about a card for pc's that enables support for gl
programs.  Unfortunately I didn't save it.  Could anybody whow has the information
send it to me?

I'm also wondering how this card works.  Does it essentially turn the pc into a gl
server for programs running remotely on a worksation?

Thank you.

Fred
---
Fred Phelan
fred@poly2.nist.gov

Newsgroups: comp.sys.sgi
From: prevost@eos.arc.nasa.gov (Michael Prevost)
Subject: Re: what happens to big color values?
Organization: NASA Ames Research Center
Distribution: comp
Date: Wed, 30 Dec 1992 05:57:31 GMT

kurt@cashew.asd.sgi.com (Kurt Akeley) writes:

>-- 

>In article <C002M8.3D8.1@cs.cmu.edu>, gleicher@CS.CMU.EDU (Michael Gleicher) writes:
>|> 
>|> When lighting calculations are taking place, what happens when color values
>|> are > 1?
>|> 
>|> I'm computing the lighting "manually" in a program as well as displaying it on
>|> the screen. For points whose RGB value is computed > 1, I'm not seeing the
>|> expected results. For instance, what I compute as an RGB value of
>|> (1.5,1.4,.9), I'd expect to appear nearly white (since I expected the values >
>|> 1 to be truncated), but it appears yellow.
>|> The things which could be happening are:
>|> 	1) truncation (this is what I expected, but doesn't seem to be the
>|> 		case) 
>|> 	2) normalization (eg: make the vector be unit magnitude)
>|> 	3) divide by the largest element
>|> 	4) something else
>|> 
>|> If someone could fill me in, I'd be most grateful.

>The color components should be independently clamped (not truncated)
>to 1.0, resulting in a color near white.  What hardware are you running on?

There was also for a short period a bug in the color routine that didn't
clamp the values correctly. This was fixed on the next release. It was 
IRIX 3.???. It was fixed by 4.0.


-- 
Michael Prevost
Sterling Software
moffett Field Ca.
prevost@eos.arc.nasa.gov
Newsgroups: comp.sys.sgi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: SYSLOG errors?!
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Sat, 2 Jan 1993 18:17:01 GMT

In article <C07u4I.68G@rahul.net>, jonathan@rahul.net (Jonathan Heiliger) writes:
>    I recently upgraded my version of Sendmail with the one available from 
> sgi.com via anonymous FTP.  Ever since this time, I get these errors:
> 
> hostname:% mailq
> orderq: qfAA00371 is a FIFO?!?        <- as in this...
> Mail queue is empty
> 
> And this appears in my SYSLOG in '/usr/adm'
> 
> 09:26 mecca sendmail[1333]: NOQUEUE: SYSERR: orderq: qfAA00371 is a FIFO?!?
> 
>    Does anyone have any idea of how to fix this?  Other than the annoyance 
> that every 2-3 days my SYSLOG file is 100k+ there are no problems.  Thanks. 


The trouble is that a file in your /usr/spool/mqueue has been corrupted
and appears to be a "FIFO".  The new version of sendmail defends itself
against such problems.  (Previous versions would just lock up trying to
read from the pipe.)

The fix is to remove any non-files in /usr/spool/mqueue.


Vernon Schryver,  vjs@sgi.com
From: bergman@glycine.cs.unc.edu (Larry Bergman)
Newsgroups: comp.sys.sgi
Subject: anti-aliasing/depthcuing problem
Date: 23 Dec 92 16:59:19 GMT

I'm having difficulty toggling anit-aliasing and
depthcuing in my program.  If I specify anti-aliasing
(using "subpixel(TRUE); linesmooth(SML_ON);
blendfunction(BF_SA,BF_MSA);") or depthcuing
(using "depthcue(TRUE);") at the start of the program,
both work fine (all these commands after "gconfig").  
If I try to turn them on, using the same commands while
the program is running, I get no results.  Is there
somthing else I need to be doing.  Any tips will be
welcome.

Thanks,  Larry Bergman
-- 


Newsgroups: comp.sys.sgi
From: PREINERT@CIPVAX.BIOLAN.UNI-KOELN.DE (Peter Reinert)
Subject: games for INDIGO?
Organization: BIOLAN - COLOGNE UNIVERSITY (FRG)
Date: Wed, 23 Dec 92 16:58:18 GMT
X-News-Reader: VMS NEWS 1.22

Hello netters,

sorry for the childish question:

Are there any games running on INDIGOS?
I'm particulary interested in Dungeon Games.

Please reply directly via e-mail.

Many thanks in advance!

Merry christmas and a happy new year!


			Peter Reinert
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: Question About 4.0.5 SGI Demos
Date: 27 Dec 92 22:06:18 GMT
Distribution: usa
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1992Dec24.164814.18136@eagle.lerc.nasa.gov> ttbob@raphael.lerc.nasa.gov (Robert Orszycki) writes:

| When I load eoe2.sw.demos in IRIX 4.0.5, I notice a few differences.
| 
| Loaded to an Indigo, GTX, VGX, the following files for "flight" exist:
| 
| l---------   1 root     sys           21 Sep 17 13:47 dog@ -> /usr/demos/bin/fli
| -rwxr-xr-x   1 demos    demos     299184 Sep 17 13:47 flight*
| -rwxr-xr-x   1 demos    demos     405680 Sep 17 13:47 flight_8bit*
| l---------   1 root     sys           21 Sep 17 13:47 shadow@ -> /usr/demos/bin/
| 
| On a Personal IRIX 4D/35 (all three I loaded it to) only the following appears:
| -rwxr-xr-x   1 demos    demos     405680 Sep 17 13:47 flight_8bit*
| 
| Is flight not supported on the PI?

Yes, but the flight (without the suffix) is the newer version with
texture mapping, etc. as I recall, so you should use flight_8bit,
from what I remember.  Perhaps Rob will comment further on this.

| If so, are there other demos besides "flight" that are not loaded by 4.0.5
| on the PI?

There are a large number of demos that are machine tagged, either because
they require specific features to run, or it was decided that they ran
too slow/poorly on other graphics.

If you have the CD-ROM, try mounting it, cd'ing to /mountpt/dist, and
running this command:
	egrep 'usr/demos.*GFXBOARD' *.idb
to see the machine tagged files.  Note that some may be installed
if any of several graphics boards are present.

| Here is output from hinv on the PI.
| 1 36 MHZ IP12 Processor
| FPU: MIPS R2010A/R3010 VLSI Floating Point Chip Revision: 4.0
| CPU: MIPS R2000A/R3000 Processor Chip Revision: 3.0

For future reference, most people at SGI (in engineering, anyway)
don't call this a PI, even though it is in the same plastics.  That
term is usually used for the 4D/20 or 25.  Sales and marketing
types and literature may not agree with this, of course ;)

If you had the Elan or XS graphics I seem to recall the other version
of flight gets installed (the 4D/30 and 35 do support these newer
graphics boards, since they are architecturally almost identical to
the Indigo).
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
From: flash@austin.lockheed.com (James W. Melton)
Newsgroups: comp.sys.sgi.bugs
Subject: Re: Pandora Login Failure
Date: 29 Dec 92 04:43:11 GMT
Organization: "Lockheed Austin Division, 6800 Burleson Rd, Austin, TX 78744

In article <1haq6bINNahs@fido.asd.sgi.com> aschaffe@holodeck.csd.sgi.com (Allan Schaffer) writes:
>
>Check to see if /etc/config/system.glGammaVal has a length of 0.  
>If so, edit the file and put the number 1.700000 into it.
>

Wasn't this value at one time 1.6something? I have seen this
problem discussed many times, but never with a 1.7 value???

Or is this a new value, just to keep us guessing?
Xref: sparky comp.sys.sgi.bugs:52 comp.sys.sgi:18353
From: shectman@LLNL.Gov (Robert M. Shectman)
Newsgroups: comp.sys.sgi.bugs,comp.sys.sgi
Subject: rectzoom on Indigo
Keywords: rectzoom Indigo
Date: 28 Dec 92 20:24:36 GMT
Organization: Computer Systems Research Group, LLNL

I have a brand new Indigo 4000 Elan, running 4.0.5f and I am in the process of moving some code from a VGX to the Indigo.

I have a true color window with pixmode(PM_TTOB,1) and
                                rectzoom(4.0,4.0)

When I run this program, and do an lrectwrite to this window, I get a graphics error that wipes out the graphics server.  The SYSLOG reports:

	unix: WARNING: VDMA error : MC rev 1 (1) status 1
   	unix: WARNING: Gr2PixelDma graphics error
   	unix: WARNING: Graphics error: GE PC = 0x4045
	Xsession: shectman: fatal IO error 32 (Broken pipe)

The lrectwrite is writing a 128 x 128 truecolor array into a 512 x 512 window.
It is the rectzoom that is the cause of the problem.  If I comment out the
rectzoom the program does not trigger the graphics error.

If I run the same program on a VGX sending the graphics to my Indigo with
a rectzoom of 4x4, the program does not crash with an error.  On the other hand the rectzoom is not performed correctly either.  It appears more like a 2.5x4 zoom with the upper section of the window appearing as mostly black with an occasional random colored pixel thrown in.

Is this a known problem?  Are there any work-arounds other than not zooming?


Robert M. Shectman
Lawrence Livermore National Laboratory
shectman@llnl.gov
Newsgroups: comp.sys.sgi.bugs
From: hoesel@igc.ethz.ch (Frans van Hoesel)
Subject: c-compiler false diagnostic.
Organization: University of Groningen, the Netherlands
Date: Wed, 23 Dec 1992 16:36:08 GMT

Hi ,

the c compiler on my indigo (4.0.1) gives the following warning on the
following program.
#include <stdio.h>

int main() {

        int i;
        int p[] = { 1,2,3,4,5};
        for (i = 0; i<5; i++ ) printf("%d ", p[i]);
        ;
        return 0;
}

> cc -fullwarn -ansi t4.c
accom: Warning 302: t4.c, line 8: bodyless for statement
        ;
       -^

This seems incorrect to me. (the warning I got was the result from some
huge preprocessor macro, not this little program above. It costed me
quite some time to discover that everything was ok, besides the warning
itself).

A - in my case - related question: is there a maximum length for the
replacement of a macro (can I have a macro with a body of say 10000
characters)?
-- frans

-- 
--    ==============================================================    --
----  ===  frans van hoesel             hoesel@igc.ethz.ch       ===  ----
--    ==============================================================    --
Newsgroups: comp.sys.sgi.bugs
Subject: Explorer & The NameServer
From: allon@batata.fh.huji.ac.il (Allon Herman)
Date: 29 Dec 92 17:17:56 GMT
Distribution: world
Organization: Hebrew U., Jerusalem Israel
Keywords: /usr/etc/resolv.conf

Dear neter's
We have encountered the following problem:
 explorer's GUI dumps a core file instead of doing what it is supposed to do.
I believe that in the earlier days of the explorer users have seen this problem,
anyway as I haven't seen any recent posting regarding this issue I'll describe
my solution.

  I have found out that the presence of /usr/etc/resolv.conf annoys the explorer,
when it was present the explorer died and dumped a core file, otherwise, it was
running perfectly okay. Introducing the hostresorder parameter to
/usr/etc/resolv.conf as follows solves the problem:

	>>hostresorder local bind

  I think that I have a good reason to believe that what actually annoys the
explorer is the that 127.0.0.1 resolves to localhost.FULDOMANNAME instead of
localhost. Lets hope that when explorer 2.0 is launched (RSN) this bug is fixed.



					Have lots of fun,
						Allon Herman.

Allon@batata.fh.huji.ac.il
From: ib@ivan.asd.sgi.com (Ivan Bach)
Newsgroups: comp.sys.sgi.bugs
Subject: Re: X Hebrew Support
Keywords: Hebrew, support, X Window System
Date: 27 Dec 92 14:46:35 GMT
Organization: Silicon Graphics, Inc., Mountain View, CA

The support for Hebrew in the X Window System will probably be based on Part 
8 of the international standard ISO8859 (ISO8859-8).  There will probably be
two Hebrew fonts that use the character encoding ISO8859-8 in the next major
release of the IRIX operating system.

If you want to add your own Hebrew fonts to the X Window System, I can give
you instructions on how to do that.

Ivan Bach, ib@sgi.com
Newsgroups: comp.sys.sgi.bugs
From: reinoud@dutecai.et.tudelft.nl (R. Lamberts)
Subject: Fix for 4.0.1 / 8M RAM slow disk writes
Originator: reinoud@dutecai.et.tudelft.nl
Reply-To: reinoud@dutecai.et.tudelft.nl (R. Lamberts)
Organization: Delft University of Technology, Dept. of Electrical Engineering
Date: Thu, 24 Dec 1992 01:34:46 GMT


OK guys, don't laugh. I still have 8 meg and IRIX 4.0.1,
and was getting sick of the slow disk write bug. If you
are in the same situation (8 meg / 4.0.1), this crazy
fix may be of interest to you.

It appears that doing a file system sync 20 times a second
increases disk write speed enormously, without giving too
much overhead. So compile something like this:

main()
{
  do
  {
    sync();
    sginap(5);
  }
  while (1);
}

(Please don't whine about this not being the best example
of software engineering. ;-)

If you use applications that write to disk at very high
rates, you may try to decrease the sginap argument, but
that results in a noticeable system load. Most tools
run at maximum write speed with the code shown above.

Run this thingy in the background and you'll actually start
enjoying large cp or file un-tar actions...

- Reinoud
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi.bugs
Subject: Re: Fix for 4.0.1 / 8M RAM slow disk writes
Date: 26 Dec 92 02:44:40 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1992Dec24.013446.26848@donau.et.tudelft.nl> reinoud@dutecai.et.tudelft.nl (R. Lamberts) writes:


| OK guys, don't laugh. I still have 8 meg and IRIX 4.0.1,
| and was getting sick of the slow disk write bug. If you
| are in the same situation (8 meg / 4.0.1), this crazy
| fix may be of interest to you.
| 
| It appears that doing a file system sync 20 times a second
| increases disk write speed enormously, without giving too
| much overhead. So compile something like this:
| 
| main()
| {
|   do
|   {
|     sync();
|     sginap(5);
|   }
|   while (1);
| }
| 
| (Please don't whine about this not being the best example
| of software engineering. ;-)
| 
| If you use applications that write to disk at very high
| rates, you may try to decrease the sginap argument, but
| that results in a noticeable system load. Most tools
| run at maximum write speed with the code shown above.
| 
| Run this thingy in the background and you'll actually start
| enjoying large cp or file un-tar actions...

The best fix is to get 4.0.5.  This bug was introduced in the last days
of 4.0.1, and fixed in 4.0.2 (after I found it (I wasn't the one who
introduced this one!) and all later releases.  The code has changed
enough since then that I don't want to invest the time to see  just
what else might help; certainly dropping BDFLUSHR to 1 would have
similar effects, without using up another process slot and causing
more context switches.  I seem to recall that increasing NBUF would help
prevent the situation from arising, but I may be remembering wrong.

Doing it ever 50 msecs (as your program does) seems just a *bit*
excessive though!
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
From: sd@chem.ucsd.edu (Steve Dempsey)
Newsgroups: comp.sys.sgi.bugs
Subject: new bug in 4.0.5 /usr/etc/dump
Date: 30 Dec 1992 20:04:24 GMT
Organization: University of California, San Diego
NNTP-Posting-Host: chedccf0.ucsd.edu

/usr/etc/dump in IRIX 4.0.5 does not correctly parse the "raw" field of the
entries in /etc/fstab.  If any other options follow the 'raw' device name
they are picked up as part of the name by "dump".  For example, this entry:

    /dev/dsk/dks1d5s6 /data1 efs rw,raw=/dev/rdsk/dks1d5s6,quota 0 0

causes "dump" to try to open the file "/dev/rdsk/dks1d5s6,quota".
This was NOT the case with IRIX 4.0.1.  The workaround is to make sure the
'raw' field is the last in the list.
---------------------------------------------------------------------------
Steve Dempsey					voice:	  (619) 534-0208
Dept. of Chemistry Computer Facility, 0314	UUCP:	  ucsd!sdempsey
University of Calif. at San Diego		BITNET:	  sdempsey@ucsd
9500 Gilman Drive				INTERNET: sdempsey@ucsd.edu
La Jolla, CA 92093-0314				fax:	  (619) 534-6255
From: davea@quasar.mti.sgi.com (David B.Anderson)
Newsgroups: comp.sys.sgi.bugs
Subject: Re: Recognizing which cc is being used.
Date: 23 Dec 92 21:40:32 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <BzqCEy.HG9@math.uwaterloo.ca> rbutterw@math.uwaterloo.ca (Ray Butterworth [MFCF]) writes:
>The cc(1) on IRIX 4.0.5f seems to operate in 3 different modes:
>-cckr, -ansi, and -xansi.
>
>-ansi  defines __STDC__
>-xansi doesn't, but does define __EXTENSIONS__
>-cckr also doesn't define __STDC__, and it also defines __EXTENSIONS__.
>
>How is one supposed to test (in the source) which of the
>last two modes the compiler is running under?
>(I suggest that -cckr should set some symbol to indicate this.)

See below

>In particular, does one use  token/**/token  or  token##token
>to join two cpp tokens in a macro?

Yes if ansi cpp (__ANSI_CPP__ is defined), no if not.
I have not figured out, or seen, any portable way to determine if ANSI CPP
or traditional Reiser cpp is in use.

I've been convinced that I was being wrongheaded: future releases 
WILL define __STDC__ with -xansi.

At that time, you will be able to test __STDC__

For now, well.....
[ David B. Anderson             (415)390-4263             davea@sgi.com ]
[ I am also sending mail: I though this was of enough general interest to post]
Newsgroups: comp.sys.sgi.bugs
From: hemmer@sun2.cern.ch (Frederic Hemmer)
Subject: close() BUG ?
Organization: CERN - European Laboratory for Particle Physics
Date: Mon, 21 Dec 1992 17:24:54 GMT


Perhaps I'm getting crazy (or tired), but I've a little problem
with close() used with ioctl(TIOCGWINSZ).

The following program :

#include <stdio.h>
#include <unistd.h>
#include <sys/termio.h>
#include <sys/types.h>
#include <fcntl.h>


/*
 * Getting terminal window size.
 */
int termwinsiz(col,row)
        int *col ;
        int *row ;
{
        int             term ;          /* Terminal identifier  */      
        struct winsize  win  ;          /* Window structure     */

        if ( (term= open("/dev/tty",O_RDWR)) == -1 ) {
                return -1 ;
        }
        if ( ioctl(term,TIOCGWINSZ,&win) == -1 ) {
                return -1 ;
        }
        if ( close(term) == -1 ) {
                return -1 ;
        }
        *col= win.ws_col ;
        *row= win.ws_row ;

        return 0 ;
}

main()  {
        int col;
        int row;

        if (termwinsiz(&col, &row) == -1)       {
                perror("unable to get terminal size");
        }
        else    {
                printf("Your window size is %dX%d\n", col, row);
        }
        exit (0);
}

Gives the following output on 4.0.5 (I believe it worked fine with 3):

unable to get terminal size: No such device

It is the close() syscall who complains.

Note that if I replace the close invocation by :

#if (defined(sgi) && defined(__EXTENSIONS__)) /* detects Irirx 4.0.5 */
        (void) close(term);
#else
        if ( close(term) == -1 ) {
                return -1 ;
        }
#endif /* sgi && __EXTENSIONS */

The output is fine :

	Your window size is 81X26

The same program worked without any problem on many systems
(sun, aix, hp, cray, ultrix ...)

Can somebody help ?

-- 
Frederic Hemmer                          email: hemmer@sun2.cern.ch
European Laboratory for Particle Physics bitnet: hemmer at cernvm
Computers and Networks division          phone: +41-22-7676104
CH-1211 Geneva 23 - Switzerland          fax:   +41-22-7677155
Newsgroups: comp.sys.sgi.bugs
From: "Ray Butterworth [MFCF]" <rbutterw@math.uwaterloo.ca>
Subject: Recognizing which cc is being used.
Organization: Math Faculty Computing Facility, University of Waterloo
Date: Wed, 23 Dec 1992 20:47:22 GMT

The cc(1) on IRIX 4.0.5f seems to operate in 3 different modes:
-cckr, -ansi, and -xansi.

-ansi  defines __STDC__
-xansi doesn't, but does define __EXTENSIONS__
-cckr also doesn't define __STDC__, and it also defines __EXTENSIONS__.

How is one supposed to test (in the source) which of the
last two modes the compiler is running under?
(I suggest that -cckr should set some symbol to indicate this.)

In particular, does one use  token/**/token  or  token##token
to join two cpp tokens in a macro?


I checked various stock header files for examples of how
it is supposed to be done, but with no luck.

The header file <sys/termio.h> contains:
   #define CTRL(c) ('c'&037)
which only works with -cckr, so this header file is in fact broken
since it needs a test for what kind of cpp is being used too.

And the header file <gl/dgl.h> has code like this:
   #ifdef __STDC__
   #define SIZEOF(x) size_##x
   #else
   #define SIZEOF(x) size_/**/x
   #endif /*__STDC__*/

But this particular section never gets looked at on IRIX,
so it doesn't matter that it doesn't work.


But I have my own header files that need to do something similar, 
and I can't find any #if test that will determine which form of
token joining should be used.

Note that suggestions of the form "put -D__ANSI__" on the command
line are of no help to me.  These header files must be used by
different people and Makefiles that might be calling different
versions of cc.  I can't expect everyone to change what they
are doing; in fact one of the purposes of the header files is
that they won't have to.  i.e. the solution has to be done
entirely within my header file(s).

(Please email any responses, since your article will probably
 expire over the holidays before I get a chance to read it.)
From: soubyran@ERE.UMontreal.CA (Soubyran Richard)
Newsgroups: comp.sys.sgi.bugs
Subject: ZModem
Date: 28 Dec 92 19:50:32 GMT
Organization: Universite de Montreal


Hello sgiers!

I have avery weird problem... When I am using zmodem (sz) to
transfer files between my Mac and the Indigo, the transfer hangs
and quit when there is only 6 seconds left in the transfer. This
problem exist only since we have changed the OS last summer. We
were running version 3 of IRIX back then. a few weeks ago, we
changed to IRIX 4.0.5 and now the transfer hangs just at 3 seconds
from the end... That's VERY strange...

Before upgrading to IRIX 3 something, everything was fine! When I
use Kermit, no problems at all... The tech support at our
university is no good at all...

	"We don't know what's wrong." 
	"We do not have that problem here in the office"
	etc

is all they can say.

One more thing... this problem occurs only if the file is big
enough to make the transfer go over 60 seconds. Any file less than
that... no problems...

Please help!

Richard Soubyran
soubyran@alize.ere.umontreal.ca
Newsgroups: comp.sys.sgi.bugs
From: apian@ise.fhg.de (Peter Apian-Bennewitz)
Subject: lmcolor on Indigo ELAN
Summary: lmcolor needed after light disable on elan ?!
Keywords: light,lmcolor,elan
Organization: FhG-ISE - Institute for Solar Energy Systems
Date: Tue, 29 Dec 92 01:00:30 GMT

Hi,

The following code behaves differently on a Indigo ELAN
and a 320VGX:

lmbind( ..wawawa )	/* switch lighting (lights,model,material) on */
lmcolor( LMC_AD );
  ..draw lighted stuff..
  .. c3f,n3f,v3f calls..

lmbind( LMODEL,0 );	/* disable lighting */
lmcolor( LMC_COLOR );	/* <- ?? */
  ..draw unlighted stuff..
  .. c3f,v3f calls..

Now, the unlighted stuff gets drawn depressingly black on a ELAN,
if lmcolor( LMC_COLOR ) is not used. 
The VGX behaviour is more similar to the man page: 
"lmcolor mode is significant only while lighting is on".

Bug, feature, or my bloody ignorance of something obvious ?

if( FAQ ) printf("our news server went offline for some weeks.sorry\n");

TIA

Peter

--------------------------------------------------------------------
 Peter Apian-Bennewitz				apian@ise.fhg.de
 Fraunhofer Institute for Solar Energy Systems	Tel +49-761-4014-123
 D-7800 Freiburg   ,  Oltmannsstrasse 22	Fax +49-761-4014-200
--------------------------------------------------------------------
Newsgroups: comp.sys.sgi.bugs