numPush seems broken

[frioux]

I'm basing my firmware off the partial-rewrite branch, if you don't recall. This is where I'm at right now: https://github.com/frioux/ergodox-firmware/commits/frew

The 10-key commit is: https://github.com/frioux/ergodox-firmware/commit/6b89f233d36227a30acd34378dfb9d51bfc57308

The main issue is that even though I use numPush instead of lpu3l3, the number keys are still in arrow mode or non numlock. If that were fixed I'd just move on. There are a couple other strange issues as well that I figure I might as well mention.

If I use the numPush on my Z key in layer 1, it correctly pushes the numpad onto the stack (albeit still not in numlock mode.) If I use the numPush mode on the key underneath V it doesn't push onto the stack. It does something else, but I can't quite tell what, maybe esc then some keys.

Lastly, if you are interested, your commit called "(planning)" made the code no longer compile.

[benblazak]

Hmm... the diff didn't give me any clues, so I compiled and tested your branch on my board - but everything worked as expected - which leads me to suspect that it's your system... When you use the numPush keys, does the "num lock" indicator LED come on? And then go off, when you use numPop?

Also, not all commits will compile, though I do try my best to keep HEAD in a usable state. Sorry if one of the bad ones slipped through as the latest commit. I just pushed a new commit that does compile, just in case :)

[frioux]

With the numPush function the light does nothing. I went ahead and hacked together my own version of numPush (https://github.com/frioux/ergodox-firmware/commit/b77995076f243ca1a2786598e93fcdf0e69a553e#L0L119) and that works just fine for me now. I know it is possible that it could get out of sync, but as far as I can tell your version could too. Anyway, no rush since I have a workaround for now :)

Yeah, I understand that some commits may be broken, I only mentioned it because HEAD wouldn't build.

[benblazak]

Hmm.. that's weird. When I use "KEYPAD__NumLock_Clear" instead of "KEYBOARD__LockingNumLock", the indicator light doesn't come on for me. But my system (OS X 10.8) seems to interpret the keypad keys as if numlock were engaged, whether or not it actually is. Ubuntu must treat things differently... My VirtualBox load of Linux Mint doesn't seem to be any help, since it's probably receiving key input from the host OS, and I don't see any way to change that - so I won't bother trying my virtualized Windows. Some day I need to get Linux legitimately dual booted on here. In the meantime, perhaps you could test my latest commit? I changed it press and release both numlock key codes - which I suppose isn't the best (since we only have 6KRO for now), but if it makes things work on both OS X and Linux, then good :)

[frioux]

That fixed it! thanks :)

[Apteryks]

Hi!

I've been testing this original ergodox firmware, which I successfully packaged for GNU Guix, and I'm also hitting this same issue with the keypad not inputting digits but special movements keys such as KP_Begin, KP_Left, KP_Right, etc.

If I enable Num Lock using a dedicated key from a second keyboard, it then does what I expect and input digits.

Is there a num lock key using this ergodox firmware? In any case, the LED of the right hand, top-left button (which enables layer 3 - they numpad) doesn't lit at any time for me.

I know the LED are correctly wired because they all lit up briefly when powering the keyboard.

Thanks!

[benblazak]

hey :)

all the keycodes are from the USB HID spec, so there should be a numlock key in there somewhere (and i would expect that one to work, though i can't be sure; not all the codes in the spec seem to be implemented on the hosts i've tested, and some don't behave as one would expect).

the LED indicators for numlock (and scroll lock and insert) never did work on all systems perfectly. they worked on my system (macos) when i wrote it, but i wasn't able to test properly for windows or linux -- and i think macos has changed how they send that status over the years, so i couldn't guarantee it works now.

if you're up for fixing this, i'd try looking at the codes that a commercial keyboard sends (or maybe look at the QMK firmware, since it's more widely used and tested) -- and i'm not sure but it might also be possible to see what's getting sent back as far as LED status too. be sure to note your OS (with version).

i don't have much time to spend on this since i'm working now -- (and actually, i'm currently using the QMK firmware, since my switches are old and need real debouncing now) -- but i'll try to look at your other comments and PRs too, as i have time :)

[Apteryks]

Hello, thanks for the response!

I've read a bit more on the topic and now understand that these LED states are kept on the host (computer) side and sent via the USB HID protocol as 'reports'. That's handled by the pjrc library used by this project, apparently correctly.

So I think the only thing which is problematic is that the numpad_toggle_numlock procedure uses the KEY_LockingNumLock key code which is legacy [0] and only available on Windows/MacOS [1]. We should use the non-locking version, "Keypad Num Lock and Clear", 0x53 instead.

[0] https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf [1] https://github.com/qmk/qmk_firmware/blob/master/docs/keycodes.md

edit: I just tried the fix, and it works! I'll send a PR.