This repo contains the firmware for my qmk enabled 5x7 dactyl-manuform using a customized miryoku keymap.
Clone and launch install.sh to symlink the layout where qmk expects it to be, then launch one of:
qmk generate-compilation-database -kb grota_dactyl_manuform/5x7 -km light_miryoku
make grota_dactyl_manuform/5x7:light_miryoku:flash
This will always will be a work in progress (most of the keys are quite stable though).
make grota_dactyl_manuform/5x7:light_miryoku:avrdude-split-right
make grota_dactyl_manuform/5x7:light_miryoku:avrdude-split-left
git diff A B -- ':!keyboards*' ':!users*' ':!layouts/*' ':!drivers/*' ':!tests/*' ':!lib/*' ':!platforms/*' ':!docs/*'
make grota_dactyl_manuform/5x7:light_miryoku:update_achordion
I also have a 6x6 dactyl-manuform and an ErgoDox-ez which I am currently not using.
make grota_dactyl_manuform/5x7:grota:flash
make grota_dactyl_manuform/6x6:grota:flash
make ergodox_ez:grota:flash
make grota_dactyl_manuform/5x7:grota:avrdude-split-right
make grota_dactyl_manuform/5x7:grota:avrdude-split-left
qmk generate-compilation-database -kb grota_dactyl_manuform/5x7 -km grota
qmk console
See here for my keymapviz customization (now using neovim plugin https://github.com/codethread/qmk.nvim).
There is a custom rgb layer indicator that I can cycle through with the other effects and that also shows how to target the color of specific keys when I switch layers or when press a modifier (see rgb_stuff.c
).
These are the indices used in the various rgb_matrix_*
functions for the ergodox.
,--------------------------------------------------. ,--------------------------------------------------.
| | 28 | 27 | 26 | 25 | 24 | | | | 0 | 1 | 2 | 3 | 4 | |
|--------+------+------+------+------+-------------| |------+------+------+------+------+------+--------|
| | 33 | 32 | 31 | 30 | 29 | | | | 5 | 6 | 7 | 8 | 9 | |
|--------+------+------+------+------+------| | | |------+------+------+------+------+--------|
| | 38 | 37 | 36 | 35 | 34 |------| |------| 10 | 11 | 12 | 13 | 14 | |
|--------+------+------+------+------+------| | | |------+------+------+------+------+--------|
| | 43 | 42 | 41 | 40 | 39 | | | | 15 | 16 | 17 | 18 | 19 | |
`--------+------+------+------+------+-------------' `-------------+------+------+------+------+--------'
| | 47 | 46 | 45 | 44 | | 20 | 21 | 22 | 23 | |
`----------------------------------' `----------------------------------'
Look into tap_dance.c to see the tap dances defined (currently I am not using all of these, but they are there just in case I change my mind).
-
[
and]
double tapped will get you{
and}
. -
TD_LEAD_MOVE_TO_LAYER_LALT
isKC_LEAD
on single tap, moves to second layer on double tap, andKC_LALT
when held. -
TD_COLON_SEMI_CTRL
isKC_SCOLON
on single tap,Shift+KC_SCOLON
on double tap, andKC_RCTL
when held. (SeeTAP_DANCE_KC1_ON_TAP_SHIFT_KC1_ON_DOUBLETAP_MOD_ON_HOLD(kc1, kc_mod, tap_specific_tapping_term)
).
My tap dances uses a slightly modified utility function to get the tapdance status, that can prefer a hold state when interrupted, see current_dance_status(qk_tap_dance_state_t *state, bool prefer_hold)
.
For the tapdance TD_LEAD_MOVE_TO_LAYER_LALT
I also check the value of the keycode that interrupts, in order to give priority to the held state (KC_LALT
) or the single tap (KC_LEAD
).
Only with these two features in place the tap dances started working for me (aka stopped driving me crazy :)).
Look into leader_stuff.c for the sequences defined.