Ok, I know nothing about the Hurd... yet. I went to a few pages to learn more
about what you were talking about and I liked it so much, that I am swiching to
the Hurd soon :-)
BUT, from what I saw (and I must say again, I have NO experence with the Hurd
yet) all you would need to do is make a daemon that talks directly to the
hardware (about like X) in user space and leave the micro- kernel alone. In
other words, make a "KGI server"-like daemon. This might sound horrable to
Linux (and other non-MACH micro-kernel) users, but it seems to be the Hurd's
way. I mean look at what "Hurd" means: Hird of UNIX-replaceing daemons. (Sorry,
I can't remember what "Hird" meant) Does anybody have a daemon like this?
Again, Hurd dudes, feel free to shut me up if I am saying this wrong.
GGI Folks:
A few Hurd folks are making noises about porting KGI/GGI onto the Hurd.
At one time a few of you were somewhat interested in this, but didn't
make much progress.
Can a kind, knowledgable soul join our "debian-hurd" mailing list and
provide some technical support?
The main questions we are trying to resolve are:
1. How to best break KGI/GGI into a kernel/user codebase. Most
processes (such as the ext2 filesystem) live in "user" space. Only
very specific things go in the microkernel -- those things that
have to deal directly with the hardware.
2. How best to get FB support into the microkernel.
We already have some glue code in place to make use of various
Linux device drivers. It shouldn't be too terrible to get others
working now. Unfortunately, most of the drivers are Linux 2.0.36
level, but we could probably update the glue code for more modern
stuff.
Attached is a recent debian-hurd message from one of the two
independent console-coding efforts that started recently. Instead
of this, we would really like to jump directly to the GGI console.
-Brent
-Original Message-
From: Marcus Brinkmann [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 29, 1999 4:47 PM
To: Kalle Olavi Niemitalo
Subject: Re: colortext translator
Hi Kalle,
On Thu, Sep 30, 1999 at 01:32:44AM +0300, Kalle Olavi Niemitalo wrote:
Thomas wrote those features wouldn't belong in /hurd/term, so I'm
writing a separate translator.
Mmmh. I see.
Reading from it would translate
scancodes from the keyboard, and writing to it would interpret
escape sequences and poke characters in video memory. The output
half now lacks only virtual consoles, scrollback and beeping.
Sounds good. Had you told earlier that you make such a steady progress,
I probably would not have spent the last days to get the linux console
working.
(Are you subscribed to bug-hurd? You must have noticed my screams for help
:)
What you mean should probably be handled by a device similar to
framebuffer
device in Linux.
Are you implying that device wouldn't parse the escape sequences?
Sorry, I hadn't all my senses together when writing this.
E0 scancode
line--- keymap --- translation --- inb()
sh --- discipline
--- esc seq -- framebuffer --- poke to
parser for each vc vid mem
The line discipline is handled by /hurd/term. I imagine
everything at its right side would be in /hurd/console, except
the inb() which would stay in the kernel. How would you split
them up?
Looks great! I have to admit I didn't know much about terminals at all until
a few days ago, but I am learning fast.
I think what you are doing is great (as it seems to give fast results, fits
nice into the Hurd philosophy and the current code and gives you practice
in writing translators).
However, I still think it would be good to take a look at KGI, before you
start to reinvent the wheel. But if you limit yourself to one EGA adapter
and
one input keyboard, there is no danger in doing so, and porting KGI would
probably be a major undertaking.
Have you looked at KGI yet? It is supposed to enable multihead/multiinput
terminals. It virtualizes the mouse device. It has interfaces for libggi,
enabling us to use the vgalib emulation and X server from the GGI project.
It also has a terminal server.
I don't know how much work it would be to form KGI into a proper Hurd
translator. Can you take a look at it? A snapshot can be found in
http://www.tu-chemnitz.de/~sse/ggi/.
Also, how interacts your translator with the kernel logger? How does it
interact with the keyboard driver (we need to make sure we can get X working
with it in some way). Those are all questions I don't know an answer for
(I face the same questions with the linux console driver in GNU Mach).
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP
Key
[EMAIL PROTECTED]PGP Key ID
36E7CD09
