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.