Thanks for the feedback. Resubmitted. -aric Vitaliy Margolen wrote:
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.