On Tuesday 25 June 2002 20:09, you wrote:
> So it seems that the GtkCList (programList) is getting the keypress
> events and they are the right ones (from
> /usr/include/gtk-2.0/gdk/gdkkeysyms.h):
>
> #define GDK_Up 0xFF52
> #define GDK_Down 0xFF54
>
> so I am at a loss as to why my GtkCList is not reacting to the keys
> when I remove the signal handler for key_press_event.
>
> Any more ideas? Any further tests I can do?
The problem is that gdk doesn't use the key symbols. Instead it asks the
driver at initialization time about the key_codes for the symbols. The answer
from the keyboard driver is used then to build a lookup table.
Therefore the symbol may be right, but gtk doesn't recognizes the key right.
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?
Mike
PS: The key_id/button values also looks strange, or?
--
Info: To unsubscribe send a mail to [EMAIL PROTECTED] with
"unsubscribe directfb-dev" as subject.
