Allow numpad bindings to be sensitive to numlock

[CobaltSpace]

Please fill out the following:

• Description: Currently, for example when I bind KP_End or KP_1, the binding is active regardless of the state of numlock. I would expect that KP_End bindings would only be active when numlock is off, and KP_1 bindings be active when numlock is on. Same with the 10 other keys, including KP_Begin & KP_5.

Usecases:

• Use numpad macro pad only when numlock is off
• Use numpad for mousekeys/pointerkeys only when numlock is off
• Have numpad function as numpad when numlock is on

[litoj]

this is in fact not exactly an enhancment, but mainly a compatibility with i3, which should be another reason to make this work.

[dfoxfranke]

+1 for attention to this issue.

The way I had things working in i3 was that I had most of my numpad mapped to i3 commands (with no modifier key required), but had it function as a normal numpad when numlock was on. I did this by discriminating on, e.g. KP_Begin vs. KP_5. I also customized my xkb map so that the numpad's +, -, *, /, and Enter would map to F13 through F17 when numlock was off, so that these keys would map to distinct keysyms that would allow me to discriminate on numlock state.

I haven't gone diving into the sway sources yet, but what appears to be going on here is that sway is too-eagerly trying to translate bindsym commands into equivalent bindcode commands. So e.g. when I write bindsym KP_Left move left, it seems as though sway is searching my keymap for a keycode that translates to KP_Left, finding 84 (aka <KP5>), and behaving as though I had written bindcode 84 move left. But these aren't the same thing, because keycode 84 only translates to KP_Left when numlock is off.