Merge pull request #2 from qmk/master

pull in new qmk changes
qmk · May 30, 2017 · 2c9f846 · 2c9f846
2 parents 5393bc6 + cb791cf
commit 2c9f846
Show file tree

Hide file tree

Showing 92 changed files with 5,520 additions and 34 deletions.
diff --git a/.gitignore b/.gitignore
@@ -22,6 +22,7 @@ quantum/version.h
 .idea/
 CMakeLists.txt
 .DS_STORE
+/util/wsl_downloaded
 
 # Eclipse/PyCharm/Other IDE Settings
 .cproject

diff --git a/book.json b/book.json
@@ -0,0 +1,23 @@
+{
+    "structure": {
+        "readme": "Home.md"
+    },
+    "plugins" : ["toolbar", "edit-link", "anchors"],
+    "pluginsConfig": {
+            "edit-link": {
+                "base": "https://github.com/qmk/qmk_firmware/edit/master/docs",
+                "label": "Suggest an edit"
+            },
+        "toolbar": {
+            "buttons":
+            [
+                {
+                    "label": "QMK Firmware",
+                    "icon": "fa fa-github",
+                    "url": "https://github.com/qmk/qmk_firmware"
+                }
+            ]
+        }
+    },
+    "root": "./docs/"
+}
diff --git a/docs/Adding-features-to-QMK.md b/docs/Adding-features-to-QMK.md
@@ -0,0 +1,7 @@
+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).
diff --git a/doc/BUILD_GUIDE.md → docs/BUILD_GUIDE.md b/doc/BUILD_GUIDE.md → docs/BUILD_GUIDE.md
diff --git a/docs/Becoming-a-QMK-Collaborator.md b/docs/Becoming-a-QMK-Collaborator.md
@@ -0,0 +1,7 @@
+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 [email protected] with an introduction and some links to your keyboard!
diff --git a/docs/Build-Environment-Setup.md b/docs/Build-Environment-Setup.md
@@ -0,0 +1,119 @@
+### Windows 10
+
+#### Creators Update
+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`.
+3. Install [DFU-Programmer](https://dfu-programmer.github.io/).
+
+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.
+
+Debian/Ubuntu example:
+
+    sudo apt-get update
+    sudo apt-get install 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
+
+### Docker
+
+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
+# defaults are ergodox/default
+
+docker run -e keymap=gwen -e subproject=ez -e keyboard=ergodox --rm -v $('pwd'):/qmk:rw edasque/qmk_firmware
+
+# 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
+docker run -e keymap=default -e subproject=ez -e keyboard=ergobox --rm -v D:/Users/Sacapuces/Documents/Repositories/qmk:/qmk:rw edasque/qmk_firmware
+
+```
+
+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.
diff --git a/doc/CYGWIN_GUIDE.md → docs/CYGWIN_GUIDE.md b/doc/CYGWIN_GUIDE.md → docs/CYGWIN_GUIDE.md
diff --git a/docs/Compatible-Microcontrollers.md b/docs/Compatible-Microcontrollers.md
@@ -0,0 +1,25 @@
+# Atmel AVR
+
+QMK should run on any Atmel AVR processor with enough Flash. It has been tested on the following:
+
+* ATmega32U4 ([PJRC Teensy 2.0](http://www.pjrc.com/teensy/))
+* AT90USB1286 ([PJRC Teensy++ 2.0](http://www.pjrc.com/teensy/))
+* AT90USB1287 ([Atmel USBKEY](http://www.atmel.com/tools/AT90USBKEY.aspx))
+* ATmega168P with using [V-USB](http://www.obdev.at/products/vusb/index.html)
+* ATmega328P with using [V-USB](http://www.obdev.at/products/vusb/index.html)
+* ATmega32U2
+* AT90USB1286, 646, 647 should work
+* AT90USB162 testing...
+
+NOTE: To enable full features of firmware you'll need 32KB flash size.
+
+Please add any tested microcontrollers to this list.
+
+# ARM
+
+You can also use any ARM processor that [ChibiOS](http://www.chibios.org) supports. The following processors have been tested:
+
+* [Kinetis MKL26Z64](http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/kinetis-cortex-m-mcus/l-series-ultra-low-power-m0-plus/kinetis-kl2x-48-mhz-usb-ultra-low-power-microcontrollers-mcus-based-on-arm-cortex-m0-plus-core:KL2x)
+* [Kinetis MK20DX128](http://www.nxp.com/assets/documents/data/en/data-sheets/K20P64M50SF0.pdf)
+* [Kinetis MK20DX128](http://www.nxp.com/assets/documents/data/en/data-sheets/K20P64M50SF0.pdf)
+* [Kinetis MK20DX256](http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/kinetis-cortex-m-mcus/k-series-performance-m4/k2x-usb/kinetis-k20-72-mhz-full-speed-usb-mixed-signal-integration-microcontrollers-mcus-based-on-arm-cortex-m4-core:K20_72)
diff --git a/docs/Custom-Quantum-Functions.md b/docs/Custom-Quantum-Functions.md
@@ -0,0 +1,123 @@
+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
+  * 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.
+
+## Hook Into Key Presses
+
+* Keyboard/Revision: `bool process_record_kb(uint16_t keycode, keyrecord_t *record)` 
+* Keymap: `bool process_record_user(uint16_t keycode, keyrecord_t *record)`
+
+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.
+
+## LED Control
+
+* Keyboard/Revision: `void led_set_kb(uint8_t usb_led)` 
+* Keymap: `void led_set_user(uint8_t usb_led)`
+
+This allows you to control the 5 LED's defined as part of the USB Keyboard spec. It will be called when the state of one of those 5 LEDs changes.
+
+* `USB_LED_NUM_LOCK`
+* `USB_LED_CAPS_LOCK`
+* `USB_LED_SCROLL_LOCK`
+* `USB_LED_COMPOSE`
+* `USB_LED_KANA`
+
+### Example:
+
+```
+void led_set_kb(uint8_t usb_led) {
+    if (usb_led & (1<<USB_LED_NUM_LOCK)) {
+        PORTB |= (1<<0);
+    } else {
+        PORTB &= ~(1<<0);
+    }
+    if (usb_led & (1<<USB_LED_CAPS_LOCK)) {
+        PORTB |= (1<<1);
+    } else {
+        PORTB &= ~(1<<1);
+    }
+    if (usb_led & (1<<USB_LED_SCROLL_LOCK)) {
+        PORTB |= (1<<2);
+    } else {
+        PORTB &= ~(1<<2);
+    }
+    if (usb_led & (1<<USB_LED_COMPOSE_LOCK)) {
+        PORTB |= (1<<3);
+    } else {
+        PORTB &= ~(1<<3);
+    }
+    if (usb_led & (1<<USB_LED_KANA_LOCK)) {
+        PORTB |= (1<<4);
+    } else {
+        PORTB &= ~(1<<4);
+    }
+}
+```
diff --git a/docs/Differences-from-TMK.md b/docs/Differences-from-TMK.md
@@ -0,0 +1,7 @@
+Understanding the essential changes made on the [tmk_keyboard firmware](http://github.com/tmk/tmk_keyboard) should help you understand the QMK Firmware.
+
+| Firmware                     |TMK                    |QMK                      |
+|------------------------------|-----------------------|-------------------------|
+| Maintainer                   |hasu  (@tmk)           |Jack Humbert et al.      |
+| Build path customization     | `TMK_DIR = ...`       | `include .../Makefile`  |
+| `keymaps` array data | 3D array of `uint8_t`  holding **keycode**      | 3D array of `uint16_t` holding **keycode**  |