linuxconsole-dev

[Linuxconsole-dev] Municon

[Jim P. <ji...@ag...>]

Hi all -

Okay, time to spill the beans.  I've been developing ideas for a new
terminal-type I'm calling `Municon' (for Multimedia Unicode Console, if
no-one's already used that name).  I'm fairly good with ideas and design,
but not necessarily so good at development or delivery (okay?), so I'm
sharing the ideas, to see where this leads.

WARNING: This is all VAPOURWARE at present.  No code yet.

I'm working from the idea that a terminal should be able to live on the end
of two pipes (or a fast serial cable).  `stty' settings and LF->CRLF mapping
and so on can stay in the kernel, where it's always been.  This ensures
compatibility.

My motivations are these:

- I like the console environment.  Everything runs full-screen.  I can have
lots of things running at the same time, and switch very quickly and easily
between them.  The keyboard drives (almost) everything.  Everything appears
in my favourite font, and at a size that is comfortable for me to read
(because I chose it).  The background is black by default, so I don't get a
headache.

- Things are moving on.  The console no longer is limited to text-mode, 16
colours and 256/512 characters.  Why not expand to meet the potential,
whilst keeping the essential features ?

- Let's not give too much control to the application.  Let's keep the user
firmly in control of their working environment.

- Let's make it dead easy to write scripts and programs to drive this.  No
more nonsense having time-outs to read the ESC key.

- Let's not try and do everything.  If you want to do streaming video, open
your own /dev/fb device.  But if you want to write a quick script to dump
your results graphically to the screen, this may be for you.  In a
restricted but flexible and easy-to-code-for environment, simple utilities
proliferate.  We love text files, right ?  Binary files ... hmmm, well ...
not so nice to hack ...

Basic features would be:

- Based on Unicode UTF-8 to support everyone's language, with right-to-left
text for those that need it.  Word or character-wrapping at line-ends.
Stick to across-then-down text, with upwards scrolling - I think Chinese
people can read across as well as down, right ?

- Modeless as far as I can take this.  I don't want my text suddenly turning
to graphics after catting a binary file.  Lose most settings (colours,
text-direction, etc) at a '\n'.

- Support for proportional and fixed-pitch fonts, but only one of each, and
those set by the user.  There will be a standard set of symbols that
applications can always expect to be present, such as ASCII + line-drawing
stuff, or whatever.  The application can define its own characters, but
perhaps we can limit it to the user-band of Unicode.

- Support for basic pixel graphics, in a few crude formats.  No complex
compression or anything, dead easy to code to get a quick picture onto the
screen.

- Support for PCM mono/stereo sound, again in a few simple formats, as the
next step up from BEL.  The BEL sound itself can be set by the user.

- Cut and paste with the mouse (as gpm).  Also, maybe, clickable regions
that generate key-sequences or commands (see later).  Maybe also generate
sequences from dragging one region on top of another.  This is crude, but
you can build a lot with this - even a shell-script based filemanager with a
trash basket, entirely navigable with the mouse.

- Mouse pointer disappears after two seconds or so without activity, so that
it doesn't get in the way.

Data stream to the terminal would consist of UTF-8.  Single-character
control codes work as expected, where this is useful.  Multi-character
`escape-codes', which I'm calling command-sequences, are introduced by a
special control code (I'm thinking ^^ right now), and look like a command.
They are terminated by another code (^_).  They are also aborted by '\n',
and certain other characters so that we don't ever get stuck in
`graphics-mode' or anything like that.

These command-sequences are very extensible - I'm thinking of starting with
a sequence of alphabetics for most commands, so the scheme could be extended
indefinately.  Any command-sequences or characters that are not known are
dumped to the screen, so nothing invalid ever gets silently forgotten.  This
also means that Unicode characters that aren't present in the user-selected
font are represented by something like a narrow box, so that you know that
you're missing something.

Anything that isn't a glyph (e.g. graphics or sound) is passed within a
command-sequence.  This doesn't have to be one immense command-sequence - it
can be broken up into manageable chunks as several smaller command-
sequences.

Coming the other way, the data-stream from the terminal also consists of
UTF-8.  Any key-press that does not represent a printable glyph, and that
isn't normally represented with one of the control-characters 0-31, comes
through as a command-sequence, in the same format as the command-sequences
in the other direction.  I'm thinking that they can come through in
Emacs-style, perhaps something like ^^key C-M-Up^_.  If I'm going to use ^^
and ^_ for sequence-delimiters, then these would have to come through as
`key C-^' and `key C-_'.

For complex applications, it's also going to be necessary to query the
terminal about many things from the application.  The application would send
a command-sequence (or several), then wait for replies to arrive back as
command-sequences in the input stream.  I know there are slight difficulties
for the application if it receives key-presses amongst the replies, but this
has to be lived with.

The queries would include Municon version-number, the screen-size, the
cell-size (for fixed text), width of a given string (for proportional text),
any many other bits and bobs.  There can be a lot more communication going
on than is common with a normal console application, especially if the
application is fussy about how things appear, mostly to handle proportional
text.  However, for a simple application that is happy to let words wrap
where they will, they can just dump it all to the screen.

Also, so long as we can get the screen-size to them, normal curses-type
applications will work without problem using the fixed-pitch font.  (Mapping
input keys might need some attention, though).

Other ideas include:

- Having a single timer in the terminal that sends a command-sequence back
when it expires (or maybe even a key-sequence).  The application can set
this timer to a clock-time, or a time-delay.  This could be used for easy
time-outs in shell scripts, or even for keeping an application's clock
display *accurately* up to date.

Remember that I'm seeing a big split between the terminal and the
application-hosting machine, that is, where the serial cable would be, even
if this is in fact all on the same machine.  I'd like to see the user firmly
in control of the configuration of the terminal-side of all this.  This
means that the user can set this up however they want.  For Chinese people,
for example, this may mean some peculiar keyboard mapping that allows them
to enter their characters into some pop-up box on the screen.  

I don't know, but this is all feasible within this scheme of ideas.  The
terminal is theirs to configure and adapt to their precise circumstances.
The application need know nothing of this.  All it gets is glyph-codes and
key-sequences - it need know nothing of how these have been entered.

You see - all I'd be defining with this is the valid sequences over the
link, and the behaviour of the terminal.  Implementation and operation of
the terminal could be extremely wild and weird without upsetting anything at
all.  This could be handled with plug-ins or whatever.

The implementation could live on top of fbdev, or GGI, or X - it doesn't
matter to the application.  It could be a daemon running in user-space with
pseudo-ttys (or maybe some modified version of these), or it could even live
in the kernel (though to be honest, I'd rather keep it out of there).

That's all I have for now.  This is all vapourware at present, but this
nails a whole lot of my concerns, and opens up the role of the console as a
device for quick graphics and sound hacks, as well as its traditional
role for text.

Remember that the console has always been very hands-on, handling many
different contexts within the same text-grid, whether that be scrolling
shell interaction, or paging text, or a text-editor.  All of these cross
over.  You can `cat' the caught output of a command, or page it, or edit it.
This doesn't happen in X.  If we can extend this to graphics and sound,
there is a lot of potential.  You can catch the output of your `beep'
command, and `cat' it later, or pipe your picture through `sed'.  

To realize this potential, however, everything needs a common standard to
work with, the equivalent of `plain text'.  This to me means UTF-8 +
command-sequences.  If all the common tools can be extended to handle UTF-8
(I suspect many do already), we're well on the way.  If command-sequences
can be made clean enough, maybe applications, like pagers or editors could
understand and edit these also.

I need to think more about handling tabbing and regions, and so on, and some
other implementation issues, but I hope you can see the potential.
Apologies for my inflexibility, but hope you can see where I'm heading.
Actually, no apologies for my inflexibility - there's a reason for it !

Am I being too much of an idealist with all of this, perhaps being a little
unrealistic ?  I don't know.  I'd much rather take the time to come up with
a clean design than add more gunk to the ANSI terminal, and try to live with
that and feel happy.

Any comments ?  Anyone spotted any design flaws ?

Does anyone see how we can take this forwards ?  Would anyone like to join
me on this, bearing in mind the current (undeveloped) state of play ?  

Does this seem to be a worthwhile project to you ?

I have some design work to do, I think, if this is going to fly.

Jim

-- 
 Jim Peters         /             __   |  \              Aguazul
                   /   /| /| )| /| / )||   \
 jim@aguazul.      \  (_|(_|(_|(_| )(_|I   /        www.aguazul.
  demon.co.uk       \    ._)     _/       /          demon.co.uk

Re: [Linuxconsole-dev] Splitting console driver and VT emulation

[Jim P. <ji...@ag...>]

> > Make the terminal emulation a loadable module.  Have the console driver
> > look for module "vte" and then you can use the alias mechanismen of
> > modload to push the appropriate module.  If that fails fall back to dumb
> > line mode (similiar to the framebuffer initialization).
> > 
> > Does that appear a workable solution?
> 
> Yes:)

Another idea - the terminal emulator can live in user-space (a terminal-
emulator daemon ?), sitting on top of the normal Linux console code, or
fbdev, or GGI, or X, or whatever.  It can use /dev/ttyp? as the tty device.

It doesn't need to go into the kernel.  If we take the GGI approach of only
having hardware-banging stuff in the kernel, then there is no reason to have
the terminal emulator live there as well.  If we can get all the services we
need from the kernel one way or another, then the terminal emulator can live
outside.  This is what xterm does anyway - sits on X, grabs a pseudo-tty.

This may need to be a high-priority process to keep the display up-to-date
in the face of high system loads.  This is a downside, but there is also the
up-side that the application does not block whilst the display is updated
(as with a kernel solution), but only when the pipe buffer is full.  A
daemon updating once every frame or so could cut out a lot of unnecessary
updates when applications have rolling counters or whatever.

Any objections to this idea ?

The other thing to remember is that in the case of a real hardware terminal,
the only link to the main machine is a two-way serial cable.  So a terminal
emulator could live on the end of a couple of pipes, across the network if
necessary.  This is taking the detachment from the kernel to the extreme,
but perhaps you see the point.

Once you've worked out how to do multiple-keyboards, multiple-heads, and so
on in the kernel, the user-space daemon could be configured to pick these
up and make use of them.

The terminal emulator daemon could support many pseudo-ttys on one display,
using hot-keys to switch (just like Alt-Fn), or even two displays at the
same time, moving pseudo-ttys between them.  You can do a lot from
user-space if the kernel can provide the services.

Jim

-- 
 Jim Peters         /             __   |  \              Aguazul
                   /   /| /| )| /| / )||   \
 jim@aguazul.      \  (_|(_|(_|(_| )(_|I   /        www.aguazul.
  demon.co.uk       \    ._)     _/       /          demon.co.uk

Re: [Linuxconsole-dev] Progress on Sapphire

[Eric S. R. <es...@th...>]

Dominik Kubla <dom...@un...>:
> Well we could report the instance: eg. 1 for tty1, 2 for tty2, that could
> be useful and wouldn't waste too many bytes...

True.
 
> Keyboard Status Report (Source: VT420 Progamming Summary, p147):
> DECREPTPARM (Source: http://www.cs.utk.edu/~shuford/terminal/virek100.txt)

Great!  I'll include these resources in nroff comments in the man page
source.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"I hold it, that a little rebellion, now and then, is a good thing, and as 
necessary in the political world as storms in the physical."
	-- Thomas Jefferson, Letter to James Madison, January 30, 1787

[Linuxconsole-dev] console_codes(4) is updated

[Eric S. R. <es...@sn...>]

I have updated console_codes(4) to reflect the changes in the Sapphire
candidate patch I gave Dominik.

James, are you going to initialize the CVS setup any time soon?  It's 
about time for us to start checking in things so shared work can go forward.

I'm going to test the Sapphire candidate on 2.2.12 today.  Other than that
I'm out of things to do.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Everything you know is wrong.  But some of it is a useful first approximation.

Re: [Linuxconsole-dev] Progress on Sapphire

[Dominik K. <dom...@un...>]

On Wed, Mar 08, 2000 at 11:24:49AM -0500, Eric S. Raymond wrote:
...
> > Haven figured out a use for the tertiary DA yet.  Using the hostid
> > as device id has the same implications as the Unique Processor ID
> > of Pentium III cpus (ignoring the fact that hostid is in widespread
> > use in the Unix world)
> 
> I think I'd stay away from that.

Well we could report the instance: eg. 1 for tty1, 2 for tty2, that could
be useful and wouldn't waste too many bytes...

> This reminds me.  What do your canned responses to the Keyboard Status, 
> Data Integrity check, and DECREQTPARM actually mean?   I want to mention this
> in the man page.  (I was able to find docs on the printer and UDK status).

Keyboard Status Report (Source: VT420 Progamming Summary, p147):

  Request (Host to VT420)   CSI ? 26 n
  Report  (VT420 to Host)   CSI ? 27 ; Pla ; Pst ; Ptyp n

     Pla = keyboard dialect
       1 = North American
       2 = British
       3 = Flemish
       4 = French Canadian
       5 = Danish
       6 = Finnish
       7 = German
       8 = Dutch 
       9 = Italian
      10 = Swiss French
      11 = Swiss German
      12 = Swedish
      13 = Norwegian
      14 = French/Belgian
      15 = Spanish
      16 = Portuguese
      28 = Canadian (English)

     Pst = keyboard status
       0 = keyboard ready
       3 = no keyboard
       8 = keyboard busy

     Ptyp= keyboard type
       0 = LK201
       1 = LK401

DECREPTPARM (Source: http://www.cs.utk.edu/~shuford/terminal/virek100.txt)

   Report  (VT100 to Host)   CSI Ps ; Pp ; Pb ; Px ; Pr ; Pm ; Pf x

      Ps = type of report
       1 = report as requested by the host
       2 = unsolicited report

      Pp = parity
       1 = no parity
       4 = even parity
       5 = odd parity

      Pb = bits per character
       1 = 8 bits
       2 = 7 bits

      Px = transmit speed
      Pr = receive speed
       0 =    50 bps
       8 =    75 bps
      16 =   110 bps
      24 =   134.5 bps
      32 =   150 bps
      40 =   200 bps
      48 =   300 bps
      56 =   600 bps
      64 =  1200 bps
      72 =  1800 bps
      80 =  2000 bps
      88 =  2400 bps
      96 =  3600 bps
     104 =  4800 bps
     112 =  9600 bps
     120 = 19200 bps

      Pm = bit rate multiplier
       1 = 16x

      Pf = value of the for switches in block 5 of SETUP-B if the STP
           option is installed.

Dominik
-- 
  Networking Group,  Hospital of Johannes Gutenberg-University                  
  Obere Zahlbacher Straße 69, 55101 Mainz, Germany                              
  Tel: +49 (0)6131 17-2482   FAX: +49 (0)6131 17-5521                           

[Linuxconsole-dev] writeup

[Brad M. <br...@tu...>]

James,

Your emailer is linewrapping your patches. That's a good way to piss off
maintainers.

I'd like to do a writeup with diagrams for the new console system like I
did before, including the terminology we all agree on. (Head, console,
tty, etc.) Have we all agreed on what we call things? For example, is a
crt an example of a head or is a head the collection of multiple displays
and input devices used by a single person?

Brad
br...@tu... | http://www.turbolinux.com/~brad/

Re: [Linuxconsole-dev] comments on multi-heading/console

[Steffen S. <s.s...@ph...>]

James Simmons wrote:

> > also, another possiblity would be to make solid api's for the fb, and
> > inputX, then create whatever console code you wanted in userspace,
> > bypassing any of linus's kernel decisions.
> 
> Personally I think this is the best approach for multihead aware programs.

A view I share.

> A VT should just be a one keyboard and one display. I used to think it was
> a cool idea to map a multiple devices like several display or several
> keyboards to a VT. So a VT would be 3 display and 2 keyboards and other
> crazy combos. Fbdev sort of does this now. 
> It maps a console to a display.
> With working with fbdev I realize now its a PITA. Know I think its better
> if a app wants to be multihead aware to open the explict hardware devices
> and grab them for themselves. Now of course the kernel has to see if
> someone is using a VT for any device you want to explictly use.

That is basically how my approach works internally to implement
consoles.
The video hardware drivers, input hardware drivers etc. only care about
mapping a virtual representation (devices) to the actual hardware.
 
> Take
> /dev/fb. You wouldn't want to be on a console and then all the sudden a X
> session starts because someone ran X on anther station requestion that
> head you are on. I really like to see the X server some day just using
> /dev/input and /dev/fb instead of any VTs like its does now.

But, there are more (security and ease-of-use) issues involved as
I had to learn.

Most important I found no (reasonably simple) way to establish 
proper protection/virtualization without introducting another process
attribute, the workplace ID. This should be set by the initial
login process like the user-ID. With that you can easily virtualize
console specific /dev entries as neccessary.
However, I did not implement it as there are much more issues,
especially login,xdm etc. need to be made aware of this.

			Steffen

PS: some 'low-level introductionary style' articles that explain how
KGI handles the human-machine interaction issues may be found at

http://www.tu-chemnitz.de/~sse/ggi

People on this list may or may not want to read and comment on it.

PPS: The sample implementation code referred in these articles
may be found there as well. Browseable or downloadable at your choice.
It is fairly useable in terms of a console replacement and I had a
simple true multihead system going with two keyboards and two monitors,
each running independent sessions, with multiple virtual terminals, etc.
_______________________________________________________________________________
Steffen Seeger                             
mailto:se...@ph...

Re: [Linuxconsole-dev] UNICODE patch

[Eric S. R. <es...@th...>]

James Simmons <jsi...@ac...>:
> Here is a old unicode support patch I have. 

I'm not sure how to deal with this.  I don't understand what it's doing, and
I'm handed the Sapphire candidate over to Dominik.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Of all tyrannies, a tyranny exercised for the good of its victims may
be the most oppressive. It may be better to live under robber barons
than under omnipotent moral busybodies. The robber baron's cruelty may
sometimes sleep, his cupidity may at some point be satiated; but those
who torment us for our own good will torment us without end, for they
do so with the approval of their consciences.
	-- C. S. Lewis

Re: [Linuxconsole-dev] Progress on Sapphire

[Eric S. R. <es...@th...>]

James Simmons <jsi...@ac...>:
> 
> > > We should also patch the MAINTAINERS file, shouldn't we?
> > 
> > Yes, but how we do that exactly will depend on how we do our release
> > packaging (which is James's problem).
> 
> The best thing to do is place these patches in CVS and announce it on 
> linux-kernel so people can go test it. Have CVS with 3 top directorys for
> each release. Sapphire, emrald, and ruby.

OK.  I gather the idea is that the base version of each file in the CVS is
copied from the release we're going to ship the patch for?

Sapphire is in good shape, I think.  I've handed a Sapphire candidate
to Dominik.  I will test my copy later today, after I finish updating
console_codes(4).

> So it would look like using just vc_data and expanding it would be the
> best choose I think. Any opinons?

Not from here, I don't know that code.


BTW, have we done a public launch announcement for c.o.l.a yet?
If not, I'll write and ship one.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Everything you know is wrong.  But some of it is a useful first approximation.

[Linuxconsole-dev] UNICODE patch

[James S. <jsi...@ac...>]

Here is a old unicode support patch I have. 

"Look its a text editor, not its a OS, no it Emacs"
James Simmons                                           ____/| 
fbdev/gfx developer                                     \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U

This fixes the input side of the Unicode console: mouse selection and
keyboard mappings.


diff -u -r v2.2.0-pre9/linux/drivers/char/console.c linux/drivers/char/console.
c
--- v2.2.0-pre9/linux/drivers/char/console.c    Fri Jan 22 20:44:08 1999
+++ linux/drivers/char/console.c        Fri Jan 22 23:51:37 1999
@@ -1027,7 +1027,7 @@
                                  * control chars if defined, don't set
                                  * bit 8 on output.
                                  */
-                               translate = set_translate(charset == 0
+                               set_translate(vc_cons[currcons].d, charset == 0
                                                ? G0_charset
-                                               : G1_charset,currcons);
+                                               : G1_charset);
                                disp_ctrl = 0;
@@ -1037,7 +1037,7 @@
                                  * Select first alternate font, lets
                                  * chars < 32 be displayed as ROM chars.
                                  */
-                               translate = set_translate(IBMPC_MAP,currcons);
+                               set_translate(vc_cons[currcons].d, IBMPC_MAP);
                                disp_ctrl = 1;
                                toggle_meta = 0;
                                break;
@@ -1045,7 +1045,7 @@
                                  * Select second alternate font, toggle
                                  * high bit before displaying as ROM char.
                                  */
-                               translate = set_translate(IBMPC_MAP,currcons);
+                               set_translate(vc_cons[currcons].d, IBMPC_MAP);
                                disp_ctrl = 1;
                                toggle_meta = 1;
                                break;
@@ -1330,7 +1330,7 @@
        color           = s_color;
        G0_charset      = saved_G0;
        G1_charset      = saved_G1;
-       translate       = set_translate(charset ? G1_charset : G0_charset,currc
ons);
+       set_translate(vc_cons[currcons].d, charset ? G1_charset : G0_charset);
        update_attr(currcons);
        need_wrap = 0;
 }
@@ -1345,7 +1345,7 @@
        bottom          = video_num_lines;
        vc_state        = ESnormal;
        ques            = 0;
-       translate       = set_translate(LAT1_MAP,currcons);
+       set_translate(vc_cons[currcons].d, LAT1_MAP);
        G0_charset      = LAT1_MAP;
        G1_charset      = GRAF_MAP;
        charset         = 0;
@@ -1428,12 +1428,12 @@
                return;
        case 14:
                charset = 1;
-               translate = set_translate(G1_charset,currcons);
+               set_translate(vc_cons[currcons].d, G1_charset);
                disp_ctrl = 1;
                return;
        case 15:
                charset = 0;
-               translate = set_translate(G0_charset,currcons);
+               set_translate(vc_cons[currcons].d, G0_charset);
                disp_ctrl = 0;
                return;
        case 24: case 26:
@@ -1740,7 +1740,7 @@
                else if (c == 'K')
                        G0_charset = USER_MAP;
                if (charset == 0)
-                       translate = set_translate(G0_charset,currcons);
+                       set_translate(vc_cons[currcons].d, G0_charset);
                vc_state = ESnormal;
                return;
        case ESsetG1:
@@ -1753,7 +1753,7 @@
                else if (c == 'K')
                        G1_charset = USER_MAP;
                if (charset == 1)
-                       translate = set_translate(G1_charset,currcons);
+                       set_translate(vc_cons[currcons].d, G1_charset);
                vc_state = ESnormal;
                return;
        default:
@@ -1778,8 +1778,10 @@
        unsigned long draw_from = 0, draw_to = 0;
        struct vt_struct *vt = (struct vt_struct *)tty->driver_data;
        u16 himask, charmask;
+       unsigned short *translation;

        currcons = vt->vc_num;
+       translation = get_acm(translate);
        if (!vc_cons_allocated(currcons)) {
            /* could this happen? */
            static int error = 0;
@@ -1848,7 +1850,7 @@
                      utf_count = 0;
                    }
                } else {        /* no utf */
-                 tc = translate[toggle_meta ? (c|0x80) : c];
+                 tc = translation[toggle_meta ? (c|0x80) : c];
                }

                 /* If the original code was a control character we
diff -u -r v2.2.0-pre9/linux/drivers/char/consolemap.c linux/drivers/char/conso
lemap.c
--- v2.2.0-pre9/linux/drivers/char/consolemap.c Wed Jan 20 21:17:04 1999
+++ linux/drivers/char/consolemap.c     Fri Jan 22 23:44:43 1999
@@ -9,6 +9,29 @@
  * Support for multiple unimaps by Jakub Jelinek <jj...@ul...>, July 199
8
  *
  * Fix bug in inverse translation. Stanislav Voronyi <st...@cn...arkov.
ua>, Dec 1998
+ *
+ * Adapted for selection in Unicode by <ed...@ra...>, January 1999
+ *
+ */
+
+/*
+ * There are two kinds of mapping:
+ *
+ * Application-Charset Map (ACM) maps from 8-bit character to 16-bit Unicode.
+ * Data structures: translations[4][256], inverse_translations[4]
+ * Functions: clear_inverse_translations, set_inverse_translations,
+ *            set_translate, get_acm, inverse_translate, con_[gs]et_trans_*
+ *
+ * Screen Font Map (SFM) maps from 16-bit Unicode to font position.
+ * Data structures: struct uni_pagedir
+ * Functions: clear_inverse_map, set_inverse_map,
+ *            inverse_convert, *_unimap, conv_uni_to_pc
+ *
+ * An inverse SFM is calculated when it is required by inverse_convert,
+ * but an inverse ACM is calculated from sys_setup and whenever the ACM
+ * changes. This is because inverse_translate may get called from inside
+ * an interrupt in keyboard.c.
+ *
  */

 #include <linux/kd.h>
@@ -129,6 +152,7 @@
   },
   /* User mapping -- default to codes for direct font mapping */
   {
+    /* UNI_DIRECT_BASE, ... */
     0xf000, 0xf001, 0xf002, 0xf003, 0xf004, 0xf005, 0xf006, 0xf007,
     0xf008, 0xf009, 0xf00a, 0xf00b, 0xf00c, 0xf00d, 0xf00e, 0xf00f,
     0xf010, 0xf011, 0xf012, 0xf013, 0xf014, 0xf015, 0xf016, 0xf017,
@@ -167,84 +191,180 @@
 /* The standard kernel character-to-font mappings are not invertible
    -- this is just a best effort. */

-#define MAX_GLYPH 512          /* Max possible glyph value */
+static unsigned char ***inverse_translations[4] = { NULL, NULL, NULL, NULL };

-static int inv_translate[MAX_NR_CONSOLES];
+#define MAX_GLYPH 512          /* Max possible glyph value */

 struct uni_pagedir {
        u16             **uni_pgdir[32];
        unsigned long   refcount;
        unsigned long   sum;
-       unsigned char   *inverse_translations[4];
+       u16             *inverse_map;
        int             readonly;
 };

-static struct uni_pagedir *dflt;
+static struct uni_pagedir *dflt = NULL;

-static void set_inverse_transl(struct vc_data *conp, struct uni_pagedir *p, in
t i)
+static void clear_inverse_translations(int m)
 {
-       int j, glyph;
-       unsigned short *t = translations[i];
-       unsigned char *q;
-
-       if (!p) return;
-       q = p->inverse_translations[i];
+       unsigned char ***q = inverse_translations[m];
+       unsigned char **p1;
+       int i, j;

-       if (!q) {
-               q = p->inverse_translations[i] = (unsigned char *)
-                       kmalloc(MAX_GLYPH, GFP_KERNEL);
-               if (!q) return;
+       if (!q) return;
+
+       for (i = 0; i < 32; i++) {
+               if ((p1 = q[i]) != NULL) {
+                       for (j = 0; j < 32; j++)
+                               if (p1[j])
+                                       kfree(p1[j]);
+                       kfree(p1);
+               }
        }
-       memset(q, 0, MAX_GLYPH);
+       kfree(q);
+       inverse_translations[m] = NULL;
+}

-       for (j = 0; j < E_TABSZ; j++) {
-               glyph = conv_uni_to_pc(conp, t[j]);
-               if (glyph >= 0 && glyph < MAX_GLYPH && q[glyph] < 32) {
-                       /* prefer '-' above SHY etc. */
-                       q[glyph] = j;
+static void set_inverse_translations(int m)
+{
+       int i, c, n;
+       unsigned char ***q, **p1, *p2;
+       u16 *t = translations[m];
+       u16 unicode;
+
+       clear_inverse_translations(m);
+       q = inverse_translations[m] = (unsigned char ***)
+               kmalloc(32*sizeof(unsigned char **), GFP_KERNEL);
+       if (!q) return;
+       for (i = 0; i < 32; i++)
+               q[i] = NULL;
+
+       /* The ACM may not be 1-1. In inverting it we prefer
+          lower characters over higher ones,
+          while excluding control characters (0..31, 127),
+          except that we force '\r' to be translated correctly.
+          */
+       for (c = E_TABSZ-1; c >= 0; c--) {
+               if (c < 32) {
+                       if (c == '\r')
+                               unicode = c;
+                       else
+                               continue;
+               }
+               else {
+                       if (c == 127)
+                               continue;
+                       else
+                               unicode = t[c];
+               }
+               if (!(p1 = q[n = unicode >> 11])) {
+                       p1 = q[n] = kmalloc(32*sizeof(unsigned char *), GFP_KER
NEL);
+                       if (!p1) {
+                               clear_inverse_translations(m);
+                               return;
+                       }
+                       for (i = 0; i < 32; i++)
+                               p1[i] = NULL;
+               }
+               if (!(p2 = p1[n = (unicode >> 6) & 0x1f])) {
+                       p2 = p1[n] = kmalloc(64*sizeof(unsigned char), GFP_KERN
EL);
+                       if (!p2) {
+                               clear_inverse_translations(m);
+                               return;
+                       }
+                       memset(p2, 0, 64*sizeof(unsigned char));
                }
+               p2[unicode & 0x3f] = c;
+       }
+}
+
+static void clear_inverse_map(struct uni_pagedir *p)
+{
+  if (p->inverse_map) {
+    kfree(p->inverse_map);
+    p->inverse_map = NULL;
+  }
+}
+
+static void set_inverse_map(struct uni_pagedir *p)
+{
+       int i, j, k;
+       u16 *q;
+       u16 **p1, *p2;
+       int ucs;
+
+       q = p->inverse_map;
+       if (!q) {
+               q = p->inverse_map = (u16 *)
+                       kmalloc(MAX_GLYPH*sizeof(u16), GFP_KERNEL);
+               if (!q) return;
        }
+       memset(q, 0xff, MAX_GLYPH*sizeof(u16));
+
+       /* The SFM is often not 1-1. In inverting it we prefer
+          lower characters over higher ones,
+          while excluding control characters (0..31, 127..159).
+          This has the desirable side effect that ' ' overrides
+          any other character mapped to the same glyph.
+          One might think about preferring Unicode characters that are
+          in the current ACM over ones that are not, but this couldn't
+          be implemented cleanly: we don't know what ACM will be used
+          with this SFM.
+          */
+       for (i = 31; i >= 0; i--)
+       if ((p1 = p->uni_pgdir[i]))
+               for (j = 31; j >= 0; j--)
+               if ((p2 = p1[j]))
+                       for (k = 63; k >= 0; k--)
+                       if (p2[k] < MAX_GLYPH) {
+                               ucs = (i << 11) | (j << 6) | k;
+                               if (ucs < 160 && (ucs >= 127 || ucs < 32))
+                                       continue;
+                               q[p2[k]] = ucs;
+                       }
 }

-unsigned short *set_translate(int m,int currcons)
+void set_translate(struct vc_data *conp, int m)
+{
+       conp->vc_translate = m;
+}
+
+unsigned short *get_acm(int m)
 {
-       inv_translate[currcons] = m;
        return translations[m];
 }

-/*
- * Inverse translation is impossible for several reasons:
- * 1. The font<->character maps are not 1-1.
- * 2. The text may have been written while a different translation map
- *    was active, or using Unicode.
- * Still, it is now possible to a certain extent to cut and paste non-ASCII.
- */
-unsigned char inverse_translate(struct vc_data *conp, int glyph)
+unsigned char inverse_translate(int m, int ucs)
 {
-       struct uni_pagedir *p;
-       if (glyph < 0 || glyph >= MAX_GLYPH)
+       unsigned char ***q, **p1, *p2, c;
+
+       if (ucs > 0xffff)
                return 0;
-       else if (!(p = (struct uni_pagedir *)*conp->vc_uni_pagedir_loc) ||
-                !p->inverse_translations[inv_translate[conp->vc_num]])
-               return glyph;
+
+       if ((q = inverse_translations[m]) &&
+           (p1 = q[ucs >> 11]) &&
+           (p2 = p1[(ucs >> 6) & 0x1f]) &&
+           (c = p2[ucs &0x3f]))
+               return c;
        else
-               return p->inverse_translations[inv_translate[conp->vc_num]][gly
ph];
+               return 0;
 }

-static void update_user_maps(void)
+u16 inverse_convert(struct vc_data *conp, int glyph)
 {
-       int i;
-       struct uni_pagedir *p, *q = NULL;
-
-       for (i = 0; i < MAX_NR_CONSOLES; i++) {
-               if (!vc_cons_allocated(i))
-                       continue;
-               p = (struct uni_pagedir *)*vc_cons[i].d->vc_uni_pagedir_loc;
-               if (p && p != q) {
-                       set_inverse_transl(vc_cons[i].d, p, USER_MAP);
-                       q = p;
-               }
+       struct uni_pagedir *p;
+
+       if (glyph < 0 || glyph >= MAX_GLYPH)
+               return 0xffff;
+       if (!(p = (struct uni_pagedir *)*conp->vc_uni_pagedir_loc))
+               /* This shouldn't happen! */
+               return UNI_DIRECT_BASE | glyph;
+       if (!p->inverse_map) {
+               set_inverse_map(p);
+               if (!p->inverse_map)
+                       return 0xffff;
        }
+       return p->inverse_map[glyph];
 }

 /*
@@ -270,7 +390,7 @@
                p[i] = UNI_DIRECT_BASE | uc;
        }

-       update_user_maps();
+       set_inverse_translations(USER_MAP);
        return 0;
 }

@@ -307,7 +427,7 @@
                p[i] = us;
        }

-       update_user_maps();
+       set_inverse_translations(USER_MAP);
        return 0;
 }

@@ -355,11 +475,7 @@
                }
                p->uni_pgdir[i] = NULL;
        }
-       for (i = 0; i < 4; i++)
-               if (p->inverse_translations[i]) {
-                       kfree(p->inverse_translations[i]);
-                       p->inverse_translations[i] = NULL;
-               }
+       clear_inverse_map(p);
 }

 void con_free_unimap(int con)
@@ -455,7 +571,7 @@
                        if (p) p->refcount++;
                        return -ENOMEM;
                }
-               memset(q, 0, sizeof(*q));
+               memset(q, 0, sizeof(*q)); /* makes the pointers NULL, one hopes
 */
                q->refcount=1;
                *conp->vc_uni_pagedir_loc = (unsigned long)q;
        } else {
@@ -518,9 +634,8 @@
        if (con_unify_unimap(conp, p))
                return err;

-       for (i = 0; i <= 3; i++)
-               set_inverse_transl(conp, p, i); /* Update all inverse translati
ons */
-
+       clear_inverse_map(p);
+
        return err;
 }

@@ -570,8 +685,7 @@
                return err;
        }

-       for (i = 0; i <= 3; i++)
-               set_inverse_transl(conp, p, i); /* Update all inverse translati
ons */
+       clear_inverse_map(p);
        dflt = p;
        return err;
 }
@@ -679,4 +793,6 @@
        for (i = 0; i < MAX_NR_CONSOLES; i++)
                if (vc_cons_allocated(i) && !*vc_cons[i].d->vc_uni_pagedir_loc)
                        con_set_default_unimap(i);
+       for (i = 0; i < 4; i++)
+               set_inverse_translations(i);
 }
diff -u -r v2.2.0-pre9/linux/drivers/char/keyboard.c linux/drivers/char/keyboar
d.c
--- v2.2.0-pre9/linux/drivers/char/keyboard.c   Wed Jan 20 21:17:31 1999
+++ linux/drivers/char/keyboard.c       Fri Jan 22 23:28:41 1999
@@ -41,6 +41,9 @@
 #include <linux/kbd_ll.h>
 #include <linux/sysrq.h>

+#include <linux/console_struct.h>
+#include <linux/consolemap.h>
+
 #define SIZE(x) (sizeof(x)/sizeof((x)[0]))

 #ifndef KBD_DEFMODE
@@ -137,7 +140,7 @@
 const int max_vals[] = {
        255, SIZE(func_table) - 1, SIZE(spec_fn_table) - 1, NR_PAD - 1,
        NR_DEAD - 1, 255, 3, NR_SHIFT - 1,
-       255, NR_ASCII - 1, NR_LOCK - 1, 255,
+       255, NR_ASCII - 1, 2*NR_LOCK - 1, 255,
        NR_LOCK - 1, 255
 };

@@ -155,12 +158,38 @@
 #endif

 /*
- * Many other routines do put_queue, but I think either
- * they produce ASCII, or they produce some user-assigned
- * string, and in both cases we might assume that it is
- * in utf-8 already.
+ * A note on character conversion:
+ *
+ * A keymap maps keycodes to keysyms, which, at present, are 16-bit
+ * values. If a keysym is < 0xf000 then it specifies a 16-bit Unicode
+ * character to be queued. If a keysym is >= 0xf000, then 0xf000 is
+ * subtracted to give a pair of octets, extracted by KTYP and KVAL.
+ * The KTYP is used as an index into key_handler[] to give a function
+ * which handles the KVAL. The "normal" key_handler is do_self, which
+ * treats the KVAL as an 8-bit character to be queued.
+ *
+ * When a 16-bit Unicode character is queued it is converted to UTF-8
+ * if the keyboard is in Unicode mode; otherwise it is converted to an
+ * 8-bit character using the current ACM (see consolemap.c). An 8-bit
+ * character is assumed to be in the character set defined by the
+ * current ACM, so it is queued unchanged if the keyboard is in 8-bit
+ * mode; otherwise it is converted using the inverse ACM.
+ *
+ * The handling of diacritics uses 8-bit characters, which are
+ * converted using the inverse ACM, when in Unicode mode. The strings
+ * bound to function keys are not converted, so they may already
+ * contain UTF-8. Codes entered using do_ascii() treated as 16-bit and
+ * converted to UTF-8 in Unicode mode; otherwise they are treated as
+ * 8-bit and queued unchanged.
+ *
+ * Since KTYP is not used in the case of Unicode keysyms, it is not
+ * possible to use KT_LETTER to implement CapsLock. Either use 8-bit
+ * keysyms with an appropriate ACM or use the work-around proposed in
+ * do_lock().
+ *
  */
-void to_utf8(ushort c) {
+
+static void to_utf8(ushort c) {
     if (c < 0x80)
        put_queue(c);                   /*  0*******  */
     else if (c < 0x800) {
@@ -175,6 +204,29 @@
        but we need only 16 bits here */
 }

+static void put_unicode(u16 uc)
+{
+  if (kbd->kbdmode == VC_UNICODE)
+    to_utf8(uc);
+  else if ((uc & ~0x9f) == 0 || uc == 127)
+    /* Don't translate control chars */
+    put_queue(uc);
+  else {
+    unsigned char c;
+    c = inverse_translate(vc_cons[fg_console].d->vc_translate, uc);
+    if (c) put_queue(c);
+  }
+}
+
+static void put_8bit(u8 c)
+{
+  if (kbd->kbdmode != VC_UNICODE ||
+      c < 32 || c == 127) /* Don't translate control chars */
+    put_queue(c);
+  else
+      to_utf8(get_acm(vc_cons[fg_console].d->vc_translate)[c]);
+}
+
 /*
  * Translation of escaped scancodes to keycodes.
  * This is now user-settable (for machines were it makes sense).
@@ -304,9 +356,8 @@
                            if (type != KT_SLOCK)
                              kbd->slockstate = 0;
                        } else {
-                           /* maybe only if (kbd->kbdmode == VC_UNICODE) ? */
                            if (!up_flag && !raw_mode)
-                             to_utf8(keysym);
+                             put_unicode(keysym);
                        }
                } else {
                        /* maybe beep? */
@@ -358,7 +409,7 @@
 static void enter(void)
 {
        if (diacr) {
-               put_queue(diacr);
+               put_8bit(diacr);
                diacr = 0;
        }
        put_queue(13);
@@ -545,7 +596,7 @@
                return;
        }

-       put_queue(value);
+       put_8bit(value);
 }

 #define A_GRAVE  '`'
@@ -600,7 +651,7 @@
        if (ch == ' ' || ch == d)
                return d;

-       put_queue(d);
+       put_8bit(d);
        return ch;
 }

@@ -674,7 +725,7 @@
                                return;
                }

-       put_queue(pad_chars[value]);
+       put_8bit(pad_chars[value]);
        if (value == KVAL(K_PENTER) && vc_kbd_mode(kbd, VC_CRLF))
                put_queue(10);
 }
