On Tue, Jul 23, 2002 at 08:46:57PM -0400, Brian A. Seklecki wrote:
> Does anyone know why the XFree86 4.2.0 xc/RELNOTE marks all the sun-related
> drivers as Sparc-Linux only.  Is there some linux-dependant code in them, or
> are we simply not important enough >:} ?

Well, that's a matter of some history.

I'll tell what I know and others can dispute and correct as they see fit.

In the ancient past, there was one true X distribution, from MIT.
It installed on many, many different architectures, with many, many
different types of display hardware.  Typically, each different
display/OS combination had a different Xserver named for it.
For example, there was "Xsun" for the Sun mono and 8bit framebuffers,
and "Xsun24" for the hackish support for Sun 24 bit displays.  There
was Xqdss for the VaxStations, and so forth.

Enter the PC, with a huge variety of graphics adaptors to put all
the unix hardware vendors to shame.  So, the original X386 driver
begat Xthis and Xthat, typically each supporting a single vendor's
display adaptor/board.  This, clearly was insanity.  The XFree86
group, having broken with the X Consortium (and rightfully so)
after a licensing issue, came up with a saner way of doing things.

This idea marks the delination between the XFree86 3.x and 4.x
series of releases.  3.x is similar to the old MIT X -- a different
X server for each board.  (Yes, there were exceptions, which I'm
sure some pedant who doesn't read this far will point out in a
followup posting.)

The Xfree 4.X series of releases featured an entirely new internal
software architecture, along with a cross-OS binary loader for
modules.  The new architecture has some nice optizations done in
a generic way, using hook functions for calling into various boards,
or failing back to a less optimal way of doing things using a
generic stub routine.  Using this new scheme, a single server could
be made to use different board drivers as loadable modules.  Put
all the common code into one big framework, and then it loads the
board-specific stuff at run-time.  There is a downside to such
improvements, as one might expect: Every driver for every display
needs to be pulled kicking and screaming into alignment with the
new internal server architecture.

However, given the history of the XFree86 source tree, there are
still vestiage of the old one-Xserver-per-adaptor in the tree.  If
you are successful in building the Xsun from the XFree86 tree (which
should work -- I did that for BSD/OS on sparc4m machines two years
ago), it will be a XFree 3.x style server.  That is to say, the
old server architecture architecture, little changed from the X11R6
tree.  It will be called Xsun.

About two years ago, the Redhat guys wrote some new bus support
routines, which extended the Xfree86 4.x code in a direction that
was planned, but not yet implemented -- support of a bus other than
PCI.  Basically, they added a set of Sbus support routines for
scaning the sbus space and attaching displays for the Xserver.

In addition they donoted X server drivers for the following list
of cards that you found:

> ---
> |sunbw2 (+)    | Sun bw2
> |suncg14 (+)   | Sun cg14
> |suncg3 (+)    | Sun cg3
> |suncg6 (+)    | Sun GX and Turbo GX
> |sunffb (+)    | Sun Creator/3D, Elite 3D
> |sunleo (+)    | Sun Leo (ZX)
> |suntcx (+)    | Sun TCX
> Drivers marked with (+) are for Linux/Sparc only.

These implement the XFree86 4.x software architecture (generic
optimizations, completely loadable board/display drivers, etc),
but do it for the Sbus.  (I'm not sure if they can support
simulataneous Sbus and PCI adaptors.  You can get that kind
of mix and match displays on the Starfire boards [aka Sun 3x00,4x00
class machines] with the right set of midplane cards.)

So, it's not just a matter of #ifdef'ing a little code -- you 
need to write support for probing the sbus space for the XFree86
server, and then whack on the drivers a bit, probably.  There's
also a matter of impedence matching the device/ioctl support for
the frame buffers under Linux with your OS.  I don't believe that
the task is impossible -- quite the contrary, I believe it is only
a couple of weeks of solid work to make the Sbus stuff go, and then
you have XFree86 4.x support for your platform.[*]

I hope this long winded explanation helps.

-Kurt

[*] -- Note that the Sun GX/TurboGX (aka cg6) drivers do NOT support
the limited acceleration that the board supports in hardware, so
for this display card at least, a XFree 4.x server is almost certainly
noticably slower than the Xsun server.