[Bug] Num Lock Sync not working properly on RP2040 Framework16 Macropad

[heumann-a]

Describe the Bug

The sync between numlock of OS and state of QMK does not work properly.
If i reflash it it works correctly, if i reseat it afterwards it gets the correct state for one time and than the wrong one aftewards.

https://github.com/heumann-a/qmk-keymaps/blob/main/fw16_macropad/keymap.c

Steps to reproduce:

• Clone my repo and the FW16 Repo linked down there
• ./compile.sh build fw16_macropad
• flash
• reseat board
• It prints 1 for enabled NUMLOCk once and than 0 for not enabled though if i press the keys the keys are the NUMLOCk Layer

How can i implement it to work correctly?

EDIT: i checked with my lily58 too. Somehow while connecting the keyboard to the computer, it somehow messes up the numlock state to disable it somehow.

• I activated numlock (visible on debug console, layer indicator and OLED screen on lily58)
• I replug lily58
• lily58 says NUMLOCK is active,
  • pressing keys on both pads are sending numbers so num is active
  • but pad on framework is on numlock disabled layer
  • to "fix it back" i need to disable and enable numlock to be in sync again.

Keyboard Used

Custom Fork of FW16 QMK https://github.com/heumann-a/fw_qmk_firmware/tree/v0.2.9

Link to product page (if applicable)

No response

Operating System

Arch Linux

qmk doctor Output

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

No response

[tzarc]

Try the print before the early exit and see if it’s filtered out due to your logic.

[heumann-a]

Did it:

flashed the macropad and replugged it.
The first number after the dash is the state of the led.numlock and after FN the state if the layer FN is activated.

Framework:Laptop 16 RGB Macropad:1: Early 942 - 1: FN: 0 Framework:Laptop 16 RGB Macropad:1: Early 942 - 1: FN: 0 Framework:Laptop 16 RGB Macropad:1: Early 943 - 1: FN: 0 Framework:Laptop 16 RGB Macropad:1: Early 944 - 1: FN: 0 Framework:Laptop 16 RGB Macropad:1: Early 944 - 1: FN: 0 Framework:Laptop 16 RGB Macropad:1: Early 945 - 1: FN: 0 Framework:Laptop 16 RGB Macropad:1: Early 946 - 1: FN: 0 Framework:Laptop 16 RGB Macropad:1: Early 950 - 0: FN: 0 Framework:Laptop 16 RGB Macropad:1: Early 950 - 0: FN: 0 Framework:Laptop 16 RGB Macropad:1: Early 951 - 0: FN: 0 Framework:Laptop 16 RGB Macropad:1: Early 951 - 0: FN: 0 Framework:Laptop 16 RGB Macropad:1: Early 952 - 0: FN: 0 Framework:Laptop 16 RGB Macropad:1: Early 952 - 0: FN: 0 Framework:Laptop 16 RGB Macropad:1: Early 953 - 0: FN: 0 Framework:Laptop 16 RGB Macropad:1: Early 953 - 0: FN: 0 Framework:Laptop 16 RGB Macropad:1: Early 954 - 0: FN: 0

For test purposes i removed all my layer_on/off calls.
Everytime at around 1s something disables my numlock.
Its kinda predictable with +- 20ms

Funny thing: the num_lock SHOULD be active because OS registers the numbers. even in this state