Re: [9fans] kbd.c

[George Bronnikov <goga@rubinstein.mccme.ru>]

On Mon, 1 Apr 2002, Boyd Roberts wrote:

> caps lock is caps lock -- it should not be overloaded.

Well the key itself is overloaded as another Ctrl in the default keymap.
Moreover, I was not happy with the code for handling it -- it only worked
for symbols between 'a' and 'z'.

That said, of course my code was a hack on top of your hack, to let
me work in my own language with minimal effort.  I think what we need is:

1. Some key that can act as a sticky modifier -- that's why the current
kbd.c is inappropriate.  I like the idea of ^t^t n.

2. Some way to change keymaps on the fly.  This is why I'm not so fond of
Nemo's solution -- I don't want to recompile the kernel each time I need
another keymap.  Moreover, I don't want to write code in C each time I
need to define a keymap (did I misunderstand his proposal?).

3. I don't like the idea of having a builtin English qwerty and
making translations in userspace -- what's so special about qwerty?  What
shall we do with keyboards that have more keys than the standard English
one (like Japanese, if I correctly understand Kenji)?

On the other hand, userspace solution is more flexible, if only we can get
the raw input, something like keycodes, from the kernel.  But then again,
we would need to imitate not just /dev/cons but also /dev/consctl --
another complexity.

In the end, my vote goes to a version with /dev/kbmap+^t^t n to change
maps, an arbitrary number of them.  The /dev/kbmap protocol needs to be
extended a little to reflect multiple maps.

	Goga