Merge branch 'mousekey-test' of https://github.com/gourdo1/qmk_firmware…

… into mousekey-test

.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
 

.github/workflows/develop_update.yml

@@ -5,7 +5,6 @@ on:
     branches:
     - master
 
-
 jobs:
   develop_update:
     runs-on: ubuntu-latest
@@ -22,14 +21,7 @@ jobs:
         git fetch origin master develop
         git checkout develop
 
-    - name: Check if branch locked
-      id: check_locked
-      uses: andstor/file-existence-action@v1
-      with:
-        files: ".locked"
-
     - name: Update develop from master
-      if: steps.check_locked.outputs.files_exists == 'false'
       run: |
         git config --global user.name "QMK Bot"
         git config --global user.email "[email protected]"

.github/workflows/feature_branch_update.yml

@@ -0,0 +1,34 @@
+name: Update feature branches after develop merge
+
+on:
+  push:
+    branches:
+    - develop
+
+jobs:
+  feature_branch_update:
+    runs-on: ubuntu-latest
+
+    if: github.repository == 'qmk/qmk_firmware'
+
+    strategy:
+      matrix:
+        branch:
+        - xap
+
+    steps:
+    - uses: actions/checkout@v2
+      with:
+        fetch-depth: 0
+
+    - name: Checkout branch
+      run: |
+        git fetch origin develop ${{ matrix.branch }}
+        git checkout ${{ matrix.branch }}
+
+    - name: Update branch from develop
+      run: |
+        git config --global user.name "QMK Bot"
+        git config --global user.email "[email protected]"
+        git merge origin/develop
+        git push origin ${{ matrix.branch }}

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",

data/schemas/keyboard.jsonschema

@@ -109,6 +109,7 @@
         },
         "layouts": {
             "type": "object",
+            "propertyNames": {"$ref": "qmk.definitions.v1#/layout_macro"},
             "additionalProperties": {
                 "type": "object",
                 "additionalProperties": false,

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
     }
-}
+}

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
 

docs/feature_bootmagic.md

@@ -23,14 +23,35 @@ And to trigger the bootloader, you hold this key down when plugging the keyboard
 
 ## Split Keyboards
 
