-*- mode: outline -*-
2.4.22-std-up-alt17.imz1 (applied the three patches)

* There can be some bad cases for the keyboard kernel driver.

For the patched driver, the following states are bad (the thing that
is bad about them is that if one gets into them one will hardly be
able to type anything reasonable by the keyboard and get out):

** No ACM initialized, G0 charset is User ("ESC ( K"), kbd_mode -u, 8bit keymap
In this state, G0 maps bytes directly to screen font positions (by
0xf0NN codes). When a key is pressed and the keymap maps it to an 8bit
letter (e.g., Latin letter a), 
kernel driver translates it to a UTF sequence which corresponds to the
0xf0NN Unicode taken from the unitiialized User charset. 
So, you won't be able to type Latin letters.

Well, this is a strange case, one wouldn't usually get into it because
the initial G0 charset is the default (ISO 8859-1 mapping) ("ESC (B"), 
one won't usually change it to User without loading an ACM.

The conversion sequence is like this:

1. keymap: 0xf0NN (8bit code stored in the keymap as private Unicode
   value; type: Letter). 

2. put_8bit: 0xNN

3. acm: 0xNN -> 0xf0MM (from the default direct user map)

4. to_utf8: 0xf0MM -> 0xYY 0xYY 0xYY

5. put to the console.

*** Test:
boot with no ACM, a keymap with 8bit values should be there
(probably, the default one can be used)
echo -ne '\E(K', kbd_mode -u

press a, w etc. You will see strange 3 character sequences as the output.

*** Possible semi-solutions:

1. Always treat 0xNN < 0x80 as Latin letters in put_8bit; so, convert
   them to the same Unicode values and output.

2. Try to get help from the SFM, if we get 0xf0MM from the ACM:
   inverse-sfm: 0xMM -> U; to_utf8: U -> ...

3. do not output anything if we got 0xf0MM from the ACM.

I do not like any of them because they are not perfect. The described
situation is quite strange to require a solution: the conversion of an
8bit code to Unicode can not be perfect, because different consoles
might have different ACMs associated with them, but we expect a key
generate a definite single UTF sequence.

The best thing to do would be 
not to switch to User charset ("ESC ( K") unless one has set
an ACM -- this is a requirement not to the kernel, but to the rest of
the system. And a related issue: going into Unicode mode
(unicode_start) could force the conversion of the current keymap to
Unicode (by a pipe like: dumpkeys <some opts> | <coverter> | loadkeys).

** No ACM initialized, G0 charset is User ("ESC ( K"), kbd_mode -a, Unicode keymap

Basically, the same problem. There is no correct way to map from
Unicode to console 8bit characters because ACM is not initialized.

As a result, if one presses a key that is mapped to Unicode value
(even a Latin letter represented as Unicode), one gets nothing in the
console.

The conversion sequence is like this:

1. keymap: U -- Unicode value (for a Latin letter) stored in the keymap. 

2. put_unicode: U

3. inverse acm: U -> not def (because the image of the default user
   map is a set of direct Unicodes 0xf0NN)

4. put nothing to the console.


*** Test:
boot with no ACM, 
$ loadkeys
keycode 17 = U+006a
$ echo -ne '\E(K'
$ kbd_mode -a

press w. Nothing will be output in response.

*** Possible semi-solutions:

1. Always pass Latin letters through (as their ASCII values) in 8bit mode.

2. Try to get help from the SFM, if we get 0xf0MM from the ACM:
   sfm: U -> c; inverse-sfm: c -> m; output m

Again, I do not like any of them because they are not perfect. And the described
situation is quite strange to require a solution.

Again, the best thing to do something about this would be 
not to switch to User charset ("ESC ( K") unless one has set
an ACM -- this is a requirement not to the kernel, but to the rest of
the system. 

And a related issue: when using Unicode keymap, one should ensure one
always loads an ACM if one is working in 8bit mode; otherwise it's
nonsense to use a Unicode keymap.
