| Re: [AD] From AL: Dead keys in allegro/mandrake |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Saturday 05 June 2004 10.25, Elias Pschernig wrote:
> 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
I think it is correct to name at most one of the two codings `scancode'.
Unfortunately docs and examples names the latter one scancodes and also in
some places in the source (variable names comments etc. in e.g. keyboard.c).
The former coding is also called scancode in the source (in e.g. xwin.c).
I guess that `pc-hw' is the one that should be the real scancode, if I
remember right it was in that context it was used. People that knows about
that might be confused when reading Allegro docs. If changing the docs,
people that has learn by using Allegro might be confused. People that reads
the sources will get confused anyway... I know that for sure.
Hmm, don't know what would be the best to do about this.
Another confusing thing (that has nothing to do with the X-problem) is
the KEY_* names. Obviously KEY_A don't mean "the key with an A on" but instead
"the key in the upper leftmost corner among the letter keys". So names that
associates with this would be less confusing, e.g. KEY_LETTER_ROW1_1,
KEY_LETTER_ROW1_2 etc. But it is not simple to define the term "letter keys",
the keys that have letters varies, depending on language layout, and the
names of other keys are not very good either, e.g., KEY_EQUALS is not good to
me because the '=' is on shift-0. It would on the other hand
also be a bit stupid to name things like KEY_LETTER_ROW1_1 (matrix index...),
so maybe just use a sequential numbering (e.g. keeping the one that exists)
and in the docs present a keyboard layout that shows the numbering
(developers that want to use acronyms can do their own, national specific or
not)?
> 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
No, that was no good idea, the change made it work with Swedish keyboard and I
thought it did for US too, but it didn't (someone (!) has activated some KDE
"quick keyboard switching" software that takes its own decisions and turned
back the settings that I made in the configuration panel :-( )
> 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).
Why should that be a problem? XKeycodeToKeysym returns the un-shifted letter
on the key, and if that is mapped to a scancode, and, in some other keyboard
setting, another (unshifted) symbol is mapped to the same scancode, then I
can't see any problem at all as long as these 2 keys are unique in its
context (the current keyboard setting). Also in case they are not unique, the
only consequence is that I will get the same letter by typing two different
keys (which is less bad than having a completely dead key).
E.g., I mapped 'ö' to the same scancode as ';' but with a Swedish keyboard
setting there will never be any conflict since the ';' comes as an shifted
','. Also an 'ä' is mapped to a ''', which makes the 'ä' appear also on the
''' key which is of course not right, but has the advantage that 'ä' can be
printed (one can live without ''' - there are several other quotations).
An objection to the patch might however be, if it is worth doing something,
since other keyboards still doesn't work (only the Swedish will work
decently).
Anyway, here is a keymap:
# xkeymap for Swedish keyboard
[xkeymap]
keycode20 = 12
keycode21 = 13
keycode34 = 26
keycode35 = 27
keycode47 = 39
keycode48 = 40
keycode51 = 43
keycode49 = 41
keycode94 = 214
keycode59 = 51
keycode60 = 52
keycode61 = 53
keycode113 = 184
/Christer
--- xwin.c 2004-06-06 14:06:13.000000000 +0000
+++ xwin-modified.c 2004-06-06 14:07:22.000000000 +0000
@@ -2677,6 +2677,16 @@
{ XK_KP_Insert, 0x52 },
{ XK_KP_Delete, 0x53 },
+ { XK_plus, 0x0C },
+ { XK_aring, 0x1A },
+ { XK_odiaeresis, 0x27 },
+ { XK_adiaeresis, 0x28 },
+ { XK_section, 0x29 },
+ { XK_dead_acute, 0x0D },
+ { XK_dead_diaeresis, 0x1B },
+ { XK_less, 0x56 | 0x80 },
+ { XK_Mode_switch, 0x38 | 0x80 },
+
/* Some X servers return different keycodes depending
upon whether NumLock is turned on. */
{ XK_KP_1, 0x4F },