-
Notifications
You must be signed in to change notification settings - Fork 6
Regression: Deactivating the Number layer now disables numlock even when it was already on on host machine. #6
Comments
Test procedure: 1. Make sure numlock is off on host machine. 2. Activate num layer. Confirm, numlock is now on. 3. Deactivate num layer. Confirm, numlock is now off. 4. Using another keyboard, activate numlock on host machine. 5. Activate num layer. Confirm, numlock is still on. 6. Deactivate num layer. Confirm, numlock is still on. Prior to this commit, step 6 resulted in numlock being off. see keyboardio#2 see keyboardio#3 see keyboardio#1 see keyboardio#6
Test procedure: 1. Make sure numlock is off on host machine. 2. Activate num layer. Confirm, numlock is now on. 3. Deactivate num layer. Confirm, numlock is now off. 4. Using another keyboard, activate numlock on host machine. 5. Activate num layer. Confirm, numlock is still on. 6. Deactivate num layer. Confirm, numlock is still on. Prior to this commit, step 6 resulted in numlock being off. see keyboardio#2 breaks keyboardio#3 see keyboardio#1 fixes keyboardio#6
Test procedure: 1. Make sure numlock is off on host machine. 2. Activate num layer. Confirm, numlock is now on. 3. Deactivate num layer. Confirm, numlock is now off. 4. Using another keyboard, activate numlock on host machine. 5. Activate num layer. Confirm, numlock is still on. 6. Deactivate num layer. Confirm, numlock is still on. Prior to this commit, step 6 resulted in numlock being off. see keyboardio#2 broken keyboardio#3 see keyboardio#1 fixes keyboardio#6
It's not clear to me what the "standard" behavior here is; in my mind, numlock is a machine state, not a keyboard state, so pressing any numlock should turn it on or off on all keyboards. (Backing this, pressing numlock on my Model 01 turns on the numlock LED on my normal keyboard and causes it to send numbers.) Though it also does affect key meanings (on a normal keyboard, arrorws/pageup/etc. vs numpad), so there could be a reasonable disagreement on whether it should be per-keyboard or per-machine. In any case #2 was a simple fix to avoid numlock staying stuck on indefinitely; I tested this, and while it's not necessarily what I expect, it does turn numlock back off when appropriate. I don't much care about the behavior of multiple keyboards, so you if feel strongly about this, I have no objections. |
I tend to agree that numlock is an feature of the machine rather than the keyboard, but that is not how the numpad is setup on the Model 01. On this keyboard, the numpad is enabled by hitting numlock, which both changes the function of the related keys and turns numlock on on the machine. The problem is that, if you have a real numpad, this overrides the machine state nature of the numlock on the separate number pad. Now, when you use the number pad on the Model 01, shut it off, and then switch to the real number pad, num lock has been shut off on the machine. The point behind this change is to make it so that the Model 01 doesn't override the machine's numpad state. |
And indeed, we should be leaving the numlock state as we found it. The
problem we're working around by toggling numlock on when we turn on the
numpad is that if the host's numlock mode is off, our numpad will generate
the secondary keypresses on the numpad (cursor movement, etc.). I don't see
any good way around this unless we don't use the numpad versions of the
number keys at all.
(It's my understanding that whether NumLock and CapsLock are system-wide or
keyboard-scoped is actually an OS level implementation detail.)
…On Thu, Mar 15, 2018 at 4:22 PM, Marty Gentillon ***@***.***> wrote:
I tend to agree that numlock is an feature of the machine rather than the
keyboard, but that is not how the numpad is setup on the Model 01. On this
keyboard, the numpad is enabled by hitting numlock, which both changes the
function of the related keys *and* turns numlock on on the machine. The
problem is that, if you have a real numpad, this overrides the machine
state nature of the numlock on the separate number pad. Now, when you use
the number pad on the Model 01, shut it off, and then switch to the real
number pad, num lock has been shut off on the machine. The point behind
this change is to make it so that the Model 01 doesn't override the
machine's numpad state.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AACxaHYc6q5I42csaVdl7cBrMCz4Gzioks5tevesgaJpZM4SrX3M>
.
|
Also, since it didn't take the contents of the commit message into the pull request, here is the change in detail: Test procedure:
Prior to this commit, step 6 resulted in numlock being off. |
I don't necessarily think that enabling the NumLock while the number layer is on a huge problem In fact, it seems entirely sensible. But, it's important that, when the number layer is shut off, the machine's state is restored correctly. The logical constraint being that, if the number layer is toggled on and then off, the machines state should be set to whatever it was in before the toggling. |
When the Numlock was on before the NumberPad layer was activated, it should remain on on the host machine.
The text was updated successfully, but these errors were encountered: