Mapping FN to Any results in locking behaviour


I received my Keyboard recently and try to customise it. One part in customising is to remap the Shift keys to the FN keys as I almost don’t need FN but I need Shift quite often. My current layout can be found at the end. The most important parts are the mapping of ‘ShiftToLayer(FUNCTION)’ to the position of Any in the QWERTY layer and to the position of the FN keys in the FN layers.

Now, if I press the physical any key/logical FN key I get stuck in the FN layer. The keyboard behaves as if I press the FN all the time. Weirdly, I can escape when pressing the FN key in the FN layer again.

I wonder what I did wrong and how to leave the FN layer automatically when I release the physical Any key.

Thank you very much.

The layout. There are no other changes to the firmware.

const Key keymaps[][ROWS][COLS] PROGMEM = {

  (___,          Key_1, Key_2, Key_3, Key_4, Key_5, Key_LEDEffectNext,
   Key_Tab, Key_Q, Key_W, Key_E, Key_R, Key_T, Key_Tab,
   Key_CapsLock,   Key_A, Key_S, Key_D, Key_F, Key_G,
   Key_LeftControl, Key_Z, Key_X, Key_C, Key_V, Key_B, Key_Escape,
   Key_LeftControl, Key_Spacebar, Key_LeftAlt, Key_LeftShift,

   ShiftToLayer(FUNCTION),  Key_6, Key_7, Key_8,     Key_9,         Key_0,         LockLayer(NUMPAD),
   Key_Enter,     Key_Y, Key_U, Key_I,     Key_O,         Key_P,         Key_CapsLock,
                  Key_H, Key_J, Key_K,     Key_L,         Key_Semicolon, Key_Quote,
   Key_RightAlt,  Key_N, Key_M, Key_Comma, Key_Period,    Key_Slash,     Key_Minus,
   Key_RightShift, Key_LeftGui, Key_RightAlt, Key_RightControl,


  (___,      Key_F1,           Key_F2,      Key_F3,     Key_F4,        Key_F5,           XXX,
   Key_Tab,  ___,              Key_mouseUp, ___,        Key_mouseBtnR, Key_mouseWarpEnd, Key_mouseWarpNE,
   Key_Home, Key_mouseL,       Key_mouseDn, Key_mouseR, Key_mouseBtnL, Key_mouseWarpNW,
   Key_End,  Key_PrintScreen,  Key_Insert,  ___,        Key_mouseBtnM, Key_mouseWarpSW,  Key_mouseWarpSE,
   ___, Key_Delete, ___, ___,

   Consumer_ScanPreviousTrack, Key_F6,                 Key_F7,                   Key_F8,                   Key_F9,          Key_F10,          Key_F11,
   Consumer_PlaySlashPause,    Consumer_ScanNextTrack, Key_LeftCurlyBracket,     Key_RightCurlyBracket,    Key_LeftBracket, Key_RightBracket, Key_F12,
                               Key_LeftArrow,          Key_DownArrow,            Key_UpArrow,              Key_RightArrow,  ___,              ___,
   Key_PcApplication,          Consumer_Mute,          Consumer_VolumeDecrement, Consumer_VolumeIncrement, ___,             Key_Backslash,    Key_Pipe,
   ___, ___, Key_Enter, ___,


The reason for this locking is because when you press a ShiftToLayer key, it switches layers, and when you release it, it will look up the key on the highest active layer. And since that key is mapped to something different, the firmware will never see a release event for the ShiftToLayer key. Now, if you press and release Fn, the release will let the firmware know you released the key.

Right now, the easiest solution would be to make the key that shifts to the FUNCTION layer transparent there, and move Consumer_ScanPreviousTrack elsewhere.

Thank you very much for the description. It works now.

Note that this is no longer true in more recent versions of Kaleidoscope; keymap cache updates are only done when keys toggle on, not when they toggle off, so if you’re building firmware with an up-to-date Kaleidoscope (i.e. from git), you can map anything you want to the FUNCTION layer palm keys (for example), and that layer won’t get stuck on.

1 Like

Thank you for that information.

Is there a way to determine, which firmware version runs on my keyboard? I would like to know beforehand whether an update is worth the hassle. So far, I relied on the wiki article,

but it seems it does not ship the latest version.

Fn + Any should print the build information.


It seems as if I choose exactly the right new position to ask for trouble. :slight_smile: