Subject: Re: XFree 4.x
To: firstname.lastname@example.org, Mario Kemper <email@example.com>
From: Richard Rauch <firstname.lastname@example.org>
Date: 08/17/2000 02:20:15
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
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." --email@example.com