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

[Vitaliy Margolen]

Please bottom post on this ML.

Aric Stewart wrote:
 > Here is a revised patch which builds the scancode->DIK table on
 > initialization making no xserver round trips required on lookup.
 >
 > How does this look?
 >
 > -aric
 >
 > Aric Stewart wrote:
 >> Yes, I have verified those vkeys in windows.
 >> the VK_OEM_* keys are specificaly VK codes that vary from keyboard to
 >> keyboard. VK_OEM_3 is just one example.
 >>
 >> -aric
 >>
 >> Vitaliy Margolen wrote:
 >>> Aric Stewart wrote:
 >>>> 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.
 >>> This is needs to be fixed in x11drv then. Not in dinput. Have you
 >>> verified what v_keys you getting from windows for these keys?
 >>>
 >>> Vitaliy.
 >>>
 >>


Few problems with your patch:

> +    if (c && c >31 && c < 96)
Checking for c != 0 is redundant here.

> -    dik_code = hook->scanCode & 0xff;
> +    dik_code = This->ScanCodemap[hook->scanCode];
Scan code can be larger then 256 so "& 0xff" is really necessary.

> +    BYTE ScanCodemap[WINE_DINPUT_KEYBOARD_MAX_KEYS];
You should make this array static and initialize it only once per process

> +static int map_dik_code(DWORD scanCode)
> +{
> +    int out_code = 0;
> +    static const int asciiCodes[] =
> +        {/*32*/ DIK_SPACE,0,0,0,0,0,0,DIK_APOSTROPHE,0,0,0,0, DIK_COMMA,       /*44*/ \
Please rearrange array to have some-what reasonable and same number of 
elements in each line, like 10 (or 5, 8).

> +        newDevice->ScanCodemap[i] = map_dik_code(i);
Please stay consistent with types. If it's a BYTE then you should return 
BYTE from the function.

Vitaliy.