Re: [AD] From AL: Dead keys in allegro/mandrake

[Elias Pschernig <elias@xxxxxxxxxx>]

On Fri, 2004-06-04 at 22:15, Christer Sandberg wrote:
> Thanks Julien and Elias for explanations. 
> (I thought that `_xwin_keydrv_handler' was the callback from X (because:
> /*Keyboard "interrupt" handler*/), and I still don't understand which
> magic forces that calls it, but it's obvious that
> `_xwin_private_process_event' is lower down, it gets all key presses)
> 

It looks like this:

(*_xwin_keyboard_interrupt) -> xkeybd.c:_xwin_keydrv_handler
xwin.c:_xwin_private_process_event (only if the key is known, it gets passed on)
xwin.c:_xwin_private_handle_input
xwin.c:_xwin_handle_input
xsystem.c:_xwin_bg_handler (called at regular intervalls ("interrupt"),
either by running in a thread, or with signals)

> If I understand it right there are two mappings, one from keycode to
> symbolcode and another from symbolcode to scancode. These are used to
> set up a direct mapping from keycode to scancode, i.e. 
> key_to_scan[i] = sym_to_scan[key_to_sym[i]] 
> This is done in `_xwin_private_init_keyboard_tables' where available
> keycodes are fetched from X as well as their mapping to symbolcodes.
> However the mapping from symbolcodes to scancodes are set up as a static
> mapping (exept from the xkeymap overloading capability). For different
> language settings in X, there might be conflicts between some symbolkeys
> (they need to map to different scancodes defpending on the setting), is
> that right?
> 

I think so. Much more complicated than it should be.

Allegro uses a table (xwin.keycode_to_scancode) to map *X keycodes* to
*Allegro PC HW scancodes*.

The initial mapping is generated with _xwin_keysym_to_scancode. It is a
list of *X keysyms* to *Allegro PC HW scancodes*. If a match is found,
an entry in the above table is added (with the corresponding *X
keycode*).

Additionally, the [xkeymap] config section is used to map *K keycodes*
(not keysyms this time) to *Allegro PC HW scancodes* - they are also
added to the above table.

Now, we leave X11, and those Allegro PC HW scancodes are passed on to
the DOS/windows keyboard handling, which does another mapping from
scancodes to Allegros KEY_* codes, and those are used to get the
ASCII/Unicode symbols (which X11 gave us right away..) by using
Allegro's incomplete keyboard localization tables.

> As you mentioned, there are some missing entries in the table. The
> attached patch fixes some of the problems with the US keyboard,
> specially the alt-gr key works. Two keys are still dead, because I don't
> know thier Allegro names (which is needed to generate codes from
> xkeymap, which in turn is needed to know what to put in the table). I
> also added some entries for Swedish keybord. I would be fine if at least
> people with French and German keybords could verify that nothing has
> gone worse.
> 

Well, it's hard to go worse with a German keyboard. But I wonder if you
can change the XK_minus setting. It will now possibly change a key for
someone which has worked before. The additional entries probably don't
matter (as long as two XK_* keysyms can't have the same value, at
least). Actually, if we are going to leave the X11 keyboard driver as it
is, we should probably have as many XK_* keysyms in there as possible.

I'm actually wondering now what the X11 keycodes are. They seem to have
a similiar function than PC HW codes - i.e. they don't change with
localization. Maybe they could be used for a direct mapping somehow?
Only an X11 expert would know.

> Someone that knows if it is likely to work in most cases if distributing
> the xkeymap definitions with an app.? (across various Linux distros)

They should work mostly, as long as the mapping corresponds to the same
Allegro mapping. E.g. de.cfg contains:

key25 = 122 (means: KEY_Y = 'z')
key26 = 121 (means: KEY_Z = 'y')

Consequently, in my [xkeymap], I need:

keycode29 = 0x15 (means: X11 keycode 29 is PC scancode for key Z)
keycode52 = 0x2C (means: X11 keycode 52 is PC scancode for key Y)

(At the same time, keycode 29 produces XK_y, and keycode 52 produces
KX_z already.)

In any case, it would make sense to distribute premade [xkeymap]
sections inside the <language>.cfg files, and read those automatically.
I'm just not sure what to do about different German mappings (Allegro
only has one, X11 has like 20). But they only differ in minor things, so
it would in any case improve things a lot (some things like Windows keys
might still be broken, but at least all major keys like Y/Z would work.

-- 
Elias Pschernig <elias@xxxxxxxxxx>