At Mon, 5 Mar 2007 21:31:50 -0500,
Michael Lorenz wrote:
> 
> Not with XFree86 unless you write a wsdisplay driver for the leo. Even  
> then it will probably need some minor hacking ( for some reason the  
> framebuffer device IDs get translated somewhere in the SBus/fb support  
> layer, it might miss an entry for the LEO on NetBSD )

So, XFree86 _requires_ wscons even on ports which don't fully support
wscons, and yet you're recommending XFree86 the the best Xserver on
those ports?  That's not right.

(There's that SBus/fb support weirdness creeping into mention again --
The Xserver shouldn't know what kind of a bus the framebuffer driver is
using to access the hardware -- that should all be hidden by the kernel
driver.)


> > but at the moment it looks like the XFree86 binary I finally see being  
> > built is useless when linked statically as the right things aren't set  
> > up to be referenced and linked into it.
> 
> I have no idea what you're talking about.

My claim comes from the fact that the XFree86 binary is obviously
smaller than the old XsunMono, and way smaller than the current XsunMono
binary, so it clearly doesn't contain all the code it should.  Something
in the build failed to take into effect the fact that it would be static
linked and thus all the necessary symbol references were not made to
ensure all the desired modules were loaded in at link time as they
should have been.

> Well, it will load display drivers, extensions etc. on startup.

Not when it's static linked, it won't.  :-) If it still tries then I'll
make damn sure my kernel does whatever is necessary to prevent it from
modifying its text memory.  That's just wrong.

I think I'd just as rather stay very well away from some dynamic-only
monstrosity using a moniker that is more of a contradiction than
anything else, at least on sparc, since it apparently won't provide any
benefit any more anyway (i.e. now that it seems Xsun* will include all
the good extensions that may be of benefit to more modern applications).

I'd much rather just try to fix the regressions in the Xsun* Xserver
code so that it works at least as good as it did before the Xfree86 PC
folks got their mittens into it.  I hate to sound like I'm spiting
something just for its heritage, but I think in this case the obvious
regressions in even very simple and common functionality show quite
clearly that there hasn't been near enough care and effort put into
actually _maintaining_ the portability of the code they started mucking
with in the first place.

-- 
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>