-If you have an idea for a custom feature or extra hardware connection, we'd love to accept it into QMK! These are generally done via [pull request](https://github.com/qmk/qmk_firmware/pulls) after forking, and here are some things to keep in mind when creating one:
-
-* **Disable by default** - memory is a pretty limited on most chips QMK supports, and it's important that current keymaps aren't broken, so please allow your feature to be turned **on**, rather than being turned off. If you think it should be on by default, or reduces the size of the code, [open an issue](https://github.com/qmk/qmk_firmware/issues) for everyone to discuss it!
-* **Compile locally before submitting** - hopefully this one is obvious, but things need to compile! Our Travis system will catch any issues, but it's generally faster for you to compile a few keyboards locally instead of waiting for the results to come back.
-* **Consider subprojects and different chip-bases** - there are several keyboards that have subprojects that have allow for slightly different configurations, and even different chip-bases. Try to make a feature supported in ARM and AVR, or automatically disabled in one that doesn't work.
-* **Explain your feature** - submitting a markdown write-up of what your feature does with your PR may be needed, and it will allow a collaborator to easily copy it into the wiki for documentation (after proofing and editing).
-* **Don't refactor code** - to maintain a clear vision of how things are laid out in QMK, we try to plan out refactors in-depth, and have a collaborator make the changes. If you have an idea for refactoring, or suggestions, [open an issue](https://github.com/qmk/qmk_firmware/issues).
-If you have any problems building the firmware, you can try using a tool called Vagrant. It will set up a virtual computer with a known configuration that's ready-to-go for firmware building. OLKB does NOT host the files for this virtual computer. Details on how to set up Vagrant are in the [VAGRANT_GUIDE file](VAGRANT_GUIDE.md).
+If you have any problems building the firmware, you can try using a tool called Vagrant. It will set up a virtual computer with a known configuration that's ready-to-go for firmware building. OLKB does NOT host the files for this virtual computer. Details on how to set up Vagrant are in the [vagrant guide](vagrant_guide.md).
## Verify Your Installation
1. If you haven't already, obtain this repository ([https://github.com/qmk/qmk_firmware](https://github.com/qmk/qmk_firmware)). You can either download it as a zip file and extract it, or clone it using the command line tool git or the Github Desktop application.
-A QMK collaborator is a keyboard maker/designer that is interested in helping QMK grow and fully support their keyboard(s), and encouraging their users/customers to submit features, ideas, and keymaps. We're always looking to add more keyboards and collaborators, but we ask that they fulfill these requirements:
-
-* **Have a PCB available for sale** - unfortunately there's just too much variation and complications with handwired keyboards.
-* **Maintain the your keyboard's directory** - this may just require an initial setup to get your keyboard working, but it could also include accommodating changes made to QMK's core.
-* **Approve and merge your keyboard's keymap pull requests** - we like to encourage users to contribute their keymaps for others to see and work from when creating their own.
-
-If you feel you meet these requirements, shoot us an email at hello@qmk.fm with an introduction and some links to your keyboard!
-If you have Windows 10 with Creators Update or later, you can build and flash the firmware directly. Before the Creators Update, only building was possible. If you don't have it yet or if are unsure, follow [these instructions](https://support.microsoft.com/en-us/instantanswers/d4efb316-79f0-1aa1-9ef3-dcada78f3fa0/get-the-windows-10-creators-update).
-
-#### Windows Subsystem for Linux
-In addition to the Creators Update, you need Windows 10 Subystem for Linux, so install it following [these instructions](http://www.howtogeek.com/249966/how-to-install-and-use-the-linux-bash-shell-on-windows-10/). If you already have the Windows 10 Subsystem for Linux from the Anniversary update it's recommended that you [upgrade](https://betanews.com/2017/04/14/upgrade-windows-subsystem-for-linux/) it to 16.04LTS, because some keyboards don't compile with the toolchains included in 14.04LTS. Note that you need to know what your are doing if you chose the `sudo do-release-upgrade` method.
-
-#### Git
-If you already have cloned the repository on your Windows file system you can ignore this section.
-
-You will need to clone the repository to your Windows file system using the normal Git for Windows and **not** the WSL Git. So if you haven't installed Git before, [download](https://git-scm.com/download/win) and install it. Then [set it up](https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup), it's important that you setup the e-mail and user name, especially if you are planning to contribute.
-
-Once Git is installed, open the Git bash command and change the directory to where you want to clone QMK, note that you have to use forward slashes, and that your c drive is accessed like this `/c/path/to/where/you/want/to/go`. Then run `git clone --recurse-submodules https://github.com/qmk/qmk_firmware`, this will create a new folder `qmk_firmware` as a subfolder of the current one.
-
-#### Toolchain setup
-The Toolchain setup is done through the Windows Subsystem for Linux, and the process is fully automated. If you want to do everything manually, there are no other instructions than the scripts themselves, but you can always open issues and ask for more information.
-
-1. Open "Bash On Ubuntu On Windows" from the start menu.
-2. Go to the directory where you cloned `qmk_firmware`. Note that the paths start with `/mnt/` in the WSL, so you have to write for example `cd /mnt/c/path/to/qmk_firmware`.
-3. Run `util/wsl_install.sh` and follow the on-screen instructions.
-4. Close the Bash command window, and re-open it.
-5. You are ready to compile and flash the firmware!
-
-#### Some important things to keep in mind
-* You can run `util/wsl_install.sh` again to get all the newest updates.
-* Your QMK repository need to be on a Windows file system path, since WSL can't run executables outside it.
-* The WSL Git is **not** compatible with the Windows Git, so use the Windows Git Bash or a windows Git GUI for all Git operations
-* You can edit files either inside WSL or normally using Windows, but note that if you edit makefiles or shell scripts, make sure you are using an editor that saves the files with Unix line endings. Otherwise the compilation might not work.
-
-### Windows (Vista and later)
-1. If you have ever installed WinAVR, uninstall it.
-2. Install [MHV AVR Tools](https://infernoembedded.com/sites/default/files/project/MHV_AVR_Tools_20131101.exe). Disable smatch, but **be sure to leave the option to add the tools to the PATH checked**.
-3. If you are going to flash Infinity based keyboards you will need to install dfu-util, refer to the instructions by [Input Club](https://github.com/kiibohd/controller/wiki/Loading-DFU-Firmware).
-4. Install [MinGW](https://sourceforge.net/projects/mingw/files/Installer/mingw-get-setup.exe/download). During installation, uncheck the option to install a graphical user interface. **DO NOT change the default installation folder.** The scripts depend on the default location.
-5. Clone this repository. [This link will download it as a zip file, which you'll need to extract.](https://github.com/qmk/qmk_firmware/archive/master.zip) Open the extracted folder in Windows Explorer.
-6. Open the `\util` folder.
-7. Double-click on the `1-setup-path-win` batch script to run it. You'll need to accept a User Account Control prompt. Press the spacebar to dismiss the success message in the command prompt that pops up.
-8. Right-click on the `2-setup-environment-win` batch script, select "Run as administrator", and accept the User Account Control prompt. This part may take a couple of minutes, and you'll need to approve a driver installation, but once it finishes, your environment is complete!
-
-If you have trouble and want to ask for help, it is useful to generate a *Win_Check_Output.txt* file by running `Win_Check.bat` in the `\util` folder.
-
-### Mac
-If you're using [homebrew,](http://brew.sh/) you can use the following commands:
-
- brew tap osx-cross/avr
- brew install avr-libc
- brew install dfu-programmer
-
-This is the recommended method. If you don't have homebrew, [install it!](http://brew.sh/) It's very much worth it for anyone who works in the command line. Note that the `make` and `make install` portion during the homebrew installation of avr-libc can take over 20 minutes and exhibit high CPU usage.
-
-You can also try these instructions:
-
-1. Install Xcode from the App Store.
-2. Install the Command Line Tools from `Xcode->Preferences->Downloads`.
-If you are going to flash Infinity based keyboards you will also need dfu-util
-
- brew install dfu-util
-
-### Linux
-
-To ensure you are always up to date, you can just run `sudo util/install_dependencies.sh`. That should always install all the dependencies needed. **This will run `apt-get upgrade`.**
-
-You can also install things manually, but this documentation might not be always up to date with all requirements.
-
-The current requirements are the following, but not all might be needed depending on what you do. Also note that some systems might not have all the dependencies available as packages, or they might be named differently.
-
-```
-build-essential
-gcc
-unzip
-wget
-zip
-gcc-avr
-binutils-avr
-avr-libc
-dfu-programmer
-dfu-util
-gcc-arm-none-eabi
-binutils-arm-none-eabi
-libnewlib-arm-none-eabi
-git
-```
-
-Install the dependencies with your favorite package manager.
-If this is a bit complex for you, Docker might be the turn-key solution you need. After installing [Docker](https://www.docker.com/products/docker), run the following command at the root of the QMK folder to build a keyboard/keymap:
-
-```bash
-# You'll run this every time you want to build a keymap
-# modify the keymap and keyboard assigment to compile what you want
-# On windows docker seems to have issue with VOLUME tag in Dockerfile, and $('pwd') won't print a windows compliant path, use full path instead like this
-This will compile the targeted keyboard/keymap and leave it in your QMK directory for you to flash.
-
-### Vagrant
-If you have any problems building the firmware, you can try using a tool called Vagrant. It will set up a virtual computer with a known configuration that's ready-to-go for firmware building. OLKB does NOT host the files for this virtual computer. Details on how to set up Vagrant are in the [VAGRANT_GUIDE file](https://github.com/qmk/qmk_firmware/blob/master/doc/VAGRANT_GUIDE.md).
-
-## Verify Your Installation
-1. If you haven't already, obtain this repository ([https://github.com/qmk/qmk_firmware](https://github.com/qmk/qmk_firmware)). You can either download it as a zip file and extract it, or clone it using the command line tool git or the Github Desktop application.
-2. Open up a terminal or command prompt and navigate to the `qmk_firmware` folder using the `cd` command. The command prompt will typically open to your home directory. If, for example, you cloned the repository to your Documents folder, then you would type `cd Documents/qmk_firmware`. If you extracted the file from a zip, then it may be named `qmk_firmware-master` instead.
-3. To confirm that you're in the correct location, you can display the contents of your current folder using the `dir` command on Windows, or the `ls` command on Linux or Mac. You should see several files, including `readme.md` and a `quantum` folder. From here, you need to navigate to the appropriate folder under `keyboards/`. For example, if you're building for a Planck, run `cd keyboards/planck`.
-4. Once you're in the correct keyboard-specific folder, run the `make` command. This should output a lot of information about the build process. More information about the `make` command can be found below.
-A custom keyboard is about more than sending button presses to your computer. QMK has designed hooks to allow you to inject code, override functionality, and otherwise customize how your keyboard responds in different situations.
-
-## A Word on Keyboards vs Keymap
-
-We have structured QMK as a hierarchy:
-
-* Core (`_quantum`)
- * Keyboard/Revision (`_kb`)
- * Keymap (`_user`)
-
-Each of the functions described below can be defined with a `_kb()` suffix or an `_user()` suffix. We intend for you to use the `_kb()` suffix at the Keyboard/Revision level, while the `_user()` suffix should be used at the Keymap level.
-
-When defining functions at the Keyboard/Revision level it is important that your `_kb()` implementation call `_user()` before executing anything else- otherwise the keymap level function will never be called.
-
-## Matrix Initialization Code
-
-* Keyboard/Revision: `void matrix_init_kb(void)`
-* Keymap: `void matrix_init_user(void)`
-
-This function gets called when the matrix is initiated. You should use this function to initialize any custom hardware you may have, such as speakers, LED drivers, or other features which need to be setup after the keyboard powers on.
-
-### Example
-
-```
-void matrix_init_kb(void) {
- // put your keyboard start-up code here
- // runs once when the firmware starts up
- matrix_init_user();
-
- // JTAG disable for PORT F. write JTD bit twice within four cycles.
- MCUCR |= (1<<JTD);
- MCUCR |= (1<<JTD);
-
- // * Set our LED pins as output
- DDRB |= (1<<0);
- DDRB |= (1<<1);
- DDRB |= (1<<2);
- DDRB |= (1<<3);
- DDRB |= (1<<4);
-}
-```
-
-## Matrix Scanning Code
-
-* Keyboard/Revision: `void matrix_scan_kb(void)`
-* Keymap: `void matrix_scan_user(void)`
-
-This function gets called at every matrix scan, which is basically as often as the MCU can handle. Be careful what you put here, as it will get run a lot.
-
-You should use this function if you need custom matrix scanning code. It can also be used for custom status output (such as LED's or a display) or other functionality that you want to trigger regularly even when the user isn't typing.
-This function gets called every time a key is pressed or released. This is particularly useful when defining custom keys or overriding the behavior of existing keys.
-
-The return value is whether or not QMK should continue processing the keycode - returning `false` stops the execution.
-
-The `keycode` variable is whatever is defined in your keymap, eg `MO(1)`, `KC_L`, etc. and can be switch-cased to execute code whenever a particular code is pressed.
-
-The `record` variable contains infomation about the actual press:
-
-```
-keyrecord_t record {
-+-keyevent_t event {
-| +-keypos_t key {
-| | +-uint8_t col
-| | +-uint8_t row
-| | }
-| +-bool pressed
-| +-uint16_t time
-| }
-}
-```
-
-The conditional `if (record->event.pressed)` can tell if the key is being pressed or released, and you can execute code based on that.
-Understanding the essential changes made on the [tmk_keyboard firmware](http://github.com/tmk/tmk_keyboard) should help you understand the QMK Firmware.
-# Dynamic macros: record and replay macros in runtime
-
-QMK supports temporarily macros created on the fly. We call these Dynamic Macros. They are defined by the user from the keyboard and are lost when the keyboard is unplugged or otherwise rebooted.
-
-You can store one or two macros and they may have a combined total of 128 keypresses. You can increase this size at the cost of RAM.
-
-To enable them, first add a new element to the `planck_keycodes` enum — `DYNAMIC_MACRO_RANGE`:
-
-```c
-enum planck_keycodes {
- QWERTY = SAFE_RANGE,
- COLEMAK,
- DVORAK,
- PLOVER,
- LOWER,
- RAISE,
- BACKLIT,
- EXT_PLV,
- DYNAMIC_MACRO_RANGE,
-};
-```
-
-It must be the last element because `dynamic_macros.h` will add some more keycodes after it.
-
-Below it include the `dynamic_macro.h` header:
-
-```c
- #include "dynamic_macro.h"`
-```
-
-Add the following keys to your keymap:
-
-* `DYN_REC_START1` — start recording the macro 1,
-* `DYN_REC_START2` — start recording the macro 2,
-* `DYN_MACRO_PLAY1` — replay the macro 1,
-* `DYN_MACRO_PLAY2` — replay the macro 2,
-* `DYN_REC_STOP` — finish the macro that is currently being recorded.
-
-Add the following code to the very beginning of your `process_record_user()` function:
-
-```c
- if (!process_record_dynamic_macro(keycode, record)) {
- return false;
- }
-```
-
-That should be everything necessary. To start recording the macro, press either `DYN_REC_START1` or `DYN_REC_START2`. To finish the recording, press the `DYN_REC_STOP` layer button. To replay the macro, press either `DYN_MACRO_PLAY1` or `DYN_MACRO_PLAY2`.
-
-Note that it's possible to replay a macro as part of a macro. It's ok to replay macro 2 while recording macro 1 and vice versa but never create recursive macros i.e. macro 1 that replays macro 1. If you do so and the keyboard will get unresponsive, unplug the keyboard and plug it again.
-
-For users of the earlier versions of dynamic macros: It is still possible to finish the macro recording using just the layer modifier used to access the dynamic macro keys, without a dedicated `DYN_REC_STOP` key. If you want this behavior back, use the following snippet instead of the one above:
- if (!process_record_dynamic_macro(macro_kc, record)) {
- return false;
- }
-```
-
-If the LED's start blinking during the recording with each keypress, it means there is no more space for the macro in the macro buffer. To fit the macro in, either make the other macro shorter (they share the same buffer) or increase the buffer size by setting the `DYNAMIC_MACRO_SIZE` preprocessor macro (default value: 128; please read the comments for it in the header).
-
-For the details about the internals of the dynamic macros, please read the comments in the `dynamic_macro.h` header.
@@ -15,7+15,7 @@ Note that this set-up has been tested on Ubuntu 16.04 only for the moment.
# Prerequisites
## Build environment
-Before starting, you must have followed the [Getting Started](/Home.md#getting-started) section corresponding to your system. In particular, you must have been able to build the firmware with [the `make` command](../#the-make-command).
+Before starting, you must have followed the [Getting Started](home.md#getting-started) section corresponding to your system. In particular, you must have been able to build the firmware with [the `make` command](../#the-make-command).
## Java
Eclipse is a Java application, so you will need to install Java 8 or more recent to be able to run it. You may choose between the JRE or the JDK, the latter being useful if you intend to do Java development.
-**PJRC** stack won't be supported actively anymore. There is no reason to hesitate to use LUFA except for binary size(about 1KB lager?). But **PJRC** is still very useful for debug and development purpose.
-See also [Issue #50](https://github.com/tmk/tmk_keyboard/issues/50) and [Issue #58](https://github.com/tmk/tmk_keyboard/issues/58).
-
-## Edit configuration but not change
-You will need followings after editing `CONSOLE_ENABLE`, `NKRO_ENABLE`, `EXTRAKEY_ENABLE` or `MOUSEKEY_ENABLE` option in **Makefile**.
-
-### 1. make clean
-This will be needed when you edit **config.h**.
-
-### 2. Remove Drivers from Device Manager(Windows)
-**Windows only.** Linux, OSX and other OS's doesn't require this. It looks like Windows keeps using driver installed when device was connected first time even after the device changes its configuration. To load proper drivers for new configuration you need to remove existent drivers from **Drvice Manager**.
-
-### 3. Build with different VID:PID
-**Windows only.** If method 2. does't work fou you try this. Change Vendor ID or Product ID in **config.h** and build firmware. Windows should recognize it as whole new device and start drivers install process.
-
-### 4. Just try other ports
-This will be useful and the easiest workaround for **Windows**.
-
-
-
-## USB VID and PID
-You can use any ID you want with editing `config.h`. Using any presumably unused ID will be no problem in fact except for very least chance of collision with other product.
-
-For example TMK uses following numbers by default.
-```
-keyboard:
-hhkb: FEED:CAFE
-gh60: FEED:6060
-
-converter:
-x68k: FEED:6800
-ps2: FEED:6512
-adb: FEED:0ADB
-ibm4704: FEED:4704
-pc98: FEED:9898
-```
-
-Also see this.
-https://github.com/tmk/tmk_keyboard/issues/150
-
-You can buy a really unique VID:PID here. I don't think you need this for personal use.
-On Linux you need proper privilege to access device file of MCU, you'll have to use `sudo` when flashing firmware. You can circumvent this with placing these files in `/etc/udev/rules.d/`.
-See [Keycodes](Keycodes). Keycodes are actually defined in [common/keycode.h](https://github.com/qmk/qmk_firmware/blob/master/tmk_core/common/keycode.h).
-
-## Sysrq key
-Use keycode for Print Screen(`KC_PSCREEN` or `KC_PSCR`) instead of `KC_SYSREQ`. Key combination of 'Alt + Print Screen' is recognized as 'System request'.
-
-See [issue #168](https://github.com/tmk/tmk_keyboard/issues/168) and
-- http://en.wikipedia.org/wiki/Magic_SysRq_key
-- http://en.wikipedia.org/wiki/System_request
-
-## Power key doesn't work
-Use `KC_PWR` instead of `KC_POWER` or vice versa.
-- `KC_PWR` works with Windows and Linux, not with OSX.
-- `KC_POWER` works with OSX and Linux, not with Windows.
-Solves my personal 'the' problem. I often got 'the' or 'THe' wrongly instead of 'The'. Oneshot Shift mitgates this for me.
-https://github.com/tmk/tmk_keyboard/issues/67
-
-## Modifier/Layer stuck
-Modifier keys or layers can be stuck unless layer switching is configured properly.
-For Modifier keys and layer actions you have to place `KC_TRANS` on same position of destination layer to unregister the modifier key or return to previous layer on release event.
-This feature is for *mechanical lock switch* like this Alps one.
-http://deskthority.net/wiki/Alps_SKCL_Lock
-
-Using enabling this feature and using keycodes `LCAP`, `LNUM` or `LSCR` in keymap you can use physical locking CapsLock, NumLock or ScrollLock keys as you expected.
-
-Old vintage mechanical keyboards occasionally have lock switches but modern ones don't have. ***You don't need this feature in most case and just use keycodes `CAPS`, `NLCK` and `SLCK`.***
-
-
-## Input special charactors other than ASCII like Cédille 'Ç'
-NO UNIVERSAL METHOD TO INPUT THOSE WORKS OVER ALL SYSTEMS. You have to define **MACRO** in way specific to your OS or layout.
-Apple/Mac keyboard sends keycode for Fn unlike most of other keyboards.
-I think you can send Apple Fn key using Apple venter specific Page 0xff01 and usage 0x0003. But you have to change HID Report Descriptor for this, of course.
-Japanese JIS keyboard specific keys like `無変換(Muhenkan)`, `変換(Henkan)`, `ひらがな(hiragana)` are not recognized on OSX. You can use **Seil** to enable those keys, try following options.
-
-* Enable NFER Key on PC keyboard
-* Enable XFER Key on PC keyboard
-* Enable KATAKANA Key on PC keyboard
-
-https://pqrs.org/osx/karabiner/seil.html
-
-
-## RN-42 Bluetooth doesn't work with Karabiner
-Karabiner - Keymapping tool on Mac OSX - ignores inputs from RN-42 module by default. You have to enable this option to make Karabiner working with your keyboard.
-This turns right modifer keys into arrow keys when the keys are tapped while still modifiers when the keys are hold. In TMK the dual-role function is dubbed **TAP**.
-```
-#include "keymap_common.h"
-
-
-/* Arrow keys on right modifier keys with TMK dual role feature
-`EJCT` keycode works on OSX. https://github.com/tmk/tmk_keyboard/issues/250
-It seems Windows 10 ignores the code and Linux/Xorg recognizes but has no mapping by default.
-
-Not sure what keycode Eject is on genuine Apple keyboard actually. HHKB uses `F20` for Eject key(`Fn+f`) on Mac mode but this is not same as Apple Eject keycode probably.
-
-
-
-## What's weak_mods and real_mods in action_util.c
-___TO BE IMPROVED___
-
-real_mods is intended to retains state of real/physical modifier key state, while
-weak_mods retains state of virtual or temprary modifiers which should not affect state real modifier key.
-
-Let's say you hold down physical left shift key and type ACTION_MODS_KEY(LSHIFT, KC_A),
-
-with weak_mods,
-* (1) hold down left shift: real_mods |= MOD_BIT(LSHIFT)
@@ -282,7+282,7 @@ It's also important to use the `KEYMAP` function we defined earlier - this is wh
#### Compiling your firmware
-After you've written out your entire keymap, you're ready to get the firmware compiled and onto your Teensy. Before compiling, you'll need to get your [development environment set-up](/doc/BUILD_GUIDE.md) - you can skip the dfu-programmer instructions, but you'll need to download and install the [Teensy Loader](https://www.pjrc.com/teensy/loader.html) to get the firmware on your Teensy.
+After you've written out your entire keymap, you're ready to get the firmware compiled and onto your Teensy. Before compiling, you'll need to get your [development environment set-up](build_guide.md) - you can skip the dfu-programmer instructions, but you'll need to download and install the [Teensy Loader](https://www.pjrc.com/teensy/loader.html) to get the firmware on your Teensy.
Once everything is installed, running `make` in the terminal should get you some output, and eventually a `<project_name>.hex` file in that folder. If you're having trouble with this step, see the end of the guide for the trouble-shooting section.
-You have found the QMK Firmware documentation site. This is a keyboard firmware based on the [tmk\_keyboard firmware](http://github.com/tmk/tmk_keyboard) \([view differences](/Differences-from-TMK.md)\) with some useful features for Atmel AVR controllers, and more specifically, the [OLKB product line](http://olkb.com), the [ErgoDox EZ](http://www.ergodox-ez.com) keyboard, and the [Clueboard product line](http://clueboard.co/). It has also been ported to ARM chips using ChibiOS. You can use it to power your own hand-wired or custom keyboard PCB.
+You have found the QMK Firmware documentation site. This is a keyboard firmware based on the [tmk\_keyboard firmware](http://github.com/tmk/tmk_keyboard) \([view differences](differences_from_tmk.md)\) with some useful features for Atmel AVR controllers, and more specifically, the [OLKB product line](http://olkb.com), the [ErgoDox EZ](http://www.ergodox-ez.com) keyboard, and the [Clueboard product line](http://clueboard.co/). It has also been ported to ARM chips using ChibiOS. You can use it to power your own hand-wired or custom keyboard PCB.
# Getting started
Before you are able to compile, you'll need to install an environment for AVR or ARM development. You'll find the instructions for any OS below. If you find another/better way to set things up from scratch, please consider [making a pull request](https://github.com/qmk/qmk_firmware/pulls) with your changes!
-The QMK Firmware can be configured via the `keymaps` array data. For simply generating a [basic keycode](/Keycodes.md), you add it as an element of your `keymaps` array data. For more complicated actions, there are more advanced keycodes that are organized carefully to represent common operations, some of which can be found on the [Key Functions](/Key-Functions.md) page.
+The QMK Firmware can be configured via the `keymaps` array data. For simply generating a [basic keycode](keycodes.md), you add it as an element of your `keymaps` array data. For more complicated actions, there are more advanced keycodes that are organized carefully to represent common operations, some of which can be found on the [Key Functions](key_functions.md) page.
-For more details of the `keymaps` array, see [Keymap Overview](/Keymap.md) page.
+For more details of the `keymaps` array, see [Keymap Overview](keymap.md) page.
## Space Cadet Shift: The future, built in
-Steve Losh [described](http://stevelosh.com/blog/2012/10/a-modern-space-cadet/) the Space Cadet Shift quite well. Essentially, you hit the left Shift on its own, and you get an opening parenthesis; hit the right Shift on its own, and you get the closing one. When hit with other keys, the Shift key keeps working as it always does. Yes, it's as cool as it sounds. Head on over to the [Space Cadet Shift](/Space-Cadet-Shift.md) page to read about it.
+Steve Losh [described](http://stevelosh.com/blog/2012/10/a-modern-space-cadet/) the Space Cadet Shift quite well. Essentially, you hit the left Shift on its own, and you get an opening parenthesis; hit the right Shift on its own, and you get the closing one. When hit with other keys, the Shift key keeps working as it always does. Yes, it's as cool as it sounds. Head on over to the [Space Cadet Shift](space_cadet_shift.md) page to read about it.
## The Leader key: A new kind of modifier
-Most modifiers have to be held or toggled. But what if you had a key that indicated the start of a sequence? You could press that key and then rapidly press 1-3 more keys to trigger a macro, or enter a special layer, or anything else you might want to do. To learn more about it check out the [Leader Key](/Leader-Key.md) page.
+Most modifiers have to be held or toggled. But what if you had a key that indicated the start of a sequence? You could press that key and then rapidly press 1-3 more keys to trigger a macro, or enter a special layer, or anything else you might want to do. To learn more about it check out the [Leader Key](leader_key.md) page.
## Tap Dance: A single key can do 3, 5, or 100 different things
-Hit the semicolon key once, send a semicolon. Hit it twice, rapidly -- send a colon. Hit it three times, and your keyboard's LEDs do a wild dance. That's just one example of what Tap Dance can do. Read more about it on the [Tap Dance](/Tap-Dance.md) page.
+Hit the semicolon key once, send a semicolon. Hit it twice, rapidly -- send a colon. Hit it three times, and your keyboard's LEDs do a wild dance. That's just one example of what Tap Dance can do. Read more about it on the [Tap Dance](tap_dance.md) page.
## Temporarily setting the default layer
@@ -33,7+33,7 @@ Hit the semicolon key once, send a semicolon. Hit it twice, rapidly -- send a co
## Macro shortcuts: Send a whole string when pressing just one key
-How would you like a single keypress to send a whole word, sentence, paragraph, or even document? Head on over to the [Macros](/Macros.md) page to read up on all aspects of Simple and Dynamic Macros.
+How would you like a single keypress to send a whole word, sentence, paragraph, or even document? Head on over to the [Macros](macros.md) page to read up on all aspects of Simple and Dynamic Macros.
## Additional keycode aliases for software-implemented layouts \(Colemak, Dvorak, etc\)
-Your keymap can include shortcuts to common operations (called "function actions" in tmk).
-
-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/qmk/qmk_firmware/blob/master/doc/keymap.md#2-action).
-
-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.
-
-### Switching and toggling layers
-
-`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.
-
-`OSL(layer)` - momentary switch to *layer*, as a one-shot operation. So if you have a key that's defined as `OSL(1)`, and you tap that key, then only the very next keystroke would come from layer 1. You would drop back to layer zero immediately after that one keystroke. That's handy if you have a layer full of custom shortcuts -- for example, a dedicated key for closing a window. So you tap your one-shot layer mod, then tap that magic 'close window' key, and keep typing like a boss. Layer 1 would remain active as long as you hold that key down, too (so you can use it like a momentary toggle-layer key with extra powers).
-
-`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).
-
-`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.
-
-`TO(layer)` - Goes to a layer. This code is special, because it lets you go either up or down the stack -- just goes directly to the layer you want. So while other codes only let you go _up_ the stack (from layer 0 to layer 3, for example), `TO(2)` is going to get you to layer 2, no matter where you activate it from -- even if you're currently on layer 5. This gets activated on keydown (as soon as the key is pressed).
-
-`TT(layer)` - Layer Tap-Toggle. If you hold the key down, the layer becomes active, and then deactivates when you let go. And if you tap it, the layer simply becomes active (toggles on). It needs 5 taps by default, but you can set it by defining `TAPPING_TOGGLE`, for example, `#define TAPPING_TOGGLE 1` for just one tap.
-
-
-### Fun with modifier keys
-
-* `LSFT(kc)` - applies left Shift to *kc* (keycode) - `S(kc)` is an alias
-* `RSFT(kc)` - applies right Shift to *kc*
-* `LCTL(kc)` - applies left Control to *kc*
-* `RCTL(kc)` - applies right Control to *kc*
-* `LALT(kc)` - applies left Alt to *kc*
-* `RALT(kc)` - applies right Alt to *kc*
-* `LGUI(kc)` - applies left GUI (command/win) to *kc*
-* `RGUI(kc)` - applies right GUI (command/win) to *kc*
-* `HYPR(kc)` - applies Hyper (all modifiers) to *kc*
- LALT(LCTL(KC_DEL)) -- this makes a key that sends Alt, Control, and Delete in a single keypress.
-
-The following shortcuts automatically add `LSFT()` to keycodes to get commonly used symbols. Their long names are also available and documented in `quantum/quantum_keycodes.h`.
-
- KC_TILD ~
- KC_EXLM !
- KC_QUES ?
- KC_AT @
- KC_HASH #
- KC_DLR $
- KC_PERC %
- KC_CIRC ^
- KC_AMPR &
- KC_ASTR *
- KC_LPRN (
- KC_RPRN )
- KC_UNDS _
- KC_PLUS +
- KC_DQUO "
- KC_LCBR {
- KC_RCBR }
- KC_LABK <
- KC_RABK >
- KC_PIPE |
- KC_COLN :
-
-`OSM(mod)` - this is a "one shot" modifier. So let's say you have your left Shift key defined as `OSM(MOD_LSFT)`. Tap it, let go, and Shift is "on" -- but only for the next character you'll type. So to write "The", you don't need to hold down Shift -- you tap it, tap t, and move on with life. And if you hold down the left Shift key, it just works as a left Shift key, as you would expect (so you could type THE). There's also a magical, secret way to "lock" a modifier by tapping it multiple times. If you want to learn more about that, open an issue. :)
-
-`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.
-
-These are the values you can use for the `mod` in `MT()` and `OSM()`:
-
- * MOD_LCTL
- * MOD_LSFT
- * MOD_LALT
- * MOD_LGUI
- * MOD_RCTL
- * MOD_RSFT
- * MOD_RALT
- * MOD_RGUI
- * MOD_HYPR
- * MOD_MEH
-
-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. Note however, that you cannot mix right and left side modifiers.
-
-We've added shortcuts to make common modifier/tap (mod-tap) mappings more compact:
-
- * `CTL_T(kc)` - is LCTL when held and *kc* when tapped
- * `SFT_T(kc)` - is LSFT when held and *kc* when tapped
- * `ALT_T(kc)` - is LALT when held and *kc* when tapped
- * `ALGR_T(kc)` - is AltGr when held and *kc* when tapped
- * `GUI_T(kc)` - is LGUI when held and *kc* when tapped
- * `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/)
- * `LCAG_T(kc)` - is CtrlAltGui when held and *kc* when tapped
- * `MEH_T(kc)` - is like Hyper, but not as cool -- does not include the Cmd/Win key, so just sends Alt+Ctrl+Shift.
-
-##### Permissive Hold
-
-As of [PR#1359](https://github.com/qmk/qmk_firmware/pull/1359/), there is a new `config.h` option:
-
-```
-#define PERMISSIVE_HOLD
-```
-
-This makes it easier for fast typists to use dual-function keys. As described in the PR:
-
-Without this, if you let go of a held key inside the tapping term, it won't register.
-
-Example: (Tapping Term = 200)
-
-- SHFT_T(KC_A) Down
-- KC_X Down
-- KC_X Up
-- SHFT_T(KC_A) Up
-
-With permissive hold, if above is typed within tapping term, this will emit `X` (so, Shift+X).
-
-With defaults, if above is typed within tapping term, this will emit `ax`, which I doubt is what anyone really wants
-If you've ever used Vim, you know what a Leader key is. If not, you're about to discover a wonderful concept. :) Instead of hitting Alt+Shift+W for example (holding down three keys at the same time), what if you could hit a _sequence_ of keys instead? So you'd hit our special modifier (the Leader key), followed by W and then C (just a rapid succession of keys), and something would happen.
-
-That's what `KC_LEAD` does. Here's an example:
-
-1. Pick a key on your keyboard you want to use as the Leader key. Assign it the keycode `KC_LEAD`. This key would be dedicated just for this -- it's a single action key, can't be used for anything else.
-2. Include the line `#define LEADER_TIMEOUT 300` somewhere in your keymap.c file, probably near the top. The 300 there is 300ms -- that's how long you have for the sequence of keys following the leader. You can tweak this value for comfort, of course.
-3. Within your `matrix_scan_user` function, do something like this:
-
-```
-LEADER_EXTERNS();
-
-void matrix_scan_user(void) {
- LEADER_DICTIONARY() {
- leading = false;
- leader_end();
-
- SEQ_ONE_KEY(KC_F) {
- register_code(KC_S);
- unregister_code(KC_S);
- }
- SEQ_TWO_KEYS(KC_A, KC_S) {
- register_code(KC_H);
- unregister_code(KC_H);
- }
- SEQ_THREE_KEYS(KC_A, KC_S, KC_D) {
- register_code(KC_LGUI);
- register_code(KC_S);
- unregister_code(KC_S);
- unregister_code(KC_LGUI);
- }
- }
-}
-```
-
-As you can see, you have three function. you can use - `SEQ_ONE_KEY` for single-key sequences (Leader followed by just one key), and `SEQ_TWO_KEYS` and `SEQ_THREE_KEYS` for longer sequences. Each of these accepts one or more keycodes as arguments. This is an important point: You can use keycodes from **any layer on your keyboard**. That layer would need to be active for the leader macro to fire, obviously.
-Each file listed below has more than one author and needs to have copyright resolved. The number of lines contributed by each author is shown as determined by:
-As raised in #1038 and other issues, the licensing status of QMK is not clear. In an effort to remove ambiguity and to clarify the licensing status of the quantum code we are identifying the providence of our source code files and clarifying what license applies to each one.
-
-# Signoff
-
-This section documents the people who need to sign off on applying the GPL to one or more of their contributions. If your name appears below and you consent to applying the GPL to your contributions, please put today's date in the last field of your row. Please stick to the following date format: 2017 Jan 28
-
-Username | Files | Sign Off Date |
----------|-------|---------------|
-@0xdec | quantum/rgblight.c | 2017 Jan 29 |
-@algernon | quantum/quantum.c<br>quantum/quantum.h<br>quantum/process_keycode/process_tap_dance.c<br>quantum/process_keycode/process_tap_dance.h<br>quantum/process_keycode/process_unicode.c<br>quantum/process_keycode/process_unicode.h | 2017 Jan 29 |
-@cdlm | quantum/template/template.c<br>quantum/template/template.h | 2017 Feb 03 |
-@DidierLoiseau | quantum/keymap_extras/keymap_canadian_multilingual.h<br>quantum/keymap_extras/keymap_bepo.h |2017 Jan 29 |
-@eltang | quantum/config_common.h<br>quantum/matrix.c<br>quantum/quantum.c<br>quantum/quantum.h<br>quantum/rgblight.c<br>quantum/rgblight.h<br>quantum/template/config.h | 2017 Feb 28 |
-@ezuk | quantum/matrix.c<br>quantum/quantum.c<br>quantum/quantum.h<br>quantum/quantum_keycodes.h<br>quantum/rgblight.c<br>quantum/rgblight.h<br>quantum/keymap_extras/keymap_colemak.h<br>quantum/keymap_extras/keymap_nordic.h | 2017 Jan 31 |
-@fredizzimo | quantum/config_common.h<br>quantum/keycode_config.h<br>quantum/keymap.h<br>quantum/keymap_common.c<br>quantum/keymap_common.c<br>quantum/matrix.c<br>quantum/quantum.h<br>quantum/rgblight.c<br>quantum/rgblight.h<br>quantum/api/api_sysex.c | 2017 Jan 29 |
-@h-youhei | quantum/keymap_extras/keymap_jp.h | 2017 Jan 28 |
-@heartsekai | quantum/keymap_extras/keymap_german_ch.h | 2017 Jan 29 |
-@IBnobody | quantum/keycode_config.h<br>quantum/matrix.c<br>quantum/quantum.c<br>quantum/audio/audio.c<br>quantum/audio/audio.h<br>quantum/audio/audio_pwm.c<br>quantum/audio/audio_pwm.c<br>quantum/audio/voices.c<br>quantum/audio/voices.h<br>quantum/template/config.h<br>quantum/template/template.c | 2017 Jan 30 |
-The full syntax of the `make` command is the following, but parts of the command can be left out if you run it from other directories than the `root` (as you might already have noticed by reading the simple instructions).
-* `<keyboard>` is the name of the keyboard, for example `planck`
- * Use `allkb` to compile all keyboards
-* `<subproject>` is the name of the subproject (revision or sub-model of the keyboard). For example, for Ergodox it can be `ez` or `infinity`, and for Planck `rev3` or `rev4`.
- * If the keyboard doesn't have any subprojects, it can be left out
- * To compile the default subproject, you can leave it out, or specify `defaultsp`
- * Use `allsp` to compile all subprojects
-* `<keymap>` is the name of the keymap, for example `algernon`
- * Use `allkm` to compile all keymaps
-* `<target>` will be explained in more detail below.
-
-**Note:** When you leave some parts of the command out, you should also remove the dash (`-`).
-
-As mentioned above, there are some shortcuts, when you are in a:
-
-* `keyboard` folder, the command will automatically fill the `<keyboard>` part. So you only need to type `<subproject>-<keymap>-<target>`
-* `subproject` folder, it will fill in both `<keyboard>` and `<subproject>`
-* `keymap` folder, then `<keyboard>` and `<keymap>` will be filled in. If you need to specify the `<subproject>` use the following syntax `<subproject>-<target>`
- * Note in order to support this shortcut, the keymap needs its own Makefile (see the example [here](https://github.com/qmk/qmk_firmware/blob/master/doc/keymap_makefile_example.mk))
-* `keymap` folder of a `subproject`, then everything except the `<target>` will be filled in
-
-The `<target>` means the following
-* If no target is given, then it's the same as `all` below
-* `all` compiles the keyboard and generates a `<keyboard>_<keymap>.hex` file in whichever folder you run `make` from. These files are ignored by git, so don't worry about deleting them when committing/creating pull requests.
-* `dfu`, `teensy` or `dfu-util`, compile and upload the firmware to the keyboard. If the compilation fails, then nothing will be uploaded. The programmer to use depends on the keyboard. For most keyboards it's `dfu`, but for Infinity keyboards you should use `dfu-util`, and `teensy` for standard Teensys. To find out which command you should use for your keyboard, check the keyboard specific readme. **Note** that some operating systems needs root access for these commands to work, so in that case you need to run for example `sudo make dfu`.
-* `clean`, cleans the build output folders to make sure that everything is built from scratch. Run this before normal compilation if you have some unexplainable problems.
-
-Some other targets are supported but, but not important enough to be documented here. Check the source code of the make files for more information.
-
-You can also add extra options at the end of the make command line, after the target
-
-* `make COLOR=false` - turns off color output
-* `make SILENT=true` - turns off output besides errors/warnings
-* `make VERBOSE=true` - outputs all of the gcc stuff (not interesting, unless you need to debug)
-* `make EXTRAFLAGS=-E` - Preprocess the code without doing any compiling (useful if you are trying to debug #define commands)
-
-The make command itself also has some additional options, type `make --help` for more information. The most useful is probably `-jx`, which specifies that you want to compile using more than one CPU, the `x` represents the number of CPUs that you want to use. Setting that can greatly reduce the compile times, especially if you are compiling many keyboards/keymaps. I usually set it to one less than the number of CPUs that I have, so that I have some left for doing other things while it's compiling. Note that not all operating systems and make versions supports that option.
-
-Here are some examples commands
-
-* `make allkb-allsp-allkm` builds everything (all keyboards, all subprojects, all keymaps). Running just `make` from the `root` will also run this.
-* `make` from within a `keyboard` directory, is the same as `make keyboard-allsp-allkm`, which compiles all subprojects and keymaps of the keyboard. **NOTE** that this behaviour has changed. Previously it compiled just the default keymap.
-* `make ergodox-infinity-algernon-clean` will clean the build output of the Ergodox Infinity keyboard. This example uses the full syntax and can be run from any folder with a `Makefile`
-* `make dfu COLOR=false` from within a keymap folder, builds and uploads the keymap, but without color output.
-
-## The `Makefile`
-
-There are 5 different `make` and `Makefile` locations:
-The root contains the code used to automatically figure out which keymap or keymaps to compile based on your current directory and commandline arguments. It's considered stable, and shouldn't be modified. The keyboard one will contain the MCU set-up and default settings for your keyboard, and shouldn't be modified unless you are the producer of that keyboard. The keymap Makefile can be modified by users, and is optional. It is included automatically if it exists. You can see an example [here](https://github.com/qmk/qmk_firmware/blob/master/doc/keymap_makefile_example.mk) - the last few lines are the most important. The settings you set here will override any defaults set in the keyboard Makefile. **The file is required if you want to run `make` in the keymap folder.**
-
-For keyboards and subprojects, the make files are split in two parts `Makefile` and `rules.mk`. All settings can be found in the `rules.mk` file, while the `Makefile` is just there for support and including the root `Makefile`. Keymaps contain just one `Makefile` for simplicity.
-
-### Makefile options
-
-Set these variables to `no` to disable them, and `yes` to enable them.
-
-`BOOTMAGIC_ENABLE`
-
-This allows you to hold a key and the salt key (space by default) and have access to a various EEPROM settings that persist over power loss. It's advised you keep this disabled, as the settings are often changed by accident, and produce confusing results that makes it difficult to debug. It's one of the more common problems encountered in help sessions.
-
-Consumes about 1000 bytes.
-
-`MOUSEKEY_ENABLE`
-
-This gives you control over cursor movements and clicks via keycodes/custom functions.
-
-`EXTRAKEY_ENABLE`
-
-This allows you to use the system and audio control key codes.
-
-`CONSOLE_ENABLE`
-
-This allows you to print messages that can be read using [`hid_listen`](https://www.pjrc.com/teensy/hid_listen.html).
-
-By default, all debug (*dprint*) print (*print*, *xprintf*), and user print (*uprint*) messages will be enabled. This will eat up a significant portion of the flash and may make the keyboard .hex file too big to program.
-
-To disable debug messages (*dprint*) and reduce the .hex file size, include `#define NO_DEBUG` in your `config.h` file.
-
-To disable print messages (*print*, *xprintf*) and user print messages (*uprint*) and reduce the .hex file size, include `#define NO_PRINT` in your `config.h` file.
-
-To disable print messages (*print*, *xprintf*) and **KEEP** user print messages (*uprint*), include `#define USER_PRINT` in your `config.h` file.
-
-To see the text, open `hid_listen` and enjoy looking at your printed messages.
-
-**NOTE:** Do not include *uprint* messages in anything other than your keymap code. It must not be used within the QMK system framework. Otherwise, you will bloat other people's .hex files.
-
-Consumes about 400 bytes.
-
-`COMMAND_ENABLE`
-
-This enables magic commands, typically fired with the default magic key combo `LSHIFT+RSHIFT+KEY`. Magic commands include turning on debugging messages (`MAGIC+D`) or temporarily toggling NKRO (`MAGIC+N`).
-
-`SLEEP_LED_ENABLE`
-
-Enables your LED to breath while your computer is sleeping. Timer1 is being used here. This feature is largely unused and untested, and needs updating/abstracting.
-
-`NKRO_ENABLE`
-
-This allows the keyboard to tell the host OS that up to 248 keys are held down at once (default without NKRO is 6). NKRO is off by default, even if `NKRO_ENABLE` is set. NKRO can be forced by adding `#define FORCE_NKRO` to your config.h or by binding `MAGIC_TOGGLE_NKRO` to a key and then hitting the key.
-
-`BACKLIGHT_ENABLE`
-
-This enables your backlight on Timer1 and ports B5, B6, or B7 (for now). You can specify your port by putting this in your `config.h`:
-
- #define BACKLIGHT_PIN B7
-
-`MIDI_ENABLE`
-
-This enables MIDI sending and receiving with your keyboard. To enter MIDI send mode, you can use the keycode `MI_ON`, and `MI_OFF` to turn it off. This is a largely untested feature, but more information can be found in the `quantum/quantum.c` file.
-
-`UNICODE_ENABLE`
-
-This allows you to send unicode symbols via `UC(<unicode>)` in your keymap. Only codes up to 0x7FFF are currently supported.
-
-`UNICODEMAP_ENABLE`
-
-This allows sending unicode symbols using `X(<unicode>)` in your keymap. Codes
-up to 0xFFFFFFFF are supported, including emojis. You will need to maintain
-a separate mapping table in your keymap file.
-
-Known limitations:
-- Under Mac OS, only codes up to 0xFFFF are supported.
-- Under Linux ibus, only codes up to 0xFFFFF are supported (but anything important is still under this limit for now).
-
-Characters out of range supported by the OS will be ignored.
-
-`BLUETOOTH_ENABLE`
-
-This allows you to interface with a Bluefruit EZ-key to send keycodes wirelessly. It uses the D2 and D3 pins.
-
-`AUDIO_ENABLE`
-
-This allows you output audio on the C6 pin (needs abstracting). See the [audio section](#audio-output-from-a-speaker) for more information.
-
-`FAUXCLICKY_ENABLE`
-
-Uses buzzer to emulate clicky switches. A cheap imitation of the Cherry blue switches. By default, uses the C6 pin, same as AUDIO_ENABLE.
-
-`VARIABLE_TRACE`
-
-Use this to debug changes to variable values, see the [tracing variables](#tracing-variables) section for more information.
-
-`API_SYSEX_ENABLE`
-
-This enables using the Quantum SYSEX API to send strings (somewhere?)
-
-This consumes about 5390 bytes.
-
-### Customizing Makefile options on a per-keymap basis
-
-If your keymap directory has a file called `Makefile` (note the filename), any Makefile options you set in that file will take precedence over other Makefile options for your particular keyboard.
-
-So let's say your keyboard's makefile has `BACKLIGHT_ENABLE = yes` (or maybe doesn't even list the `BACKLIGHT_ENABLE` option, which would cause it to be off). You want your particular keymap to not have the debug console, so you make a file called `Makefile` and specify `BACKLIGHT_ENABLE = no`.
-
-You can use the `doc/keymap_makefile_example.md` as a template/starting point.
-In rare circumstances, your keyboard/device can become unwritable, and `dfu-programmer` will give you an error like this:
-
- Erasing flash... Success
- Checking memory from 0x0 to 0x6FFF... Empty.
- Checking memory from 0x0 to 0x607F... Empty.
- 0% 100% Programming 0x6080 bytes...
- [ X ERROR
- Memory write error, use debug for more info.
-
-Currently the only way to solve this is to [reprogram the chip via ISP](https://www.reddit.com/r/olkb/comments/4rjzen/flashing_error_on_mac_os_x/d52rj8o/). This requires another device to be hooked up to a couple of exposed pins on the PCB. There is a guide on how to do this [here](https://learn.sparkfun.com/tutorials/installing-an-arduino-bootloader), and [this is where things are on the Planck PCB](http://imgur.com/lvbxbHt).
-
-An example command to flash the board once things are hooked up is:
-Research is still being done on why this happens, but here are some cases:
-
-* [`make -f Makefile.rn42 dfu` and not the dfu-programmer commands worked for @tybenz](https://github.com/tmk/tmk_keyboard/issues/316) - also see [the hhkb keyboard on tmk](https://github.com/tmk/tmk_keyboard/tree/master/keyboard/hhkb)
-* [Doing a force erase works here](https://geekhack.org/index.php?topic=12047.msg1520147#msg1520147)
-* [`dfu-programmer atmega32u4 erase --force` works here as well](https://forum.fhem.de/index.php?topic=29777.0) [DE]
-* [Unresolved, but some data dumps](https://github.com/dfu-programmer/dfu-programmer/issues/29)
-Your keyboard can make sounds! If you've got a Planck, Preonic, or basically any keyboard that allows access to the C6 port, you can hook up a simple speaker and make it beep. You can use those beeps to indicate layer transitions, modifiers, special keys, or just to play some funky 8bit tunes.
-
-The audio code lives in [quantum/audio/audio.h](https://github.com/qmk/qmk_firmware/blob/master/quantum/audio/audio.h) and in the other files in the audio directory. It's enabled by default on the Planck [stock keymap](https://github.com/qmk/qmk_firmware/blob/master/keyboards/planck/keymaps/default/keymap.c). Here are the important bits:
-
-```
-#include "audio.h"
-```
-
-Then, lower down the file:
-
-```
-float tone_startup[][2] = {
- ED_NOTE(_E7 ),
- E__NOTE(_CS7),
- E__NOTE(_E6 ),
- E__NOTE(_A6 ),
- M__NOTE(_CS7, 20)
-};
-```
-
-This is how you write a song. Each of these lines is a note, so we have a little ditty composed of five notes here.
-Wherein we bind predefined songs (from [quantum/audio/song_list.h](https://github.com/qmk/qmk_firmware/blob/master/quantum/audio/song_list.h)) into named variables. This is one optimization that helps save on memory: These songs only take up memory when you reference them in your keymap, because they're essentially all preprocessor directives.
-
-So now you have something called `tone_plover` for example. How do you make it play the Plover tune, then? If you look further down the keymap, you'll see this:
-
-```
-PLAY_NOTE_ARRAY(tone_plover, false, 0); // Signature is: Song name, repeat, rest style
-```
-
-This is inside one of the macros. So when that macro executes, your keyboard plays that particular chime.
-
-"Rest style" in the method signature above (the last parameter) specifies if there's a rest (a moment of silence) between the notes.
-
-## Music mode
-
-The music mode maps your columns to a chromatic scale, and your rows to octaves. This works best with ortholinear keyboards, but can be made to work with others. All keycodes less than `0xFF` get blocked, so you won't type while playing notes - if you have special keys/mods, those will still work. A work-around for this is to jump to a different layer with KC_NOs before (or after) enabling music mode.
-
-Recording is experimental due to some memory issues - if you experience some weird behavior, unplugging/replugging your keyboard will fix things.
-
-Keycodes available:
-
-* `MU_ON` - Turn music mode on
-* `MU_OFF` - Turn music mode off
-* `MU_TOG` - Toggle music mode
-
-In music mode, the following keycodes work differently, and don't pass through:
-
-* `LCTL` - start a recording
-* `LALT` - stop recording/stop playing
-* `LGUI` - play recording
-* `KC_UP` - speed-up playback
-* `KC_DOWN` - slow-down playback
-
-## MIDI functionalty
-
-This is still a WIP, but check out `quantum/keymap_midi.c` to see what's happening. Enable from the Makefile.
-
-## Bluetooth functionality
-
-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.
-
-## RGB Under Glow Mod
-
-![Planck with RGB Underglow](https://raw.githubusercontent.com/qmk/qmk_firmware/master/keyboards/planck/keymaps/yang/planck-with-rgb-underglow.jpg)
-
-Here is a quick demo on Youtube (with NPKC KC60) (https://www.youtube.com/watch?v=VKrpPAHlisY).
-
-For this mod, you need an unused pin wiring to DI of WS2812 strip. After wiring the VCC, GND, and DI, you can enable the underglow in your Makefile.
-
- RGBLIGHT_ENABLE = yes
-
-In order to use the underglow animation functions, you need to have `#define RGBLIGHT_ANIMATIONS` in your `config.h`.
-
-Please add the following options into your config.h, and set them up according your hardware configuration. These settings are for the `F4` pin by default:
-
- #define RGB_DI_PIN F4 // The pin your RGB strip is wired to
- #define RGBLIGHT_ANIMATIONS // Require for fancier stuff (not compatible with audio)
- #define RGBLED_NUM 14 // Number of LEDs
- #define RGBLIGHT_HUE_STEP 10
- #define RGBLIGHT_SAT_STEP 17
- #define RGBLIGHT_VAL_STEP 17
-
-You'll need to edit `RGB_DI_PIN` to the pin you have your `DI` on your RGB strip wired to.
-
-The firmware supports 5 different light effects, and the color (hue, saturation, brightness) can be customized in most effects. To control the underglow, you need to modify your keymap file to assign those functions to some keys/key combinations. For details, please check this keymap. `keyboards/planck/keymaps/yang/keymap.c`
-Please note the USB port can only supply a limited amount of power to the keyboard (500mA by standard, however, modern computer and most usb hubs can provide 700+mA.). According to the data of NeoPixel from Adafruit, 30 WS2812 LEDs require a 5V 1A power supply, LEDs used in this mod should not more than 20.
-
-## PS/2 Mouse Support
-
-Its possible to hook up a PS/2 mouse (for example touchpads or trackpoints) to your keyboard as a composite device.
-
-To hook up a Trackpoint, you need to obtain a Trackpoint module (i.e. harvest from a Thinkpad keyboard), identify the function of each pin of the module, and make the necessary circuitry between controller and Trackpoint module. For more information, please refer to [Trackpoint Hardware](https://deskthority.net/wiki/TrackPoint_Hardware) page on Deskthority Wiki.
-
-There are three available modes for hooking up PS/2 devices: USART (best), interrupts (better) or busywait (not recommended).
-
-### Busywait version
-
-Note: This is not recommended, you may encounter jerky movement or unsent inputs. Please use interrupt or USART version if possible.
-
-In rules.mk:
-
-```
-PS2_MOUSE_ENABLE = yes
-PS2_USE_BUSYWAIT = yes
-```
-
-In your keyboard config.h:
-
-```
-#ifdef PS2_USE_BUSYWAIT
-# define PS2_CLOCK_PORT PORTD
-# define PS2_CLOCK_PIN PIND
-# define PS2_CLOCK_DDR DDRD
-# define PS2_CLOCK_BIT 1
-# define PS2_DATA_PORT PORTD
-# define PS2_DATA_PIN PIND
-# define PS2_DATA_DDR DDRD
-# define PS2_DATA_BIT 2
-#endif
-```
-
-### Interrupt version
-
-The following example uses D2 for clock and D5 for data. You can use any INT or PCINT pin for clock, and any pin for data.
-
-In rules.mk:
-
-```
-PS2_MOUSE_ENABLE = yes
-PS2_USE_INT = yes
-```
-
-In your keyboard config.h:
-
-```
-#ifdef PS2_USE_INT
-#define PS2_CLOCK_PORT PORTD
-#define PS2_CLOCK_PIN PIND
-#define PS2_CLOCK_DDR DDRD
-#define PS2_CLOCK_BIT 2
-#define PS2_DATA_PORT PORTD
-#define PS2_DATA_PIN PIND
-#define PS2_DATA_DDR DDRD
-#define PS2_DATA_BIT 5
-
-#define PS2_INT_INIT() do { \
- EICRA |= ((1<<ISC21) | \
- (0<<ISC20)); \
-} while (0)
-#define PS2_INT_ON() do { \
- EIMSK |= (1<<INT2); \
-} while (0)
-#define PS2_INT_OFF() do { \
- EIMSK &= ~(1<<INT2); \
-} while (0)
-#define PS2_INT_VECT INT2_vect
-#endif
-```
-
-### USART version
-
-To use USART on the ATMega32u4, you have to use PD5 for clock and PD2 for data. If one of those are unavailable, you need to use interrupt version.
-**Q:** The default speed for controlling the mouse with the keyboard is slow. I've tried increasing the mouse's sensitivity at work using xset m and it worked, although sometimes it changes by itself for some reason. At home, on Arch Linux, this does not change ti. I've looked through the forums and resolved to use libinput using xinput but using that I only manage to change the speed of the mouse using the actual mouse. The speed of the mouse using the keyboard controls remained unchanged.
-Is there perhaps something I can input in the keymap.c to change the sensitivity? Or some other surefire way of increasing the speed?
-Thanks!
-
-**A:** In your keymap's config.h:
-
-```
-#define MOUSEKEY_INTERVAL 20
-#define MOUSEKEY_DELAY 0
-#define MOUSEKEY_TIME_TO_MAX 60
-#define MOUSEKEY_MAX_SPEED 7
-#define MOUSEKEY_WHEEL_DELAY 0
-```
-
-Tweak away. A lower interval or higher max speed will effectively make the mouse move faster. Time-to-max controls acceleration. (See [this Reddit thread for the original discussion](https://www.reddit.com/r/ErgoDoxEZ/comments/61fwr2/a_reliable_way_to_increase_the_speed_of_the_mouse/)).
@@ -119,7+119,7 @@ A number of other keycodes have been added that you may find useful:
The extended keymap extends the number of function layers from 32 to the near-infinite value of 256. Rather than using `FN<num>` notation (still available, but limited to `FN0`-`FN31`), you can use the `FUNC(<num>)` notation. `F(<num>)` is a shortcut for this.
-The function actions are unchanged, and you can see the full list of them [here](https://github.com/jackhumbert/tmk_keyboard/blob/master/common/action_code.h). They are explained in detail [here](https://github.com/jackhumbert/tmk_keyboard/blob/master/doc/keymap.md#2-action).
+The function actions are unchanged, and you can see the full list of them [here](https://github.com/qmk/qmk_firmware/blob/master/tmk_core/common/action_code.h). They are explained in detail [here](keymap.md#2-action).
-Setting up your ARM based PCB is a little more involved than an Atmel MCU, but is easy enough. Start by using `util/new_project.sh <keyboard>` to create a new project:
-The `USB Device descriptor parameter` block contains parameters are used to uniquely identify your keyboard, but they don't really matter to the machine.
-
-Your `MATRIX_ROWS` and `MATRIX_COLS` are the numbers of rows and cols in your keyboard matrix - this may be different than the number of actual rows and columns on your keyboard. There are some tricks you can pull to increase the number of keys in a given matrix, but most keyboards are pretty straight-forward.
-
-The `MATRIX_ROW_PINS` and `MATRIX_COL_PINS` are the pins your MCU uses on each row/column. Your schematic (if you have one) will have this information on it, and the values will vary depending on your setup. This is one of the most important things to double-check in getting your keyboard setup correctly.
-
-For the `DIODE_DIRECTION`, most hand-wiring guides will instruct you to wire the diodes in the `COL2ROW` position, but it's possible that they are in the other - people coming from EasyAVR often use `ROW2COL`. Nothing will function if this is incorrect.
-
-`BACKLIGHT_PIN` is the pin that your PWM-controlled backlight (if one exists) is hooked-up to. Currently only B5, B6, and B7 are supported.
-
-`BACKLIGHT_BREATHING` is a fancier backlight feature that adds breathing/pulsing/fading effects to the backlight. It uses the same timer as the normal backlight. These breathing effects must be called by code in your keymap.
-
-`BACKLIGHT_LEVELS` is how many levels exist for your backlight - max is 15, and they are computed automatically from this number.
-
-## `/keyboards/<keyboard>/Makefile`
-
-The values at the top likely won't need to be changed, since most boards use the `atmega32u4` chip. The `BOOTLOADER_SIZE` will need to be adjusted based on your MCU type. It's defaulted to the Teensy, since that's the most common controller. Below is quoted from the `Makefile`.
-
-```
-# Boot Section Size in *bytes*
-# Teensy halfKay 512
-# Teensy++ halfKay 1024
-# Atmel DFU loader 4096
-# LUFA bootloader 4096
-# USBaspLoader 2048
-OPT_DEFS += -DBOOTLOADER_SIZE=512
-```
-
-At the bottom of the file, you'll find lots of features to turn on and off - all of these options should be set with `?=` to allow for the keymap overrides. `?=` only assigns if the variable was previously undefined. For the full documenation of these features, see the [Makefile options](#makefile-options).
-
-## `/keyboards/<keyboard>/readme.md`
-
-This is where you'll describe your keyboard - please write as much as you can about it! Talking about default functionality/features is useful here. Feel free to link to external pages/sites if necessary. Images can be included here as well. This file will be rendered into a webpage at qmk.fm/keyboards/<keyboard>/.
-
-## `/keyboards/<keyboard>/<keyboard>.c`
-
-This is where all of the custom logic for your keyboard goes - you may not need to put anything in this file, since a lot of things are configured automatically. All of the `*_kb()` functions are defined here. If you modify them, remember to keep the calls to `*_user()`, or things in the keymaps might not work. You can read more about the functions [here](#custom-quantum-functions-for-keyboards-and-keymaps)
-
-## `/keyboards/<keyboard>/<keyboard>.h`
-
-Here is where you can (optionally) define your `KEYMAP` function to remap your matrix into a more readable format. With ortholinear boards, this isn't always necessary, but it can help to accomodate the dead spots on your matrix, where there are keys that take up more than one space (2u, staggering, 6.25u, etc). The example shows the difference between the physical keys, and the matrix design:
-
-```
-#define KEYMAP( \
- k00, k01, k02, \
- k10, k11 \
-) \
-{ \
- { k00, k01, k02 }, \
- { k10, KC_NO, k11 }, \
-}
-```
-
-Each of the `kxx` variables needs to be unique, and usually follows the format `k<row><col>`. You can place `KC_NO` where your dead keys are in your matrix.
-If your keyboard is running an Atmega chip (atmega32u4 and others), it's pretty easy to get things setup for compiling your own firmware to flash onto your board. There is a `/util/new_project.sh <keyboard>` script to help get you started - you can simply pass your keyboard's name into the script, and all of the necessary files will be created. The components of each are described below.
-
-## `/keyboards/<keyboard>/config.h`
-
-The `USB Device descriptor parameter` block contains parameters are used to uniquely identify your keyboard, but they don't really matter to the machine.
-
-Your `MATRIX_ROWS` and `MATRIX_COLS` are the numbers of rows and cols in your keyboard matrix - this may be different than the number of actual rows and columns on your keyboard. There are some tricks you can pull to increase the number of keys in a given matrix, but most keyboards are pretty straight-forward.
-
-The `MATRIX_ROW_PINS` and `MATRIX_COL_PINS` are the pins your MCU uses on each row/column. Your schematic (if you have one) will have this information on it, and the values will vary depending on your setup. This is one of the most important things to double-check in getting your keyboard setup correctly.
-
-For the `DIODE_DIRECTION`, most hand-wiring guides will instruct you to wire the diodes in the `COL2ROW` position, but it's possible that they are in the other - people coming from EasyAVR often use `ROW2COL`. Nothing will function if this is incorrect.
-
-`BACKLIGHT_PIN` is the pin that your PWM-controlled backlight (if one exists) is hooked-up to. Currently only B5, B6, and B7 are supported.
-
-`BACKLIGHT_BREATHING` is a fancier backlight feature that adds breathing/pulsing/fading effects to the backlight. It uses the same timer as the normal backlight. These breathing effects must be called by code in your keymap.
-
-`BACKLIGHT_LEVELS` is how many levels exist for your backlight - max is 15, and they are computed automatically from this number.
-
-## `/keyboards/<keyboard>/Makefile`
-
-The values at the top likely won't need to be changed, since most boards use the `atmega32u4` chip. The `BOOTLOADER_SIZE` will need to be adjusted based on your MCU type. It's defaulted to the Teensy, since that's the most common controller. Below is quoted from the `Makefile`.
-
-```
-# Boot Section Size in *bytes*
-# Teensy halfKay 512
-# Teensy++ halfKay 1024
-# Atmel DFU loader 4096
-# LUFA bootloader 4096
-# USBaspLoader 2048
-OPT_DEFS += -DBOOTLOADER_SIZE=512
-```
-
-At the bottom of the file, you'll find lots of features to turn on and off - all of these options should be set with `?=` to allow for the keymap overrides. `?=` only assigns if the variable was previously undefined. For the full documenation of these features, see the [Makefile options](#makefile-options).
-
-## `/keyboards/<keyboard>/readme.md`
-
-This is where you'll describe your keyboard - please write as much as you can about it! Talking about default functionality/features is useful here. Feel free to link to external pages/sites if necessary. Images can be included here as well. This file will be rendered into a webpage at qmk.fm/keyboards/<keyboard>/.
-
-## `/keyboards/<keyboard>/<keyboard>.c`
-
-This is where all of the custom logic for your keyboard goes - you may not need to put anything in this file, since a lot of things are configured automatically. All of the `*_kb()` functions are defined here. If you modify them, remember to keep the calls to `*_user()`, or things in the keymaps might not work. You can read more about the functions [here](#custom-quantum-functions-for-keyboards-and-keymaps)
-
-## `/keyboards/<keyboard>/<keyboard>.h`
-
-Here is where you can (optionally) define your `KEYMAP` function to remap your matrix into a more readable format. With ortholinear boards, this isn't always necessary, but it can help to accomodate the dead spots on your matrix, where there are keys that take up more than one space (2u, staggering, 6.25u, etc). The example shows the difference between the physical keys, and the matrix design:
-
-```
-#define KEYMAP( \
- k00, k01, k02, \
- k10, k11 \
-) \
-{ \
- { k00, k01, k02 }, \
- { k10, KC_NO, k11 }, \
-}
-```
-
-Each of the `kxx` variables needs to be unique, and usually follows the format `k<row><col>`. You can place `KC_NO` where your dead keys are in your matrix.
-This page attempts to explain the basic information you need to know to work with the QMK project. It assumes that you are familiar with navigating a UNIX shell, but does not assume you are familiar with C or with compiling using make.
-
-# Basic QMK structure
-
-QMK is a fork of @tmk's [tmk_keyboard](https://github.com/tmk/tmk_keyboard) project. The original TMK code, with modifications, can be found in the `tmk` folder. The QMK additions to the project may be found in the `quantum` folder. Keyboard projects may be found in the `handwired` and `keyboard` folders.
-
-## Keyboard project structure
-
-Within the `handwired` and `keyboard` folders is a directory for each keyboard project, for example `qmk_firmware/keyboards/clueboard`. Within you'll find the following structure:
-
-* `keymaps/`: Different keymaps that can be built
-* `rules.mk`: The file that sets the default "make" options. Do not edit this file directly, instead use a keymap specific `Makefile`.
-* `config.h`: The file that sets the default compile time options. Do not edit this file directly, instead use a keymap specific `config.h`.
-
-### Keymap structure
-
-In every keymap folder, the following files may be found. Only `keymap.c` is required, if the rest of the files are not found the default options will be chosen.
-
-* `config.h`: the options to configure your keymap
-* `keymap.c`: all of your keymap code, required
-* `Makefile`: the features of QMK that are enabled, required to run `make` in your keymap folder
-* `readme.md`: a description of your keymap, how others might use it, and explanations of features
-* Other files: Some people choose to include an image depicting the layout, and other files that help people to use or understand a particular keymap.
-
-# The `make` command
-
-The `make` command is how you compile the firmware into a .hex file, which can be loaded by a dfu programmer (like dfu-progammer via `make dfu`) or the [Teensy loader](https://www.pjrc.com/teensy/loader.html) (only used with Teensys). It it recommended that you always run make from within the `root` folder.
-
-**NOTE:** To abort a make command press `Ctrl-c`
-
-For more details on the QMK build process see [Make Instructions](/Make-Instructions.md).
-
-### Simple instructions for building and uploading a keyboard
-
-**Most keyboards have more specific instructions in the keyboard specific readme.md file, so please check that first**
-
-1. Enter the `root` folder
-2. Run `make <keyboard>-<subproject>-<keymap>-<programmer>`
-
-In the above commands, replace:
-
-* `<keyboard>` with the name of your keyboard
-* `<keymap>` with the name of your keymap
-* `<subproject>` with the name of the subproject (revision or sub-model of your keyboard). For example, for Ergodox it can be `ez` or `infinity`, and for Planck `rev3` or `rev4`.
- * If the keyboard doesn't have a subproject, or if you are happy with the default (defined in `rules.mk` file of the `keyboard` folder), you can leave it out. But remember to also remove the dash (`-`) from the command.
-* `<programmer>` The programmer to use. Most keyboards use `dfu`, but some use `teensy`. Infinity keyboards use `dfu-util`. Check the readme file in the keyboard folder to find out which programmer to use.
- * If you don't add `-<programmer` to the command line, the firmware will be still be compiled into a hex file, but the upload will be skipped.
-
-**NOTE:** Some operating systems will refuse to program unless you run the make command as root for example `sudo make clueboard-default-dfu`
-
-## Make Examples
-
-* Build all Clueboard keymaps: `make clueboard`
-* Build the default Planck keymap: `make planck-rev4-default`
-* Build and flash your ergodox-ez: `make ergodox-ez-default-teensy`
-The keyboard `config.h` is included only if the keymap one doesn't exist. The format to use for your custom one [is here](https://github.com/qmk/qmk_firmware/blob/master/doc/keymap_config_h_example.h). If you want to override a setting from the parent `config.h` file, you need to do this:
-
-```c
-#undef MY_SETTING
-#define MY_SETTING 4
-```
-
-For a value of `4` for this imaginary setting. So we `undef` it first, then `define` it.
-
-You can then override any settings, rather than having to copy and paste the whole thing.
-Steve Losh [described](http://stevelosh.com/blog/2012/10/a-modern-space-cadet/) the Space Cadet Shift quite well. Essentially, you hit the left Shift on its own, and you get an opening parenthesis; hit the right Shift on its own, and you get the closing one. When hit with other keys, the Shift key keeps working as it always does. Yes, it's as cool as it sounds.
-
-To use it, use `KC_LSPO` (Left Shift, Parens Open) for your left Shift on your keymap, and `KC_RSPC` (Right Shift, Parens Close) for your right Shift.
-
-It's defaulted to work on US keyboards, but if your layout uses different keys for parenthesis, you can define those in your `config.h` like this:
-
- #define LSPO_KEY KC_9
- #define RSPC_KEY KC_0
-
-You can also choose between different rollover behaviors of the shift keys by defining:
-
- #define DISABLE_SPACE_CADET_ROLLOVER
-
-in your `config.h`. Disabling rollover allows you to use the opposite shift key to cancel the space cadet state in the event of an erroneous press instead of emitting a pair of parentheses when the keys are released.
-
-The only other thing you're going to want to do is create a `Makefile` in your keymap directory and set the following:
-
-```
-COMMAND_ENABLE = no # Commands for debug and configuration
-```
-
-This is just to keep the keyboard from going into command mode when you hold both Shift keys at the same time.
-**S60-X**: [DIY 60% keyboard](https://www.massdrop.com/buy/sentraq-60-diy-keyboard-kit?mode=guest_open) designed by [VinnyCordeiro](https://github.com/VinnyCordeiro) for Sentraq:
-- https://github.com/VinnyCordeiro/tmk_keyboard
-
-**Octagon V1**: Korean custom keyboard designed by Duck.
Boot Magic are executed during boot up time. Press Magic key below then plug in keyboard cable.
Note that you must use keys of **Layer 0** as Magic keys. These settings are stored in EEPROM so that retain your configure over power cycles.
-To avoid configuring accidentally additive salt key `KC_SPACE` also needs to be pressed along with the following configuration keys. The salt key is configurable in `config.h`. See [tmk_core/common/bootmagic.h](tmk_core/common/bootmagic.h).
+To avoid configuring accidentally additive salt key `KC_SPACE` also needs to be pressed along with the following configuration keys. The salt key is configurable in `config.h`. See [tmk_core/common/bootmagic.h](/tmk_core/common/bootmagic.h).
#### General
- Skip reading EEPROM to start with default configuration(`ESC`)
-# Tap Dance: A single key can do 3, 5, or 100 different things
-
-Hit the semicolon key once, send a semicolon. Hit it twice, rapidly -- send a colon. Hit it three times, and your keyboard's LEDs do a wild dance. That's just one example of what Tap Dance can do. It's one of the nicest community-contributed features in the firmware, conceived and created by [algernon](https://github.com/algernon) in [#451](https://github.com/qmk/qmk_firmware/pull/451). Here's how algernon describes the feature:
-
-With this feature one can specify keys that behave differently, based on the amount of times they have been tapped, and when interrupted, they get handled before the interrupter.
-
-To make it clear how this is different from `ACTION_FUNCTION_TAP`, lets explore a certain setup! We want one key to send `Space` on single tap, but `Enter` on double-tap.
-
-With `ACTION_FUNCTION_TAP`, it is quite a rain-dance to set this up, and has the problem that when the sequence is interrupted, the interrupting key will be send first. Thus, `SPC a` will result in `a SPC` being sent, if they are typed within `TAPPING_TERM`. With the tap dance feature, that'll come out as `SPC a`, correctly.
-
-The implementation hooks into two parts of the system, to achieve this: into `process_record_quantum()`, and the matrix scan. We need the latter to be able to time out a tap sequence even when a key is not being pressed, so `SPC` alone will time out and register after `TAPPING_TERM` time.
-
-But lets start with how to use it, first!
-
-First, you will need `TAP_DANCE_ENABLE=yes` in your `Makefile`, because the feature is disabled by default. This adds a little less than 1k to the firmware size. Next, you will want to define some tap-dance keys, which is easiest to do with the `TD()` macro, that - similar to `F()`, takes a number, which will later be used as an index into the `tap_dance_actions` array.
-
-This array specifies what actions shall be taken when a tap-dance key is in action. Currently, there are three possible options:
-
-* `ACTION_TAP_DANCE_DOUBLE(kc1, kc2)`: Sends the `kc1` keycode when tapped once, `kc2` otherwise. When the key is held, the appropriate keycode is registered: `kc1` when pressed and held, `kc2` when tapped once, then pressed and held.
-* `ACTION_TAP_DANCE_FN(fn)`: Calls the specified function - defined in the user keymap - with the final tap count of the tap dance action.
-* `ACTION_TAP_DANCE_FN_ADVANCED(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn)`: Calls the first specified function - defined in the user keymap - on every tap, the second function on when the dance action finishes (like the previous option), and the last function when the tap dance action resets.
-
-The first option is enough for a lot of cases, that just want dual roles. For example, `ACTION_TAP_DANCE(KC_SPC, KC_ENT)` will result in `Space` being sent on single-tap, `Enter` otherwise.
-
-And that's the bulk of it!
-
-And now, on to the explanation of how it works!
-
-The main entry point is `process_tap_dance()`, called from `process_record_quantum()`, which is run for every keypress, and our handler gets to run early. This function checks whether the key pressed is a tap-dance key. If it is not, and a tap-dance was in action, we handle that first, and enqueue the newly pressed key. If it is a tap-dance key, then we check if it is the same as the already active one (if there's one active, that is). If it is not, we fire off the old one first, then register the new one. If it was the same, we increment the counter and the timer.
-
-This means that you have `TAPPING_TERM` time to tap the key again, you do not have to input all the taps within that timeframe. This allows for longer tap counts, with minimal impact on responsiveness.
-
-Our next stop is `matrix_scan_tap_dance()`. This handles the timeout of tap-dance keys.
-
-For the sake of flexibility, tap-dance actions can be either a pair of keycodes, or a user function. The latter allows one to handle higher tap counts, or do extra things, like blink the LEDs, fiddle with the backlighting, and so on. This is accomplished by using an union, and some clever macros.
-
-### Examples
-
-Here's a simple example for a single definition:
-
-1. In your `makefile`, add `TAP_DANCE_ENABLE = yes`
-2. In your `config.h` (which you can copy from `qmk_firmware/keyboards/planck/config.h` to your keymap directory), add `#define TAPPING_TERM 200`
-3. In your `keymap.c` file, define the variables and definitions, then add to your keymap:
-There are three Unicode keymap definition method available in QMK:
-
-### UNICODE_ENABLE
-
-Supports Unicode input up to 0xFFFF. The keycode function is `UC(n)` in
-keymap file, where *n* is a 4 digit hexadecimal.
-
-### UNICODEMAP_ENABLE
-
-Supports Unicode up to 0xFFFFFFFF. You need to maintain a separate mapping
-table `const uint32_t PROGMEM unicode_map[] = {...}` in your keymap file.
-The keycode function is `X(n)` where *n* is the array index of the mapping
-table.
-
-### UCIS_ENABLE
-
-TBD
-
-Unicode input in QMK works by inputing a sequence of characters to the OS,
-sort of like macro. Unfortunately, each OS has different ideas on how Unicode is inputted.
-
-This is the current list of Unicode input method in QMK:
-
-* UC_OSX: MacOS Unicode Hex Input support. Works only up to 0xFFFF. Disabled by default. To enable: go to System Preferences -> Keyboard -> Input Sources, and enable Unicode Hex.
-* UC_LNX: Unicode input method under Linux. Works up to 0xFFFFF. Should work almost anywhere on ibus enabled distros. Without ibus, this works under GTK apps, but rarely anywhere else.
-* UC_WIN: (not recommended) Windows built-in Unicode input. To enable: create registry key under `HKEY_CURRENT_USER\Control Panel\Input Method\EnableHexNumpad` of type `REG_SZ` called `EnableHexNumpad`, set its value to 1, and reboot. This method is not recommended because of reliability and compatibility issue, use WinCompose method below instead.
-* UC_WINC: Windows Unicode input using WinCompose. Requires [WinCompose](https://github.com/samhocevar/wincompose). Works reliably under many (all?) variations of Windows.
-
-## Additional language support
-
-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.
-
-## International Characters on Windows
-
-[AutoHotkey](https://autohotkey.com) allows Windows users to create custom hotkeys among others.
-
-The method does not require Unicode support in the keyboard itself but depends instead of AutoHotkey running in the background.
-
-First you need to select a modifier combination that is not in use by any of your programs.
-CtrlAltWin is not used very widely and should therefore be perfect for this.
-There is a macro defined for a mod-tab combo `LCAG_T`.
-Add this mod-tab combo to a key on your keyboard, e.g.: `LCAG_T(KC_TAB)`.
-This makes the key behave like a tab key if pressed and released immediately but changes it to the modifier if used with another key.
-
-In the default script of AutoHotkey you can define custom hotkeys.
-
- <^<!<#a::Send, ä
- <^<!<#<+a::Send, Ä
-
-The hotkeys above are for the combination CtrlAltGui and CtrlAltGuiShift plus the letter a.
-AutoHotkey inserts the Text right of `Send, ` when this combination is pressed.
-If you are new to unit testing, then you can find many good resources on internet. However most of it is scattered around in small pieces here and there, and there's also many different opinions, so I won't give any recommendations.
-
-Instead I recommend these two books, explaining two different styles of Unit Testing in detail.
-
-* "Test Driven Development: By Example: Kent Beck"
-* "Growing Object-Oriented Software, Guided By Tests: Steve Freeman, Nat Pryce"
-
-If you prefer videos there are Uncle Bob's [Clean Coders Videos](https://cleancoders.com/), which unfortunately cost quite a bit, especially if you want to watch many of them. But James Shore has a free [Let's Play](http://www.jamesshore.com/Blog/Lets-Play) video series.
-
-## Google Test and Google Mock
-It's possible to Unit Test your code using [Google Test](https://github.com/google/googletest). The Google Test framework also includes another component for writing testing mocks and stubs, called "Google Mock". For information how to write the actual tests, please refer to the documentation on that site.
-
-## Use of C++
-
-Note that Google Test and therefore any test has to be written in C++, even if the rest of the QMK codebases is written in C. This should hopefully not be a problem even if you don't know any C++, since there's quite clear documentation and examples of the required C++ features, and you can write the rest of the test code almost as you would write normal C. Note that some compiler errors which you might get can look quite scary, but just read carefully what it says, and you should be ok.
-
-One thing to remember, is that you have to append `extern "C"` around all of your C file includes.
-
-## Adding tests for new or existing features
-
-If you want to unit test some feature, then take a look at the existing serial_link tests, in the `quantum/serial_link/tests folder`, and follow the steps below to create a similar structure.
-
-1. If it doesn't already exist, add a test subfolder to the folder containing the feature.
-2. Create a `testlist.mk` and a `rules.mk` file in that folder.
-3. Include those files from the root folder `testlist.mk`and `build_test.mk` respectively.
-4. Add a new name for your testgroup to the `testlist.mk` file. Each group defined there will be a separate executable. And that's how you can support mocking out different parts. Note that it's worth adding some common prefix, just like it's done for the serial_link tests. The reason for that is that the make command allows substring filtering, so this way you can easily run a subset of the tests.
-5. Define the source files and required options in the `rules.mk` file.
- * `_SRC` for source files
- * `_DEFS` for additional defines
- * `_INC` for additional include folders
-6. Write the tests in a new cpp file inside the test folder you created. That file has to be one of the files included from the `rules.mk` file.
-
-Note how there's several different tests, each mocking out a separate part. Also note that each of them only compiles the very minimum that's needed for the tests. It's recommend that you try to do the same. For a relevant video check out [Matt Hargett "Advanced Unit Testing in C & C++](https://www.youtube.com/watch?v=Wmy6g-aVgZI)
-
-## Running the tests
-
-To run all the tests in the codebase, type `make test`. You can also run test matching a substring by typing `make test-matchingsubstring` Note that the tests are always compiled with the native compiler of your platform, so they are also run like any other program on your computer.
-
-## Debugging the tests
-
-If there are problems with the tests, you can find the executable in the `./build/test` folder. You should be able to run those with GDB or a similar debugger.
-
-## Full Integration tests
-
-It's not yet possible to do a full integration test, where you would compile the whole firmware and define a keymap that you are going to test. However there are plans for doing that, because writing tests that way would probably be easier, at least for people that are not used to unit testing.
-
-In that model you would emulate the input, and expect a certain output from the emulated keyboard.
-
-# Tracing variables
-
-Sometimes you might wonder why a variable gets changed and where, and this can be quite tricky to track down without having a debugger. It's of course possible to manually add print statements to track it, but you can also enable the variable trace feature. This works for both for variables that are changed by the code, and when the variable is changed by some memory corruption.
-
-To take the feature into use add `VARIABLE_TRACE=x` to the end of you make command. `x` represents the number of variables you want to trace, which is usually 1.
-
-Then at a suitable place in the code, call `ADD_TRACED_VARIABLE`, to begin the tracing. For example to trace all the layer changes, you can do this
-This will add a traced variable named "layer" (the name is just for your information), which tracks the memory location of `layer_state`. It tracks 4 bytes (the size of `layer_state`), so any modification to the variable will be reported. By default you can not specify a size bigger than 4, but you can change it by adding `MAX_VARIABLE_TRACE_SIZE=x` to the end of the make command line.
-
-In order to actually detect changes to the variables you should call `VERIFY_TRACED_VARIABLES` around the code that you think that modifies the variable. If a variable is modified it will tell you between which two `VERIFY_TRACED_VARIABLES` calls the modification happened. You can then add more calls to track it down further. I don't recommend spamming the codebase with calls. It's better to start with a few, and then keep adding them in a binary search fashion. You can also delete the ones you don't need, as each call need to store the file name and line number in the ROM, so you can run out of memory if you add too many calls.
-
-Also remember to delete all the tracing code once you have found the bug, as you wouldn't want to create a pull request with tracing code.
+If you have an idea for a custom feature or extra hardware connection, we'd love to accept it into QMK! These are generally done via [pull request](https://github.com/qmk/qmk_firmware/pulls) after forking, and here are some things to keep in mind when creating one:
+
+* **Disable by default** - memory is a pretty limited on most chips QMK supports, and it's important that current keymaps aren't broken, so please allow your feature to be turned **on**, rather than being turned off. If you think it should be on by default, or reduces the size of the code, [open an issue](https://github.com/qmk/qmk_firmware/issues) for everyone to discuss it!
+* **Compile locally before submitting** - hopefully this one is obvious, but things need to compile! Our Travis system will catch any issues, but it's generally faster for you to compile a few keyboards locally instead of waiting for the results to come back.
+* **Consider subprojects and different chip-bases** - there are several keyboards that have subprojects that have allow for slightly different configurations, and even different chip-bases. Try to make a feature supported in ARM and AVR, or automatically disabled in one that doesn't work.
+* **Explain your feature** - submitting a markdown write-up of what your feature does with your PR may be needed, and it will allow a collaborator to easily copy it into the wiki for documentation (after proofing and editing).
+* **Don't refactor code** - to maintain a clear vision of how things are laid out in QMK, we try to plan out refactors in-depth, and have a collaborator make the changes. If you have an idea for refactoring, or suggestions, [open an issue](https://github.com/qmk/qmk_firmware/issues).
+A QMK collaborator is a keyboard maker/designer that is interested in helping QMK grow and fully support their keyboard(s), and encouraging their users/customers to submit features, ideas, and keymaps. We're always looking to add more keyboards and collaborators, but we ask that they fulfill these requirements:
+
+* **Have a PCB available for sale** - unfortunately there's just too much variation and complications with handwired keyboards.
+* **Maintain the your keyboard's directory** - this may just require an initial setup to get your keyboard working, but it could also include accommodating changes made to QMK's core.
+* **Approve and merge your keyboard's keymap pull requests** - we like to encourage users to contribute their keymaps for others to see and work from when creating their own.
+
+If you feel you meet these requirements, shoot us an email at hello@qmk.fm with an introduction and some links to your keyboard!
+If you have Windows 10 with Creators Update or later, you can build and flash the firmware directly. Before the Creators Update, only building was possible. If you don't have it yet or if are unsure, follow [these instructions](https://support.microsoft.com/en-us/instantanswers/d4efb316-79f0-1aa1-9ef3-dcada78f3fa0/get-the-windows-10-creators-update).
+
+#### Windows Subsystem for Linux
+In addition to the Creators Update, you need Windows 10 Subystem for Linux, so install it following [these instructions](http://www.howtogeek.com/249966/how-to-install-and-use-the-linux-bash-shell-on-windows-10/). If you already have the Windows 10 Subsystem for Linux from the Anniversary update it's recommended that you [upgrade](https://betanews.com/2017/04/14/upgrade-windows-subsystem-for-linux/) it to 16.04LTS, because some keyboards don't compile with the toolchains included in 14.04LTS. Note that you need to know what your are doing if you chose the `sudo do-release-upgrade` method.
+
+#### Git
+If you already have cloned the repository on your Windows file system you can ignore this section.
+
+You will need to clone the repository to your Windows file system using the normal Git for Windows and **not** the WSL Git. So if you haven't installed Git before, [download](https://git-scm.com/download/win) and install it. Then [set it up](https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup), it's important that you setup the e-mail and user name, especially if you are planning to contribute.
+
+Once Git is installed, open the Git bash command and change the directory to where you want to clone QMK, note that you have to use forward slashes, and that your c drive is accessed like this `/c/path/to/where/you/want/to/go`. Then run `git clone --recurse-submodules https://github.com/qmk/qmk_firmware`, this will create a new folder `qmk_firmware` as a subfolder of the current one.
+
+#### Toolchain setup
+The Toolchain setup is done through the Windows Subsystem for Linux, and the process is fully automated. If you want to do everything manually, there are no other instructions than the scripts themselves, but you can always open issues and ask for more information.
+
+1. Open "Bash On Ubuntu On Windows" from the start menu.
+2. Go to the directory where you cloned `qmk_firmware`. Note that the paths start with `/mnt/` in the WSL, so you have to write for example `cd /mnt/c/path/to/qmk_firmware`.
+3. Run `util/wsl_install.sh` and follow the on-screen instructions.
+4. Close the Bash command window, and re-open it.
+5. You are ready to compile and flash the firmware!
+
+#### Some important things to keep in mind
+* You can run `util/wsl_install.sh` again to get all the newest updates.
+* Your QMK repository need to be on a Windows file system path, since WSL can't run executables outside it.
+* The WSL Git is **not** compatible with the Windows Git, so use the Windows Git Bash or a windows Git GUI for all Git operations
+* You can edit files either inside WSL or normally using Windows, but note that if you edit makefiles or shell scripts, make sure you are using an editor that saves the files with Unix line endings. Otherwise the compilation might not work.
+
+### Windows (Vista and later)
+1. If you have ever installed WinAVR, uninstall it.
+2. Install [MHV AVR Tools](https://infernoembedded.com/sites/default/files/project/MHV_AVR_Tools_20131101.exe). Disable smatch, but **be sure to leave the option to add the tools to the PATH checked**.
+3. If you are going to flash Infinity based keyboards you will need to install dfu-util, refer to the instructions by [Input Club](https://github.com/kiibohd/controller/wiki/Loading-DFU-Firmware).
+4. Install [MinGW](https://sourceforge.net/projects/mingw/files/Installer/mingw-get-setup.exe/download). During installation, uncheck the option to install a graphical user interface. **DO NOT change the default installation folder.** The scripts depend on the default location.
+5. Clone this repository. [This link will download it as a zip file, which you'll need to extract.](https://github.com/qmk/qmk_firmware/archive/master.zip) Open the extracted folder in Windows Explorer.
+6. Open the `\util` folder.
+7. Double-click on the `1-setup-path-win` batch script to run it. You'll need to accept a User Account Control prompt. Press the spacebar to dismiss the success message in the command prompt that pops up.
+8. Right-click on the `2-setup-environment-win` batch script, select "Run as administrator", and accept the User Account Control prompt. This part may take a couple of minutes, and you'll need to approve a driver installation, but once it finishes, your environment is complete!
+
+If you have trouble and want to ask for help, it is useful to generate a *Win_Check_Output.txt* file by running `Win_Check.bat` in the `\util` folder.
+
+### Mac
+If you're using [homebrew,](http://brew.sh/) you can use the following commands:
+
+ brew tap osx-cross/avr
+ brew install avr-libc
+ brew install dfu-programmer
+
+This is the recommended method. If you don't have homebrew, [install it!](http://brew.sh/) It's very much worth it for anyone who works in the command line. Note that the `make` and `make install` portion during the homebrew installation of avr-libc can take over 20 minutes and exhibit high CPU usage.
+
+You can also try these instructions:
+
+1. Install Xcode from the App Store.
+2. Install the Command Line Tools from `Xcode->Preferences->Downloads`.
+If you are going to flash Infinity based keyboards you will also need dfu-util
+
+ brew install dfu-util
+
+### Linux
+
+To ensure you are always up to date, you can just run `sudo util/install_dependencies.sh`. That should always install all the dependencies needed. **This will run `apt-get upgrade`.**
+
+You can also install things manually, but this documentation might not be always up to date with all requirements.
+
+The current requirements are the following, but not all might be needed depending on what you do. Also note that some systems might not have all the dependencies available as packages, or they might be named differently.
+
+```
+build-essential
+gcc
+unzip
+wget
+zip
+gcc-avr
+binutils-avr
+avr-libc
+dfu-programmer
+dfu-util
+gcc-arm-none-eabi
+binutils-arm-none-eabi
+libnewlib-arm-none-eabi
+git
+```
+
+Install the dependencies with your favorite package manager.
+If this is a bit complex for you, Docker might be the turn-key solution you need. After installing [Docker](https://www.docker.com/products/docker), run the following command at the root of the QMK folder to build a keyboard/keymap:
+
+```bash
+# You'll run this every time you want to build a keymap
+# modify the keymap and keyboard assigment to compile what you want
+# On windows docker seems to have issue with VOLUME tag in Dockerfile, and $('pwd') won't print a windows compliant path, use full path instead like this
+This will compile the targeted keyboard/keymap and leave it in your QMK directory for you to flash.
+
+### Vagrant
+If you have any problems building the firmware, you can try using a tool called Vagrant. It will set up a virtual computer with a known configuration that's ready-to-go for firmware building. OLKB does NOT host the files for this virtual computer. Details on how to set up Vagrant are in the [vagrant guide](vagrant_guide.md).
+
+## Verify Your Installation
+1. If you haven't already, obtain this repository ([https://github.com/qmk/qmk_firmware](https://github.com/qmk/qmk_firmware)). You can either download it as a zip file and extract it, or clone it using the command line tool git or the Github Desktop application.
+2. Open up a terminal or command prompt and navigate to the `qmk_firmware` folder using the `cd` command. The command prompt will typically open to your home directory. If, for example, you cloned the repository to your Documents folder, then you would type `cd Documents/qmk_firmware`. If you extracted the file from a zip, then it may be named `qmk_firmware-master` instead.
+3. To confirm that you're in the correct location, you can display the contents of your current folder using the `dir` command on Windows, or the `ls` command on Linux or Mac. You should see several files, including `readme.md` and a `quantum` folder. From here, you need to navigate to the appropriate folder under `keyboards/`. For example, if you're building for a Planck, run `cd keyboards/planck`.
+4. Once you're in the correct keyboard-specific folder, run the `make` command. This should output a lot of information about the build process. More information about the `make` command can be found below.
+# This guide has now been included in the main readme - please reference that one instead.
+
+## Build Environment Setup
+
+### Windows (Vista and later)
+1. If you have ever installed WinAVR, uninstall it.
+2. Install [MHV AVR Tools](https://infernoembedded.com/sites/default/files/project/MHV_AVR_Tools_20131101.exe). Disable smatch, but **be sure to leave the option to add the tools to the PATH checked**.
+3. Install [MinGW](https://sourceforge.net/projects/mingw/files/Installer/mingw-get-setup.exe/download). During installation, uncheck the option to install a graphical user interface. **DO NOT change the default installation folder.** The scripts depend on the default location.
+4. Clone this repository. [This link will download it as a zip file, which you'll need to extract.](https://github.com/qmk/qmk_firmware/archive/master.zip) Open the extracted folder in Windows Explorer.
+5. Double-click on the 1-setup-path-win batch script to run it. You'll need to accept a User Account Control prompt. Press the spacebar to dismiss the success message in the command prompt that pops up.
+6. Right-click on the 2-setup-environment-win batch script, select "Run as administrator", and accept the User Account Control prompt. This part may take a couple of minutes, and you'll need to approve a driver installation, but once it finishes, your environment is complete!
+7. Future build commands should be run from the standard Windows command prompt, which you can find by searching for "command prompt" from the start menu or start screen. Ignore the "MHV AVR Shell".
+
+### Mac
+If you're using [homebrew,](http://brew.sh/) you can use the following commands:
+
+ brew tap osx-cross/avr
+ brew install avr-libc
+ brew install dfu-programmer
+
+This is the recommended method. If you don't have homebrew, [install it!](http://brew.sh/) It's very much worth it for anyone who works in the command line.
+
+You can also try these instructions:
+
+1. Install Xcode from the App Store.
+2. Install the Command Line Tools from `Xcode->Preferences->Downloads`.
+3. Install [DFU-Programmer][dfu-prog].
+
+### Linux
+Install AVR GCC, AVR libc, and dfu-progammer with your favorite package manager.
+If you have any problems building the firmware, you can try using a tool called Vagrant. It will set up a virtual computer with a known configuration that's ready-to-go for firmware building. OLKB does NOT host the files for this virtual computer. Details on how to set up Vagrant are in the [vagrant guide](vagrant_guide.md).
+
+## Verify Your Installation
+1. If you haven't already, obtain this repository ([https://github.com/qmk/qmk_firmware](https://github.com/qmk/qmk_firmware)). You can either download it as a zip file and extract it, or clone it using the command line tool git or the Github Desktop application.
+2. Open up a terminal or command prompt and navigate to the `qmk_firmware` folder using the `cd` command. The command prompt will typically open to your home directory. If, for example, you cloned the repository to your Documents folder, then you would type `cd Documents/qmk_firmware`. If you extracted the file from a zip, then it may be named `qmk_firmware-master` instead.
+3. To confirm that you're in the correct location, you can display the contents of your current folder using the `dir` command on Windows, or the `ls` command on Linux or Mac. You should see several files, including `readme.md` and a `quantum` folder. From here, you need to navigate to the appropriate folder under `keyboards/`. For example, if you're building for a Planck, run `cd keyboards/planck`.
+4. Once you're in the correct keyboard-specific folder, run the `make` command. This should output a lot of information about the build process. More information about the `make` command can be found below.
+
+## Customizing, Building, and Deploying Your Firmware
+
+### The Make command
+
+The `make` command is how you compile the firmware into a .hex file, which can be loaded by a dfu programmer (like dfu-progammer via `make dfu`) or the [Teensy loader](https://www.pjrc.com/teensy/loader.html) (only used with Teensys). You can run `make` from the root (`/`), your keyboard folder (`/keyboards/<keyboard>/`), or your keymap folder (`/keyboards/<keyboard>/keymaps/<keymap>/`) if you have a `Makefile` there (see the example [here](/doc/keymap_makefile_example.mk)).
+
+By default, this will generate a `<keyboard>_<keymap>.hex` file in whichever folder you run `make` from. These files are ignored by git, so don't worry about deleting them when committing/creating pull requests.
+
+* The "root" (`/`) folder is the qmk_firmware folder, in which are `doc`, `keyboard`, `quantum`, etc.
+* The "keyboard" folder is any keyboard project's folder, like `/keyboards/planck`.
+* The "keymap" folder is any keymap's folder, like `/keyboards/planck/keymaps/default`.
+
+Below is a list of the useful `make` commands in QMK:
+
+* `make` - cleans automatically and builds your keyboard and keymap depending on which folder you're in. This defaults to the "default" layout (unless in a keymap folder), and Planck keyboard in the root folder
+ * `make keyboard=<keyboard>` - specifies the keyboard (only to be used in root)
+ * `make keymap=<keymap>` - specifies the keymap (only to be used in root and keyboard folder - not needed when in keymap folder)
+* `make quick` - skips the clean step (cannot be used immediately after modifying config.h or Makefiles)
+* `make dfu` - (requires dfu-programmer) builds and flashes the keymap to your keyboard once placed in reset/dfu mode (button or press `KC_RESET`). This does not work for Teensy-based keyboards like the ErgoDox EZ.
+ * `keyboard=` and `keymap=` are compatible with this
+* `make all-keyboards` - builds all keymaps for all keyboards and outputs status of each (use in root)
+* `make all-keyboards-default` - builds all default keymaps for all keyboards and outputs status of each (use in root)
+* `make all-keymaps [keyboard=<keyboard>]` - builds all of the keymaps for whatever keyboard folder you're in, or specified by `<keyboard>`
+* `make all-keyboards-quick`, `make all-keyboards-default-quick` and `make all-keymaps-quick [keyboard=<keyboard>]` - like the normal "make-all-*" commands, but they skip the clean steps
+
+Other, less useful functionality:
+
+* `make COLOR=false` - turns off color output
+* `make SILENT=true` - turns off output besides errors/warnings
+* `make VERBOSE=true` - outputs all of the avr-gcc stuff (not interesting)
+
+### The Makefile
+
+There are 3 different `make` and `Makefile` locations:
+The root contains the code used to automatically figure out which keymap or keymaps to compile based on your current directory and commandline arguments. It's considered stable, and shouldn't be modified. The keyboard one will contain the MCU set-up and default settings for your keyboard, and shouldn't be modified unless you are the producer of that keyboard. The keymap Makefile can be modified by users, and is optional. It is included automatically if it exists. You can see an example [here](/doc/keymap_makefile_example.mk) - the last few lines are the most important. The settings you set here will override any defaults set in the keyboard Makefile. **It is required if you want to run `make` in the keymap folder.**
+The keyboard `config.h` is included only if the keymap one doesn't exist. The format to use for your custom one [is here](/doc/keymap_config_h_example.h). If you want to override a setting from the parent `config.h` file, you need to do this:
+
+```
+#undef MY_SETTING
+#define MY_SETTING 4
+```
+
+For a value of `4` for this imaginary setting. So we `undef` it first, then `define` it.
+
+You can then override any settings, rather than having to copy and paste the whole thing.
+A custom keyboard is about more than sending button presses to your computer. QMK has designed hooks to allow you to inject code, override functionality, and otherwise customize how your keyboard responds in different situations.
+
+## A Word on Keyboards vs Keymap
+
+We have structured QMK as a hierarchy:
+
+* Core (`_quantum`)
+ * Keyboard/Revision (`_kb`)
+ * Keymap (`_user`)
+
+Each of the functions described below can be defined with a `_kb()` suffix or an `_user()` suffix. We intend for you to use the `_kb()` suffix at the Keyboard/Revision level, while the `_user()` suffix should be used at the Keymap level.
+
+When defining functions at the Keyboard/Revision level it is important that your `_kb()` implementation call `_user()` before executing anything else- otherwise the keymap level function will never be called.
+
+## Matrix Initialization Code
+
+* Keyboard/Revision: `void matrix_init_kb(void)`
+* Keymap: `void matrix_init_user(void)`
+
+This function gets called when the matrix is initiated. You should use this function to initialize any custom hardware you may have, such as speakers, LED drivers, or other features which need to be setup after the keyboard powers on.
+
+### Example
+
+```
+void matrix_init_kb(void) {
+ // put your keyboard start-up code here
+ // runs once when the firmware starts up
+ matrix_init_user();
+
+ // JTAG disable for PORT F. write JTD bit twice within four cycles.
+ MCUCR |= (1<<JTD);
+ MCUCR |= (1<<JTD);
+
+ // * Set our LED pins as output
+ DDRB |= (1<<0);
+ DDRB |= (1<<1);
+ DDRB |= (1<<2);
+ DDRB |= (1<<3);
+ DDRB |= (1<<4);
+}
+```
+
+## Matrix Scanning Code
+
+* Keyboard/Revision: `void matrix_scan_kb(void)`
+* Keymap: `void matrix_scan_user(void)`
+
+This function gets called at every matrix scan, which is basically as often as the MCU can handle. Be careful what you put here, as it will get run a lot.
+
+You should use this function if you need custom matrix scanning code. It can also be used for custom status output (such as LED's or a display) or other functionality that you want to trigger regularly even when the user isn't typing.
+This function gets called every time a key is pressed or released. This is particularly useful when defining custom keys or overriding the behavior of existing keys.
+
+The return value is whether or not QMK should continue processing the keycode - returning `false` stops the execution.
+
+The `keycode` variable is whatever is defined in your keymap, eg `MO(1)`, `KC_L`, etc. and can be switch-cased to execute code whenever a particular code is pressed.
+
+The `record` variable contains infomation about the actual press:
+
+```
+keyrecord_t record {
++-keyevent_t event {
+| +-keypos_t key {
+| | +-uint8_t col
+| | +-uint8_t row
+| | }
+| +-bool pressed
+| +-uint16_t time
+| }
+}
+```
+
+The conditional `if (record->event.pressed)` can tell if the key is being pressed or released, and you can execute code based on that.
+#Planck Advanced (but not too advanced) `cygwin` Users Guide
+If you are a user of the [cygwin environment](https://cygwin.com) in Windows and want the freedom to use the latest tools available, then this is the guide for you. If compiling your own copy of the latest and greatest Gnu C Compiler makes you super happy, then this is the guide for you. If the command line make you smile, then this is the guide for you.
+
+This guide was written step by step as I went through the process on a `Windows 10` `x86_64` and a `Windows 7` `amd k10` based system. This should be generally applicable to to any `Windows` environment with `cygwin`.
+
+#####Do not skip steps. Do not move past a step until the previous step finishes successfully.
+
+Based on [avr-libc installation guide](http://www.nongnu.org/avr-libc/user-manual/install_tools.html)
+
+##Get the Required Packages
+Download the `cygwin` setup ([x86_64](https://cygwin.com/setup-x86_64.exe)) and install the default system plus the following if they are not already selected:
+The set of commands below will create a directory (`~/local/avr`) for the sources you compile to be installed on the machine and a directory (`~/src`) for these source files to be stored. The commands then download the sources of the needed packages and unpack them. Note: the expand commands are different depending on if the packages are offered as a `bz2` or `gz` archive
+These commands will set up the install directory and the `PATH` variable, which will allow you to access your installed packages. Note: if you close the `cygwin` terminal window, you will need to rerun these commands, they are not permanent.
+The following packages are required to be complied and installed in order to compile `gcc`. They are not sufficiently available through the `cygwin` package system, so we have to make them ourselves. They must be complied in this order because each one depends on the previous. Verfiy that for each package, `make check` returns all passing and no fails.
+You can build and install a brand new `gcc` or you can use the one supplied by `cygwin`. This will take about 4-5 hours to compile (It is a "native build", so it does the entire build **3 times**. This takes a long while).
+##Buliding `binutils`, `gcc`, and `avr-libc` for the AVR system
+Now we can make the critical stuff for compiling our firmware: `binutils`, `gcc`, and `avr-libc` for the AVR architecture. These allow us to build and manipulate the firmware for the keyboard.
+
+###Build `binutils` for AVR
+If you plan to build and install `avr-gdb` also, use the `gdb` install at the end of this guide as it also builds the `binutils`
+For building the `avr-libc`, we have to specify the host build system. In my case it is `x86_64-unknown-cygwin`. You can look for build system type in the `gcc` configure notes for the proper `--build` specification to pass when you configure `avr-libc`.
+##Building 'dfu-programmer' for flashing the firmware via USB and installing the drivers
+We can either build our own, or use the precomplied binaries. The precompiled binaries don't play well with `cygwin` so it is better to build them ourselves. The procedure for the precompiled binaries is included at the end of this guide.
+
+### Build and Install the `libusb`
+The `dfu-programmer` requires `libusb` so that it can interact with the USB system. These repos must be bootstrapped in order to create an appropriate `./configure` and `Makefile` for your system.
+Type 'dfu-programmer --help' for a list of commands
+ 'dfu-programmer --targets' to list supported target devices
+```
+If you are not getting the above result, you will not be able to flash the firmware!
+
+###Install the USB drivers
+The drivers are included in the windows binary version of [`dfu-programmer` 0.7.2](http://iweb.dl.sourceforge.net/project/dfu-programmer/dfu-programmer/0.7.2/dfu-programmer-win-0.7.2.zip).
+The official drivers are found in [Atmel's `FLIP` installer](http://www.atmel.com/images/Flip%20Installer%20-%203.4.7.112.exe). Download and then install `FLIP`. Upon installation, the drivers will be found in `C:\Program Files (x86)\Atmel\Flip 3.4.7\usb`.
+
+Then, from an **administrator-privileged** `Windows` terminal, run the following command (adjust the path for username, etc. as necessary) and accept the prompt that pops up:
+```
+C:\> pnputil -i -a C:\cygwin64\home\Kevin\src\dfu-programmer-win-0.7.2\dfu-prog-usb-1.2.2\atmel_usb_dfu.inf
+or
+C:\> pnputil -i -a "C:\Program Files (x86)\Atmel\Flip 3.4.7\usb\atmel_usb_dfu.inf"
+```
+
+This should be the result:
+```
+Microsoft PnP Utility
+
+Processing inf : atmel_usb_dfu.inf
+Successfully installed the driver on a device on the system.
+Driver package added successfully.
+Published name : oem104.inf
+
+
+Total attempted: 1
+Number successfully imported: 1
+```
+
+Alternatively, the `Windows` driver can be installed when prompted by `Windows` when the keyboard is attached. Do not let `Windows` search for a driver; specify the path to search for a driver and point it to the `atmel_usb_dfu.inf` file.
+
+##Building and Flashing the Planck firmware!
+If you did everything else right. This part should be a snap! Grab the latest sources from `github`, make the Plank firmware, then flash it.
+If you do not get the above, you **did not** build the firmware, and you will have nothing to flash. If you have the fresh clone from `github`, it was probably something gone wrong in this install process, go check and see what didn't work and threw errors or what steps you might have missed.
+
+But if everything went OK, you are ready to flash! Press the reset button on the bottom of the Planck, wait two seconds, then:
+```
+$ make dfu
+```
+.
+.
+.
+profit!!!
+
+
+
+
+
+##extra bits...
+
+###Installing Precompiled `dfu-programmer` Binaries (not recommended for `cygwin`)
+To install the `dfu-programmer` from the binaries, we must get if from [the `dfu-programmer` website](https://dfu-programmer.github.io/) ([0.7.2](http://iweb.dl.sourceforge.net/project/dfu-programmer/dfu-programmer/0.7.2/dfu-programmer-win-0.7.2.zip)).
+
+Copy this file into your `cygwin` home\src directory. (For me, it is `C:\cygwin64\home\Kevin\src`), extract the files, move `dfu-programmer.exe` to `~/local/avr/bin`. Most obnoxiously, the `libusb0_x86.dll` and `libusb0.sys` need to be moved from `./dfu-prog-usb-1.2.2/x86/` to a directory in the `Windows` `PATH` and the `cygwin` `PATH`. This is because the `dfu-programmer` binary is `mingw` based, not `cygwin` based, so the `dlls` do not cooperate. I achieved acceptable pathing by moving the files to `C:\cygwin64\home\Kevin\local\avr\bin` Then, in a `WINDOWS` command prompt running (Adjusting your path for username, etc. as needed):
+```
+C:\> set PATH=%PATH%;C:\cygwin64\home\Kevin\local\avr\bin
+```
+
+Then, rename `libusb0_x86.dll` to `libusb0.dll`.
+
+You can tell that you were successful by trying to execute 'dfu-programmer' from the 'cygwin' prompt:
+```
+$ which dfu-programmer
+/home/Kevin/local/avr/bin/dfu-programmer
+
+$ dfu-programmer
+dfu-programmer 0.7.2
+https://github.com/dfu-programmer/dfu-programmer
+Type 'dfu-programmer --help' for a list of commands
+ 'dfu-programmer --targets' to list supported target devices
+```
+
+If you are not getting the above result, you will not be able to flash the firmware!
+- Try making sure your `PATH` variables are set correctly for both `Windows` and `cygwin`.
+- Make sure the `dll` is named correctly.
+- Do not extract it with `cygwin`'s `unzip` as it does not set the executable permission. If you did it anyway, do `chmod +x dfu-programmer.exe`.
+- Still have problems? Try building it instead.
+
+
+##Debugging Tools
+
+These tools are for debugging your firmware, etc. before flashing. Theoretically, it can save your memory from wearing out. However, these tool do not work 100% for the Planck firmware.
+
+### `gdb` for AVR
+`gdb` has a simulator for AVR but it does not support all instructions (like WDT), so it immediately crashes when running the Planck firmware (because `lufa.c` disables the WDT in the first few lines of execution). But it can still be useful in debugging example code and test cases, if you know how to use it.
+`simulavr` is an AVR simulator. It runs the complied AVR elfs. `simulavr` does not support the `atmega32u4` device... it does `atmega32` but that is not good enough for the firmware (no PORTE and other things), so you cannot run the Planck firmware. I use it to simulate ideas I have for features in separate test projects.
+
+This one is a major pain in the butt because it has a lot of dependencies and it is buggy. I will do my best to explain it but... it was hard to figure out. A few things need to be changed in the 'Makefile' to make it work in `cygwin`.
+ Edit `src/Makefile.am` now so that `-no-undefined` is included (I did this by removing the SYS_MINGW conditional surrounding `libsim_la_LDFLAGS += -no-undefined` and `libsimulavr_la_LDFLAGS += -no-undefined \ libsimulavr_la_LIBADD += $(TCL_LIB)`. Also, `$(EXEEXT)` is added after `kbdgentables` in two places.
+Understanding the essential changes made on the [tmk_keyboard firmware](http://github.com/tmk/tmk_keyboard) should help you understand the QMK Firmware.
+# Dynamic macros: record and replay macros in runtime
+
+QMK supports temporarily macros created on the fly. We call these Dynamic Macros. They are defined by the user from the keyboard and are lost when the keyboard is unplugged or otherwise rebooted.
+
+You can store one or two macros and they may have a combined total of 128 keypresses. You can increase this size at the cost of RAM.
+
+To enable them, first add a new element to the `planck_keycodes` enum — `DYNAMIC_MACRO_RANGE`:
+
+```c
+enum planck_keycodes {
+ QWERTY = SAFE_RANGE,
+ COLEMAK,
+ DVORAK,
+ PLOVER,
+ LOWER,
+ RAISE,
+ BACKLIT,
+ EXT_PLV,
+ DYNAMIC_MACRO_RANGE,
+};
+```
+
+It must be the last element because `dynamic_macros.h` will add some more keycodes after it.
+
+Below it include the `dynamic_macro.h` header:
+
+```c
+ #include "dynamic_macro.h"`
+```
+
+Add the following keys to your keymap:
+
+* `DYN_REC_START1` — start recording the macro 1,
+* `DYN_REC_START2` — start recording the macro 2,
+* `DYN_MACRO_PLAY1` — replay the macro 1,
+* `DYN_MACRO_PLAY2` — replay the macro 2,
+* `DYN_REC_STOP` — finish the macro that is currently being recorded.
+
+Add the following code to the very beginning of your `process_record_user()` function:
+
+```c
+ if (!process_record_dynamic_macro(keycode, record)) {
+ return false;
+ }
+```
+
+That should be everything necessary. To start recording the macro, press either `DYN_REC_START1` or `DYN_REC_START2`. To finish the recording, press the `DYN_REC_STOP` layer button. To replay the macro, press either `DYN_MACRO_PLAY1` or `DYN_MACRO_PLAY2`.
+
+Note that it's possible to replay a macro as part of a macro. It's ok to replay macro 2 while recording macro 1 and vice versa but never create recursive macros i.e. macro 1 that replays macro 1. If you do so and the keyboard will get unresponsive, unplug the keyboard and plug it again.
+
+For users of the earlier versions of dynamic macros: It is still possible to finish the macro recording using just the layer modifier used to access the dynamic macro keys, without a dedicated `DYN_REC_STOP` key. If you want this behavior back, use the following snippet instead of the one above:
+ if (!process_record_dynamic_macro(macro_kc, record)) {
+ return false;
+ }
+```
+
+If the LED's start blinking during the recording with each keypress, it means there is no more space for the macro in the macro buffer. To fit the macro in, either make the other macro shorter (they share the same buffer) or increase the buffer size by setting the `DYNAMIC_MACRO_SIZE` preprocessor macro (default value: 128; please read the comments for it in the header).
+
+For the details about the internals of the dynamic macros, please read the comments in the `dynamic_macro.h` header.
+[Eclipse](https://en.wikipedia.org/wiki/Eclipse_(software)) is an open-source [Integrated Development Environment](https://en.wikipedia.org/wiki/Integrated_development_environment) (IDE) widely used for Java development, but with an extensible plugin system that allows to customize it for other languages and usages.
+
+Using an IDE such as Eclipse provides many advantages over a plain text editor, such as:
+* intelligent code completion
+* convenient navigation in the code
+* refactoring tools
+* build automation (no need for the command-line)
+* a GUI for GIT
+* static code analysis
+* many other tools such as debugging, code formatting, showing call hierarchies etc.
+
+The purpose of the is page is to document how to set-up Eclipse for developing AVR software, and working on the QMK code base.
+
+Note that this set-up has been tested on Ubuntu 16.04 only for the moment.
+
+# Prerequisites
+## Build environment
+Before starting, you must have followed the [Getting Started](home.md#getting-started) section corresponding to your system. In particular, you must have been able to build the firmware with [the `make` command](../#the-make-command).
+
+## Java
+Eclipse is a Java application, so you will need to install Java 8 or more recent to be able to run it. You may choose between the JRE or the JDK, the latter being useful if you intend to do Java development.
+
+# Install Eclipse and its plugins
+Eclipse comes in [several flavours](http://www.eclipse.org/downloads/eclipse-packages/) depending on the target usage that you will have. There is no package comprising the AVR stack, so we will need to start from Eclipse CDT (C/C++ Development Tooling) and install the necessary plugins.
+
+## Download and install Eclipse CDT
+If you already have Eclipse CDT on your system, you can skip this step. However it is advised to keep it up-to-date for better support.
+
+If you have another Eclipse package installed, it is normally possible to [install the CDT plugin over it](https://eclipse.org/cdt/downloads.php). However it is probably better to reinstall it from scratch to keep it light and avoid the clutter of tools that you don't need for the projects you will be working on.
+
+Installation is very simple: follow the [5 Steps to Install Eclipse](https://eclipse.org/downloads/eclipse-packages/?show_instructions=TRUE), and choose **Eclipse IDE for C/C++ Developers** at Step 3.
+
+Alternatively, you can also directly [download Eclipse IDE for C/C++ Developers](http://www.eclipse.org/downloads/eclipse-packages/) ([direct link to current version](http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/neonr)) and extract the package to the location of your choice (this creates an `eclipse` folder).
+
+## First Launch
+When installation is complete, click the <kbd>Launch</kbd> button. (If you extracted the package manually, open the Eclipse installation folder and double-click the `eclipse` executable)
+
+When you are prompted with the Workspace Selector, select a directory that will hold Eclipse metadata and usually your projects. **Do not select the `qmk_firmware` directory**, this will be the project directory. Select the parent folder instead, or another (preferably empty) folder of your choice (the default is fine if you do not use it yet).
+
+Once started, click the <kbd>Workbench</kbd> button at the top right to switch to the workbench view (there is a also checkbox at the bottom to skip the welcome screen at startup).
+
+## Install the necessary plugins
+Note: you do not need to restart Eclipse after installing each plugin. Simply restart once all plugins are installed.
+This is the most important plugin as it will allow Eclipse to _understand_ AVR C code. Follow [the instructions for using the update site](http://avr-eclipse.sourceforge.net/wiki/index.php/Plugin_Download#Update_Site), and agree with the security warning for unsigned content.
+
+### [ANSI Escape in Console](https://marketplace.eclipse.org/content/ansi-escape-console)
+This plugin is necessary to properly display the colored build output generated by the QMK makefile.
+
+1. Open <kbd><kbd>Help</kbd> > <kbd>Eclipse Marketplace…</kbd></kbd>
+2. Search for _ANSI Escape in Console_
+3. Click the <samp>Install</samp> button of the plugin
+4. Follow the instructions and agree again with the security warning for unsigned content.
+
+Once both plugins are installed, restart Eclipse as prompted.
+ * Select the directory where you cloned the repository as _Existing Code Location_;
+ * (Optional) Give a different name to the project¹, e.g. _QMK_ or _Quantum_;
+ * Select the _AVR-GCC Toolchain_;
+ * Keep the rest as-is and click <kbd>Finish</kbd>
+
+ ![Importing QMK in Eclipse](http://i.imgur.com/oHYR1yW.png)
+
+3. The project will now be loaded and indexed. Its files can be browsed easily through the _Project Explorer_ on the left.
+
+¹ There might be issues for importing the project with a custom name. If it does not work properly, try leaving the default project name (i.e. the name of the directory, probably `qmk_firmware`).
+
+## Build your keyboard
+We will now configure a make target that cleans the project and builds the keymap of your choice.
+
+1. On the right side of the screen, select the <kbd>Make Target</kbd> tab
+2. Expand the folder structure to the keyboard of your choice, e.g. `qmk_firmware/keyboards/ergodox`
+3. Right-click on the keyboard folder and select <kbd>New…</kbd> (or select the folder and click the <kbd>New Make Target</kbd> icon above the tree)
+4. Choose a name for your build target, e.g. _clean \<your keymap\>_
+5. Make Target: this is the arguments that you give to `make` when building from the command line. If your target name does not match these arguments, uncheck <kbd>Same as target name</kbd> and input the correct arguments, e.g. `clean <your keymap>`
+6. Leave the other options checked and click <kbd>OK</kbd>. Your make target will now appear under the selected keyboard.
+7. (Optional) Toggle the <kbd>Hide Empty Folders</kbd> icon button above the targets tree to only show your build target.
+8. Double-click the build target you created to trigger a build.
+9. Select the <kbd>Console</kbd> view at the bottom to view the running build.
+# WARNING: Until issue [#173](https://github.com/tmk/tmk_keyboard/issues/173) goes through, the [core][1] repository will not be up-to-date with the latest changes and fixes, but can still be used.
+
+If you want to use TMK for your own keyboard project, you've got three options for embedding the [core][1].
+The recommended option is [subtrees](#1-git-subtree).
+
+After adding the embed you'll need to [modify the Makefile](#modifications-to-the-makefile) of your project to point to the core correctly.
+
+## 1. git subtree
+
+In order to set up the subtree in your project, first add the core repository as a remote:
+Extract the zip in your project's directory, then rename the folder to <kbd>tmk_core</kbd>.
+
+## Modifications to the *Makefile*
+
+The one thing you have to make sure to change in the *Makefile* (compared to [tmk_keyboard](https://github.com/tmk/tmk_keyboard) drivers' *[Makefile](https://github.com/tmk/tmk_keyboard/blob/master/keyboard/gh60/Makefile#L45)*) is the "TMK_DIR" variable, which needs to point to the embed directory:
+First you have to compile frimware with this build option `NKRO_ENABLE` in **Makefile**.
+
+Try `Magic` **N** command(`LShift+RShift+N` by default) when **NKRO** still doesn't work. You can use this command to toggle between **NKRO** and **6KRO** mode temporarily. In some situations **NKRO** doesn't work you need to switch to **6KRO** mode, in particular when you are in BIOS.
+
+If your firmeare built with `BOOTMAGIC_ENABLE` you need to turn its switch on by `BootMagic` **N** command(`Space+N` by default). This setting is stored in EEPROM and keeped over power cycles.
+Use `1UL<<16` instead of `1<<16` in `read_cols()` in **matrix.h** when your columns goes beyond 16.
+
+In C `1` means one of **int** type which is **16bit** in case of AVR so you can't shift left more than 15. You will get unexpected zero when you say `1<<16`. You have to use **unsigned long** type with `1UL`.
+Properly configure bootloader size in **Makefile**. With wrong section size bootloader won't probably start with **Magic command** and **Boot Magic**.
+```
+# Size of Bootloaders in bytes:
+# Atmel DFU loader(ATmega32U4) 4096
+# Atmel DFU loader(AT90USB128) 8192
+# LUFA bootloader(ATmega32U4) 4096
+# Arduino Caterina(ATmega32U4) 4096
+# USBaspLoader(ATmega***) 2048
+# Teensy halfKay(ATmega32U4) 512
+# Teensy++ halfKay(AT90USB128) 2048
+OPT_DEFS += -DBOOTLOADER_SIZE=4096
+```
+AVR Boot section size are defined by setting **BOOTSZ** fuse in fact. Consult with your MCU datasheet.
+Note that **Word**(2 bytes) size and address are used in datasheet while TMK uses **Byte**.
+
+AVR Boot section is located at end of Flash memory like the followings.
+In Windows check `Allow this device to wake the computer` setting in Power **Management property** tab of **Device Manager**. Also check BIOS setting.
+
+Pressing any key during sleep should wake host.
+
+
+## Using Arduino?
+**Note that Arduino pin naming is different from actual chip.** For example, Arduino pin `D0` is not `PD0`. Check circuit with its schematics yourself.
+Arduino leonardo and micro have **ATMega32U4** and can be used for TMK, though Arduino bootloader may be a problem.
+
+
+## Using PF4-7 pins of USB AVR?
+You need to set JTD bit of MCUCR yourself to use PF4-7 as GPIO. Those pins are configured to serve JTAG function by default. MCUs like ATMega*U* or AT90USB* are affeteced with this.
+
+If you are using Teensy this isn't needed. Teensy is shipped with JTAGEN fuse bit unprogrammed to disable the function.
+
+See this code.
+```
+ // JTAG disable for PORT F. write JTD bit twice within four cycles.
+## Problem on BIOS(UEFI)/Resume(Sleep&Wake)/Power cycles
+Some people reported their keyboard stops working on BIOS and/or after resume(power cycles).
+
+As of now root of its cause is not clear but some build options seem to be related. In Makefile try to disable those options like `CONSOLE_ENABLE`, `NKRO_ENABLE`, `SLEEP_LED_ENABLE` and/or others.
+**PJRC** stack won't be supported actively anymore. There is no reason to hesitate to use LUFA except for binary size(about 1KB lager?). But **PJRC** is still very useful for debug and development purpose.
+See also [Issue #50](https://github.com/tmk/tmk_keyboard/issues/50) and [Issue #58](https://github.com/tmk/tmk_keyboard/issues/58).
+
+## Edit configuration but not change
+You will need followings after editing `CONSOLE_ENABLE`, `NKRO_ENABLE`, `EXTRAKEY_ENABLE` or `MOUSEKEY_ENABLE` option in **Makefile**.
+
+### 1. make clean
+This will be needed when you edit **config.h**.
+
+### 2. Remove Drivers from Device Manager(Windows)
+**Windows only.** Linux, OSX and other OS's doesn't require this. It looks like Windows keeps using driver installed when device was connected first time even after the device changes its configuration. To load proper drivers for new configuration you need to remove existent drivers from **Drvice Manager**.
+
+### 3. Build with different VID:PID
+**Windows only.** If method 2. does't work fou you try this. Change Vendor ID or Product ID in **config.h** and build firmware. Windows should recognize it as whole new device and start drivers install process.
+
+### 4. Just try other ports
+This will be useful and the easiest workaround for **Windows**.
+
+
+
+## USB VID and PID
+You can use any ID you want with editing `config.h`. Using any presumably unused ID will be no problem in fact except for very least chance of collision with other product.
+
+For example TMK uses following numbers by default.
+```
+keyboard:
+hhkb: FEED:CAFE
+gh60: FEED:6060
+
+converter:
+x68k: FEED:6800
+ps2: FEED:6512
+adb: FEED:0ADB
+ibm4704: FEED:4704
+pc98: FEED:9898
+```
+
+Also see this.
+https://github.com/tmk/tmk_keyboard/issues/150
+
+You can buy a really unique VID:PID here. I don't think you need this for personal use.
+On Linux you need proper privilege to access device file of MCU, you'll have to use `sudo` when flashing firmware. You can circumvent this with placing these files in `/etc/udev/rules.d/`.
+See [Keycodes](Keycodes). Keycodes are actually defined in [common/keycode.h](https://github.com/qmk/qmk_firmware/blob/master/tmk_core/common/keycode.h).
+
+## Sysrq key
+Use keycode for Print Screen(`KC_PSCREEN` or `KC_PSCR`) instead of `KC_SYSREQ`. Key combination of 'Alt + Print Screen' is recognized as 'System request'.
+
+See [issue #168](https://github.com/tmk/tmk_keyboard/issues/168) and
+- http://en.wikipedia.org/wiki/Magic_SysRq_key
+- http://en.wikipedia.org/wiki/System_request
+
+## Power key doesn't work
+Use `KC_PWR` instead of `KC_POWER` or vice versa.
+- `KC_PWR` works with Windows and Linux, not with OSX.
+- `KC_POWER` works with OSX and Linux, not with Windows.
+Solves my personal 'the' problem. I often got 'the' or 'THe' wrongly instead of 'The'. Oneshot Shift mitgates this for me.
+https://github.com/tmk/tmk_keyboard/issues/67
+
+## Modifier/Layer stuck
+Modifier keys or layers can be stuck unless layer switching is configured properly.
+For Modifier keys and layer actions you have to place `KC_TRANS` on same position of destination layer to unregister the modifier key or return to previous layer on release event.
+This feature is for *mechanical lock switch* like this Alps one.
+http://deskthority.net/wiki/Alps_SKCL_Lock
+
+Using enabling this feature and using keycodes `LCAP`, `LNUM` or `LSCR` in keymap you can use physical locking CapsLock, NumLock or ScrollLock keys as you expected.
+
+Old vintage mechanical keyboards occasionally have lock switches but modern ones don't have. ***You don't need this feature in most case and just use keycodes `CAPS`, `NLCK` and `SLCK`.***
+
+
+## Input special charactors other than ASCII like Cédille 'Ç'
+NO UNIVERSAL METHOD TO INPUT THOSE WORKS OVER ALL SYSTEMS. You have to define **MACRO** in way specific to your OS or layout.
+Apple/Mac keyboard sends keycode for Fn unlike most of other keyboards.
+I think you can send Apple Fn key using Apple venter specific Page 0xff01 and usage 0x0003. But you have to change HID Report Descriptor for this, of course.
+Japanese JIS keyboard specific keys like `無変換(Muhenkan)`, `変換(Henkan)`, `ひらがな(hiragana)` are not recognized on OSX. You can use **Seil** to enable those keys, try following options.
+
+* Enable NFER Key on PC keyboard
+* Enable XFER Key on PC keyboard
+* Enable KATAKANA Key on PC keyboard
+
+https://pqrs.org/osx/karabiner/seil.html
+
+
+## RN-42 Bluetooth doesn't work with Karabiner
+Karabiner - Keymapping tool on Mac OSX - ignores inputs from RN-42 module by default. You have to enable this option to make Karabiner working with your keyboard.
+This turns right modifer keys into arrow keys when the keys are tapped while still modifiers when the keys are hold. In TMK the dual-role function is dubbed **TAP**.
+```
+#include "keymap_common.h"
+
+
+/* Arrow keys on right modifier keys with TMK dual role feature
+`EJCT` keycode works on OSX. https://github.com/tmk/tmk_keyboard/issues/250
+It seems Windows 10 ignores the code and Linux/Xorg recognizes but has no mapping by default.
+
+Not sure what keycode Eject is on genuine Apple keyboard actually. HHKB uses `F20` for Eject key(`Fn+f`) on Mac mode but this is not same as Apple Eject keycode probably.
+
+
+
+## What's weak_mods and real_mods in action_util.c
+___TO BE IMPROVED___
+
+real_mods is intended to retains state of real/physical modifier key state, while
+weak_mods retains state of virtual or temprary modifiers which should not affect state real modifier key.
+
+Let's say you hold down physical left shift key and type ACTION_MODS_KEY(LSHIFT, KC_A),
+
+with weak_mods,
+* (1) hold down left shift: real_mods |= MOD_BIT(LSHIFT)
+* Wire (strained for wiring to the Teensy, anything for the rows/columns)
+* Soldering iron set at 600ºF or 315ºC (if temperature-controlled)
+* Resin-cored solder (leaded or lead-free)
+* Adequate ventilation/a fan
+* Tweezers (optional)
+* Wire cutters/snippers
+
+## How the matrix works (why we need diodes)
+
+The microcontroller (in this case, the Teensy 2.0) will be setup up via the firmware to send a logical 1 to the columns, one at a time, and read from the rows, all at once - this process is called matrix scanning. The matrix is a bunch of open switches that, by default, don't allow any current to pass through - the firmware will read this as no keys being pressed. As soon as you press one key down, the logical 1 that was coming from the column the keyswitch is attached to gets passed through the switch and to the corresponding row - check out the following 2x2 example:
+
+ Column 0 being scanned Column 1 being scanned
+ x x
+ col0 col1 col0 col1
+ | | | |
+ row0 ---(key0)---(key1) row0 ---(key0)---(key1)
+ | | | |
+ row1 ---(key2)---(key3) row1 ---(key2)---(key3)
+
+The `x` represents that the column/row associated has a value of 1, or is HIGH. Here, we see that no keys are being pressed, so no rows get an `x`. For one keyswitch, keep in mind that one side of the contacts is connected to its row, and the other, its column.
+
+When we press `key0`, `col0` gets connected to `row0`, so the values that the firmware receives for that row is `0b01` (the `0b` here means that this is a bit value, meaning all of the following digits are bits - 0 or 1 - and represent the keys in that column). We'll use this notation to show when a keyswitch has been pressed, to show that the column and row are being connected:
+
+ Column 0 being scanned Column 1 being scanned
+ x x
+ col0 col1 col0 col1
+ | | | |
+ x row0 ---(-+-0)---(key1) row0 ---(-+-0)---(key1)
+ | | | |
+ row1 ---(key2)---(key3) row1 ---(key2)---(key3)
+
+We can now see that `row0` has an `x`, so has the value of 1. As a whole, the data the firmware receives when `key0` is pressed is
+
+ col0: 0b01
+ col1: 0b00
+ │└row0
+ └row1
+
+A problem arises when you start pressing more than one key at a time. Looking at our matrix again, it should become pretty obvious:
+
+ Column 0 being scanned Column 1 being scanned
+ x x
+ col0 col1 col0 col1
+ | | | |
+ x row0 ---(-+-0)---(-+-1) x row0 ---(-+-0)---(-+-1)
+ | | | |
+ x row1 ---(key2)---(-+-3) x row1 ---(key2)---(-+-3)
+
+ Remember that this ^ is still connected to row1
+
+The data we get from that is:
+
+ col0: 0b11
+ col1: 0b11
+ │└row0
+ └row1
+
+Which isn't accurate, since we only have 3 keys pressed down, not all 4. This behavior is called ghosting, and only happens in odd scenarios like this, but can be much more common on a bigger keyboard. The way we can get around this is by placing a diode after the keyswitch, but before it connects to its row. A diode only allows current to pass through one way, which will protect our other columns/rows from being activated in the previous example. We'll represent a dioded matrix like this;
+
+ Column 0 being scanned Column 1 being scanned
+ x x
+ col0 col1 col0 col1
+ │ │ | │
+ (key0) (key1) (key0) (key1)
+ ! │ ! │ ! | ! │
+ row0 ─────┴────────┘ │ row0 ─────┴────────┘ │
+ │ │ | │
+ (key2) (key3) (key2) (key3)
+ ! ! ! !
+ row1 ─────┴────────┘ row1 ─────┴────────┘
+
+In practical applications, the black line of the diode will be placed facing the row, and away from the keyswitch - the `!` in this case is the diode, where the gap represents the black line. A good way to remember this is to think of this symbol: `>|`
+
+Now when we press the three keys, invoking what would be a ghosting scenario:
+
+ Column 0 being scanned Column 1 being scanned
+ x x
+ col0 col1 col0 col1
+ │ │ │ │
+ (┌─┤0) (┌─┤1) (┌─┤0) (┌─┤1)
+ ! │ ! │ ! │ ! │
+ x row0 ─────┴────────┘ │ x row0 ─────┴────────┘ │
+ │ │ │ │
+ (key2) (┌─┘3) (key2) (┌─┘3)
+ ! ! ! !
+ row1 ─────┴────────┘ x row1 ─────┴────────┘
+
+Things act as they should! Which will get us the following data:
+
+ col0: 0b01
+ col1: 0b11
+ │└row0
+ └row1
+
+The firmware can then use this correct data to detect what it should do, and eventually, what signals it needs to send to the OS.
+
+## The actual hand-wiring
+
+### Getting things in place
+
+When starting this, you should have all of your stabilisers and keyswitches already installed (and optionally keycaps). If you're using a Cherry-type stabiliser (plate-mounted only, obviously), you'll need to install that before your keyswitches. If you're using Costar ones, you can installed them afterwards.
+
+To make things easier on yourself, make sure all of the keyswitches are oriented the same way (if they can be - not all layouts support this). Despite this, it's important to remember that the contacts on the keyswitches are completely symmetrical. We'll be using the keyswitch's left side contact for wiring the rows, and the right side one for wiring the columns.
+
+Get your soldering iron heated-up and collect the rest of the materials from the part list at the beginning of the guide. Place your keyboard so that the bottoms of the keyswitches are accessible - it may be a good idea to place it on a cloth to protect your keyswitches/keycaps.
+
+Before continuing, plan out where you're going to place your Teensy. If you're working with a board that has a large (6.25u) spacebar, it may be a good idea to place it in-between switches against the plate. Otherwise, you may want to trim some of the leads on the keyswitches where you plan on putting it - this will make it a little harder to solder the wire/diodes, but give you more room to place the Teensy.
+
+### Preparing the diodes
+
+It's a little easier to solder the diodes in place if you bend them at a 90º angle immediately after the black line - this will help to make sure you put them on the right way (direction matters), and in the correct position. The diodes will look like this when bent (with longer leads):
+
+ ┌─────┬─┐
+ ───┤ │ ├─┐
+ └─────┴─┘ │
+ │
+
+We'll be using the long lead at the bent end to connect it to the elbow (bent part) of the next diode, creating the row.
+
+### Soldering the diodes
+
+Starting at the top-left switch, place the diode (with tweezers if you have them) on the switch so that the diode itself is vertically aligned, and the black line is facing toward you. The straight end of the diode should be touching the left contact on the switch, and the bent end should be facing to the right and resting on the switch there, like this:
+
+ │o
+ ┌┴┐ o
+ │ │ O
+ ├─┤
+ └┬┘
+ └─────────────
+
+Letting the diode rest, grab your solder, and touch both it and the soldering iron to the left contact at the same time - the rosin in the solder should make it easy for the solder to flow over both the diode and the keyswitch contact. The diode may move a little, and if it does, carefully position it back it place by grabbing the bent end of the diode - the other end will become hot very quickly. If you find that it's moving too much, using needle-nose pliers of some sort may help to keep the diode still when soldering.
+
+The smoke that the rosin releases is harmful, so be careful not to breath it or get it in your eyes/face.
+
+After soldering things in place, it may be helpful to blow on the joint to push the smoke away from your face, and cool the solder quicker. You should see the solder develop a matte (not shiney) surface as it solidifies. Keep in mind that it will still be very hot afterwards, and will take a couple minutes to be cool to touch. Blow on it will accelerate this process.
+
+When the first diode is complete, the next one will need to be soldered to both the keyswitch, and the previous diode at the new elbow. That will look something like this:
+
+ │o │o
+ ┌┴┐ o ┌┴┐ o
+ │ │ O │ │ O
+ ├─┤ ├─┤
+ └┬┘ └┬┘
+ └────────────────┴─────────────
+
+After completing a row, use the wire cutters to trim the excess wire from the tops of the diodes, and from the right side on the final switch. This process will need to completed for each row you have.
+
+When all of the diodes are completely soldered, it's a good idea to quickly inspect each one to ensure that your solder joints are solid and sturdy - repairing things after this is possible, but more difficult.
+
+### Soldering the columns
+
+You'll have some options in the next process - it's a good idea to insulate the column wires (since the diodes aren't), but if you're careful enough, you can use exposed wires for the columns - it's not recommended, though. If you're using single-cored wire, stripping the plastic off of the whole wire and feeding it back on is probably the best option, but can be difficult depending on the size and materials. You'll want to leave parts of the wire exposed where you're going to be solder it onto the keyswitch.
+
+If you're using stranded wire, it's probably easiest to just use a lot of small wires to connect each keyswitch along the column. It's possible to use one and melt through the insulation, but this isn't recommended, will produce even more harmful fumes, and can ruin your soldering iron.
+
+Before beginning to solder, it helps to have your wire pre-bent (if using single-cored), or at least have an idea of how you're going to route the column (especially if you're making a staggered board). Where you go in particular doesn't matter too much, as we'll be basing our keymap definitions on how it was wired - just make sure every key in a particular row is in a unique column, and that they're in order from left to right.
+
+If you're not using any insulation, you can try to keep the column wires elevated, and solder them near the tips of the keyswitch contacts - if the wires are sturdy enough, they won't short out to the row wiring an diodes.
+
+### Wiring things to the Teensy
+
+Now that the matrix itself is complete, it's time to connect what you've done to the Teensy. You'll be needing the number of pins equal to your number of columns + your number of rows. There are some pins on the Teensy that are special, like D6 (the LED on the chip), or some of the UART, SPI, I2C, or PWM channels, but only avoid those if you're planning something in addition to a keyboard. If you're unsure about wanting to add something later, you should have enough pins in total to avoid a couple.
+
+The pins you'll absolutely have to avoid are: GND, VCC, AREF, and RST - all the others are usable and accessible in the firmware.
+
+Place the Teensy where you plan to put it - you'll have to cut wires to length in the next step, and you'll want to make sure they reach.
+
+Starting with the first column on the right side, measure out how much wire you'll need to connect it to the first pin on the Teensy - it helps to pick a side that you'll be able to work down, to keep the wires from overlapping too much. It may help to leave a little bit of slack so things aren't too tight. Cut the piece of wire, and solder it to the Teensy, and then the column - you can solder it anywhere along the column, but it may be easiest at the keyswitch. Just be sure the wire doesn't separate from the keyswitch when soldering.
+
+As you move from column to column, it'll be helpful to write the locations of the pins down. We'll use this data to setup the matrix in the future.
+
+When you're done with the columns, start with the rows in the same process, from top to bottom, and write them all down. Again, you can solder anywhere along the row, as long as it's after the diode - soldering before the diode (on the keyswitch side) will cause that row not to work.
+
+As you move along, be sure that the Teensy is staying in place - recutting and soldering the wires is a pain!
+
+### Getting some basic firmware set-up
+
+From here, you should have a working keyboard with the correct firmware. Before we attach the Teensy permanently to the keyboard, let's quickly get some firmware loaded onto the Teensy so we can test each keyswitch.
+
+To start out, download [the firmware](https://github.com/qmk/qmk_firmware/) - we'll be using my (Jack's) fork of TMK called QMK/Quantum. We'll be doing a lot from the Terminal/command prompt, so get that open, along with a decent text editor like [Sublime Text](http://www.sublimetext.com/).
+
+The first thing we're going to do is create a new project using the script in the root directory of the firmware. In your terminal, run this command with `<project_name>` replaced by the name of your project - it'll need to be different from any other project in the `keyboards/` folder:
+
+ util/new_project.sh <project_name>
+
+You'll want to navigate to the `keyboards/<project_name>/` folder by typing, like the print-out from the script specifies:
+
+ cd keyboards/<project_name>
+
+#### config.h
+
+The first thing you're going to want to modify is the `config.h` file. Find `MATRIX_ROWS` and `MATRIX_COLS` and change their definitions to match the dimensions of your keyboard's matrix.
+
+Farther down are `MATRIX_ROW_PINS` and `MATRIX_COL_PINS`. Change their definitions to match how you wired up your matrix (looking from the top of the keyboard, the rows run top-to-bottom and the columns run left-to-right). Likewise, change the definition of `UNUSED_PINS` to match the pins you did not use (this will save power).
+
+#### \<project_name\>.h
+
+The next file you'll want to look at is `<project_name>.h`. You're going to want to rewrite the `KEYMAP` definition - the format and syntax here is extremely important, so pay attention to how things are setup. The first half of the definition are considered the arguments - this is the format that you'll be following in your keymap later on, so you'll want to have as many k*xy* variables here as you do keys. The second half is the part that the firmware actually looks at, and will contain gaps depending on how you wired your matrix.
+
+We'll dive into how this will work with the following example. Say we have a keyboard like this:
+
+ ┌───┬───┬───┐
+ │ │ │ │
+ ├───┴─┬─┴───┤
+ │ │ │
+ └─────┴─────┘
+
+This can be described by saying the top row is 3 1u keys, and the bottom row is 2 1.5u keys. The difference between the two rows is important, because the bottom row has an unused column spot (3 v 2). Let's say that this is how we wired the columns:
+
+ ┌───┬───┬───┐
+ │ ┋ │ ┋ │ ┋ │
+ ├─┋─┴─┬─┴─┋─┤
+ │ ┋ │ ┋ │
+ └─────┴─────┘
+
+The middle column is unused on the bottom row in this example. Our `KEYMAP` definition would look like this:
+
+ #define KEYMAP( \
+ k00, k01, k02, \
+ k10, k11, \
+ ) \
+ { \
+ { k00, k01, k02 }, \
+ { k10, KC_NO, k11 }, \
+ }
+
+Notice how the top half is spaced to resemble our physical layout - this helps us understand which keys are associated with which columns. The bottom half uses the keycode `KC_NO` where there is no keyswitch wired in. It's easiest to keep the bottom half aligned in a grid to help us make sense of how the firmware actually sees the wiring.
+
+Let's say that instead, we wired our keyboard like this (a fair thing to do):
+
+ ┌───┬───┬───┐
+ │ ┋ │ ┋│ ┋ │
+ ├─┋─┴─┬┋┴───┤
+ │ ┋ │┋ │
+ └─────┴─────┘
+
+This would require our `KEYMAP` definition to look like this:
+
+ #define KEYMAP( \
+ k00, k01, k02, \
+ k10, k11, \
+ ) \
+ { \
+ { k00, k01, k02 }, \
+ { k10, k11, KC_NO }, \
+ }
+
+Notice how the `k11` and `KC_NO` switched places to represent the wiring, and the unused final column on the bottom row. Sometimes it'll make more sense to put a keyswitch on a particular column, but in the end, it won't matter, as long as all of them are accounted for. You can use this process to write out the `KEYMAP` for your entire keyboard - be sure to remember that your keyboard is actually backwards when looking at the underside of it.
+
+#### keymaps/default.c
+
+This is the actual keymap for your keyboard, and the main place you'll make changes as you perfect your layout. `default.c` is the file that gets pull by default when typing `make`, but you can make other files as well, and specify them by typing `make KEYMAP=<variant>`, which will pull `keymaps/<variant>.c`.
+
+The basis of a keymap is its layers - by default, layer 0 is active. You can activate other layers, the highest of which will be referenced first. Let's start with our base layer.
+
+Using our previous example, let's say we want to create the following layout:
+
+ ┌───┬───┬───┐
+ │ A │ 1 │ H │
+ ├───┴─┬─┴───┤
+ │ TAB │ SPC │
+ └─────┴─────┘
+
+This can be accomplished by using the following `keymaps` definition:
+Note that the layout of the keycodes is similar to the physical layout of our keyboard - this make it much easier to see what's going on. A lot of the keycodes should be fairly obvious, but for a full list of them, check out [tmk_code/doc/keycode.txt](https://github.com/qmk/qmk_firmware/blob/master/tmk_core/doc/keycode.txt) - there are also a lot of aliases to condense your keymap file.
+
+It's also important to use the `KEYMAP` function we defined earlier - this is what allows the firmware to associate our intended readable keymap with the actual wiring.
+
+#### Compiling your firmware
+
+After you've written out your entire keymap, you're ready to get the firmware compiled and onto your Teensy. Before compiling, you'll need to get your [development environment set-up](build_guide.md) - you can skip the dfu-programmer instructions, but you'll need to download and install the [Teensy Loader](https://www.pjrc.com/teensy/loader.html) to get the firmware on your Teensy.
+
+Once everything is installed, running `make` in the terminal should get you some output, and eventually a `<project_name>.hex` file in that folder. If you're having trouble with this step, see the end of the guide for the trouble-shooting section.
+
+Once you have your `<project_name>.hex` file, open up the Teensy loader application, and click the file icon. From here, navigate to your `QMK/keyboards/<project_name>/` folder, and select the `<project_name>.hex` file. Plug in your keyboard and press the button on the Teensy - you should see the LED on the device turn off once you do. The Teensy Loader app will change a little, and the buttons should be clickable - click the download button (down arrow), and then the reset button (right arrow), and your keyboard should be ready to go!
+
+#### Testing your firmware
+
+Carefully flip your keyboard over, open up a new text document, and try typing - you should get the characters that you put into your keymap. Test each key, and note the ones that aren't working. Here's a quick trouble-shooting guide for non-working keys:
+
+0. Flip the keyboard back over and short the keyswitch's contacts with a piece wire - this will eliminate the possibility of the keyswitch being bad and needing to be replaced.
+1. Check the solder points on the keyswitch - these need to be plump and whole. If you touch it with a moderate amount of force and it comes apart, it's not strong enough.
+2. Check the solder joints on the diode - if the diode is loose, part of your row may register, while the other may not.
+3. Check the solder joints on the columns - if your column wiring is loose, part or all of the column may not work.
+4. Check the solder joints on both sides of the wires going to/from the Teensy - the wires need to be fully soldered and connect to both sides.
+5. Check the <project_name>.h file for errors and incorrectly placed `KC_NO`s - if you're unsure where they should be, instead duplicate a k*xy* variable.
+6. Check to make sure you actually compiled the firmware and flashed the Teensy correctly. Unless you got error messages in the terminal, or a pop-up during flashing, you probably did everything correctly.
+
+If you've done all of these things, keep in mind that sometimes you might have had multiple things affecting the keyswitch, so it doesn't hurt to test the keyswitch by shorting it out at the end.
+
+#### Securing the Teensy, finishing your hardware, getting fancier firmware
+
+Now that you have a working board, it's time to get things in their permanent positions. I've often used liberal amounts of hot glue to secure and insulate things, so if that's your style, start spreading that stuff like butter. Otherwise, double-sided tape is always an elegant solution, and electrical tape is a distant second. Due to the nature of these builds, a lot of this part is up to you and how you planned (or didn't plan) things out.
+
+There are a lot of possibilities inside the firmware - check out the [readme](https://github.com/qmk/qmk_firmware/blob/master/readme.md) for a full feature list, and dive into the different project (Planck, Ergodox EZ, etc) to see how people use all of them. You can always stop by [the OLKB subreddit for help!](http://reddit.com/r/olkb)
+You have found the QMK Firmware documentation site. This is a keyboard firmware based on the [tmk\_keyboard firmware](http://github.com/tmk/tmk_keyboard) \([view differences](differences_from_tmk.md)\) with some useful features for Atmel AVR controllers, and more specifically, the [OLKB product line](http://olkb.com), the [ErgoDox EZ](http://www.ergodox-ez.com) keyboard, and the [Clueboard product line](http://clueboard.co/). It has also been ported to ARM chips using ChibiOS. You can use it to power your own hand-wired or custom keyboard PCB.
+
+# Getting started
+
+Before you are able to compile, you'll need to install an environment for AVR or ARM development. You'll find the instructions for any OS below. If you find another/better way to set things up from scratch, please consider [making a pull request](https://github.com/qmk/qmk_firmware/pulls) with your changes!
+The QMK Firmware can be configured via the `keymaps` array data. For simply generating a [basic keycode](keycodes.md), you add it as an element of your `keymaps` array data. For more complicated actions, there are more advanced keycodes that are organized carefully to represent common operations, some of which can be found on the [Key Functions](key_functions.md) page.
+
+For more details of the `keymaps` array, see [Keymap Overview](keymap.md) page.
+
+## Space Cadet Shift: The future, built in
+
+Steve Losh [described](http://stevelosh.com/blog/2012/10/a-modern-space-cadet/) the Space Cadet Shift quite well. Essentially, you hit the left Shift on its own, and you get an opening parenthesis; hit the right Shift on its own, and you get the closing one. When hit with other keys, the Shift key keeps working as it always does. Yes, it's as cool as it sounds. Head on over to the [Space Cadet Shift](space_cadet_shift.md) page to read about it.
+
+## The Leader key: A new kind of modifier
+
+Most modifiers have to be held or toggled. But what if you had a key that indicated the start of a sequence? You could press that key and then rapidly press 1-3 more keys to trigger a macro, or enter a special layer, or anything else you might want to do. To learn more about it check out the [Leader Key](leader_key.md) page.
+
+## Tap Dance: A single key can do 3, 5, or 100 different things
+
+Hit the semicolon key once, send a semicolon. Hit it twice, rapidly -- send a colon. Hit it three times, and your keyboard's LEDs do a wild dance. That's just one example of what Tap Dance can do. Read more about it on the [Tap Dance](tap_dance.md) page.
+
+## Temporarily setting the default layer
+
+`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.
+
+## Macro shortcuts: Send a whole string when pressing just one key
+
+How would you like a single keypress to send a whole word, sentence, paragraph, or even document? Head on over to the [Macros](macros.md) page to read up on all aspects of Simple and Dynamic Macros.
+
+## Additional keycode aliases for software-implemented layouts \(Colemak, Dvorak, etc\)
+
+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:
+
+```
+#include <keymap_colemak.h>
+```
+
+If you use Dvorak, use `keymap_dvorak.h` instead of `keymap_colemak.h` for this line. After including this line, you will get access to:
+
+* `CM_*` for all of the Colemak-equivalent characters
+* `DV_*` for all of the Dvorak-equivalent characters
+
+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.
+
+To give an example, if you're using software-implemented Colemak, and want to get an `F`, you would use `CM_F`. Using `KC_F` under these same circumstances would result in `T`.
+
+## Backlight Breathing
+
+In order to enable backlight breathing, the following line must be added to your config.h file.
+
+```
+#define BACKLIGHT_BREATHING
+```
+
+The following function calls are used to control the breathing effect.
+
+* `breathing_enable()` - Enable the free-running breathing effect.
+* `breathing_disable()` - Disable the free-running breathing effect immediately.
+* `breathing_self_disable()` - Disable the free-running breathing effect after the current effect ends.
+* `breathing_toggle()` - Toggle the free-running breathing effect.
+* `breathing_defaults()` - Reset the speed and brightness settings of the breathing effect.
+
+The following function calls are used to control the maximum brightness of the breathing effect.
+
+* `breathing_intensity_set(value)` - Set the brightness of the breathing effect when it is at its max value.
+* `breathing_intensity_default()` - Reset the brightness of the breathing effect to the default value based on the current backlight intensity.
+
+The following function calls are used to control the cycling speed of the breathing effect.
+
+* `breathing_speed_set(value)` - Set the speed of the breathing effect - how fast it cycles.
+* `breathing_speed_inc(value)` - Increase the speed of the breathing effect by a fixed value.
+* `breathing_speed_dec(value)` - Decrease the speed of the breathing effect by a fixed value.
+* `breathing_speed_default()` - Reset the speed of the breathing effect to the default value.
+
+The following example shows how to enable the backlight breathing effect when the FUNCTION layer macro button is pressed:
+
+```
+case MACRO_FUNCTION:
+ if (record->event.pressed)
+ {
+ breathing_speed_set(3);
+ breathing_enable();
+ layer_on(LAYER_FUNCTION);
+ }
+ else
+ {
+ breathing_speed_set(1);
+ breathing_self_disable();
+ layer_off(LAYER_FUNCTION);
+ }
+ break;
+```
+
+The following example shows how to pulse the backlight on-off-on when the RAISED layer macro button is pressed:
+Your keymap can include shortcuts to common operations (called "function actions" in tmk).
+
+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](keymap.md#2-action).
+
+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.
+
+### Switching and toggling layers
+
+`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.
+
+`OSL(layer)` - momentary switch to *layer*, as a one-shot operation. So if you have a key that's defined as `OSL(1)`, and you tap that key, then only the very next keystroke would come from layer 1. You would drop back to layer zero immediately after that one keystroke. That's handy if you have a layer full of custom shortcuts -- for example, a dedicated key for closing a window. So you tap your one-shot layer mod, then tap that magic 'close window' key, and keep typing like a boss. Layer 1 would remain active as long as you hold that key down, too (so you can use it like a momentary toggle-layer key with extra powers).
+
+`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).
+
+`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.
+
+`TO(layer)` - Goes to a layer. This code is special, because it lets you go either up or down the stack -- just goes directly to the layer you want. So while other codes only let you go _up_ the stack (from layer 0 to layer 3, for example), `TO(2)` is going to get you to layer 2, no matter where you activate it from -- even if you're currently on layer 5. This gets activated on keydown (as soon as the key is pressed).
+
+`TT(layer)` - Layer Tap-Toggle. If you hold the key down, the layer becomes active, and then deactivates when you let go. And if you tap it, the layer simply becomes active (toggles on). It needs 5 taps by default, but you can set it by defining `TAPPING_TOGGLE`, for example, `#define TAPPING_TOGGLE 1` for just one tap.
+
+
+### Fun with modifier keys
+
+* `LSFT(kc)` - applies left Shift to *kc* (keycode) - `S(kc)` is an alias
+* `RSFT(kc)` - applies right Shift to *kc*
+* `LCTL(kc)` - applies left Control to *kc*
+* `RCTL(kc)` - applies right Control to *kc*
+* `LALT(kc)` - applies left Alt to *kc*
+* `RALT(kc)` - applies right Alt to *kc*
+* `LGUI(kc)` - applies left GUI (command/win) to *kc*
+* `RGUI(kc)` - applies right GUI (command/win) to *kc*
+* `HYPR(kc)` - applies Hyper (all modifiers) to *kc*
+ LALT(LCTL(KC_DEL)) -- this makes a key that sends Alt, Control, and Delete in a single keypress.
+
+The following shortcuts automatically add `LSFT()` to keycodes to get commonly used symbols. Their long names are also available and documented in `quantum/quantum_keycodes.h`.
+
+ KC_TILD ~
+ KC_EXLM !
+ KC_QUES ?
+ KC_AT @
+ KC_HASH #
+ KC_DLR $
+ KC_PERC %
+ KC_CIRC ^
+ KC_AMPR &
+ KC_ASTR *
+ KC_LPRN (
+ KC_RPRN )
+ KC_UNDS _
+ KC_PLUS +
+ KC_DQUO "
+ KC_LCBR {
+ KC_RCBR }
+ KC_LABK <
+ KC_RABK >
+ KC_PIPE |
+ KC_COLN :
+
+`OSM(mod)` - this is a "one shot" modifier. So let's say you have your left Shift key defined as `OSM(MOD_LSFT)`. Tap it, let go, and Shift is "on" -- but only for the next character you'll type. So to write "The", you don't need to hold down Shift -- you tap it, tap t, and move on with life. And if you hold down the left Shift key, it just works as a left Shift key, as you would expect (so you could type THE). There's also a magical, secret way to "lock" a modifier by tapping it multiple times. If you want to learn more about that, open an issue. :)
+
+`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.
+
+These are the values you can use for the `mod` in `MT()` and `OSM()`:
+
+ * MOD_LCTL
+ * MOD_LSFT
+ * MOD_LALT
+ * MOD_LGUI
+ * MOD_RCTL
+ * MOD_RSFT
+ * MOD_RALT
+ * MOD_RGUI
+ * MOD_HYPR
+ * MOD_MEH
+
+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. Note however, that you cannot mix right and left side modifiers.
+
+We've added shortcuts to make common modifier/tap (mod-tap) mappings more compact:
+
+ * `CTL_T(kc)` - is LCTL when held and *kc* when tapped
+ * `SFT_T(kc)` - is LSFT when held and *kc* when tapped
+ * `ALT_T(kc)` - is LALT when held and *kc* when tapped
+ * `ALGR_T(kc)` - is AltGr when held and *kc* when tapped
+ * `GUI_T(kc)` - is LGUI when held and *kc* when tapped
+ * `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/)
+ * `LCAG_T(kc)` - is CtrlAltGui when held and *kc* when tapped
+ * `MEH_T(kc)` - is like Hyper, but not as cool -- does not include the Cmd/Win key, so just sends Alt+Ctrl+Shift.
+
+##### Permissive Hold
+
+As of [PR#1359](https://github.com/qmk/qmk_firmware/pull/1359/), there is a new `config.h` option:
+
+```
+#define PERMISSIVE_HOLD
+```
+
+This makes it easier for fast typists to use dual-function keys. As described in the PR:
+
+Without this, if you let go of a held key inside the tapping term, it won't register.
+
+Example: (Tapping Term = 200)
+
+- SHFT_T(KC_A) Down
+- KC_X Down
+- KC_X Up
+- SHFT_T(KC_A) Up
+
+With permissive hold, if above is typed within tapping term, this will emit `X` (so, Shift+X).
+
+With defaults, if above is typed within tapping term, this will emit `ax`, which I doubt is what anyone really wants
+When defining a [keymap](keymap.md) each key needs a valid key definition.
+
+This page documents the symbols that correspond to keycodes that are available to you in QMK.
+
+To customize your board, they can be used by themselves or as **action codes** in combination with one of the [many C macros](https://github.com/qmk/qmk_firmware/wiki#c-macros-for-action-code).
+
+The source of truth for these codes is [tmk_core/common/keycode.h](https://github.com/qmk/qmk_firmware/blob/master/tmk_core/common/keycode.h) file in the qmk source code.
+
+# The Keycodes
+
+Keycodes in QMK are based on [HID Usage Keyboard/Keypad Page(0x07)](http://www.usb.org/developers/hidpage/Hut1_12v2.pdf) with following exceptions:
+
+* `KC_NO` = 0 for no action
+* `KC_TRNS` = 1 for layer transparency
+* internal special keycodes in the `0xA5-DF` range (tmk heritage).
+The following keys can be used to turn on and off various "Magic" features. These include Boot Magic (holding certain keys down while plugging the keyboard in) and the Magic Key.
+
+|Long Name|Short Name|Description|
+|---------|----------|-----------|
+|MAGIC_SWAP_CONTROL_CAPSLOCK||Swap Capslock and Control|
+|MAGIC_CAPSLOCK_TO_CONTROL||Change Capslock to Control|
+|MAGIC_SWAP_ALT_GUI||Swap ALT and GUI|
+|MAGIC_SWAP_LALT_LGUI||Swap LALT and LGUI|
+|MAGIC_SWAP_RALT_RGUI||Swap RALT and RGUI|
+|MAGIC_NO_GUI||Disable off the GUI key|
+|MAGIC_SWAP_GRAVE_ESC||Swap the GRAVE (~ `) and Esc keys|
+|MAGIC_SWAP_BACKSLASH_BACKSPACE||Swap Backslash and Backspace|
+|MAGIC_UNSWAP_CONTROL_CAPSLOCK||Disable the Control/Caps Swap|
+|MAGIC_UNCAPSLOCK_TO_CONTROL||Turn Capslock back into Capslock|
+|MAGIC_UNSWAP_ALT_GUI||Turn the ALT/GUI swap off|
+|MAGIC_UNSWAP_LALT_LGUI||Turn the LALT/LGUI swap off|
+|MAGIC_UNSWAP_RALT_RGUI||Turn the RALT/RGUI swap off|
+|MAGIC_UNNO_GUI||Enable the GUI key|
+|MAGIC_UNSWAP_GRAVE_ESC||Turn the GRAVE/ESC swap off|
+|MAGIC_UNSWAP_BACKSLASH_BACKSPACE||Turn the Backslash/Backspace swap off|
+QMK keymaps are defined inside a C source file. The data structure is an array of arrays. The outer array is a list of layer arrays while the inner layer array is a list of keys. Most keyboards define a `KEYMAP()` macro to help you create this array of arrays.
+
+
+## Keymap and layers
+In QMK, **`const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS]`** holds multiple **layers** of keymap information in **16 bit** data holding the **action code**. You can define **32 layers** at most.
+
+For trivial key definitions, the higher 8 bits of the **action code** are all 0 and the lower 8 bits holds the USB HID usage code generated by the key as **keycode**.
+
+Respective layers can be validated simultaneously. Layers are indexed with 0 to 31 and higher layer has precedence.
+
+ Keymap: 32 Layers Layer: action code matrix
+ ----------------- ---------------------
+ stack of layers array_of_action_code[row][column]
+ 0 /___________/ V low 0 `--------------------------
+
+
+Sometimes, the action code stored in keymap may be referred as keycode in some documents due to the TMK history.
+
+### Keymap layer status
+Keymap layer has its state in two 32 bit parameters:
+
+* **`default_layer_state`** indicates a base keymap layer(0-31) which is always valid and to be referred.
+* **`layer_state`** () has current on/off status of the layer on its each bit.
+
+Keymap has its state in two parameter **`default_layer`** indicates a base keymap layer(0-31) which is always valid and to be referred, **`keymap_stat`** is 16bit variable which has current on/off status of layers on its each bit.
+Keymap layer '0' is usually `default_layer` and which is the only valid layer and other layers is initially off after boot up firmware, though, you can configured them in `config.h`.
+To change `default_layer` will be useful when you switch key layout completely, say you want Colmak instead of Qwerty.
+On the other hand, you shall change `layer_state` to overlay base layer with some layers for feature such as navigation keys, function key(F1-F12), media keys or special actions.
+
+ Overlay feature layer
+ --------------------- bit|status
+ ____________ ---+------
+ 31 / / 31 | 0
+ 30 /___________// -----> 30 | 1
+ 29 /___________/ -----> 29 | 1
+ : : | :
+ : ____________ : | :
+ 2 / / 2 | 0
+ ,->1 /___________/ -----> 1 | 1
+ | 0 0 | 0
+ | +
+ `--- default_layer = 1 |
+ layer_state = 0x60000002 <-'
+
+
+
+### Layer Precedence and Transparency
+Note that ***higher layer has higher priority on stack of layers***, namely firmware falls down from top layer to bottom to look up keycode. Once it spots keycode other than **`KC_TRNS`**(transparent) on a layer it stops searching and lower layers aren't referred.
+
+You can place `KC_TRANS` on overlay layer changes just part of layout to fall back on lower or base layer.
+Key with `KC_TRANS` (`KC_TRNS` and `_______` are the alias) doesn't has its own keycode and refers to lower valid layers for keycode, instead.
+
+## Anatomy Of A `keymap.c`
+
+For this example we will walk through the [default Clueboard keymap](https://github.com/qmk/qmk_firmware/blob/master/keyboards/clueboard/keymaps/default/keymap.c). You'll find it helpful to open that file in another browser window so you can look at everything in context.
+
+There are 3 main sections of a `keymap.c` file you'll want to concern yourself with:
+ // The underscores don't mean anything - you can
+ // have a layer called STUFF or any other name.
+ // Layer names don't all need to be of the same
+ // length, and you can also skip them entirely
+ // and just use numbers.
+ #define _BL 0
+ #define _FL 1
+ #define _CL 2
+
+These are some handy definitions we can use when building our keymap and our custom function. The `GRAVE_MODS` definition will be used later in our custom function. The `_______` define makes it easier to see what keys a layer is overriding, while the `_BL`, `_FL`, and `_CL` defines make it easier to refer to each of our layers.
+
+### Layers and Keymaps
+
+The main part of this file is the `keymaps[]` definition. This is where you list your layers and the contents of those layers. This part of the file begins with this definition:
+After this you'll find a list of KEYMAP() macros. A KEYMAP() is simply a list of keys to define a single layer. Typically you'll have one or more "base layers" (such as QWERTY, Dvorak, or Colemak) and then you'll layer on top of that one or more "function" layers. Due to the way layers are processed you can't overlay a "lower" layer on top of a "higher" layer.
+
+`keymaps[][MATRIX_ROWS][MATRIX_COLS]` in QMK holds the 16 bit action code (sometimes referred as the quantum keycode) in it. For the keycode representing typical keys, its high byte is 0 and its low byte is the USB HID usage ID for keyboard.
+
+> TMK from which QMK was forked uses `const uint8_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS]` instead and holds the 8 bit keycode. Some keycode values are reserved to induce execution of certain action codes via the `fn_actions[]` array.
+
+#### Base Layer
+
+Here is an example of the Clueboard's base layer:
+* From a C source point of view it's only a single array, but we have embedded whitespace to more easily visualize where each key is on the physical device.
+* Plain keyboard scancodes are prefixed with KC_, while "special" keys are not.
+* The upper left key activates custom function 0 (`F(0)`)
+* The "Fn" key is defined with `MO(_FL)`, which moves to the `_FL` layer while that key is being held down.
+
+#### Function Overlay Layer
+
+Our function layer is, from a code point of view, no different from the base layer. Conceptually, however, you will build that layer as an overlay, not a replacement. For many people this distinction does not matter, but as you build more complicated layering setups it matters more and more.
+* We have used our `_______` definition to turn `KC_TRNS` into `_______`. This makes it easier to spot the keys that have changed on this layer.
+* While in this layer if you press one of the `_______` keys it will activate the key in the next lowest active layer.
+
+### Custom Functions
+
+At the bottom of the file we've defined a single custom function. This function defines a key that sends `KC_ESC` when pressed without modifiers and `KC_GRAVE` when modifiers are held. There are a couple pieces that need to be in place for this to work, and we will go over both of them.
+
+#### `fn_actions[]`
+
+We define the `fn_actions[]` array to point to custom functions. `F(N)` in a keymap will call element N of that array. For the Clueboard's that looks like this:
+In this case we've instructed QMK to call the `ACTION_FUNCTION` callback, which we will define in the next section.
+
+> This `fn_actions[]` interface is mostly for backward compatibility. In QMK, you don't need to use `fn_actions[]`. You can directly use `ACTION_FUNCTION(N)` or any other action code value itself normally generated by the macro in `keymaps[][MATRIX_ROWS][MATRIX_COLS]`. N in `F(N)` can only be 0 to 31. Use of the action code directly in `keymaps` unlocks this limitation.
+
+#### `action_function()`
+
+To actually handle the keypress event we define an `action_function()`. This function will be called when the key is pressed, and then again when the key is released. We have to handle both situations within our code, as well as determining whether to send/release `KC_ESC` or `KC_GRAVE`.
+We are actively working to improve these docs. If you have suggestions for how they could be made better please [file an issue](https://github.com/qmk/qmk_firmware/issues/new)!
+If you've ever used Vim, you know what a Leader key is. If not, you're about to discover a wonderful concept. :) Instead of hitting Alt+Shift+W for example (holding down three keys at the same time), what if you could hit a _sequence_ of keys instead? So you'd hit our special modifier (the Leader key), followed by W and then C (just a rapid succession of keys), and something would happen.
+
+That's what `KC_LEAD` does. Here's an example:
+
+1. Pick a key on your keyboard you want to use as the Leader key. Assign it the keycode `KC_LEAD`. This key would be dedicated just for this -- it's a single action key, can't be used for anything else.
+2. Include the line `#define LEADER_TIMEOUT 300` somewhere in your keymap.c file, probably near the top. The 300 there is 300ms -- that's how long you have for the sequence of keys following the leader. You can tweak this value for comfort, of course.
+3. Within your `matrix_scan_user` function, do something like this:
+
+```
+LEADER_EXTERNS();
+
+void matrix_scan_user(void) {
+ LEADER_DICTIONARY() {
+ leading = false;
+ leader_end();
+
+ SEQ_ONE_KEY(KC_F) {
+ register_code(KC_S);
+ unregister_code(KC_S);
+ }
+ SEQ_TWO_KEYS(KC_A, KC_S) {
+ register_code(KC_H);
+ unregister_code(KC_H);
+ }
+ SEQ_THREE_KEYS(KC_A, KC_S, KC_D) {
+ register_code(KC_LGUI);
+ register_code(KC_S);
+ unregister_code(KC_S);
+ unregister_code(KC_LGUI);
+ }
+ }
+}
+```
+
+As you can see, you have three function. you can use - `SEQ_ONE_KEY` for single-key sequences (Leader followed by just one key), and `SEQ_TWO_KEYS` and `SEQ_THREE_KEYS` for longer sequences. Each of these accepts one or more keycodes as arguments. This is an important point: You can use keycodes from **any layer on your keyboard**. That layer would need to be active for the leader macro to fire, obviously.
+As raised in #1038 and other issues, the licensing status of QMK is not clear. In an effort to remove ambiguity and to clarify the licensing status of the quantum code we are identifying the providence of our source code files and clarifying what license applies to each one.
+
+# Signoff
+
+This section documents the people who need to sign off on applying the GPL to one or more of their contributions. If your name appears below and you consent to applying the GPL to your contributions, please put today's date in the last field of your row. Please stick to the following date format: 2017 Jan 28
+
+Username | Files | Sign Off Date |
+---------|-------|---------------|
+@0xdec | quantum/rgblight.c | 2017 Jan 29 |
+@algernon | quantum/quantum.c<br>quantum/quantum.h<br>quantum/process_keycode/process_tap_dance.c<br>quantum/process_keycode/process_tap_dance.h<br>quantum/process_keycode/process_unicode.c<br>quantum/process_keycode/process_unicode.h | 2017 Jan 29 |
+@cdlm | quantum/template/template.c<br>quantum/template/template.h | 2017 Feb 03 |
+@DidierLoiseau | quantum/keymap_extras/keymap_canadian_multilingual.h<br>quantum/keymap_extras/keymap_bepo.h |2017 Jan 29 |
+@eltang | quantum/config_common.h<br>quantum/matrix.c<br>quantum/quantum.c<br>quantum/quantum.h<br>quantum/rgblight.c<br>quantum/rgblight.h<br>quantum/template/config.h | 2017 Feb 28 |
+@ezuk | quantum/matrix.c<br>quantum/quantum.c<br>quantum/quantum.h<br>quantum/quantum_keycodes.h<br>quantum/rgblight.c<br>quantum/rgblight.h<br>quantum/keymap_extras/keymap_colemak.h<br>quantum/keymap_extras/keymap_nordic.h | 2017 Jan 31 |
+@fredizzimo | quantum/config_common.h<br>quantum/keycode_config.h<br>quantum/keymap.h<br>quantum/keymap_common.c<br>quantum/keymap_common.c<br>quantum/matrix.c<br>quantum/quantum.h<br>quantum/rgblight.c<br>quantum/rgblight.h<br>quantum/api/api_sysex.c | 2017 Jan 29 |
+@h-youhei | quantum/keymap_extras/keymap_jp.h | 2017 Jan 28 |
+@heartsekai | quantum/keymap_extras/keymap_german_ch.h | 2017 Jan 29 |
+@IBnobody | quantum/keycode_config.h<br>quantum/matrix.c<br>quantum/quantum.c<br>quantum/audio/audio.c<br>quantum/audio/audio.h<br>quantum/audio/audio_pwm.c<br>quantum/audio/audio_pwm.c<br>quantum/audio/voices.c<br>quantum/audio/voices.h<br>quantum/template/config.h<br>quantum/template/template.c | 2017 Jan 30 |
+Each file listed below has more than one author and needs to have copyright resolved. The number of lines contributed by each author is shown as determined by:
+# Macros - Send multiple keystrokes when pressing just one key
+
+QMK has a number of ways to define and use macros. These can do anything you want- type common phrases for you, copypasta, repetitive game movements, or even help you code.
+
+**Security Note**: While it is possible to use macros to send passwords, credit card numbers, and other sensitive information it is a supremely bad idea to do so. Anyone who gets ahold of your keyboard will be able to access that information by opening a text editor.
+
+# Macro Definitions
+
+By default QMK assumes you don't have any macros. To define your macros you create an `action_get_macro()` function. For example:
+This defines two macros which will be run when the key they are assigned to is pressed. If you'd like them to run when the release is released instead you can change the if statement:
+
+```c
+ if (!record->event.pressed) {
+```
+
+## Macro Commands
+
+A macro can include the following commands:
+
+* I() change interval of stroke in milliseconds.
+* D() press key.
+* U() release key.
+* T() type key(press and release).
+* W() wait (milliseconds).
+* END end mark.
+
+## Sending strings
+
+Sometimes you just want a key to type out words or phrases. For the most common situations we've provided `SEND_STRING()`, which will type out your string for you instead of having to build a `MACRO()`. Right now it assumes a US keymap with a QWERTY layout, so if you are using something else it may not behave as you expect.
+When you press the key on the left it will type "Hi!" and when you press the key on the right it will type "Bye!".
+
+## Naming your macros
+
+If you have a bunch of macros you want to refer to from your keymap while keeping the keymap easily readable you can name them using `#define` at the top of your file.
+While working within the `action_get_macro()` function block there are some functions you may find useful. Keep in mind that while you can write some fairly advanced code within a macro if your functionality gets too complex you may want to define a custom keycode instead. Macros are meant to be simple.
+
+#### `record->event.pressed`
+
+This is a boolean value that can be tested to see if the switch is being pressed or released. An example of this is
+
+```c
+ if (record->event.pressed) {
+ // on keydown
+ } else {
+ // on keyup
+ }
+```
+
+#### `register_code(<kc>);`
+
+This sends the `<kc>` keydown event to the computer. Some examples would be `KC_ESC`, `KC_C`, `KC_4`, and even modifiers such as `KC_LSFT` and `KC_LGUI`.
+
+#### `unregister_code(<kc>);`
+
+Parallel to `register_code` function, this sends the `<kc>` keyup event to the computer. If you don't use this, the key will be held down until it's sent.
+
+#### `clear_keyboard();`
+
+This will clear all mods and keys currently pressed.
+
+#### `clear_mods();`
+
+This will clear all mods currently pressed.
+
+#### `clear_keyboard_but_mods();`
+
+This will clear all keys besides the mods currently pressed.
+
+# Advanced Example: Single-key copy/paste (hold to copy, tap to paste)
+
+This example defines a macro which sends `Ctrl-C` when pressed down, and `Ctrl-V` when released.
+The full syntax of the `make` command is the following, but parts of the command can be left out if you run it from other directories than the `root` (as you might already have noticed by reading the simple instructions).
+* `<keyboard>` is the name of the keyboard, for example `planck`
+ * Use `allkb` to compile all keyboards
+* `<subproject>` is the name of the subproject (revision or sub-model of the keyboard). For example, for Ergodox it can be `ez` or `infinity`, and for Planck `rev3` or `rev4`.
+ * If the keyboard doesn't have any subprojects, it can be left out
+ * To compile the default subproject, you can leave it out, or specify `defaultsp`
+ * Use `allsp` to compile all subprojects
+* `<keymap>` is the name of the keymap, for example `algernon`
+ * Use `allkm` to compile all keymaps
+* `<target>` will be explained in more detail below.
+
+**Note:** When you leave some parts of the command out, you should also remove the dash (`-`).
+
+As mentioned above, there are some shortcuts, when you are in a:
+
+* `keyboard` folder, the command will automatically fill the `<keyboard>` part. So you only need to type `<subproject>-<keymap>-<target>`
+* `subproject` folder, it will fill in both `<keyboard>` and `<subproject>`
+* `keymap` folder, then `<keyboard>` and `<keymap>` will be filled in. If you need to specify the `<subproject>` use the following syntax `<subproject>-<target>`
+ * Note in order to support this shortcut, the keymap needs its own Makefile (see the example [here](https://github.com/qmk/qmk_firmware/blob/master/doc/keymap_makefile_example.mk))
+* `keymap` folder of a `subproject`, then everything except the `<target>` will be filled in
+
+The `<target>` means the following
+* If no target is given, then it's the same as `all` below
+* `all` compiles the keyboard and generates a `<keyboard>_<keymap>.hex` file in whichever folder you run `make` from. These files are ignored by git, so don't worry about deleting them when committing/creating pull requests.
+* `dfu`, `teensy` or `dfu-util`, compile and upload the firmware to the keyboard. If the compilation fails, then nothing will be uploaded. The programmer to use depends on the keyboard. For most keyboards it's `dfu`, but for Infinity keyboards you should use `dfu-util`, and `teensy` for standard Teensys. To find out which command you should use for your keyboard, check the keyboard specific readme. **Note** that some operating systems needs root access for these commands to work, so in that case you need to run for example `sudo make dfu`.
+* `clean`, cleans the build output folders to make sure that everything is built from scratch. Run this before normal compilation if you have some unexplainable problems.
+
+Some other targets are supported but, but not important enough to be documented here. Check the source code of the make files for more information.
+
+You can also add extra options at the end of the make command line, after the target
+
+* `make COLOR=false` - turns off color output
+* `make SILENT=true` - turns off output besides errors/warnings
+* `make VERBOSE=true` - outputs all of the gcc stuff (not interesting, unless you need to debug)
+* `make EXTRAFLAGS=-E` - Preprocess the code without doing any compiling (useful if you are trying to debug #define commands)
+
+The make command itself also has some additional options, type `make --help` for more information. The most useful is probably `-jx`, which specifies that you want to compile using more than one CPU, the `x` represents the number of CPUs that you want to use. Setting that can greatly reduce the compile times, especially if you are compiling many keyboards/keymaps. I usually set it to one less than the number of CPUs that I have, so that I have some left for doing other things while it's compiling. Note that not all operating systems and make versions supports that option.
+
+Here are some examples commands
+
+* `make allkb-allsp-allkm` builds everything (all keyboards, all subprojects, all keymaps). Running just `make` from the `root` will also run this.
+* `make` from within a `keyboard` directory, is the same as `make keyboard-allsp-allkm`, which compiles all subprojects and keymaps of the keyboard. **NOTE** that this behaviour has changed. Previously it compiled just the default keymap.
+* `make ergodox-infinity-algernon-clean` will clean the build output of the Ergodox Infinity keyboard. This example uses the full syntax and can be run from any folder with a `Makefile`
+* `make dfu COLOR=false` from within a keymap folder, builds and uploads the keymap, but without color output.
+
+## The `Makefile`
+
+There are 5 different `make` and `Makefile` locations:
+The root contains the code used to automatically figure out which keymap or keymaps to compile based on your current directory and commandline arguments. It's considered stable, and shouldn't be modified. The keyboard one will contain the MCU set-up and default settings for your keyboard, and shouldn't be modified unless you are the producer of that keyboard. The keymap Makefile can be modified by users, and is optional. It is included automatically if it exists. You can see an example [here](https://github.com/qmk/qmk_firmware/blob/master/doc/keymap_makefile_example.mk) - the last few lines are the most important. The settings you set here will override any defaults set in the keyboard Makefile. **The file is required if you want to run `make` in the keymap folder.**
+
+For keyboards and subprojects, the make files are split in two parts `Makefile` and `rules.mk`. All settings can be found in the `rules.mk` file, while the `Makefile` is just there for support and including the root `Makefile`. Keymaps contain just one `Makefile` for simplicity.
+
+### Makefile options
+
+Set these variables to `no` to disable them, and `yes` to enable them.
+
+`BOOTMAGIC_ENABLE`
+
+This allows you to hold a key and the salt key (space by default) and have access to a various EEPROM settings that persist over power loss. It's advised you keep this disabled, as the settings are often changed by accident, and produce confusing results that makes it difficult to debug. It's one of the more common problems encountered in help sessions.
+
+Consumes about 1000 bytes.
+
+`MOUSEKEY_ENABLE`
+
+This gives you control over cursor movements and clicks via keycodes/custom functions.
+
+`EXTRAKEY_ENABLE`
+
+This allows you to use the system and audio control key codes.
+
+`CONSOLE_ENABLE`
+
+This allows you to print messages that can be read using [`hid_listen`](https://www.pjrc.com/teensy/hid_listen.html).
+
+By default, all debug (*dprint*) print (*print*, *xprintf*), and user print (*uprint*) messages will be enabled. This will eat up a significant portion of the flash and may make the keyboard .hex file too big to program.
+
+To disable debug messages (*dprint*) and reduce the .hex file size, include `#define NO_DEBUG` in your `config.h` file.
+
+To disable print messages (*print*, *xprintf*) and user print messages (*uprint*) and reduce the .hex file size, include `#define NO_PRINT` in your `config.h` file.
+
+To disable print messages (*print*, *xprintf*) and **KEEP** user print messages (*uprint*), include `#define USER_PRINT` in your `config.h` file.
+
+To see the text, open `hid_listen` and enjoy looking at your printed messages.
+
+**NOTE:** Do not include *uprint* messages in anything other than your keymap code. It must not be used within the QMK system framework. Otherwise, you will bloat other people's .hex files.
+
+Consumes about 400 bytes.
+
+`COMMAND_ENABLE`
+
+This enables magic commands, typically fired with the default magic key combo `LSHIFT+RSHIFT+KEY`. Magic commands include turning on debugging messages (`MAGIC+D`) or temporarily toggling NKRO (`MAGIC+N`).
+
+`SLEEP_LED_ENABLE`
+
+Enables your LED to breath while your computer is sleeping. Timer1 is being used here. This feature is largely unused and untested, and needs updating/abstracting.
+
+`NKRO_ENABLE`
+
+This allows the keyboard to tell the host OS that up to 248 keys are held down at once (default without NKRO is 6). NKRO is off by default, even if `NKRO_ENABLE` is set. NKRO can be forced by adding `#define FORCE_NKRO` to your config.h or by binding `MAGIC_TOGGLE_NKRO` to a key and then hitting the key.
+
+`BACKLIGHT_ENABLE`
+
+This enables your backlight on Timer1 and ports B5, B6, or B7 (for now). You can specify your port by putting this in your `config.h`:
+
+ #define BACKLIGHT_PIN B7
+
+`MIDI_ENABLE`
+
+This enables MIDI sending and receiving with your keyboard. To enter MIDI send mode, you can use the keycode `MI_ON`, and `MI_OFF` to turn it off. This is a largely untested feature, but more information can be found in the `quantum/quantum.c` file.
+
+`UNICODE_ENABLE`
+
+This allows you to send unicode symbols via `UC(<unicode>)` in your keymap. Only codes up to 0x7FFF are currently supported.
+
+`UNICODEMAP_ENABLE`
+
+This allows sending unicode symbols using `X(<unicode>)` in your keymap. Codes
+up to 0xFFFFFFFF are supported, including emojis. You will need to maintain
+a separate mapping table in your keymap file.
+
+Known limitations:
+- Under Mac OS, only codes up to 0xFFFF are supported.
+- Under Linux ibus, only codes up to 0xFFFFF are supported (but anything important is still under this limit for now).
+
+Characters out of range supported by the OS will be ignored.
+
+`BLUETOOTH_ENABLE`
+
+This allows you to interface with a Bluefruit EZ-key to send keycodes wirelessly. It uses the D2 and D3 pins.
+
+`AUDIO_ENABLE`
+
+This allows you output audio on the C6 pin (needs abstracting). See the [audio section](#audio-output-from-a-speaker) for more information.
+
+`FAUXCLICKY_ENABLE`
+
+Uses buzzer to emulate clicky switches. A cheap imitation of the Cherry blue switches. By default, uses the C6 pin, same as AUDIO_ENABLE.
+
+`VARIABLE_TRACE`
+
+Use this to debug changes to variable values, see the [tracing variables](#tracing-variables) section for more information.
+
+`API_SYSEX_ENABLE`
+
+This enables using the Quantum SYSEX API to send strings (somewhere?)
+
+This consumes about 5390 bytes.
+
+### Customizing Makefile options on a per-keymap basis
+
+If your keymap directory has a file called `Makefile` (note the filename), any Makefile options you set in that file will take precedence over other Makefile options for your particular keyboard.
+
+So let's say your keyboard's makefile has `BACKLIGHT_ENABLE = yes` (or maybe doesn't even list the `BACKLIGHT_ENABLE` option, which would cause it to be off). You want your particular keymap to not have the debug console, so you make a file called `Makefile` and specify `BACKLIGHT_ENABLE = no`.
+
+You can use the `docs/keymap_makefile_example.md` as a template/starting point.
+In rare circumstances, your keyboard/device can become unwritable, and `dfu-programmer` will give you an error like this:
+
+ Erasing flash... Success
+ Checking memory from 0x0 to 0x6FFF... Empty.
+ Checking memory from 0x0 to 0x607F... Empty.
+ 0% 100% Programming 0x6080 bytes...
+ [ X ERROR
+ Memory write error, use debug for more info.
+
+Currently the only way to solve this is to [reprogram the chip via ISP](https://www.reddit.com/r/olkb/comments/4rjzen/flashing_error_on_mac_os_x/d52rj8o/). This requires another device to be hooked up to a couple of exposed pins on the PCB. There is a guide on how to do this [here](https://learn.sparkfun.com/tutorials/installing-an-arduino-bootloader), and [this is where things are on the Planck PCB](http://imgur.com/lvbxbHt).
+
+An example command to flash the board once things are hooked up is:
+Research is still being done on why this happens, but here are some cases:
+
+* [`make -f Makefile.rn42 dfu` and not the dfu-programmer commands worked for @tybenz](https://github.com/tmk/tmk_keyboard/issues/316) - also see [the hhkb keyboard on tmk](https://github.com/tmk/tmk_keyboard/tree/master/keyboard/hhkb)
+* [Doing a force erase works here](https://geekhack.org/index.php?topic=12047.msg1520147#msg1520147)
+* [`dfu-programmer atmega32u4 erase --force` works here as well](https://forum.fhem.de/index.php?topic=29777.0) [DE]
+* [Unresolved, but some data dumps](https://github.com/dfu-programmer/dfu-programmer/issues/29)
+Your keyboard can make sounds! If you've got a Planck, Preonic, or basically any keyboard that allows access to the C6 port, you can hook up a simple speaker and make it beep. You can use those beeps to indicate layer transitions, modifiers, special keys, or just to play some funky 8bit tunes.
+
+The audio code lives in [quantum/audio/audio.h](https://github.com/qmk/qmk_firmware/blob/master/quantum/audio/audio.h) and in the other files in the audio directory. It's enabled by default on the Planck [stock keymap](https://github.com/qmk/qmk_firmware/blob/master/keyboards/planck/keymaps/default/keymap.c). Here are the important bits:
+
+```
+#include "audio.h"
+```
+
+Then, lower down the file:
+
+```
+float tone_startup[][2] = {
+ ED_NOTE(_E7 ),
+ E__NOTE(_CS7),
+ E__NOTE(_E6 ),
+ E__NOTE(_A6 ),
+ M__NOTE(_CS7, 20)
+};
+```
+
+This is how you write a song. Each of these lines is a note, so we have a little ditty composed of five notes here.
+Wherein we bind predefined songs (from [quantum/audio/song_list.h](https://github.com/qmk/qmk_firmware/blob/master/quantum/audio/song_list.h)) into named variables. This is one optimization that helps save on memory: These songs only take up memory when you reference them in your keymap, because they're essentially all preprocessor directives.
+
+So now you have something called `tone_plover` for example. How do you make it play the Plover tune, then? If you look further down the keymap, you'll see this:
+
+```
+PLAY_NOTE_ARRAY(tone_plover, false, 0); // Signature is: Song name, repeat, rest style
+```
+
+This is inside one of the macros. So when that macro executes, your keyboard plays that particular chime.
+
+"Rest style" in the method signature above (the last parameter) specifies if there's a rest (a moment of silence) between the notes.
+
+## Music mode
+
+The music mode maps your columns to a chromatic scale, and your rows to octaves. This works best with ortholinear keyboards, but can be made to work with others. All keycodes less than `0xFF` get blocked, so you won't type while playing notes - if you have special keys/mods, those will still work. A work-around for this is to jump to a different layer with KC_NOs before (or after) enabling music mode.
+
+Recording is experimental due to some memory issues - if you experience some weird behavior, unplugging/replugging your keyboard will fix things.
+
+Keycodes available:
+
+* `MU_ON` - Turn music mode on
+* `MU_OFF` - Turn music mode off
+* `MU_TOG` - Toggle music mode
+
+In music mode, the following keycodes work differently, and don't pass through:
+
+* `LCTL` - start a recording
+* `LALT` - stop recording/stop playing
+* `LGUI` - play recording
+* `KC_UP` - speed-up playback
+* `KC_DOWN` - slow-down playback
+
+## MIDI functionalty
+
+This is still a WIP, but check out `quantum/keymap_midi.c` to see what's happening. Enable from the Makefile.
+
+## Bluetooth functionality
+
+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.
+
+## RGB Under Glow Mod
+
+![Planck with RGB Underglow](https://raw.githubusercontent.com/qmk/qmk_firmware/master/keyboards/planck/keymaps/yang/planck-with-rgb-underglow.jpg)
+
+Here is a quick demo on Youtube (with NPKC KC60) (https://www.youtube.com/watch?v=VKrpPAHlisY).
+
+For this mod, you need an unused pin wiring to DI of WS2812 strip. After wiring the VCC, GND, and DI, you can enable the underglow in your Makefile.
+
+ RGBLIGHT_ENABLE = yes
+
+In order to use the underglow animation functions, you need to have `#define RGBLIGHT_ANIMATIONS` in your `config.h`.
+
+Please add the following options into your config.h, and set them up according your hardware configuration. These settings are for the `F4` pin by default:
+
+ #define RGB_DI_PIN F4 // The pin your RGB strip is wired to
+ #define RGBLIGHT_ANIMATIONS // Require for fancier stuff (not compatible with audio)
+ #define RGBLED_NUM 14 // Number of LEDs
+ #define RGBLIGHT_HUE_STEP 10
+ #define RGBLIGHT_SAT_STEP 17
+ #define RGBLIGHT_VAL_STEP 17
+
+You'll need to edit `RGB_DI_PIN` to the pin you have your `DI` on your RGB strip wired to.
+
+The firmware supports 5 different light effects, and the color (hue, saturation, brightness) can be customized in most effects. To control the underglow, you need to modify your keymap file to assign those functions to some keys/key combinations. For details, please check this keymap. `keyboards/planck/keymaps/yang/keymap.c`
+Please note the USB port can only supply a limited amount of power to the keyboard (500mA by standard, however, modern computer and most usb hubs can provide 700+mA.). According to the data of NeoPixel from Adafruit, 30 WS2812 LEDs require a 5V 1A power supply, LEDs used in this mod should not more than 20.
+
+## PS/2 Mouse Support
+
+Its possible to hook up a PS/2 mouse (for example touchpads or trackpoints) to your keyboard as a composite device.
+
+To hook up a Trackpoint, you need to obtain a Trackpoint module (i.e. harvest from a Thinkpad keyboard), identify the function of each pin of the module, and make the necessary circuitry between controller and Trackpoint module. For more information, please refer to [Trackpoint Hardware](https://deskthority.net/wiki/TrackPoint_Hardware) page on Deskthority Wiki.
+
+There are three available modes for hooking up PS/2 devices: USART (best), interrupts (better) or busywait (not recommended).
+
+### Busywait version
+
+Note: This is not recommended, you may encounter jerky movement or unsent inputs. Please use interrupt or USART version if possible.
+
+In rules.mk:
+
+```
+PS2_MOUSE_ENABLE = yes
+PS2_USE_BUSYWAIT = yes
+```
+
+In your keyboard config.h:
+
+```
+#ifdef PS2_USE_BUSYWAIT
+# define PS2_CLOCK_PORT PORTD
+# define PS2_CLOCK_PIN PIND
+# define PS2_CLOCK_DDR DDRD
+# define PS2_CLOCK_BIT 1
+# define PS2_DATA_PORT PORTD
+# define PS2_DATA_PIN PIND
+# define PS2_DATA_DDR DDRD
+# define PS2_DATA_BIT 2
+#endif
+```
+
+### Interrupt version
+
+The following example uses D2 for clock and D5 for data. You can use any INT or PCINT pin for clock, and any pin for data.
+
+In rules.mk:
+
+```
+PS2_MOUSE_ENABLE = yes
+PS2_USE_INT = yes
+```
+
+In your keyboard config.h:
+
+```
+#ifdef PS2_USE_INT
+#define PS2_CLOCK_PORT PORTD
+#define PS2_CLOCK_PIN PIND
+#define PS2_CLOCK_DDR DDRD
+#define PS2_CLOCK_BIT 2
+#define PS2_DATA_PORT PORTD
+#define PS2_DATA_PIN PIND
+#define PS2_DATA_DDR DDRD
+#define PS2_DATA_BIT 5
+
+#define PS2_INT_INIT() do { \
+ EICRA |= ((1<<ISC21) | \
+ (0<<ISC20)); \
+} while (0)
+#define PS2_INT_ON() do { \
+ EIMSK |= (1<<INT2); \
+} while (0)
+#define PS2_INT_OFF() do { \
+ EIMSK &= ~(1<<INT2); \
+} while (0)
+#define PS2_INT_VECT INT2_vect
+#endif
+```
+
+### USART version
+
+To use USART on the ATMega32u4, you have to use PD5 for clock and PD2 for data. If one of those are unavailable, you need to use interrupt version.
+**Q:** The default speed for controlling the mouse with the keyboard is slow. I've tried increasing the mouse's sensitivity at work using xset m and it worked, although sometimes it changes by itself for some reason. At home, on Arch Linux, this does not change ti. I've looked through the forums and resolved to use libinput using xinput but using that I only manage to change the speed of the mouse using the actual mouse. The speed of the mouse using the keyboard controls remained unchanged.
+Is there perhaps something I can input in the keymap.c to change the sensitivity? Or some other surefire way of increasing the speed?
+Thanks!
+
+**A:** In your keymap's config.h:
+
+```
+#define MOUSEKEY_INTERVAL 20
+#define MOUSEKEY_DELAY 0
+#define MOUSEKEY_TIME_TO_MAX 60
+#define MOUSEKEY_MAX_SPEED 7
+#define MOUSEKEY_WHEEL_DELAY 0
+```
+
+Tweak away. A lower interval or higher max speed will effectively make the mouse move faster. Time-to-max controls acceleration. (See [this Reddit thread for the original discussion](https://www.reddit.com/r/ErgoDoxEZ/comments/61fwr2/a_reliable_way_to_increase_the_speed_of_the_mouse/)).