>> I have heard things that imply that NetBSD xsrc has gone XFree86
>> even on ports like sparc where this doesn't really make any sense;
> netbsd xsrc has _always_ been based on code from the XFree86 team.
> netbsd/sparc has always used the "Xsun" family of servers.

Are you contrasting Xsun with XFree86 code, or referring to a
particular subset of the XFree86 stuff, or what?  This is rather
unclear to me.

> as i understand, the "XFree86" X server code has modules for all the
> sun graphics cards that includes better acceleration for many of them
> than the old "Xsun" family does.

For sufficiently old values of "old", this may be true - though eeh's
remarks about the cgsix reinforce my suspicion that it's actually
something of an urban legend: often repeated but seldom checked against
fact.  In the one case where I have looked at XFree86 code for sparcs
(the cg14, I think it was), the XFree86 code had no acceleration
whatever and was significantly dumber than my hacked-together server.

I also see no excuse whatsoever for a software architecture that
insists on performing for itself a number of tasks that really belong
in the kernel and in fact I'm astonished that a user program _can_ do.
(Bus enumeration in an _X server_?  Furrfu.)

> this implies that if we can make XFree86 work with these, we'll have
> a faster result... so it may be desirable to do this.

Again you seem to be contrasting the SPARC X servers with XFree86.  Now
I'm confused - have SPARC X servers not been built from xsrc, or what?

I'd also suggest that if there _are_ any cases where XFree86 Sun
framebuffer code is in fact better accelerated than Xsun code, the
better result would be obtained by adding the acceleration to the Xsun
code, rather than trying to twist and bend both the XFree86 model and
the Sun model until they can be bolted together.  (And as someone who
has relatively recently created X servers for two framebuffers
previously supported poorly to not at all - the s24 and the cg14 - I
feel that (for a change!) I'm not just playing armchair quarterback in
saying this.)

Of course, NetBSD may decide that having a single model across all
ports is worth inflicting kludgery created to address the i386's
problems on all other ports.  As you can probably tell from my choice of
language, though, I believe that would be a mistake.  (Some of them
have reason to need some of it in some cases, such as NoName alphas,
but even in those cases the problems are rarely port-wide; to continue
the alpha example, there are the turbochannel machines.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B