Subject: Re: new console driver code
To: None <email@example.com>
From: Ty Sarna <firstname.lastname@example.org>
Date: 03/23/1998 18:06:19
In article <sp5i21y6LiYE411FQa@zelux6> you write:
> A keymap per virtual terminal... interesting idea, I didn't think about it
> yet. As the code is laid out, it seems possible to implement.
> Sdrawsdvui towarishtsh (or so:-)
> Isn't that more like the ALTGR on european keyboards - something
> which changes the meaning of the keyboard completely?
> (OK, the ALTGR is not locking normally.)
I think so (but I've never uset an ALTGR keyboard). I think in this
case it makes sense for it to be locking. For European languages,
mostly the regular ASCII letters are used, and once in a while a special
one. Similar to capital letters -- mostly lowercase, once in a while
uppercase. So for those it makes sense to have the modifier be
But for the Cyrillic alphabet, one might switch back and forth (switch
to ASCII, type command to start editor, switch to cyrillic, write
message and save, switch back), but there will be long blocks of one
alphabet and then the other, so I think a locking modifier makes more
sense. One wouldn't switch on a letter-by-letter basis.
(Hmm, just realizes emacs will be a pain in such a system... control
keys will work OK, but commands that use Meta-<letter> or ^X-<letter>
will require a shift. Fortunately those are less common...)
> Perhaps it would be acceptable to switch the complete keymap
> when a special key is pressed (eg F1 -- ever used ChiWriter)?
That would be pretty much the same thing from the user's perspective, I
think. Sounds like a good idea.
Maybe there should just be 'N' keboard map slots (needn't be to many...
maybe 4 or 8), and each vt can just have a current keymap slot number,
rather than loading the complete keymap. Then allow keys to be defined
that switch the current vt to the Nth keymap slot. Should be easier to
implement and allow sharing without so much work.