On the history and implementation of NumLock

(Michael Richters) #21

Okay, sure, but only if you’re frequently changing the host-side keymap. And then it would be just as true that the keys on the number row itself would only work the way you expect some of the time. I find that to be a very unconvincing argument.

(Andrew Gallagher) #22

Indeed. You can’t assume that your OS is using a particular keymap, but more fundamentally you can’t assume your software is obeying the OS keymap at all.

(Andrew Gallagher) #23

Lots of people type in two languages and switch keymaps regularly. And what someone expects due to their experience with a standard keyboard should prepare them as much as possible for what to expect with any other keyboard. The fact that the number row does change with keymap makes it even more important that the numpad does not.

(Michael Richters) #24

You make it sound like it’s a total free-for-all. “Who knows what unpredictable thing my computer will do with its input? Might as well just chuck it in the bin, because it’s totally useless.”

I can, in fact, control the keymap on my computer. And any software that does unpredictable things with keyboard input is simply broken. And none of that is specific to the numeric keypad.

The one thing you’ve said that’s relevant is about Unicode input on Windows, which is certainly a reason for people who use that feature to include those keycodes in their sketches. To a lesser extent, there may be a reason for people who switch host keymaps frequently to do so, but those problems are probably better addressed by other means (different layers for other languages).

(Andrew Gallagher) #25

It’s not quite that bad. Most software developers follow convention, because it is less confusing to the user. But convention is not binding. For example, this is from the inkscape manual:

The keypad +/- keys do zooming even when you are editing a text object, unless NumLock is on.

This may be unconventional, but it’s not irrational. And Inkscape is not some weird, broken product that can be dismissed out of hand. I remember a long time ago using a piece of CAD software (I forget which one) where mouse clicks behaved differently depending on the state of NumLock. This made sense within the context of the software. But if you’ve never used the software, it would never cross your mind.

In general, if you want to see your assumptions about keyboards being challenged, CAD software is the place to look. You can never have too many keys. :smiley:

Yes, but the keymap is just one layer of abstraction in a stack at least four or five deep, all of which have lists of unstated assumptions. Most of the time you don’t notice the leaks.

Not necessarily, because if you use different firmware layers, then you may have to change the OS keymap and the firmware layer when switching languages, and keep them in sync.

I’m not saying you’re wrong. You can remap your keyboard so that the numpad uses the number-row scancodes if you like. But it’s not something that should be done out of the box.


Sure you can, if you have any left.

The state of keymapping in modded Minecraft actually somewhat ridiculous. In the larger modpacks[1] it’s not unusual for most of the letter keys to already be mapped to at least two functions. Sometimes the functions are able to coexist on the same key, but not always.

One of the difficulties for key mapping in a game is that usually the game really is looking at the key report from the keyboard (as possibly modified by the OS). Frequently the modifier keys have already been assigned in-game functions (such as sneaking or sprinting), with the result being that the mappings have to be independent of the state of the modifier keys.

[1] A modpack is a curated set of mods, usually chosen with a thematic and/or narrative goal in mind, that typically have had their behavioral configuration and crafting recipes tweaked to work better together. It’s not unusual to have modpacks with over 150 mods in them.

Edit: A sentence I left out -
In many ways treating the keyboard as an N-button controller has different needs than using the keyboard to type text. With the current state of keyboard/OS communication anything that reduces the number of available unique keycodes (independent of modifiers) reduces the number of “buttons” on the keyboard-as-a-controller.

(Michael Richters) #27

Oh, did you think I was arguing that the default firmware shouldn’t use the numeric keypad keycodes? I do think that NumLock shouldn’t be handled the way it is in the current default firmware, but I think we’re in complete agreement about that, but I was asking only if anyone could think of a reason why my plan might be inadequate — of which there were a few, but none that apply to me.

This is a point that I was thinking of bringing up, myself. Because if you’re going to be switching OS keymaps frequently with a Model 01, the default firmware is unlikely to work well, because it’s got several keys that are missing from the base layer, and those keys don’t always make sense as the ones to push onto a separate layer with keymaps for other languages and locales. So, if I was doing that switching, I’d need a custom firmware with layers for each OS keymap…and would be able to rearrange the “numpad” keys to suit each one, without dealing with the “oops, the OS has NumLock off” nuisance. To make that easier, it might be nice to define some constants like “Key_Hungarian_8” – a different set for each common OS keymap, if that hasn’t already been done somewhere.

