Re: [AD] keyboard recalcitrant under X

[Julien Cugniere <jcugniere@xxxxxxxxxx>]

Elias Pschernig wrote:
> A mapping from the X-codes to something else is always needed, else
> programs would be quite non-portable. Allegro just does a bad job at
> mapping X-keycodes to Allegro-keycodes.

Sorry to bother you further with this issue, but I'd really like to find a 
good solution :-o

I've looked further into the problem, and here's what I found. In xwin.c, 
there is a harcoded table _xwin_keysym_to_scancode[] that maps X keysyms to 
(I think) raw pc codes. It is used to generate the final mapping 
keycode_to_scancode[]. It contains an entry for each key of a *QWERTY* 
keyboard, identified by the keysym that this key would produce with no 
modifier active.

For keys like XK_a, this works fine, because it can be found on every 
keyboard. But other keys like XK_1 are troublesome because for example, on an 
AZERTY keyboard, there is no key that with no modifier would produce a "1". 
The corresponding key would produce XK_ampersand. So the autodection of the 
mapping fails on an AZERTY keyboard for this key (and similar ones).

Now, if I replace the entry { XK_1, 0x02 } by { XK_ampersand, 0x02 } in 
_xwin_keysym_to_scancode[], the mapping is correctly autodected on my 
keyboard (but would fail on a QWERTY).

So, unless I'm missing something, if we create an _xwin_keysym_to_scancode[] 
table for every keyboard layout, and use the one that correspond to the 
keyboard language selected in allegro.cfg, it might be possible to get much 
better mappings, and maybe even get completely rid of the xkeymap utility!

Or maybe not, and it only works for me because of the way my system is 
(mis)configured :-). Anyway, I hope my explanations were clear (the problem 
is a bit complex!).

Julien Cugniere