diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/contributing.md | 6 | ||||
| -rw-r--r-- | docs/custom_quantum_functions.md | 8 | ||||
| -rw-r--r-- | docs/faq_build.md | 12 | ||||
| -rw-r--r-- | docs/faq_debug.md | 18 | ||||
| -rw-r--r-- | docs/faq_keymap.md | 4 | ||||
| -rw-r--r-- | docs/feature_advanced_keycodes.md | 2 | ||||
| -rw-r--r-- | docs/feature_audio.md | 2 | ||||
| -rw-r--r-- | docs/feature_dynamic_macros.md | 2 | ||||
| -rw-r--r-- | docs/feature_layouts.md | 4 | ||||
| -rw-r--r-- | docs/feature_macros.md | 4 | ||||
| -rw-r--r-- | docs/feature_ps2_mouse.md | 2 | ||||
| -rw-r--r-- | docs/feature_tap_dance.md | 8 | ||||
| -rw-r--r-- | docs/feature_terminal.md | 8 | ||||
| -rw-r--r-- | docs/feature_userspace.md | 10 | ||||
| -rw-r--r-- | docs/flashing.md | 6 | ||||
| -rw-r--r-- | docs/getting_started_build_tools.md | 6 | ||||
| -rw-r--r-- | docs/getting_started_make_guide.md | 12 | ||||
| -rw-r--r-- | docs/glossary.md | 2 | ||||
| -rw-r--r-- | docs/hand_wire.md | 4 | ||||
| -rw-r--r-- | docs/hardware_keyboard_guidelines.md | 2 | ||||
| -rw-r--r-- | docs/isp_flashing_guide.md | 24 | ||||
| -rw-r--r-- | docs/keycode.txt | 2 | ||||
| -rw-r--r-- | docs/keycodes_us_ansi_shifted.md | 2 | ||||
| -rw-r--r-- | docs/keymap.md | 14 | ||||
| -rw-r--r-- | docs/power.txt | 2 | ||||
| -rw-r--r-- | docs/quantum_keycodes.md | 2 | ||||
| -rw-r--r-- | docs/understanding_qmk.md | 6 | ||||
| -rw-r--r-- | docs/unit_testing.md | 2 |
28 files changed, 88 insertions, 88 deletions
diff --git a/docs/contributing.md b/docs/contributing.md index a1534d9681..0e8066f005 100644 --- a/docs/contributing.md +++ b/docs/contributing.md @@ -75,7 +75,7 @@ Most of our style is pretty easy to pick up on, but right now it's not entirely We have a few different types of changes in QMK, each requiring a different level of rigor. We'd like you to keep the following guidelines in mind no matter what type of change you're making. -* Separate PR's into logical units. For example, do not submit one PR covering two separate features, instead submit a separate PR for each feature. +* Separate PR's into logical units. For example, do not submit one PR covering two separate features, instead submit a separate PR for each feature. * Check for unnecessary whitespace with `git diff --check` before committing. * Make sure your code change actually compiles. * Keymaps: Make sure that `make keyboard:your_new_keymap` does not return an error @@ -111,7 +111,7 @@ Most first-time QMK contributors start with their personal keymaps. We try to ke Keyboards are the raison d'être for QMK. Some keyboards are community maintained, while others are maintained by the people responsible for making a particular keyboard. The `readme.md` should tell you who maintains a particular keyboard. If you have questions relating to a particular keyboard you can [Open An Issue](https://github.com/qmk/qmk_firmware/issues) and tag the maintainer in your question. -We also ask that you follow these guidelines: +We also ask that you follow these guidelines: * Write a `readme.md` using [the template](https://docs.qmk.fm/documentation_templates.html#). * Keep the number of commits reasonable or we will squash your PR @@ -136,7 +136,7 @@ Here are some things to keep in mind when working on your feature or bug fix. * **Consider revisions and different chip-bases** - there are several keyboards that have revisions that allow for slightly different configurations, and even different chip-bases. Try to make a feature supported in ARM and AVR, or automatically disabled on platforms it doesn't work on. * **Explain your feature** - Document it in `docs/`, either as a new file or as part of an existing file. If you don't document it other people won't be able to benefit from your hard work. -We also ask that you follow these guidelines: +We also ask that you follow these guidelines: * Keep the number of commits reasonable or we will squash your PR * Do not lump keyboards or keymaps in with core changes. Submit your core changes first. diff --git a/docs/custom_quantum_functions.md b/docs/custom_quantum_functions.md index 16faf9732a..928dccc9c3 100644 --- a/docs/custom_quantum_functions.md +++ b/docs/custom_quantum_functions.md @@ -1,6 +1,6 @@ # How to Customize Your Keyboard's Behavior -For a lot of people a custom keyboard is about more than sending button presses to your computer. You want to be able to do things that are more complex than simple button presses and macros. QMK has hooks that allow you to inject code, override functionality, and otherwise customize how your keyboard behaves in different situations. +For a lot of people a custom keyboard is about more than sending button presses to your computer. You want to be able to do things that are more complex than simple button presses and macros. QMK has hooks that allow you to inject code, override functionality, and otherwise customize how your keyboard behaves in different situations. This page does not assume any special knowledge about QMK, but reading [Understanding QMK](understanding_qmk.md) will help you understand what is going on at a more fundamental level. @@ -66,7 +66,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) { ### `process_record_*` Function Documentation -* Keyboard/Revision: `bool process_record_kb(uint16_t keycode, keyrecord_t *record)` +* Keyboard/Revision: `bool process_record_kb(uint16_t keycode, keyrecord_t *record)` * Keymap: `bool process_record_user(uint16_t keycode, keyrecord_t *record)` The `keycode` argument is whatever is defined in your keymap, eg `MO(1)`, `KC_L`, etc. You should use a `switch...case` block to handle these events. @@ -130,7 +130,7 @@ void led_set_kb(uint8_t usb_led) { ### `led_set_*` Function Documentation -* Keyboard/Revision: `void led_set_kb(uint8_t usb_led)` +* Keyboard/Revision: `void led_set_kb(uint8_t usb_led)` * Keymap: `void led_set_user(uint8_t usb_led)` # Matrix Initialization Code @@ -155,7 +155,7 @@ void matrix_init_kb(void) { ### `matrix_init_*` Function Documentation -* Keyboard/Revision: `void matrix_init_kb(void)` +* Keyboard/Revision: `void matrix_init_kb(void)` * Keymap: `void matrix_init_user(void)` # Matrix Scanning Code diff --git a/docs/faq_build.md b/docs/faq_build.md index 0474e27465..d38ca69d0d 100644 --- a/docs/faq_build.md +++ b/docs/faq_build.md @@ -6,7 +6,7 @@ This page covers questions about building QMK. If you have not yet you should re You will need proper permission to operate a device. For Linux users see udev rules below. Easy way is to use `sudo` command, if you are not familiar with this command check its manual with `man sudo` or this page on line. In short when your controller is ATMega32u4, - + $ sudo dfu-programmer atmega32u4 erase --force $ sudo dfu-programmer atmega32u4 flash your.hex $ sudo dfu-programmer atmega32u4 reset @@ -81,11 +81,11 @@ make: *** [obj_alps64/protocol/lufa/lufa.o] Error 1 Note that Teensy2.0++ bootloader size is 2048byte. Some Makefiles may have wrong comment. ``` -# Boot Section Size in *bytes* -# Teensy halfKay 512 -# Teensy++ halfKay 2048 +# Boot Section Size in *bytes* +# Teensy halfKay 512 +# Teensy++ halfKay 2048 # Atmel DFU loader 4096 (TMK Alt Controller) -# LUFA bootloader 4096 -# USBaspLoader 2048 +# LUFA bootloader 4096 +# USBaspLoader 2048 OPT_DEFS += -DBOOTLOADER_SIZE=2048 ``` diff --git a/docs/faq_debug.md b/docs/faq_debug.md index 25226102d7..7c1690d13f 100644 --- a/docs/faq_debug.md +++ b/docs/faq_debug.md @@ -116,12 +116,12 @@ http://deskthority.net/workshop-f7/rebuilding-and-redesigning-a-classic-thinkpad 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 +# 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 ``` @@ -135,14 +135,14 @@ byte Atmel/LUFA(ATMega32u4) byte Atmel(AT90SUB1286) | | | | | | | | | Application | | Application | - | | | | + | | | | = = = = | | 32KB-4KB | | 128KB-8KB 0x6000 +---------------+ 0x1E000 +---------------+ | Bootloader | 4KB | Bootloader | 8KB 0x7FFF +---------------+ 0x1FFFF +---------------+ - + byte Teensy(ATMega32u4) byte Teensy++(AT90SUB1286) 0x0000 +---------------+ 0x00000 +---------------+ | | | | @@ -230,7 +230,7 @@ https://geekhack.org/index.php?topic=14290.msg1884034#msg1884034 ## 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. +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. https://github.com/tmk/tmk_keyboard/issues/266 https://geekhack.org/index.php?topic=41989.msg1967778#msg1967778 diff --git a/docs/faq_keymap.md b/docs/faq_keymap.md index f0410fcb4d..7093dec202 100644 --- a/docs/faq_keymap.md +++ b/docs/faq_keymap.md @@ -48,7 +48,7 @@ For Modifier keys and layer actions you have to place `KC_TRANS` on same positio ## Mechanical Lock Switch Support This feature is for *mechanical lock switch* like [this Alps one](http://deskthority.net/wiki/Alps_SKCL_Lock). You can enable it by adding this to your `config.h`: - + ``` #define LOCKING_SUPPORT_ENABLE #define LOCKING_RESYNC_ENABLE @@ -187,7 +187,7 @@ ___TO BE IMPROVED___ real_mods is intended to retains state of real/physical modifier key state, while weak_mods retains state of virtual or temporary 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), +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) diff --git a/docs/feature_advanced_keycodes.md b/docs/feature_advanced_keycodes.md index 3ea28ca4e8..0e22154f62 100644 --- a/docs/feature_advanced_keycodes.md +++ b/docs/feature_advanced_keycodes.md @@ -41,7 +41,7 @@ If you are just getting started with QMK you will want to keep everything simple ### Intermediate Users -Sometimes you need more than one base layer. For example, if you want to switch between QWERTY and Dvorak, switch between layouts for different countries, or switch your layout for different videogames. Your base layers should always be the lowest numbered layers. When you have multiple base layers you should always treat them as mutually exclusive. When one base layer is on the others are off. +Sometimes you need more than one base layer. For example, if you want to switch between QWERTY and Dvorak, switch between layouts for different countries, or switch your layout for different videogames. Your base layers should always be the lowest numbered layers. When you have multiple base layers you should always treat them as mutually exclusive. When one base layer is on the others are off. ### Advanced Users diff --git a/docs/feature_audio.md b/docs/feature_audio.md index 774e0ae5a2..6b991a9afd 100644 --- a/docs/feature_audio.md +++ b/docs/feature_audio.md @@ -49,7 +49,7 @@ It's advised that you wrap all audio features in `#ifdef AUDIO_ENABLE` / `#endif ## 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. +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. diff --git a/docs/feature_dynamic_macros.md b/docs/feature_dynamic_macros.md index 23fefea4ce..9803557e9e 100644 --- a/docs/feature_dynamic_macros.md +++ b/docs/feature_dynamic_macros.md @@ -52,7 +52,7 @@ For users of the earlier versions of dynamic macros: It is still possible to fin ```c uint16_t macro_kc = (keycode == MO(_DYN) ? DYN_REC_STOP : keycode); - + if (!process_record_dynamic_macro(macro_kc, record)) { return false; } diff --git a/docs/feature_layouts.md b/docs/feature_layouts.md index fcfe9cd1cf..24c42c09fe 100644 --- a/docs/feature_layouts.md +++ b/docs/feature_layouts.md @@ -1,6 +1,6 @@ # Layouts: Using a Keymap with Multiple Keyboards -The `layouts/` folder contains different physical key layouts that can apply to different keyboards. +The `layouts/` folder contains different physical key layouts that can apply to different keyboards. ``` layouts/ @@ -21,7 +21,7 @@ layouts/ | + ... ``` -The `layouts/default/` and `layouts/community/` are two examples of layout "repositories" - currently `default` will contain all of the information concerning the layout, and one default keymap named `default_<layout>`, for users to use as a reference. `community` contains all of the community keymaps, with the eventual goal of being split-off into a separate repo for users to clone into `layouts/`. QMK searches through all folders in `layouts/`, so it's possible to have multiple repositories here. +The `layouts/default/` and `layouts/community/` are two examples of layout "repositories" - currently `default` will contain all of the information concerning the layout, and one default keymap named `default_<layout>`, for users to use as a reference. `community` contains all of the community keymaps, with the eventual goal of being split-off into a separate repo for users to clone into `layouts/`. QMK searches through all folders in `layouts/`, so it's possible to have multiple repositories here. Each layout folder is named (`[a-z0-9_]`) after the physical aspects of the layout, in the most generic way possible, and contains a `readme.md` with the layout to be defined by the keyboard: diff --git a/docs/feature_macros.md b/docs/feature_macros.md index a9c138e815..dff692bd8f 100644 --- a/docs/feature_macros.md +++ b/docs/feature_macros.md @@ -1,6 +1,6 @@ # Macros -Macros allow you to 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. +Macros allow you to 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. {% hint style='danger' %} **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 a hold of your keyboard will be able to access that information by opening a text editor. @@ -245,7 +245,7 @@ This will clear all keys besides the mods currently pressed. ## Advanced Example: Single-Key Copy/Paste -This example defines a macro which sends `Ctrl-C` when pressed down, and `Ctrl-V` when released. +This example defines a macro which sends `Ctrl-C` when pressed down, and `Ctrl-V` when released. ```c const macro_t *action_get_macro(keyrecord_t *record, uint8_t id, uint8_t opt) { diff --git a/docs/feature_ps2_mouse.md b/docs/feature_ps2_mouse.md index 51ae5fa263..909406e7d2 100644 --- a/docs/feature_ps2_mouse.md +++ b/docs/feature_ps2_mouse.md @@ -135,7 +135,7 @@ These enable settings supported by the PS/2 mouse protocol: http://www.computer- ``` /* Use remote mode instead of the default stream mode (see link) */ -#define PS2_MOUSE_USE_REMOTE_MODE +#define PS2_MOUSE_USE_REMOTE_MODE /* Enable the scrollwheel or scroll gesture on your mouse or touchpad */ #define PS2_MOUSE_ENABLE_SCROLLING diff --git a/docs/feature_tap_dance.md b/docs/feature_tap_dance.md index 271d1a0f00..e31e331679 100644 --- a/docs/feature_tap_dance.md +++ b/docs/feature_tap_dance.md @@ -187,9 +187,9 @@ enum { SINGLE_TAP = 1, SINGLE_HOLD = 2, DOUBLE_TAP = 3, - DOUBLE_HOLD = 4, + DOUBLE_HOLD = 4, DOUBLE_SINGLE_TAP = 5 //send SINGLE_TAP twice - NOT DOUBLE_TAP - // Add more enums here if you want for triple, quadruple, etc. + // Add more enums here if you want for triple, quadruple, etc. }; typedef struct { @@ -209,14 +209,14 @@ int cur_dance (qk_tap_dance_state_t *state) { if (state->interrupted) return DOUBLE_SINGLE_TAP; else if (state->pressed) return DOUBLE_HOLD; else return DOUBLE_TAP; - } + } else return 6; //magic number. At some point this method will expand to work for more presses } //**************** Definitions needed for quad function to work *********************// //instanalize an instance of 'tap' for the 'x' tap dance. -static tap xtap_state = { +static tap xtap_state = { .is_press_action = true, .state = 0 }; diff --git a/docs/feature_terminal.md b/docs/feature_terminal.md index 5c805e6ca5..334a46c2d4 100644 --- a/docs/feature_terminal.md +++ b/docs/feature_terminal.md @@ -68,11 +68,11 @@ Prints out the entire keymap for a certain layer ``` > keymap 0 -0x002b, 0x0014, 0x001a, 0x0008, 0x0015, 0x0017, 0x001c, 0x0018, 0x000c, 0x0012, 0x0013, 0x002a, -0x0029, 0x0004, 0x0016, 0x0007, 0x0009, 0x000a, 0x000b, 0x000d, 0x000e, 0x000f, 0x0033, 0x0034, -0x00e1, 0x001d, 0x001b, 0x0006, 0x0019, 0x0005, 0x0011, 0x0010, 0x0036, 0x0037, 0x0038, 0x0028, +0x002b, 0x0014, 0x001a, 0x0008, 0x0015, 0x0017, 0x001c, 0x0018, 0x000c, 0x0012, 0x0013, 0x002a, +0x0029, 0x0004, 0x0016, 0x0007, 0x0009, 0x000a, 0x000b, 0x000d, 0x000e, 0x000f, 0x0033, 0x0034, +0x00e1, 0x001d, 0x001b, 0x0006, 0x0019, 0x0005, 0x0011, 0x0010, 0x0036, 0x0037, 0x0038, 0x0028, 0x5cd6, 0x00e0, 0x00e2, 0x00e3, 0x5cd4, 0x002c, 0x002c, 0x5cd5, 0x0050, 0x0051, 0x0052, 0x004f, -> +> ``` ### `exit` diff --git a/docs/feature_userspace.md b/docs/feature_userspace.md index 9d7737fe1d..950377423b 100644 --- a/docs/feature_userspace.md +++ b/docs/feature_userspace.md @@ -18,7 +18,7 @@ All this only happens when you build a keymap named `<name>`, like this: make planck:<name> -For example, +For example, make planck:jack @@ -32,9 +32,9 @@ Please include authorship (your name, github username, email), and optionally [a For a brief example, checkout `/users/_example/` , or for a more detailed examples check out [`template.h`](https://github.com/qmk/qmk_firmware/blob/master/users/drashna/template.h) and [`template.c`](https://github.com/qmk/qmk_firmware/blob/master/users/drashna/template.c) in `/users/drashna/` . -### Consolidated Macros +### Consolidated Macros -If you wanted to consolidate macros and other functions into your userspace for all of your keymaps, you can do that. The issue is that you then cannot call any function defined in your userspace, or it gets complicated. To better handle this, you can call the functions here and create new functions to use in individual keymaps. +If you wanted to consolidate macros and other functions into your userspace for all of your keymaps, you can do that. The issue is that you then cannot call any function defined in your userspace, or it gets complicated. To better handle this, you can call the functions here and create new functions to use in individual keymaps. First, you'd want to go through all of your `keymap.c` files and replace `process_record_user` with `process_record_keymap` instead. This way, you can still use keyboard specific codes on those boards, and use your custom "global" keycodes as well. You'll also want to replace `SAFE_RANGE` with `NEW_SAFE_RANGE` so that you wont have any overlapping keycodes @@ -47,7 +47,7 @@ Once you've done that, you'll want to set the keycode definitions that you need #include "quantum.h" -// Define all of +// Define all of enum custom_keycodes { KC_MAKE = SAFE_RANGE, NEW_SAFE_RANGE //use "NEW_SAFE_RANGE" for keymap specific codes @@ -90,6 +90,6 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) { } ``` -This will add a new `KC_MAKE` keycode that can be used in any of your keymaps. And this keycode will output `make <keyboard>:<keymap">`, making frequent compiling easier. And this will work with any keyboard and any keymap as it will output the current boards info, so that you don't have to type this out every time. +This will add a new `KC_MAKE` keycode that can be used in any of your keymaps. And this keycode will output `make <keyboard>:<keymap">`, making frequent compiling easier. And this will work with any keyboard and any keymap as it will output the current boards info, so that you don't have to type this out every time. Additionally, this should flash the newly compiled firmware automatically, using the correct utility, based on the bootloader settings (or default to just generating the HEX file). However, it should be noted that this may not work on all systems. AVRDUDE doesn't work on WSL, namely (and will dump the HEX in the ".build" folder instead). diff --git a/docs/flashing.md b/docs/flashing.md index 1adacc55c2..8e1381f698 100644 --- a/docs/flashing.md +++ b/docs/flashing.md @@ -12,7 +12,7 @@ To ensure compatibility with the DFU bootloader, make sure this block is present # Bootloader # This definition is optional, and if your keyboard supports multiple bootloaders of - # different sizes, comment this out, and the correct address will be loaded + # different sizes, comment this out, and the correct address will be loaded # automatically (+60). See bootloader.mk for all options. BOOTLOADER = atmel-dfu @@ -57,7 +57,7 @@ To ensure compatibility with the Caterina bootloader, make sure this block is pr # Bootloader # This definition is optional, and if your keyboard supports multiple bootloaders of - # different sizes, comment this out, and the correct address will be loaded + # different sizes, comment this out, and the correct address will be loaded # automatically (+60). See bootloader.mk for all options. BOOTLOADER = caterina @@ -86,7 +86,7 @@ To ensure compatibility with the Halfkay bootloader, make sure this block is pre # Bootloader # This definition is optional, and if your keyboard supports multiple bootloaders of - # different sizes, comment this out, and the correct address will be loaded + # different sizes, comment this out, and the correct address will be loaded # automatically (+60). See bootloader.mk for all options. BOOTLOADER = halfkay diff --git a/docs/getting_started_build_tools.md b/docs/getting_started_build_tools.md index cd92ed68a7..6c8eca0de4 100644 --- a/docs/getting_started_build_tools.md +++ b/docs/getting_started_build_tools.md @@ -78,15 +78,15 @@ In addition to the Creators Update, you need Windows 10 Subystem for Linux, so i ### 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. +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`. +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! diff --git a/docs/getting_started_make_guide.md b/docs/getting_started_make_guide.md index ecf030d1dd..39ea34a60f 100644 --- a/docs/getting_started_make_guide.md +++ b/docs/getting_started_make_guide.md @@ -4,7 +4,7 @@ The full syntax of the `make` command is `<keyboard_folder>:<keymap>:<target>`, * `<keyboard_folder>` is the path of the keyboard, for example `planck` * Use `all` to compile all keyboards - * Specify the path to compile a revision, for example `planck/rev4` or `planck/rev3` + * Specify the path to compile a revision, for example `planck/rev4` or `planck/rev3` * If the keyboard doesn't have any folders, it can be left out * To compile the default folder, you can leave it out * `<keymap>` is the name of the keymap, for example `algernon` @@ -14,7 +14,7 @@ The full syntax of the `make` command is `<keyboard_folder>:<keymap>:<target>`, The `<target>` means the following * If no target is given, then it's the same as `all` below * `all` compiles as many keyboard/revision/keymap combinations as specified. For example, `make planck/rev4:default` will generate a single .hex, while `make planck/rev4:all` will generate a hex for every keymap available to the planck. -* `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 ChibiOS 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. +* `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 ChibiOS 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**: some operating systems need root access for these commands to work, so in that case you need to run for example `sudo make planck/rev4:default: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. @@ -30,7 +30,7 @@ The make command itself also has some additional options, type `make --help` for Here are some examples commands * `make all:all` builds everything (all keyboard folders, all keymaps). Running just `make` from the `root` will also run this. -* `make ergodox_infinity:algernon:clean` will clean the build output of the Ergodox Infinity keyboard. +* `make ergodox_infinity:algernon:clean` will clean the build output of the Ergodox Infinity keyboard. * `make planck/rev4:default:dfu COLOR=false` builds and uploads the keymap without color output. ## `rules.mk` Options @@ -53,9 +53,9 @@ 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). +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. +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. @@ -65,7 +65,7 @@ To disable print messages (*print*, *xprintf*) and **KEEP** user print messages 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. +**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. diff --git a/docs/glossary.md b/docs/glossary.md index 1ccd8f76c8..c8c54d6ded 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -167,4 +167,4 @@ The USB Host is your computer, or whatever device your keyboard is plugged into. # Couldn't Find the Term You're Looking For? -[Open an issue](https://github.com/qmk/qmk_firmware/issues) with your question and the term in question could be added here. Better still, open a pull request with the definition. :) +[Open an issue](https://github.com/qmk/qmk_firmware/issues) with your question and the term in question could be added here. Better still, open a pull request with the definition. :) diff --git a/docs/hand_wire.md b/docs/hand_wire.md index 4d4bd3c72f..1cbc16dfea 100644 --- a/docs/hand_wire.md +++ b/docs/hand_wire.md @@ -133,7 +133,7 @@ Starting at the top-left switch, place the diode (with tweezers if you have them │o ┌┴┐ o │ │ O - ├─┤ + ├─┤ └┬┘ └───────────── ``` @@ -150,7 +150,7 @@ When the first diode is complete, the next one will need to be soldered to both │o │o ┌┴┐ o ┌┴┐ o │ │ O │ │ O - ├─┤ ├─┤ + ├─┤ ├─┤ └┬┘ └┬┘ └────────────────┴───────────── ``` diff --git a/docs/hardware_keyboard_guidelines.md b/docs/hardware_keyboard_guidelines.md index fcc3b75ceb..0a4e2d11b8 100644 --- a/docs/hardware_keyboard_guidelines.md +++ b/docs/hardware_keyboard_guidelines.md @@ -91,7 +91,7 @@ All key positions and rotations are specified in relation to the top-left corner * `RY` * The absolute position of the point to rotate the key around in the vertical axis. Default: `y` * `KS` - * Key Shape: define a polygon by providing a list of points, in Key Units. + * Key Shape: define a polygon by providing a list of points, in Key Units. * **Important**: These are relative to the top-left of the key, not absolute. * Example ISO Enter: `[ [0,0], [1.5,0], [1.5,2], [0.25,2], [0.25,1], [0,1], [0,0] ]` diff --git a/docs/isp_flashing_guide.md b/docs/isp_flashing_guide.md index c2668c63b4..8abc454868 100644 --- a/ |