dz60rgb ansi when press MO key stay forever on the other layer

[rodrigore]

Hi, not sure if this issue belong to this category.

I have a dz60 rgb ansi v1, that work perfectly but today I mapped two keys and now when I use the Mo key to enter to layer 1, the keyboard stay always on that layer.

I use qmk configurator to define the layers and then qmk toolbox on the same mac.

I saw other issues like #4958 that fix this problem using the 'Clear EEPROM' but on my case I try with that but not sure if is doing something because I pressed before and after the Flash keyboard. Can you answer me if I press the 'Clear EEPROM' should appear something on the GUI or maybe some option on the dfu-util ?

The output of the flashing is correct and is this:

The strange of this is that I have access to my old bin and is work fine. Also I have my old json configuration that I use to change the two keys. I try to use the default bin and also works (loaded inside qmk toolbox).

Not sure if is a problem with qmk configurator website, but try to load my new layout from default and also broke my keyboard when I access to the 'Mo' layer.

Note: the keys that I changed are only left control and caps lock.

I hope that someone can guide me to test another solution, not sure if is a qmk configurator website problem or qmk toolbox dont let me clear eeprom.

[mu-b]

I think this may have been introduced in 0.8.69. Fixed by rolling quantum/quantum.c back to 0.8.68.

[rodrigore]

Hi @mu-b thank you for the answer but not sure if now the problem was solved or I have to wait that the repo roll back the changes to quantum.c.

[am]

Notice the same on a split, using touchcursor layer that it got stuck. Confirmed that rolling back to https://github.com/qmk/qmk_firmware/releases/tag/0.8.69 solves the issue. @rodrigore I don't think this is fixed by now since I tried also to update to master and the issue persists. Try to reset your project to the mentioned version it should be fine.

[Syzygies]

I just filed #8600 which sounds related. If this is the same bug, it was introduced in the last 27 commits. I'm on 0.8.79.

[Erovia]

@rodrigore do you have your keymap.c or Configurator json somewhere?

[am]

@Erovia in case it help here's mine.

[Erovia]

@am could you please try to KC_TRNS instead of KC_NO?

[am]

@Erovia I've tested to rebase my branch with current master and now it's working fine with the same layout I had before 🤷‍♂
TBH is also difficult for me to reproduce exactly the same setup I test before since I've been testing changes on this same layout and I've been amending commit and force pushing my branch. I could reflog in case it's needed. But since master is now working for me I rather not.

It would be nice if know if now master works for @rodrigore if that is the case this could be closed.

[rodrigore]

Hi all, I use qmk configurator website. (I don’t compile on my machine locally)
Do you think is updated on the https://config.qmk.fm/ to test ?

EDIT: I tested with the website and still get stuck

[Ty-deo]

I'm getting this issue now too @rodrigore. Any headway that anyone's found?

[Syzygies]

This was fixed on QMK main branch by #8693. I build my firmware locally using a mirror of that branch, and the issue is resolved. I can't comment on the timeline by which this fix propagates to various configurators.

[rodrigore]

@Syzygies great! Do you know if https://config.qmk.fm/ is updated with the main branch?

[Erovia]

Firmwares built with Configurator should contain this fix now.