new console server code checked in

[Marcus Brinkmann]

Hi,

I checked in my new console server code.  It is buggy like hell, but it has
one big advantage over the older code:  It actually makes for a runnable
program that does something visibly useful.

I hope that this allows for a more incremental and hopefully more
collaborative console server.  Everyone can follow the progress, and play
around with the code.  As I said, don't expect something really useful at
this stage of development.

Because I wanted to keep the old code around, I did a bit of renaming.  This
is always ugly, please bear with me.  See the makefile for a list of source
files belonging together (the new code is only console.*, display.* and
input.*).

So what can the new code do?

$ settrans -ac console /hurd/console
$ ls console

No output.  Why?  Because no virtual console is used, and they are created
and destroyed on the fly!  Let's attach a terminal to a virtual console:

$ settrans -ac term /hurd/term `pwd`/term hurdio `pwd`/console/1/console

Does this make a difference?  No.  Why?  Because the hurdio backend in term
is smart enough to open and close the connection as the term node is
opened/closed.  So the term server alone will not make the node used.

Let's try to simulate some program output.  Try in one window:
$ cat > term
Hello World!

Don't forget to press return.  Now, you can try to get an impression of the
content of the virtual console display in another window (keep the above cat
running! or the virtual console will be destroyed because term will close
the connection).

$ cat console/1/display
Hello World!
[24 blank lines]

This assumes your window is 80x25.  Note: You won't be able to see the first
line when it has scrolled off the screen.  There will always be one screen
full of output (eg 2000 characters).  Use dd if you only want the first line
or something.  Note: The input was isolat1 (native encoding), but the output
is actually UCS-4 characters, each 4 byte long, and in the native endianess.
So if you look at the output in less, it is H^@^@^@e^@^@^@l^@^@^@... etc.
Luckily, binary zeroes are swallowed in normal console output, and we have
only used 7bit ASCII so the above works ;)

Let's try to simulate some keyboard input.  Try in the second window:

$ cat term

Leave cat running.  Try in a third window:

$ echo How about this\? > console/1/input

You should now see the "how about" appearing on the second window as output of
cat (read: the application on the terminal receives the input). 
Furthermore, you should now be able to see the output in the "display" file,
because term echoes the input to the console.

Note that the console/1/input file expects UTF-8 encoded characters.  But
the output will be in isolat1 (eg, the native encoding, which will be
configurable, of course)

So you can see, the pieces are there.  However, if you start to become
serious about it, like running "dselect > term", you will see a lot of
corruption on the display, obviously there are bugs in the escape sequence
parser.  emacs doesn't start up fully at all, I am not sure what the bug is
here.  And in general flooding the input buffer or doing other weird things
is not well received by the program (although I did not crash it so far).
There must be bugs in the iconv conversion routines, too, they are way too
complex to get right in a hurry.

However, I don't expect serious problems when debugging this stuff.
The next thing I will write is a cheesy unix console client, that polls the
display node and passes through keyboard input.  When I add virtual console
switching to it, this program should work almost like screen!  And it should
be simple to write.  It will make debugging the console server a lot easier.

What is left to do?
1. No attributes (color/bold) are currently stored in the matrix.  One plan
is to use the 11 higher bits in the UCS-4 characters, which are free.
11 = 3 + 3 + 5, so with foreground and background color, we can store 5
attributes like bold, blinking, underlined, invisible and dim.  I will have
to study ECMA-48 to find out what we really want to do.  There is also the
reverse attribute, but I guess reverse and invisible can be emulated by the
server with choosing the colors appropriately, rather than passing it to the
client.  This would make space for future extension.

The reason I have not activated the attribute code is that it makes it
harder to use "cat" etc for debugging.  With the chessy unix console client,
this will not be an issue anymore.

2. The whole display interface issue, including asynchronous notifications. 
I have some ideas for this obviously.  Maybe the first versions will be
ugly, I hope that nobody expects us to not break the interfaces here in the
beginning. ;)  It seems that with UCS-4 characters, we automatically get the
joy of endian issues, so I will have to convert the data to network byte
order somewhere.  This is not done yet.

I am full of doubts wrt the details of this interface, see my last mails.
For example, cursor position.  Either we will have to add a header in front
of the screen matrix, which contains

Cursor X position
Cursor Y position
Cursor Status (very visible, normal, invisible)

Or we do this via request and notification messages, but then we need some
extra RPCs.

I am also unsure about sharing the data via mmap, in particular when we want
to allow direct writes to the display.  Thomas' async I/O is deprecated, but
what can replace it?

Maybe I should look at how screen does it.

3. The Hurdish VGA/PC Kbd console client will be developed last, when the
interfaces have been proven usable by the unix console client.
And then hopefully the BRLTTY software.

Lots of more stuff to resolve, but we are getting there.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de