Re: Events in libcons

[Thomas Bushnell, BSG]

Ok, so it sounds like a "console" is basically the Hurd replacement
for what is called the "console" in Linux: that is, its job is to
emulate vdt behavior on a PC display, and do the other sorts of things
people expect from the Linux "console".  This is good because it takes
that functionality out of Mach, where it never belonged in the first
place.  (This was an action item for a long time, and I'm delighted to
see it going.)

That is, a console is a mapping between the Hurd term protocol and
actual hardware.

There's another beastie I'm thinking about, and I wonder if
abstracting it might not also be a good idea.  That beastie is a
"vdt/keyboard/mouse", and you would run X on it, and to run the above
mentioned "console" on it too.  Call this thing a "human interface
link" (a term I have stolen from HP), or "hil" for short.

An hil would map between something-we-don't-have-now and actual
hardware.

We could then run the normal console on top of an hil instead of on
top of the raw hardware.  That would be fine performance-wise.  X
would also sort-of run on top of the hil: but only by using hil
features to find out what kind of video card you have and such, and
then using some hil call to get at the raw hardware.  I think the
patches to the X server would be fairly minimal here.  We could make X
configuration a lot easier it seems to me.

Now the normal hil would run on raw hardware.  But we could also make
a java program that implemented the hil inside a remote web browser.
Or inside an X window.  The possibilities are endless.

The console would then no longer have to do the job it does now:
understanding the details of hardware; it could instead just map term
to hil and let the hil understand the details of hardware.

(Or, alternatively, the functions I've described as "console" and
"hil" could be combined into one.  But I think that's probably the
wrong approach.)

Thomas