mesa3d-dev

Re: [Mesa3d-dev] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)

[Keith W. <ke...@va...>]

Brian Paul wrote:
> 
> Keith Whitwell wrote:
> >
> > Brian Paul wrote:
> > >
> > > CVSROOT:        /cvsroot/mesa3d
> > > Module name:    Mesa
> > > Repository:     Mesa/src/tnl_dd/
> > > Changes by:     brianp@usw-pr-cvs1.     01/03/05 14:40:10
> > >
> > > Modified files:
> > >       Mesa/src/tnl_dd/:
> > >         t_dd_vbtmp.h
> > >
> > >   Revision      Changes    Path
> > >   1.6           +160 -116  Mesa/src/tnl_dd/t_dd_vbtmp.h
> > >
> > > Log message:
> > >   fixed segfaults when tex unit 1 enabled, but not unit 0 (conform)
> >
> > Brian,
> >
> > This should already be handled by the code in  which checks
> > if texcoordptr[0] is null, and if so assigns it to texcoordptr[1]  (the
> > maximally numbered texcoordptr must be nonnull).
> >
> > The question is why this mechanism didn't work in your case - what hardware
> > demonstrated the problem?
> 
> i810 running 'conform -1 multitex.c'  VB->TexCoordPtr[0] was null and causing
> the segfault, around line 188 in t_dd_vbtmp.h.

I've found a way for this to happen.  Can you confirm that this occurs via
'i810_emit_contiguous_verts()' ?

Keith

Re: [Mesa3d-dev] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)

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

Keith Whitwell wrote:
> 
> Brian Paul wrote:
> >
> > CVSROOT:        /cvsroot/mesa3d
> > Module name:    Mesa
> > Repository:     Mesa/src/tnl_dd/
> > Changes by:     brianp@usw-pr-cvs1.     01/03/05 14:40:10
> >
> > Modified files:
> >       Mesa/src/tnl_dd/:
> >         t_dd_vbtmp.h
> >
> >   Revision      Changes    Path
> >   1.6           +160 -116  Mesa/src/tnl_dd/t_dd_vbtmp.h
> >
> > Log message:
> >   fixed segfaults when tex unit 1 enabled, but not unit 0 (conform)
> 
> Brian,
> 
> This should already be handled by the code in  which checks
> if texcoordptr[0] is null, and if so assigns it to texcoordptr[1]  (the
> maximally numbered texcoordptr must be nonnull).
> 
> The question is why this mechanism didn't work in your case - what hardware
> demonstrated the problem?

i810 running 'conform -1 multitex.c'  VB->TexCoordPtr[0] was null and causing
the segfault, around line 188 in t_dd_vbtmp.h.

-Brian

[Mesa3d-dev] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)

[Keith W. <ke...@va...>]

Brian Paul wrote:
> 
> CVSROOT:        /cvsroot/mesa3d
> Module name:    Mesa
> Repository:     Mesa/src/tnl_dd/
> Changes by:     brianp@usw-pr-cvs1.     01/03/05 14:40:10
> 
> Modified files:
>       Mesa/src/tnl_dd/:
>         t_dd_vbtmp.h
> 
>   Revision      Changes    Path
>   1.6           +160 -116  Mesa/src/tnl_dd/t_dd_vbtmp.h
> 
> Log message:
>   fixed segfaults when tex unit 1 enabled, but not unit 0 (conform)

Brian,

This should already be handled by the code in 'check_tex_sizes', which checks
if texcoordptr[0] is null, and if so assigns it to texcoordptr[1]  (the
maximally numbered texcoordptr must be nonnull).

The question is why this mechanism didn't work in your case - what hardware
demonstrated the problem?

Keith

Re: [Mesa3d-dev] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)

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

Keith Whitwell wrote:
> 
> Brian Paul wrote:
> >
> 
> > Log message:
> >   used indent to clean-up the code
> 
> Hooray!

Speaking of whitespace cleanups, I like having this in my .emacs file:

