Ok. By my reading, that means that we’re now properly emulating what a regular keyboard does.While I understand that the behavior may not be desirable, it is at least not -broken-
1 Like
Weeeeeeeellll… sort of. But on a regular keyboard you can choose not to press NumLock. 
2 Likes
The new behavior works perfectly on Windows. Nice change.
That did the trick! Thanks. Perhaps this should be featured in the documentation…
1 Like
Now that we know it works, totally. Since you’ve run through the process, would you be up for proposing what we should tell folks?
Sure. How much agonizing detail do we want? 
Enough but not too much? 
Feel free to sketch something out and I can test it and flesh it out on Windows and OSX.
1 Like
There is some value to putting both “here’s how to fix this issue” and “here’s an interesting doctoral dissertation on the history and societal implications of this problem” online, as the former is what most folks want and the latter is what will someday save someone six hours of agonizing research. 
But the short version is probably the critical bit
3 Likes
Random observation today while I was working and getting used to using NumLock to access the number pad more quickly… The quote key (2 spaces down from the num key) lights up red. I looked at the default legend that comes with the Model 01 and noticed that that key doesn’t have a NumLock assignment.
Through just a little digging, I found that this is due to the fact that the NumLock layer has Key_Quote assigned to that key and doesn’t just fall through to the base layer (also defined as Key_Quote). Was this intentional? Maybe we should just update the default sketch to have that key be transparent so it doesn’t light up red and confuse people.
4 Likes
Your Model01 should ensure that your computer’s NumLock mode is enabled when you activate the numeric keypad. On Windows and Linux, NumLock must be enabled for the keypad to generate digits. If your keypad is moving your cursor rather than generating digits, it is because NumLock is not being properly synchronised. This is a known problem in early versions of the firmware; to fix it please update to the latest version. (Insert reference to firmware upgrade instructions)
On Mac OS X, there is no such thing as NumLock. But since the Model01 can’t be 100% sure what sort of computer it is plugged into, it tries to enable NumLock anyway. Most Mac software will ignore this, however the following software has been known to behave oddly:
- iTerm2 - When activating your Model01’s numpad, sometimes an escape sequence is sent and this can cause unusual behaviour in terminal programs such as
bashandvi. To fix this, go to iTerm2 → Preferences → Profile → Keys, click “Load preset” and choose “xterm with numeric keypad”.
1 Like
Blender uses it, unfortunately. As such, I have a dedicated external number pad for Blender.
I’ve upgraded to the latest firmware, but I’m still having the problem. There is a complication here I should mention: I’ve moved ‘LockLayer(NUMPAD)’ to Fn-Num so I can use the Num key for Backslash/VerticalBar. Maybe that has something to do with it. But anyway, the first time I engaged the numpad after flashing the new firmware, I got digits as desired, but when I disengaged it, one of the modifier keys was stuck on; I think it was the right Control key. (I hadn’t seen that before.) And then, when I engaged the numpad again, I got arrow keys etc. instead of digits.
… Oh, this is interesting. According to ‘xev’, when I engage the numpad with Fn-Num, I get an ongoing stream of KeyPress/KeyRelease pairs with keycode 77, Num_Lock. As soon as I press another key, those stop and I get the press/release pair for the key I pressed; they don’t resume afterwards. And the last keycode 77 event is a KeyPress! And with a little more experimentation I see that the first one in the stream is actually a KeyRelease. So this is really a stream of KeyRelease/KeyPress event pairs.
I think you have to be careful choosing the positions for the layer changers. In particular, you should make sure that the layer changer is available both before and after numlock is engaged. Are you using the new layer order, where function is defined after numpad rather than before?
Interesting! Can you see what happens if you stick the numlock toggle somewhere that’s visible on the map from within Numlock? Like possibly not making it a ___ key on the NUMPAD layout but instead being LockLayer(NUMPAD)?
you should make sure that the layer changer is available both before and after numlock is engaged
Heheh, I thought of that 
Num on the numpad layer is ‘LockLayer(NUMPAD)’. Yes, I’m using the new layer order.
Can you see what happens if you stick the numlock toggle somewhere that’s visible on the map from within Numlock? Like possibly not making it a ___ key on the NUMPAD layout but instead being LockLayer(NUMPAD)?
It is already, for the reason Andrew mentioned. Although, I guess it wouldn’t really be a problem if it weren’t; I’d just have to hit Fn-Num again to get back to the base layer. Let me try that…
Also, do you see the weird behavior with the default keymap?
Okay, I flashed the default keymap, and I did the endless stream of release/press pairs once. I think it was on the third try, though, and then I couldn’t get it to happen again, even after power-cycling the keyboard. But now I’ve switched back to my layout and it happens easily. Changing the numpad layer entry for Num back to ‘___’ seems to make no difference.
Hmm, this last time I tried it with ‘xev’, there was initially a KeyPress event with keycode 77, and then 500 ms [edit: actually 600 ms] later, the series of release/press pairs started.
Would you mind opening a bug report at https://github.com/keyboardio/Kaleidoscope-NumPad/issues?
Oh. Wait. Is your sketch using Kaleidoscope-NumPad or Kaleidoscope-Numlock?