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 [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
