qmk_firmware/users/ericgebhart

Overview

This is as much a keymap framework as it is a keymap. It can take many shapes with just a few configuration choices. Base layers, Mods, thumb clusters, edge_keys, all can be changed with just a configuration option. There are over 50 base layouts to choose from, as well as multiple choices of navigation, mouse, media, symbols, and keypads. Home row mods come in a few flavors or none, in a mod layer which is easily understandable and can be turned on or off, or switched. There are Miryoku options for everything if that is your thing.

If there is a oled of 64x128 the maps of each layer will be displayed, which helps a lot in remembering and learning.

This is an easily configurable keymap for keymap exploration. It is for primarily for minimalist, ortho split keyboards but does support some rectangles. It´s first keyboard was an Ergodox-ez many years ago. My daily driver is now a Kyria or a Corne, but I still use an original dactyl, rebound and ergodox-ez regularly although most of the love goes to the Kyria and Corne.

The framework is Language agnostic, it supports having layers for different locales which can be cycled through. There are multiple mods layers to choose or not, home row mods or not, a variety of thumb layouts, mouse/no mouse, smart lock layers and mods, N-Shot mods like callum's, swapper. Combos, tap_hold, accented keys, alternate shifted keys, automatic custom keys, key overrides. Minimal or no C-code required for most things. Language, mods, layouts and extensions are encapsulated, so that they do not interact in the configuration which makes it much easier to modify and grow. Mods and combos are by key location rather than specific key codes.

Quick start

Everything is encapsulated here. Base layers, functional layers, mods, or no mods, even the language. This means that anything can change independently and easily.

If you don't mind dvorak, beakl or hands down, you can probably just use what is configured. Or just change it to a base layer of your choice. The fastest way to get started is to just change the base layers to the ones you want, compile and flash.

Edit config.h,

• Set the lang_is, probably to EN.
  • US international and BEPO are also supported out of the box.
• Uncomment the base layers you wish to have.
  • comment the ones you don't.
  • keep the number below 5 if you enable a second locale.
• Set the thumb clusters
• Choose a mod layer
• Choose an edge key set if you need one.
• Choose the layer flavors that you want.
• For Miryoku, copy the miryoku_hd_gold_config.h over config.h It is a complete config with miryoku choices. Choose the base layers you wish if Hands Down Gold and Qwerty is not your thing.

** do not turn off extensions until you know them ** It will likely cause a stream of errors for the keycodes that go missing when something is turned off. There are known interactions between combos, smart locks, not_dead, and alt local keys. Turning encoders or oled on and off certainly won´t break anything.

There are other interactions between your choices. Edge keys, thumbs, combos, other extensions, may use the extensions that are enabled.

Look here to see the parts

• Everything can be turned on and off in config.h
• Base layers are in base_layers/
• Edge keys are in layers/edge_keys.h
• Thumbs can be reviewed in layers/thumbs.h
• Mods are in mod_layers/
• All other layers are also in layers/

The long version

All can be turned on or off in the config. supports en-us and fr-bepo Support for other languages is easily added.

Layouts are human readable, all extensions are defined with def files. If an 128x64 oled is available, a map of the current layer is shown if enabled.

I'm an Xmonad, emacs in vi emulation programmer, that just means that Gui, Esc, :/?!% and . are all easy access and I like my arrow and mouse keys in a 4 column row.

I have also become minimalist in my keyboard choices. I don't use number rows, not even on my kinesis, dactyl, or ergodox_ez, which have them. Although my maps do reasonably support these bigger keyboards as that is where it all started for me and I do still use them. My preference for keyboards is more in line with the Kyria and Corne. I still use 6 columns, but have been looking to use only 5.

Note: Combos at QMK master do not currently support multiple reference layers which this configuration uses. Combos still work as always, but do not support all the features found here. To get fully functioning multi-reference combos, see my ericgebhart_dev branch and pull request below.

Actually, at the moment, the fix is in my ericgebhart branch, since I accidently pushed it. I'll remedy that soon.

A more current version of my QMK user can be found here in A sparse tree of my QMK User Space

For full multi-lingual combo functionality you will need my pull request for fully functioning multi-reference combos which can found here.

Things which effect the thinking.

• No mouse.
• Preference for 3x10 layouts. Corne, Kyria, etc.
• Still works with bigger keyboards like xd75, kinesis, dactyl, ergodox, viterbi.
• Change mods without changing any maps.
• No number row preference. - all layouts have them if needed.
• Xmonad window manager, GUI key is the entrance to the Xmonad world.
• Typing in other languages.
• Curious about keyboard layouts and experimenting.
• Must be easy to maintain, extend and modify.
• Minimize digging in code to add new things, or change old ones.
• Minimize process record user.
• Easy to add enums for keys and layers, as well as oled display.
• Easy to support multiple languages regardless of maps.
• Minimize the need to write C code.
• Encapsulate C code, so that it is extensible through data.

Features:

• Everything is configurable from config.h and .def files.
• Def files for most things.
• Custom key codes are mostly defined automatically.
• Everything is chosen or turned on and off in config.h
• Lots of macros to make it easy to redefine things without a refactor.
• Multiple edge/outer pinky column sets.
• Multiple thumb clusters to choose from.
• Thumb clusters and mods can be changed on a map by map basis.
• Easily define thumb clusters with an alpha letter.
• Easily define thumb clusters for non-base layer.
• Multiple base layers to choose from.
• Several variations of function layers to choose from
• Miryoku layers, thumbs and mods if desired
• Miryoku hands down gold config can be swapped with config.h
• Navigation and mouse layers
• A selection of symbol, keypads, and other layers.
• Regular and Beakl keypad and number rows
• Multi language support, (locales in the code).
• Multiple mod layers to choose from. Easy to add more.
  • home row mods - a selection
  • no mods
  • alt mods
  • miryoku mods
• Extensions are easily defined in def files.
  • N-shot mods
  • One-shot mods
  • swapper
  • Smart lock mods
  • Smart lock layers.
  • Accent keys
  • Alternate shift keys
  • Alternate local keys
  • key overrides
  • Tap hold
  • Not dead keys
  • Send unicode
  • Send string
  • Encoders
• Display a map of the current layer on the oled.
• Adding a new layer is painless.
• Adding or changing most things, is not difficult.
• Console key logging for heatmap analysis.

Layout shape and keyboard choices.

