> > As a small data point, here are some numbers for a TurboChannel sfb
> > (which uses an earlier generation of the chip that the multia uses)
> > running on a DECstation 5000/260 (R4400).  With an XFree86/X11R6 X
> > server (which treats the sfb as a dumb framebuffer) I get around 20k
> > xstones.  With the DEC supplied X server, this jumps to over 120k
> > xstones.
> 
> Digital has supplied to the XFree86 folks the accelerated ddx layer for
> the TGA X server (primarily for Linux).  If anyone is really interested
> in a fast X server, I suggest you talk to them.

Uh:

	(1) as of the last public source release, i couldn't find
	    any TGA sources in the XF86 public distribution.

	(2) i'm on their beta list, and i've yet to see TGA support
	    listed among their patches.

	(3) with respect to how they're planning to do server support
	    for the Alpha in general, i've sent several pieces of
	    mail inquiring, and never received a response from anyone
	    other than users, who pretty much said "works great on
	    linux."  It was suggested at one point that there should
	    be an XFreeAXP server, which i agree with, given my desire
	    to support 'wacked out' frame buffers (i.e. various TC
	    stuf), that makes little sense in the 'normal' XFree86
	    tree, and also given my desire to support LK-series
	    keyboards on TC machines (which makes absolutely no sense
	    in the context of XFree86).  As far as I can tell, the
	    "strategy" is to hack XFree86 linux sources until they
	    work on the Alpha.  That doesn't make any sense for
	    NetBSD/Alpha, since the i386 and Alpha console code
	    is so different, and given my previously stated desires.

	(4) many of the hacks mentioned in (3) were, as of the last
	    time i looked at the source code (~3.1.2E) of the form
	    that they would not be portable to different machines in
	    the Alpha family that NetBSD/Alpha currently supports.
	    In particular, they were hard-coding address ranges
	    for PCI dense memory, and the values that they were using
	    worked on the 2106x, but would not work on the 21164.

In other words:

As of the last time I looked, XFree86 supports various PCI VGA boards
on the Alpha, but does not support TGA, and the means used to support
those VGA boards were both inadqeuate for the purposes of
NetBSD/Alpha, and ill-thought-out.

(If somebody from the XF86 group takes issue with this
characterization, uh, well, you can start your reply by responding to the
questions and points that i raised in my message to axp@Xfree86.org,
dated June 26, 1996, message ID <22528.835833388@ux2.sp.cs.cmu.edu>,
and resent, dated July 4, 1996, message ID
<17382.836455818@ux2.sp.cs.cmu.edu>.  Yes, i am a bit annoyed about
being blown off, especially since i went out of my way to provide
early copies of my hacked TGA server to XF86 people who wanted them.)


To those who have been asking about PCI VGA server support under
NetBSD/Alpha: no, there is currently nothing being done, and the
problems listed above, along with my lack of time, are largely the
reason.  Sorry to have taken so long to reply to your queries.


> This also means with little effort you can have a fast X server for SFB
> based systems (Flamingo/Sandpiper or DECstations 5000) since the TGA and
> SFB chipsets are very similar (mostly just different buses).  [Of course,
> this begs the question of why we TGA console but no SFB console under
> NetBSD/alpha.]

Because a console needs input.

There is currently no support in NetBSD/Alpha for LK-series keyboard
input, or for mouse input.  I've been hoping that a pmax person would
convert the z8530 driver to use the (relatively new)
machine-independent 8530 code, and produce something that works on
both that pmax and on the alpha.  Unfortunately, that's not happened
yet, but i can't harp on people for not having enough free time to
work on projects for me.  8-)

There currently _does_ exist a working SFB driver for NetBSD/Alpha...
However, because there's no LK keyboard support, console is
effectively output only.  "not bloody useful."  Once the keyboard
support is there, it wouldn't be hard to hook the keyboard/SFB up as
the "real" console, but until the keyboard works, i'd say that that
is counter-productive, if not dangerous.  (Actually, i'm not entirely
telling the truth -- the NetBSD/Alpha SFB driver works, but doesn't
include any real support for the RAMDACs found on the SFB.  but that
code already exists for the TGA, and could be copied, or, better,
shared.  Still, that's a SMOP, whereas making the keyboard driver go
is a fair bit harder, since the z8530 driver currently used by
NetBSD/Alpha should be taken out and burned.)



chris