dinput: the DIK_ keycode is not the same as the scancode.

Aric Stewart 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 game.

the top row scan codes for a japanese keyboard are:
1    2    3    4    5    6    7    8    9    0    -    ^    \
second row
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 
to that?


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.
> Regards,
>   Michael Karcher

More information about the wine-devel mailing list