> > What I did, and what appears to work, is to install XFree86 v4.0 (or
> > later, one presumes), and then build (but not install)
> > Mesa-glx. 
> 
> Ok, what I have going now is a pre-xpkgwedge Mesa (not -glx)
> installed, such that /usr/X11R6/lib contains:

I suppose sticking the OpenGL stuff into the X includes/libs directories
would save me trouble in the long run.  (As would convincing the package
system that I have Mesa installed, even though I'm not really using Mesa
for everything; (^&.)

I guess I could have used regular Mesa as well as Mesa-glx---it's only
libGL that really knows whether to talk to the GLX extension or to use
faked internal code.  As long as you use the XFree86 libGL, it should all
be okay.  Yes?


> lrwxr-xr-x   1 root  wheel       12 Aug 12 00:05 libGL.so -> libGL.so.1.2
> lrwxr-xr-x   1 root  wheel       12 Aug 12 00:05 libGL.so.1 -> libGL.so.1.2
> -rwxr-xr-x   1 root  wheel   364272 Aug 12 00:05 libGL.so.1.2
> 
> Note where libGL.so.1 points.

(nod)  When I put in XFree86 4.0, I had no such symbolic links, and could
not even start the X server.


> I imagine that if I were xpkgwedge-less, I could install a
> new Mesa or Mesa-glx and then reinstall XFree86's libGL
> shared objects and includes, and new programs would DTRT.
> 
> Alternatively, Mesa/Mesa-glx could be made aware of
> XFree86's more recent libGL stuff, and leave it alone.
> 
> I get lost thinking about how this would work with
> xpkgwedge installed. -:)   Is that why you had to tweak
> library & include locations?  It "just worked" for me.

No.  I haven't really looked at xpkgwedge.

My thinking was: I am not installing this as a package, so I'd rather not
confuse the package system.  It's not really part of X, so it shouldn't go
into the X directories (well, libGL and the GLX stuff should---but those
are put there by XFree86 already).

So, I put the includes and libraries under /usr/local/* directories.  And
pkgsrc doesn't look there by default.  Further, as far as pkgsrc is
concerned, Mesa is not installed on my system.  Thus, any package trying
to use Mesa{,-glx} has to be tweaked:

  * It should not try to install Mesa (this could trash the XFree86
    stuff).

  * It should pick up the non-standard includes & libs directories.

In a sense, I still prefer my approach, but in practice it is probably not
going to work out very sanely.  (Sooner or later I'll build something that
will install Mesa, overwriting XFree86's libGL.)  On the other hand,
sooner or later, NetBSD will presumably move to the newer XFree86, and
this problem will probably have to be dealt with cleanly during a
transition period.  (Maybe another pkgsrc make variable?)


>   Battalion continues to display the improper shading when in
>   highest-quality mode.  (I first noticed this, I think, after doing a
>   massive package rebuild around May.)  Wireframe mode in Battalion is also
>   broken (about the same time-frame, too).
> 
> Yes, I observe this too.  The wireframe mode is not
> "broken" for me -- it behaves as the highest-quality mode
> should behave if it were working (i.e., the wireframes are
> shaded in.  I think the server is doing the filling in,

Really?  I'd still call that broken.  It's supposed to render wire-frame
as wire-frame.

What I actually see in wire-frame mode is: The solid object surfaces are
drawn as polygons (no fog, unshaded, no texture maps).  This is almost the
same as the second-lowest-quality mode, save that if you pay attention,
you will see that depth-checking is disabled. (From behind your monster,
you can see the eyes on the front of its head, for example.)

(For one frame, it does render it as wire-frame.  Something kicks it back
out of wire-frame mode (at the OpenGL API level), and it doesn't recover,
I think.)

I saw this same effect with Mesa (no -glx) and with Mesa-glx earlier this
year.  It also, as I noted, causes shading errors in highest quality mode.
(For some reason, polygon vertices seem to pick up colors from other
elements.)  A year ago, it did not do these things.  Since that time, I've
upgraded Mesa and Battalion, and don't know which one is responsible.  The
fact that nothing else seems to suffer this way suggests that the bug is
in Battalion.


  "I probably don't know what I'm talking about." --rauch@eecs.ukans.edu