Subject: Re: Any news on X-servers with pcivga support?
To: Berndt Josef Wulf <wulf@ping.net.au>
From: Chris G Demetriou <Chris_G_Demetriou@ux2.sp.cs.cmu.edu>
List: port-alpha
Date: 11/30/1996 14:11:49
[ sorry for the delay... this last thursday was one of the more major
  US holidays, and things have been hectic all around... ]

> the title says it all. I had a good look around but can't detect any
> advances on this subject. Has it been canned?

In a nutshell: there was a volunteer who indicated that he wanted to
work on it, and he hasn't produced anything (at least, that i'm
aware).

As previously noted, I don't really have much time to be working on
NetBSD/alpha at all (i spend much more time on it than i should), let
alone PCI VGA X server support.  I've been trying to get some bogons
out of the way (e.g. the fact that ISA VGA didn't previously work),
and now i'm going to see about some sane interface by which the
drivers can describe to user-land processes what they're letting the
user-land processes map.

Apparently the XFree86 situation has improved somewhat, or at least
the Alpha Linux XFree people are being more chattery about making sure
things work right (under Linux) on the Alpha.  That indicates that
it'd only take a finite amount of work to make it go with
NetBSD/alpha, but i don't know how much work that'd be and don't have
much time to find out.


> Whilest on the subject... scrolling text still is jerky. Which files
> contain the code responsible for it? The screen jumps by about 9 lines
> instead of scrolling line by line once it reaches the end of the
> screen. This is independent from selected terminal type and shell.

Actually, it's 10 lines, and the source code responsible is the
arch/alpha/wscons/wscons_emul.c, lines 122 - 133.  8-)

It's actually intentional, and I put it in because it's bloody slow to
scroll the TGA line by line.  On a 24-line VGA, though i could see how
it would be annoying.  Any suggestions for a 'not ugly' way to fix it?
I guess i could make the number of lines to scroll a kernel option,
though i'm loathe to do it...

FYI: The emulation code is also (at least) a little bit buggy, and
doesn't even do a very good job of emulating the (simple!!) sun
terminal that it claims to emulate.


Sort of a wscons emulation wishlist, if anybody's bored:

I'd really prefer it emulated a more 'buff' terminal type, e.g. ansi
or vt???, but 'sun' was the only thing i could easily get the specs on
at the time i cobbled the code together.  (the ANSI terminal spec was
out of print, and i have only a quick reference sheet for a vt220...
no real docs on anything, other than the SunOS manual pages that
desribe their terminal emulation. 8-)

It should be possible to have multiple emulations compiled into the
kernel, with a way (e.g. user-land program) to switch between them.
People wishing to save memory could use a dumb terminal (i.e. no real
emulation), others could have 'ansi' or vt220, or whatever.  This
would also make the code more palatable to other ports.  (i'd
eventually like to see it used by other ports, but it's in need of a
bunch of work yet...)

Accelerated raster functions for the TGA would be something cool to
experiment with.  It should be relatively easy to implement the
operations that wscons uses often, especially the typically-costly
ones (e.g. block copy and clear).

And then, of course, seriously cleaning up the whole chunk of code.
If anybody wants to work on _this_, get in touch...  8-)


chris