The impression I got from earlier postings is that, the lack of VGA
support in NetBSD/Alpha is partly due to the fact that certain very
talented developers would rather not spend their time implementing code
which they aren't proud of and know will eventually have to be removed.  
That's what a Kludge is, in our world at least--code you don't like, that
you know you're going to have to back out some day.

A lot of people's opinions together have made convincing the argument that
the kludge is worth doing.  If NetBSD were a commercial product, that
would be good enough.  But, it's not.  If developers aren't interested in
writing the code, it doesn't get written.  Kludgy code is less fun to
write.  I think this factor is at least, if not _more_ important, than
some sort of philosophical resistance to The Kludge, or to crappy PeeCee
hardware limitations and XFree86's (historically) Wintel-centric software
architecting. At this point, the philosophical barrier is overcome--the
only barrier that remains to your getting the code you want is what I'm
discussing here:  limited interest on the part of developers with limited 
time.

NetBSD is a big project with lots of interesting directions.  Some very
interesting work is going on now--the unified buffer cache, MP support,
IPv6, Coda, faster SCSI drivers, and a package/binary emulation subsystem
that's developing at a phenomenal rate.  NetBSD is not ``lagging'' because
it doesn't support cheap fast PeeCee video cards on the Alpha.  NetBSD
developers simply find other projects more interesting.

And, it also needs pointing out that NetBSD developers haven't
categorically condemned the interestingness of fast-cheap-PeeCee video
cards.  They've simply said (in the past) something like, ``we're not
interested in twisting the Alpha to look like a PeeCee for the sake of a
few X servers.'' Remember, NetBSD supports Power Macintoshes, StrongARM's,
the Atari Hades, and eventually newer UltraSPARC's--all of which have PCI.  
The past position has been:  getting XFree86 servers to drive PeeCee video
cards on _all_ these platforms is interesting.  Hacking them into just the
Alpha platform, is not.

Indeed, I think you'll find Linux/PPC does not have accelerated support
for the PeeCee-ish video chips in modern Macintoshes.  It supports them
only as raw framebuffers, and only thanks to the OpenFirmware ROM's that
come with the Mac versions of video cards.  correct me if i'm wrong.  This
is a consequence of their choosing not to solve the XFree86-on-non'86
problem the way we wanted to.

On Sat, 16 Oct 1999, Berndt Josef Wulf wrote:

> I fail to see why NetBSD-alpha takes a special status when compared with 
> Linux, FreeBSD or Digital Unix,

perhaps because the other two operating systems don't even see it as a
kludge, because they don't have bus_space.  they don't have bus_space
because they used to run only on PeeCee's, and only decided to port to the
Alpha in the first place because the Alpha runs Windows NT and thus is
designed to be an easy port for Wintel-like operating systems.  they
implemented The Kludge when they first ported their PeeCee-centric
operating system to the Alpha, so it wasn't ``extra work'' or a
``decision'' for them.  it's, in that sense, a matter of perspective.
NetBSD:

  o is ported to many platforms and many odd bus architectures (Digital
    TurboLaser, the sbus expansion boxes, VME), and has a demand for
    bus_space

  o invented and created bus_space, and therefore believes in its value

Keep in mind, NetBSD had better TGA support sooner than either of the
other OS's, and NetBSD runs on large Alpha's that Linux and FreeBSD do not
support.

Thus, one might say the PeeCee kludge was held off in hopes the XFree86
folk could be persuaded to adopt a solution that (1) avoided forcing
NetBSD into a kludg (2) benefited all the platforms XFree86 runs on, and
(3) improved XFree86's portability to non-i386 architectures, a
historically sore point with the XF86 code and probably one of the XFree86
team's long-term goals.

This strategy shows some promises of success.  The likelihood of Xfree86
eventually adopting something like bus_space, given the way they seem to
be moving, is in my opinion all but certain since they are interested in
multiple card support and portability to other PCI platforms. It's just
that XFree86 hasn't made a major (non-bugfix) release in, what, four or
five years if not more, right?  Corect me if i'm wrong, but i think
there's a NetBSD-ish I/O architecture as one of the key new features in
XFree86 4.0, which will probably come out in about one more year.  Why
does this architecture exist in XFree86?  Partly, I hope, because one
particular NetBSD developer bothered to point out that it might be useful.

I'm not disagreeing with Ross's decision that the PeeCee I/O kludge is
acceptable for and worth integrating.  Rather, I'm saying that the
original decision to put it off was very well-considered, is easy to
defend, and does not reflect anything shabby about NetBSD's Alpha support.  

I believe NetBSD has always done (and still does) the most work to bring
out what's truly good in the Alpha architecture.  A lot of important home
users who can only afford one inexpensive machine want to put a PeeCee
display head on it--that's good, but I think we should give due credit to
all the great work NetBSD developers have been doing for the Alpha in the
free time they could have spent implementing this PeeCee kludge for the
benefit of old (release) versions of XFree86.  

NetBSD/Alpha was the best thing that happened to my box since i bought it.  
To be perfectly honest, none of the three different PeeCee video cards i
tried worked in my Alpha back when I ran Linux, so I wasn't losing much.
Actually i should be fair--the S3 card workred for about a week I think,
and then mysteriously quit. But, assuming I was somehow under the
impression that VGA support in FreeBSD and Linux actually worked, I would
rather find a different box to serve X than use something besides NetBSD
that doesn't support the Alpha architecture as well.

-- 
Miles Nordin / v:1-888-857-2723 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US