README.md

   1 # Quantum MK Firmware
   2
   3 This is a keyboard firmware based on the [tmk_keyboard firmware](http://github.com/tmk/tmk_keyboard) with some useful features for Atmel AVR controllers, and more specifically, the [OLKB product line](http://olkb.co) and the [ErgoDox EZ](http://www.ergodox-ez.com) keyboard.
   4
   5 QMK is developed and maintained by Jack Humbert of OLKB with contributions from the community, and of course, TMK.
   6
   7 This documentation is edited and maintained by Erez Zukerman of ErgoDox EZ. If you spot any typos or inaccuracies, please [open an issue](https://github.com/jackhumbert/qmk_firmware/issues/new).
   8
   9 ## Important background info: TMK documentation
  10
  11 The documentation below explains QMK customizations and elaborates on some of the more useful features of TMK. To understand the base firmware, and especially what *layers* are and how they work, please see [TMK_README.md](/TMK_README.md).
  12
  13 ## Getting started
  14
  15 * **If you're looking to customize a keyboard that currently runs QMK or TMK** , find your keyboard's directory under `/keyboard/` and read the README file. This will get you all set up.
  16 * If you're looking to apply this firmware to an entirely new hardware project (a new kind of keyboard), you can create your own Quantum-based project by using `./new_project.sh <project_name>`, which will create `/keyboard/<project_name>` with all the necessary components for a Quantum project.
  17
  18 You have access to a bunch of goodies! Check out the Makefile to enable/disable some of the features. Uncomment the `#` to enable them. Setting them to `no` does nothing and will only confuse future you.
  19
  20     BACKLIGHT_ENABLE = yes # Enable keyboard backlight functionality
  21     MIDI_ENABLE = yes      # MIDI controls
  22     # UNICODE_ENABLE = yes # Unicode support - this is commented out, just as an example. You have to use #, not //
  23     BLUETOOTH_ENABLE = yes # Enable Bluetooth with the Adafruit EZ-Key HID
  24
  25 ## Quick aliases to common actions
  26
  27 Your keymap can include shortcuts to common operations (called "function actions" in tmk).
  28
  29 ### Switching and toggling layers
  30
  31 `MO(layer)` - momentary switch to *layer*. As soon as you let go of the key, the layer is deactivated and you pop back out to the previous layer. When you apply this to a key, that same key must be set as `KC_TRNS` on the destination layer. Otherwise, you won't make it back to the original layer when you release the key (and you'll get a keycode sent). You can only switch to layers *above* your current layer. If you're on layer 0 and you use `MO(1)`, that will switch to layer 1 just fine. But if you include `MO(3)` on layer 5, that won't do anything for you -- because layer 3 is lower than layer 5 on the stack.
  32
  33 `LT(layer, kc)` - momentary switch to *layer* when held, and *kc* when tapped. Like `MO()`, this only works upwards in the layer stack (`layer` must be higher than the current layer).
  34
  35 `TG(layer)` - toggles a layer on or off. As with `MO()`, you should set this key as `KC_TRNS` in the destination layer so that tapping it again actually toggles back to the original layer. Only works upwards in the layer stack.
  36
  37 ### Fun with modifier keys
  38
  39 * `LSFT(kc)` - applies left Shift to *kc* (keycode) - `S(kc)` is an alias
  40 * `RSFT(kc)` - applies right Shift to *kc*
  41 * `LCTL(kc)` - applies left Control to *kc*
  42 * `RCTL(kc)` - applies right Control to *kc*
  43 * `LALT(kc)` - applies left Alt to *kc*
  44 * `RALT(kc)` - applies right Alt to *kc*
  45 * `LGUI(kc)` - applies left GUI (command/win) to *kc*
  46 * `RGUI(kc)` - applies right GUI (command/win) to *kc*
  47 * `HYPR(kc)` - applies Hyper (all modifiers) to *kc*
  48 * `MEH(kc)`  - applies Meh (all modifiers except Win/Cmd) to *kc*
  49
  50 You can also chain these, like this:
  51
  52     LALT(LCTL(KC_DEL)) -- this makes a key that sends Alt, Control, and Delete in a single keypress.
  53
  54 The following shortcuts automatically add `LSFT()` to keycodes to get commonly used symbols. Their long names are also available and documented in `/quantum/keymap_common.h`.
  55
  56     KC_TILD  ~
  57     KC_EXLM  !
  58     KC_AT    @
  59     KC_HASH  #
  60     KC_DLR   $
  61     KC_PERC  %
  62     KC_CIRC  ^
  63     KC_AMPR  &
  64     KC_ASTR  *
  65     KC_LPRN  (
  66     KC_RPRN  )
  67     KC_UNDS  _
  68     KC_PLUS  +
  69     KC_LCBR  {
  70     KC_RCBR  }
  71     KC_PIPE  |
  72     KC_COLN  :
  73
  74 `MT(mod, kc)` - is *mod* (modifier key - MOD_LCTL, MOD_LSFT) when held, and *kc* when tapped. In other words, you can have a key that sends Esc (or the letter O or whatever) when you tap it, but works as a Control key or a Shift key when you hold it down.
  75
  76 These are the values you can use for the `mod` in `MT()` (right-hand modifiers are not available):
  77
  78   * MOD_LCTL
  79   * MOD_LSFT
  80   * MOD_LALT
  81   * MOD_LGUI
  82
  83 These can also be combined like `MOD_LCTL | MOD_LSFT` e.g. `MT(MOD_LCTL | MOD_LSFT, KC_ESC)` which would activate Control and Shift when held, and send Escape when tapped.
  84
  85 We've added shortcuts to make common modifier/tap (mod-tap) mappings more compact:
  86
  87   * `CTL_T(kc)` - is LCTL when held and *kc* when tapped
  88   * `SFT_T(kc)` - is LSFT when held and *kc* when tapped
  89   * `ALT_T(kc)` - is LALT when held and *kc* when tapped
  90   * `GUI_T(kc)` - is LGUI when held and *kc* when tapped
  91   * `ALL_T(kc)` - is Hyper (all mods) when held and *kc* when tapped. To read more about what you can do with a Hyper key, see [this blog post by Brett Terpstra](http://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/)
  92   * `MEH_T(kc)` - is like Hyper, but not as cool -- does not include the Cmd/Win key, so just sends Alt+Ctrl+Shift.
  93
  94 ### Temporarily setting the default layer
  95
  96 `DF(layer)` - sets default layer to *layer*. The default layer is the one at the "bottom" of the layer stack - the ultimate fallback layer. This currently does not persist over power loss. When you plug the keyboard back in, layer 0 will always be the default. It is theoretically possible to work around that, but that's not what `DF` does.
  97
  98 ### Remember: These are just aliases
  99
 100 These functions work the same way that their `ACTION_*` functions do - they're just quick aliases. To dig into all of the tmk ACTION_* functions, please see the [TMK documentation](https://github.com/jackhumbert/qmk_firmware/blob/master/tmk_core/doc/keymap.md#2-action).
 101
 102 Instead of using `FNx` when defining `ACTION_*` functions, you can use `F(x)` - the benefit here is being able to use more than 32 function actions (up to 4096), if you happen to need them.
 103
 104 ## Macro shortcuts: Send a whole string when pressing just one key
 105
 106 Instead of using the `ACTION_MACRO` function, you can simply use `M(n)` to access macro *n* - *n* will get passed into the `action_get_macro` as the `id`, and you can use a switch statement to trigger it. This gets called on the keydown and keyup, so you'll need to use an if statement testing `record->event.pressed` (see keymap_default.c).
 107
 108 ```c
 109 const macro_t *action_get_macro(keyrecord_t *record, uint8_t id, uint8_t opt) // this is the function signature -- just copy/paste it into your keymap file as it is.
 110 {
 111   switch(id) {
 112     case 0: // this would trigger when you hit a key mapped as M(0)
 113       if (record->event.pressed) {
 114         return MACRO( I(255), T(H), T(E), T(L), T(L), W(255), T(O), END  ); // this sends the string 'hello' when the macro executes
 115       }
 116       break;
 117   }
 118   return MACRO_NONE;
 119 };
 120 ```
 121 A macro can include the following commands:
 122
 123 * I() change interval of stroke in milliseconds.
 124 * D() press key.
 125 * U() release key.
 126 * T() type key(press and release).
 127 * W() wait (milliseconds).
 128 * END end mark.
 129
 130 So above you can see the stroke interval changed to 255ms between each keystroke, then a bunch of keys being typed, waits a while, then the macro ends.
 131
 132 Note: Using macros to have your keyboard send passwords for you is a bad idea.
 133
 134 ### Additional keycode aliases for software-implemented layouts (Colemak, Dvorak, etc)
 135
 136 Everything is assuming you're in Qwerty (in software) by default, but there is built-in support for using a Colemak or Dvorak layout by including this at the top of your keymap:
 137
 138    #include "keymap_<layout>.h"
 139
 140 Where <layout> is "colemak" or "dvorak". After including this line, you will get access to:
 141
 142  * `CM_*` for all of the Colemak-equivalent characters
 143  * `DV_*` for all of the Dvorak-equivalent characters
 144
 145 These implementations assume you're using Colemak or Dvorak on your OS, not on your keyboard - this is referred to as a software-implemented layout. If your computer is in Qwerty and your keymap is in Colemak or Dvorak, this is referred to as a firmware-implemented layout, and you won't need these features.
 146
 147 To give an example, if you're using software-implemented Colemak, and want to get an `F`, you would use `CM_F` - `KC_F` under these same circumstances would result in `T`.
 148
 149 ## Additional language support
 150
 151 In `quantum/keymap_extras/`, you'll see various language files - these work the same way as the alternative layout ones do. Most are defined by their two letter country/language code followed by an underscore and a 4-letter abbreviation of its name. `FR_UGRV` which will result in a `ù` when using a software-implemented AZERTY layout. It's currently difficult to send such characters in just the firmware (but it's being worked on - see Unicode support).
 152
 153 ## Unicode support
 154
 155 You can currently send 4 hex digits with your OS-specific modifier key (RALT for OSX with the "Unicode Hex Input" layout) - this is currently limited to supporting one OS at a time, and requires a recompile for switching. 8 digit hex codes are being worked on. The keycode function is `UC(n)`, where *n* is a 4 digit hexidecimal. Enable from the Makefile.
 156
 157 ## Other firmware shortcut keycodes
 158
 159 * `RESET` - puts the MCU in DFU mode for flashing new firmware (with `make dfu`)
 160 * `DEBUG` - the firmware into debug mode - you'll need hid_listen to see things
 161 * `BL_ON` - turns the backlight on
 162 * `BL_OFF` - turns the backlight off
 163 * `BL_<n>` - sets the backlight to level *n*
 164 * `BL_INC` - increments the backlight level by one
 165 * `BL_DEC` - decrements the backlight level by one
 166 * `BL_TOGG` - toggles the backlight
 167 * `BL_STEP` - steps through the backlight levels
 168
 169 Enable the backlight from the Makefile.
 170
 171 ## MIDI functionalty
 172
 173 This is still a WIP, but check out `quantum/keymap_midi.c` to see what's happening. Enable from the Makefile.
 174
 175 ## Bluetooth functionality
 176
 177 This requires [some hardware changes](https://www.reddit.com/r/MechanicalKeyboards/comments/3psx0q/the_planck_keyboard_with_bluetooth_guide_and/?ref=search_posts), but can be enabled via the Makefile. The firmware will still output characters via USB, so be aware of this when charging via a computer. It would make sense to have a switch on the Bluefruit to turn it off at will.