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 - ^ \ 0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x29, second row q w e r t y u i o p @ [ 0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1A,0x1B
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?
-aric
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