GNOME Bugzilla – Bug 117691
Cursor keys do not work properly.
Last modified: 2004-12-22 21:47:04 UTC
Using RedHat Linux 9 and a US 105+ keyborad, the cursor keys do not function properly. (These are _not_ the keys in the numeric keypad.) Pressing the up, down, right, & left cursor keys generates: 8246. Instead, I would expect them to change the focused widget.
Hi Dennis, Could you add something like: fprintf(stderr, "kframe_key_press_cb: keyval is %x\n", event->keyval); near the beginning of the kframe_key_press_cb() function in gtk.c please (about line 1358). Rerun gcalctool, press those keys and tell me what you get. Thanks.
Hi Rich, I pressed the cursor keys in the following order: Up, Down, Right & Left. Results: kframe_key_press_cb: keyval is ff52 kframe_key_press_cb: keyval is ff54 kframe_key_press_cb: keyval is ff51 kframe_key_press_cb: keyval is ff53
[Cc:'ing Owen for his take on this]. I get the same results on my Solaris S9U3 box. According to .../gtk/gdk/gdkkeysyms.h ff52 is GDK_Up ff54 is GDK_Down ff51 is GDK_Left ff53 id GDK_Right Trouble is these are exactly the same keysyms that get generated (at least for me) when I use the Numpad arrow keys, irrespective of whether I've got NumLock on or not. Owen, any ideas of the best way to handle this? Thanks.
Rich, For what it's worth, pressing the cursor keys on the numeric keypad in the order Up, Down, Right & Left gives: With the num lock key not set... kframe_key_press_cb: keyval is ff97 kframe_key_press_cb: keyval is ff99 kframe_key_press_cb: keyval is ff96 kframe_key_press_cb: keyval is ff98 And with the num lock key set... kframe_key_press_cb: keyval is ffb8 kframe_key_press_cb: keyval is ffb2 kframe_key_press_cb: keyval is ffb4 kframe_key_press_cb: keyval is ffb6 Thanks, Dennis
Which equates to GDK_KP_[2,4,6,8] when NumLock is set, and GDK_KP_[Up,DownLeft,Right] when it's not. Which is sane. Looks like Solaris keysyms are screwed. Well a simple fix for Linux is to just remove GDK_Up, GDK_Right, GDK_Left and GDK_Down from the keysym compare tables in calctool.c. I'll attach a patch that does this, though I'm not sure it's the right solution yet. Adding Alan for Sun specifix X keysym comments here.
Created attachment 18395 [details] Potential patch to fix problem on Linux - not sure where that leaves Solaris numpad.
Note that key syms are part of the X protocol ... if there is a system where you dont' have: #define XK_KP_0 0xFFB0 #define XK_KP_1 0xFFB1 #define XK_KP_2 0xFFB2 #define XK_KP_3 0xFFB3 [...] then it's X incompatible. So, I really doubt the keysyms are different on Solaris. But I guess what you are saying is that your keymap is not working properly, not that the keysyms are different. You might want to check with a straight Xlib program like 'Xev' to see if it's really the keymap that is messed up or problems with the GDK key handling code.
Here are the results of running xev on my Solaris machine: Arrow keys, and numpad arrow keys (both with and without Numlock key on) report: Up 0xFF52 Down 0xFF54 Left 0xFF51 Right 0xFF53
On my Solaris 9 SunBlade 100 with Sun Type 6 Unix keyboard, xev returns Up, Down, Left, Right if the NumLock key is off. (Yes, I know, it's annoying, but it's historical.) If numlock is on it returns KP_8, KP_4, etc. Our current XKB keymaps use the KP_ names for both modes, but XKB is not yet on by default, so few users will see this for now.
Okay, thanks Alan. It looks like I should just apply the potential patch. Dennis could you try it out please and tell me if it fixes the problem for you?
Hi Rich, The patch works. After applying it, the cursor keys move the widget focus accordingly, and the keys on the numeric keypad continue to work as before. Thanks, Dennis
Thanks Dennis. Changes checked in. Fixed in v4.2.100.