Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
JonyLee,
If I may - this is with reference to your M2 PR on QMK (.qmk#19853 ), specifically the comment from zverc (.qmk#19853 (review) ) around not including "custom code at the keyboard level". This may need an explanation:
The
default
keymap is used by the QMK Configurator to allow users to create custom keymaps ... so if you hard code KB specific code ... for example in yourprocess_record_kb
function you specifically trapcase DF(WIN_B)
, so if that user uses that specific key combo, but not for the default 3+3 layers, then they will get very unpredictable results. This is a no-no.The best practice here is to stick to the
default
keymap to only support keys that match the electrical characteristics of the PCB. Same goes for thevia
keymap, as that keymap is generated by The-VIA project to populate their downloads site. So much so, that it's recommended that these keymaps be written in thekeymap.json
format.So how does one create the "factory default" variant of the firmware. Not sure if it's best practice per-se, but it's common to create a keymap with the vendor name. In this case "monsgeek".
With that in mind - I offer you the code that brings the PR to that thinking... plus some other fixes.
monsgeek
keymap.default
keymap tojson
file style.via
keymap to thejson
file style.LOCKING_*
as this is not needed in a default build."matrix": [0, 0]
entry in the RGB matrix.monsgeek
keymap (as was in the original).case RGB_TOG
key handler as this is not needed here. There is no requirement to keep all the RGB's off as the caps-, num- & scroll-lock LED's are not operated from the under-key RGB's.info.json
file.TG(WIN_WASD)
in the Mac set) - but have left themonsgeek
keymap functionally the same as the Monsgeek user manual.I don't think[MovedDRIVER_x_LED_TOTAL
defines are required - but left them in as I was unsure.RGB_MATRIX_LED_COUNT
toinfo.json
]There is also some fixes to the VIA
json
file (here: https://github.com/vinorodrigues/the-via.keyboards/blob/vr-monsgeek-m2/v3/monsgeek/m2/m2.json).[PS: On this branch you will need to bring QMK up to ver. 0.23.0, or as is current upstream
master
, as the whole CKLED rename thing is required.]