dinput: the DIK_ keycode is not the same as the scancode.
aric at codeweavers.com
Thu Jul 31 07:08:03 CDT 2008
Yes this is a specific problem I am seeing. In a Japanese online Mahjong
game, there appears to be no way to remap the keys and the game is using
the top 2 rows of the keyboard to control the movement of the tiles in
the top row scan codes for a japanese keyboard are:
1 2 3 4 5 6 7 8 9 0 - ^ \
q w e r t y u i o p @ [
Notice how 0x0C (-) 0x0d(^) 0x1A(@) and 0x1B([) have scan codes that
do not correspnd to the character on the qwerty keyboard. This means
with the current code if the user presses the key to the right of 'P' it
generates a DIK_LBRACKET which is actaully they key two to the right,
so the wrong tile gets highlighted. The program is looking for DIK_AT
for that key.
vkey codes similarly do not produce a clean 1 to 1 correspondance. the
'@' key (0x1a) is vkey (VK_OEM_3) which is the vkey of the '`' key on
the us keyboard.
So I am seeing a real world problematic behavior in wine that I am
trying to correct. Your presumption that ALL programs let the user remap
their keys seem overly broad.
I like Michael's idea of initializing this lookup array on
initialization of the keyboard. Then we only have to worry about it if
the user switches keyboard layouts mid program and since last i looked
wine does not support that anyway we would be ok.
If i built the lookup table at that point would you have any objection
Michael Karcher wrote:
> Am Mittwoch, den 30.07.2008, 18:12 -0600 schrieb Vitaliy Margolen:
> Disclaimer: I didn't thoroughly read the thread, but if I understood
> the problem area correctly, the following comments apply:
>> And even if Wine returns different DIKs on different keyboard layouts for
>> some questionable keys. Why is it a problem? In all the programs and games
>> I've seen one can remap their keys to whatever they want.
> It is a problem, because Wine should be compatible to Windows. Also, I
> wouldn't understand why the key containing minus and underscore would be
> called "slash" in the game.
>> The reason I'm so against adding extra X calls - it dramatically affects
>> latency of the input. We already have horrid latency with mouse. All because
>> thread that talks to X is busy doing other things.
> Thats why you should not look up what DIK code to use on each key event,
> but once on DirectInput initialization you should create a map from vkey
> do DIK. SDL uses something like the DIK codes seem to be with their SDLK
> constants. As SDL is also LGPL one might take a look into SDL how it is
> implemented there.
> Michael Karcher
More information about the wine-devel