Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#1358 closed bug (fixed (in master))

numpad keys now broken

Reported by: eddiegrove Owned by: myshkin
Milestone: 3.3.0 Keywords: ui commands
Cc:

Description

I just cloned to test a theory on a different old bug, and found that the numpad keys no longer work. I can move with the arrow keys. This is X11 under linux. However, shift + numpad correctly runs in the appropriate direction.

Attachments (1)

kp5.patch (1.5 KB) - added by myshkin 9 years ago.
New fix to add KC_BEGIN keycode (per takkaria).

Download all attachments as: .zip

Change History (17)

comment:1 Changed 9 years ago by eddiegrove

I wonder if this has anything to do with ticket 1316.

comment:2 Changed 9 years ago by scud

OS X 10.6.6: keypad problem introduced with nightly of 20 Feb. With new character managed to a) buy more ammo and b) get to DL1 before problem became apparent (was sitting out a nasty dose of confusion and it was obvious nothing was happening). Initially no diagonal movement, then after some frantic numlocking etc no horizontal movement either.

comment:3 Changed 9 years ago by myshkin

  • Keywords ui commands added

comment:4 Changed 9 years ago by myshkin

  • Status changed from new to confirmed

Internal keymaps are missing some entries for the keypad. I have posted a workaround to the oook thread for this bug.

comment:5 Changed 9 years ago by myshkin

I've also added the relevant entries to pref.prf in myshkin/staging.

comment:6 Changed 9 years ago by myshkin

  • Owner set to myshkin
  • Status changed from confirmed to assigned

comment:7 Changed 9 years ago by myshkin

  • Status changed from assigned to pending

comment:8 Changed 9 years ago by myshkin

  • Status changed from pending to confirmed

We need to settle on which keypad mappings go into pref.prf, and we need to resolve why keypad 5 on Linux (at least) doesn't generate an event.

comment:9 Changed 9 years ago by eddiegrove

Why not include all possible signals from all reported keypads? With both numlock on and off. 1, {K}1, {MK}1, {K}[End], and anything else we can think of. It is not as if someone with a different system should be bothered if {MK}1 is bound if they don't ever produce that signal.

The change is pretty recent. My 3.2.0 game reports just the number when I query it on the numpad. So does a code I cloned from github sometime around 1/26. It is only since the keypad was recently changed to properly report the numpad keys that the numpad 5 went missing for me. Presuming the 5 is not some pref issue, I'd be happy to try to figure it out if someone could suggest a file to look at or the commit that changed the key input. If no one can point me, hopefully I can still do it, but it will take longer.

comment:10 Changed 9 years ago by myshkin

I've added {K}1, {MK}1, {K}[End], and {MK}[End] (and their analogues) to pref.prf on my staging branch. The changes should propagate to the nightlies soon.

I think the problem came into main-x11.c with commit 8cc8201. I suspect that the IsKeypadKey macro in main-x11.c is not correctly defined, and there just isn't a case in the react_keypress() switch statement for keypad 5 with numlock off.

comment:11 Changed 9 years ago by myshkin

Eddie, if you get a chance, could you try the kp5.patch above? If that doesn't work, what event does xev report when you press keypad 5?

Changed 9 years ago by myshkin

New fix to add KC_BEGIN keycode (per takkaria).

comment:12 Changed 9 years ago by myshkin

Please note that, if the patch works the way I expect, keypad 5 will send {K}[Begin]. The patch modifies pref.prf accordingly.

comment:13 Changed 9 years ago by eddiegrove

I could not apply the patch as given. Your base pref.prf in the diff does not match the current codebase. However, when I took out the pref.prf differences I could apply the patch. Unsurprisingly the numpad keys were undefined, but the good news is that when I queried the numpad 5 it told me {K}[Begin]. Presumably that means you've fixed the problem. Thank You!

comment:14 Changed 9 years ago by myshkin

  • Resolution set to fixed
  • Status changed from confirmed to closed

I have pushed this patch, along with some other additions to pref.prf for running and tunneling with the keypad, to my staging branch. The changes should be in nightlies shortly. Thanks for your help in debugging, Eddie.

comment:15 Changed 9 years ago by myshkin

  • Milestone changed from Triage to 3.3.0

comment:16 Changed 9 years ago by myshkin

I've added a few more entries per http://angband.oook.cz/forum/showthread.php?p=52763.

Note: See TracTickets for help on using tickets.