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

Aric Stewart aric at codeweavers.com
Wed Jul 30 10:13:11 CDT 2008


Well the main problem is with Japanese keyboards I was testing with. 
Often the scan codes, nor the vkey of the keyboards did not line up the 
characters in the other keyboards.  Yet dinput on windows correctly set 
the DIK codes to represent the character being pressed.
An example is the  key to the right of 'P'.  It is scancode 0x1a on both 
qwerty_us and the Japanese keyboard.  However on the us keyboard it is 
'[' while on the Japanese keyboard it is '@' (it is vkey VKEY_OEM_3, 
which is '`' on the us keyboard)

I saw similar problems with scan 0x1B  ('[' in Japanese and ']' on 
qwerty) 0x2b (']' vs '\')

I did pretty extensive testing with shift on windows and with my code 
and do not recall any specific problems though most of those tests where 
with the Japanese keyboard. I can try some more. I am curious what 
SHIFT+'2' (qwerty)  produces as that is '@'

I am not sure of a better way to try to solve this problem without 
having a bunch of special case situations which struck me as bad.

-aric

Vitaliy Margolen wrote:
> Aric Stewart wrote:
>> It is mapped with the keyboard mapping to the resulting character. so 
>> the key 'A' is DIK_A nomatter what its scancode or vkey would be. This 
>> is relevent to Japanese keymapping where the '@' key is in the '[' 
>> location the scancode for both is 0x22 but dinput generates DIK_AT in 
>> japanese and DIK_LBRACKET in us_qwerty
>>
>> reworked to remove the giant case statement and hopefully be more clear.
>> remove japan specific stuff as with the proper keyboard scancodes it 
>> works out.
> 
> I'm still not clear why do you need to translate the v_key into char? This 
> involves a round trip to the X server for each key press.
> 
> Besides this will depend on the state of the num-lock, shift, etc. Which 
> should not be the case for dinput. It should always return the same code for 
> the key regardless of anything else.
> 
> Vitaliy.
> 
> 



More information about the wine-devel mailing list