I have some general comments on this topic.  Now seems as good a time as
any to trot them out.  (^&  (Does the NetBSD project have anyone actively
tracking XFree86 as part of their contribution?  Does the project have any
kind of standing point-of-contact with the XFree86 project?)

 * As noted, there are conflicts with our packages, re. both Mesa
   and Xpm.  (I found my libXpm from XFree86 suddenly missing; it
   appears to have been the victim of pkgsrc.)  Mesa is actually
   a slightly more complicated problem, since Mesa includes
   libGLU and libglut, both of which are absent from XFree86 4.0.
   I'm surprised that XFree86 4.0 doesn't include them, and hope
   that this changes.

 * If we get a TrueType-capable font interface in pkgsrc, this
   will be another point of conflict (XFree86 4.0 includes _two_).

 * Mesa-glx may be ahead of XFree86 for hardware-accelerated
   OpenGL support.  I can't tell what boards are really supported;
   XFree86 claims that S3 ViGE chipsets are fully accelerated, yet
   rendering looks (TO ME) to be about the same speed as pure software
   under Mesa & XFree86 3.3.6.  So, 3D acceleration _may_ not be
   included when they speak of ``fully accelerated'' support.
   (I do gather that the S3 chipsets are supported in Mesa-glx,
   though not in the version we have packaged.)

   (Then again, to be fair, I recently got a new PC and stuck the old
   S3 ViRGE board in it, since fast graphics isn't really of paramount
   importance right now.  I'll get a nice AGP board in another year,
   I figure.  (^&  It's possible that the new AMD CPU is so fast that
   I just don't notice the difference when the old/``slow'' graphics
   board is doing some 3D support---but, I tend to doubt that.)

   Presumably, any lead that Mesa-glx has will wane before long...

 * Mesa-glx (last I tried it) and XFree86's OpenGL API implementation
   both seem to suffer from having a single thread in a single
   process.  Anything that preoccupies (or locks up) the Mesa code
   will have negative effects on the rest of the X server.

   (I actually have a snippet of code that, with the ``right''
   data, will crash Mesa under XF86 3.3.6, and will cause the
   XF86 4.0 server to lock up.  Unfortunately, the data set that
   I'm using is not something that I can publish, and so far I
   haven't narrowed it down to a definite bit of bad data.  Although,
   my suspicion is that it has to do with running a line straight
   through the OpenGL ``eye''.)

 * XFree86 4.0 failed to detect my wsmouse, which was only mildly
   disappointing.  In general, though, ``XFree86 -configure'' looks
   good to me.  (For those that may not know, this causes XFree86
   to attempt to autoconfigure itself.)  It is much nicer than the quasi-
   manual configuration that I had to go through with 3.3.x.

 * According to the release notes (I think), some things planned
   for 4.0 didn't quite make it into 4.0.

 * As 4.0's docs (RELNOTES) state themselves:

     Oh, another thing you might notice is that our documentation is
     rather patchy.  Most of what is present should be in reasonable
     shape, but there are gaps.  We thought it better to leave out docs
     that were very out of date rather than providing inaccurate and
     misleading information.

   Elsewhere, in the same document:

     The module interfaces (API and ABI) used in this release is still
     subject to change without notice. [...] We are planning to fully
     document and stabilise the module interfaces in a future release, and
     at that point backward compatibility will be easier to achieve.

   I.e.: There's still quite a bit to settle down for a nice, solid,
   stable XFree86 4.x.


Bringing NetBSD up to XFree86 4.x, I think, might best be done by putting
it in a package for now.  This way, it would be ``officially available''
for those who want it, but not forced on everyone prematurely.  
(Eventually, of course, I would hope to see it in the base distribution.)  
In the meantime, issues with pkgsrc could be fixed.  And, it will give
XFree86 4.x a chance to better stabilize (documents, etc.) before NetB SD
actually depends upon it.

Well, someone started this thread with an open-sounding request for
opinions.  Make what you will of the above. (^&


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