Thanks for the feedback. Resubmitted.
-aric
Vitaliy Margolen wrote:
> Please bottom post on this ML.
>
> Aric Stewart wrote:
> > Here is a revised patch which builds the scancode->DIK table on
> > initialization making no xserver round trips required on lookup.
> >
> > How does this look?
>
James Mckenzie wrote:
> Vitaliy Margolen <[EMAIL PROTECTED]> at Jul 31, 2008 10:10 PM (PNT) wrote
> about Re: dinput: the DIK_ keycode is not the same as the scancode.
>>> -dik_code = hook->scanCode & 0xff;
>>> +dik_code = This->ScanCodemap[hook->
Aric Stewart <[EMAIL PROTECTED]> writes:
> 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 b
Please bottom post on this ML.
Aric Stewart wrote:
> Here is a revised patch which builds the scancode->DIK table on
> initialization making no xserver round trips required on lookup.
>
> How does this look?
>
> -aric
>
> Aric Stewart wrote:
>> Yes, I have verified those vkeys in windows.
xed in x11drv then. Not in dinput. Have you
verified what v_keys you getting from windows for these keys?
Vitaliy.
commit f32b8b281a5df115881f2c5c6dd2f273d5b2b657
Author: Aric Stewart <[EMAIL PROTECTED]>
Date: Fri Jul 25 16:07:30 2008 +0900
dinput: the DIK_ keycode is not the same
Yes, I have verified those vkeys in windows.
the VK_OEM_* keys are specificaly VK codes that vary from keyboard to
keyboard. VK_OEM_3 is just one example.
-aric
Vitaliy Margolen wrote:
> Aric Stewart wrote:
>> vkey codes similarly do not produce a clean 1 to 1 correspondance.
>> the '@' key (0
Aric Stewart wrote:
> 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.
This is needs to be fixed in x11drv then. Not in dinput. Have you verified
what v_keys you getting from window
Am Donnerstag, den 31.07.2008, 08:53 +0200 schrieb Michael Karcher:
> SDL uses something like the DIK codes seem to be with their SDLK
> constants.
Argl! That sentence sense no make does. I meant to say: "SDL's SDLK_*
constants seem to be conceptually what Window's DIK_* are."
Regards,
Michael K
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:
1234
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.
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 l
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.
-aric
Vitaliy Margolen wrote:
> Aric Stewart wrote:
>> It is
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 t
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 generat
Thanks, I will look into what i can do. I worried about using VK codes
because sometimes the same VK can produce different characters. The
specific example I am looking at is VK_OEM_3 which produces the '@' in
Japanese and often the '`' character in other layouts. I could use VK
from the hook
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
16 matches
Mail list logo
