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