In all cases these keyboards are defined in a matrix which is a set of rows. Maybe like so, or less. Kinesis has one more row.

   -------------------------|------------------------ */
   | Left0 | Numbers L | mid|dle0 | numbers R | Right0 |
   | Left1 | keys0-5   | mid|dle1 | Keys6-10  | Right1 |
   | Left2 | keys11-15 | mid|dle2 | Keys16-20 | Right2 |
   | Left3 | keys20-25 | mid|dle3 | Keys25-30 | Right3 |
   | Row5L                  |                    Row5R |
   |               ThumbsL  | ThumbsR                  |
   -------------------------|------------------------ 

Generally speaking, the keys on the right and left and middle don't change. Neither do the bottom row or the thumbs, unless asked. Frequently the numbers row is identical across layers.

For automatic edge columns set EDGE_COLS. Outside pinky keys are 'yes'. This is on by default. N rows by 6 columns per side. Should be undef/def'd by the keyboard's keymap if no. #define EDGE_COLS yes. this is all taken care of for supported keyboards.

Thumbs and Edge keys are grouped into sets so that different sets can be chosen in the config.

All layer macros take 3x10 or 3x12 as needed. Edge columns are added as needed, and middle keys fill up the gap. Thumb keys are added as asked.

keyboard shapes: Matrix size + 5th row + thumbs. Matrix size + thumbs.

• kinesis 4x6 + 4 + 6 - 18 func keys.
• dactyl - Morpho handwire 4x6 + 5 + 6
• ergodox_ez 4x6 + 5 + 6 & 3 pairs of center keys.
• crkbd - corne 3x6 + 3 or 3x5 + 3
• xiudi/xd75 5x15
• keebio/viterbi 5x14
• montsinger/rebound/rev4 4x12 + 3 center keys.
• -- 4x12
• splitkb/kyria 3x6 + 7 or 3x5 + 7

The parts of a keymap

• keymap

  • defined in keymap/keymap.c.
  • Completely configurable from config.h
  • Separated into logical chunks.
  • Uses a language setting to create all maps.
  • Creates the same maps in multiple languages.
  • More than one language simultaneously on one keyboard.
  • Currently provides these languag settings and keycodes.
    • US - US-intl (US_)
    • EN - US-en (KC_),
    • BEPO - fr-bepo (BP_).
  • Choosing dvorak, and enabling bepo as the second locale, will produce two base layers to choose from on the keyboard. Dvorak on US and BEPO.

• Base layers

  • Simple and compact definitions.
  • Base layers are pure.
  • Mods are defined separately.
  • OLED Maps for 128x64 sized oleds.
  • Language agnostic.
  • Core layer chunks are 3x10.
    • Except for few exceptions which are 3x12
  • More than 50 base layers to choose from.

  Caution: Choosing too many base layers will result in toprows or keypad layer LT's to stop working. If bepo is enabled, all base layers are doubled so it's easy to hit the 16 layer limit for LT.

• Locales

  • Locales, defines a set of layers for a locale.
  • Layer definitions are language agnostic. - see lang.h.

• Extensions - Defs.

  • Can be selected in config.h

  • Defined in easy to read .def files.

  • Correspondance between extensions/ and defs/

  • accented_keys.def - direct access to altgr keys

  • altlocal_keys.def - alternate un/shifted pairs.

  • alt_shift.def - alternate shifting behaviors for existing keycodes.

  • not_dead.def - definitions for non-dead dead keys.

  • caps_word - no def file.

  • combos.def -

  • custom_keys.def - list of custom keys.

  • encoders.def - encoder behaviors by mod/layer.

  • key_overrides.def - Bigger more complex alt keys.

  • mod_lock.def - smart locking mods with a set of ignore keys.

  • nshot.def - N-shot locking mods

  • oneshot.def - One-shot locking mods

  • smart_lock.def - Smart lock layers and mods.

  • swapper.def - key substitution, reverser.

    • eg. toggle between tab, backtab on a key, with a reverse key.

  • tap_hold.def - Define key for tap and hold for tapping term for qqc autre.

  • unicode.def - keycodes to send unicode strings.

  • send_string.def - keycodes to send strings.

• Layers

  • Multiple selections of the Transient layers.
  • Layer chunks are 3x10, with some options.
  • Full Navigation layer - stable and well used.
  • Mouse keys or without.
  • 1 or 2 layer nav, 2nd for mouse. or all on one. - choices.
  • Multiple choices of an easy to use top rows layer similar to raise and lower.
  • A fully complete symbol layer, Used for coding and writing.
  • Accented letters and dead key layers.
  • Keypads and function pads.
  • Beakl keypads and symbol layers.
  • Control layers.
    • Layers
    • Adjust
    • RGB

• OLED A simple, configurable implementation.

  • Current base layer
  • Current locale
  • Current transient layer
  • Last key, matrix location and value.
  • Mods and locks
  • Map of the current layer. (Oled 128x64)
  • key logger

