Closed sporkus closed 1 year ago
Thank you for the excellent bug report! Your analysis is correct, the keycode parsing is not getting the layer as it should. The encodings for some keycodes changed recently with QMK 0.19, and I overlooked that this code was affected.
I just pushed https://github.com/getreuer/qmk-keymap/commit/694c2ffafa369a78448f9efca5ce2c607d629821 with a fix, using the new keycode parsing helpers.
Thank you so much for the quick fix!
Thank you for your many qmk articles and features. Achordion is fantastic! However, I'm having issues with the layer lock feature.
Describe the bug
The bitwise operation in
process_layer_lock
returns the wrong layer from the keycode. By having the wrong layer inis_layer_locked()
, the function returns true and qmk's default handling turns off the layer instead.I had added some debugging code, and here's what I'm seeing:
MO(3)
key down ->MO(3)
key upThe macro
QK_MOMENTARY_GET_LAYER(kc) ((kc)&0x1F)
fromquantum_keycodes.h
seem to return the correct result instead:MO(3)
key down ->LLOCK
key down ->LLOCK
key up ->MO(3)
key upFix
After applying the following patch, the layer lock key worked as expected.
Comment
It looks like the correct bit mask to use is only 5 bits for the 32 maximum layers. The keycode range seems to confirm it.
The bitwise operation for layer tap matches the macro
QK_LAYER_TAP_GET_LAYER(kc)
, and works as expected, but perhaps it would be better for readability to use the macro also.Information
Do the keys involved use any of the following features?