I’ve observed this a few times now. Has anyone else seen this?
After a power cycle, the keyboard module reverts to a QWERTY keyboard layout, instead of whatever is programmed into Layer 0.
When I force a transition to Layer 0 via hotkey, the keyboard layout switches to whatever is defined in the keyboard memory as Layer 0, as expected.
This is very different than other programmable keyboards I’ve used in the past. Those default to Layer 0 after a power cycle.
Could you post screenshots of how your layers are set up?
How do you do that? In the factory default layout, there is no key to switch to layer 0. Do you toggle layer 1?
Layer 0 I have mapped to Dvorak, Layer 1 is largely default, Layer 2 is QWERTY.
Yes, it’s quite bizarre that it defaults to QWERTY, but still allows me to switch layers to Layer 0.
Seems you’re in fn-lock.
Looks like you are using DF(0) to switch to layer 0, but that’s not persistent. It’s not retained when the keyboard loses power. So, on power up, you are returned to your saved fn-lock state. The fn-lock-active base is layer 2, so you get your QWERTY layer.
You can either use fn-lock instead of DF(0) to switch between layer 0 and layer 2, which will persist. Or you can disable fn-lock and remove it from your keymap so that you don’t accidentally trigger it. fn-lock is CUSTOM(65)
Can you post your Layer 2, Layer 3, and any other layers you have?
Can you post your Layer 2, Layer 3, and any other layers you have?
Layer 2
Seems you’re in fn-lock.
Looks like you are using
DF(0)to switch to layer 0, but that’s not persistent. It’s not retained when the keyboard loses power. So, on power up, you are returned to your saved fn-lock state. The fn-lock-active base is layer 2, so you get your QWERTY layer.
You can either use fn-lock instead of
DF(0)to switch between layer 0 and layer 2, which will persist. Or you can disable fn-lock and remove it from your keymap so that you don’t accidentally trigger it. fn-lock isCUSTOM(65)[/quote]
This is definitely NOT the case. I removed CUSTOM(65) from the keymap and power cycled, and the behavior persists.
Again I need to point out that, on power cycle, it’s ignoring layer 0 altogether, and defaulting to whatever the standard layout is (which happens to be US QWERTY), until I force a transition to Layer 0.
Fn lock is also forced to a certain state at power cycle (and behaves as F keys instead of media keys), but forcing transition to Layer 0 makes the F keys act as I intend (Layer 0 I want them to act as media keys by default). (I do have Layer 2 intentionally make the F keys behave as F keys).
It’s shown here still on layer 1
But even if you remove it, if it was saved as active then it will persist.
That’s what fn-lock will do. On power cycle it will restore it’s stored base layer state, regardless of what layer you were last on. You can be on layer 0, power cycle & you will now be on layer 2, if that was it’s stored state.
The way fn-lock works in qmk on the FWL16 is using set_single_persistent_default_layer to write a new default layer to persistent memory. It effects the whole layer, not only the F keys.
Perhaps I’m misunderstanding what you’re seeing.
When you power cycle and get QWERTY instead of the layer 0 that you want, do all of the keys match what you have on layer 2?
Yeah, MJ1 is right. I had a similar issue when I set up my “standard” mapping, and it took me a while to figure out why I was seemingly stuck in my symbol layer.
You can either reset the EEPROM or use the set_single_persistent_default_layer function temporarily to set it to 0.
What’s the procedure for resetting the EEPROM?
I havent checked to see what happens if I change layer 2 to something non-standard, but it’s behaving equivalently to layer 2 being the default.
I won’t be able to check until later whether it’s actually running layer 2 by default, or if it’s coincidence.
Actually, unless you are okay losing your VIA keymap, you’re better off recreating the FN_LOCK key in VIA and hitting it once. You can remap to remove it again after that.
The plot thickens.
After changing around Layer 2 to something that’s not standard, I discovered that my keyboard is defaulting to Layer 2 after power cycle, instead of Layer 0!
How do you do either of these? Is there a way to do this via the VIA web app, or is there a different preferred way?
Isn’t that what you were already seeing?
Defaulting to Layer 2 after power cycle is what will happen if the fn-lock-active state was stored at any time & never turned off. You can switch to any layer you want using DF(x), TG(x), or any other layer switching options available in Via. The fn-lock persistent default layer will still be there, and it tells your keyboard to start in Layer 2 after power cycle.
Toggling set_single_persistent_default_layer back to 0 is what pressing the CUSTOM(65) / fn-lock key does when on Layer 3.
from keymap.c for the ANSI (american) keyboard
Note
Layer 0 is _BASE
Layer 1 is _FN
Layer 2 is _FN_LOCK
Layer 3 is _FM
// Make sure to keep FN Lock even after reset
bool process_record_user(uint16_t keycode, keyrecord_t *record) {
switch (keycode) {
case FN_LOCK:
if (record->event.pressed) {
if (layer_state_is(_FN)) {
set_single_persistent_default_layer(_FN_LOCK);
}
if (layer_state_is(_FM)) {
set_single_persistent_default_layer(_BASE);
}
}
return false;
break;
default:
break;
}
return true;
}
First place CUSTOM(65) somewhere on layer 3.
Then switch to layer 3, and press CUSTOM(65).
This will set set_single_persistent_default_layer back to 0.
Afterward, you can remove CUSTOM(65) from all layers, so it can never be activated again.
Be aware that you still have CUSTOM(65) / fn-lock there on layer 1. Be sure to remove it.
Clearing the EEPROM will erase your kemaps. All changes you’ve made will be reset, and the keyboard will be back to factory default. You will still need to remove CUSTOM(65) / fn-lock from the keymap, being sure it’s disabled before you do so. I can provide the steps if you wish, it can be done in Via.
Thank you! That explains it, now it makes sense.
Problem solved. Thanks for the help!