Multiple layers?

I’ve recently discovered the Planck keyboard out there on the internet and fell in love with the idea of never having to move my wrists when typing. So I am wondering how easy it would be to change the firmware so that the left fn button changes the keyboard to one layer and then the right to another so that I could move the number line down with one of those. For those working on the firmware a lot, would that be very easy to add in with the current state of the project? Just curious if it would even be worth it to try and dive in and do it.

I believe it would be quite straightforward. I will defer to those who know more than me, but I believe I could set that up with minimal effort.

You would just add a fourth keymap to the sketch with whatever changes you want, and link one palm button to it and leave the other linked to FUNCTION.

2 Likes

I’ve just been looking at the code and cosmetically at least, it’s similar to QMK which drives the Planck. Having added one-shot modifiers, my next step is to replace the function layer with a raise and lower layer in a similar manner to what I have with the Planck/QMK. I’ll let you know how I get on.

I prefer how Kaleidoscope is structured compared to QMK and may have a stab at a Planck port while I wait for my Model 01 to arrive.

3 Likes

As @Jennigma and others have said, this is very easy. You do it pretty much the same way you’d do it for the Planck.

3 Likes

Cool! Thanks yall. @dshields please do keep me updated with your progress!

I finally got around to swapping the function layer for two separate layers:

3 Likes

I am a Planck user, too, and would love to see a Planck port of Kaleidoscope!

How many layers can/does the M01 support?

3?

default - qwerty, dvorak, colemak, etc.
function
numlock

The firmware itself supports up to 32 layers, including the base one. There are some plugins like DualUse and OneShot that provide layer keys, but only support 8 layers. And if you store your keymap in EEPROM, you are limited to at most 7 (but if you use the EEPROM-Keymap plugin, then to 6, because there’s a small header, and 7 layers would need the whole EEPROM). You can use a combination of PROGMEM and EEPROM, but the upper limit will still remain 32.

2 Likes

Thank you sir. A few more questions.

How do we make a layer persistent?

qwerty is default, when we press num it turns on the number pad permanently until we turn num off.
function is turned on temporarily when we hold down fn (+ key)

enum { QWERTY, FUNCTION, NUMPAD }; // layers

can we do this:

enum { QWERTY, FUNCTION, NUMPAD , DVORAK, COLEMAK, WORKMAN}; // layers

and if we can, how do we assign keystrokes to access those layers? example might be:

prog + F1 = QWERTY
prog + F2 = DVORAK
prog + F3 = COLEMAK

etc.

You are looking for LockLayer(N), like LockLayer(DVORAK).

Yes, you can do that. I would suggest that you put FUNCTION and NUMPAD at the end, after DVORAK and the rest, because layer order matters: if you turn a layer on, any key it specifies that are not transparent, will shadow any other layer below it. In the above example DVORAK would shadow FUNCTION and NUMPAD, which is not what you want.

As PROG is just an ordinary key (and on the default keymap, it does nothing), I’d suggest turning it into a layer key, which gets you to a layer we’ll call, say, LAYOUTS (and put it last): ShiftLayer(LAYOUTS). On that layer, make the keys you want to use for switching layouts LockLayer(X), and that should do.

Does this make sense?

5 Likes

Yes, I think so. I’ll get to drafting a config and uploading it for you (or any other wonderful peeps to double check my work). Appreciate it.

2 Likes

Something like this?

  [QWERTY] = KEYMAP_STACKED
  (LockLayer(WORKMAN),  Key_1, Key_2, Key_3, Key_4, Key_5, Key_LEDEffectNext,
   Key_Backtick,	Key_Q, Key_W, Key_E, Key_R, Key_T, Key_Tab,
   Key_PageUp,   	Key_A, Key_S, Key_D, Key_F, Key_G,
   Key_PageDown, 	Key_Z, Key_X, Key_C, Key_V, Key_B, Key_Escape,
   Key_LeftControl, Key_Backspace, Key_LeftShift, Key_LeftAlt,
   ShiftToLayer(FUNCTION),

   Key_Delete,    Key_6, Key_7, Key_8,     Key_9,         Key_0,         Key_KeypadNumLock,
   Key_Enter,     Key_Y, Key_U, Key_I,     Key_O,         Key_P,         Key_Equals,
                  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_RightGui, Key_RightShift, Key_Spacebar, Key_RightControl,
   ShiftToLayer(FUNCTION)),


  [WORKMAN] = KEYMAP_STACKED
  (___,          Key_1, Key_2, Key_3, Key_4, Key_5, Key_LEDEffectNext,
   Key_Backtick, Key_Q, Key_W, Key_E, Key_R, Key_T, Key_Tab,
   Key_PageUp,   Key_A, Key_S, Key_D, Key_F, Key_G,
   Key_PageDown, Key_Z, Key_X, Key_C, Key_V, Key_B, Key_Escape,
   Key_LeftControl, Key_Backspace, Key_LeftShift, Key_LeftAlt,
   ShiftToLayer(FUNCTION),

   Key_Delete,	  Key_6, Key_7, Key_8,     Key_9,         Key_0,         Key_KeypadNumLock,
   Key_Enter,     Key_Y, Key_U, Key_I,     Key_O,         Key_P,         Key_Equals,
                  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_RightGui, Key_RightShift, Key_Spacebar, Key_RightControl,
   ShiftToLayer(FUNCTION)),

My questions is:

Do I have to add LockLayer(QWERTY) under the workman section to go back to QWERTY? or will hitting prog toggle back to QWERTY? Like the behavior of numlock.

1 Like

Having it transparent like you do is perfect, that will get you back to QWERTY.

In other words, LockLayer(N) toggles layer N — it turns it off if that layer is on, and vice versa. The name is a bit misleading, and hints at idempotent behaviour.

1 Like

If we want a key that only cycles through some layers (we may not want to cycle through num and function) what’s the easiest way? Define an array of only the layers you want and use an iterator over it?

We spent a bunch of time on the naming and settled on LockLayer, as it acts similarly to CapsLock/NumLock/ScrollLock.

Do you have thoughts on names that would better convey the behavior to you?

1 Like

Yes, but I’m not convinced that my ideas are better than what you chose, and my implication that LockLayer() was a poor choice was unintentional. I think the concept that will be unintuitive for many people is the idea that multiple layers can be toggled on at the same time (with upper ones masking lower ones), and that would lead to them thinking that on Layer “A” they should have LockLayer(B) and on Layer “B” LockLayer(A) will get them back to Layer “A”, which would lead to being trapped in Layer “B”, and just toggling the buried Layer “A” on and off.

On the other hand, if it was called “ToggleLayer” instead, that might lead to a different source of confusion because it’s not obvious if that acts like NumLock or Shift. To me, “ToggleLayer” and “ShiftLayer” would be more intuitive, but I can only speak for myself, and since I do understand the concept (if not the whole implementation), I can deal with it either way.

1 Like

nod We talked about Toggle. I recall there being some reason we ended up hating it.

I think the main thing is to clearly convey the concept of turning layers on and off, rather than switching from one layer to another in the documentation. Once that’s understood, it becomes clearer what LockLayer() does, though some people will probably go looking for a separate UnlockLayer()