Quoting Mike Pieper ([EMAIL PROTECTED]):
> This is a Cursor_Up from keyboard:
> (gdb) p event
> $1 = {clazz = DFEC_WINDOW, type = DWET_KEYDOWN, window_id = 5, x = 0, y = 0,
> cx = 0, cy = 0, step = 0, w = 0, h = 0, key_code = 103, key_id = DIKI_UP,
> key_symbol = DIKS_CURSOR_UP, modifiers = 0, locks = 0, button = DIBI_LEFT,
> buttons = 0}
>
> and this from lirc:
> (gdb) p event
> $2 = {clazz = DFEC_WINDOW, type = DWET_KEYDOWN, window_id = 5, x = 0, y = 0,
> cx = 0, cy = 0, step = 0, w = 0, h = 0, key_code = -1, key_id = DIKI_DOWN,
> key_symbol = DIKS_CURSOR_UP, modifiers = 0, locks = 0, button = DIBI_LEFT,
> buttons = 0}
>
> You see key_code is bad here. If I alter the key_code to 103 in the debugger
> the key is correctly recognized.
>
> I'm about to find the reason for that wrong key_code. If I find something I'll
> send a patch here. Perhaps anybody else have a quick idea where to look?
Not every input input device supports/has key codes used in conjunction
with a keymap. The lirc driver simply dispatches a symbol and the input
core translates it into a key id. This is done in "fixup_key_event".
Only the keyboard driver has a keymap yet. It simply dispatches the hardware
key code to the input core and it gets translated taking modifiers and
locks into account.
> PS: The key_id/button values also looks strange, or?
The button field is ignored and not valid in key events.
I'm just wondering why there is a DIKI_DOWN for the DIKS_CURSOR_UP.
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
Convergence GmbH
--
Info: To unsubscribe send a mail to [EMAIL PROTECTED] with
"unsubscribe directfb-dev" as subject.
