ibnuda · angelbirth · Mar 3, 2022 · Mar 3, 2022 · Mar 3, 2022 · Mar 3, 2022
diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -18,19 +18,18 @@ assignees: ''
 
 ## System Information
 
- - Keyboard:  
-   - Revision (if applicable):  
- - Operating system:
- - AVR GCC version: 
-<!-- Run `avr-gcc --version` to find this out. -->
- - ARM GCC version: 
-<!-- Run `arm-none-eabi-gcc --version` to find this out. -->
- - QMK Firmware version:
-<!-- Run `git describe --abbrev=0 --tags` to find this out. -->
- - Any keyboard related software installed? 
-   - [ ] AutoHotKey
-   - [ ] Karabiner
-   - [ ] Other:
+**Keyboard:** 
+**Revision (if applicable):** 
+**Operating system:** 
+**`qmk doctor` output:** 
+```
+(Paste output here)
+```
+
+**Any keyboard related software installed?** 
+ - [ ] AutoHotKey (Windows)
+ - [ ] Karabiner (macOS)
+ - [ ] Other:
 
 ## Additional Context
 

diff --git a/data/schemas/definitions.jsonschema b/data/schemas/definitions.jsonschema
@@ -33,7 +33,33 @@
         "oneOf": [
             {
                 "type": "string",
-                "enum": ["LAYOUT", "LAYOUT_planck_1x2uC"]
+                "enum": [
+                    "LAYOUT",
+                    "LAYOUT_1x2uC",
+                    "LAYOUT_1x2uL",
+                    "LAYOUT_1x2uR",
+                    "LAYOUT_2x2uC",
+                    "LAYOUT_2x3uC",
+                    "LAYOUT_625uC",
+                    "LAYOUT_ANSI_DEFAULT",
+                    "LAYOUT_JP",
+                    "LAYOUT_ortho_3x12_1x2uC",
+                    "LAYOUT_ortho_4x12_1x2uC",
+                    "LAYOUT_ortho_4x12_1x2uL",
+                    "LAYOUT_ortho_4x12_1x2uR",
+                    "LAYOUT_ortho_5x12_1x2uC",
+                    "LAYOUT_ortho_5x12_2x2uC",
+                    "LAYOUT_ortho_5x14_1x2uC",
+                    "LAYOUT_ortho_5x14_1x2uL",
+                    "LAYOUT_ortho_5x14_1x2uR",
+                    "LAYOUT_planck_1x2uC",
+                    "LAYOUT_planck_1x2uL",
+                    "LAYOUT_planck_1x2uR",
+                    "LAYOUT_preonic_1x2uC",
+                    "LAYOUT_preonic_1x2uL",
+                    "LAYOUT_preonic_1x2uR",
+                    "LAYOUT_reviung34_2uL"
+                ]
             },
             {
                 "type": "string",

diff --git a/data/schemas/keyboard.jsonschema b/data/schemas/keyboard.jsonschema
@@ -109,6 +109,7 @@
         },
         "layouts": {
             "type": "object",
+            "propertyNames": {"$ref": "qmk.definitions.v1#/layout_macro"},
             "additionalProperties": {
                 "type": "object",
                 "additionalProperties": false,

diff --git a/data/templates/keyboard/info.json b/data/templates/keyboard/info.json
@@ -15,11 +15,11 @@
         "device_version": "1.0.0"
     },
     "features": {
-        "bootmagic_lite": true,
+        "bootmagic": true,
         "command": false,
         "console": false,
         "extrakey": true,
         "mousekey": true,
         "nkro": true
     }
-}
+}
diff --git a/docs/cli_development.md b/docs/cli_development.md
@@ -188,15 +188,15 @@ cli.log.info('Reading from %s and writing to %s', cli.args.filename, cli.args.ou
 
 # Testing, and Linting, and Formatting (oh my!)
 
-We use nose2, flake8, and yapf to test, lint, and format code. You can use the `pytest` and `format-py` subcommands to run these tests:
+We use nose2, flake8, and yapf to test, lint, and format code. You can use the `pytest` and `format-python` subcommands to run these tests:
 
 ### Testing and Linting
 
     qmk pytest
 
 ### Formatting
 
-    qmk format-py
+    qmk format-python
 
 ## Formatting Details
 

diff --git a/docs/feature_pointing_device.md b/docs/feature_pointing_device.md
@@ -245,7 +245,7 @@ The following configuration options are only available when using `SPLIT_POINTIN
 | `pointing_device_get_report(void)`                         | Returns the current mouse report (as a `mouse_report_t` data structure).                                      | 
 | `pointing_device_set_report(mouse_report)`                 | Sets the mouse report to the assigned `mouse_report_t` data structured passed to the function.                | 
 | `pointing_device_send(void)`                               | Sends the current mouse report to the host system.  Function can be replaced.                                 | 
-| `has_mouse_report_changed(old, new)`                       | Compares the old and new `mouse_report_t` data and returns true only if it has changed.                       |
+| `has_mouse_report_changed(new_report, old_report)`         | Compares the old and new `mouse_report_t` data and returns true only if it has changed.                       |
 | `pointing_device_adjust_by_defines(mouse_report)`          | Applies rotations and invert configurations to a raw mouse report.                                             |
 
 
@@ -276,14 +276,14 @@ The report_mouse_t (here "mouseReport") has the following properties:
 To manually manipulate the mouse reports outside of the `pointing_device_task_*` functions, you can use:
 
 * `pointing_device_get_report()` - Returns the current report_mouse_t that represents the information sent to the host computer
-* `pointing_device_set_report(report_mouse_t newMouseReport)` - Overrides and saves the report_mouse_t to be sent to the host computer
+* `pointing_device_set_report(report_mouse_t mouse_report)` - Overrides and saves the report_mouse_t to be sent to the host computer
 * `pointing_device_send()` - Sends the mouse report to the host and zeroes out the report. 
 
 When the mouse report is sent, the x, y, v, and h values are set to 0 (this is done in `pointing_device_send()`, which can be overridden to avoid this behavior).  This way, button states persist, but movement will only occur once.  For further customization, both `pointing_device_init` and `pointing_device_task` can be overridden.
 
 Additionally, by default, `pointing_device_send()` will only send a report when the report has actually changed.  This prevents it from continuously sending mouse reports, which will keep the host system awake.  This behavior can be changed by creating your own `pointing_device_send()` function.
 
-Also, you use the `has_mouse_report_changed(new, old)` function to check to see if the report has changed.
+Also, you use the `has_mouse_report_changed(new_report, old_report)` function to check to see if the report has changed.
 
 ## Examples
 

diff --git a/docs/ja/cli_commands.md b/docs/ja/cli_commands.md
@@ -275,14 +275,14 @@ $ qmk kle2json -f kle.txt -f
 Ψ Wrote out to info.json
 ```
 
-## `qmk format-py`
+## `qmk format-python`
 
 このコマンドは `qmk_firmware` 内の python コードを整形します。
 
 **使用法**:
 
 ```
-qmk format-py
+qmk format-python
 ```
 
 ## `qmk pytest`

diff --git a/docs/ja/cli_development.md b/docs/ja/cli_development.md
@@ -192,15 +192,15 @@ cli.log.info('Reading from %s and writing to %s', cli.args.filename, cli.args.ou
 
 # テスト、リントおよびフォーマット
 
-nose2、flake8 および yapf を使ってコードをテスト、リントおよびフォーマットします。これらのテストを実行するために `pytest` と `format-py` サブコマンドを使うことができます。
+nose2、flake8 および yapf を使ってコードをテスト、リントおよびフォーマットします。これらのテストを実行するために `pytest` と `format-python` サブコマンドを使うことができます。
 
 ### テストとリント
 
     qmk pytest
 
 ### フォーマット
 
-    qmk format-py
+    qmk format-python
 
 ## フォーマットの詳細
 

diff --git a/docs/ja/feature_pointing_device.md b/docs/ja/feature_pointing_device.md
@@ -16,7 +16,7 @@ POINTING_DEVICE_ENABLE = yes
 マウスレポートを操作するために、以下の関数を使うことができます:
 
 * `pointing_device_get_report()` - ホストコンピュータに送信された情報を表す現在の report_mouse_t を返します。
-* `pointing_device_set_report(report_mouse_t newMouseReport)` - ホストコンピュータに送信される report_mouse_t を上書き保存します。
+* `pointing_device_set_report(report_mouse_t mouse_report)` - ホストコンピュータに送信される report_mouse_t を上書き保存します。
 
 report_mouse_t (ここでは "mouseReport") が以下のプロパティを持つことを覚えておいてください:
 
@@ -34,7 +34,7 @@ report_mouse_t (ここでは "mouseReport") が以下のプロパティを持つ
 
 さらに、デフォルトでは、`pointing_device_send()` はレポートが実際に変更された場合のみレポートを送信します。これにより、マウスレポートが継続的に送信されてホストシステムが起動されたままになることを防ぎます。この動作は、独自の `pointing_device_send()` 関数を作成することで変更できます。
 
-また、`has_mouse_report_changed(new, old)` 関数を使って、レポートが変更されたかどうかを確認できます。(訳注：独自の `pointing_device_send()` 関数を作成する場合でも、その中で `has_mouse_report_changed(new, old)` 関数でチェックして、デフォルトの `pointing_device_send()` と類似の無駄なレポートの抑制をして、ホストシステムがスリープ状態に入れる余地を残すようにしておくのが良いでしょう。)
+また、`has_mouse_report_changed(new_report, old_report)` 関数を使って、レポートが変更されたかどうかを確認できます。(訳注：独自の `pointing_device_send()` 関数を作成する場合でも、その中で `has_mouse_report_changed(new_report, old_report)` 関数でチェックして、デフォルトの `pointing_device_send()` と類似の無駄なレポートの抑制をして、ホストシステムがスリープ状態に入れる余地を残すようにしておくのが良いでしょう。)
 
 以下の例では、カスタムキーを使ってマウスをクリックし垂直および水平方向に127単位スクロールし、リリースされた時にそれを全て元に戻します - なぜならこれは完全に便利な機能だからです。いいですか、以下はひとつの例です:
 

diff --git a/docs/keymap.md b/docs/keymap.md
@@ -132,7 +132,7 @@ The main part of this file is the `keymaps[]` definition. This is where you list
 
     const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
 
-After this you'll find a list of LAYOUT() macros. A LAYOUT() 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.
+After this you'll find the layer definitions. 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.
 
@@ -153,7 +153,9 @@ Here is an example of the Clueboard's base layer:
 
 Some interesting things to note about this:
 
-* 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.
+* The layer is defined using the LAYOUT macro, traditionally defined in the keyboard's `.h` file.
+* The LAYOUT macro takes a single list of keycodes, but we have written it in the C source using embedded whitespace and newlines to visualize where each key is on the physical device.
+* The LAYOUT macro hides and handles the mapping to the hardware's key scan matrix.
 * 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.

diff --git a/docs/pr_checklist.md b/docs/pr_checklist.md
@@ -50,7 +50,7 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
     - valid maintainer
     - displays correctly in Configurator (press Ctrl+Shift+I to preview local file, turn on fast input to verify ordering)
 - `readme.md`
-    - standard template should be present -- [link to template](https://github.com/qmk/qmk_firmware/blob/master/data/templates/avr/readme.md)
+    - standard template should be present -- [link to template](https://github.com/qmk/qmk_firmware/blob/master/data/templates/keyboard/readme.md)
     - flash command is present, and has `:flash` at end
     - valid hardware availability link (unless handwired) -- private groupbuys are okay, but one-off prototypes will be questioned. If open-source, a link to files should be provided.
     - clear instructions on how to reset the board into bootloader mode

diff --git a/docs/reference_info_json.md b/docs/reference_info_json.md
@@ -28,11 +28,11 @@ The `info.json` file is a JSON formatted dictionary with the following keys avai
 * `layout_aliases`
     * A dictionary containing layout aliases. The key is the alias and the value is a layout in `layouts` it maps to.
 * `layouts`
-    * Physical Layout representations. See the [Layout Format](#layout_format) section for more detail.
+    * Physical Layout representations. See the [Layout Format](#layout-format) section for more detail.
 * `matrix_pins`
-    * Configure the pins corresponding to columns and rows, or direct pins. See the [Matrix Pins](#matrix_pins) section for more detail.
+    * Configure the pins corresponding to columns and rows, or direct pins. See the [Matrix Pins](#matrix-pins) section for more detail.
 * `rgblight`
-    * Configure the [RGB Lighting feature](feature_rgblight.md). See the [RGB Lighting](#rgb_lighting) section for more detail.
+    * Configure the [RGB Lighting feature](feature_rgblight.md). See the [RGB Lighting](#rgb-lighting) section for more detail.
 * `usb`
     * Configure USB VID, PID, and other parameters. See the [USB](#USB) section for more detail.
 

diff --git a/docs/squeezing_avr.md b/docs/squeezing_avr.md
@@ -34,7 +34,7 @@ Largest in size is "magic" -- the QMK magic keycodes -- which control things lik
 
 If you've done all of that, and you don't want to disable features like RGB, Audio, OLEDs, etc, there are some additional options that you can add to your config.h that can help.
 
-Starting with Lock Key support. If you have an Cherry MX Lock switch (lucky you!), you don't want to do this. But chances are, you don't. In that case, add this to your `config.h`:
+Starting with Lock Key support. If you have a Cherry MX Lock switch (lucky you!), you don't want to do this. But chances are, you don't. In that case, add this to your `config.h`:
 ```c
 #undef LOCKING_SUPPORT_ENABLE
 #undef LOCKING_RESYNC_ENABLE

diff --git a/docs/understanding_qmk.md b/docs/understanding_qmk.md
@@ -8,27 +8,22 @@ This document attempts to explain how the QMK firmware works from a very high le
 
 ## Startup
 
-You can think of QMK as no different from any other computer program. It is started, performs its tasks, and then ends. The entry point for the program is the `main()` function, just like it is on any other C program. However, for a newcomer to QMK it can be confusing because the `main()` function appears in multiple places, and it can be hard to tell which one to look at.
+You can think of QMK as no different from any other computer program. It is started and performs its tasks, but this program never finishes. Like other C programs, the entry point is the `main()` function. For QMK, the `main()` function is found in [`quantum/main.c`](https://github.com/qmk/qmk_firmware/blob/0.15.13/quantum/main.c#L55).
 
-The reason for this is the different platforms that QMK supports. The most common platform is `lufa`, which runs on AVR processors such at the atmega32u4. We also support `chibios` and `vusb`.
+If you browse through the `main()` function you'll find that it starts by initializing any hardware that has been configured (including USB to the host). The most common platform for QMK is `lufa`, which runs on AVR processors such as the atmega32u4. When compiled for that platform, it will invoke for example `platform_setup()` in [`platforms/avr/platform.c`](https://github.com/qmk/qmk_firmware/blob/0.15.13/platforms/avr/platform.c#L19) and `protocol_setup()` in [`tmk_core/protocol/lufa/lufa.c`](https://github.com/qmk/qmk_firmware/blob/0.15.13/tmk_core/protocol/lufa/lufa.c#L1066). It will use other implementations when compiled for other platforms like `chibios` and `vusb`. At first glance, it can look like a lot of functionality but most of the time the code will be disabled by `#define`s.
 
-We'll focus on AVR processors for the moment, which use the `lufa` platform. You can find the `main()` function in [tmk_core/protocol/lufa/lufa.c](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/tmk_core/protocol/lufa/lufa.c#L1028). If you browse through that function you'll find that it initializes any hardware that has been configured (including USB to the host) and then it starts the core part of the program with a [`while(1)`](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/tmk_core/protocol/lufa/lufa.c#L1069). This is [The Main Loop](#the-main-loop).
+The `main()` function will then start the core part of the program with a [`while (true)`](https://github.com/qmk/qmk_firmware/blob/0.15.13/quantum/main.c#L63). This is [The Main Loop](#the-main-loop).
 
 ## The Main Loop
 
-This section of code is called "The Main Loop" because it's responsible for looping over the same set of instructions forever. This is where QMK dispatches out to the functions responsible for making the keyboard do everything it is supposed to do. At first glance it can look like a lot of functionality but most of the time the code will be disabled by `#define`'s.
+This section of code is called "The Main Loop" because it's responsible for looping over the same set of instructions forever, without ever reaching the end. This is where QMK dispatches out to the functions responsible for making the keyboard do everything it is supposed to do.
 
-```
-    keyboard_task();
-```
-
-This is where all the keyboard specific functionality is dispatched. The source code for `keyboard_task()` can be found in [tmk_core/common/keyboard.c](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/tmk_core/common/keyboard.c#L216), and it is responsible for detecting changes in the matrix and turning status LEDs on and off.
+The main loop will call [`protocol_task()`](https://github.com/qmk/qmk_firmware/blob/0.15.13/quantum/main.c#L38), which in turn will call `keyboard_task()` in [`quantum/keyboard.c`](https://github.com/qmk/qmk_firmware/blob/0.15.13/quantum/keyboard.c#L377). This is where all the keyboard specific functionality is dispatched, and it is responsible for detecting changes in the matrix and turning status LEDs on and off.
 
 Within `keyboard_task()` you'll find code to handle:
 
 * [Matrix Scanning](#matrix-scanning)
 * Mouse Handling
-* Serial Link(s)
 * Keyboard status LEDs (Caps Lock, Num Lock, Scroll Lock)
 
 #### Matrix Scanning

diff --git a/drivers/sensors/analog_joystick.c b/drivers/sensors/analog_joystick.c
@@ -18,6 +18,8 @@
 #include "analog.h"
 #include "gpio.h"
 #include "wait.h"
+#include "timer.h"
+#include <stdlib.h>
 
 // Set Parameters
 uint16_t minAxisValue = ANALOG_JOYSTICK_AXIS_MIN;