Removal of user keymaps from QMK

[manna-harbour]

QMK have introduced a breaking change that removes user keymaps, including Miryoku QMK. See the announcement for details.

As a result, Miyoku QMK is not longer present in QMK master, and references to QMK master in the Miryoku QMK documentation are now out of date. In particular, Miryoku QMK can't be built directly from QMK master, and the miryoku branch can no longer be merged with QMK master. Miryoku QMK can still be built directly from the miryoku branch, where a more recent version of QMK is not required.

As a temporary work around, the last commit still containing user keymaps in QMK can be used as a substitute for QMK master. That commit is at tag user-keymaps-still-present, and has been made available as a branch for merging at https://github.com/manna-harbour/qmk_firmware/tree/user-keymaps-still-present. That branch can be used in place of QMK master in the Miryoku QMK documentation to build from directly, or merge with Miryoku QMK, if a more recent version of QMK than is present in the miryoku branch is required. For merging using workflow builds, use manna-harbour/qmk_firmware/user-keymaps-still-present with the workflow merge option.

To update for changes introduced to QMK after that commit, such as new keyboards, files will need to be copied manually between branches. To add Miryoku QMK to QMK, copy the contents of https://github.com/manna-harbour/miryoku_qmk/tree/miryoku/users/manna-harbour_miryoku plus the required keyboard (e.g. https://github.com/manna-harbour/miryoku_qmk/tree/miryoku/keyboards/a_dux/keymaps/manna-harbour_miryoku) or community layout (e.g. https://github.com/manna-harbour/miryoku_qmk/tree/miryoku/layouts/community/split_3x5_3/manna-harbour_miryoku) keymaps from your Miryoku QMK clone to the corresponding locations in your QMK clone. To add individual keyboard support from QMK to Miryoku QMK, copy the required keyboard directory from your QMK clone to the corresponding directory in your Miryoku QMK clone.

In future, Miryoku QMK will be updated to use the new user keymap overlay feature "External QMK Userspace" instead of being a QMK fork.

@drashna has made a copy of Miryoku QMK adapted for this feature as a proof-of-concept, available at https://github.com/drashna/qmk_userspace/tree/miryoku. This can be used now for testing, but won't be updated and isn't supported.

[rvannoord]

Has Miryoku QMK already been updated to use the new user keymap overlay feature "External QMK Userspace"?
I've been trying to find answers to this in your repo but no luck (probably my lack of understanding).

[manna-harbour]

It will be announced here when it's updated, so subscribe to this discussion for notifications. For now, see the work arounds above.

[peterjc]

The main README needs updating, and perhaps a link to this discussion. e.g. manna-harbour/miryoku_qmk#43

[sudosteve]

I'm interested in this feature. My keyboard is supported in the main qmk repo but hasn't been added here yet. I was considering submitting a PR but it seems the right way to get this support is by migrating to the new user_space way of doing things.

What work is required to push this forward?

[manna-harbour]

@peterjc I'm planning on making a repo that includes the full history from all of the original branches i.e. before squashing for QMK PRs. When I get to that point I'll compare with your repo, including the commits you've added on top, so thanks for making it! At the moment I'm working on a new build system, but after that I'll work on the history.

[peterjc]

That sounds good. There is a hack to compile via the QMK user space repository GitHub Actions even with keyboard specific C code - eg peterjc/qmk_userspace#4 - I need to finish soldering my keyboard to test this for real 😉

[peterjc]

I have now tested the firmware from peterjc/qmk_userspace#4 on my own keyboard with LAYOUT_split_3x5_3, demonstating the GitHub Actions approach via QMK Userspace. I look forward to the official QMK Miryoku Userspace 😄

[manna-harbour]

@peterjc
I didn't notice any keyboard specific code in the linked PR? But the new build system will incorporate the outboards feature from Miryoku ZMK, so that could be used for keyboard specific code, and also to build keyboards that maintain their keyboard definitions outside QMK.

[peterjc]

That repo has my own 36-key keyboard “tutte_coxeter_36k” QMK firmware supporting the community split 3x5_3 layout. The keyboard has has a default layout, vial, and on that branch is also built with Miryoku.

I have since also started to look at how ZMK handles out-of-tree keyboards.

[winmillwill]

Just a note for some issues I encountered: (EDIT: was trying to compile for a newer board added after userspace removal)

• needed to apply this fix to drashna's userspace example: https://docs.qmk.fm/ChangeLog/20240825#key-override-keymap-c-signature-change-24120
• could not just copy new keyboard files to pre-removal qmk because it locates by looking for rules.mk and my board doesn't have that file and generating it using the hidden qmk command left some data structure unpopulated and made the qmk cli error out

What ultimately let me compile was following the hardware support steps here #85 in drashna's miryoku branch (not tag, checking out the branch is annoying but doable with git switch -c miryoku --track origin/miryoku) together with the key_overrides change above.

[peterjc]

That fix is in drashna's proof-of-principle qmk userspace miryoku branch now: drashna/qmk_userspace@55dda9d

[manna-harbour]

To build with current QMK also see #361.

[rvannoord]

Cool! So does that mean we won’t really need the user-keymaps-still-present branch anymore?

[manna-harbour]

@rvannoord This is only if you're copying Miryoku into current QMK master.

[maatthc]

Using the instructions I've found here, I've created a userspace for beekeeb/piantor using the latest version of QMK (I needed that to give Predictive Tap Hold a try).

Two additional changes I had to do:

• Rename the keymap : Keymap names must contain only a-z, 0-9 and _!
• Update miryoku mouse keycodes

[riderkirk]

I am new to this whole keyboard thing. I am trying to get setup using the instructions here to flash miryoku to my crkbd v4.1.But first I just wanted to add miryoku_qmk to qmk and test it by compiling rev1. I can compile the firmware for rev1 when I am in miryoku_qmk. But in my own branch where I tried to add miryoku_qmk to the most recent version of qmk I can't get that working. I copied https://github.com/manna-harbour/miryoku_qmk/tree/miryoku/users/manna-harbour_miryoku as stated above. But I didn't find any manna-harbour_miryoku keymap for crkbd to copy over. Which raised the question, how is rev1 able to compile in miryoku_qmk if that keymap doesn't exist there? Again, I am new to this keyboard firmware stuff so forgive me if my confusion is ignorant. Am I even on the right track for getting this working for corne v4.1?

[peterjc]

@riderkirk It is tricky, and will remain so until Miryoku QMK is updated for the QMK upheaval. If using an older QMK is fine for you (before all the keyboard removal stuff which Miryoku still needs), try the advice on manna-harbour/miryoku_qmk#40 perhaps?