On Tue, Sep 28, 1999 at 10:08:03AM -0400, Thomas Bushnell, BSG wrote: > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > > No, this is unrelated. The term translator handles input stream of > > characters. It would be useful to get the scancode directly and do mapping > > in the translator. > > > > What you mean should probably be handled by a device similar to framebuffer > > device in Linux. The GGI people have some ideas here, I am sure, and i think > > they are interested in contributing a translator. Maybe this translator > > could do text mode as well. > > term is responsible for both input and output. > > When I've spoken about punting the Mach console driver, I mean getting > rid of both halves, and having term poke the screen memory and > directly fetch scancodes. This is not to imply that this is the Right > Thing; just that it's what I've been thinking of.
Allright then. I was a bit confused with the framebuffer device in Linux and what the GGI people do. The GGI people have a thing called KGI. >From http://www.ggi-project.org/docs/Whatiskgi/Whatiskgi.html: KGI stands for Kernel Graphics Interface. KGI has two basic goals: 1. to add support for multiple monitors and keyboards 2. to add support for the needs of libggi In the Hurd, it would be a translator which would be set to /dev/display and provide a full set of subdirectories head? containing vty* devices. It would be great to get the KGI people interested in implementing this on the Hurd. There was already a short discussion about KGI on the Hurd on their mailing list, but it did not lead to anyone working on it. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNU http://www.gnu.org for public PGP Key [EMAIL PROTECTED] PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
