* move underglow led count from parent to child
* Added pearl support
* Added personal keymap for pearl
* start splitting up ps2avrGB boards
* clean up ps2avrgb boards
* Move keycodes to their own section
* Clarify `KC_PWR` vs `KC_POWER`. Fixes#1994.
* Cleaned uppersonal userspace and keymaps (#1998)
* Cleanup of keymaps
* Remove Tap Dance from Orthodox keymap
* Cleaned up userspace and keymaps
* Added sample (template)userspace files to my folder
* Document the Teensy hardware reset problem
* add mfluid keymap to atreus62
* Update hand_wire.md
Change "Resin" to "Rosin"
* Add keyboard: mt40 (#2001)
* add keyboard: chinese planck clone
* rename chinese_planck to mt40
* add image for the mt40 board
* lets_split: Fix matrix_init for ROW2COL
Signed-off-by: Marian Rusu <rusumarian91@gmail.com>
* Add Keymap for Whitefox Truefox layout
* Add keyboard: ACR60 (#1999)
* base acr60 keyboard folder created
* mitch acr60 keymap updates, documentation
* latest keymap updates
* slight modifications to layer switching
* Changes to Atreus and Ergodox EZ Dvorak 42key layout (#1997)
* importing 42 key dvorak layout
* added comment for build instructions
* adding atreus dvorak 42 key layout
* added readme
* add readme
* build instructions
* additional MEH shortcuts
* added shifted symbols on symbols layer
* working extra symbols on COMBINED layer
* bring atreus layout inline with the ergodox one
* add necessary macros
* working ls macro
* added more shell macros
* added screen rename / screen number macros
* add ctrl-a key in shell-nav to use screen more easily
* added shell screen layer
* assign screen switching macros to screen layer
* define all screen switching macros
* more screen-related shortcuts added on shell screen layer
* change shell nav bottom right row to match base layer (backspace / delete)
* remove some mappings on SHELL_NAV layer as they are now in the screen layer
* added more screen macros
* changes to COMBINED layer (pipe on the right) and modified shell nav
* moved pipe/backslash to then right
* documented SHELL_SCREEN layer
* put backspace/delete on SHELL_NAV layer
* add an explicit lisence file for github to pickup
* Updated keymaps to allow base layer alternation for QWERTY, Colemak & Dvorak (#1962)
* First commit of the Terminus_Mini firmware and the DivergeJM version of the Nyquist firmware
* Fix terminus_mini & nyquist/DivergeJM readme files
Previously an outdated copy of the default readme. Updated to match the Nyquist/DivergeJM format (DivergeJM is a split 5x12 implementation of the terminus_mini layout)
* Update makefiles to rules.mk
Renamed both Makefiles to rules.mk, removed references to makefiles
* Updated rules.mk
Inadvertantly removed important code from the rules.mk in previous commit. This has been restored.
Also disabled Tap_Dance in both rules.mk files
* Moved terminus_mini to handwired
Realised that existing directory was not appropriate for the terminus_mini project, moved to handwired.
* New Frosty Flake layout for QFR TKL
Added a TKL layout for the Frosty Flake with a navigation cluster on LOWER under the left hand and a similarly functioning MOUSE layer that includes mouse navigation functionality.
* README fix & keymap update for 3 keyboards
Fixed the markdown for the handwired/terminus_mini:default, Nyqyist:DivergeJM & frosty_flake:QFR_JM.
Added TAPPING_TERM = 150 to config.h for all keyboards
Switched LT(LOWER) and LAlt on the mod row for ortholinear boards.
* Update readme for QFR_JM to include make instructions
* Revert "Merge branch 'master' of https://github.com/mogranjm/qmk_firmware"
This reverts commit a45f264ada, reversing
changes made to 62349c3341.
* Revert "Revert "Merge branch 'master' of https://github.com/mogranjm/qmk_firmware""
This reverts commit eae54fb3be.
* Added QWERTY support to the QFR_JM
Implemented variable default base layer from the Planck default keymap.
* Update README to reflect QWERTY support
* Nyquist:DivergeJM - Update RESET location
Add a reset button to both hands, accessible when halves are disconnected.
* Typo fix
* Update DivergeJM
Switched master to Left hand,
Moved Reset key to a different location
* Added macros to send R pointer & dplyr pipe
Macros added as a string of keypresses, couldn't figure out how to get SEND_STRING to work.
* Added ADJUST -> QWERTY, DVORAK, COLEMAK
Re-implemented update_tri_layer fuctionality to reset base layer for Terminus_Mini & DivergeJM Nyquist keymaps to QWERTY, DVORAK or COLEMAK via the ADJUST layer.
Updated ReadMe files accordingly.
* Fix base layout diagram for Terminus_Mini
Remove split from diagram
* Changed the R operators to SEND_STRING, rather than keypress macros
* Added Dvorak to the QFR_JM keymap
* fixed duplicate row in Nyquist keymap
* Fix readme - LAlt location on mouse layer
* Set EE_HANDS to allow either Nyquist hand to work as master.
* Update R operator strings, clean up layering for terminus_mini, QFR_JM and DivergeJM
"<-" to " <- "
"%>%" to " %>% "
Also played around with the layering, removed unnecessary TAP_TOGGLE for LOWER and shuffled FUNCTION and MOUSE momentary actions to reflect layer order.
* Update bottom alpha row to output symbols on LOWER
This row now outputs the following (z -> /) when in the LOWER layer:
<-
%>%
{
[
`
|
]
}
.
/
* Updated readme files for QFR_JM, terminus_mini & DivergeJM
QFR_JM readme reflects correct LOWER bottom row symbol output,
terminus_mini & DivergeJM reflect correct command line make instructions.
* Add media keys to QFR_JM LOWER - Replicate QFR default functionality
* Fix issue with Mouse layering
Stuck on mouse layer because the wrong macro was assigned to the 'exit layer' key. Reassigned that key.
* Changed " <- " to "<- " for QFR_JM, terminus_mini & DivergeJM
* Add "KC_MAKE" to userspace example
* QMK DFU bootloader generation (#2009)
* adds :bootloader target
* update planck and preonic revisions
* remove references to .h files for planck
* update preonic keymap
* only add keyboard.h files that exist
* add production target
* hook things up with the new lufa variables
* update rules for planck/preonic
* back backlight key turn of status led when pressed
* add manufacturer/product strings to bootloader
* fix push script
* Added support for let's split kailh socket version (#2010)
* Added support for socket version of the let's split
* renamed files
* socket-version-works
* fix up lets_split keymaps
* fix up lets_split keymaps
* shrink preonic by a bit
* fix lets_split keyboards
* update travis script
* update travis script
* update version silencing
* - Fixed DK60 version in config.h
* - Updated dk60 readme with new QMK rules
* - Fixed wording in readme
* Added dbroqua layout for DZ60
I've also updated dz60.h to add "true HHKD" keymap definition (6U
spacebar).
With the default HHKB definition r_alt was not mapped and when I pressed
r_menu it was r_alt.
Regards
* Updated dbroqua layout for HHKB keyboard
Added default configuration and alternate (swap gui/alt keys).
Save user choice in keyboard memory (like plank, thanks for this
feature!).
* adds :bootloader target
* update planck and preonic revisions
* remove references to .h files for planck
* update preonic keymap
* only add keyboard.h files that exist
* add production target
* hook things up with the new lufa variables
* update rules for planck/preonic
* back backlight key turn of status led when pressed
* add manufacturer/product strings to bootloader
* First commit of the Terminus_Mini firmware and the DivergeJM version of the Nyquist firmware
* Fix terminus_mini & nyquist/DivergeJM readme files
Previously an outdated copy of the default readme. Updated to match the Nyquist/DivergeJM format (DivergeJM is a split 5x12 implementation of the terminus_mini layout)
* Update makefiles to rules.mk
Renamed both Makefiles to rules.mk, removed references to makefiles
* Updated rules.mk
Inadvertantly removed important code from the rules.mk in previous commit. This has been restored.
Also disabled Tap_Dance in both rules.mk files
* Moved terminus_mini to handwired
Realised that existing directory was not appropriate for the terminus_mini project, moved to handwired.
* New Frosty Flake layout for QFR TKL
Added a TKL layout for the Frosty Flake with a navigation cluster on LOWER under the left hand and a similarly functioning MOUSE layer that includes mouse navigation functionality.
* README fix & keymap update for 3 keyboards
Fixed the markdown for the handwired/terminus_mini:default, Nyqyist:DivergeJM & frosty_flake:QFR_JM.
Added TAPPING_TERM = 150 to config.h for all keyboards
Switched LT(LOWER) and LAlt on the mod row for ortholinear boards.
* Update readme for QFR_JM to include make instructions
* Revert "Merge branch 'master' of https://github.com/mogranjm/qmk_firmware"
This reverts commit a45f264ada, reversing
changes made to 62349c3341.
* Revert "Revert "Merge branch 'master' of https://github.com/mogranjm/qmk_firmware""
This reverts commit eae54fb3be.
* Added QWERTY support to the QFR_JM
Implemented variable default base layer from the Planck default keymap.
* Update README to reflect QWERTY support
* Nyquist:DivergeJM - Update RESET location
Add a reset button to both hands, accessible when halves are disconnected.
* Typo fix
* Update DivergeJM
Switched master to Left hand,
Moved Reset key to a different location
* Added macros to send R pointer & dplyr pipe
Macros added as a string of keypresses, couldn't figure out how to get SEND_STRING to work.
* Added ADJUST -> QWERTY, DVORAK, COLEMAK
Re-implemented update_tri_layer fuctionality to reset base layer for Terminus_Mini & DivergeJM Nyquist keymaps to QWERTY, DVORAK or COLEMAK via the ADJUST layer.
Updated ReadMe files accordingly.
* Fix base layout diagram for Terminus_Mini
Remove split from diagram
* Changed the R operators to SEND_STRING, rather than keypress macros
* Added Dvorak to the QFR_JM keymap
* fixed duplicate row in Nyquist keymap
* Fix readme - LAlt location on mouse layer
* Set EE_HANDS to allow either Nyquist hand to work as master.
* Update R operator strings, clean up layering for terminus_mini, QFR_JM and DivergeJM
"<-" to " <- "
"%>%" to " %>% "
Also played around with the layering, removed unnecessary TAP_TOGGLE for LOWER and shuffled FUNCTION and MOUSE momentary actions to reflect layer order.
* Update bottom alpha row to output symbols on LOWER
This row now outputs the following (z -> /) when in the LOWER layer:
<-
%>%
{
[
`
|
]
}
.
/
* Updated readme files for QFR_JM, terminus_mini & DivergeJM
QFR_JM readme reflects correct LOWER bottom row symbol output,
terminus_mini & DivergeJM reflect correct command line make instructions.
* Add media keys to QFR_JM LOWER - Replicate QFR default functionality
* Fix issue with Mouse layering
Stuck on mouse layer because the wrong macro was assigned to the 'exit layer' key. Reassigned that key.
* Changed " <- " to "<- " for QFR_JM, terminus_mini & DivergeJM
* importing 42 key dvorak layout
* added comment for build instructions
* adding atreus dvorak 42 key layout
* added readme
* add readme
* build instructions
* additional MEH shortcuts
* added shifted symbols on symbols layer
* working extra symbols on COMBINED layer
* bring atreus layout inline with the ergodox one
* add necessary macros
* working ls macro
* added more shell macros
* added screen rename / screen number macros
* add ctrl-a key in shell-nav to use screen more easily
* added shell screen layer
* assign screen switching macros to screen layer
* define all screen switching macros
* more screen-related shortcuts added on shell screen layer
* change shell nav bottom right row to match base layer (backspace / delete)
* remove some mappings on SHELL_NAV layer as they are now in the screen layer
* added more screen macros
* changes to COMBINED layer (pipe on the right) and modified shell nav
* moved pipe/backslash to then right
* documented SHELL_SCREEN layer
* put backspace/delete on SHELL_NAV layer
* More keymap fixes. F-row on bottom layer wasn't fully setup, also switched raise/lower keys to use tap-toggle.
* Added PrScr, put Tab back on top layer.
* Fixed build breakage with default keymap (unneeded rgblight.h include)
* Add yuuki keymap
Documentation is still a TODO and the keymap may not be final
* GRV on colon
* add KC_GRV to FN ESC
* more RGB modes
* Update README.md
Add image of layout and fix typo
* switch from jpg to png
For some reason the JPG had red outlines around the keys.
* remove whitespace
* add instruction to reset keyboard before flashing
* gh60 stytle layout
* moved the GH60 style layout to new folder
* add HOME and END
* Add heading
* moved ayanami to other branch
* restructure converters
each converter is its own keyboard and different hardware variants are different subprojects.
remove (seemingly) old method of loading layouts from main Makefile
* call led_set_kb() from overridden led_set()
* put converter back into one folder
* revert some structure changes to bring in line with #1784.
Also attempt to get the BLE thing more properly integrated.
Also also fix led_set() to call led_set_kb().
* Add woodpad
* Cleanup
* Remove misc layouts for woodpad
* Move woodpad to handwired
* Updated RGB Underglow info
* Cleanup macros
* Tweaked RGB lighting stuff
* Start to merge orthodox/ergodox keymaps (persistant layers)
* Add woodpad
* Add forced NKRO
* Added default layer (qwerty/colemak/dvorak) detection to RGB Underglow
* Updated macros and added workman keymaps
* Fixed RGB lighting for Workman layout
* Add leader keys
* Remove force NKRO
* Add Viterbi one handed layout and minor tweaks to others
* Finishing up Viterbi keyboard layout, and NKRO tweaks to other layouts
* Made "make" keystroke universal
* Clean up and updates of drashna keymaps
* Add workman layer to planck
* Update to keymaps
* Fix makefile toggle code in ez keymap
Finish adding RGB code to orthodox
* Updated RGB Underglow layer indication code due to discovery of the layer_state_set_kb function
* Remove unnecessary planck layout
* Fixed Workman song
* update make command and added lit reset
* Fixed formatting to fall in line with official standards
* Minor tweaks
* Removed Leader Keys from Ergodox EZ Keymap
Added KC_RESET that resets board and sets underglow to red
* Tweak reset code
* Cleanup
* Remove misc layouts for woodpad
* Move woodpad to handwired
* Updated RGB Underglow info
* Cleanup macros
* Tweaked RGB lighting stuff
* Start to merge orthodox/ergodox keymaps (persistant layers)
* Add forced NKRO
* Added default layer (qwerty/colemak/dvorak) detection to RGB Underglow
* Updated macros and added workman keymaps
* Fixed RGB lighting for Workman layout
* Add leader keys
* Remove force NKRO
* Add Viterbi one handed layout and minor tweaks to others
* Finishing up Viterbi keyboard layout, and NKRO tweaks to other layouts
* Made "make" keystroke universal
* Clean up and updates of drashna keymaps
* Add workman layer to planck
* Update to keymaps
* Fix makefile toggle code in ez keymap
Finish adding RGB code to orthodox
* Updated RGB Underglow layer indication code due to discovery of the layer_state_set_kb function
* Remove unnecessary planck layout
* Fixed Workman song
* update make command and added lit reset
* Fixed formatting to fall in line with official standards
* Minor tweaks
* Removed Leader Keys from Ergodox EZ Keymap
Added KC_RESET that resets board and sets underglow to red
* Tweak reset code
* Fix rebasing issues
* remove head files
* Fix "macro" issue
* Rename ez keymaps for userspace
* Revert "Rename ez keymaps for userspace"
This reverts commit c25425911852e41711a5f0273b5741adb16e5bd4.
* Renamed Ergodox EZ layouts so that all of my personal layouts are on the same name, in prep for using userspaces
* Fix ergodox code
* Remove "drashna-ez" keymap as it's no longer needed
* Migrate majority of code to Userspace
* Add woodpad
* Cleanup
* Remove misc layouts for woodpad
* Move woodpad to handwired
* Updated RGB Underglow info
* Cleanup macros
* Tweaked RGB lighting stuff
* Start to merge orthodox/ergodox keymaps (persistant layers)
* Add woodpad
* Add forced NKRO
* Added default layer (qwerty/colemak/dvorak) detection to RGB Underglow
* Updated macros and added workman keymaps
* Fixed RGB lighting for Workman layout
* Add leader keys
* Remove force NKRO
* Add Viterbi one handed layout and minor tweaks to others
* Finishing up Viterbi keyboard layout, and NKRO tweaks to other layouts
* Made "make" keystroke universal
* Clean up and updates of drashna keymaps
* Add workman layer to planck
* Update to keymaps
* Fix makefile toggle code in ez keymap
Finish adding RGB code to orthodox
* Updated RGB Underglow layer indication code due to discovery of the layer_state_set_kb function
* Remove unnecessary planck layout
* Fixed Workman song
* update make command and added lit reset
* Fixed formatting to fall in line with official standards
* Minor tweaks
* Removed Leader Keys from Ergodox EZ Keymap
Added KC_RESET that resets board and sets underglow to red
* Tweak reset code
* Cleanup
* Remove misc layouts for woodpad
* Move woodpad to handwired
* Updated RGB Underglow info
* Cleanup macros
* Tweaked RGB lighting stuff
* Start to merge orthodox/ergodox keymaps (persistant layers)
* Add forced NKRO
* Added default layer (qwerty/colemak/dvorak) detection to RGB Underglow
* Updated macros and added workman keymaps
* Fixed RGB lighting for Workman layout
* Add leader keys
* Remove force NKRO
* Add Viterbi one handed layout and minor tweaks to others
* Finishing up Viterbi keyboard layout, and NKRO tweaks to other layouts
* Made "make" keystroke universal
* Clean up and updates of drashna keymaps
* Add workman layer to planck
* Update to keymaps
* Fix makefile toggle code in ez keymap
Finish adding RGB code to orthodox
* Updated RGB Underglow layer indication code due to discovery of the layer_state_set_kb function
* Remove unnecessary planck layout
* Fixed Workman song
* update make command and added lit reset
* Fixed formatting to fall in line with official standards
* Minor tweaks
* Removed Leader Keys from Ergodox EZ Keymap
Added KC_RESET that resets board and sets underglow to red
* Tweak reset code
* Fix rebasing issues
* remove head files
* Fix "macro" issue
* Rename ez keymaps for userspace
* Revert "Rename ez keymaps for userspace"
This reverts commit c25425911852e41711a5f0273b5741adb16e5bd4.
* Renamed Ergodox EZ layouts so that all of my personal layouts are on the same name, in prep for using userspaces
* Fix ergodox code
* Remove "drashna-ez" keymap as it's no longer needed
avoid the following error when `UNICODEMAP_ENABLE = yes`:
```
quantum/process_keycode/process_unicodemap.c:52:21: error: implicit declaration of function 'pgm_read_dword'
```
* Set up tap dance for layers on the lower button.
* Refactored code to share in the users directory between my two keyboard layouts.
* Small keyboard layout change.
* Updated documentation on oneshot usage in macros/tap dance.
* importing 42 key dvorak layout
* added comment for build instructions
* adding atreus dvorak 42 key layout
* added readme
* add readme
* build instructions
* additional MEH shortcuts
* added shifted symbols on symbols layer
* working extra symbols on COMBINED layer
* bring atreus layout inline with the ergodox one
* add necessary macros
* working ls macro
* added more shell macros
* added screen rename / screen number macros
* add ctrl-a key in shell-nav to use screen more easily
* added shell screen layer
* assign screen switching macros to screen layer
* define all screen switching macros
* more screen-related shortcuts added on shell screen layer
* change shell nav bottom right row to match base layer (backspace / delete)
* remove some mappings on SHELL_NAV layer as they are now in the screen layer
* added more screen macros
* Fix RGBLIGHT startup color
While it's awesome to see the layer indicating code in here (no really!), and the general rule is to not alter the default keymap/code....
The problem with the layer_state_set_kb call handling this, is that the code doesn't seem to be called at startup. So the default layer color won't ever get set on startup. It needs to be called in the init function to be properly set.
I've played with this extensively, and if you check my keymaps, that is precisely why I have the setrgb/sethsv in the init function.
* Removed typo (pipe)
* mitosis/datagrok: reduce features from rules.mk
* mitosis/datagrok: make both layer keys neighbor shift
* mitosis/datagrok: (no-op) tweak some comments
* mitosis/datagrok: set baudrate to 250k
This requires a corresponding change to the mitosis wireless firmware:
https://github.com/reversebias/mitosis/pull/10
* mitosis/datagrok: move design description from code comment to a readme
* mitosis/datagrok: new layout, new shifted keys, efficient LED code
This is experimental, but compiles and seems to work correctly.
* mitosis/datagrok: whoops, move readme.md
* mitosis/datagrok: a minor layout improvement simplifies custom-shifted code
instead of [, .] [? !], using [, ?] [. !] greatly simplifies the code
needed to perform the shifted-key switching. (And keeps , and . on the
same keys that they are under qwerty.)
also: layout improvements for symbols
* mitosis/datagrok: make my code conform to QMK style guidelines
* mitosis/datagrok: TODO note for layout table in README
* mitosis/datagrok: remove led_set_user until i figure out other changes
need to see if the corresponding changes needed in the keyboard-level code
is okay.
* mitosis/datagrok: simpler layer indicator
* mitosis/datagrok: undo change to keyboard baud; make it in my layout dir.
* mitosis/datagrok: apply same punctuation hack to qwerty layer
* mitosis/datagrok: enable qwerty layer toggle
* mitosis/datagrok: update readme
* Add satan keymap: HHKB-alike based on dbroqua's, with mouse functionality and without LED functionality
* move mouse layer to DOUBLE_HOLD, add UTIL layer for TRIPLE_HOLD
- UTIL layer
- currently has "RESET" key and nothing else.
- functionality otherwise covered by bootmagic should go here
- small bugfix: dispatch of [QTY]_HOLD should be based on range tap count
falls in, not exact count.
* Added support for Knops Mini (3x2 macropad) keyboard.
* Added better documentation, according to the QMK standards.
* Fixed typo.
* Changed names of files to comply with QMK standards.
* Ignored makefile in keymap.
* Removed makefiles and added my credentials in the copyrights.
* adds .qmk file type as a target
* adds info.json with vendor and product
* add files for qmk info script
* add layout file for planck
* ignore .qmk files
* more settings
* update rules for avr and chibios
* update .qmk generation for info.json and inheritence
* Typo: Github => GitHub
* Typo: windows => Windows, docker => Docker, and some punctuations
* "QMK Introduction" links to the right file
* "Unix" rather than "UNIX", which is a trademark
* Directory name is "keyboards", not "keyboard"
* "handwired" is a subdirectory of "keyboards"
* Punctuation and minor fixes
* macOS rather than Mac
* Punctuation and other minor fixes
* Vagrant Guide links to an existing file
* Jun Wako referenced with his name rather than his nickname
* Saxon genitive 's outside the link
* Add woodpad
* Cleanup
* Remove misc layouts for woodpad
* Move woodpad to handwired
* Updated RGB Underglow info
* Cleanup macros
* Fix odd merge issue
* Tweaked RGB lighting stuff
* Start to merge orthodox/ergodox keymaps (persistant layers)
* Add forced NKRO
* Added Colemak and Dvorak layers to default orthodox keymap
* Added default layer (qwerty/colemak/dvorak) detection to RGB Underglow
* Updated macros and added workman keymaps
* Fixed RGB lighting for Workman layout
* Add leader keys
* Remove force NKRO
* Add Viterbi one handed layout and minor tweaks to others
* Finishing up Viterbi keyboard layout, and NKRO tweaks to other layouts
* Made "make" keystroke universal
* Clean up and updates of drashna keymaps
* Add workman layer to planck
* Update to keymaps
* Fix accidental commit because I don't know how to git
* Fix makefile toggle code in ez keymap
Finish adding RGB code to orthodox
* missing underscore in init function declaration
* Updated RGB Underglow layer indication code due to discovery of the layer_state_set_kb function
* Remove unnecessary planck layout
* Created Kona Classic config
* Fixed KonaClassic config
* Updated README
* Updated Readme to conform to format standards
* Added ANSI and ISO layout options
* Fixed images in Readme
* Added labels to images
* Added absolute links to images in Readme
* Image link updates again
* Fixed bottom row keys in some layouts
* Fixed Grave and Tilde
* Fixed Underglow in Kona Classic configs
* Renamed KonaClassic to kona_classic
* add RETRO_TAP: tap anyway, even after TAP_TERM, if no interruption
* consistent variable name
* add option doc
* change name for consistency
* make RETRO_TAPPING default to off
* 🔧 add editorconfig
This makes supported editors automatically change their settings to match desired code styles
* 🔧 add extension recommendation for VSCode
This will cause VS Code to prompt the user to install the EditorConfig extension when they open the project.
If this is felt to be too opinionated, I can revert it.
* Fix pointer device options
when the feature was added, the appropriate option definition wasn't created. This needs to be added to function properly.
* Update common_features.mk
* missing underscore in init function declaration
I'm almost 100% sure "else if (state->count = 2) {" was a typo (it should have two ='s for a logical operator), and I'm *pretty* sure "if (state->interrupted || state->!pressed) return SINGLE_TAP;" has a typo. At least, it returns an error on my machine saying something about an unexpected '!'.
I changed it to a slightly longer form (i.e., "state->pressed==0"), and that worked fine.
* First commit of the Terminus_Mini firmware and the DivergeJM version of the Nyquist firmware
* Fix terminus_mini & nyquist/DivergeJM readme files
Previously an outdated copy of the default readme. Updated to match the Nyquist/DivergeJM format (DivergeJM is a split 5x12 implementation of the terminus_mini layout)
* Update makefiles to rules.mk
Renamed both Makefiles to rules.mk, removed references to makefiles
* Updated rules.mk
Inadvertantly removed important code from the rules.mk in previous commit. This has been restored.
Also disabled Tap_Dance in both rules.mk files
* Moved terminus_mini to handwired
Realised that existing directory was not appropriate for the terminus_mini project, moved to handwired.
* New Frosty Flake layout for QFR TKL
Added a TKL layout for the Frosty Flake with a navigation cluster on LOWER under the left hand and a similarly functioning MOUSE layer that includes mouse navigation functionality.
* README fix & keymap update for 3 keyboards
Fixed the markdown for the handwired/terminus_mini:default, Nyqyist:DivergeJM & frosty_flake:QFR_JM.
Added TAPPING_TERM = 150 to config.h for all keyboards
Switched LT(LOWER) and LAlt on the mod row for ortholinear boards.
* Update readme for QFR_JM to include make instructions
* Revert "Merge branch 'master' of https://github.com/mogranjm/qmk_firmware"
This reverts commit a45f264ada, reversing
changes made to 62349c3341.
* Revert "Revert "Merge branch 'master' of https://github.com/mogranjm/qmk_firmware""
This reverts commit eae54fb3be.
* Added QWERTY support to the QFR_JM
Implemented variable default base layer from the Planck default keymap.
* Update README to reflect QWERTY support
Previously, this code was implemented in keymap.c, but I'm unaware of
someone with a different implementation of this particular hack. [If
someone has it, we can add another #ifdef in the future.]
* Added personal minivan keymap
more consistent layer setup
documentation!
slide some things around
more doc jiggling
* Small layout and documentation tweaks
Small documentation updates
dropped Makefile that for some reason was still in my branch
* found and removed extra makefile
* added bfake support as a subproject
also moved existing bmini stuff to a subproject
fixed columns
minor keymap update
making this a subproject
remove old stuff
got subproject stuff figured out
* travis was upset because a board didn't have a default keymap
This commit adds a new keycode `RGB_SMOD` which is the same as `RGB_MOD` (cycle through all modes),
but when it is used in combination with shift it will reverse the direction.
* - Fixed DK60 version in config.h
* - Updated dk60 readme with new QMK rules
* - Fixed wording in readme
* Added dbroqua layout for DZ60
I've also updated dz60.h to add "true HHKD" keymap definition (6U
spacebar).
With the default HHKB definition r_alt was not mapped and when I pressed
r_menu it was r_alt.
Regards
* First commit of the Terminus_Mini firmware and the DivergeJM version of the Nyquist firmware
* Fix terminus_mini & nyquist/DivergeJM readme files
Previously an outdated copy of the default readme. Updated to match the Nyquist/DivergeJM format (DivergeJM is a split 5x12 implementation of the terminus_mini layout)
* Update makefiles to rules.mk
Renamed both Makefiles to rules.mk, removed references to makefiles
* Updated rules.mk
Inadvertantly removed important code from the rules.mk in previous commit. This has been restored.
Also disabled Tap_Dance in both rules.mk files
* Moved terminus_mini to handwired
Realised that existing directory was not appropriate for the terminus_mini project, moved to handwired.
* New Frosty Flake layout for QFR TKL
Added a TKL layout for the Frosty Flake with a navigation cluster on LOWER under the left hand and a similarly functioning MOUSE layer that includes mouse navigation functionality.
* Add existing file
* Add new keyboard layout - initial commit
* Revised readme.md
* Clarified readme.md, reorganized keymap.c, and added license text.
* Fixing last incomplete commit
* Just a little code cleanup to make things more readable.
* Add carvac_dv keymap for mitosis
* Add mouse keys
* move backspace, etc, and fix tab
* remove commented-out functions in keymap
* Fix scroll buttons and add left/right scrolling
* Make num momentary, add comments, and clean up
* fix mouse scroll acceleration
* Add tab, remove bksp, move print screen
Having tab next to control and alt makes for much easier
alt-tabbing and ctrl-tabbing.
That displaced print screen, but I had never used the non-layer
backspace on the right hand, so I moved printscreen over there.
* - Fancy default PID and option for corresponding VID.
- Information about official VID/PID.
- Correct manufacturer name.
- NKRO enabled by default.
* Resolved build error with `#ifndef FORCE_NKRO`.
* Clone Nyquist code to Iris and rename
* Set keymap and pins
* Work in progress Iris default keymap
* Add Iris rev2
* Update Iris files to new build system
* Add lewisridden keymap
* Added section to example, detailing how to accomplish the
'quad-function' tap dance.
* Refactored TD documentation to clearly separate different complex
examples
Change-Id: Ifc1495d1142849c771418fdabc458c04c48311e6
* Address #1689 by using a formula to define the breathing curve and exposing defines to control the shape of the curve.
* Tweak the behavior of breathing for clueboard
* First commit of the Terminus_Mini firmware and the DivergeJM version of the Nyquist firmware
* Fix terminus_mini & nyquist/DivergeJM readme files
Previously an outdated copy of the default readme. Updated to match the Nyquist/DivergeJM format (DivergeJM is a split 5x12 implementation of the terminus_mini layout)
* Update makefiles to rules.mk
Renamed both Makefiles to rules.mk, removed references to makefiles
* Updated rules.mk
Inadvertantly removed important code from the rules.mk in previous commit. This has been restored.
Also disabled Tap_Dance in both rules.mk files
* Moved terminus_mini to handwired
Realised that existing directory was not appropriate for the terminus_mini project, moved to handwired.
* redo make args to use colons, better folder structuring system [skip ci]
* don't put spaces after statements - hard lessons in makefile development
* fix-up some other rules.mk
* give travis a chance
* reset KEYMAPS variable
* start converting keyboards to new system
* try making all with travis
* redo make args to use colons, better folder structuring system [skip ci]
* don't put spaces after statements - hard lessons in makefile development
* fix-up some other rules.mk
* give travis a chance
* reset KEYMAPS variable
* start converting keyboards to new system
* try making all with travis
* start to update readmes and keyboards
* look in keyboard directories for board.mk
* update visualizer rules
* fix up some other keyboards/keymaps
* fix arm board ld includes
* fix board rules
* fix up remaining keyboards
* reset layout variable
* reset keyboard_layouts
* fix remainging keymaps/boards
* update readmes, docs
* add note to makefile error
* update readmes
* remove planck keymap warnings
* update references and docs
* test out tarvis build stages
* don't use stages for now
* don't use stages for now
* add ymd96 base
currently not working correctly.
* Update
honestly not really sure what I've been doing but I'm just more or less brute forcing this until I can get the pcb schematic or something
* honestly just trying stuff out
* Update keymaps
Getting closer hopefully
* ymd96 works!
at least for me
* Update readme
* Update readme
* Update readme
* Adds support for multiple layouts. Adds custom keymap for "offset"
layout.
* Adds a tool to help detach the keyboard from the Linux HID driver before programming.
* Adds a tool to help detach the keyboard from the Linux HID driver before programming.
- a keyboard already in bootloader mode will now be detected
- if setting the keyboard to bootloader mode doesn't work, a hint will be printed on how to do so
- instead of failing instantly when no keyboard is found, the script will now wait up to 60 seconds (it retries every 5 seconds, up to 12 times)
At one time, "ez" and "infinity" may have been subprojects of a
unified "ergodox" project, but this is not currently the case. Running
`make ergodox-ez-default-teensy` (or similar), as the documentation
currently implies, does not work.
neue Datei: keyboards/lets_split/keymaps/DE_simple/config.h
neue Datei: keyboards/lets_split/keymaps/DE_simple/keymap.c
neue Datei: keyboards/lets_split/keymaps/DE_simple/rules.mk
* slight modifier changes; added plover and reusing jack's default planck keymap as the basis
* space is not shift when held anymore
* added fabian layout (based on jack's default)
* changed fabian layout (based on jack's default)
* changed fabian layout (based on jack's default)
* Fix mbsurfer let's split layout RGB indicators when both lower and raise are pressed
* Update mbsurfer let's split keymap with new RGB key codes for modes
* Clean up mbsurfer keymap matrix layout
Overall changes
===============
* Updated to work with QMK master.
* The `$` and `^` symbols on the number row were swapped on both the base and
the ADORE layers.
* The bracket tap-dance keys can now be used to input Japanese brackets, `「`
and `」` with a third tap.
* The second column of the top row on the right side will act as a "Social"
application selector on the `AppSel` layer.
* The third key on the same column will select a password manager.
* The `GUI` key will now launch `rofi` when triple-tapped.
Miscellaneous
=============
* The `👶` symbol can be entered with UCIS.
* The `👪` symbol can be entered with UCIS.
Tools
=====
* `tools/hid-commands` can now find the `Mstdn`, not just `Slack`, as the
"Slack"/chat app.
* `tools/hid-commands` can now find the Plex web app as a music/media player.
* `tools/hid-commands` now understands the "Social" application selector. It
raises the `Mstdn` and `Tweetdeck` windows, but keeps focus on the previous
window.
* `tools/hid-commands` now understands the "Social2" application selector, which
raises `Signal` and `Viber`, but keeps focus on the previous window.
* `tools/hid-commands` is now able to select a password manager (KeePass*).
* `tools/hid-commands` can now run `rofi` when receiving an `appsel_helper`
command (triggered by a triple-tapped `GUI` key).
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
* initial clueboard_60 support
* LED lighting support
* fix the clueboard->clueboard_66 rename
* Add layout support to clueboard_60
* Fix the 60_iso layout so it's actually iso
* add a default keymap for AEK layout
* fix clueboard_17
* Fixup the ISO layouts
* Fix the `wait_ms()/wait_us()` definitions for chibios
* Fix up the wait_ms/wait_us hack. Reduce stack size.
* Add a missing #include "wait.h"
* commit files that should have already been comitted
* Support for KBP V60 Type R 60% keyboard
Support does not include in switch or underglow lighting for Polestar Edition.
* rename v60type_r to v60_type_r
* Remove old v60type_r
* Modify readme.md to adhere with QMK readme formatting.
tearing it down so that it can be rebuilt
fiddling with audio
big default config overhaul
apparently startup sounds work without the override now
readme!
readme fixes
readme tweaking
* Add yuuki keymap
Documentation is still a TODO and the keymap may not be final
* GRV on colon
* add KC_GRV to FN ESC
* hhkb ish
* hhkbish 2
* HHKBish and documentation
* Fix Markdown warnings
* typo
* phreed keymap added
This keymap moves many pinky keys to the center
* set to do what I want but LT() does not return to previous layer
* get overlays working
* get overlays working
* fix the readme
* fix the readme
* swapped the shift
* swapped the shift
* propagate mods
* clear special char on readme
* Implement sticky modifiers
* Change underglow based on sticky mod status
* Set RGB lights based on which mods are stickied
* Add controls for dimming RGB LEDs
* Only update RGB lights if modifiers have changed
* Use all LEDs to show modifier state
* Create default keymap for Viterbi
* Duplicate default layout as basis of my own
* Basic Colemak layer, just to practice flashing
* Add reset button so that we don't have to short out the reset button on the board to flash it.
* Symbols layer
* Navigation layer, and remove unused keys. Now usable, nice.
* Correct backspace for UK QWERTY mapping
* Small clarification in XD75RE readme instructions
* Use UK pipe so that I can type a pipe on a UK keyboard
* adding new layout for the planck that helps when coming from the pok3r
* Fixing the function layer
* Update readme.md
* Update keymap.c
Making some small adjustments
* Update keymap.c
switching GUI and Esc
* Update keymap.c
* changed 'infinity' to 'ergodox_infinity' and specified to be in the top-level directory as per recent changes to directory structure of QMK_firmware git repo
* accidently removed '-' in last line of readme
* add new RGB keycodes and clean up lets split keymap
* extraneous cases
* More cleanup and added macro
* one more macro
* cleaned up my planck keymap and added macros
* Transitioned planck keymap to new formatting / audio modes based on new default
* Remove extraneous newline in song list, add keycodes missed in previous commit
* error in graphical representation of keycodes
* Merge with upstream
* Finish merge
* Add new keymap
* Change use of KEYMAP macro
* Add Readme.md
* Fix link
* Clean up comments
* Raise on leading edge of keypress
* Add HOME/END keys as upper/lower on arrow-up/down
* Reduce .hex file size by turning off unneeded options
* Put digit keypad onto left hand upon RAISE; this will sometimes be preferable to double-hits of right hand
* Latest super latest version merge
* cbbrowne keymap for XD75re
* starting notes on XD75re keymap plans
* First draft of bottom row of QWERTY
* Switch my special bottom line over to QCENT
* Dunno
* Filling in wanted keys, bit by bit...
* Add copyright, extra macro
* Clean up comments, remove some experimental code I didn't like
* TODO plans for xd75re
* clean up keyboard layout
* QCENT2 is my new experiment for the main keyboard...
* Add a few more main layer keys, and modify LOWER to shift things outwards to conform with main layer
* Clean up RAISE layer to conform with main layer, remove QCENT layer as QCENT2 is the new thing
* More xd75 changes, now that I actually have it in hand
* shift keymap around, as original attempt was a bit too aggressive in keeping to the edges
* more revs to XD75
* Dropping parts of the centre keypad in favor of Keys I Really Need
* Improve documentation to conform with how builds are done now
* Improve documentation to conform with how builds are done now
* Add cbbrowne rules file as alternative to having the rules in Makefile
* Makefile not needed anymore for individual keymap
* Remove all Makefiles from the keyboards directory.
* update keymaps added in the last 8 days
* Ignore keyboard/keymap makefiles
* update hand_wire to reflect our new Makefile-less reality
* Update the make guide to reflect the new reality
* move planck keymap options to rules.mk
* update planck keymaps 4real
* trigger travis
* add back build_keyboard.mk
* restore changes to build_keyboard
* Allow the knight animation to be restricted to a portion of the LED strip
* Add keys for jumping directly to particular animation modes
* Remove orphaned break statements
* Tweak the `RGB_MODE` buttons so they cycle through the same mode.
* small indentation fix
* Add a new revision of the clueboard with 18 underlight LEDs
* Allow the knight animation to be restricted to a portion of the LED strip
* Add keys for jumping directly to particular animation modes
* Remove orphaned break statements
* Tweak the `RGB_MODE` buttons so they cycle through the same mode.
* small indentation fix
`avr-libc` is no longer, and it's called `avr-gcc` now. https://github.com/osx-cross/homebrew-avr
Also you need `gcc-arc-none-eabi` to be able to compile in my experience.
* copied mjt keymaps from archive
* All mjt boards now compile
* fixed jd45-mjt breathing
* Updates to fix SpaceFN but not tested yet.
* Still missing either spacebar or an adjacent keypress.
* Debugging rigged up for use with hid_listen.
* Reverted the default keymap to use tap_layer_key rather than custom. Moved custom approach to keymap_debug.c
* Fixed the lower-left side of the keymap, which needed more spacers due to the matrix being directly put into the array rather than using the keymap function.
* Cleaned up JD45 keymap that uses tapkey.
* Redid minivan keymap with numsym rather than raise/lower.
Untested.
* Created my MJT keymap for HHKB
Enabled dynamic macros and moved
somoe of the shortcuts around.
* Minor keymap fixes to make them compile without errors.
* Added home/end to right arrow cluster on DYN layer.
* Added more keys to fn and dyn layers.
* It wasn't using my custom layer last time somehow...? Now it will.
* Compiled and installed at end of day on 8/23
* Moved macros to FKEY layer because Adjust was too hard to get into and out of without some sort of feedback.
* Fixed volume controls... were reversed and disabled.
* Added F13-F15 back to fkeys layer in Minivan
* Created new Planck Keymap that uses the NumSym and FKeys layer approach like the Minivan.
* Removed DYN layer.
* Fixed diagram in planck numsym.
* Cleanup for pull request.
* Roadkit flip phone warning.
* Replaced PLAY_NOTES_ARRAY to PLAY_SONG
* reset the submodules
* checked out specific commits for submodules
* Removed debugging from JD45 shared config.h
* Moved custom rules.mk to apropriate keymap
Reset the shared rules.mk file.
* Trailing return issue in rules.mk
Gotta make for a smooth pull request :-)
* Mitosis music troubleshooting
Also updated the song playing function.
Does not work currently.
* Fixed mitosis audio
* Put mitosis/rules.mk back to QMK master
* copied mjt keymaps from archive
* All mjt boards now compile
* fixed jd45-mjt breathing
* Updates to fix SpaceFN but not tested yet.
* Still missing either spacebar or an adjacent keypress.
* Debugging rigged up for use with hid_listen.
* Reverted the default keymap to use tap_layer_key rather than custom. Moved custom approach to keymap_debug.c
* Fixed the lower-left side of the keymap, which needed more spacers due to the matrix being directly put into the array rather than using the keymap function.
* Cleaned up JD45 keymap that uses tapkey.
* Redid minivan keymap with numsym rather than raise/lower.
Untested.
* Created my MJT keymap for HHKB
Enabled dynamic macros and moved
somoe of the shortcuts around.
* Minor keymap fixes to make them compile without errors.
* Added home/end to right arrow cluster on DYN layer.
* Added more keys to fn and dyn layers.
* It wasn't using my custom layer last time somehow...? Now it will.
* Compiled and installed at end of day on 8/23
* Moved macros to FKEY layer because Adjust was too hard to get into and out of without some sort of feedback.
* Fixed volume controls... were reversed and disabled.
* Added F13-F15 back to fkeys layer in Minivan
* Created new Planck Keymap that uses the NumSym and FKeys layer approach like the Minivan.
* Removed DYN layer.
* Fixed diagram in planck numsym.
* Cleanup for pull request.
* Roadkit flip phone warning.
* Replaced PLAY_NOTES_ARRAY to PLAY_SONG
* reset the submodules
* checked out specific commits for submodules
* Removed debugging from JD45 shared config.h
* Moved custom rules.mk to apropriate keymap
Reset the shared rules.mk file.
* Trailing return issue in rules.mk
Gotta make for a smooth pull request :-)
* include variables and .h files as pp directives
* start layout compilation
* split ergodoxes up
* don't compile all layouts for everything
* might seg fault
* reset layouts variable
* actually reset layouts
* include rules.mk instead
* remove includes from rules.mk
* update variable setting
* load visualizer from path
* adds some more examples
* adds more layouts
* more boards added
* more boards added
* adds documentation for layouts
* use lowercase names for LAYOUT_
* add layout.json files for each layout
* add community folder, default keymaps for layouts
* touch-up default layouts
* touch-up layouts, some keyboard rules.mk
* update documentation for layouts
* fix up serial/i2c switches
Turns out that 3c and 3d are not reversed when splitting the right
shift in the way that the Mark I layout does. Reversing it here, rather
than in the generic satan.h to avoid breaking the other layouts.
Fix and issue with the original Sentraq S60-X not being compatible with 'default'. If 'default' shouldn't be changed, perhaps I can create an 'original' revision.
It looks like build_environment_setup.md got renamed to
getting_started_build_tools.md in this commit:
commit e6c638bed1
Author: skullY <skullydazed@gmail.com>
Date: Sat Aug 5 20:54:34 2017 -0700
Overhaul the Getting Started section and add a FAQ section
docs/{build_environment_setup.md => getting_started_build_tools.md} | 132 ++++++++++++++++++++++++++++++++++++-------------------------------------
This commit adjusts the links to match the new name.
Updated MiniDox split_util.h and eeprom files to reflect this change.
I recommend adding this to any split board that used these files, my changes will not effect them currently.
This adds the `ACTION_TAP_DANCE_DUAL_ROLE` helper, which makes it easy to have
keys that act as a key on the first tap, and as a layer toggle on the second.
Fixes#1532, reported by @Ptomerty.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
[Colemak Mod-DH](https://colemakmods.github.io/mod-dh/) layout for
users keeping an `azerty` layout configuration on their OS.
The symbols layers was done after analysing various programming
languages sources codes and should be close to optimal for typing
confort.
The let's split code used delays in its debouncing algorithm which
increases input latency. This commit copies and adapts the code from
`quantum/matrix.c` to lets_split's `matrix.c`.
This protocol breaks out "duplicate" keys into their own entry in the packet so that more complicated logic can be done on the software side, including support for additional languages and alternative theories.
Requires virtser; Allows QMK to speak the TX BOlt protocol used by stenography machines and software (such as Plover). The upside is that Plover can be configured to listen only to TX Bolt allow the keyboard to switch layers without need to enable/disable the Plover software, or to have a second non-Steno keyboard work concurrently.
* merge
* line ending stuff
* Added MiniDox keyboard folder / configs / and some keymaps
* Updated minidox rev1 config, and readme. Also updated that_canadian keymap to include RGB
* cleaned up that_canadian keymap comments
* Fixed RGB being enabled by default, now it must be turned on at the keymap level
This introduces a grep dependency, which I believe we didn't have
before, but it should be available and installed by default on all the
supported systems.
This is a setup that is very useful for me. It may or may not be for
you. I will use it in conjunction with the A5 overlayed sv_SE layout.
The layout is subject to change (in particular I'm thinking about adding
a macro recording feature), but it have not changed much the past year
or two so you can expect it to be stable enough to learn it.
A5: http://aoeu.info/s/dvorak/svorak
My xkb map: https://github.com/lindhe/dotfiles/blob/master/usr/share/X11/xkb/symbols/se-A5
The most major points:
======================
L0:
---
* Easily accessible F11 key for fullscreening
* Print screen
* Middle mouse button for X-paste
* Improved reachability of meta buttons (LCtrl, LALt, AltGr, LGui etc.)
* Cluster Page Up/Down + Home/End by the right thumb
* Vim-like arrow layout in right bottom row
* Set media layer toggle to right thumb (Enter)
* Set apostrophe on LCtl (putting it next to some other small
characters)
L1:
---
* Full function key layout
* Teensy button
L2:
---
* Improved media buttons layout (close by the jkl; Vim binding)
* Improved layout of emulated mouse buttons
LED behaviour to binary+CAPS
============================
The ErgoDox LEDs on this layout is using the two rightmost LEDs as the
two LSB in a two digit binary number, representing layer 0, 1, 2 and 3.
The leftmost byte/LED indicates CAPS status.
Instead of having all sendstring keycode mappings in the main quantum.c
file, give each one its own file in keymap_extras that can be #included
in a user's keymap. If one is included, it will define the appropriate
lookup tables and overwrite the weak definitions in quantum.c.
(Including more than one sendstring definition will fail at compile
time.)
Update @rai-suta's test keymap to match, as well as the documentation.
Refactor new-ish JIS_KEYCODE send_string implementation with existing
send_string
Reshuffle JIS in line with other alternative keycodes for sendstring,
and make them all accessible via compile-time options
Add a separate function to allow sending a string with a delay.
* Move Space Caded Parentheses to own layer
The space cadet parentheses where too much distracting. Therefore they are now on the function layer. I also added two more layers for also having angle brackets and curly braces on the shift keys forr better access.
Also updated the README
* Fixed SHIFT+Function key conflict
* Removed Angle Bracket and Curly Bracket layers, as they don't work corrrectly
*NOTE:* it might still be desirable to set the software layout to sv_SE in your
OS.
Swedish (sv_SE) Qwerty layout for ErgoDox, based on the Default configuration
I have tried making this as close of a match I could between the [default
ErgoDox EZ configuration](https://ergodox-ez.com/pages/our-firmware) and a
standard Swedish Qwerty layout.
Notable differences from default:
=================================
* There are three special character buttons (acute accent, circumflex/tilde and
apostrophe/asterisk) that don't have any buttons to map to naturally. I've put
these at other places:
* Acute accent (´) can be found in the lower left corner, conveniently
placed to reach for making an é.
* Apostrophe (') was put in the lower left corner, close to acute accent.
* Circumflex (^) and asterisk (*) was placed in the lower right corner.
* Tilde (~) and diaeresis (¨) I couldn't find a good place for, so I left
those out. I could only get the buttons to produce a single one of the
characters. How can I get it to work properly?
* The Alt button on right thumb was exchanged for AltGr (RAlt).
* I changed the backslash in the numpad (layer 1) for a minus. Thought it was
more sensible.
* I didn't find a good place for the "<>|" button, so that one was left out.
That is a problem that really needs to be resolved. Pipe can be found on layer
one, however.
* allow mod swapping for mod tap
* quick include
* fix the mod swapping
* make changes consistent with action code
* fix bug
* re-enable no gui, etc
* fix binary comps
* solid logic
* Added orthodox
* Modified readme
* Modified readme
* Modified readme
* Updated makefile
* Fixed keymap issues
* Modified serial communications to allow for over 8 columns
* Fixed sizeof command
* Fixed some typing issues
* Testing issue #1191 (n-column split i2c slave)
Based on initial OrthoDox (serial) config by @reddragond and others,
this attempts to add TWI (I2C) support.
Relevant: <https://github.com/qmk/qmk_firmware/issues/1191>
- per @ahtn recommendation, using memcpy for moving slave matrix
into slave sending buffer
- slave buffer has been enlarged using sizeof(matrix_row_t)
- note: i2c.h now includes matrix.h
- note: matrix.c includes <string.h>
* Added i2c keymap - right col still not working
* orthodox: re-added i2c keymap, based on serial
* orthodox / issue #1191: trying 9-bit serial
- orthodox serial protocol now sends 9 bits per row, instead of 16.
Technically it's using MATRIX_COLS, so it might work generically.
- ROW_MASK is #defined in serial.c to truncate the checksums to prevent
overflows causing false errors. This macro should be renamed if it's
kept.
* Revert "Fixed sizeof command"
This reverts commit f62a5b9939.
Changes had been made to the lets_split serial driver for testing which
mirrored the multi-byte-row changes made to support the orthodox. As the
lets_split does not require these changes, and new improvements had
been added to the orthodox port only, this commit reverts them.
Because the new code could potentially reduce latency over the serial
transport, it may be desirable to re-add in the future, by backporting
the current working orthodox code.
* orthodox: default serial keymap improvements
- formatting has been improved
- a few keys have been shifted, mainly in Raise and Lower layers,
to be more like the default Planck layout
- Now available: F12, Home, End, PgUp, PgDn, Media-Next, Media-Play
Still To Do:
- duplicate for TWI
- Alt modifier
- GUI modifier
* orthodox: failed attempt at 16b/row TWI
- duplicated updated serial keymap for "i2c"
- removed string.h/memcpy, instead
- hardcoded copying of six bytes per update
- still doesn't work; master reports interconnect errors on txled
* orthodox: adjusted default keymap
- this is applied to both 'serial' and 'i2c' keymaps
- Alt and GUI have been added, as they were missing
- comma and period persist across more layers; Home/PgUp and End/PgDn
have been moved slightly to accommodate
* orthodox: revert TWI support to minimum to debug
- disabled ssd1306 and hardware locking in build configuration
- increased TWI buffer from 0x10 to 0x20 bytes
- decreased TWI clock from 400000 to 100000
- removed hardcoded TWI multi-byte sending/receiving
An 'i2c' build of this was found to work on a rev1 Orthodox, although
slave-side col9 was understandably not working. When testing-time
permits, features will be gradually re-enabled towards getting the full
matrix supported over TWI.
* orthodox: TWI (i2c) is working, kludge for col9
The TWI interconnect ("i2c" in directories and build config) is now
working for the Orthodox, including the slave half's column #9.
This is intended as an interim solution, as it's a kludge, not a fix.
Rather than a working multi-byte implementation, the two col9 keys'
bits are packed-into and unpacked-from the two unused bits in row1.
Furthermore, the TWI clock constant has been reduced to 100000 from
400000, as testing revealed the higher value just didn't work.
Testing also found that (with this kludge) increasing the TWI buffer
was not necessary.
This commit leaves many commented-out lines in matrix.c from previous
testing, which will be removed in a future commit once the
interconnects' multi-byte problems have been debugged more thoroughly.
* orthodox: updated readme.md
The readme for the Orthodox now includes a description of the keyboard,
allusions to its author and availability, a linked photo, and links to
the evolving build guide and the current keymap on KLE.
This update has been prepared with /u/Deductivemonkee's assistance.
Added basic description of the keyboard and some build and configuration
instructions.
Also moved the RGB underlight modification instructions to the readme.
The previous default configuration and keymap was made for a Phantom
modified with RGB underlight.
This commit makes the default more in line with the "official"
configurations provided by the PCB.
The previous default have been moved to a separate keymap named
`rgbmod`. It has also been updated to better match the template keymap.
It's a little unclear what the style guidelines are for the QMK project.
But I figured that I should at least keep the indentation consistent
within the KMAC part.
Previously KEYMAP referred to the KEYMAP_ARROW layout and had 45 keys. It makes
more sense for the default keymap to be the 44 key layout, as is implied by the
name.
Additionally keymaps for all other known layouts have been added:
KEYMAP - base layout
KEYMAP_ARROW - additional key in bottom right
KEYMAP_COMMAND - additional key in bottom left
KEYMAP_ARROW_COMMAND - combination of KEYMAP_ARROW and KEYMAP_COMMAND
* Make submodules point to qmk
* Update uGFX to 2.7
* Use ugfx with custom fixes
* Fix the ChibiOs submodule commit hash
To match the hashes in the mabl/ChibiOS and therefore QMK repository.
* Add MIDI layer
* Respect brightness level on layer signalling
* Add hotkey in control layer for signalling state
* Update layout.png
* Remove image and replace it with imgur link
QMK strives to be an inclusive and tolerant community. We welcome participation from anyone regardless of age, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, political belief, race, religion, or sexual identity and orientation.
> “A gentle word turns away wrath, but a harsh word stirs up anger.”
Our users, contributors, and collaborators are expected to treat each other with respect, to assume good intentions, and to gently correct, where possible, rather than react with escalation. Some examples of behavior we will not tolerate include, but is not limited to:
* The use of sexualized language or imagery
* Unwelcome advances, sexual or otherwise
* Insults or derogatory comments, or personal or political attacks
* Publishing others’ private information without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
If someone is violating this Code of Conduct you may email hello@qmk.fm to bring your concern to the Members. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident.
QMK (*Quantum Mechanical Keyboard*) is an open source community that maintains QMK Firmware, QMK Flasher, qmk.fm, and these docs. QMK Firmware is a keyboard firmware based on the [tmk\_keyboard](http://github.com/tmk/tmk_keyboard) with some useful features for Atmel AVR controllers, and more specifically, the [OLKB product line](http://olkb.com), the [ErgoDox EZ](http://www.ergodox-ez.com) keyboard, and the [Clueboard product line](http://clueboard.co/). It has also been ported to ARM chips using ChibiOS. You can use it to power your own hand-wired or custom keyboard PCB.
## How to get it {#how-to-get-it}
If you plan on contributing a keymap, keyboard, or features to QMK, the easiest thing to do is [fork the repo through Github](https://github.com/qmk/qmk_firmware#fork-destination-box), and clone your repo locally to make your changes, push them, then open a [Pull Request](https://github.com/qmk/qmk_firmware/pulls) from your fork.
Otherwise, you can either download it directly ([zip](https://github.com/qmk/qmk_firmware/zipball/master), [tar](https://github.com/qmk/qmk_firmware/tarball/master)), or clone it via git (`git@github.com:qmk/qmk_firmware.git`), or https (`https://github.com/qmk/qmk_firmware.git`).
## How to compile {#how-to-compile}
Before you are able to compile, you'll need to [install an environment](getting_started_build_tools.md) for AVR or/and ARM development. Once that is complete, you'll use the `make` command to build a keyboard and keymap with the following notation:
make planck/rev4:default
This would build the `rev4` revision of the `planck` with the `default` keymap. Not all keyboards have revisions (also called subprojects or folders), in which case, it can be omitted:
make preonic:default
## How to customize {#how-to-customize}
QMK has lots of [features](features.md) to explore, and a good deal of [reference documentation](http://docs.qmk.fm) to dig through. Most features are taken advantage of by modifying your [keymap](keymap.md), and changing the [keycodes](keycodes.md).
If you have an idea for a custom feature or extra hardware connection, we'd love to accept it into QMK! These are generally done via [pull request](https://github.com/qmk/qmk_firmware/pulls) after forking, and here are some things to keep in mind when creating one:
* **Disable by default** - memory is a pretty limited on most chips QMK supports, and it's important that current keymaps aren't broken, so please allow your feature to be turned **on**, rather than being turned off. If you think it should be on by default, or reduces the size of the code, [open an issue](https://github.com/qmk/qmk_firmware/issues) for everyone to discuss it!
* **Compile locally before submitting** - hopefully this one is obvious, but things need to compile! Our Travis system will catch any issues, but it's generally faster for you to compile a few keyboards locally instead of waiting for the results to come back.
* **Consider subprojects and different chip-bases** - there are several keyboards that have subprojects that have allow for slightly different configurations, and even different chip-bases. Try to make a feature supported in ARM and AVR, or automatically disabled in one that doesn't work.
* **Explain your feature** - submitting a markdown write-up of what your feature does with your PR may be needed, and it will allow a collaborator to easily copy it into the wiki for documentation (after proofing and editing).
* **Don't refactor code** - to maintain a clear vision of how things are laid out in QMK, we try to plan out refactors in-depth, and have a collaborator make the changes. If you have an idea for refactoring, or suggestions, [open an issue](https://github.com/qmk/qmk_firmware/issues).
# How keys are registered, and interpreted by computers
In this file, you can will learn the concepts of how keyboards work over USB,
and you'll be able to better understand what you can expect from changing your
firmware directly.
## Schematic view
Whenever you type on 1 particular key, here is the chain of actions taking
place:
``` text
+------+ +-----+ +----------+ +----------+ +----+
| User |-------->| Key |------>| Firmware |----->| USB wire |---->| OS |
+------+ +-----+ +----------+ +----------+ |----+
```
This scheme is a very simple view of what's going on, and more details follow
in the next sections.
## 1. You Press a Key
Whenever you press a key, the firmware of your keyboard can register this event.
It can register when the key is pressed, held and released.
This usually happens with a [periodic scan of key presses with a frequency around 100 hz](https://github.com/benblazak/ergodox-firmware/blob/master/references.md#typical-keyboard-information).
This speed often is limited by the mechanical key response time, the protocol
to transfer those key presses (here USB HID), and by the software it is used in.
## 2. What the Firmware Sends
The [HID specification](http://www.usb.org/developers/hidpage/Hut1_12v2.pdf)
tells what a keyboard can actually send through USB to have a chance to be
properly recognised. This includes a pre-defined list of keycodes which are
simple numbers from `0x00` to `0xE7`. The firmware assigns a keycode to each
key of the keyboard.
The firmware does not send actually letters or characters, but only keycodes.
Thus, by modifying the firmware, you only can modify what keycode is sent over
USB for a given key.
## 3. What the Operating System Does
Once the keycode reaches the operating system, a piece of software has to have
it match an actual character thanks to a keyboard layout. For example, if your
layout is set to QWERTY, a sample of the matching table is as follow:
``` text
| keycode | character |
|---------+-----------|
| 0x04 | a/A |
| 0x05 | b/B |
| 0x06 | c/C |
| ... | ... |
| 0x1C | y/Y |
| 0x1D | z/Z |
| ... | ... |
|---------+-----------|
```
## Back to the firmware
As the layout is generally fixed (unless you create your own), the firmware can
actually call a keycode by its layout name directly to ease things for you.
This is exactly what is done here with `KC_A` actually representing `0x04` in
QWERTY. The full list can be found in `keycode.txt`.
## List of Characters You Can Send
Putting aside shortcuts, having a limited set of keycodes mapped to a limited
layout means that **the list of characters you can assign to a given key only
is the ones present in the layout**.
For example, this means that if you have a QWERTY US layout, and you want to
assign 1 key to produce `€` (euro currency symbol), you are unable to do so,
because the QWERTY US layout does not have such mapping. You could fix that by
using a QWERTY UK layout, or a QWERTY US International.
You may wonder why a keyboard layout containing all of Unicode is not devised
then? The limited number of keycode available through USB simply disallow such
a thing.
## How to (Maybe) Enter Unicode Characters
You can have the firmware send *sequences of keys* to use the [software Unicode
Input
Method](https://en.wikipedia.org/wiki/Unicode_input#Hexadecimal_code_input) of
the target operating system, thus effectively entering characters independently
of the layout defined in the OS.
Yet, it does come with multiple disadvantages:
- Tied to a specific OS a a time (need recompilation when changing OS);
- Within a given OS, does not work in all software;
If you have Windows 10 with Creators Update or later, you can build and flash the firmware directly. Before the Creators Update, only building was possible. If you don't have it yet or if are unsure, follow [these instructions](https://support.microsoft.com/en-us/instantanswers/d4efb316-79f0-1aa1-9ef3-dcada78f3fa0/get-the-windows-10-creators-update).
#### Windows Subsystem for Linux
In addition to the Creators Update, you need Windows 10 Subystem for Linux, so install it following [these instructions](http://www.howtogeek.com/249966/how-to-install-and-use-the-linux-bash-shell-on-windows-10/). If you already have the Windows 10 Subsystem for Linux from the Anniversary update it's recommended that you [upgrade](https://betanews.com/2017/04/14/upgrade-windows-subsystem-for-linux/) it to 16.04LTS, because some keyboards don't compile with the toolchains included in 14.04LTS. Note that you need to know what your are doing if you chose the `sudo do-release-upgrade` method.
#### Git
If you already have cloned the repository on your Windows file system you can ignore this section.
You will need to clone the repository to your Windows file system using the normal Git for Windows and **not** the WSL Git. So if you haven't installed Git before, [download](https://git-scm.com/download/win) and install it. Then [set it up](https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup), it's important that you setup the e-mail and user name, especially if you are planning to contribute.
Once Git is installed, open the Git bash command and change the directory to where you want to clone QMK, note that you have to use forward slashes, and that your c drive is accessed like this `/c/path/to/where/you/want/to/go`. Then run `git clone --recurse-submodules https://github.com/qmk/qmk_firmware`, this will create a new folder `qmk_firmware` as a subfolder of the current one.
#### Toolchain setup
The Toolchain setup is done through the Windows Subsystem for Linux, and the process is fully automated. If you want to do everything manually, there are no other instructions than the scripts themselves, but you can always open issues and ask for more information.
1. Open "Bash On Ubuntu On Windows" from the start menu.
2. Go to the directory where you cloned `qmk_firmware`. Note that the paths start with `/mnt/` in the WSL, so you have to write for example `cd /mnt/c/path/to/qmk_firmware`.
3. Run `util/wsl_install.sh` and follow the on-screen instructions.
4. Close the Bash command window, and re-open it.
5. You are ready to compile and flash the firmware!
#### Some important things to keep in mind
* You can run `util/wsl_install.sh` again to get all the newest updates.
* Your QMK repository need to be on a Windows file system path, since WSL can't run executables outside it.
* The WSL Git is **not** compatible with the Windows Git, so use the Windows Git Bash or a windows Git GUI for all Git operations
* You can edit files either inside WSL or normally using Windows, but note that if you edit makefiles or shell scripts, make sure you are using an editor that saves the files with Unix line endings. Otherwise the compilation might not work.
### Windows (Vista and later)
1. If you have ever installed WinAVR, uninstall it.
2. Install [MHV AVR Tools](https://infernoembedded.com/sites/default/files/project/MHV_AVR_Tools_20131101.exe). Disable smatch, but **be sure to leave the option to add the tools to the PATH checked**.
3. If you are going to flash Infinity based keyboards you will need to install dfu-util, refer to the instructions by [Input Club](https://github.com/kiibohd/controller/wiki/Loading-DFU-Firmware).
4. Install [MinGW](https://sourceforge.net/projects/mingw/files/Installer/mingw-get-setup.exe/download). During installation, uncheck the option to install a graphical user interface. **DO NOT change the default installation folder.** The scripts depend on the default location.
5. Clone this repository. [This link will download it as a zip file, which you'll need to extract.](https://github.com/qmk/qmk_firmware/archive/master.zip) Open the extracted folder in Windows Explorer.
6. Open the `\util` folder.
7. Double-click on the `1-setup-path-win` batch script to run it. You'll need to accept a User Account Control prompt. Press the spacebar to dismiss the success message in the command prompt that pops up.
8. Right-click on the `2-setup-environment-win` batch script, select "Run as administrator", and accept the User Account Control prompt. This part may take a couple of minutes, and you'll need to approve a driver installation, but once it finishes, your environment is complete!
If you have trouble and want to ask for help, it is useful to generate a *Win_Check_Output.txt* file by running `Win_Check.bat` in the `\util` folder.
### Mac
If you're using [homebrew,](http://brew.sh/) you can use the following commands:
brew tap osx-cross/avr
brew install avr-libc
brew install dfu-programmer
This is the recommended method. If you don't have homebrew, [install it!](http://brew.sh/) It's very much worth it for anyone who works in the command line. Note that the `make` and `make install` portion during the homebrew installation of avr-libc can take over 20 minutes and exhibit high CPU usage.
You can also try these instructions:
1. Install Xcode from the App Store.
2. Install the Command Line Tools from `Xcode->Preferences->Downloads`.
If you are going to flash Infinity based keyboards you will also need dfu-util
brew install dfu-util
### Linux
To ensure you are always up to date, you can just run `sudo util/install_dependencies.sh`. That should always install all the dependencies needed. **This will run `apt-get upgrade`.**
You can also install things manually, but this documentation might not be always up to date with all requirements.
The current requirements are the following, but not all might be needed depending on what you do. Also note that some systems might not have all the dependencies available as packages, or they might be named differently.
```
build-essential
gcc
unzip
wget
zip
gcc-avr
binutils-avr
avr-libc
dfu-programmer
dfu-util
gcc-arm-none-eabi
binutils-arm-none-eabi
libnewlib-arm-none-eabi
git
```
Install the dependencies with your favorite package manager.
If this is a bit complex for you, Docker might be the turn-key solution you need. After installing [Docker](https://www.docker.com/products/docker), run the following command at the root of the QMK folder to build a keyboard/keymap:
```bash
# You'll run this every time you want to build a keymap
# modify the keymap and keyboard assigment to compile what you want
# On windows docker seems to have issue with VOLUME tag in Dockerfile, and $('pwd') won't print a windows compliant path, use full path instead like this
This will compile the targeted keyboard/keymap and leave it in your QMK directory for you to flash.
### Vagrant
If you have any problems building the firmware, you can try using a tool called Vagrant. It will set up a virtual computer with a known configuration that's ready-to-go for firmware building. OLKB does NOT host the files for this virtual computer. Details on how to set up Vagrant are in the [vagrant guide](vagrant_guide.md).
## Verify Your Installation
1. If you haven't already, obtain this repository ([https://github.com/qmk/qmk_firmware](https://github.com/qmk/qmk_firmware)). You can either download it as a zip file and extract it, or clone it using the command line tool git or the Github Desktop application.
2. Open up a terminal or command prompt and navigate to the `qmk_firmware` folder using the `cd` command. The command prompt will typically open to your home directory. If, for example, you cloned the repository to your Documents folder, then you would type `cd Documents/qmk_firmware`. If you extracted the file from a zip, then it may be named `qmk_firmware-master` instead.
3. To confirm that you're in the correct location, you can display the contents of your current folder using the `dir` command on Windows, or the `ls` command on Linux or Mac. You should see several files, including `readme.md` and a `quantum` folder. From here, you need to navigate to the appropriate folder under `keyboards/`. For example, if you're building for a Planck, run `cd keyboards/planck`.
4. Once you're in the correct keyboard-specific folder, run the `make` command. This should output a lot of information about the build process. More information about the `make` command can be found below.
# This guide has now been included in the main readme - please reference that one instead.
## Build Environment Setup
### Windows (Vista and later)
1. If you have ever installed WinAVR, uninstall it.
2. Install [MHV AVR Tools](https://infernoembedded.com/sites/default/files/project/MHV_AVR_Tools_20131101.exe). Disable smatch, but **be sure to leave the option to add the tools to the PATH checked**.
3. Install [MinGW](https://sourceforge.net/projects/mingw/files/Installer/mingw-get-setup.exe/download). During installation, uncheck the option to install a graphical user interface. **DO NOT change the default installation folder.** The scripts depend on the default location.
4. Clone this repository. [This link will download it as a zip file, which you'll need to extract.](https://github.com/qmk/qmk_firmware/archive/master.zip) Open the extracted folder in Windows Explorer.
5. Double-click on the 1-setup-path-win batch script to run it. You'll need to accept a User Account Control prompt. Press the spacebar to dismiss the success message in the command prompt that pops up.
6. Right-click on the 2-setup-environment-win batch script, select "Run as administrator", and accept the User Account Control prompt. This part may take a couple of minutes, and you'll need to approve a driver installation, but once it finishes, your environment is complete!
7. Future build commands should be run from the standard Windows command prompt, which you can find by searching for "command prompt" from the start menu or start screen. Ignore the "MHV AVR Shell".
### Mac
If you're using [homebrew,](http://brew.sh/) you can use the following commands:
brew tap osx-cross/avr
brew install avr-libc
brew install dfu-programmer
This is the recommended method. If you don't have homebrew, [install it!](http://brew.sh/) It's very much worth it for anyone who works in the command line.
You can also try these instructions:
1. Install Xcode from the App Store.
2. Install the Command Line Tools from `Xcode->Preferences->Downloads`.
3. Install [DFU-Programmer][dfu-prog].
### Linux
Install AVR GCC, AVR libc, and dfu-progammer with your favorite package manager.
If you have any problems building the firmware, you can try using a tool called Vagrant. It will set up a virtual computer with a known configuration that's ready-to-go for firmware building. OLKB does NOT host the files for this virtual computer. Details on how to set up Vagrant are in the [vagrant guide](vagrant_guide.md).
## Verify Your Installation
1. If you haven't already, obtain this repository ([https://github.com/qmk/qmk_firmware](https://github.com/qmk/qmk_firmware)). You can either download it as a zip file and extract it, or clone it using the command line tool git or the Github Desktop application.
2. Open up a terminal or command prompt and navigate to the `qmk_firmware` folder using the `cd` command. The command prompt will typically open to your home directory. If, for example, you cloned the repository to your Documents folder, then you would type `cd Documents/qmk_firmware`. If you extracted the file from a zip, then it may be named `qmk_firmware-master` instead.
3. To confirm that you're in the correct location, you can display the contents of your current folder using the `dir` command on Windows, or the `ls` command on Linux or Mac. You should see several files, including `readme.md` and a `quantum` folder. From here, you need to navigate to the appropriate folder under `keyboards/`. For example, if you're building for a Planck, run `cd keyboards/planck`.
4. Once you're in the correct keyboard-specific folder, run the `make` command. This should output a lot of information about the build process. More information about the `make` command can be found below.
## Customizing, Building, and Deploying Your Firmware
### The Make command
The `make` command is how you compile the firmware into a .hex file, which can be loaded by a dfu programmer (like dfu-progammer via `make dfu`) or the [Teensy loader](https://www.pjrc.com/teensy/loader.html) (only used with Teensys). You can run `make` from the root (`/`), your keyboard folder (`/keyboards/<keyboard>/`), or your keymap folder (`/keyboards/<keyboard>/keymaps/<keymap>/`) if you have a `Makefile` there (see the example [here](/doc/keymap_makefile_example.mk)).
By default, this will generate a `<keyboard>_<keymap>.hex` file in whichever folder you run `make` from. These files are ignored by git, so don't worry about deleting them when committing/creating pull requests.
* The "root" (`/`) folder is the qmk_firmware folder, in which are `doc`, `keyboard`, `quantum`, etc.
* The "keyboard" folder is any keyboard project's folder, like `/keyboards/planck`.
* The "keymap" folder is any keymap's folder, like `/keyboards/planck/keymaps/default`.
Below is a list of the useful `make` commands in QMK:
*`make` - cleans automatically and builds your keyboard and keymap depending on which folder you're in. This defaults to the "default" layout (unless in a keymap folder), and Planck keyboard in the root folder
*`make keyboard=<keyboard>` - specifies the keyboard (only to be used in root)
*`make keymap=<keymap>` - specifies the keymap (only to be used in root and keyboard folder - not needed when in keymap folder)
*`make quick` - skips the clean step (cannot be used immediately after modifying config.h or Makefiles)
*`make dfu` - (requires dfu-programmer) builds and flashes the keymap to your keyboard once placed in reset/dfu mode (button or press `KC_RESET`). This does not work for Teensy-based keyboards like the ErgoDox EZ.
*`keyboard=` and `keymap=` are compatible with this
*`make all-keyboards` - builds all keymaps for all keyboards and outputs status of each (use in root)
*`make all-keyboards-default` - builds all default keymaps for all keyboards and outputs status of each (use in root)
*`make all-keymaps [keyboard=<keyboard>]` - builds all of the keymaps for whatever keyboard folder you're in, or specified by `<keyboard>`
*`make all-keyboards-quick`, `make all-keyboards-default-quick` and `make all-keymaps-quick [keyboard=<keyboard>]` - like the normal "make-all-*" commands, but they skip the clean steps
Other, less useful functionality:
*`make COLOR=false` - turns off color output
*`make SILENT=true` - turns off output besides errors/warnings
*`make VERBOSE=true` - outputs all of the avr-gcc stuff (not interesting)
### The Makefile
There are 3 different `make` and `Makefile` locations:
The root contains the code used to automatically figure out which keymap or keymaps to compile based on your current directory and commandline arguments. It's considered stable, and shouldn't be modified. The keyboard one will contain the MCU set-up and default settings for your keyboard, and shouldn't be modified unless you are the producer of that keyboard. The keymap Makefile can be modified by users, and is optional. It is included automatically if it exists. You can see an example [here](/doc/keymap_makefile_example.mk) - the last few lines are the most important. The settings you set here will override any defaults set in the keyboard Makefile. **It is required if you want to run `make` in the keymap folder.**
The keyboard `config.h` is included only if the keymap one doesn't exist. The format to use for your custom one [is here](/doc/keymap_config_h_example.h). If you want to override a setting from the parent `config.h` file, you need to do this:
```
#undef MY_SETTING
#define MY_SETTING 4
```
For a value of `4` for this imaginary setting. So we `undef` it first, then `define` it.
You can then override any settings, rather than having to copy and paste the whole thing.
## This guide may be out-dated - use [build_guide.md](build_guide.md) instead
Download and Install
--------------------
### 1. Install Tools
1.**Toolchain** On Windows install [MHV AVR Tools][mhv] for AVR GCC compiler and [Cygwin][cygwin](or [MinGW][mingw]) for shell terminal. On Mac you can use [CrossPack][crosspack]. On Linux you can install AVR GCC (and avr-libc) with your favorite package manager or run the avr_setup.sh script in the root of this repository.
2.**Programmer** On Windows install [Atmel FLIP][flip]. On Mac and Linux install [dfu-programmer][dfu-prog].
3.**Driver** On Windows you start DFU bootloader on the chip first time you will see 'Found New Hardware Wizard' to install driver. If you install device driver properly you can find chip name like 'ATmega32U4' under 'LibUSB-Win32 Devices' tree on 'Device Manager'. If not you shall need to update its driver on 'Device Manager'. You will find the driver in `FLIP` install directory like: C:\Program Files (x86)\Atmel\Flip 3.4.5\usb\. In case of `dfu-programmer` use its driver.
If you use PJRC Teensy you don't need step 2 and 3 above, just get [Teensy loader][teensy-loader].
### 2. Download source
You can find firmware source at github:
-<https://github.com/tmk/tmk_keyboard>
If you are familiar with `Git` tools you are recommended to use it but you can also download zip archive from:
Open terminal window to get access to commands. Use Cygwin(or MingGW) `shell terminal` in Windows or `Terminal.app` on Mac OSX. In Windows press `Windows` key and `R` then enter `cmd` in 'Run command' dialog showing up.
### 2. Change directory
Move to project directory in the firmware source.
cd tmk_keyboard/{'keyboard' or 'converter'}/<project>
### 3. Make
Build firmware using GNU `make` command. You'll see `<project>_<variant>.hex` file in that directory unless something unexpected occurs in build process.
make -f Makefile.<variant> clean
make -f Makefile.<variant>
Program Controller
------------------
Now you have **hex** file to program on current directory. This **hex** is only needed to program your controller, other files are used for development and you may leave and forget them.
### 1. Start bootloader
How to program controller depends on controller chip and its board design. To program AVR USB chips you'll need to start it up in bootloader mode. Most of boards with the chip have a push button to let bootloader come up. Consult with your controller board manual.
### 2. Program with DFU bootloader
Stock AVR USB chip including ATmega32U4 has DFU bootloader by factory default. `FLIP` is a DFU programmer on Windows offered by Atmel. Open source command line tool `dfu-programmer` also supports AVR chips, it runs on Linux, Mac OSX and even Windows.
To program AVR chip with DFU bootloader use `FLIP` or `dfu-programmer`.
If you have a proper program command in `Makefile` just type this.
`FLIP` has two version of tool, GUI app and command line program. If you want GUI see tutorial below.
To use command line tool run this command. Note that you need to set PATH variable properly.
$ make -f Makefile.<variant> flip
Or to program with `dfu-programmer` run:
$ make -f Makefile.<variant> dfu
#### FLIP GUI tutorial
1. On menu bar click Device -> Select, then. `ATmega32u4`.
2. On menu bar click Settings -> Communication -> USB, then click 'Open' button on 'USB Port Connection' dialog.
At this point you'll see grey-outed widgets on the app get colored and ready.
3. On menu bar click File -> Load HEX File, then select your firmware hex file on File Selector dialog.
4. On 'Operations Flow' panel click 'Run' button to load the firmware binary to the chip. Note that you should keep 'Erase', 'Blank Check', 'Program' and 'Verify' check boxes selected.
5. Re-plug USB cord or click 'Start Application' button to restart your controller.
If you have PJRC Teensy see instruction of `Teensy Loader`.
-<http://www.pjrc.com/teensy/loader.html>
Or use this command if you have command line version of Teensy Loader installed.
$ make -f Makefile.<variant> teensy
### 4. Program with Other programmer
You may want to use other programmer like `avrdude` with AVRISPmkII, Arduino or USBasp. In that case you can still use make target `program` for build with configuring `PROGRAM_CMD` in Makefile.
Optional. Set proper command for your controller, bootloader and programmer. This command can be used with `make program`. Not needed if you use `FLIP`, `dfu-programmer` or `Teensy Loader`.
QMK is nearly infinitely configurable. Wherever possible we err on the side of allowing users to customize their keyboard, even at the expense of code size. That level of flexibility makes for a daunting configuration experience, however.
There are two main types of configuration files in QMK- `config.h` and `rules.mk`. These files exist at various levels in QMK and all files of the same type are combined to build the final configuration. The levels, from lowest priority to highest priority, are:
* QMK Default
* Keyboard
* Folders (Up to 5 levels deep)
* Keymap
## QMK Default
Every available setting in QMK has a default. If that setting is not set at the Keyboard, Folder, or Keymap level this is the setting that will be used.
## Keyboard
This level contains config options that should apply to the whole keyboard. Some settings won't change in revisions, or most keymaps. Other settings are merely defaults for this keyboard and can be overridden by folders and/or keymaps.
## Folders
Some keyboards have folders and sub-folders to allow for different hardware configurations. Most keyboards only go 1 folder deep, but QMK supports structures up to 5 folders deep. Each folder can have its own `config.h` and `rules.mk` files that are incorporated into the final configuration.
## Keymap
This level contains all of the options for that particular keymap. If you wish to override a previous declaration, you can use `#undef <variable>` to undefine it, where you can then redefine it without an error.
# The `config.h` file
This is a C header file that is one of the first things included, and will persist over the whole project (if included). Lots of variables can be set here and accessed elsewhere.
## `config.h` Options
### Hardware Options
*`#define VENDOR_ID 0x1234`
* defines your VID, and for most DIY projects, can be whatever you want
*`#define PRODUCT_ID 0x5678`
* defines your PID, and for most DIY projects, can be whatever you want
*`#define DEVICE_VER 0`
* defines the device version (often used for revisions)
* COL2ROW or ROW2COL - how your matrix is configured. COL2ROW means the black mark on your diode is facing to the rows, and between the switch and the rows.
*`#define AUDIO_VOICES`
* turns on the alternate audio voices (to cycle through)
*`#define C6_AUDIO`
* enables audio on pin C6
*`#define B5_AUDIO`
* enables audio on pin B5 (duophony is enable if both are enabled)
*`#define BACKLIGHT_PIN B7`
* pin of the backlight - B5, B6, B7 use PWM, others use softPWM
*`#define BACKLIGHT_LEVELS 3`
* number of levels your backlight will have (not including off)
*`#define DEBOUNCING_DELAY 5`
* the delay when reading the value of the pin (5 is default)
*`#define LOCKING_SUPPORT_ENABLE`
* mechanical locking support. Use KC_LCAP, KC_LNUM or KC_LSCR instead in keymap
*`#define LOCKING_RESYNC_ENABLE`
* tries to keep switch state consistent with keyboard LED state
* key combination that allows the use of magic commands (useful for debugging)
### Features That Can Be Disabled
If you define these options you will disable the associated feature, which can save on code size.
*`#define NO_DEBUG`
* disable debuging
*`#define NO_PRINT`
* disable printing/debugging using hid_listen
*`#define NO_ACTION_LAYER`
* disable layers
*`#define NO_ACTION_TAPPING`
* disable tap dance and other tapping features
*`#define NO_ACTION_ONESHOT`
* disable one-shot modifiers
*`#define NO_ACTION_MACRO`
* disable all macro handling
*`#define NO_ACTION_FUNCTION`
* disable the action function (deprecated)
### Features That Can Be Enabled
If you define these options you will enable the associated feature, which may increase your code size.
*`#define FORCE_NKRO`
* NKRO by default requires to be turned on, this forces it on during keyboard startup regardless of eeprom setting. NKRO can still be turned off but will be turned on again if the keyboard reboots.
*`#define PREVENT_STUCK_MODIFIERS`
* when switching layers, this will release all mods
### Behaviors That Can Be Configured
*`#define TAPPING_TERM 200`
* how long before a tap becomes a hold
*`#define RETRO_TAPPING`
* tap anyway, even after TAPPING_TERM, if there was no other key interruption between press and release
*`#define TAPPING_TOGGLE 2`
* how many taps before triggering the toggle
*`#define PERMISSIVE_HOLD`
* makes tap and hold keys work better for fast typers who don't want tapping term set above 500
*`#define LEADER_TIMEOUT 300`
* how long before the leader key times out
*`#define ONESHOT_TIMEOUT 300`
* how long before oneshot times out
*`#define ONESHOT_TAP_TOGGLE 2`
* how many taps before oneshot toggle is triggered
*`#define IGNORE_MOD_TAP_INTERRUPT`
* makes it possible to do rolling combos (zx) with keys that convert to other keys on hold
### RGB Light Configuration
*`#define RGB_DI_PIN D7`
* pin the DI on the ws2812 is hooked-up to
*`#define RGBLIGHT_ANIMATIONS`
* run RGB animations
*`#define RGBLED_NUM 15`
* number of LEDs
*`#define RGBLIGHT_HUE_STEP 12`
* units to step when in/decreasing hue
*`#define RGBLIGHT_SAT_STEP 25`
* units to step when in/decresing saturation
*`#define RGBLIGHT_VAL_STEP 12`
* units to step when in/decreasing value (brightness)
*`#define RGBW_BB_TWI`
* bit-bangs twi to EZ RGBW LEDs (only required for Ergodox EZ)
### Mouse Key Options
*`#define MOUSEKEY_INTERVAL 20`
*`#define MOUSEKEY_DELAY 0`
*`#define MOUSEKEY_TIME_TO_MAX 60`
*`#define MOUSEKEY_MAX_SPEED 7`
*`#define MOUSEKEY_WHEEL_DELAY 0`
# The `rules.mk` File
This is a [make](https://www.gnu.org/software/make/manual/make.html) file that is included by the top-level `Makefile`. It is used to set some information about the MCU that we will be compiling for as well as enabling and disabling certain features.
## `rules.mk` options
### Build Options
*`DEFAULT_FOLDER`
* Used to specify a default folder when a keyboard has more than one sub-folder.
*`SRC`
* Used to add files to the compilation/linking list.
*`LAYOUTS`
* A list of [layouts](feature_layouts.md) this keyboard supports.
### AVR MCU Options
*`MCU = atmega32u4`
*`F_CPU = 16000000`
*`ARCH = AVR8`
*`F_USB = $(F_CPU)`
*`OPT_DEFS += -DINTERRUPT_CONTROL_ENDPOINT`
*`OPT_DEFS += -DBOOTLOADER_SIZE=4096`
### Feature Options
Use these to enable or disable building certain features. The more you have enabled the bigger your firmware will be, and you run the risk of building a firmware too large for your MCU.
*`BOOTMAGIC_ENABLE`
* Virtual DIP switch configuration(+1000)
*`MOUSEKEY_ENABLE`
* Mouse keys(+4700)
*`EXTRAKEY_ENABLE`
* Audio control and System control(+450)
*`CONSOLE_ENABLE`
* Console for debug(+400)
*`COMMAND_ENABLE`
* Commands for debug and configuration
*`NKRO_ENABLE`
* USB Nkey Rollover - if this doesn't work, see here: https://github.com/tmk/tmk_keyboard/wiki/FAQ#nkro-doesnt-work
👍🎉 First off, thanks for taking the time to read this and contribute! 🎉👍
Third-party contributions help us grow and improve QMK. We want to make the pull request and contribution process useful and easy for both contributors and maintainers. To this end we've put together some guidelines for contributors to help your pull request be accepted without major changes.
* [Project Overview](#project-overview)
* [Coding Conventions](#coding-conventions)
* [General Guidelines](#general-guidelines)
* [What does the Code of Conduct mean for me?](#what-does-the-code-of-conduct-mean-for-me)
## I Don't Want To Read This Whole Thing I Just Have a Question!
If you'd like to ask questions about QMK you can do so on the [OLKB Subreddit](https://reddit.com/r/olkb) or on [Gitter](https://gitter.im/qmk/qmk_firmware).
Please keep these things in mind:
* It may take several hours for someone to respond to your question. Please be patient!
* Everyone involved with QMK is donating their time and energy. We don't get paid to work on or answer questions about QMK.
* Try to ask your question so it's as easy to answer as possible. If you're not sure how to do that these are some good guides:
QMK is largely written in C, with specific features and parts written in C++. It targets embedded processors found in keyboards, particularly AVR ([LUFA](http://www.fourwalledcubicle.com/LUFA.php)) and ARM ([ChibiOS](http://www.chibios.com)). If you are already well versed in Arduino programming you'll find a lot of the concepts and limitations familiar. Prior experience with Arduino is not required to successfully contribute to QMK.
<!-- FIXME: We should include a list of resources for learning C here. -->
# Where can I go for help?
If you need help you can [open an issue](https://github.com/qmk/qmk_firmware/issues) or [chat on gitter](http://gitter.im/QMK/qmk_firmware).
# How Do I Make a Contribution?
Never made an open source contribution before? Wondering how contributions work in QMK? Here's a quick rundown!
0. Sign up for a [GitHub](https://github.com) account.
1. Put together a keymap to contribute, [find an issue](https://github.com/qmk/qmk_firmware/issues) you are interested in addressing, or [a feature](https://github.com/qmk/qmk_firmware/issues?q=is%3Aopen+is%3Aissue+label%3Afeature) you would like to add.
2. Fork the repository associated with the issue to your GitHub account. This means that you will have a copy of the repository under `your-GitHub-username/qmk_firmware`.
3. Clone the repository to your local machine using `git clone https://github.com/github-username/repository-name.git`.
4. If you're working on a new feature consider opening an issue to talk with us about the work you're about to undertake.
5. Create a new branch for your fix using `git checkout -b branch-name-here`.
6. Make the appropriate changes for the issue you are trying to address or the feature that you want to add.
7. Use `git add insert-paths-of-changed-files-here` to add the file contents of the changed files to the "snapshot" git uses to manage the state of the project, also known as the index.
8. Use `git commit -m "Insert a short message of the changes made here"` to store the contents of the index with a descriptive message.
9. Push the changes to your repository on GitHub using `git push origin branch-name-here`.
10. Submit a pull request to [QMK Firmware](https://github.com/qmk/qmk_firmware/pull/new/master).
11. Title the pull request with a short description of the changes made and the issue or bug number associated with your change. For example, you can title an issue like so "Added more log outputting to resolve #4352".
12. In the description of the pull request explain the changes that you made, any issues you think exist with the pull request you made, and any questions you have for the maintainer. It's OK if your pull request is not perfect (no pull request is), the reviewer will be able to help you fix any problems and improve it!
13. Wait for the pull request to be reviewed by a maintainer.
14. Make changes to the pull request if the reviewing maintainer recommends them.
15. Celebrate your success after your pull request is merged!
# Coding conventions
Most of our style is pretty easy to pick up on, but right now it's not entirely consistent. You should match the style of the code surrounding your change, but if that code is inconsistent or unclear use the following guidelines:
* We indent using two spaces (soft tabs)
* We use One True Brace Style
* Opening Brace: At the end of the same line as the statement that opens the block
* Closing Brace: Lined up with the first character of the statement that opens the block
* Else If: Place the closing brace at the beginning of the line and the next opening brace at the end of the same line.
* Optional Braces: Always include optional braces.
* Good: if (condition) { return false; }
* Bad: if (condition) return false;
* We use C style comments: /* */
* Think of them as a story describing the feature
* Use them liberally to explain why particular decisions were made.
* Do not write obvious comments
* If you not sure if a comment is obvious, go ahead and include it.
* In general we don't wrap lines, they can be as long as needed. If you do choose to wrap lines please do not wrap any wider than 76 columns.
# General Guidelines
We have a few different types of changes in QMK, each requiring a different level of rigor. We'd like you to keep the following guidelines in mind no matter what type of change you're making.
* Separate PR's into logical units. For example, do not submit one PR covering two separate features, instead submit a separate PR for each feature.
* Check for unnecessary whitespace with `git diff --check` before committing.
* Make sure your code change actually compiles.
* Keymaps: Make sure that `make keyboard:your_new_keymap` does not return an error
* Keyboards: Make sure that `make keyboard:all` does not return any errors
* Core: Make sure that `make all` does not return any errors.
* Make sure commit messages are understandable on their own. You should put a short description (no more than 70 characters) on the first line, the second line should be empty, and on the 3rd and later lines you should describe your commit in detail, if required. Example:
```
Adjust the fronzlebop for the kerpleplork
The kerpleplork was intermittently failing with error code 23. The root cause was the fronzlebop setting, which causes the kerpleplork to activate every N iterations.
Limited experimentation on the devices I have available shows that 7 is high enough to avoid confusing the kerpleplork, but I'd like to get some feedback from people with ARM devices to be sure.
```
## Documentation
Documentation is one of the easiest ways to get started contributing to QMK. Finding places where the documentation is wrong or incomplete and fixing those is easy! We also very badly need someone to edit our documentation, so if you have editing skills but aren't sure where or how to jump in please [reach out for help](#where-can-i-go-for-help)!
You'll find all our documentation in the `qmk_firmware/docs` directory, or if you'd rather use a web based workflow you can click "Suggest An Edit" at the top of each page on http://docs.qmk.fm/.
## Keymaps
Most first-time QMK contributors start with their personal keymaps. We try to keep keymap standards pretty casual (keymaps, after all, reflect the personality of their creators) but we do ask that you follow these guidelines to make it easier for others to discover and learn from your keymap.
* Write a `readme.md` using [the template](https://docs.qmk.fm/documentation_templates.html#).
* All Keymap PR's are squashed, so if you care about how your commits are squashed you should do it yourself
* Do not lump features in with keymap PR's. Submit the feature first and then a second PR for the keymap.
* Do not include `Makefile`s in your keymap folder (they're no longer used)
* Update copyrights in file headers (look for `REPLACE_WITH_YOUR_NAME `)
## Keyboards
Keyboards are the raison d'être for QMK. Some keyboards are community maintained, while others are maintained by the people responsible for making a particular keyboard. The `readme.md` should tell you who maintains a particular keyboard. If you have questions relating to a particular keyboard you can [Open An Issue](https://github.com/qmk/qmk_firmware/issues) and tag the maintainer in your question.
We also ask that you follow these guidelines:
* Write a `readme.md` using [the template](https://docs.qmk.fm/documentation_templates.html#).
* Keep the number of commits reasonable or we will squash your PR
* Do not lump core features in with new keyboards. Submit the feature first and then submit a separate PR for the keyboard.
* Name `.c`/`.h` file after the immediate parent folder, eg `/keyboards/<kb1>/<kb2>/<kb2>.[ch]`
* Do not include `Makefile`s in your keyboard folder (they're no longer used)
* Update copyrights in file headers (look for `REPLACE_WITH_YOUR_NAME `)
## Quantum/TMK Core
Before you put a lot of work into building your new feature you should make sure you are implementing it in the best way. You can get a basic understanding of QMK by reading [Understaning QMK](understanding_qmk.html), which will take you on a tour of the QMK program flow. From here you should talk to us to get a sense of the best way to implement your idea. There are two main ways to do this:
* [Chat on Gitter](https://gitter.im/qmk/qmk_firmware)
* [Open an Issue](https://github.com/qmk/qmk_firmware/issues/new)
Feature and Bug Fix PR's affect all keyboards. We are also in the process of restructuring QMK. For this reason it is especially important for significant changes to be discussed before implementation has happened. If you open a PR without talking to us first please be prepared to do some significant rework if your choices do not mesh well with our planned direction.
Here are some things to keep in mind when working on your feature or bug fix.
* **Disabled by default** - memory is a pretty limited on most chips QMK supports, and it's important that current keymaps aren't broken, so please allow your feature to be turned **on**, rather than being turned off. If you think it should be on by default, or reduces the size of the code, please talk with us about it.
* **Compile locally before submitting** - hopefully this one is obvious, but things need to compile! Our Travis system will catch any issues, but it's generally faster for you to compile a few keyboards locally instead of waiting for the results to come back.
* **Consider revisions and different chip-bases** - there are several keyboards that have revisions that allow for slightly different configurations, and even different chip-bases. Try to make a feature supported in ARM and AVR, or automatically disabled on platforms it doesn't work on.
* **Explain your feature** - Document it in `docs/`, either as a new file or as part of an existing file. If you don't document it other people won't be able to benefit from your hard work.
We also ask that you follow these guidelines:
* Keep the number of commits reasonable or we will squash your PR
* Do not lump keyboards or keymaps in with core changes. Submit your core changes first.
* Write [Unit Tests](http://docs.qmk.fm/unit_testing.html) for your feature
* Follow the style of the file you are editing. If the style is unclear or there are mixed styles you should conform to the [coding conventions](#coding-conventions) above.
## Refactoring
To maintain a clear vision of how things are laid out in QMK we try to plan out refactors in-depth and have a collaborator make the changes. If you have an idea for refactoring, or suggestions, [open an issue](https://github.com/qmk/qmk_firmware/issues), we'd love to talk about how QMK can be improved.
# What does the Code of Conduct mean for me?
Our [Code of Conduct](https://github.com/qmk/qmk_firmware/blob/master/CODE_OF_CONDUCT.md) means that you are responsible for treating everyone on the project with respect and courtesy regardless of their identity. If you are the victim of any inappropriate behavior or comments as described in our Code of Conduct, we are here for you and will do the best to ensure that the abuser is reprimanded appropriately, per our code.
A custom keyboard is about more than sending button presses to your computer. QMK has designed hooks to allow you to inject code, override functionality, and otherwise customize how your keyboard responds in different situations.
# How To Customize Your Keyboard's Behavior
## A Word on Keyboards vs Keymap
For a lot of people a custom keyboard is about more than sending button presses to your computer. You want to be able to do things that are more complex than simple button presses and macros. QMK has hooks that allow you to inject code, override functionality, and otherwise customize how your keyboard behaves in different situations.
This page does not assume any special knowledge about QMK, but reading [Understanding QMK](understanding_qmk.html) will help you understand what is going on at a more fundamental level.
## A Word on Core vs Keyboards vs Keymap
We have structured QMK as a hierarchy:
@@ -8,59 +12,66 @@ We have structured QMK as a hierarchy:
* Keyboard/Revision (`_kb`)
* Keymap (`_user`)
Each of the functions described below can be defined with a `_kb()` suffix or an`_user()` suffix. We intend for you to use the `_kb()` suffix at the Keyboard/Revision level, while the `_user()` suffix should be used at the Keymap level.
Each of the functions described below can be defined with a `_kb()` suffix or a `_user()` suffix. We intend for you to use the `_kb()` suffix at the Keyboard/Revision level, while the `_user()` suffix should be used at the Keymap level.
When defining functions at the Keyboard/Revision level it is important that your `_kb()` implementation call `_user()` before executing anything else- otherwise the keymap level function will never be called.
## Matrix Initialization Code
# Custom Keycodes
* Keyboard/Revision: `void matrix_init_kb(void)`
* Keymap: `void matrix_init_user(void)`
By far the most common task is to change the behavior of an existing keycode or to create a new keycode. From a code standpoint the mechanism for each is very similar.
This function gets called when the matrix is initiated. You should use this function to initialize any custom hardware you may have, such as speakers, LED drivers, or other features which need to be setup after the keyboard powers on.
## Defining a New Keycode
### Example
The first step to creating your own custom keycode(s) is to enumerate them. This means both naming them and assigning a unique number to that keycode. Rather than limit custom keycodes to a fixed range of numbers QMK provides the `SAFE_RANGE` macro. You can use `SAFE_RANGE` when enumerating your custom keycodes to guarantee that you get a unique number.
Here is an example of enumerating 2 keycodes. After adding this block to your `keymap.c` you will be able to use `FOO` and `BAR` inside your keymap.
```
void matrix_init_kb(void) {
// put your keyboard start-up code here
// runs once when the firmware starts up
matrix_init_user();
enum my_keycodes {
FOO = SAFE_RANGE,
BAR
};
```
// JTAG disable for PORT F. write JTD bit twice within four cycles.
MCUCR |= (1<<JTD);
MCUCR |= (1<<JTD);
## Programming The Behavior Of Any Keycode
// * Set our LED pins as output
DDRB |= (1<<0);
DDRB |= (1<<1);
DDRB |= (1<<2);
DDRB |= (1<<3);
DDRB |= (1<<4);
When you want to override the behavior of an existing key, or define the behavior for a new key, you should use the `process_record_kb()` and `process_record_user()` functions. These are called by QMK during key processing before the actual key event is handled. If these functions return `true` QMK will process the keycodes as usual. That can be handy for extending the functionality of a key rather than replacing it. If these functions return `false` QMK will skip the normal key handling, and it will be up you to send any key up or down events that are required.
These function are called every time a key is pressed or released.
### Example `process_record_user()` implementation
This example does two things. It defines the behavior for a custom keycode called `FOO`, and it supplements our Enter key by playing a tone whenever it is pressed.
return false; // Skip all further processing of this key
case KC_ENTER:
// Play a tone when enter is pressed
if (record->event.pressed) {
PLAY_NOTE_ARRAY(tone_qwerty);
}
return true; // Let QMK send the enter press/release events
}
}
```
## Matrix Scanning Code
* Keyboard/Revision: `void matrix_scan_kb(void)`
* Keymap: `void matrix_scan_user(void)`
This function gets called at every matrix scan, which is basically as often as the MCU can handle. Be careful what you put here, as it will get run a lot.
You should use this function if you need custom matrix scanning code. It can also be used for custom status output (such as LED's or a display) or other functionality that you want to trigger regularly even when the user isn't typing.
This function gets called every time a key is pressed or released. This is particularly useful when defining custom keys or overriding the behavior of existing keys.
The `keycode` argument is whatever is defined in your keymap, eg `MO(1)`, `KC_L`, etc. You should use a `switch...case` block to handle these events.
The return value is whether or not QMK should continue processing the keycode - returning `false` stops the execution.
The `keycode` variable is whatever is defined in your keymap, eg `MO(1)`, `KC_L`, etc. and can be switch-cased to execute code whenever a particular code is pressed.
The `record` variable contains infomation about the actual press:
The `record` argument contains infomation about the actual press:
```
keyrecord_t record {
@@ -75,12 +86,7 @@ keyrecord_t record {
}
```
The conditional `if (record->event.pressed)` can tell if the key is being pressed or released, and you can execute code based on that.
Before a keyboard can be used the hardware must be initialized. QMK handles initialization of the keyboard matrix itself, but if you have other hardware like LED's or i²c controllers you will need to set up that hardware before it can be used.
### Example `matrix_init_kb()` implementation
This example, at the keyboard level, sets up B1, B2, and B3 as LED pins.
```
void matrix_init_kb(void) {
// Call the keymap level matrix init.
matrix_init_user();
// Set our LED pins as output
DDRB |= (1<<1);
DDRB |= (1<<2);
DDRB |= (1<<3);
}
```
### `matrix_init_*` Function documentation
* Keyboard/Revision: `void matrix_init_kb(void)`
* Keymap: `void matrix_init_user(void)`
# Matrix Scanning Code
Whenever possible you should customize your keyboard by using `process_record_*()` and hooking into events that way, to ensure that your code does not have a negative performance impact on your keyboard. However, in rare cases it is necessary to hook into the matrix scanning. Be extremely careful with the performance of code in these functions, as it will be called at least 10 times per second.
### Example `matrix_scan_*` implementation
This example has been deliberately omitted. You should understand enough about QMK internals to write this without an example before hooking into such a performance sensitive area. If you need help please [open an issue](https://github.com/qmk/qmk_firmware/issues/new) or [chat with us on gitter](https://gitter.im/qmk/qmk_firmware).
### `matrix_scan_*` Function documentation
* Keyboard/Revision: `void matrix_scan_kb(void)`
* Keymap: `void matrix_scan_user(void)`
This function gets called at every matrix scan, which is basically as often as the MCU can handle. Be careful what you put here, as it will get run a lot.
You should use this function if you need custom matrix scanning code. It can also be used for custom status output (such as LED's or a display) or other functionality that you want to trigger regularly even when the user isn't typing.
Understanding the essential changes made on the [tmk_keyboard firmware](http://github.com/tmk/tmk_keyboard) should help you understand the QMK Firmware.
| `keymaps` array data | 3D array of `uint8_t` holding **keycode** | 3D array of `uint16_t` holding **keycode** |
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