@@ -790,7 +841,22 @@
 {
        if (up_flag || rep)
                return;
-       chg_vc_kbd_lock(kbd, value);
+
+       if (value >= NR_LOCK) {
+               /* Change the lock state and
+                  set the CapsLock LED to the new state */
+               unsigned char mask;
+
+               mask = 1 << (value -= NR_LOCK);
+               if ((kbd->lockstate ^= mask) & mask)
+                       set_vc_kbd_led(kbd, VC_CAPSLOCK);
+               else
+                       clr_vc_kbd_led(kbd, VC_CAPSLOCK);
+       }
+       else {
+               /* Just change the lock state */
+               chg_vc_kbd_lock(kbd, value);
+       }
 }

 static void do_slock(unsigned char value, char up_flag)
diff -u -r v2.2.0-pre9/linux/drivers/char/selection.c linux/drivers/char/select
ion.c
--- v2.2.0-pre9/linux/drivers/char/selection.c  Thu Sep 17 17:35:03 1998
+++ linux/drivers/char/selection.c      Fri Jan 22 23:28:41 1999
@@ -9,6 +9,8 @@
  *     'int sel_loadlut(const unsigned long arg)'
  *
  * Now that /dev/vcs exists, most of this can disappear again.
+ *
+ * Adapted for selection in Unicode by <ed...@ra...>, January 1999
  */

 #include <linux/module.h>
