Lennart,
	I recognize the i18n issues in keyboard scancodes are a pain; it
strikes me that this is an issue with the interface between our chosen
window system and the NetBSD kernel. Either we get completely out of the
way, and let X11 try to do the right thing (and help it where minimally
necessary), or we virtualize it so that a common protocol of some sort
(standard scancodes?) is spoken between the NetBSD keyboard/mouse drivers
and X11 (e.g. an extended wscons).

I honestly don't know which approach is better. UNIX has traditionally
supported (where "support" means "get the hell out of the way") nearly
completely "raw" access to various devices for applications that wanted it,
but that means putting the smarts in the application. On the other hand, if
the kernel virtualizes (as UNIX does for disks, TTYs, and other things with
relatively well understood models of operation), then we take on the
low-level support headaches. Are the Xfree86 people pushing any particular
model for this?


I'm probably going to regret asking this, but is supporting a multiple
console system (i.e. N frame buffers, with N keyboard/mouse combinations,
for N users) so that multiple users can use one computer a really
desireable thing?

Maybe "console" is the wrong word.

When people say "multi-headed" to me these days, I think of my
PowerMacintosh 8600/300, with one keyboard, one mouse, and two 20" Apple
MultiSync Monitors on it, with one contiguous desktop (it's nice to have
all that screen real-estate; at one point at Apple, I had a machine in my
office with one color monitor, and two 19" greyscales on either side of it
for terminal windows). I submit that this is likely to be a far more common
configuration (particularly in the Mac system space, since they've
supported multiple screens seemingly forever) than two or more people using
the same machine with multiple frame buffers. I mean, computers are so
cheap (granted, I'm spoiled; I live in Silicon Valley, but that just means
we're on the leading edge of these things; it percolates out to the rest of
the world in due course), why not N CPUs per user for N >= 1, as opposed to
N users per CPU?

Now, having said that, I can give you a pointer to related reference
material; in the old days, we all used TTYs, and all state relating to one
user's interaction with the system was associated with that TTY, which had
a standard interface: ASCII in, ASCII out, and a single node in /dev.
Simple.

In the modern world, where what we would have thought of as a TTY is now
split up in to screen, keyboard, and "pointer" that are all separate
devices with separate drivers, we need a new unifying notion to associate
these things and the processes that want to play with them, with each other
for I/O dispatch, and other common operations. Steve Bellovin took a step
in this direction some years ago by creating the notion of a "session" and
wrote up a paper about it for a USENIX Conference. A quick search of the
Internet in the right place turned this up:

http://www.research.att.com/~smb/papers/sessext.pdf

Steve gave this paper at the Summer 1988 USENIX Conference. While it is
about TTYs, I think the essential notion is what you need to do what you
want; the rest of UNIX should just follow along nicely once this is done.
SMOP.

The rub I see in implementation is figuring out which keyboards and mice
are associated with which frame buffers; I think that problem is just nasty
enough that it's worth dodging by saying, "... there can be only one!"
particularly since if we say that, we get the advantages I enumerated
earlier: no need to care which keyboard is "console" - they all are. No
need to worry about hot-swap, etc.

As I think about it, if we really want to go down this path, we may want to
have a closer look at the Plan9 model: file server, CPU server, "terminal"
(more analogus to an X terminal than a TTY) rather than the "workstation"
model we've been using all this time which is really just a shrunken
timesharing system.

Do you have a particular application in mind for your multiple-user
multiple frame-buffer system?

	really curious,

	Erik <fair@clock.org>

P.S.	I spent this week at the Apple World Wide Developer's Conference
(WWDC) in San Jose; I will be writing up some notes because there are some
things we can use, some issues for us to think about, and some things we
all need to be aware of.