Subject: Re: Wskeyboard mappings
To: Reinoud Zandijk <email@example.com>
From: Juergen Hannken-Illjes <firstname.lastname@example.org>
Date: 03/14/2001 20:37:04
> 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
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.
Juergen Hannken-Illjes - email@example.com - TU Braunschweig (Germany)