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 GNU http://www.gnu.org for public PGP
> Key
> [EMAIL PROTECTED] PGP Key ID
> 36E7CD09
> http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