@@ -24,6 +26,7 @@
 #include <linux/consolemap.h>
 #include <linux/console_struct.h>
 #include <linux/selection.h>
+#include <linux/kbd_kern.h>

 #ifndef MIN
 #define MIN(a,b)       ((a) < (b) ? (a) : (b))
@@ -40,7 +43,7 @@
 static volatile int sel_start = -1;    /* cleared by clear_selection */
 static int sel_end;
 static int sel_buffer_lth = 0;
-static char *sel_buffer = NULL;
+static u16 *sel_buffer = NULL;

 /* clear_selection, highlight and highlight_pointer can be called
    from interrupt (via scrollback/front) */
@@ -57,10 +60,11 @@
        complement_pos(sel_cons, where);
 }

-static unsigned char
+static u16
 sel_pos(int n)
 {
-       return inverse_translate(vc_cons[sel_cons].d, screen_glyph(sel_cons, n)
);
+       return inverse_convert(vc_cons[sel_cons].d,
+                              screen_glyph(sel_cons, n));
 }

 /* remove the current selection highlight, if any,
@@ -89,8 +93,9 @@
   0xFF7FFFFF  /* latin-1 accented letters, not division sign */
 };

-static inline int inword(const unsigned char c) {
-       return ( inwordLut[c>>5] >> (c & 0x1F) ) & 1;
+static inline int inword(const u16 c) {
+       /* Everything over 0xff is considered alphabetic! */
+       return c >= 0x100 || ( inwordLut[c>>5] >> (c & 0x1F) ) & 1;
 }

 /* set inwordLut contents. Invoked by ioctl(). */
@@ -119,7 +124,8 @@
 int set_selection(const unsigned long arg, struct tty_struct *tty, int user)
 {
        int sel_mode, new_sel_start, new_sel_end, spc;
-       char *bp, *obp;
+       u16 *bp, *obp;
+       u16 ucs;
        int i, ps, pe;
        unsigned int currcons = fg_console;

@@ -259,7 +265,7 @@
        sel_end = new_sel_end;

        /* Allocate a new buffer before freeing the old one ... */
-       bp = kmalloc((sel_end-sel_start)/2+1, GFP_KERNEL);
+       bp = kmalloc(((sel_end-sel_start)/2+1)*sizeof(u16), GFP_KERNEL);
        if (!bp) {
                printk(KERN_WARNING "selection: kmalloc() failed\n");
                clear_selection();
@@ -271,8 +277,9 @@

        obp = bp;
        for (i = sel_start; i <= sel_end; i += 2) {
-               *bp = sel_pos(i);
-               if (!isspace(*bp++))
+               ucs = sel_pos(i);
+               *bp++ = ucs;
+               if (!isspace(ucs))
                        obp = bp;
                if (! ((i + 2) % video_size_row)) {
                        /* strip trailing blanks from line and add newline,
@@ -294,25 +301,80 @@
  */
 int paste_selection(struct tty_struct *tty)
 {
+       int utf;
+       unsigned char *paste_buffer, *bp, *p;
        struct vt_struct *vt = (struct vt_struct *) tty->driver_data;
-       int     pasted = 0, count;
+       int count;
        struct wait_queue wait = { current, NULL };

+       if (!sel_buffer || !sel_buffer_lth) return 0;
+
+       /* Paste UTF-8 iff the keyboard is in UTF-8 mode */
+       utf = (kbd_table[fg_console].kbdmode == VC_UNICODE);
+
+       /* Make a paste buffer containing an appropriate translation
+          of the selection buffer */
+       paste_buffer = kmalloc(utf ? sel_buffer_lth*3 : sel_buffer_lth, GFP_KER
NEL);
+       if (!paste_buffer) {
+               printk(KERN_WARNING "selection: kmalloc() failed\n");
+               return -ENOMEM;
+       }
+
+       bp = paste_buffer;
+       if (utf) {
+               /* convert to UTF-8 */
+               int i, ucs;
+
+               for (i = 0; i < sel_buffer_lth; i++) {
+                       ucs = sel_buffer[i];
+                       /* The following code should at some point
+                          be merged with to_utf8() in keyboard.c */
+                       if (!(ucs & ~0x7f)) /* 0?????? */
+                               *bp++ = ucs;
+                       else if (!(ucs & ~0x7ff)) { /* 110????? 10?????? */
+                               *bp++ = 0xc0 | (ucs >> 6);
+                               *bp++ = 0x80 | (ucs & 0x3f);
+                       }
+                       else { /*  1110???? 10?????? 10?????? */
+                               *bp++ = 0xe0 | (ucs >> 12);
+                               *bp++ = 0x80 | ((ucs >> 6) & 0x3f);
+                               *bp++ = 0x80 | (ucs & 0x3f);
+                       }
+                       /* UTF-8 is defined for words of up to 31 bits,
+                          but we need only 16 bits here */
+               }
+       }
+       else {
+               /* convert to 8-bit */
+               int inv_translate = vc_cons[fg_console].d->vc_translate;
+               int i;
+               unsigned char c;
+
+               for (i = 0; i < sel_buffer_lth; i++) {
+                       c = inverse_translate(inv_translate, sel_buffer[i]);
+                       if (c) *bp++ = c;
+               }
+       }
+
        poke_blanked_console();
        add_wait_queue(&vt->paste_wait, &wait);
-       while (sel_buffer && sel_buffer_lth > pasted) {
+       p = paste_buffer;
+       while (bp > p) {
                current->state = TASK_INTERRUPTIBLE;
                if (test_bit(TTY_THROTTLED, &tty->flags)) {
                        schedule();
                        continue;
                }
-               count = sel_buffer_lth - pasted;
+               count = bp - p;
                count = MIN(count, tty->ldisc.receive_room(tty));
-               tty->ldisc.receive_buf(tty, sel_buffer + pasted, 0, count);
-               pasted += count;
+               tty->ldisc.receive_buf(tty, p, 0, count);
+               p += count;
        }
        remove_wait_queue(&vt->paste_wait, &wait);
        current->state = TASK_RUNNING;
+
+       kfree(paste_buffer);
+
        return 0;
 }

diff -u -r v2.2.0-pre9/linux/drivers/char/vt.c linux/drivers/char/vt.c
--- v2.2.0-pre9/linux/drivers/char/vt.c Wed Jan 20 21:17:42 1999
+++ linux/drivers/char/vt.c     Fri Jan 22 23:28:41 1999
@@ -159,11 +159,9 @@
        switch (cmd) {
        case KDGKBENT:
                key_map = key_maps[s];
-               if (key_map) {
+               if (key_map)
                    val = U(key_map[i]);
-                   if (kbd->kbdmode != VC_UNICODE && KTYP(val) >= NR_TYPES)
-                       val = K_HOLE;
-               } else
+               else
                    val = (i ? K_HOLE : K_NOSUCHMAP);
                return __put_user(val, &user_kbe->kb_value);
        case KDSKBENT:
@@ -182,12 +180,9 @@
                        break;
                }

-               if (KTYP(v) < NR_TYPES) {
-                   if (KVAL(v) > max_vals[KTYP(v)])
-                               return -EINVAL;
-               } else
-                   if (kbd->kbdmode != VC_UNICODE)
-                               return -EINVAL;
+               if ((v & 0xf000) == 0 &&
+                   (KTYP(v) >= NR_TYPES || KVAL(v) > max_vals[KTYP(v)]))
+                       return -EINVAL;

                /* ++Geert: non-PC keyboards may generate keycode zero */
 #if !defined(__mc68000__) && !defined(__powerpc__)
diff -u -r v2.2.0-pre9/linux/include/linux/console_struct.h linux/include/linux
/console_struct.h
--- v2.2.0-pre9/linux/include/linux/console_struct.h    Thu Sep 17 17:35:04 199
8
+++ linux/include/linux/console_struct.h        Fri Jan 22 23:28:41 1999
@@ -70,7 +70,7 @@
                 int    vc_utf_char;
        unsigned int    vc_tab_stop[5];         /* Tab stops. 160 columns. */
        unsigned char   vc_palette[16*3];       /* Colour palette for VGA+ */
-       unsigned short * vc_translate;
+                int    vc_translate;           /* Current ACM */
        unsigned char   vc_G0_charset;
        unsigned char   vc_G1_charset;
        unsigned char   vc_saved_G0;
diff -u -r v2.2.0-pre9/linux/include/linux/consolemap.h linux/include/linux/con
solemap.h
--- v2.2.0-pre9/linux/include/linux/consolemap.h        Wed Jan 20 21:17:09 199
9
+++ linux/include/linux/consolemap.h    Fri Jan 22 23:30:16 1999
@@ -10,6 +10,8 @@

 struct vc_data;

-extern unsigned char inverse_translate(struct vc_data *conp, int glyph);
-extern unsigned short *set_translate(int m,int currcons);
+extern unsigned short *get_acm(int m);
+extern unsigned char inverse_translate(int m, int ucs);
+extern u16 inverse_convert(struct vc_data *conp, int glyph);
+extern void set_translate(struct vc_data *conp, int m);
 extern int conv_uni_to_pc(struct vc_data *conp, long ucs);

Re: [Linuxconsole-dev] Progress on Sapphire

[James S. <jsi...@ac...>]

> > We should also patch the MAINTAINERS file, shouldn't we?
> 
> Yes, but how we do that exactly will depend on how we do our release
> packaging (which is James's problem).

The best thing to do is place these patches in CVS and announce it on 
linux-kernel so people can go test it. Have CVS with 3 top directorys for
each release. Sapphire, emrald, and ruby. Ruby is going to be the big on!
Once we get feed back and any possible bug fixes we can send it off to
linus. Perhapsa  tree like this 

CVS -> shappire -> v2.0
                -> v2.2
                -> v2.3
    -> emrald   -> v2.0 
		-> v2.2
                -> v2.3
    -> ruby     -> v2.3
                -> v2.4

I have been working on fbdev today with a few new patchs. I going to see
if I can sneak some time in to clean up the data struct stuff. Their are
three data structs for the current console system. 

struct vt_struct;
struct vc_data;
struct vc; 

struct vt_struct is whats in tty->driver_data. Their is only some code
relating to it in vt.c. Struct vc_data is everywhere for a video terminal
system. I don't see it in any serial consoel code. It is a hardware 
independent data struct that represents the state of the video terminal
device. The next data struct is vc which is this 

struct vc {
        struct vc_data *d;

        /* might add  scrmem, vt_struct, kbd  at some time,
           to have everything in one place - the disadvantage
           would be that vc_cons etc can no longer be static */
};
 
Which is really used anywhere. Just a few struct vc_data *conp =
vc_cons[con].d;

So it would look like using just vc_data and expanding it would be the
best choose I think. Any opinons?

"Look its a text editor, not its a OS, no it Emacs"
James Simmons                                           ____/| 
fbdev/gfx developer                                     \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U

Re: [Linuxconsole-dev] Progress on Sapphire

[Eric S. R. <es...@th...>]

Dominik Kubla <dom...@un...>:
> The 2.2.1 patch of mine had much more in it then just simple vt102
> related fixes (some of the control sequences are for vt220 and up).
> But i guess they can stay. So if you'll send me your version of the patch,
> i will base the 2.2 branch on that.

Enclosed.

> One question arise: should i bother to backport the 2.2 stuff to 2.0?
> Given the fact that 2.0 is still seen as somewhat more stable than
> 2.2 and that it appears to be a one-timer (since there won't be too
> many new 2.0 release).  I would say yes.

I doubt there's much extra work involved as the console driver hasn't changed
that fast.  So we might as well ship for 2.0 as well.
 
> > BTW, in the revised console_codes(4) page, I refer to the existing
> > console as `version 1'.  You and I are working on `version 2', emulation
> > patches only.  Versions 3 and up will be the big rewrite.
> 
> VT320 terminals provide a secondary and tertiary DA, which i am likely to
> implement to give the user-land an idea about the version of the console
> emulator.
> 
> Secondary DA:
> 
> Request:  CSI > 0 c
> Reply:    CSI > 41 ; Pv ; 0 c     (where Pv is the firmware revision)

OK.  To make version comparisons easier later on, I suggest we return
"200" for the first version.

> Tertiary DA:
> 
> Request:  CSI = 0 c
> Reply:    DCS ! | D...D ST        (where D...D is the device id)
> 
> Haven figured out a use for the tertiary DA yet.  Using the hostid
> as device id has the same implications as the Unique Processor ID
> of Pentium III cpus (ignoring the fact that hostid is in widespread
> use in the Unix world)

I think I'd stay away from that.

This reminds me.  What do your canned responses to the Keyboard Status, 
Data Integrity check, and DECREQTPARM actually mean?   I want to mention this
in the man page.  (I was able to find docs on the printer and UDK status).
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

As with the Christian religion, the worst advertisement for Socialism
is its adherents.
	-- George Orwell 

Re: [Linuxconsole-dev] Which tree and developers

[Dominik K. <dom...@un...>]

On Wed, Mar 08, 2000 at 11:03:42AM -0500, James Simmons wrote:
> P.S
> 
>   Vojtech I tried your patch against 2.3.50-3. It bomded. I was wondering
> if you updated it already so we don't duplicate effort here. 

Working on it... But right now i have to check my defences: some cracker
scanned our University and i have to make sure my external systems are
secured.

Dominik
-- 
  Networking Group,  Hospital of Johannes Gutenberg-University                  
  Obere Zahlbacher Straße 69, 55101 Mainz, Germany                              
  Tel: +49 (0)6131 17-2482   FAX: +49 (0)6131 17-5521                           

Re: [Linuxconsole-dev] Which tree and developers

[James S. <jsi...@ac...>]

On Wed, 8 Mar 2000, Dominik Kubla wrote:

> On Tue, Mar 07, 2000 at 07:54:08PM -0500, James Simmons wrote:
> ...
> > Thinking about creating a console directory for now and a diff against
> > various kernel versions. Opinions?
> 
> Just what i wanted to propose.  Another note regarding coding style:

Thats solved. 

> All _exported_ functions and variables need to have constant name prefix.
> I propose the following:
> 
>    con_      console device             (already used for this)
>    kb_       keyboard driver
>    vt_       virtual terminal handling  (already used for this)
>    vte_      video terminal emulation

Looks good. Should we go with vt_ or vc_ since in theory you could have
virtual consoles on serial consoles as well?  Or have virtual terminal
handling only for video terminals. I also assume this is for now. the
"ruby" series will different for kb_ since this will be intergrated with
Vojtech's work.   


P.S

  Vojtech I tried your patch against 2.3.50-3. It bomded. I was wondering
if you updated it already so we don't duplicate effort here. 

"Look it's a text editor, not it's a OS, no it's Emacs"
James Simmons                                           ____/| 
fbdev/gfx developer                                     \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U

Re: [Linuxconsole-dev] Progress on Sapphire

[Dominik K. <dom...@un...>]

On Wed, Mar 08, 2000 at 05:50:43AM -0500, Eric S. Raymond wrote:

> How will this differ from the 2.2.12 patch I just generated?  We may be
> unnecessarily duplicating work here...

The 2.2.1 patch of mine had much more in it then just simple vt102
related fixes (some of the control sequences are for vt220 and up).
But i guess they can stay. So if you'll send me your version of the patch,
i will base the 2.2 branch on that.

One question arise: should i bother to backport the 2.2 stuff to 2.0?
Given the fact that 2.0 is still seen as somewhat more stable than
2.2 and that it appears to be a one-timer (since there won't be too
many new 2.0 release).  I would say yes.

> BTW, in the revised console_codes(4) page, I refer to the existing
> console as `version 1'.  You and I are working on `version 2', emulation
> patches only.  Versions 3 and up will be the big rewrite.

VT320 terminals provide a secondary and tertiary DA, which i am likely to
implement to give the user-land an idea about the version of the console
emulator.

Secondary DA:

Request:  CSI > 0 c
Reply:    CSI > 41 ; Pv ; 0 c     (where Pv is the firmware revision)

Tertiary DA:

Request:  CSI = 0 c
Reply:    DCS ! | D...D ST        (where D...D is the device id)

Haven figured out a use for the tertiary DA yet.  Using the hostid
as device id has the same implications as the Unique Processor ID
of Pentium III cpus (ignoring the fact that hostid is in widespread
use in the Unix world)

Comments?
  Dominik
-- 
  Networking Group,  Hospital of Johannes Gutenberg-University                  
  Obere Zahlbacher Straße 69, 55101 Mainz, Germany                              
  Tel: +49 (0)6131 17-2482   FAX: +49 (0)6131 17-5521                           

Re: [Linuxconsole-dev] Progress on Sapphire

[Eric S. R. <es...@th...>]

Dominik Kubla <dom...@un...>:
> > Dominik, am I correct in believing these are all of the functional
> > changes in the emulation?
> 
> Looks like it. BTW i would prefer that you use the correct CSI instead
> of \E[, because \E[ is only the 7bit translation of the correct C1 control
> code.  Of coures you would have to define the term "Control Sequence
> Introducer" before using it.  And the page should mention how a valid
> ESCape and control has to look like.

console_codes(4) already covers this.  I'll make sure I conform.

> > And, if I have it right, you didn't mess with anything that was
> > 
> > (a) before the comment "VT102 emulator"
> > (b) after the end of do_con_trol (except for the ESnormal->ESinit
> > change in do_con_write). 
> 
> I think so, but i am not sure. I am just working on a 2.2.14 patch...

How will this differ from the 2.2.12 patch I just generated?  We may be
unnecessarily duplicating work here...
 
> We should also patch the MAINTAINERS file, shouldn't we?

Yes, but how we do that exactly will depend on how we do our release
packaging (which is James's problem).

BTW, in the revised console_codes(4) page, I refer to the existing
console as `version 1'.  You and I are working on `version 2', emulation
patches only.  Versions 3 and up will be the big rewrite.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Morality is always the product of terror; its chains and
strait-waistcoats are fashioned by those who dare not trust others,
because they dare not trust themselves, to walk in liberty.
	-- Aldous Huxley 

[Linuxconsole-dev] Re: Localization of Linux

[Dominik K. <dom...@un...>]

On Wed, Jan 05, 2000 at 07:29:01PM +0530, Santhosh Kumar M [CEC-S] wrote:
> 
> Greetings,
> 
> 	I am planning to localize linux for Indian language. Can anyone
> guide me how to go about do the same.
> 
> 	Indian language is not support in the ISO-8859 series
> (ISO-8859-12 is reserved for Indian language). Unicode supports Indian
> language (Range U+0900 to U+097f).
> 

Hi Santhosh,

a group of kernel developers has just started a complete overhaul of
the linux console code.  If you are interested to participate then 
your input would be welcome.  Further information is available at:

    http://linuxconsole.sourceforge.net 

And there is also an mailing-list for the coordination and discussion
of the development effort:

    http://sourceforge.net/mail/?group_id=3063

Yours,
  Dominik Kubla
-- 
  Networking Group,  Hospital of Johannes Gutenberg-University                  
  Obere Zahlbacher Straße 69, 55101 Mainz, Germany                              
  Tel: +49 (0)6131 17-2482   FAX: +49 (0)6131 17-5521                           

Re: [Linuxconsole-dev] Progress on Sapphire

[Dominik K. <dom...@un...>]

On Wed, Mar 08, 2000 at 04:38:31AM -0500, Eric S. Raymond wrote:
> OK.  I think I have a minimal patch, equivalent to Dominik's 2.2.1
> patch, that works on the 2.2.12 console.c.  This is a candidate for
> Sapphire 1, but it's not tested yet; I should probably sleep before I
> try rebuilding my kernel ;-).
> 
> Dominik, am I correct in believing these are all of the functional
> changes in the emulation?
> 
> \E[6m	blink		added
> \E[21m	turn off 1	removed
> 0x84	IND		added 
> 0x85	NEL		added
> 0x88	HTS		added
> 0x8d	RI		added
> \E[?6n	DECXCPR		added
> \E[?15n	Printer status	added
> \E[?25n	UDK status	added
> \E[?26n	Keyboard status	added
> \E[?75n	Data integrity	added
> \E[x	DECREQTPARM	added
> \E[ n k	VPB		added
> \E[ n j	HPB		added
> \E[ n I	CHT		added
> \E[ n W	CTC		added (n=0, 2, 5)
> \E[ n Y	CVT		added
> \E[ n Z	CBT		added
> \E[s	DECRC		removed
> \E[u	DECSC		removed

Looks like it. BTW i would prefer that you use the correct CSI instead
of \E[, because \E[ is only the 7bit translation of the correct C1 control
code.  Of coures you would have to define the term "Control Sequence
Introducer" before using it.  And the page should mention how a valid
ESCape and control has to look like.  See the following references:

   ECMA-35 (ISO 2022), Section 13, "Structure and use of escape sequences"
   ECMA-48 (ISO 6429), Section 5.4, "Control sequences"

> And, if I have it right, you didn't mess with anything that was
> 
> (a) before the comment "VT102 emulator"
> (b) after the end of do_con_trol (except for the ESnormal->ESinit
> change in do_con_write). 

I think so, but i am not sure. I am just working on a 2.2.14 patch...

> If so, then I have reduced the patch from 99K to 18K.  I think this 
> makes it rather more likely to be accepted :-).

We should also patch the MAINTAINERS file, shouldn't we?

Dominik
-- 
  Networking Group,  Hospital of Johannes Gutenberg-University                  
  Obere Zahlbacher Straße 69, 55101 Mainz, Germany                              
  Tel: +49 (0)6131 17-2482   FAX: +49 (0)6131 17-5521                           

[Linuxconsole-dev] It builds...

[Eric S. R. <es...@sn...>]

Sapphire 1 builds into a 2.2.12 kernel without errors, but I'm going
to get some sleep before I try actually testing this puppy.  Good night, all.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The possession of arms by the people is the ultimate warrant
that government governs only with the consent of the governed.
        -- Jeff Snyder

[Linuxconsole-dev] Progress on Sapphire

[Eric S. R. <es...@sn...>]

OK.  I think I have a minimal patch, equivalent to Dominik's 2.2.1
patch, that works on the 2.2.12 console.c.  This is a candidate for
Sapphire 1, but it's not tested yet; I should probably sleep before I
try rebuilding my kernel ;-).

Dominik, am I correct in believing these are all of the functional
changes in the emulation?

\E[6m	blink		added
\E[21m	turn off 1	removed
0x84	IND		added
0x85	NEL		added
0x88	HTS		added
0x8d	RI		added
\E[?6n	DECXCPR		added
\E[?15n	Printer status	added
\E[?25n	UDK status	added
\E[?26n	Keyboard status	added
\E[?75n	Data integrity	added
\E[x	DECREQTPARM	added
\E[ n k	VPB		added
\E[ n j	HPB		added
\E[ n I	CHT		added
\E[ n W	CTC		added (n=0, 2, 5)
\E[ n Y	CVT		added
\E[ n Z	CBT		added
\E[s	DECRC		removed
\E[u	DECSC		removed

And, if I have it right, you didn't mess with anything that was

(a) before the comment "VT102 emulator"
(b) after the end of do_con_trol (except for the ESnormal->ESinit
change in do_con_write). 

If so, then I have reduced the patch from 99K to 18K.  I think this 
makes it rather more likely to be accepted :-).
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Good intentions will always be pleaded for every assumption of
authority. It is hardly too strong to say that the Constitution was
made to guard the people against the dangers of good intentions. There
are men in all ages who mean to govern well, but they mean to
govern. They promise to be good masters, but they mean to be masters.
	-- Daniel Webster

Re: [Linuxconsole-dev] Which tree and developers

[Eric S. R. <es...@th...>]

Dominik Kubla <dom...@un...>:
> On Wed, Mar 08, 2000 at 03:19:33AM -0500, Eric S. Raymond wrote:
> 
> > By "a programmers reference manual for the terminal emulation", do you mean a 
> > description of the supported escape sequences?
> 
> With annotations regarding recommended use and implementation specifics. 
> Just like the respective DEC manuals, but i think we can skip the users
> manual ;-)
> 
> Oh, i see!  That's what console_codes(4) already does ...

Yes, asnd I've almost finished tabulating the changes in your 2.2.1 patch.

> Got any pointers on what he is using?

No, but you could ask him.  He doesn't bite :-).
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

...Virtually never are murderers the ordinary, law-abiding people
against whom gun bans are aimed.  Almost without exception, murderers
are extreme aberrants with lifelong histories of crime, substance
abuse, psychopathology, mental retardation and/or irrational violence
against those around them, as well as other hazardous behavior, e.g.,
automobile and gun accidents."
        -- Don B. Kates, writing on statistical patterns in gun crime

Re: [Linuxconsole-dev] Which tree and developers

[Dominik K. <dom...@un...>]

On Wed, Mar 08, 2000 at 03:19:33AM -0500, Eric S. Raymond wrote:

> By "a programmers reference manual for the terminal emulation", do you mean a 
> description of the supported escape sequences?

With annotations regarding recommended use and implementation specifics. 
Just like the respective DEC manuals, but i think we can skip the users
manual ;-)

Oh, i see!  That's what console_codes(4) already does ...

> > I recall Linus being less appreciative of the idea of using embedded docs
> > and automatic tools to generate man pages, but that might have changed since
> > it was mentionend the last time...
> 
> I believe Alan Cox is pushing some tools for doing this.

Got any pointers on what he is using?

Dominik
-- 
  Networking Group,  Hospital of Johannes Gutenberg-University                  
  Obere Zahlbacher Straße 69, 55101 Mainz, Germany                              
  Tel: +49 (0)6131 17-2482   FAX: +49 (0)6131 17-5521                           

Re: [Linuxconsole-dev] Which tree and developers

[Eric S. R. <es...@th...>]

Dominik Kubla <dom...@un...>:
> I will most definitely contribute the beginnings of a programmers reference
> manual for the terminal emulation.  And since i intend to document all changes
> in the kernel code, we could start with section 9 again, if we were so inclined.

By "a programmers reference manual for the terminal emulation", do you mean a 
description of the supported escape sequences?
 
> I recall Linus being less appreciative of the idea of using embedded docs
> and automatic tools to generate man pages, but that might have changed since
> it was mentionend the last time...

I believe Alan Cox is pushing some tools for doing this.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

See, when the GOVERNMENT spends money, it creates jobs; whereas when the money
is left in the hands of TAXPAYERS, God only knows what they do with it.  Bake
it into pies, probably.  Anything to avoid creating jobs.
	-- Dave Barry

Re: [Linuxconsole-dev] Which tree and developers

[Dominik K. <dom...@un...>]

On Wed, Mar 08, 2000 at 02:46:03AM -0500, Eric S. Raymond wrote:
...
> Nroff should be fine for this application.   Anyway, the only documentation
> change I was immediately planning was an update to console_codes(4).

I will most definitely contribute the beginnings of a programmers reference
manual for the terminal emulation.  And since i intend to document all changes
in the kernel code, we could start with section 9 again, if we were so inclined.

I recall Linus being less appreciative of the idea of using embedded docs
and automatic tools to generate man pages, but that might have changed since
it was mentionend the last time...

Dominik
-- 
  Networking Group,  Hospital of Johannes Gutenberg-University                  
  Obere Zahlbacher Straße 69, 55101 Mainz, Germany                              
  Tel: +49 (0)6131 17-2482   FAX: +49 (0)6131 17-5521                           

Re: [Linuxconsole-dev] Which tree and developers

[Eric S. R. <es...@th...>]

Dominik Kubla <dom...@un...>:
> All _exported_ functions and variables need to have constant name prefix.
> I propose the following:
> 
>    con_      console device             (already used for this)
>    kb_       keyboard driver
>    vt_       virtual terminal handling  (already used for this)
>    vte_      video terminal emulation
> 
> Comments? 

Good idea.
 
> Eric, what format should we use for the docs? Plain text? Nroff? I would
> discount TeX and SGML because people can not be expected to have these
> tools installed, even so one could use a SGML subset and sed/awk scripts
> to convert them to text.  Since man pages are already written in nroff
> and nroff is generating decent printer output (and since it's the Unix
> standard way of delivering documents anyway), i would propose to use nroff
> for the other docs to be included into the kernel as well.  And i recall
> you are well versed in nroff anyway... ;-)

Nroff should be fine for this application.   Anyway, the only documentation
change I was immediately planning was an update to console_codes(4).
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"I hold it, that a little rebellion, now and then, is a good thing, and as 
necessary in the political world as storms in the physical."
	-- Thomas Jefferson, Letter to James Madison, January 30, 1787