mesa3d-dev

Re: [Mesa3d-dev] Minor change requested in docs/README.3DFX

[Brian P. <br...@pr...>]

"James A. Treacy" wrote:
> 
> I got the following request from a user and see no reason not to implement it.
> It is rather minor, but allows the text to be cut and pasted directly into a
> shell script.
> 
> --- README.3DFX.orig    Fri Feb 11 20:35:30 2000
> +++ README.3DFX Wed Jun 28 17:25:33 2000
> @@ -184,9 +184,9 @@
>            quality. However you can use any visual depth supported by X.
> 
>         2. Set the following environment variables:
> -               export MESA_GLX_FX="window"     // to enable window rendering
> -               export SST_VGA_PASS=1   // to stop video signal switching
> -               export SST_NOSHUTDOWN=1 // to stop video signal switching
> +               export MESA_GLX_FX="window"     # to enable window rendering
> +               export SST_VGA_PASS=1   # to stop video signal switching
> +               export SST_NOSHUTDOWN=1 # to stop video signal switching
>             OR
>                 setenv MESA_GLX_FX window
>                 setenv SST_VGA_PASS 1

Done.

-Brian

[Mesa3d-dev] more lighting fixes

[Brian P. <br...@pr...>]

I've been spending the past few nights fixing GL conformance
failures in Mesa 3.2 and 3.3.  I finally fixed the last lighting
bugs.  The most recent changes fix the (somewhat broken) handling
of ambient lighting terms.

If anyone has suspected that their ambient lighting wasn't coming
out correct please grab the latest Mesa 3.2 or 3.3 code out of CVS
and test.

As of now, Mesa 3.2.x now only fails AA points and AA triangles but
those have been fixed for 3.3.

Mesa 3.3 now passes all GL conformance tests except line stippling.
That shouldn't be too hard to fix.

I've got a couple other tiny bugs to fix in 3.2 before I make a
3.2.1 release.  A 3.3 release should follow soon after.

-Brian

[Mesa3d-dev] SGI Free Software license B v1.1: Is it Free?

[James A. T. <tr...@de...>]

While the license has some interesting points, that will inspire strong
opinions from many directions, I believe that the issue of compatibility
with the DFSG comes down to section 2.3.

Here's my quick take on what SGI is trying to accomplish. They want
to allow free use of the software, but in software form only; don't
try translating one of the algorithms for use in hardware. They
also want free use of any patents that a user holds on algorithms used
in the software. Pretty slick -- A company notices that the code uses
an algorithm they have patented, but only after executing the code.
They can't sue because by using the software they have given SGI
free use of their patent. Would it hold up in court? I have no idea.
They also allow the software to be redistributed under a different
license. The issues are sufficiently muddled that it probably isn't
worth attempting.

In addition to deciding whether the license is compatable with the
DFSG, it is also important that it be compatable with the current
license used by mesa. Luckily, this second issue doesn't appear to
be a problem.

Since Debian has a number of people who have experience with licenses
and are sufficiently demented^H^H^H^H^H^Hinterested to spend some time
on this issue, I'll forward this to debian-legal and see what they
have to say on the issue.

-- 
James (Jay) Treacy
tr...@de...

Re: [Mesa3d-dev] Inconsistent scan conversion in XOR mode

[Howard <ho...@me...>]

----- Original Message -----
From: "Brian Paul" <br...@pr...>
To: "Howard" <ho...@me...>
> >
> > Has anyone else observed a problem with the scan conversion of vertical
and
> > horizontal lines while in XOR mode. We have consistently observed that
there
> > are:
> > a) Irregularities in vertical and horizontal line, i.e. 4 - 10 pixel
spans
> > that are offset by a pixel.
> > b) Non repeating patterns, i.e. the same vertical or horizontal line
> > coordinates plot these irregularities differently. This is especially
> > visible/troublesome in the XOR case, because the 2nd, (erase) draw does
not
> > cover the same pixels, and consequently leaves scars. This only seems to
> > happen in the vertical/horizontal cases and does not happen when in a
> > normal, (non XOR) mode.
>
> I've seen a problem in which a clipped, vertical, wide line will "wiggle"
> left/right by a pixel.  When I looked into it it was a case where one
> endpoint was at X=5 and the other at x=4.999 (for example).
>
> Are your endpoints being clipped?
>
No, there is no clipping. There must a round-off of some kind. The data
points are the same, but the view matrix could be slightly different. The
funny thing is, the start and end points will be level, but the path, as you
say, "wiggles", when in XOR mode. The problem is not present with the same
code on Irix. We will try to distill this down to a small example if no one
else is experiencing it.

