This is a crude attempt to run NetBSD's in-kernel terminal emulation code in
userland. It will do most drawing operations in regular, cached RAM and only
update the framebuffer as needed, while pulling a few dirty tricks to make 
things go faster.
In order to run it you need:
- NetBSD kernel sources, mostly for kernel headers and fonts
- a console driver that supports dumb framebuffer mode in 8bit or 32bit colour
... and that's it. So far it will:
- open a bunch of 80x25 terminals, the number of which is determined by your
  display resolution and font size, the font can be configured in init.c
- the terminals support ANSI colour, bold, and underline attributes, but only
  bitmap fonts
- use a hardware sprite as mouse cursor if supported
- draw window decorations, so far they only indicate which window has the input
  focus

Mouse events are read from /dev/wsmouse, keyboard events from individual 
/dev/wskbd*, the reason to do this - we need raw event data, key up and down,
modifiers etc., and there is no guarantee that all devices on the same keyboard
mux use the same set of scancodes. For example, PowerBooks may have a builtin
ADB keyboard and a USB numberpad or bluetooth devices.
The downside of doing it this way is that devices may or may not re-join their
mux after closing, which may lead to a non-responsive console.
Also, keyboard and mux devices are owned by root, in order to be usable you
need to be able to open them for reading. The display device will be owned by
the user logged in on it, so that will just work.
So, with the right permissions on /dev/wsmouse and /dev/wskbd* this should work
without privileges.

The dirty tricks mentioned above involve:
- treat the framebuffer as strictly write only - fb reads are expensive and
  break write buffering where supported.
- use a shadow fb so we don't get speed penalties for less-than-32bit writes
  since everything goes into cache first
- use optimized framebuffer upload routines:
  * VISMoveImage*() on sparc64
  * only 32bit accesses everywhere else ( should probably add a 64bit variant )
  * shadowfb scanlines are 64bit aligned
- the terminal uses a 2KB read buffer ( so, about a screen's worth ) which is
  fed to the terminal emulator to run strictly on a text/attribute buffer, then
  we redraw the character cells that actually changed ( and the cursor ). This
  gives us jump scrolling essentially for free.