For myself, I’m thinking of the Model 01 as offering something that’s pretty close to a blank slate. So I plan to do a lot of things, like dissociate unrelated symbols that happen to share the same key on “normal” keyboards, rearrange them in a way that makes sense to me, and put numbers in a calculator-style array on a separate layer or two. This last thing is not “a numeric keypad” to me – it’s just a better place to have the numbers on my keyboard.

(Andrew Gallagher) #28

No, but you did ask what the separate numpad keycodes were useful for. And you didn’t seem to like the answers. :stuck_out_tongue_winking_eye:

(Andrew Gallagher) #29

That’s exactly why I advocate a layout that has all the native printables on the base layer. And it can be done!

(Michael Richters) #30

What I said was that I found your arguments unconvincing. They’re all for special situations that I never encounter (I have an enormous preference for a compose key for entering non-ASCII Unicode characters, so I have no reason to be constantly switching OS keymaps or to memorize arbitrary numbers for Windows Unicode input). I do think it was a useful discussion, and you pointed out a few differences that would be relevant for some users.

How useful do you think it would be to add alternate key_defs_keyboard.h files for different keyboards, to make it easier on people in Europe to map keys to the ones on their native keyboards? I don’t even know how many different variants there are that are prevalent enough to warrant that.

…and yet that’s not what has been done. Alas.

(Jesse) #31

Some of this pain will go away when the GUI remapped in Chrysalis is ready.

I do think that we can offer better affordances for non-US keymaps, but I don’t yet think we have a good enough handle on what people really want and need to figure out the -right- solution.

It should be the case that key_defs_keyboard.h already had all of the key definitions for every native keyboard key. Some of them might just have nonobvious names.

(Andrew Gallagher) #32

Neither do I. There is at least one for every country, sometimes more for different languages, but they tend to cluster in groups that differ from each other by only a few keys, particularly if you only consider the unshifted glyphs. And it is only the printable characters that tend to differ - nonprintables and white space stay constant.

(Michael Richters) #33

So, I may not be understanding, because I don’t have a non-US keyboard to test this out on, but isn’t the keycode for Q on a QWERTY keyboard the same as for A on a French AZERTY keyboard? I’m thinking of having an include file for people who have an OS AZERTY keymap, which has (among others) something like the following line:


…or, if this is better:

#define Key_AZERTY_A (Key) { 0x14, KEY_FLAGS }

Or does the A on AZERTY send a different keycode than the Q on QWERTY?

Then there’s the German keyboard, with keys for ü, ä, and ö, but no descriptive identifier for those keys exists in key_defs_keyboard.h. I don’t think it makes sense to put them there, but it might be nice to have them available for people to simply #include in their firmware sketches.

(Andrew Gallagher) #34

No, you are correct.

There is a good case to be made for an include file that defines a set of key aliases for each OS keymap. It should be possible to knock up a batch programmatically. Let me have a go…

(Jennifer Leigh) #35

I think we need friendly documentation that provides the translations folks need, and comments in the definitions file to clarify the stuff that’s really opaque. It’s on my list to do, but it’s pretty far down the queue for me right now. :slight_smile:

Another thing we need are language specific keymaps that map foreign layouts as starting places for the people who don’t use qwerty, Dvorak, or Colemak. They’re developing in various conversations on the forums and I’m watching. :slight_smile: Eventually I’ll solicit finished keymaps from folks and get them added to the wiki.

Narrowing down parameter space for international layouts
(ScottB) #36

So is there any way to update the host’s numlock state? It almost seems like selecting the numpad layer and sending numlock on/off to the host are two different functions. I have noticed that holding Shift while typing the numpad keys swaps their meaning; maybe we just need an ordinary shiftlock function?

(Jesse) #37

If you pull up to current firmware, you should see significantly better behavior.

(Andrew Gallagher) #38

That’s a great improvement. But the NumLock coercion does strange things on OSX. Mac doesn’t have NumLock, and the NumLock keycode is acting as an escape sequence instead.

(Jesse) #39

What specifically are you seeing happen? On OS X, everything appeared to be working ok for me. (Also, if you have your own sketch, make sure you’re using the new Numpad plugin rather than the old Numlock plugin)

(Andrew Gallagher) #40

If for example I’m in iTerm2, and I engage the numpad, it sends an escape sequence so that when I then press a numpad key it looks like this:

galactica:~ andrewg$
(arg: 4)

This only happens on engaging the numpad. This is the same behaviour that happens if I hit NumLock on my normal external keyboard - it’s sending an escape sequence and [Esc] in bash triggers the (arg: ) prompt.