Thanks,
--
Howard Luby     Fax:248 540-3138 Tel:248 540-2251
ho...@me... http://www.mediascape.com

[Mesa3d-dev] Minor change requested in docs/README.3DFX

[James A. T. <tr...@de...>]

I got the following request from a user and see no reason not to implement it.
It is rather minor, but allows the text to be cut and pasted directly into a
shell script.

--- README.3DFX.orig	Fri Feb 11 20:35:30 2000
+++ README.3DFX	Wed Jun 28 17:25:33 2000
@@ -184,9 +184,9 @@
 	   quality. However you can use any visual depth supported by X.
 
 	2. Set the following environment variables:
-		export MESA_GLX_FX="window"	// to enable window rendering
-		export SST_VGA_PASS=1	// to stop video signal switching
-		export SST_NOSHUTDOWN=1	// to stop video signal switching
+		export MESA_GLX_FX="window"	# to enable window rendering
+		export SST_VGA_PASS=1	# to stop video signal switching
+		export SST_NOSHUTDOWN=1	# to stop video signal switching
 	    OR
 		setenv MESA_GLX_FX window
 		setenv SST_VGA_PASS 1

-- 
James (Jay) Treacy
tr...@de...

[Mesa3d-dev] libMesaGLw vs. libGLw: which is preferred

[James A. T. <tr...@de...>]

Debian has (mostly) converted to using lib{GL,GLU} from libMesa{GL,GLU}
for the library names. Is it recommended that we also drop Mesa from
the names of the mesa widgets, GLw and GLwM?

-- 
James (Jay) Treacy
tr...@de...

Re: [Mesa3d-dev] Inconsistent scan conversion in XOR mode

[Brian P. <br...@pr...>]

Howard wrote:
> 
> Has anyone else observed a problem with the scan conversion of vertical and
> horizontal lines while in XOR mode. We have consistently observed that there
> are:
> a) Irregularities in vertical and horizontal line, i.e. 4 - 10 pixel spans
> that are offset by a pixel.
> b) Non repeating patterns, i.e. the same vertical or horizontal line
> coordinates plot these irregularities differently. This is especially
> visible/troublesome in the XOR case, because the 2nd, (erase) draw does not
> cover the same pixels, and consequently leaves scars. This only seems to
> happen in the vertical/horizontal cases and does not happen when in a
> normal, (non XOR) mode.

I've seen a problem in which a clipped, vertical, wide line will "wiggle"
left/right by a pixel.  When I looked into it it was a case where one
endpoint was at X=5 and the other at x=4.999 (for example).

Are your endpoints being clipped?

-Brian

[Mesa3d-dev] Inconsistent scan conversion in XOR mode

[Howard <ho...@me...>]

Has anyone else observed a problem with the scan conversion of vertical and
horizontal lines while in XOR mode. We have consistently observed that there
are:
a) Irregularities in vertical and horizontal line, i.e. 4 - 10 pixel spans
that are offset by a pixel.
b) Non repeating patterns, i.e. the same vertical or horizontal line
coordinates plot these irregularities differently. This is especially
visible/troublesome in the XOR case, because the 2nd, (erase) draw does not
cover the same pixels, and consequently leaves scars. This only seems to
happen in the vertical/horizontal cases and does not happen when in a
normal, (non XOR) mode.

Thanks,
--
Howard Luby     Fax:248 540-3138 Tel:248 540-2251
ho...@me... http://www.mediascape.com

