[directfb-users] Can't translate usb keyboard keys correctly

[Ezequiel García]

Hi,

I am trying to get my usb keyboard working under DirectFB-1.4.3 on a
sh4 box. I am testing it with a small sample application that polls
some keys state through IDirectFBInputDevice::GetKeyState().

The keyboard _is_ working fine as I am getting the keys correctly with
an independent utility (evtest) that tests the linux evdev subsystem
itself (curious reader, just google evtest).

I traced the code looking for the problem placing some 'printfs' here
and there, and it seems to be "mapping" the keys wrongly.

For instance, if I press 'A' my extra printfs give me this:

[DEBUG] keyboardEventThread - Read 1
[DEBUG] keyboardEventThread - Event: type 1, flags 8, keycode 97
[DEBUG] !!!! wm_process_input - Key type 1
[DEBUG] !!!! wm_process_input - Key press
[DEBUG] handle_key_press entered
[DEBUG] handle_key_press - Getting keyboard window
[DEBUG] handle_key_press - Keyboard window (nil)
[DEBUG] IDirectFBInputDevice_React callback
[DEBUG] IDirectFBInputDevice_React - key pressed! index 52, key_id 63028

^^^^^^^^^^^^

Notice that key_id notified by React callback is 63028.

Now, If I ask for the state of the A key (DIKI_A), my extra printfs
give me this:

[DEBUG] IDirectFBInputDevice_GetKeyState
[DEBUG] IDirectFBInputDevice_GetKeyState - index 1, key_id 62977, state 0

^^^^^^^^^^^^^^^^^^^^

So, this means that DIKI_A corresponds to key_id 62977. How come!!!

My questions:

* WTF? Any idea what is going on? Any clue might help me :)
* Who translates kernel (evdev?) key codes into meaningful, e.g.
DIKI_A, DIKI_LEFT.
* What kind of file does IDirectFBInputDevice::LoadKeymap() needs?

Thanks,
Ezequiel.