DirectInput -> Keyboard -> GetDeviceState

[Arjen Nienhuis]

Ove Kaaven wrote:
> 
> On Fri, 22 Feb 2002, Arjen Nienhuis wrote:
> 
>> The MapVirtualKey in GetDeviceState is not "the way to do it". It does 
>> not map VK_?? to DIK_??. I don't know why it does work most of the time.
> 
> 
> It works because DIK_* is (at least up to 0x53, as far as I can see)  
> identical to the PC keyboard scancodes, and MapVirtualKey handles
> scancodes perfectly well. I really don't think this is a coincidence, I
> think this is so that Microsoft's DirectInput do *not* need the kind of
> mapping table you propose. If there's a problem with the scancode
> conversion, you should fix it in MapVirtualKey. I think you may want to
> keep in mind that the scancode tables in the keyboard code denote extended
> codes with e.g. 0x138 (0x100 + 0x38), while the DIK for that key is 0xB8
> (0x80 + 0x38). Perhaps the keyboard scancode tables could be changed to be
> compatible with the DIK codes without losing any functionality.
> 

The problem with

152: ((LPBYTE)ptr)[i] = 0x80;
153: ((LPBYTE)ptr)[i | 0x80] = 0x80;

is that it breaks a program I have: It moves the cursor two positions on 
a key press. When I checked the MapVirtualKeyA( i, 1 ) results in 
windows, I noticed that it wasn't the direct mapping between VK and DIK.
Also notice, that to check if the DIK_NUMPAD5 key is pressed it is 
necesary to check both VK_CLEAR and VK_NUMPAD5.

> Then that table would depend on the keyboard layout (country, language,
> etc). It should be enough to keep the keyboard layout table mess in *one*
> place in Wine (in the keyboard code, where MapVirtualKey resides), not
> two.

I don't think this table is dependant on the keyboard layout. I think 
(VK_5 <=> DIK_5) is also true in german or french. The only buttons that 
might be a problem are:

   {VK_OEM_1, DIK_SEMICOLON},
   {VK_OEM_2, DIK_SLASH},
   {VK_OEM_3, DIK_GRAVE},
   {VK_OEM_4, DIK_LBRACKET},
   {VK_OEM_5, DIK_BACKSLASH},
   {VK_OEM_6, DIK_RBRACKET},
   {VK_OEM_7, DIK_APOSTROPHE}

but I don't know if those are dependant on the keyboard layout. Do you?

I also found out that the Microsoft code for DirectInput doesn't use 
GetAsyncKeyState, as there is a bug in that function, and not in DI.