Re: Events in libcons

[Marcus Brinkmann]

At 03 Apr 2004 16:44:04 -0800,
thomas wrote:
> 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.)

Oh, yes.  It's already working for some time now.  What marco is
working on is extra-features and integrate it with X (so you can start
X from inside the console client etc).
 
> 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.

Yes.  This is really desirable to sanitize the sharing of hardware
properly.  Switching between the console and X in Linux (and in our
current console client, when it is implemented) is really a bad hack
(and not really robust).  What you want is a layer below the console
and X that abstracts the human interface hardware and allows to
manage/share it.

> 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.

Yes, yes, and yes!
 
> 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.

Yes again!
 
> 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.

Yes once more!
 
> (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.)

You know, this idea of a HLI is so great that other people already had
it (dammit!), however, rather than patenting it (*sigh of relieve*)
they actually implemented it (cool!).  It's called KGI, and you
probably have heard of it (Kernel Graphics Interface).  Despite the
odd name, and the fact that it was used as lower-layer for GGI, it is
actually exactly what you describe, plus a set of low-level drivers
for Linux.

KGI has exactl the abstraction you want.  It has low level drivers,
which are organized into human interface links in the "KGI manager".
In the Hurd, the KGI manager would not be in the kernel, as in Linux,
but in a Hurdish server, of course.  You can assign (and reassign at
runtime) several input and output devices to the various human
interface links managed by the manager.  These can then be used by
GGI, or something else (special X server, or SDK, whatever).

The KGI people have already worked out interfaces that also allow
accelerated hardware access to some extent, if I understood it
correctly.  However, despite the fact they give you some raw hardware
access for that, it is a sufficient high level abstraction.  (Given
the fact that acceleration is plenty important these days for multi
media applications, you can't avoid it - but you can at least make the
rest of the infrastructure clean).

Implementing a KGI manager for the Hurd (well, the low level drivers
are something that is also needed, but I like to think of that as a
minor implementation detail that is not visible from the outside) is
something we have thought now and then for some time.  It always came
up when discussing the future of the console, and we actually had a
chat with KGI developers about it.

So, your intuition matches exactly what we already considered to be
our long-term plan.  With KGI, there is already an external project to
draw from.  So, it's not even that difficult a path to follow.  When
it happens, GGI can easily be ported (and GGI comes with an X server
for GGI).  The console should also be easy to port to KGI then.  At
that point, things would fall together very nicely.

Until then, the short term plan (which is ery cost-effective, because
it is proven and really simple to do), is to have a console switching
interface like Linux/BSD, and simple pass-through repeater devices for
kbd and mouse (which X uses to get at the raw or even translated input
data).  Marco is already almost finished with an implementation of
this.  This setup has none of the cool flexibility of the HLI idea,
but it models exactly what people know from Linux/BSD, and allows to
make the new Hurd console the default in Debian GNU/Hurd, which is a
big usability boost.

PS: The new Hurd console already (without the HLI stuff) allows for
many nice features like internationalization comparable to the Linux
console (unicode support etc), but also makes it pretty easy to port
brltty (braille terminal) to it, and many other usability features.
I believe that with just a little more work (which Marco seems to be
willing to put into it), it will actually slightly exceed the
usability of the Linux console, and thus equalizes the "first
impression" that the user gets when starting the system.

Thanks,
Marcus