[9fans] keymaps question. would this be acceptable for you all?

[9fans] keymaps question. would this be acceptable for you all?

[Fco.J.Ballesteros]

Since the plan is translating some runes to other ones within
the user level keyboard driver, I'd need both to

1. change the kernel driver to supply alt/altgr as regular keys before
each key they modify.

2. change the format of the keymaps to be
	rune in us kbd -> rune in desdired map.

This means that all our kbd_xx.c would become obsolete, and we'd
need to build other tables. That's the cons, the pro is that we would
start using the distributed kernel driver, as is (Of course assuming
that it's acceptable to dismantle alt processing in it).

As a side note, it'd be fairly easy to build these tables, since they're
using keys and not keycodes. IMHO this removes also the need for
dynamic maps.

Let me know, because I'm already all set and it wouldn't be worth to
make the change if it doesn't remove all alternate keyboard drivers.

Re: [9fans] keymaps question. would this be acceptable for you all?

[Boyd Roberts]

what was ever wrong with forthsyth's /dev/kbmap stuff?

(well i can think of one or things, but there's not much he he can do about
it)

it's the one thing lunix gets right: very early on it asks you
where you are, what you're typing on and who's the leader
of the opposition ...

Re: [9fans] keymaps question. would this be acceptable for you all?

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

The problem is that you need your own keymap setup at
boot(8) time, or you'll have problems typing your password
(unless your password is a naive one that stays the same
no matter the keyboard used). Remember, there's no fs
where to get the keymap from, but you still need that map.

In fact, what I'm proposing is to `move' kbmap (and a couples of
fixed tables) out of the kernel, into the user-level keyboard
driver that can be started by boot. The tables used by such
driver are similar to those of /dev/kmap: go from this rune to this
other rune.

As an extra benefit, we could get rid of the kernel code for devkbmap,
static keymaps, and compose.

Is there anything I'm missing?

[-- Attachment #2: Type: message/rfc822, Size: 2113 bytes --]

From: Boyd Roberts <boyd@insultant.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] keymaps question. would this be acceptable for you all?
Date: Wed, 12 Nov 2003 11:13:57 GMT
Message-ID: <3fb20a7e$0$13405$79c14f64@nan-newsreader-03.noos.net>

what was ever wrong with forthsyth's /dev/kbmap stuff?

(well i can think of one or things, but there's not much he he can do about
it)

it's the one thing lunix gets right: very early on it asks you
where you are, what you're typing on and who's the leader
of the opposition ...

Re: [9fans] keymaps question. would this be acceptable for you all?

[boyd, rounin]

> As an extra benefit, we could get rid of the kernel code for devkbmap,
> static keymaps, and compose.

it was never really static.  you just loaded the one you wanted.

you need various 'compose' shifts.

Re: [9fans] keymaps question. would this be acceptable for you all?

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

The one used while boot(8)ing was static (we're using the spanish layout).
The only compose shifts I need to detect are alt and altgr (left alt, right alt on us).
Since we get rid of compose in the kernel, I can simply put the key 'Alt'/AltGr before
any key being kbdputc for the user driver to know. Regarding shift and control, the
user driver already gets keys for shift-a control-a.

is there any other thing I'm missing?
thanks for your reply.


[-- Attachment #2: Type: message/rfc822, Size: 2182 bytes --]

From: "boyd, rounin" <boyd@insultant.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] keymaps question. would this be acceptable for you all?
Date: Wed, 12 Nov 2003 12:39:50 +0100
Message-ID: <011801c3a911$af3db1a0$b9844051@insultant.net>

> As an extra benefit, we could get rid of the kernel code for devkbmap,
> static keymaps, and compose.

it was never really static.  you just loaded the one you wanted.

you need various 'compose' shifts.

Re: [9fans] keymaps question. would this be acceptable for you all?

[boyd, rounin]

> Regarding shift and control, the user driver already gets keys for shift-a
control-a.

you are assuming where 'a' is.  the scan codes [song] remain[s]  the same.

> is there any other thing I'm missing?

this not a simple problem.  so you want to default to some minimal
subset.  the keyboard is a nightmare.  i would propose some simple
gui-ish thing that used a ps2 style mosue, but then we are in vga hell.

so back up a bit.  if you can see what you're typing then you can correct
and let's _assume_ BS is where it should be or at that point BS and DEL
blow away chars.  so, no gui and using top level domains [two chars]
will give you a keyboard map, in general.

from there you can type.  all the world's not a QWERTY (sic) ...

Re: [9fans] keymaps question. would this be acceptable for you all?

[Fco.J.Ballesteros]

>> Regarding shift and control, the user driver already gets keys for shift-a
> control-a.
>
> you are assuming where 'a' is.  the scan codes [song] remain[s]  the same.

No. Ctrl+[what would be a in the us] is reported as ctrl-a by the kernel.
If your keyboard says it should be ctrl-x, you remap it. But the still get the ctrl
reported.

What I try to say is that the maps no longer use scan codes. They use runes
(or control runes).