Unexpected DF() behavior

[AlabasterAxe]

One of the features that I'm trying to add to my Planck is to be able to set the layout to Qwerty or Dvorak regardless of if the computer is Qwerty or Dvorak in software. To this end, I've defined 8 keymaps:

Software Dvorak:
Firmware Dvorak // 0
Firmware Qwerty // 1
Firmware Raised // 2
Firmware Lowered // 3

Software Qwerty:
Firmware Dvorak // 4
Firmware Qwerty // 5
Firmware Raised // 6
Firmware Lowered // 7

My layouts are pretty close to the default so I likewise have the DF() cluster in the lower right side of my altered layers. The main difference is that on my raised layer, I keep the same software configuration and on the lowered layer I switch to the other software layer.

For example, if I start on layer 0, hit the raise key, and hit the DF(Qwerty) key, I'll switch to the Qwerty layout in firmware, keeping the software layout Dvorak.

If instead I start on layer 0, hit the lower key and hit the DF(Qwerty) key, I'll switch to the Qwerty Layout in firmware and software.

I can reliably switch to the Software Qwerty, but when I try to switch back to the Software Dvorak layers, it seems to get stuck on one of the raised layers and nothing I've tried gets it back to any of the default layers. I just have to unplug it and re plug it.

Does anyone know why this might be happening and what I can do to get the behavior I'm looking for?

Thanks!

[AlabasterAxe]

This is the keymap that I'm using:
keymap.c

[AlabasterAxe]

One final bit of information is that I have confirmed that the keyboard consistently gets stuck in the Querty Software, Raised layout.

[jackhumbert]

That's definitely an odd behavior - it may help to put your default layers further down the chain like

#define DV_DV 0
#define DV_QW 1
#define QW_DV 2
#define QW_QW 3

#define DV_LW 4
#define DV_RS 5
#define QW_LW 6
#define QW_RS 7

The DF() is using some built-in TMK stuff, but if you'd like more control, you can make them macros and use layer_on() and layer_off().

[DidierLoiseau]

I think your problem is the following:

1. you are in QW_DV or QW_QW;
2. you press the MO(QW_RS) to temporarily enable the QW_RS layer;
3. you type the DF(QW_DV) or DF(QW_QW) to disable the layer you are coming from, and go back to one of the DV_ layers;
4. now you release the MO(QW_RS) key… but this key does not have the same mapping any more since you have disabled the QW_DV/QW_QW layer: it is now mapped to MO(DV_RS).

The consequence is that when you release the key, the firmware tries to disable the wrong layer, and the QW_RS remains enabled.

However I think there is a simple workaround: just repeat all the MO() keys in the destination layers, so that they don't depend on the lower layers through KC_TRNS. You should do it on the DV_RS/DV_LW layers too.

[ezuk]

Closing this one as it seems fixed by that PR.