• Keyboards

  • nothing is needed in keymaps/*/keymap.c
  • Layouts - keyboard matrix adaptation.
    • Adaptive. Usually taking 3x10 maps and filling the edges and thumbs.
    • 4x10 or whatever is possible.
    • 3 versions, thinking in a split kb, way.
      • 5 columns in, 5 out.
      • 5 columns in, 6 out.
      • 6 columns in, 6 out.
  • per keyboard shape.
  • There are layouts per keyboard.
    • Base layout with mods and thumbs and edges added.
    • Transient layout which can be KC_TRANS, in those same places.
  • The number row addition can be turned on and off as needed by the layout.
  • Layouts can hard code the number row, negating the need for giving one.

• Multiple edge key sets

• Multiple Thumb clusters - see config or thumbs.h for up to date choices.

  • Support for multiple definitions.
    • mods
    • layers
    • mods_layers
    • mods_layers_nav
    • beakl wi
    • beakl wi - official.
    • test - to play with.
    • trans - transparent, could be used in the transient layout to allow alternates.
    • miryoku with keypad
    • miryoku with toprows
    • mods_layers with left thumb letter
    • hands down approximation with left thumb letter
    • miryoku with keypad, letter on left, space on right. - no tab.
    • miryoku with toprows, letter on left, space on right. - no tab.

• Mod Layers

  • Completely independent of any layer or base layer definition.
  • Easy to create a new one by copying the transparent version.
  • Can be changed on a layer per layer basis.
  • Based on position in the matrix.
  • Chosen in config.
  • Multiple choices.
    • Home Row Mods. sacg, gacs, gasc Left and right mods on left and right.
    • Transparent - the default if not chosen.
    • Alt - Non home row mod variant.
    • miryoku HRMS is sacg plus right alt/altgr on third row.

• Alternate language/locale support

  • Happens at the lowest level
  • All maps work with any of the keymap extras.
  • Language support is simple to add with just a new, very simple macro.

The language keycodes can be found here.

Architecture

The idea here is that most things don't change, and the things that do are easy to understand and change. The defs directory is where all the extras are, tap_hold, alternate shift keys, combos, keycodes, smart lock, one shot mods,etc.

If layers exist that you want and like, then all other behaviors are defined in def files which are much nicer than working directly with C code. If there is need there is always the copy pasta way too.

Things that are likely to be changed when adapting a layout to personal preferences are layers/thumbs.h and mod_layers/. The function layers are all in the layers folder and should be easy to understand. Once added, it is only necessary to add the appropriate defines in config.h

Adding new layers requires changes in layer_names, oled/oled_layers.h and oled/oled_cartes.h and the appropriate keymap/ .h file.

Adding a new keyboard is done in keyboards and should be fairly obvious.

.
├── base_layers
│   ├── accents.h
│   ├── alt.h
│   ├── base_layers.h
│   ├── beakl.h
│   ├── bepo.h
│   ├── carpalx.h
│   ├── dvorak.h
│   ├── gap.h
│   ├── hands_down.h
│   ├── keymaps.txt
│   ├── maks.h
│   ├── qwerty.h
│   └── toprows.h
├── config.h
├── defs
│   ├── accented_keys.def
│   ├── altlocal_keys.def
│   ├── alt_shift.def
│   ├── combos.def
│   ├── custom_keys.def
│   ├── encoders.def
│   ├── key_overrides.def
│   ├── mod_lock.def
│   ├── not_dead.def
│   ├── nshot.def
│   ├── oneshot.def
│   ├── send_string.def
│   ├── smart_lock.def
│   ├── swapper.def
│   ├── tap_hold.def
│   └── unicode.def
├── ericgebhart.c
├── ericgebhart.h
├── extensions
│   ├── accented_keys.c
│   ├── accented_keys.h
│   ├── altlocal_keys.c
│   ├── altlocal_keys.h
│   ├── alt_shift.c
│   ├── caps_word.c
│   ├── caps_word.h
│   ├── console_key_logger.c
│   ├── console_key_logger.h
│   ├── encoders.c
│   ├── encoders.h
│   ├── extensions.h
│   ├── keycodes.h
│   ├── keymap_combo.h
│   ├── key_overrides.h
│   ├── mod_lock.c
│   ├── mod_lock.h
│   ├── not_dead.c
│   ├── nshot_mod.c
│   ├── nshot_mod.h
│   ├── oneshot.c
│   ├── oneshot.h
│   ├── process_locales.h
│   ├── process_nshot.h
│   ├── process_smart_lock.h
│   ├── send_string.c
│   ├── smart_lock.c
│   ├── smart_lock.h
│   ├── swapper.c
│   ├── swapper.h
│   ├── tap_dances.c
│   ├── tap_dances.h
│   ├── tap_hold.c
│   ├── tap_hold.h
│   ├── unicode.c
│   └── unicode.h
├── keyboards
│   ├── keyboards.h
│   └── layouts.h
├── keymap
│   ├── keymap.c
│   ├── map_accented.h
│   ├── map_alt.h
│   ├── map_beakl.h
│   ├── map_bepo.h
│   ├── map_carpalx.h
│   ├── map_dvorak.h
│   ├── map_funcs.h
│   ├── map_gap.h
│   ├── map_hd.h
│   ├── map_keypads.h
│   ├── map_maks.h
│   ├── map_qwerty.h
│   ├── map_symbols.h
│   └── map_toprows.h
├── lang
│   ├── lang.h
│   ├── lang_map.h
│   ├── locale_layers.h
│   ├── locales.c
│   └── locales.h
├── layer_names
│   ├── base_names.h
│   ├── func_names.h
│   ├── layer_names.h
│   └── util_names.h
├── layers
│   ├── edge_keys.h
│   ├── keypads.h
│   ├── layers.h
│   ├── nav.h
│   ├── symbols.h
│   ├── thumbs.h
│   ├── toprows.h
│   └── utility.h
├── listen_keylogger.sh
├── mod_layers
│   ├── alt_mods.h
│   ├── hrm_gacs.h
│   ├── hrm_gacs_miryoku.h
│   ├── hrm_gasc.h
│   ├── hrm_sacg.h
│   ├── hrs_nav.h
│   ├── mod_layer.h
│   └── trns_mods.h
├── oled
│   ├── oled_cartes.c
│   ├── oled_layers.c
│   ├── oled_stuff.c
│   └── oled_stuff.h
├── process_records.c
├── readme.md
└── rules.mk

10 directories, 118 files

Locales

There are currently three locales. LANG_IS defines the one in use. The map changes this value as it goes, to get the maps that are asked for. I have recently renamed some variables, such that it seems that only 2 locales are possible. It seems more than two might be too many. And keeping at 2 is a little easier.

• EN - en-us, KC_ keycodes.
• US-INT - us-international variant, US_ keycodes.
• BEPO - bepo-fr, BP_ keycodes.

Switching LANG_IS before adding a new map will cause that map to use LANG keycodes and keymap chunks when building the map.

Enabling a second locale to bepo, will cause bepo versions of the chosen layers to be added to the keymap.

defining a locale.

This is to manage BEPO and Qwerty Locale/language/Layers Each locale is defined with a start and end layer from the layers enum.

This is only necessary to give contextual base layer choices based on the current locale setting, which the keyboard tracks.

The first and last defines are all done with the magic of defines in ericgebhart.h where the layers enum is defined.

This could potentially hold multiple locales, The map turns on off the layers and their enums if they are not enabled so that the layer array does not fill up with too many base layers, or other layers because LT only works up to layer 15.

What this does is allow the keyboard to know which locales it has, and which layers go with them.

If you have an oled, the locale will be displayed after the layout name. Currently en-us and bepo-fr are there.

Locales are tracked, as to the layer ranges which belong to them in the layers enum. This allows for a KC_NEXT_LOCALE key and a KC_NEXT_BASE_LAYER key, on the layers layer. KC_SET_BASE sets the default layer in the eeprom.

When cycling through layers only the layers for the chosen local will appear.

The layers are different keycode sets. So there are two symbol layers, two toprows layers, two keypad layers. One for Qwerty and one for bepo. The Navigation layer is not affected because it has only control keycodes which are independent of locale.

Locales, how they work in layouts.

This is done through consistent naming patterns and macros. Here are the macros that support creation of layout parts by locale. All are defined in lang.h

• Keycode Prefix - KC or BP, etc. LANG_KC(_A) -> KC_A or BP_A

• Defined key/layer Suffix - SYMB_EN, SYMB_BP, ... LANG_N(NAME) -> NAME_EN, NAME_BP

• Map chunk Suffix - _EN, SYMB_BP, etc. MAP_CHUNK(15_BOTTOM) --> ___15_BOTTOM_EN___ or ___15_BOTTOM_BP___

lang.h has the macro definitions used in the keymap resolution, A new locale, will need a new set of macros that match the others. They use LANG_IS, Follow the patterns. It should be reasonably obvious.

It is only necessary to create new base level macros that are used by these macros. All of them are similar.

LANG_KC uses these macros to resolve it's values.

    // Give the right keycode prefix by LANG_IS
    #define LANG_PFX CAT(LANG_IS_, KC)
    #define BEPO_KC BP_
    #define EN_KC KC_

Adding a new one is just a matter of adding the a macro named with this format. LANG_IS _Keycode prefix. for Slovak, if the LANG_IS value is SK that would be,

`#define SK_KC SK_`

LANG_N macro uses these similar macros for it's resolution.

    // Give the right symbol suffix by LANG_IS
    #define LANG_SFX CAT(CAT(LANG_IS, _), SFX)
    #define BEPO_SFX _BP
    #define EN_SFX _EN

Adding Slovak support to the LANG_N macro looks like this.

`#define SK_SFX _SK`

Thumb clusters.

Thumb clusters can be chosen by layer with the value of THUMBS_ARE.

The easiest way to see them is to look in layers/thumbs.h.

At the core of the thumb clusters are a set of six keys which can be changed to a one of a set of keys, with settings in the config. Supporting a 4 key thumb cluster would just need a similar set.

The newer Hands down variants also have need of thumb clusters which can take a letter. A default can be given in config.h. Each keymap layer entry can give it's letter to change the thumb cluster. This is needed for hands down, maltron, rsthd, and beakl wi.

These layouts use a special thumb cluster variant which will use the value of THUMB_LETTER to place a letter on one of the thumb keys.

It is reasonably easy to add a new thumb cluster and use it. Add it to thumbs.h, add to the list of macros for it's suffix, and turn it on by setting it to THUMBS_ARE in config.h

Additionally a thumb cluster can be set for the various function layers as well. The transparent thumbs can be used, or something else. The nav and mouse layers have the mouse buttons if mouse keys are enabled.

It is also possible to use a Miryoku thumb cluster and layers or mix the other layers in as desired.

The language of thumb clusters is managed at the lowest level. These keys are mostly not language specific.

Here is the definition for my space and symbol layer key. This changes the name of the layer given like this.

_SYMB becomes _SYMB_EN or _SYMB_BP. Depending on the value of LANG_IS

`#define SPC_SYMB LT(LANG_N(_SYMB), KC_SPC)`

Edge key sets

Edge keys, or the 6th, and outer pinky column are often not specified in base keymaps and are not strictly necessary. There are a few sets to choose from here. A NOKC set with no keys, NORM which is sorta normal with grave, equal, tab, -, and /. There is also a smart lock set which gives access to smart lock layers tab and -. Last there is test, so its easy to try new things. Edge keys are defined in layers/edge_keys.h.

Base Layers

I like to experiment with layouts. So I have a few. They can be turned on in config.h.

To switch base layers there is a combo to raise the layers layer. Hold both pinkies on their lower row keys to get the layer. Tap the home row left middle finger to change layers. Tap the ring finger to set it to eeprom if you want it to stick.

The left index finger will cycle through locales if you have them.

Here is a list of some of the base layers..

• Dvorakish
  • Dvorak
  • Capewell-Dvorak
  • Ahei
  • Boo
  • Dvorak RLC-UI
• Beakl
  • 15
  • 19
  • 27
  • WI
• Qwertyish
  • Qwerty
  • Azerty
  • Workman
  • Norman
• Maks
  • Colemak
  • Colemak_DH
  • Halmak
  • Minimak
  • Minimak 8
  • Minimak 12
• Carpalx
  • QFMLWY
  • QGMLWB
  • QGMLWY
• Hands Down
  • Neu
  • Neu narrow
  • Titanium
  • Gold
  • Platinum
  • Silver
  • Bronze
  • Elan
  • Dash
  • Ref
• MTGAP
  • Mtgap
  • Ctgap
  • Apt
  • Canary
• Others
  • Maltron
  • Eucalyn
  • Rsthd
  • Isrt
  • Hands Up
  • White
  • Soul
  • Niro
  • Asset
  • Whorf
  • Whorf6
• Bepo, layers with accented letters.
  • Bepo
  • Optimot
  • Optimot compact
  • Beakl19bis

Adding a new base layer, or any layer

Adding a new base layer is easy. They all live in base_layers/. A base layer entry looks like this. There is an empty template in base_layers.h which collects all the other maps. The name of the carte de map, should be CARTE followed by the layer name that will be used. Layer names are usually an underscore followed by the name. For dvorak, that is _DVORAK, which because of the language layer ultimately and magically becomes _DVORAK_EN, _DVORAK_US, _DVORAK_BP as needed.

#define CARTE_DVORAK                            \
  carte_de_map(" ',.py fgcrl ",                 \
               " aoeui dhtns ",                 \
               " ;qjkx bmwvz ")

#define ___DVORAK___                                                    \
  LANG_MAP(TL_QUOT,  TL_COMM, TL_DOT, _P,  _Y,   _F, _G, _C, _R, _L,               \
           _A,       _O,      _E,     _U,  _I,   _D, _H, _T, _N, _S,    \
           TL_SCLN,  _Q,      _J,     _K,  _X,   _B, _M, _W, _V, _Z)

TL_ keycodes

Use TL_ keycodes for any punctuation, this allows for targeting of these keys by language and by target layout as needed. for instance TL_COMM -> TLKC(_COMM). The Target-Language-comma, becomes BP_BK_COMM, or KC_DV_COMM, US_HD_COMM, or whatever it needs to be based on current language and target layout. If your layer has special puncuation needs,

• Add key entries to altlocal_keys.def
• Edit to lang/lang_map.h to add the new TARGET_PFX entry.
• Set the appropriate value to ALT_TARGET_IS in the layer's keymap entry.

Integration

Integrating the new map into the rest of the framework is just a simple entry in a few places.

• layer_names needs to know about the new name so we can use it,
• The oled needs to know about it so it can display it.
• The config needs to know about it so we can turn it on.

Follow these steps. Everything is very simple, and just one to 3 lines. Just follow the same patterns as all the rest.

• Add the layer definition and map of the definition in base_layers/.h.
• Add the layer name to layer_names/base_names.h
• Add the layer name to keymap/.h
• Add the layer entry to oled/oled_layers.c
• Add the layer map entry to oled/oled_cartes.c
• Add the define for the layer enable to config.h

Adding a new functional layer follows the same patterns, although their keymap and oled entries may be more complex, since it is usually trying to pick one from a set of choices.

Adding a new thumb cluster configuration

Adding a new thumb keys definition is done in layers/thumbs.h. The keys that change are just 6 and they all have the name of __6_ERGO_THUMBS....

• Define a new thumb definition with a nice suffix like all the rest.
• Add an entry to the THUMB_EXT list with the nice new suffix.
• Set the appropriate THUMBS_ARE defines in config.h to it's new thumb extension name.

Adding a new mod layer

This is also easy. Mod layers live in the mod_layers folder. Each file there is a separate mod layer, which is tracked in mod_layers.h The file, trns_mods.h is the transparent mods layer and by definition has no modifiers applied, providing a clean slate.

The steps are these:

• Make a new copy of an existing mod layer.
• Edit the new file and change the names to your new name.
  • ie. _trns changes to _my_new_mods
• Add the mods you want. MT's and LT's, tap holds, etc.
• Edit mod_layers/mod_layer.h
  • Add the include for the new mods file*
  • Add the MOD_EXT entry for the new name
• Define MODS_ARE in config.h to use the new name.

Keymaps

I only have one. It's in keymap/keymap.c.
My config.h has all the current usable settings. Turn on the layers by enabling and choosing them in config.h. Most keyboards don't need a keymap.c.

There are corresponding Bepo layers, as needed, which will arrive if SECOND_LOCALE is set to BEPO. This essentially doubles the number of keymaps.
Nav, mouse, media, layers, RGB, and Adjust are not duplicated as there is no current need.

Mods, home row and otherwise.

With all these layers it was a real pain to apply mods consistently and easily with the old wrapper code. So I changed the way I use keymap macro wrappers and added in my own mod layer. The only thing it has is the mods to apply. No more editing keymaps to apply mods. I do it once, and it works everywhere I want by location.

Multiple versions are possible. Just copy the trns_mod_layer.h to a new name and modify it with a new extension name, (replace '_trns'). Then add it's include to mod_layer.h, to be used when the config says.

The defines for MODS_ARE and DEFAULT_MODS determine which mods are applied to a given keymap layer.

Keyboard matrix Layouts

This is where the keymap of the keyboard meets the mods and all the edge, middle and thumb keys, and makes it easy to give just a 3x10 definition for most layers regardless of which keyboard it is going to.

To use an existing layout for a different keyboard, simply make an entry in keyboards.h to assign the proper layouts that fit that keyboard. So a planck could use the 4x12 layout out of the box. In the keyboards keymap there is only a need for config.h or rules.mk if something needs changing. For the keyboard an empty keymap.c will do.

The base layout can be anything really. The base layer sets the thumbs and anything outside of the 3x10. The mod layer is wrapped in the base layout and adds the mods, and a 6th outer pinky column as needed.

Some layouts take an extra number row. Layouts can be any shape, all of these take a 3x10, 3x12, 4x10 or 4x12, and make it fit the keyboard.

The layouts defined in layouts.h take a list of keys. and give them to the keyboard's layout. The Corne (crkbd), uses a layout called LAYOUT_split_3x6_3. So for the corne, I have a Base_3x6_6 that is the same shape, in its resolution.

There are layouts for Corne, ergodox, kinesis, dactyl, viterbi, xd75, rebound.

Currently, 3 layouts are needed per keyboard.

• A Base layout, for default/base layers,
• A transient layout for the function layers.
• A version which takes 3x12 for the larger bepo base layers.

The base layouts can take 3 or 4 rows by 10 columns as desired. They add in the mods, and any pieces of matrix outside of the 3x10 center, function, numbers, lower rows, outside pinky keys, and thumb clusters.

Functional layers

There are quite a few of these to choose from. The easiest way to see them all is to go look at them in layers/. They are logically divided into files, and their cartes/maps are easy to look at. There are minimalist Miryoku versions as needed.

Navigation Layer

I do not use a mouse. I use Xmonad as my window manager, and I have practically no use for one. They are necessary however. So I have a Navigation layer which is all mouse, arrows, home, end, tab, page up, down, 5 mouse buttons and so on.

There are a growing number of choices, left and right sided mouse layers right side arrows etc, and some monolithic nav layers like the one shown below.

There is also a split layer, with arrows etc on the right, and smart mods and N-shots on the other. A left side mouse layer is accessible from the first nav layer. There are various choices at this point. It is best to look at the config.h for clues.

The miryoku nav and mouse layers are somewhat but not terribly different.

One of the Navigation layers.

M = Mouse
B = Button
W = Wheel
AC   = Acceleration
CCCV = Tap -> Ctrl-C, hold for double tap duration -> Ctrl-V
CTCN = Tap -> Ctrl-T, hold for double tap duration -> Ctrl-N
CWCQ = Tap -> Ctrl-W, hold for double tap duration -> Ctrl-Q
HOME = TAB & PGDN
END = BKTAB & PGUP
Lock/Unlock LAYER = PGDN & PGUP
 
MB5  MB4    MB3    MB2  MB1     MAC0  |  CTCN  MB1    MB2    MB3  MB4   MB5 
TAB  MLeft  MDown  MUp  MRight  MAC1  |  CCCV  Left   Down   UP   Right TAB 
     WLeft  WDown  WUp  WRight  MAC2  |  CWCQ  TAB    PGDN   PGUP BKTAB
                                                                             
     Left   Down   Up   Right   CCCV  |  CCCV  MLeft  MDown  MUp  MRight
     
     

Symbol Layer

The symbol layer is based on the Beakl15 symbol layer. It was very similar to a symbol layer that I had before beakl, but this felt better, and has been through a few iterations at this point. Vi likes using :/?! a lot. The = is not that important to me, as the : for the vi ex: command. The ! is very satisfying in this location.

For US-intl and Bepo which have dead keys, the symbol layer uses the not_dead extension to give '`"^~ which are not dead.

The beakl symbol layer is intuitive and fairly easy to remember. There are 3 versions. The original, an extended, and an extended and enhanced for vi. The primary purpose of the extension was to provide keys which might not be available elsewhere on the default layer. The vi version takes this further and moves :/? to better places.

I prefer a modified beakl15 symbol layer. here it is, left and right. This layer has some extra characters so it works with non-beakl base layouts. The beakl wi symbol layer is not an improvement on this IMO. Miryoku symbols layer is only left sided, and minimalist as well. This might be a little vi centric, with the : in the middle. ymmv.

There are a few choices, this is one.

        `<$>'  ?[_-] 
      - \("#)  !{:/} ;
        @=*+;  %&^~|

TopRows Layer

The toprows layer is a nice way to transition to small keyboards. I think, truly this is the layer that makes tiny keyboards accessible in the beginning. Everything can remain familiar. I use this one with a beakl number row. The default, if no choices are made, aside from enabling toprows, will
have a normal qwerty number row, as in the second map.

I do not use F keys, The latest addition has smart and nshot mods in the third row. There is a miryoku thumb cluster which uses this layer instead of a keypad.

```
!@#$%   ^&*()
40123   76598
F1   ---  F10
```

or

```
!@#$%   ^&*()
12345   67890
F1   ---  F10
```

Keypad and Funcpad Layers

There are several variations of keypads and function key pads in various sizes, and left and right. There are also versions with smart and nshot mods instead of F-keys. There are monolithic, left and right, and also half keyboard left mostly... A miryoku version also exists. The keypad can be chosen in config.h.

    523:  F9-12 
   7.104  F5-8
   /698,  F1-4

Media Layer

A simple Miryoku, media layer, controls on the right.

OLED

The oled shows the basic stuff I could find in most places.

• Default layer
• Current layer
• Locale
• Mods
• Locks
• Last key pressed
• Map of the current layer as simply as possible. (128x64)

Process_records.c

This is where the keycodes are processed... It tends to be where cruft gathers. Mostly I try to keep it empty and do all my processing with the extensions. The file, extensions.h takes care of inserting them in process_records with it's macro.

Extensions

Extensions are all in the extensions directory and have a single entry point via extensions.h which provides a macro to place in process_record_user. The intention is that they are easy to copy and use as is without digging around in the C code. Custom keys are also defined there. Any keycodes defined by an extension are automatically added to the custom keys enumeration so there is no need to define them manually.

A new extension can be added with a process record entry in extensions.h. Just follow the same code pattern. If an extension defines keycodes, add it's include entry in keycodes.h so that they are automatically added to the enum. Keycodes.h is also where all the miscellaneous short cut key defines are done.

To copy all the extensions,

• Copy the extensions and defs folders,
• Copy process_records.c file or adapt yours.
• Adapt your custom keycodes to custom_keys.def.
• Copy the pertinant parts of config.h so that everything can be enabled.
• Define _USERSPACE_H such that all the extensions can find your stuff.

To adapt to your own process_record_user do this; Include extensions.h in your process_record_user,then add this above the switch.

PROCESS_EXTENSIONS

This will cause process records to use whatever extensions are turned on.

Many extensions have a .def file in /defs for any data that is needed.

Because many of them use custom keycodes or layers in their definitions, it is necessary to include your userspace .h such that keycodes and layer codes can be found. To simplify this, simply add a define to config.h to point at your .h or wherever your custom codes can be found.

In my case;

#define USERSPACE_H "ericgebhart.h"

Custom keys

The Custom keys are in custom_keys.def.

keycodes.h is an extension of sorts. It is the custom keys enumeration. The custom_keys.def has a few random keycodes in it.

All other keys are automatically generated from the other def files.

For the extensions that have key definitions those keys are enumerated automatically. The keys are defined in the def files so there is no need to add them to the enumeration manually.

It will complain as usual if there are duplicates.

Mostly, keycodes.h is key defines to make shortcuts, since the enumeration is done almost completely automatically. When adding a new extension which defines keycodes, that extension will also need an entry in keycodes.h in order to automatically define the new key enumerations it´s def file creates.

Accent keys

This is a way to create keycodes which access keys which are normally only accessible with an Altgr/Ralt and a dead key.

Each definition takes a keycode, the key to modify, and the dead key to apply to it.

ACCENTED(BP_OCIR, BP_O, BP_DCIR)
ACCENTED(BP_ACIR, BP_A, BP_DCIR)

Alternate keycodes

Normally, a keycode has unshifted and shifted key values. These are defined by the OS and it's locale, not the keyboard. This feature allows a keycode to be defined that uses arbitrary unshifted and shifted keycodes and their modifiers. This is necessary, because, for instance, qwerty has , and ; paired. Other locales may not. Bepo, and Beakl both have different pairings as do many other layouts.

Because of wanting dvorak and beakl on bepo there was the necessity to create keys from keycodes which were not combined. key overrides were not sufficient because some keys are not actually keys that can be accessed without modifiers. Each keycode for the new key specifies it's own modifiers making any character available as an unshifted or shifted key.

Alternate keys for a locale, are defined in altlocal_keys.def. These are to emulate a key, from 2 keycodes.

This is for emulating keys on another locale/language. Dvorak on Bepo-fr, or Qwerty on sk-SK, or de_DE.

It is also good for alternate shifted and unshifted pairs like what is needed for beakl or hands down on en-us/qwerty.

This feature is usually only needed for punctuation keys and the top row number keys. Where the unshifted and shifted keys are not the same character as the keyboard local on the OS.

It has turned out that most of these keys have a destination language, and a target language/layout. The target is to emulate something on some language. QMK uses keycode prefixes, so this works pretty well and the names stay consistent with all the others, but with a middle name.

The pattern is Language prefix, target language prefix, name. The target prefix is made up. BK -> beakl, DV -> dvorak, HD -> hands down, etc.

The naming pattern is only important in that it works with all of the Lang macros elsewhere in this userspace. A macro is provided on a per key basis, which can be used at the base layer definition, such that TL_COMM; target-language-comma, becomes BP_BK_COMM, or KC_BK_COMM, or whatever it needs to be based on current language and target layout.

Here is a def entry to create the 1/! keycode for dvorak in the Bepo-fr locale in altlocal_keys.def.

  MK_KEY(BP_DV_1,    BP_DQUO, MOD_LSFT,      BP_DCIR, MOD_LSFT)

Here is what some Beakl keys look like for en-us/qwerty. Beakl has dot with @, comma with ! and " with `.

In altlocal_keys.def.

  // Keys for BEAKL on Qwerty
  MK_KEY(KC_BK_DOT,  KC_DOT, MOD_NONE,    KC_2, MOD_LSFT)
  MK_KEY(KC_BK_COMM, KC_COMMA, MOD_NONE,  KC_1, MOD_LSFT)
  MK_KEY(KC_BK_QUOT, KC_QUOT, MOD_NONE,   KC_GRV, MOD_NONE)

Not Dead keys

As a writer dead keys give me access to accented letters in other languages, As a programmer they are a pain, especially for a vi user. This problem is limited to a few characters; "'`^ and ~. This extension helps to fix these characters and make them accessible as non-dead keys. It does this by adding a space afterward. The space is eaten by the OS keyboard driver and the letter emerges as needed. Here are some non dead keys for US-Intl. In use, I put these on the symbol layer, and let all the others remain dead.

NOT_DEAD(US_DQUO_ND, US_DQUO)
NOT_DEAD(US_GRV_ND,  US_GRV)
NOT_DEAD(US_QUOT_ND, US_QUOT)
NOT_DEAD(US_CIRC_ND, US_CIRC)
NOT_DEAD(US_TILD_ND, US_TILD)

Alternate shifts

The alt shift extension is very simple, it uses a usual keycode, it does not define custom keys. It allows for an existing key like dot or semi-colon to have a different letter on its shifted value.

There are currently three types of shift mods.

• Give a different character than usual on shift.
• Give two of the usual character instead of one.
• Give three of the usual character instead of one.

They are all defined in defs/alt_shift.def. Here are some silly examples.

ALT_SHIFT(US_EXLM, US_PERC)
SHIFT_FOR_2(US_AT)
SHIFT_FOR_3(US_DLR)

Key Overrides

These are the standard QMK key overrides. For un/shifted pair keys altlocal_keys is much, +3x, smaller and direct in that it makes keycodes that can be placed anywhere. However, if ko's are desired, this extension is an easy place to start.

There are nice macros which take care of defining everything that is possible with the ?_ko() functions

This first example is better done with altlocal_keys.

// KOL(slash_pipe,      MOD_MASK_SHIFT, KC_SLSH, KC_PIPE, _DVORAK_EN)

Other key overrides can be defined with these.

KO(name, mods, key, replacement)

KOL(name, mods, modded_key, replacement, layer)

KOLN(name, mods, key, replacement, layer, neg_mods)

KOLNO(name, mods, key, replacement, layer, neg_mods, options)

Combos/Chords

The combos here use multiple reference layers which is a pending pull request in the dev branch of QMK. The combos here will still work to an extent if COMBO_ONLY_FROM_LAYER is set to the correct layer number.

See my pull request to enhance combos here

This pull request defines a hook function for combos to determine the reference layer for the current layer. This allows for multiple reference layers to be used depending on the situation.

Reference layers will be created and used according to the following defines. If the reference layer is enabled, it will automatically be assigned to COMBO_REF_DEFAULT and that will be the default reference if none is specified. If not specified, the reference will be the current layer.

• #define COMBO_REF_LAYER_ENABLE // enable a reference layer.
• #define COMBO_REF_LAYER_TWO_ENABLE // enable a second reference layer
• #define COMBO_ONLY_FROM_LAYER 2
• #define COMBO_REF_DEFAULT 2 Works in config.h if you know the number of your layer. Automatically set if ref layer is enabled.

Defining layer specific combo reference layers by layer in combos.def In this case, the default will be _COMBO_REF, the NAV layer will reference it's self, while bepo dvorak will reference the second combo reference layer. Keys start or end with CB or CB2.

COMBO_REF_LAYER(_DVORAK_BP, _COMBO_REF2)
COMBO_REF_LAYER(_NAV, _NAV)

The combo reference layers follow an easy to remember keycode naming convention so that it is easy to define combos based on position. Keycodes are prefixed by CB or CB2, the first number is the row, followed by L or R for left and right, then the column number, for each hand left to right.

Row 0 is the number row, there are 4 rows possible.

CB_1L1 is the left pinky, CB_1R1 is the inside right hand index column.

  _1L1,  _1L2, _1L3, _1L4,  _1L5,   _1R1, _1R2, _1R3, _1R4, _1R5, 

If there are edge keys, they are named accordingly, left and right.

L0_CB, L1_CB, L2_CB, L3_CB
R0_CB, R1_CB, R2_CB, R3_CB

Thumb keys use the COMBO and COMBO2 thumb settings which give keycodes like this.

#define ___6_ERGO_THUMBS_COMBO___  CB_TH1, CB_TH2, CB_TH3, CB_TH4, CB_TH5, CB_TH6
#define ___6_ERGO_THUMBS_COMBO2___ CB2_TH1, CB2_TH2, CB2_TH3, CB2_TH4, CB2_TH5, CB2_TH6

Tap-Hold

Tap hold currently has tap_taplong and open_openclose functions. These are in tap_hold.c, tap_hold.h and tap_hold.defs. Both use TAP_HOLD_TERM as the hold duration.

Tap_taplong sends one keycode on tap, and another after a hold of tapping term. Open_openclose, sends one keycode on tap, hold sends that, plus the second, followed by a back arrow.

Additionally, open_openclose will send a triple of the open keycode when tapped with the shift modifier on.

There as also a not dead version of open_openclose that accomodates using dead keys like quote so that the functionalty behaves as if the key were not a dead key, giving a quote, a pair of quotes or a triple of quotes.

The file tap_hold.defs contains all the definitions. Like combos, these entries are processed with a function call from process_user_record process_tap_hold_user(keycode, record);

Define your keys in tap_hold.defs.

Here is Ctrl-C, Ctrl-V, as tap and long tap.

TP_TPL(KC_CCCV, LCTL(KC_C), LCTL(KC_V))

For tap open, hold for open and close then a back arrow. Here is ( or () with tap and long tap.

OPEN_OCL(KC_OCPRN, KC_LPRN, KC_RPRN)

OPEN_OCL(KC_OCQUOT, KC_QUOT, KC_QUOT)
// non dead version of quote.
OPEN_OCL_ND(BP_OCQUOT, BP_QUOT, BP_QUOT)
OPEN_OCL_ND(US_OCQUOT, US_QUOT, US_QUOT)

It is also possible to trigger a smart lock with a hold. This example creates a keycode, ENTNAV which can be used to type enter, or smart lock the nav layer. Note that SML_NAV should be defined in smart_lock.defs.

Caveat: This does have the unfortunate behavior of delaying the action until key up. So it may not be that useful. I did not like it for this particular example.

TP_SML(ENTNAV, KC_ENTER, SML_NAV)

Caps Word

This is a slightly modified version of caps word which adds a CAPS_WORD_ON keycode which can be used to turn caps word on explicitly. This is useful for mapping a single key or creating a combo.

As documented in here. Holding both pinkies on home row for double tapping term, is effectively right-shift and left-shift, invokes caps-word. The next word will be capitalized. It continues until it shouldn't.

Smart lock

They are defined in smart_lock.def. They need a custom keycode, and a layer or mods, not mod keycode, to apply, followed by a list of keycodes to ignore and stay active. This allows popping to layer which will stick until it doesn't. Or to apply mods until it shouldn't. Each definition has it's own list of key codes to ignore. Derived from smart_layers by @possumvibes.

Add a keycode to custom_keys.def then assign it to it's action in smart_lock.def.

// SMLL = smart lock layer.
// SMLM = smart lock mod.

// Keycode, layer/mod.
// list of keycodes to ignore.

SMLM(SMLM_LSFT, MOD_LSFT,
  ___VI_ARROWS___,
  ___HOME_PGDN_PGUP_END___,
  ___TAB_PGDN_PGUP_BKTAB___,
  ___SML_MODS_L___)

SMLL(SML_NAV, _NAV, ___NAVA_3x10___)

Mod lock

Mod lock is originally from @possumvibes, it has ignore keys as well, but these keys apply to all locks defined. which gives a slightly smaller memory footprint than smart locks. The mods, are keycodes, rather than mod codes.

The behavior is the same as smart lock mods, but less flexible, and smaller. First create a keycode in custom_keys.def, then assign it to the mod you want.

Ignore keys are universal for all mod locks.

// mod lock keys. takes keymods not mods.
// keycode should be defined in custom_keys.def.
// custom key,  modkey to activate
MODL(ML_LSFT, KC_LSFT)
MODL(ML_LCTL, KC_LCTL)
MODL(ML_LALT, KC_LALT)
MODL(ML_LGUI, KC_LGUI)

// Keycodes which will NOT cancel mod lock mode.
IGNORE_KC( KC_LEFT)
IGNORE_KC( KC_RGHT)

N-shot mods

I simply modified N-shots to use a def file. This is essentially @possumvibes fancier version of @callum's one shot mods. It has ignore and cancel keys, and there are one shot mods or N shot mods. Ignore and cancel keys apply to all oneshot and n-shots.

// Define keycodes in custom keys.
// KEYCode, mod keycode, to set for n-shot.
// ONESHOT is for one.
// NSHOT takes a count.

// oneshots
ONESHOT(OS_LSFT, KC_LSFT)

// N-Shots
NSHOT(TS_LCTL, KC_LCTL, 2)

// Keys which will cancel the n-shots.
CANCEL_KEY( PANIC)

// Keys which will be ignored by n-shots.
IGNORE_KEY( SML_NAV)

One-shot mods

This code came by way of @jurgen-kluft, I encapsulated the code and made the user functions definable with a .def file. This is similar to N-shots. This one keeps track of the last key consumed which helps it's decision making. It also has cancel and ignore keys like N-shots.

Essentially the same as n-shots, but with less elegant C code. Choose one or the other.

In evaluation. The code for nshots is better.

// custom-key, Oneshot name.
ONESHOT( OS_LSFT, ONESHOT_LSFT)

// keys to cancel
CANCEL_KEY( KC_ESC)

// keys to ignore.
IGNORE_KEY( SPC_NAV)

Swapper

I added the defs code so they are easy to define. This is a way to alternate between 2 keycodes for a key by sending another keycode. An example is tab or backtab on one key, which reverses when you press a second key. It also allows for mods to be applied. The following defines SW_WIN, which sends left alt-tab and shift- left alt- tab, when reversed by SW_REV.

SWAPPER_KEY(SW_WIN, SW_REV, KC_TAB, S(KC_TAB), KC_LALT)

Note: The switch key is not automatically defined in the custom keys enum in keycodes.h. It is convenient to use the same one which causes problems for automatically adding it. Add it to custom_keys.def

Encoders

This is basic encoder stuff, modified to use a def file which makes it a lot easier to define and use. It can switch the encoder functions based on layers and mods. Give it a layer name and/or mods to match on, and the clockwise and counter clockwise keycodes to send.

I used LEFT and RIGHT, but really it's just 0-N, but I happen to have one on the left and one on the right. If you have one, use 0 or LEFT.

The code scans the entries for matches on layer first, checking for a match for mods. If an encoder entry is not found it then scans for entries with layer set to LAYER_NONE.

RGB light controls require calling the functions directly, for this there is a special macro and function that does this. The functions should take no arguments.

// Layer/none, encoder index 0/1, CW_KC, CCW_KC, Qualifying mod or none
// LAYER_NONE and MOD_NONE for a single use.
// LEFT and RIGHT for index. they go on from there, 2, 3, etc
// if one encoder, LEFT/0, is the first one, on the master side.

// default encoders, all layers no mods.
ENCODER_ACTION(LAYER_NONE, RIGHT,  KC_PGDN, KC_PGUP, MOD_NONE)
ENCODER_ACTION(LAYER_NONE, LEFT,  KC_DOWN, KC_UP, MOD_NONE)
ENCODER_ACTION(LAYER_NONE, LEFT,  KC_PGDN, KC_PGUP, MOD_LSFT)

// Symbol layer encoders.
ENCODER_ACTION(_SYMB, LEFT, KC_LEFT, KC_RIGHT, MOD_NONE)

// RGB function encoders
ENCODER_FUNCTION(_RGB, LEFT,
                rgb_matrix_increase_speed_noeeprom,
                rgb_matrix_decrease_speed_noeeprom, MOD_NONE)

Unicode

This is just the basic unicode example everyone seems to have. Add your keys to send unicode strings like so.

 UC_STR(UC_DISA, "ಠ_ಠ")

Send_string

This is just basic send string functionality using SEND_STRING and SEND_STRING_DELAY. Each entry defines a key to send a string.

SEND_STR(MYKEY, "this is a test")
SEND_STR_DELAY(VRSN, QMK_KEYBOARD ":" QMK_KEYMAP " @ " QMK_VERSION ", Built on: " QMK_BUILDDATE)

Console key logging - for heat maps.

Both CONSOLE_ENABLE and CONSOLE_KEY_LOGGER_ENABLE must be enabled for this to work.

This is a console key logger which can save keys typed for analysis of keymaps using Vlad/Precondition's heat map tool. The code for the logger came from here The explanation and use of the heatmap is here

There is a script listen_keylogger.sh which should be run to collect the keylogger data.

This does require hid_listen to be installed on the computer. On Arch linux this can by installed from the AUR with yay -S hid_listen

The output can also be seen just by using qmk console.

Note: print.h is automatically included when CONSOLE_ENABLE is set. This allows for debug messages anwhere in the code base as needed to see what might be going on.

Tap Dance

I had a lot of tap dance, It's turned off. It's big. tap-hold works pretty well most of the time, instead. My favorites were tab-backtab, home-end.