(defun gth-rm-trailing-spaces ()
  "Remove trailing whitespace from all lines in the current buffer."
  (interactive)
  (if (or (eq major-mode 'c-mode)
	  (eq major-mode 'asm-mode)
	  (eq major-mode 'makefile-mode))
      (progn
	(message "removing trailing whitespace...")
	(save-excursion
	  (goto-char (point-min))
	  (while (re-search-forward "[ \t]+$" nil t)
	    (delete-region (match-beginning 0)
			   (save-excursion
			     (end-of-line)
			     (point))))))))

(defun gth-rm-trailing-blank-lines ()
  "Remove trailing blank lines from the current buffer."
  (interactive)
  (if (or (eq major-mode 'c-mode)
	  (eq major-mode 'asm-mode)
	  (eq major-mode 'makefile-mode))
      (progn
	(message "removing extra lines at end of file...")
	(save-excursion
	  (goto-char (point-max))
	  (while (and (eq 0 (forward-line -1))
		      (looking-at "^[ \t]*$")))
	  (delete-matching-lines "^[ \t]*$")))))

(add-hook 'write-file-hooks 'gth-rm-trailing-spaces)
(add-hook 'write-file-hooks 'gth-rm-trailing-blank-lines)

Every time you save, it strips trailing whitespace and trailing blank
lines from the file.

-- Gareth

[Mesa3d-dev] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)

[Keith W. <ke...@va...>]

Brian Paul wrote:
> 

> Log message:
>   used indent to clean-up the code

Hooray!

Keith

[Mesa3d-dev] FetchTexel and new texture format/utility code

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

I really like the way this has come together.  I'm just filling out the
FetchTexel routines for the non-standard formats at the moment, but all
in all I think the texture image handling is much more driver-friendly. 
This, combined with the changes to the DD API for Tex[Sub]Image*, means
that texture state and image handling will be cleaner and certainly more
efficient where hardware drivers are concerned.

-- Gareth

Re: [Mesa3d-dev] Bug in imports.c

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

Brian Paul wrote:
> 
> I've fixed it.  It was just a silly mistake.

I'd made the same change locally, but wasn't sure if this was the
intended fix.

> The imports stuff is based on the OpenGL SI.  The idea is that the __GLimports
> struct is OpenGL's interface to basic system functions such as stdio, memory
> allocation, getenv, etc.
> 
> The goal is to make Mesa more interchangable with the SI.  It's not done yet.

It's certainly a nice way to handle this kind of stuff.

-- Gareth

Re: [Mesa3d-dev] Bug in imports.c

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

Gareth Hughes wrote:
> 
> I think this is pretty fatal:
> 
> static char *
> _mesa_getenv(__GLcontext *gc, const char *var)
> {
>    (void) gc;
>    return gc->imports.getenv(gc, var);
> }
> 
> void
> _mesa_InitDefaultImports(__GLimports *imports, void *driverCtx, void
> *other)
> {
>    ...
>    imports->getenv = _mesa_getenv;
>    ...
> }
> 
> It seems that this:
> 
> static void
> _mesa_warning(__GLcontext *gc, char *str)
> {
>    GLboolean debug;
> #ifdef DEBUG
>    debug = GL_TRUE;
> #else
> /* Whacko XFree86 macro:
>  */
> #ifdef getenv
> #undef getenv
> #endif
>    if (gc->imports.getenv(gc, "MESA_DEBUG")) {
>       debug = GL_TRUE;
>    }
>    else {
>       debug = GL_FALSE;
>    }
> #endif
>    if (debug) {
>       fprintf(stderr, "Mesa warning: %s\n", str);
>    }
> }
> 
> is preventing _mesa_getenv() from just calling getenv(), right?  There's
> obviously stuff going on here that I don't know about, so I'll leave it
> up to you Brian.

I've fixed it.  It was just a silly mistake.

The imports stuff is based on the OpenGL SI.  The idea is that the __GLimports
struct is OpenGL's interface to basic system functions such as stdio, memory
allocation, getenv, etc.

The goal is to make Mesa more interchangable with the SI.  It's not done yet.

-Brian

[Mesa3d-dev] Bug in imports.c

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

I think this is pretty fatal:

static char *
_mesa_getenv(__GLcontext *gc, const char *var)
{
   (void) gc;
   return gc->imports.getenv(gc, var);
}

void
_mesa_InitDefaultImports(__GLimports *imports, void *driverCtx, void
*other)
{
   ...
   imports->getenv = _mesa_getenv;
   ...
}


It seems that this:

static void
_mesa_warning(__GLcontext *gc, char *str)
{
   GLboolean debug;
#ifdef DEBUG
   debug = GL_TRUE;
#else
/* Whacko XFree86 macro:
 */
#ifdef getenv
#undef getenv
#endif
   if (gc->imports.getenv(gc, "MESA_DEBUG")) {
      debug = GL_TRUE;
   }
   else {
      debug = GL_FALSE;
   }
#endif
   if (debug) {
      fprintf(stderr, "Mesa warning: %s\n", str);
   }
}

is preventing _mesa_getenv() from just calling getenv(), right?  There's
obviously stuff going on here that I don't know about, so I'll leave it
up to you Brian.

-- Gareth

Re: [Mesa3d-dev] Mesa Init

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

Andrew Richardson wrote:
> 
> Is there a main function in Mesa that is only called once per library load?
> I could use a once per context, so that would do...

In src/context.c you'll find the one_time_init() function.  It's
called everytime a new context is created but its code is protected
by a static init flag so it only executes once.

-Brian

Re: [Mesa3d-dev] Mesa and it's inner functions

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

Andrew Richardson wrote:
> 
> Dear All,
>   Ive just come over from the DRI devel list. I've been looking at providing
> an SMP dispatch layer to Mesa to provide a means by which even if a client is
> not multithreaded  you can still get the whole process running ~2 as fast. I
> have'nt got the concentration to enumerate exactly how it works as ive been
> up ~all~ night coding. :)
>   Anyway I need some way to hook a set of dummy functions into mesa so that
> the client thinks the real openGL routine has been called without breaking
> the ABI (that I assume exists in Mesa). I can quite happily using the
> _mesa_<function-name> and _tnl_<function-name> but they don't cover the whole
> API. I need to know where the other functions are.
>   If anyone has a better idea of how to hook a set of routines info mesa
> without breaking the ABI I would like to know. I know that you have some sort
> of override layer thing. How does that work? Does it alow me to get my
> routines called without knackering the ABI, but does mesa then call the
> original layer or is that my responibility? If anyone can tell me I would be
> greatful.

You can override any GL entrypoint function by patching into the
API dispatch tables.  In the GLcontext struct you'll see:

   /* API function pointer tables */
   struct _glapi_table *Save;	/* Display list save funcs */
   struct _glapi_table *Exec;	/* Execute funcs */
   struct _glapi_table *CurrentDispatch;  /* == Save or Exec !! */

If you wanted to override glHint() for example, you'd do something
like

ctx->Exec->Hint = myHintFunction;

Then, you might have:

void myHintFunction(GLenum hint, GLenum value)
{
   /* my hint code here */

   /* call normal Mesa hint function */
   _mesa_Hint(hint, value);
}

-Brian

Re: [Mesa3d-dev] Re: [Dri-devel] Mesa glBegin

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

Andrew Richardson wrote:
> 
> On Sunday 25 February 2001 12:40, you wrote:
> > Andrew Richardson wrote:
> > > Cal anyone tell me what glBegin /glEnd actually is in Mesa? I thought
> > > everything went to _mesa_Begin...sort of thing, but not so :( It MUST be
> > > in there somewhere, surely :)
> >
> > Let's move this discussion to mesa3d-dev...
> >
> > What version are you talking about?
> 
> 3.5
> 
> I need to override the functions _mesa_<gl base name> and the like.
> I don't think that I can just faf about with glapitemp.h etc as is there not
> something special about the ABI, and I don't want to bugger that up.
> Is there anyway I can call _mesa_<function_name> from inside mesa.
> I know I can do it for a lot of functions, _tnl_<function name> and
> _mesa_<function_name> cover almost all of the api. BUT I can find things like
> Index (color index function). Can you advise?

glIndexi() ends up calling _tnl_Indexi() in src/tnl/t_imm_api.c.
Other versions of glIndex*() call glIndexi().

Are there other ones you're confused by?

-Brian

Re: [Mesa3d-dev] Bug in subtexture_error_check()

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

Brian Paul wrote:
> 
> Are you sure you have the most recent code?  I fixed this problem a
> while back.
> 
> The current code in 3.5 is:
> 
>    destTex = _mesa_select_tex_image(ctx, texUnit, target, level);
> 
>    if (!destTex) {
>       gl_error(ctx, GL_INVALID_OPERATION, "glTexSubImage2D");
>       return GL_TRUE;
>    }

My mistake.  The current 3.4.1-based DRI trunk code has this:

   destTex = texUnit->CurrentD[dimensions]->Image[level];

I obviously need to merge the 3.4.1 updates into my branch.  Sorry for
the false alarm.

-- Gareth

Re: [Mesa3d-dev] Bug in subtexture_error_check()

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

Gareth Hughes wrote:
> 
> I'm running through the new Radeon texture state code and came across
> this.  I've implemented full 1D and 2D texture image support (3D support
> needs a bit more testing), and came across this:
> 
>    destTex = texUnit->CurrentD[2]->Image[level];
>    if (!destTex) {
>       gl_error(ctx, GL_INVALID_OPERATION, "glTexSubImage2D");
>       return GL_TRUE;
>    }
> 
> This seems to suggest that subtexture_error_check() will always fail if
> the target is not GL_TEXTURE_2D.  Perhaps I'm the only one silly enough
> to be looking at 1D and 3D subimage updates...
> 
> I'm changing the above to this:
> 
>    destTex = texUnit->Current->Image[level];
> 
> Are there any obvious hidden nasties in doing so?

Are you sure you have the most recent code?  I fixed this problem a
while back.

The current code in 3.5 is:

   destTex = _mesa_select_tex_image(ctx, texUnit, target, level);

   if (!destTex) {
      gl_error(ctx, GL_INVALID_OPERATION, "glTexSubImage2D");
      return GL_TRUE;
   }


-Brian

[Mesa3d-dev] Bug in subtexture_error_check()

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

I'm running through the new Radeon texture state code and came across
this.  I've implemented full 1D and 2D texture image support (3D support
needs a bit more testing), and came across this:

   destTex = texUnit->CurrentD[2]->Image[level];
   if (!destTex) {
      gl_error(ctx, GL_INVALID_OPERATION, "glTexSubImage2D");
      return GL_TRUE;
   }

This seems to suggest that subtexture_error_check() will always fail if
the target is not GL_TEXTURE_2D.  Perhaps I'm the only one silly enough
to be looking at 1D and 3D subimage updates...

I'm changing the above to this:

   destTex = texUnit->Current->Image[level];

Are there any obvious hidden nasties in doing so?

-- Gareth

[Mesa3d-dev] Mesa Init

[Andrew R. <and...@uc...>]

Is there a main function in Mesa that is only called once per library load?
I could use a once per context, so that would do...

	Thanks in advance
		Andy
-- 

                      \\\|///
                    \\  - -  //
                     (  @ @  )
+---------------o00o----(_)----o00o-------------------------------------+
|Andy Richardson                          Dept. of Chemistry            |
|t(w): +44-20-7679 (4718)                 University college London     |
|f(w): +44-20-7679 (4560)                 Gordon street                 |
|e: and...@uc...           London WC1E 6BT         UK    |
+------------------------------0ooo-------------------------------------+
                   ooo0        (   )
                  (   )         ) /
                   \ (         (_/
                    \_)   

[Mesa3d-dev] Mesa and it's inner functions

[Andrew R. <and...@uc...>]

Dear All,
  Ive just come over from the DRI devel list. I've been looking at providing 
an SMP dispatch layer to Mesa to provide a means by which even if a client is 
not multithreaded  you can still get the whole process running ~2 as fast. I 
have'nt got the concentration to enumerate exactly how it works as ive been 
up ~all~ night coding. :)
  Anyway I need some way to hook a set of dummy functions into mesa so that 
the client thinks the real openGL routine has been called without breaking 
the ABI (that I assume exists in Mesa). I can quite happily using the 
_mesa_<function-name> and _tnl_<function-name> but they don't cover the whole 
API. I need to know where the other functions are. 
  If anyone has a better idea of how to hook a set of routines info mesa 
without breaking the ABI I would like to know. I know that you have some sort 
of override layer thing. How does that work? Does it alow me to get my 
routines called without knackering the ABI, but does mesa then call the 
original layer or is that my responibility? If anyone can tell me I would be 
greatful.

	Thanks
		Andy


-- 

                      \\\|///
                    \\  - -  //
                     (  @ @  )
+---------------o00o----(_)----o00o-------------------------------------+
|Andy Richardson                          Dept. of Chemistry            |
|t(w): +44-20-7679 (4718)                 University college London     |
|f(w): +44-20-7679 (4560)                 Gordon street                 |
|e: and...@uc...           London WC1E 6BT         UK    |
+------------------------------0ooo-------------------------------------+
                   ooo0        (   )
                  (   )         ) /
                   \ (         (_/
                    \_)   

[Mesa3d-dev] Re: [Dri-devel] Mesa glBegin

[Andrew R. <and...@uc...>]

On Sunday 25 February 2001 12:40, you wrote:
> Andrew Richardson wrote:
> > Cal anyone tell me what glBegin /glEnd actually is in Mesa? I thought
> > everything went to _mesa_Begin...sort of thing, but not so :( It MUST be
> > in there somewhere, surely :)
>
> Let's move this discussion to mesa3d-dev...
>
> What version are you talking about?

3.5

I need to override the functions _mesa_<gl base name> and the like.
I don't think that I can just faf about with glapitemp.h etc as is there not 
something special about the ABI, and I don't want to bugger that up.
Is there anyway I can call _mesa_<function_name> from inside mesa. 
I know I can do it for a lot of functions, _tnl_<function name> and  
_mesa_<function_name> cover almost all of the api. BUT I can find things like 
Index (color index function). Can you advise?

	Thanks
		Andy


-- 

                      \\\|///
                    \\  - -  //
                     (  @ @  )
+---------------o00o----(_)----o00o-------------------------------------+
|Andy Richardson                          Dept. of Chemistry            |
|t(w): +44-20-7679 (4718)                 University college London     |
|f(w): +44-20-7679 (4560)                 Gordon street                 |
|e: and...@uc...           London WC1E 6BT         UK    |
+------------------------------0ooo-------------------------------------+
                   ooo0        (   )
                  (   )         ) /
                   \ (         (_/
                    \_)   

Re: [Mesa3d-dev] What is your develop environment for Mesa on Unix?

[Keith W. <ke...@va...>]

Yuan-chung Lee wrote:
> 
> Hello:
> 
>     I am researching the 3D graphics algorithm, and I need to modify the Mesa
> source codes to do some tests. My previous develop environment on Solaris OS
> is: VIM + command-line compilation + DDD.
> 
>     I will try to use KDevelop. Does anyone have the KDevelop Project file
> for Mesa-3.4.1 ?

Gak.

>     Is there any other better IDE(Integrated Development Enviroment) for
> development of Mesa on Solaris?

emacs + M-x compile + M-x gdb.

Keith

[Mesa3d-dev] What is your develop environment for Mesa on Unix?

[Yuan-chung L. <yz...@cc...>]

Hello:

    I am researching the 3D graphics algorithm, and I need to modify the Mesa
source codes to do some tests. My previous develop environment on Solaris OS
is: VIM + command-line compilation + DDD.

    I will try to use KDevelop. Does anyone have the KDevelop Project file
for Mesa-3.4.1 ?

    Is there any other better IDE(Integrated Development Enviroment) for 
development of Mesa on Solaris?

Re: [Mesa3d-dev] tnl module swapping

[Keith W. <ke...@va...>]

Keith Whitwell wrote:
> 
> Gareth Hughes wrote:
> >
> > I've been working on this a bit lately, and the biggest stumbling block
> > at the moment is my lack of intimate knowledge of the X11 driver.  I
> > will change this at some point perhaps, but in an effort to get this
> > done I'll probably move my work over to a hardware driver.
> >
> > As it stands, there seem to be some inconsistencies between the latest
> > 3.5 sources and the mesa-3-5-branch of DRI CVS (notably
> > swrast/s_quads.[ch] and tnl/t_vb_materials.[ch] have gone).  It looks
> > like the i810 still needs t_vb_materials.c, as it uses
> > _tnl_update_material_stage.  Keith?
> 
> I've found the vb_materials changes in radeon_context.c and i810_context.c,
> but I'm pretty sure the Imakefile changes have been committed.

The OSmesa makefile still uses ../swrast/?*.o to reference objects; you may
need to remove those .o files to proceed.

Keith

Re: [Mesa3d-dev] tnl module swapping

[Keith W. <ke...@va...>]

Gareth Hughes wrote:
> 
> I've been working on this a bit lately, and the biggest stumbling block
> at the moment is my lack of intimate knowledge of the X11 driver.  I
> will change this at some point perhaps, but in an effort to get this
> done I'll probably move my work over to a hardware driver.
> 
> As it stands, there seem to be some inconsistencies between the latest
> 3.5 sources and the mesa-3-5-branch of DRI CVS (notably
> swrast/s_quads.[ch] and tnl/t_vb_materials.[ch] have gone).  It looks
> like the i810 still needs t_vb_materials.c, as it uses
> _tnl_update_material_stage.  Keith?

I've found the vb_materials changes in radeon_context.c and i810_context.c,
but I'm pretty sure the Imakefile changes have been committed.

Keith

Re: [Mesa3d-dev] tnl module swapping

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

I've been working on this a bit lately, and the biggest stumbling block
at the moment is my lack of intimate knowledge of the X11 driver.  I
will change this at some point perhaps, but in an effort to get this
done I'll probably move my work over to a hardware driver.

As it stands, there seem to be some inconsistencies between the latest
3.5 sources and the mesa-3-5-branch of DRI CVS (notably
swrast/s_quads.[ch] and tnl/t_vb_materials.[ch] have gone).  It looks
like the i810 still needs t_vb_materials.c, as it uses
_tnl_update_material_stage.  Keith?

-- Gareth

Re: [Mesa3d-dev] shadow extensions

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

On Tue, Feb 20, 2001 at 10:22:28AM -0700, Brian Paul wrote:
| I want to experiment with shadow map sampling.  Linear filtering
| won't necessarily give better results than nearest filtering.
| Consider the discontinuities along object profiles.  I might try
| taking 4 depth samples, perform 4 R comparisons then use the
| results of those 4 tests to determine if the fragment is shadowed
| or not.  I'm also curious how mipmapping will work out.

If I remember correctly, SGIX_shadow is written so that the depth
comparisons happen before the mipmap filtering.  So in theory you get
a shadow value ranging from 0.0 to 1.0, rather than a hard-edged
0.0-or-1.0, and you avoid misclassifying geometry near edges.

It's still possible to get artifacts from depth-value quantization and
undersampling, of course.

Allen

Re: [Mesa3d-dev] shadow extensions

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

On Wed, 21 Feb 2001, Gareth Hughes wrote:

> Brian Paul wrote:
> > 
> > While working on the texture image code I had to fix some
> > things related to color index (paletted) texture images.  That
> > got me thinking about other texture formats like depth textures.
> > So, I implemented the GL_SGIX_depth_texture extension and then
> > GL_SGIX_shadow to exercise it.  GL_SGIX_shadow_ambient was a
> > simple addition on top of that.
> > 
> > ...
> >
> > My implementation isn't 100% complete either.  Right now, the
> > depth texture is only sampled with nearest/nearest filtering
> > and the texels are always stored as floats.  I'll try to fix
> > those things in the not-too distant future.
> 
> Great work!  I remember talking about this with you at SIGGRAPH last
> year -- I'm really interested in checking this out.
 
It's not a universal panacea though.

The most serious problem is that the resolution with which the polygon
is rendered from the perspective of the light source generally
differs radically from the resolution it'll appear to be from
the perspective of the viewer.  Hence, you can get shadows
plastered inappropriately on the wrong surfaces - or the shadows
may have VERY pixellated or have severe aliasing artifacts.

But - having said that - in the right situations it works
amazingly well. It's a clever hack.  You just have to know when
you can and can't use it.

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