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

Aric Stewart aric at codeweavers.com
Wed Jul 30 10:26:16 CDT 2008

Doing tests with shift show that the presence of the shift key does not 
affect MapVirtualKey so  SHIFT+2  still returns '2'  since it is 
scancode based i doubt that numlock would either. So I do not think we 
need to worry about that.


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