Conversation
There was a problem hiding this comment.
Among other issues, please note the PR checklist:
- default keymaps should be "pristine"
- should use encoder map feature, rather than
encoder_update_user()
As these are not the only two problems, it is worth reading the aforementioned PR checklist, reviewing the code of other split keyboards in the QMK repository which also use Pro Micros (e.g. the Sweep—just off the dome), and testing your flash commands on actual hardware.
|
This also needs to be relocated to the |
Update examples of compiling and flashing
c8dabc9 to
8d5a02a
Compare
There was a problem hiding this comment.
I am not a collaborator, but as it stands I don't think the code in this keymap will be considered acceptable for inclusion within the main QMK repository.
| } | ||
| } | ||
|
|
||
| void normolizeMatrix(uint8_t* row, uint8_t* col) |
There was a problem hiding this comment.
Can you explain the thought process behind manually manipulating the row and column values of the keypress within process_record_user()?
There was a problem hiding this comment.
I'll start with the meaning of SET keycode and to understand this we have to look at (A,S,D,F) keys in which I added tap-hold functionality accordingly when held (Win, Alt, Ctrl, Shift), and this gives ability to press almost any combination without issue and exceptions are for example (Shift+F, Shift+G, Ctrl+D, Ctrl+C,). SET key comes to solve this problem by adding layer on it and functionality of this you can see in image
Of course the first thing what I did was to add SET as a layer and you can see in previous commits in the comment I've implemented as a layer but with only as a layer it wasn't working stable and by that I decided to implement manually.
With normalizeMatrix() function I tried to align matrix virtually because in hardware it is not implemented optimal for procedure and also code will be tight to hardware which is not good. So with this function I tried to optimize code and in the same time separate hardware from code. But there is an issue with this, this function related to rev1 and it should be there but I couldn't find way to bind with rev1.
Co-authored-by: Joel Challis <git@zvecr.com>
|
I have a question, this version of "default" keymap can it be considered as pristine or should I change it to previous version? |
| case LOWER: | ||
| if (record->event.pressed) { | ||
| layer_on(_LOWER); | ||
| update_tri_layer(_LOWER, _RAISE, _ADJUST); | ||
| } else { | ||
| layer_off(_LOWER); | ||
| update_tri_layer(_LOWER, _RAISE, _ADJUST); | ||
| } | ||
| return false; | ||
| case RAISE: | ||
| if (record->event.pressed) { | ||
| layer_on(_RAISE); | ||
| update_tri_layer(_LOWER, _RAISE, _ADJUST); | ||
| } else { | ||
| layer_off(_RAISE); | ||
| update_tri_layer(_LOWER, _RAISE, _ADJUST); | ||
| } | ||
| return false; |
There was a problem hiding this comment.
tri layer feature enables this.
https://docs.qmk.fm/features/tri_layer
There was a problem hiding this comment.
you could convert this to a keymap.json file, and support both the encoder map and the custom macro (for double 0).
| case QWERTY: | ||
| if (record->event.pressed) { | ||
| _PAD_index = _NUMPAD; | ||
| set_single_persistent_default_layer(_QWERTY); | ||
| layer_clear(); | ||
| } | ||
| return false; |
There was a problem hiding this comment.
This isn't needed, as you only have the one layer

Description
I've created a split keyboard, ortholinear (column-staggered) keyboard powered by an Atmega32u4 microcontroller. It uses the Caterina bootloader and features support for rotary encoders, mouse keys, and NKRO. The firmware is configured for a split matrix layout with a custom hand-swap configuration.
Types of Changes
Issues Fixed or Closed by This PR
Checklist