[Mesa3d-dev] Re: [ogl-sample] SGI SI GLU integration

[Dave S. <shr...@sg...>]

Brian Paul writes:
> Olivier Michel wrote:
> 
> > b) The old OpenGL 1.0 constants GL_LOGIC_OP AND GL_TEXTURE_COMPONENT are
> > redefined in SGI glu.h (they are previously defined in Mesa gl.h)
> > => idea: move them into SGI gl.h
> 
> glu.h should not define any GL_* tokens.  Could you send me your glu.h
> file?

   I believe this situation is caused by an error in SGI's header
generator script.  I'll take a look at it.

Thanx,
Dave

  ---------------------------------------------------------------------

   Dave Shreiner                                   <shr...@sg...>
   Silicon Graphics, Inc.                            (650) 933-4899

[Mesa3d-dev] Re: [ogl-sample] SGI SI GLU integration

[Brian P. <br...@pr...>]

Olivier Michel wrote:
> 
> Hello,
> 
> I wrote the ogl-sample-glu.spec RPM file to produce the RPM package for
> SGI SI GLU and everything seemed fine. I could build the
> ogl-sample-glu-20000126.i386.rpm file properly.
> 
> I also built a mesa-without-glu-280600.i386.rpm for testing SGI SI GLU
> with mesa core GL.
> 
> However, I had a couple of problems when trying to get it work:
> 
> 1) The SGI glu.h file has some problem with Mesa gl.h file:
> 
> a) The typedef void (*_GLfuncptr) defined in SGI gl.h but not in Mesa
> gl.h
> => idea: either add this typedef to Mesa gl.h,
>    or use something different in SGI glu.h (like *_GLUfuncptr)

My understanding was the _GLfuncptr was something added in order to
make work the autogeneration of the header files from the spec files.
It's supposed to be a private symbol.

I like the idea of glu.h defining _GLUfuncptr if it needs it.


> b) The old OpenGL 1.0 constants GL_LOGIC_OP AND GL_TEXTURE_COMPONENT are
> redefined in SGI glu.h (they are previously defined in Mesa gl.h)
> => idea: move them into SGI gl.h

glu.h should not define any GL_* tokens.  Could you send me your glu.h
file?


