Greg,

you're missing the point of the modern XFree86 architecture. The server guts
are platform neutral. The modular card drivers are mostly platform neutral.
The entire point of the modular architecture is to allow a vendor to write
one driver for all platforms, and to have that work on XFree86 4.0 -> 4.9
without change. So far, that's been the case, as the ABI has been relatively
static (so far, with a few minor exceptions). Theoretically, it's possible
for a well-written driver module to support all operating systems on that
processor, for example, NetBSD, FreeBSD or Linux without recompilation.

This allows the card manufacturers to target XFree86 as a platform, rather
than re-implement new drivers on each of the operating systems and platforms
that users wish to use. By coalescing their effort into one place, XFree86
makes it more likely that video card manufacturers will indeed help open
source efforts to have a driver for their users on non-traditional operating
systems at all.

And despite your best efforts to slag it off, XFree86 does have a clean,
modern architecture, with a well-defined API and (relatively) stable ABI. If
you want to write a new driver, you write approximately a dozen functions,
and then start work on the XAA functions to go accelerated. If you stick to
C and use the right macros when twiddling data, your driver will work on all
the platforms that XFree86 supports, including little endian and big endian
32 and 64 bit with a simple recompile.

The specifics of graphics initialization are so incredibly specific to a
particular card or card revision that there is no possible way you want this
stuff in your kernel. All you'd be doing is moving about 1/3rd of each of
the XFree86 driver modules and all the operating system glue to the kernel,
taking up valuable memory if the kernel is non-pageable. And considering how
rapidly some of the modules are being developed to take in new cards and
revisions, you'd be constantly updating your kernel.

Your system will do about 11,000 xstones on the local framebuffer. It
probably is faster than you need. When we started getting the Matrox
Millennium working, the first version of the driver that properly setup
graphics mode (Radek simply copied in the 1024x768 RAMDAC details from
Windows :-), we got 44,000 xstones with no acceleration. We were already the
second fastest card at that time, even so. By the time we were finished, the
Matrox Millennium I was capable of 735,000 xstones under the old
"workstation"-derived XC (3.3.x) architecture and 950,000 xstones under the
new 4.0 architecture on my dual PPro 200. This is why I always get a bit
PO'd with the "workstation" snobs. Consumer PC hardware is more than just
good - it kicks ass. No one uses banked frame buffers these days, EXCEPT for
installation routines. Let's move on.

When NT moved from user space GDI to kernel space GDI, NT graphic benchmarks
went up by an average of 25%, with some primitives being more than twice as
fast, simply because they run kernel side longer than others. I'd expect a
similar increase in speed if something like GGI and X were to run the same
benchmark, with GGI winning by an incredible margin because there's no
network interaction in the way of local display.

The other alternatives to X died on the vine because no one supported them.
GGI will always be non-mainstream. QT/embedded will almost certainly stay in
the embedded space. Photon is too closely tied to QNX. About the only thing
that might make more sense than X, is to support GDI+ and DirectDraw under
Unix. Most commercial software vendors are very familiar with GDI &
DirectDraw. But since all Unix apps would have to be recoded somewhat (
;-) ) to support it, as well as donning an abestos/kevlar body armour to
suggest it around most foaming Linux zealots, I doubt you'd get very far.

There is a generic VESA fb that does some of what you ask anyway. It works
as well as the VESA bios on your video cards.

Andrew