Thanks Markus for the detailed description. Some time ago I implemented such a "filter" to implement the Unicode Bidirectional Algorithm in the terminal. The very poor result has been what is now known as "BiCon". Anyway, the next step I wrote a small shell script to run mingetty inside my filter, called it, say, bidigetty, and updated inittab to run bidigetty instead of mingetty. The main practical problem I faced was that the terminal device that the applications run on is no longer /dev/ttyX, so for example you cannot login as root, unless you add pts* to /etc/securetty, which is not a real solution. Another problem was, after you login on such a terminal, you don't magically become the console owner. So you cannot run startx for example. I'm sure there are solutions for this, [gkx]dm do this for example, but it's not as easy as just implementing a terminal emulator...
behdad On Sun, 16 Jan 2005, Markus Kuhn wrote: > Simon wrote on 2005-01-15 01:12 UTC: > > However, how does this user-space software for console look like? > > What exactly should it do? What's to remove/modify from the kernel? > > The user-mode console communicates with the applications connected to it > using the "pseudo-terminal" device, the same kernel mechanism that > allows xterm, sshd or iscreen to look for their applications virtually > like a good old serial port into which a DEC VT102 is plugged. See > "man pts" for details. > > The user-mode console communicates with the keyboard and VGA card using > a low-level graphics-mode and keyboard library such as SVGAlib or > libSDL, or alternatively, using the same kernel direct memory mapping > mechanisms and raw keyboard modes that these libraries and the X server > or these libraries use already today. > > The user-mode console has to be started as one of the very first > programs by the init process. This way even the stdout of the boot > scripts is already rendered by it. The only text still rendered by the > old kernel console would be: > > - initialization messages by the kernel and its drivers > - kernel error messages (before klogd is started) > - kernel panic messages > > All of these are only intended for expert users and will therefore > without doubt remain in English for the next 25 years. > > I believe that there are no extensions whatsoever necessary to the > kernel to support a user-mode console. All the necessary mechanisms have > been used by X servers for more than 13 years now. > > I'm not sure, whether init should start the user-mode console or vice > versa. > > Alternatively, the user-mode console could be started much later in the > boot process, more like the X server is today. It could even be started > in .profile (like many people do with ssh-agent). > > Such details might well differ from distribution to distribution. > > What I want to say is that something like this is pretty standard and > not at all difficult to implement. Unfortunately, so far the path of > least resistance has guided people towards fiddling with the > emergency-terminal (shall we call it "panic terminal", after its main > purpose?) in the kernel, as opposed to building a simple proper one. > > Perhaps the only reason that this has not been done yet is that nobody > has felt an itch strong enough to fill the gap between the slightly > bloated kernel terminal and the massively bloated X11 environment, with > slim a user-level VT100 emulator with direct non-X framebuffer and > keyboard access. > > (The valid question remains, whether in the end, the result with "full > Unicode 4.1 support" will be any more light weight than X11. I reserve > the right to remain sceptical here.) > > > Any proof-of-concept code that can show the validity of direction? > > Look at the X server and GNU screen, as well as some of the other pieces > of software mentioned above. > > Markus > > --behdad http://behdad.org/ -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/