> 2) The libGLU.so built from the GNUmakefile does not contain the C++
> symbols like __pure_virtual. This is Ok if you link it with a C++ app,
> but it causes an undefined symbol when linking with C programs or
> libraries. I could work around this problem by linking by hand the
> libGLU.so using g++ instead of ld:
> 
> g++ -shared -Wl,-soname,libGLU.so libutil/*.o libtess/*.o etc.
> 
> Fixing this would require big change the GNUmakefile and included files
> in the ogl-sample package. I didn't do it because I was afraid of
> breaking other things (in the build of other libraries than GLU).

When you build the libGLU.so shared library, could you add -lg++
(the C++ runtime lib) to the list of objects?  That way, libGLU.so
would be implicitly linked to libg++.so, so hopefully the end-user
could use the regular gcc linker.


> Anyway, I did all that with the downloadable tarball of ogl-sample
> (ogl-sample-20000126.tgz) because I was unable to get the CVS source
> tree version (apparently, there is a broken link on the web page).
> 
> Any help or advices greatly appreciated.

Here's how I get the ogl-sample CVS files:

% cvs -d:pserver:cv...@os...:/cvs login
password is cvs

% cvs -d:pserver:cv...@os...:/cvs co projects/ogl-sample/main


-Brian

[Mesa3d-dev] SGI SI GLU integration

[Olivier M. <Oli...@cy...>]

Hello,

I wrote the ogl-sample-glu.spec RPM file to produce the RPM package for
SGI SI GLU and everything seemed fine. I could build the
ogl-sample-glu-20000126.i386.rpm file properly.

I also built a mesa-without-glu-280600.i386.rpm for testing SGI SI GLU
with mesa core GL.

However, I had a couple of problems when trying to get it work:

1) The SGI glu.h file has some problem with Mesa gl.h file:

a) The typedef void (*_GLfuncptr) defined in SGI gl.h but not in Mesa
gl.h
=> idea: either add this typedef to Mesa gl.h,
   or use something different in SGI glu.h (like *_GLUfuncptr)

b) The old OpenGL 1.0 constants GL_LOGIC_OP AND GL_TEXTURE_COMPONENT are
redefined in SGI glu.h (they are previously defined in Mesa gl.h)
=> idea: move them into SGI gl.h

2) The libGLU.so built from the GNUmakefile does not contain the C++
symbols like __pure_virtual. This is Ok if you link it with a C++ app,
but it causes an undefined symbol when linking with C programs or
libraries. I could work around this problem by linking by hand the
libGLU.so using g++ instead of ld:

g++ -shared -Wl,-soname,libGLU.so libutil/*.o libtess/*.o etc.

Fixing this would require big change the GNUmakefile and included files
in the ogl-sample package. I didn't do it because I was afraid of
breaking other things (in the build of other libraries than GLU).

Anyway, I did all that with the downloadable tarball of ogl-sample
(ogl-sample-20000126.tgz) because I was unable to get the CVS source
tree version (apparently, there is a broken link on the web page).

Any help or advices greatly appreciated.

-Olivier

[Mesa3d-dev] recent Mesa changes

[Brian P. <br...@pr...>]

1. I've moved the programs that used to be in 3Dfx/demos/ into the demos/
   directory since they're also suitable for other 3D hardware, not just 3dfx.
   If you update with 'cvs update -P' it'll prune away the dead 3Dfx/
   directory.

2. Holger Waechtler has implemented the GL_EXT_texture_env_combine extension.
   I applied his patch this afternoon.  Thanks, Holger!

3. Gareth Hughes implemented new functions for allocating memory on
   arbitrary memory alignment boundaries.  By aligning floating point
   arrays on 16-byte boundaries (for example) we should be able to make
   better use of caching and memory fetches with 3DNow and SSE instructions.
   It might even help in tiny bit in ordinary x86 FP code too.
   Thanks, Gareth!

This has all been checked into the 3.3 trunk.

Please report any problems ASAP.

-Brian

Re: [Mesa3d-dev] GLU tessellator (was something completely OT)

[Allen A. <ak...@po...>]

On Tue, Jun 27, 2000 at 09:21:35AM -0500, Stephen J Baker wrote:
| 
| ...I don't think anyone is every *likely* to want to put GLU
| into hardware ...

Although at one time HP shipped a machine that accelerated trimmed
NURBS, so it's possible.  (Unlikely anytime soon, I agree.)

|              ...that clause is almost certainly intended to
| apply only to the core GL functions.  I don't know whether
| Debian's guidelines require authors to grant permission for
| hardware implementations of the code...

I think the clause is there to avoid liability for contributory
infringement -- the notion that if an OpenGL feature leads someone to
develop hardware that infringes on a patent held by a third party,
then SGI (as the OpenGL licensor) won't be subject to suit by the
third party for contributing to the infringement of the patent.

Don't know what the Debian folks think about this.  Personally, I
don't think it's a big deal.  Anytime someone wants to ship hardware
they have to deal with the possibility that they might infringe on
someone's patents.  All the clause does is take SGI out of the loop in
such cases.

Allen

Re: [Mesa3d-dev] GL_INTENSITY as a base format for texture images?

[Brian P. <br...@pr...>]

Gareth Hughes wrote:
> 
> Brian, this is in relation to the demo program I sent you earlier.
> 
> I've adapted one of the old GLUT demos to test all the different texture
> environment modes for all texture formats.  The problem I'm seeing is
> textures with GL_INTENSITY as a base or internal format.  It appears
> that GL_INTENSITY is an illegal base format for an image (as it's not
> valid for glDrawPixels) and thus is rejected in the format/type test in
> Mesa (can't remember where that test is).  Perhaps I'm just missing
> something, but my quick reading of the spec and the Red Book seem to
> indicate that this is in fact true, but it really doesn't make sense to
> me.
> 
> The GL_INTENSITY texture combine functionality will surely never be
> invoked if you can't make a GL_INTENSITY texture image, right?  From
> looking at the implementation of the apply_texture (or whatever)
> function, we need to be able to assign the base format to GL_INTENSITY
> to get the correct texturing functionality inside the software
> rasterizer, which is what I would have expected.  This is causing an
> error at the moment.
> 
> Caveat: I'm kinda working really hard at the moment and haven't slept
> much lately.  Don't be too cruel if I'm an idiot :-)

You're right.  GL_INTENSITY wasn't being error checked correctly.
I've checked in the fix to the Mesa CVS trunk.  Thank!

It's kind of frustrating how the image formats accepted by glTex{Sub}Image,
glDraw/ReadPixels, glColorTable, glConvolutionFilter, etc. aren't uniform.

-Brian

[Mesa3d-dev] GL_INTENSITY as a base format for texture images?

[Gareth H. <ga...@va...>]

Brian, this is in relation to the demo program I sent you earlier.

I've adapted one of the old GLUT demos to test all the different texture
environment modes for all texture formats.  The problem I'm seeing is
textures with GL_INTENSITY as a base or internal format.  It appears
that GL_INTENSITY is an illegal base format for an image (as it's not
valid for glDrawPixels) and thus is rejected in the format/type test in
Mesa (can't remember where that test is).  Perhaps I'm just missing
something, but my quick reading of the spec and the Red Book seem to
indicate that this is in fact true, but it really doesn't make sense to
me.  

The GL_INTENSITY texture combine functionality will surely never be
invoked if you can't make a GL_INTENSITY texture image, right?  From
looking at the implementation of the apply_texture (or whatever)
function, we need to be able to assign the base format to GL_INTENSITY
to get the correct texturing functionality inside the software
rasterizer, which is what I would have expected.  This is causing an
error at the moment.

Caveat: I'm kinda working really hard at the moment and haven't slept
much lately.  Don't be too cruel if I'm an idiot :-)

-- Gareth

[Mesa3d-dev] SGI SI GLU RPM packaging for Mesa

[Olivier M. <Oli...@cy...>]

Hello,

After a discussion on the mesa3d-dev mailing list, it has been decided
by Brian Paul to drop the Mesa GLU and use the SGI SI GLU instead:

See the mailing list archive for reference:

http://www.geocrawler.com/lists/3/SourceForge/1290/0/3943395/
http://www.geocrawler.com/lists/3/SourceForge/1290/0/3943052/

I am not sure we could simply merge SGI GLU within Mesa distribution
(for license reasons).
However, I would like to make it easy for end users to use Mesa together
with SGI SI GLU.

For this reason, I would like to build a couple of binary RPM packages.
The first one would contain Mesa without its GLU and the second would
contain SGI SI GLU only (that is libGLU.so and associated soft links and
the glu.h header file). For this, it might be useful to add an RPM .spec
file into the SGI GLU CVS.

Maybe it could be even simpler for the end user to have a single binary
RPM package containing both Mesa GL and SGI GLU, but I don't know if
this is legally possible ?

Could someone from SGI-OSS let me know his point of view about it ?

Thank you.

-Olivier

Re: [Mesa3d-dev] GLU tessellator (was something completely OT)

[Olivier M. <Oli...@cy...>]

"James A. Treacy" wrote:
> 
> On Mon, Jun 26, 2000 at 03:43:18PM -0500, Stephen J Baker wrote:
> >
> > Do you think that the more 'pure' Linux distro's like Debian would
> > accept that?  It would be bad if OpenGL applications couldn't rely on
> > the existance of GLU for simple stuff like gluBuildMipMaps just
> > because we don't have a perfect tessellator or whatever.
> >
> Could someone point me to the license for SGI's version?

It's http://oss.sgi.com/projects/FreeB (be careful the first postscript
page seems corrupted, it created many gremlins on my printer, maybe the
.doc version is better).

> If the license does not comply with the Debian Free Software Guidelines
> (DFSG for short)(*) then the GLU library would have to go in non-free.
> 
> Just in case anyone is wondering, I am the Debian maintainer for mesa.
> 
> (*)They are basically the same as the Open Source definition, since the
> Open Source definition is based on the DFSG. See
> http://www.debian.org/social_contract#guidelines for details.

Let us know if you think that this SGI license fits with Debian DFSG.

Thanks,

-Olivier

Re: [Mesa3d-dev] GLU tessellator (was something completely OT)

[James A. T. <tr...@de...>]

On Mon, Jun 26, 2000 at 03:43:18PM -0500, Stephen J Baker wrote:
>  
> Do you think that the more 'pure' Linux distro's like Debian would
> accept that?  It would be bad if OpenGL applications couldn't rely on
> the existance of GLU for simple stuff like gluBuildMipMaps just
> because we don't have a perfect tessellator or whatever.
> 
Could someone point me to the license for SGI's version?

If the license does not comply with the Debian Free Software Guidelines
(DFSG for short)(*) then the GLU library would have to go in non-free.

Just in case anyone is wondering, I am the Debian maintainer for mesa.

(*)They are basically the same as the Open Source definition, since the
Open Source definition is based on the DFSG. See
http://www.debian.org/social_contract#guidelines for details.

-- 
James (Jay) Treacy
tr...@de...

[Mesa3d-dev] glide 2x

[winterlion <win...@fs...>]

I've got a patched glide 2x (for 3dfx/Banshee and 3dfx/3) that runs under
FB/dev (the framebuffer console in newer Linux and related)

Anyways, what chance is there for making Mesa accelerated under this
circumstance?  And what sections should I look at?

As far as I remember, the older glide can be accelerated under
console.  Or maybe it's only under DOS.

But any suggestions, let me know :)

G'day, eh? :)
	- Winterlion

PS: the glide patches are on the 3Dfx glide patch archives if anyone's
curious.  They're pretty primitive and could use some work :)

-- 
Trying to bring truth from beauty is Winterlion.
find at this <a href="http://www.geocities.com/winterlion">winterlions' page</a>

[Mesa3d-dev] lighting fixes

[Brian P. <br...@pr...>]

I've just committed several bug fixes for lighting problems in Mesa.
First, specular highlights were sometimes in the wrong place.
Second, glMaterial and glColorMaterial updates to the emissive or
ambient coefficients weren't always handled correctly.

I'd appreciate it if people would update their Mesa CVS trees
and test with your apps to make sure things work better (or as
the same, if you didn't have this problem).

-Brian

Re: [Mesa3d-dev] GLU tessellator (was something completely OT)

[Stephen J B. <sj...@li...>]

On Mon, 26 Jun 2000, Brian Paul wrote:

> Stephen J Baker wrote:
> > 
> > On Fri, 23 Jun 2000, Gareth Hughes wrote:
> > 
> > > Okay, here's the deal, for the record:
> > >
> > > Brian and I have discussed this, and we have decided to replace Mesa's
> > > GLU with the SI's one RSN.
> > 
> > I was under the impression that SGI's not-quite-OpenSource license would
> > be a problem here.
> 
> I'm thinking that I'll simply drop Mesa's GLU and require people to
> get SGI's GLU.  It would be nice if someone made RPMs or other easily
> installed images of SGI's GLU.
 
Do you think that the more 'pure' Linux distro's like Debian would
accept that?  It would be bad if OpenGL applications couldn't rely on
the existance of GLU for simple stuff like gluBuildMipMaps just
because we don't have a perfect tessellator or whatever.

Don't get me wrong though - I'd like to see SGI's SI GLU become
"The One True GLU".

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Mesa3d-dev] GLU tessellator (was something completely OT)

[Brian P. <br...@pr...>]

Hward Luby wrote:

> We can do that for Red Hat. Since it's only one file, we'll make a
> compressed .so. Do you want us to host it or should it go on sourceforge?

There's the libGLU.so library and glu.h header file.  Is it standard
practice to put the library and header in the same package?  It would
be the simplest for most people.

I'm not sure of the best place to host it right now.  The SGI SI site
might be best.



Olivier Michel wrote:

> Ok, so I am volunteer to do a re-packaging for SGI GLU. I plan to do the
> following:
> 
> 1) remove everything else than GLU (i.e., GL, GLX) from the SGI SI
> package.

Hopefully the main/gfx/lib/glu/ subdirectory can stand on its own.
That is, it doesn't have intimate dependencies on the rest of the sample
GL source tree.


> 2) get rid of C++ dependencies since I believe they are useless for GLU.

I think the GLU NURBS tessellator is written in C++.


> 3) create some standard and easy way to build (like the GNU
> ./configure;make;make install but also the old style "make target" as
> used in Mesa)
> 4) create one RPM source package and two binary RPM packages (Linux i386
> and Linux PPC)

There are already GNU makefiles within the tree.  It would be nice
if you could add rules to generate the binary and source RPMs and
have those rules put into the SI's CVS tree.

I think binary RPMs are the most important thing initially.  People
can download and compile the sources now but probably >95% of people
just want to simply install the library and header files with minimal
fuss.


> I am currently printing the license B from SGI to understand how I can
> remove parts / add new things.

I encourage you to work in cooperation with the SI developers/maintainers
rather than branch off.  I think they'd be receptive to someone helping
with packaging.


Perhaps you guys should join the SI mailing list and discuss your plans
there.

I'm sure a lot of people would appreciate you doing this!

-Brian

PS: A similar treatment for GLUT would be nice too.

Re: [Mesa3d-dev] GLU tessellator (was something completely OT)

[Howard <ho...@me...>]

----- Original Message -----
From: "Brian Paul" <br...@pr...>
>
> I'm thinking that I'll simply drop Mesa's GLU and require people to
> get SGI's GLU.  It would be nice if someone made RPMs or other easily
> installed images of SGI's GLU.
>
We can do that for Red Hat. Since it's only one file, we'll make a
compressed .so. Do you want us to host it or should it go on sourceforge?
--
Howard Luby     Fax:248 540-3138 Tel:248 540-2251
ho...@me... http://www.mediascape.com

Re: [Mesa3d-dev] GLU tessellator (was something completely OT)

[Olivier M. <Oli...@cy...>]

Brian Paul wrote:
> 
> Stephen J Baker wrote:
> >
> > On Fri, 23 Jun 2000, Gareth Hughes wrote:
> >
> > > Okay, here's the deal, for the record:
> > >
> > > Brian and I have discussed this, and we have decided to replace Mesa's
> > > GLU with the SI's one RSN.
> >
> > I was under the impression that SGI's not-quite-OpenSource license would
> > be a problem here.
> 
> I'm thinking that I'll simply drop Mesa's GLU and require people to
> get SGI's GLU.  It would be nice if someone made RPMs or other easily
> installed images of SGI's GLU.
> 
> -Brian

Ok, so I am volunteer to do a re-packaging for SGI GLU. I plan to do the
following:

1) remove everything else than GLU (i.e., GL, GLX) from the SGI SI
package.
2) get rid of C++ dependencies since I believe they are useless for GLU.
3) create some standard and easy way to build (like the GNU
./configure;make;make install but also the old style "make target" as
used in Mesa)
4) create one RPM source package and two binary RPM packages (Linux i386
and Linux PPC)

I am currently printing the license B from SGI to understand how I can
remove parts / add new things.

I will let you know when it's ready.

-Olivier

Re: [Mesa3d-dev] GLU tessellator (was something completely OT)

[Brian P. <br...@pr...>]

Stephen J Baker wrote:
> 
> On Fri, 23 Jun 2000, Gareth Hughes wrote:
> 
> > Okay, here's the deal, for the record:
> >
> > Brian and I have discussed this, and we have decided to replace Mesa's
> > GLU with the SI's one RSN.
> 
> I was under the impression that SGI's not-quite-OpenSource license would
> be a problem here.

I'm thinking that I'll simply drop Mesa's GLU and require people to
get SGI's GLU.  It would be nice if someone made RPMs or other easily
installed images of SGI's GLU.

-Brian