-When handedness is predetermined via an option like `SPLIT_HAND_PIN`, you might need to configure a different key between halves. To do so, add these entries to your `config.h` file:
+When [handedness](feature_split_keyboard.md#setting-handedness) is predetermined via options like `SPLIT_HAND_PIN` or `EE_HANDS`, you might need to configure a different key between halves. To identify the correct key for the right half, examine the split key matrix defined in the `<keyboard>.h` file, e.g.:
+
+```c
+#define LAYOUT_split_3x5_2( \
+        L01, L02, L03, L04, L05,   R01, R02, R03, R04, R05, \
+        L06, L07, L08, L09, L10,   R06, R07, R08, R09, R10, \
+        L11, L12, L13, L14, L15,   R11, R12, R13, R14, R15, \
+                       L16, L17,   R16, R17                 \
+    ) \
+    { \
+        { L01, L02, L03, L04, L05 }, \
+        { L06, L07, L08, L09, L10 }, \
+        { L11, L12, L13, L14, L15 }, \
+        { L16, L17, KC_NO, KC_NO, KC_NO }, \
+        { R01, R02, R03, R04, R05 }, \
+        { R06, R07, R08, R09, R10 }, \
+        { R11, R12, R13, R14, R15 }, \
+        { R16, R17, KC_NO, KC_NO, KC_NO }  \
+    }
+```
+
+If you pick the top right key for the right half, it is `R05` on the top layout. Within the key matrix below, `R05` is located on row 4 columnn 4. To use that key as the right half's Bootmagic Lite trigger, add these entries to your `config.h` file:
 
 ```c
 #define BOOTMAGIC_LITE_ROW_RIGHT 4
-#define BOOTMAGIC_LITE_COLUMN_RIGHT 1
+#define BOOTMAGIC_LITE_COLUMN_RIGHT 4
 ```
 
-By default, these values are not set.
+?> These values are not set by default.
 
 ## Advanced Bootmagic Lite
 
@@ -51,7 +72,7 @@ void bootmagic_lite(void) {
 }
 ```
 
-You can additional feature here. For instance, resetting the EEPROM or requiring additional keys to be pressed to trigger Bootmagic Lite. Keep in mind that `bootmagic_lite` is called before a majority of features are initialized in the firmware.
+You can define additional logic here. For instance, resetting the EEPROM or requiring additional keys to be pressed to trigger Bootmagic Lite. Keep in mind that `bootmagic_lite` is called before a majority of features are initialized in the firmware.
 
 ## Addenda
 

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
 
@@ -325,7 +325,8 @@ report_mouse_t pointing_device_task_user(report_mouse_t mouse_report) {
     if (set_scrolling) {
         mouse_report.h = mouse_report.x;
         mouse_report.v = mouse_report.y;
-        mouse_report.x = mouse_report.y = 0
+        mouse_report.x = 0;
+        mouse_report.y = 0;
     }
     return mouse_report;
 }

docs/isp_flashing_guide.md

@@ -4,7 +4,7 @@ In order to flash a microcontroller over USB, it needs something called a bootlo
 
 However, it can sometimes happen that the bootloader becomes corrupted and needs reflashing, or you may want to change the bootloader to another one. It's not possible to do this with the existing bootloader, because, of course, it is already running, and cannot overwrite itself. Instead, you will need to ISP flash the microcontroller.
 
-There are several different kinds of bootloaders available for AVR microcontrollers. Most STM32 ARM-based microcontrollers already have a USB-capable bootloader in ROM, so generally do not need to be ISP flashed.
+There are several different kinds of bootloaders available for AVR microcontrollers. Most STM32 ARM-based microcontrollers already have a USB-capable bootloader in ROM, so generally do not need to be ISP flashed. The one current exception is the [STM32F103](#flashing-stm32duino-bootloader).
 
 ## Hardware
 
@@ -260,3 +260,93 @@ For mass production purposes, it is possible to join the bootloader and QMK firm
  4. Save it as a new file, for example `<keyboard>_<keymap>_production.hex`.
 
 You can then ISP flash this combined firmware instead, which allows you to skip the extra step of flashing the QMK firmware over USB.
+
+## Flashing STM32Duino Bootloader
+
+As mentioned above, *most* supported STM32 devices already possess a USB DFU bootloader which cannot be overwritten, however the ROM bootloader in the STM32F103 used on the Bluepill is not USB capable. In this case an ST-Link V2 dongle is required to upload the STM32Duino bootloader to the device. These can be readily purchased for relatively cheap on eBay and other places.
+
+This bootloader is a descendant of the Maple bootloader by Leaflabs, and is compatible with dfu-util.
+
+### Software
+
+To communicate with the ST-Link, you must install the following packages:
+
+* **macOS:** `brew install stlink openocd`
+* **Windows (MSYS2):** `pacman -S mingw-w64-x86_64-stlink mingw-w64-x86_64-openocd`
+* **Linux:** will vary by distribution, but will likely be `stlink` and `openocd` through your particular package manager
+
+Additionally, you may need to update the ST-Link's firmware with the [`STSW-LINK007`](https://www.st.com/en/development-tools/stsw-link007.html) application. Note you will be asked to provide your name and email address if you do not have an ST.com account (this does not create one).
+
+Finally, the bootloader binary itself can be downloaded from [here](https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/bootloader_only_binaries/generic_boot20_pc13.bin).
+
+### Wiring
+
+Connect the four-pin header on the end of the Bluepill to the matching pins on the ST-Link (the pinout will usually be printed on the side):
+
+|ST-Link      |Bluepill|
+|-------------|--------|
+|`GND` (6)    |`GND`   |
+|`SWCLK` (2)  |`DCLK`  |
+|`SWDIO` (4)  |`DIO`   |
+|`3.3V` (8)   |`3.3`   |
+
+### Flashing
+
+Firstly, make sure both jumpers on the Bluepill are set to 0.
+
+Check that the ST-Link can talk to the Bluepill by running `st-info --probe`:
+
+```
+Found 1 stlink programmers
+  version:    V2J37S7
+  serial:     2C1219002B135937334D4E00
+  flash:      65536 (pagesize: 1024)
+  sram:       20480
+  chipid:     0x0410
+  descr:      F1xx Medium-density
+```
+
+If the reported `chipid` is `0x0410`, everything is working. If it is `0x0000`, check your wiring, and try swapping the `SWDIO` and `SWCLK` pins, as some ST-Link dongles may have incorrect pinouts.
+
+Next, run the following command:
+
+```
+st-flash --reset --format binary write <path-to-bootloader> 0x08000000
+```
+
+where `<path-to-bootloader>` is the path to the bootloader `.bin` file above. You can run this command from the directory you downloaded it to, so that you can simply pass in the filename.
+
+If all goes well, you should get output similar to the following:
+
+```
+st-flash 1.7.0
+2022-03-08T12:16:30 INFO common.c: F1xx Medium-density: 20 KiB SRAM, 64 KiB flash in at least 1 KiB pages.
+file generic_boot20_pc13.bin md5 checksum: 333c30605e739ce9bedee5999fdaf81b, stlink checksum: 0x0008e534
+2022-03-08T12:16:30 INFO common.c: Attempting to write 7172 (0x1c04) bytes to stm32 address: 134217728 (0x8000000)
+2022-03-08T12:16:30 INFO common.c: Flash page at addr: 0x08000000 erased
+2022-03-08T12:16:30 INFO common.c: Flash page at addr: 0x08000400 erased
+2022-03-08T12:16:31 INFO common.c: Flash page at addr: 0x08000800 erased
+2022-03-08T12:16:31 INFO common.c: Flash page at addr: 0x08000c00 erased
+2022-03-08T12:16:31 INFO common.c: Flash page at addr: 0x08001000 erased
+2022-03-08T12:16:31 INFO common.c: Flash page at addr: 0x08001400 erased
+2022-03-08T12:16:31 INFO common.c: Flash page at addr: 0x08001800 erased
+2022-03-08T12:16:31 INFO common.c: Flash page at addr: 0x08001c00 erased
+2022-03-08T12:16:31 INFO common.c: Finished erasing 8 pages of 1024 (0x400) bytes
+2022-03-08T12:16:31 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL
+2022-03-08T12:16:31 INFO flash_loader.c: Successfully loaded flash loader in sram
+2022-03-08T12:16:31 INFO flash_loader.c: Clear DFSR
+  8/  8 pages written
+2022-03-08T12:16:31 INFO common.c: Starting verification of write complete
+2022-03-08T12:16:31 INFO common.c: Flash written and verified! jolly good!
+2022-03-08T12:16:31 WARN common.c: NRST is not connected
+```
+
+Otherwise, if you receive an `Unknown memory region` error, run the following command to unlock the STM32F103:
+
+```
+openocd -f interface/stlink.cfg -f target/stm32f1x.cfg -c "init; reset halt; stm32f1x unlock 0; reset halt; exit"
+```
+
+Then re-plug the ST-Link and try again.
+
+After all of this, unplug the Bluepill from the ST-Link and connect it to USB. It should now be ready to flash using dfu-util, the QMK CLI or Toolbox.

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`

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
 
 ## フォーマットの詳細