dinput: the DIK_ keycode is not the same as the scancode.
wine-devel at kievinfo.com
Wed Jul 30 19:12:05 CDT 2008
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.
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.
> 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.
More information about the wine-devel