1585 lines
56 KiB
Markdown
Executable File
1585 lines
56 KiB
Markdown
Executable File
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 ](https://github.com/EricGebhart/MyQMK/users/ericgebhart)
|
||
|
||
For full multi-lingual combo functionality you will need my [pull request for fully functioning multi-reference combos which can found here.](https://github.com/qmk/qmk_firmware/pull/16699)
|
||
|
||
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.](https://precondition.github.io/qmk-heatmap)
|
||
|
||
|
||
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.](https://docs.qmk.fm/#/reference_keymap_extras)
|
||
* Language support is simple to add with just a new, very simple macro.
|
||
|
||
The language keycodes can be found
|
||
[here.](https://github.com/qmk/qmk_firmware/tree/master/quantum/keymap_extras)
|
||
|
||
|
||
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/<appropiate>.h*.
|
||
* Add the layer name to *layer_names/base_names.h*
|
||
* Add the layer name to *keymap/<appropiate>.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;
|
||
```c
|
||
#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](https://github.com/qmk/qmk_firmware/pull/16699)
|
||
|
||
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.](https://getreuer.info/posts/keyboards/caps-word/index.html)
|
||
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](https://precondition.github.io/qmk-heatmap#how-to-collect-the-required-data)
|
||
The explanation and use of the heatmap is [here](https://precondition.github.io/qmk-heatmap)
|
||
|
||
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.
|
||
|