> 
> 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)

Looks ok. You get grave/not and bar/bar with alt-gr.

> > > 	- 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).

Depending on your map alt-w is w with bit 8 set to 1.
Without an alt-gr (usually the right alt) you cannot get more than two
characters (normal/shifted) per key. You need something like

  KC(xxx), KS_Mode_switch, ...

in your map.

> > 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 ?)

You need alt-gr instead of alt.

> > > 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 ?

That is the current implementation. It doesn't consume much space, since nearly
all maps are overlays of a generic map.

We have us: `KC(3), KS_2, KS_at,' and
	uk: `KC(3), KS_2, KS_quotedbl, KS_twosuperior, KS_cent,'

While looking at wskbdmap_mfii.c pckbd_keydesc_uk uses alt-gr entries but doesn't
have a alt-gr key. This is an error.
> Cheers,
> Reinoud
> 
> 


-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)