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/

Reply via email to