colortext translator

[Kalle Olavi Niemitalo <tosi@ees2.oulu.fi>]

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> 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.

Thomas wrote those features wouldn't belong in /hurd/term, so I'm
writing a separate translator.  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.

http://stekt.oulu.fi/~tosi/gnu/colortext-0.1.tar.gz

I fear the input half will be more difficult to write because it
must block until the user presses a key.

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

         			     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?