Hi Juergen,

On Wed, 14 Mar 2001, Juergen Hannken-Illjes wrote:
> > 	- It doenst seem to be posible to place the mathimatical `not' on
> > the key next to the `1' together with the agauche (spelling?) and the bar.
>
> Please explain what characters are on this key (normal, shifted,
> alt-gr, shift alt-gr).

My current keyboard line is :
keyc    normal    shift       alt-gr
KC(14),	KS_grave, KS_notsign, KS_bar

(just changed soms stuff so i cant check if this is now correct, but it
should be)


> > 	- I noticed that the wskbd driver just assumes every keyboard to
> > return XT keycodes in its maps !
>
> Depends on the map. sys/dev/pckbc/wskbdmap_mfii.c is built around XT
> scancodes.

yeah .... thats the one i modelled after indeed; my point is really that
it would IMHO be nicer to seperate keyboard-layout from keyboard-protocol.

> > 	- Some characters like o^, a" etc seem bolted somewhere in a table
> > instead of the keyboard mapping tables.
>
> This is a compose table to be used if your keyboard is missing some
> characters. If your keyboard has for example Aumlaut, you don't need
> <Compose A ">.

AFAIK i dont have a compose in my keyboard mapping; Still alt-w gives some
composed char (not behind the keyboard now so i cant type it in and check
it).

> While the input is a more or less abstract scancode (Just numbers) the
> MI output is already close to 16-bit unicode.

Wich is a good sign indeed ! :)

> > 2) Extend the keyboard mapping in a way to include all keyboard >
> ``weed'' apart from the obvious `Compose' and toupper() functionality.
> In > this way the a^, a`, a' as well as the `not' can be placed at
> arbitrary > positions on the keyboard.
>
> Doesn't work, because no keyboard has enough spare keys for all these
> characters.

Euhm.... i was more refering to say the specific modelling of <alt>w to be
say ... A" and/or to have <alt>E produce Euro... (is it somewhere else ?)

> > The reasons for me to make a fuzz of it is that the current tables seem to
> > have both a translation role (keyboard codes->key codes) as well as its
> > behaviour (i.e. shift 4 is $)
>
> If shift-4 is not $, either your keyboard or the map file are wrong.

Esp. English keyboards tend to have " above 2 :) ... so yes a keyboard
mapping but thats not my point ... my point is the the two functions the
table fullfills. Or are you suggesting to have #k * #p mappings? i.e. a
mapping for each layout for every keyboard protocol ?

Cheers,
Reinoud