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

[Vitaliy Margolen]

This is all well and good but I don't see a problem. In dinput that is. Are 
those scan codes match to what you are getting on windows? They should since 
they are hardware dependent. But might not. However v_key should stay the same.

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.

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.

Vitaliy.

Aric Stewart wrote:
> 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.
>>
>>