Skip to content

Commit

Permalink
Merge remote-tracking branch 'qmk/develop' into develop
Browse files Browse the repository at this point in the history 
* qmk/develop: (76 commits)
  Update ReadMe for the Roopad (qmk#15380)
  Tidy up existing i2c_master implementations (qmk#15376)
  Remove pointless `CUSTOM_MATRIX = no` (qmk#15383)
  Remove manual enable of LTO within keyboards (qmk#15377)
  [Keyboard] Han60 QMK / VIA Support (qmk#15332)
  Convert ai03/orbit to SPLIT_KEYBOARD (qmk#15340)
  Convert not_so_minidox to SPLIT_KEYBOARD (qmk#15306)
  Tidy up `SLEEP_LED_ENABLE` rules (qmk#15362)
  [Keyboard] Add support for Mode SixtyFive M65HA and M65HI (qmk#14685)
  Implement MAGIC_TOGGLE_CONTROL_CAPSLOCK (qmk#15368)
  Rename Layout Macros for TKLs with F13 keys (qmk#15361)
  [Docs] Reorder functions in Understanding QMK (qmk#15357)
  [Keyboard] Fix up Endgame34 (qmk#15366)
  [Keyboard] Fix compilation issues for Ploopy Trackball classic (qmk#15364)
  [Keyboard] Add missng define for 4x6 Tractyl Manuform (qmk#15363)
  [Core] Added chconf.h for WB32 (qmk#15359)
  [Keyboard] kangaroo improvements (qmk#15350)
  [Keyboard] Convert ergoinu to SPLIT_KEYBOARD (qmk#15305)
  [Keymap] Keebio Sinc layout with macOS support (qmk#15324)
  Fixup paths for `ramonimbao/wete/v2`. (qmk#15360)
  ...
  • Loading branch information
Carlos Cardoso committed Dec 2, 2021
2 parents f4a446b + 3c0a910 commit 09b3951
Show file tree
Hide file tree
Showing 2,233 changed files with 11,102 additions and 7,769 deletions.
31 changes: 30 additions & 1 deletion builddefs/mcu_selection.mk
View file
Original file line number Diff line number Diff line change
Expand Up @@ -540,10 +540,39 @@ ifneq (,$(filter $(MCU),STM32L412 STM32L422))
UF2_FAMILY ?= STM32L4
endif

ifneq ($(findstring WB32F3G71, $(MCU)),)
# Cortex version
MCU = cortex-m3

# ARM version, CORTEX-M0/M1 are 6, CORTEX-M3/M4/M7 are 7
ARMV = 7

## chip/board settings
# - the next two should match the directories in
# <chibios>/os/hal/ports/$(MCU_FAMILY)/$(MCU_SERIES)
MCU_FAMILY = WB32
MCU_SERIES = WB32F3G71xx

# Linker script to use
# - it should exist either in <chibios>/os/common/ports/ARMCMx/compilers/GCC/ld/
# or <keyboard_dir>/ld/
MCU_LDSCRIPT ?= WB32F3G71x9

# Startup code to use
# - it should exist in <chibios>/os/common/startup/ARMCMx/compilers/GCC/mk/
MCU_STARTUP ?= wb32f3g71xx

# Board: it should exist either in <chibios>/os/hal/boards/,
# <keyboard_dir>/boards/, or drivers/boards/
BOARD ?= GENERIC_WB32_F3G71XX

USE_FPU ?= no
endif

ifneq ($(findstring GD32VF103, $(MCU)),)
# RISC-V
MCU = risc-v

# RISC-V extensions and abi configuration
MCU_ARCH = rv32imac
MCU_ABI = ilp32
Expand Down
4 changes: 2 additions & 2 deletions data/schemas/keyboard.jsonschema
View file
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@
},
"processor": {
"type": "string",
"enum": ["cortex-m0", "cortex-m0plus", "cortex-m3", "cortex-m4", "MKL26Z64", "MK20DX128", "MK20DX256", "MK66FX1M0", "STM32F042", "STM32F072", "STM32F103", "STM32F303", "STM32F401", "STM32F405", "STM32F407", "STM32F411", "STM32F446", "STM32G431", "STM32G474", "STM32L412", "STM32L422", "STM32L433", "STM32L443", "GD32VF103", "atmega16u2", "atmega32u2", "atmega16u4", "atmega32u4", "at90usb162", "at90usb646", "at90usb647", "at90usb1286", "at90usb1287", "atmega32a", "atmega328p", "atmega328", "attiny85", "unknown"]
"enum": ["cortex-m0", "cortex-m0plus", "cortex-m3", "cortex-m4", "MKL26Z64", "MK20DX128", "MK20DX256", "MK66FX1M0", "STM32F042", "STM32F072", "STM32F103", "STM32F303", "STM32F401", "STM32F405", "STM32F407", "STM32F411", "STM32F446", "STM32G431", "STM32G474", "STM32L412", "STM32L422", "STM32L433", "STM32L443", "GD32VF103", "WB32F3G71", "atmega16u2", "atmega32u2", "atmega16u4", "atmega32u4", "at90usb162", "at90usb646", "at90usb647", "at90usb1286", "at90usb1287", "atmega32a", "atmega328p", "atmega328", "attiny85", "unknown"]
},
"audio": {
"type": "object",
Expand Down Expand Up @@ -57,7 +57,7 @@
},
"bootloader": {
"type": "string",
"enum": ["atmel-dfu", "bootloadhid", "bootloadHID", "caterina", "halfkay", "kiibohd", "lufa-dfu", "lufa-ms", "micronucleus", "qmk-dfu", "qmk-hid", "stm32-dfu", "stm32duino", "gd32v-dfu", "unknown", "usbasploader", "USBasp", "tinyuf2"],
"enum": ["atmel-dfu", "bootloadhid", "bootloadHID", "caterina", "halfkay", "kiibohd", "lufa-dfu", "lufa-ms", "micronucleus", "qmk-dfu", "qmk-hid", "stm32-dfu", "stm32duino", "gd32v-dfu", "wb32-dfu", "unknown", "usbasploader", "USBasp", "tinyuf2"],
},
"bootloader_instructions": {
"type": "string",
Expand Down
2 changes: 0 additions & 2 deletions data/templates/avr/rules.mk
View file
Original file line number Diff line number Diff line change
Expand Up @@ -12,8 +12,6 @@ MOUSEKEY_ENABLE = yes # Mouse keys
EXTRAKEY_ENABLE = yes # Audio control and System control
CONSOLE_ENABLE = no # Console for debug
COMMAND_ENABLE = no # Commands for debug and configuration
# Do not enable SLEEP_LED_ENABLE. it uses the same timer as BACKLIGHT_ENABLE
SLEEP_LED_ENABLE = no # Breathing sleep LED during USB suspend
# if this doesn't work, see here: https://github.com/tmk/tmk_keyboard/wiki/FAQ#nkro-doesnt-work
NKRO_ENABLE = no # USB Nkey Rollover
BACKLIGHT_ENABLE = no # Enable keyboard backlight functionality
Expand Down
2 changes: 0 additions & 2 deletions data/templates/ps2avrgb/rules.mk
View file
Original file line number Diff line number Diff line change
Expand Up @@ -12,8 +12,6 @@ MOUSEKEY_ENABLE = yes # Mouse keys
EXTRAKEY_ENABLE = yes # Audio control and System control
CONSOLE_ENABLE = no # Console for debug
COMMAND_ENABLE = no # Commands for debug and configuration
# Do not enable SLEEP_LED_ENABLE. it uses the same timer as BACKLIGHT_ENABLE
SLEEP_LED_ENABLE = no # Breathing sleep LED during USB suspend
BACKLIGHT_ENABLE = no # Enable keyboard backlight functionality
RGBLIGHT_ENABLE = no # Enable keyboard RGB underglow
WS2812_DRIVER = i2c
457 changes: 457 additions & 0 deletions docs/ChangeLog/20211127.md
View file

Large diffs are not rendered by default.

2 changes: 1 addition & 1 deletion docs/_summary.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -129,7 +129,7 @@
* Breaking Changes
* [Overview](breaking_changes.md)
* [My Pull Request Was Flagged](breaking_changes_instructions.md)
* [Most Recent ChangeLog](ChangeLog/20210529.md "QMK v0.13.0 - 2021 May 29")
* [Most Recent ChangeLog](ChangeLog/20211127.md "QMK v0.15.0 - 2021 Nov 27")
* [Past Breaking Changes](breaking_changes_history.md)

* C Development
Expand Down
32 changes: 23 additions & 9 deletions docs/breaking_changes.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,10 +2,13 @@

This document describes QMK's Breaking Change process. A Breaking Change is any change which modifies how QMK behaves in a way that in incompatible or potentially dangerous. We limit these changes so that users can have confidence that updating their QMK tree will not break their keymaps.

This also includes any keyboard moves within the repository.

The breaking change period is when we will merge PR's that change QMK in dangerous or unexpected ways. There is a built-in period of testing so we are confident that any problems caused are rare or unable to be predicted.

## What has been included in past Breaking Changes?

* [2021 Nov 27](ChangeLog/20211127.md)
* [2021 Aug 28](ChangeLog/20210828.md)
* [2021 May 29](ChangeLog/20210529.md)
* [2021 Feb 27](ChangeLog/20210227.md)
Expand All @@ -17,16 +20,17 @@ The breaking change period is when we will merge PR's that change QMK in dangero

## When is the next Breaking Change?

The next Breaking Change is scheduled for August 28, 2021.
The next Breaking Change is scheduled for February 26, 2022.

### Important Dates

* [x] 2021 Aug 29 - `develop` is created. Each push to `master` is subsequently merged to `develop`
* [ ] 2021 Oct 31 - `develop` closed to new PR's.
* [ ] 2021 Oct 31 - Call for testers.
* [ ] 2021 Nov 26 - `master` is locked, no PR's merged.
* [ ] 2021 Nov 28 - Merge `develop` to `master`.
* [ ] 2021 Nov 28 - `master` is unlocked. PR's can be merged again.
* [x] 2021 Nov 27 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
* [ ] 2022 Jan 31 - `develop` closed to new PR's.
* [ ] 2022 Jan 31 - Call for testers.
* [ ] 2022 Feb 12 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
* [ ] 2022 Feb 24 - `master` is locked, no PR's merged.
* [ ] 2022 Feb 26 - Merge `develop` to `master`.
* [ ] 2022 Feb 26 - `master` is unlocked. PR's can be merged again.

## What changes will be included?

Expand All @@ -36,8 +40,10 @@ If you want your breaking change to be included in this round you need to create

Criteria for acceptance:

* PR is complete and ready to merge
* PR has a ChangeLog
* The PR is complete and ready to merge
* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20220226`.
* This should be in Markdown format, with a name in the format `PR12345.md`, substituting the digits for your PR's ID.
* One strong recommendation that the ChangeLog document matches the PR description on GitHub, so as to ensure traceability.

# Checklists

Expand Down Expand Up @@ -68,6 +74,14 @@ This happens immediately after the previous `develop` branch is merged.
* [ ] GitHub PR
* [ ] https://reddit.com/r/olkb

## 2 Weeks Before Merge

* `develop` is now closed to existing PR merges, only bugfixes for previous merges may be included
* Post call for testers
* [ ] Discord
* [ ] GitHub PR
* [ ] https://reddit.com/r/olkb

## 1 Week Before Merge

* Announce that master will be closed from <2 Days Before> to <Day of Merge>
Expand Down
1 change: 1 addition & 0 deletions docs/breaking_changes_history.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,7 @@

This page links to all previous changelogs from the QMK Breaking Changes process.

* [2021 Nov 27](ChangeLog/20211127.md) - version 0.15.0
* [2021 Aug 28](ChangeLog/20210828.md) - version 0.14.0
* [2021 May 29](ChangeLog/20210529.md) - version 0.13.0
* [2021 Feb 27](ChangeLog/20210227.md) - version 0.12.0
Expand Down
4 changes: 4 additions & 0 deletions docs/compatible_microcontrollers.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -37,6 +37,10 @@ You can also use any ARM chip with USB that [ChibiOS](https://www.chibios.org) s
* [STM32L422](https://www.st.com/en/microcontrollers-microprocessors/stm32l4x2.html)
* [STM32L433](https://www.st.com/en/microcontrollers-microprocessors/stm32l4x3.html)
* [STM32L443](https://www.st.com/en/microcontrollers-microprocessors/stm32l4x3.html)

### WestBerryTech (WB32)

* [WB32F3G71xx](http://www.westberrytech.com)

### NXP (Kinetis)

Expand Down
15 changes: 1 addition & 14 deletions docs/feature_encoders.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -46,27 +46,14 @@ For 4× encoders you also can assign default position if encoder skips pulses wh
## Split Keyboards
The above is enough for split keyboards that are symmetrical, i.e. the halves have the same number of encoders and they are on the same pins.
If the halves are not symmetrical, you can define the pinout (and optionally, resolutions) of the right half separately.
The left half will use the definitions above.
If you are using different pinouts for the encoders on each half of a split keyboard, you can define the pinout (and optionally, resolutions) for the right half like this:
```c
#define ENCODERS_PAD_A_RIGHT { encoder1a, encoder2a }
#define ENCODERS_PAD_B_RIGHT { encoder1b, encoder2b }
#define ENCODER_RESOLUTIONS_RIGHT { 2, 4 }
```
If only the right half has encoders, you must still define an empty array for the left pads (and resolutions, if you define `ENCODER_RESOLUTIONS_RIGHT`).
```c
#define ENCODERS_PAD_A { }
#define ENCODERS_PAD_B { }
#define ENCODER_RESOLUTIONS { }
#define ENCODERS_PAD_A_RIGHT { encoder1a, encoder2a }
#define ENCODERS_PAD_B_RIGHT { encoder1b, encoder2b }
#define ENCODER_RESOLUTIONS_RIGHT { 2, 4 }
```
## Callbacks
The callback functions can be inserted into your `<keyboard>.c`:
Expand Down
3 changes: 2 additions & 1 deletion docs/feature_key_lock.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -19,4 +19,5 @@ First, enable Key Lock by setting `KEY_LOCK_ENABLE = yes` in your `rules.mk`. Th
Key Lock is only able to hold standard action keys and [One Shot modifier](one_shot_keys.md) keys (for example, if you have your Shift defined as `OSM(KC_LSFT)`).
This does not include any of the QMK special functions (except One Shot modifiers), or shifted versions of keys such as `KC_LPRN`. If it's in the [Basic Keycodes](keycodes_basic.md) list, it can be held.

Switching layers will not cancel the Key Lock.
Switching layers will not cancel the Key Lock. The Key Lock can be cancelled by calling the `cancel_key_lock()` function.

4 changes: 3 additions & 1 deletion docs/feature_swap_hands.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -27,5 +27,7 @@ Note that the array indices are reversed same as the matrix and the values are o
|`SH_MON` |Swaps hands when pressed, returns to normal when released (momentary). |
|`SH_MOFF` |Momentarily turns off swap. |
|`SH_TG` |Toggles swap on and off with every key press. |
|`SH_TT` |Toggles with a tap; momentary when held. |
|`SH_TT` |Momentary swap when held, toggles with repeated taps (see below). |
|`SH_OS` |One shot swap hands: toggles while pressed or until next key press. |

`SH_TT` swap-hands tap-toggle key is similar to [layer tap-toggle](feature_layers.md?id=switching-and-toggling-layers). Tapping repeatedly (5 taps by default) will toggle swap-hands on or off, like `SH_TG`. Tap-toggle count can be changed by defining a value for `TAPPING_TOGGLE`.
1 change: 1 addition & 0 deletions docs/keycodes.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -326,6 +326,7 @@ See also: [Magic Keycodes](keycodes_magic.md)
|----------------------------------|---------|--------------------------------------------------------------------------|
|`MAGIC_SWAP_CONTROL_CAPSLOCK` |`CL_SWAP`|Swap Caps Lock and Left Control |
|`MAGIC_UNSWAP_CONTROL_CAPSLOCK` |`CL_NORM`|Unswap Caps Lock and Left Control |
|`MAGIC_TOGGLE_CONTROL_CAPSLOCK` |`CL_TOGG`|Toggle Caps Lock and Left Control swap |
|`MAGIC_CAPSLOCK_TO_CONTROL` |`CL_CTRL`|Treat Caps Lock as Control |
|`MAGIC_UNCAPSLOCK_TO_CONTROL` |`CL_CAPS`|Stop treating Caps Lock as Control |
|`MAGIC_SWAP_LCTL_LGUI` |`LCG_SWP`|Swap Left Control and GUI |
Expand Down
1 change: 1 addition & 0 deletions docs/keycodes_magic.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,7 @@
|----------------------------------|---------|--------------------------------------------------------------------------|
|`MAGIC_SWAP_CONTROL_CAPSLOCK` |`CL_SWAP`|Swap Caps Lock and Left Control |
|`MAGIC_UNSWAP_CONTROL_CAPSLOCK` |`CL_NORM`|Unswap Caps Lock and Left Control |
|`MAGIC_TOGGLE_CONTROL_CAPSLOCK` |`CL_TOGG`|Toggle Caps Lock and Left Control swap |
|`MAGIC_CAPSLOCK_TO_CONTROL` |`CL_CTRL`|Treat Caps Lock as Control |
|`MAGIC_UNCAPSLOCK_TO_CONTROL` |`CL_CAPS`|Stop treating Caps Lock as Control |
|`MAGIC_SWAP_LCTL_LGUI` |`LCG_SWP`|Swap Left Control and GUI |
Expand Down
4 changes: 4 additions & 0 deletions docs/pr_checklist.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -118,6 +118,10 @@ Also, specific to ChibiOS:
## Core PRs
- must now target `develop` branch, which will subsequently be merged back to `master` on the breaking changes timeline
- any support for new hardware now requires a corresponding test board under `keyboards/handwired/onekey`
- for new MCUs, a new "child" keyboard should be added that targets your newly-added MCU, so that builds can be verified
- for new hardware support such as display panels, core-side matrix implementations, or other peripherals, an associated keymap should be provided
- if an existing keymap exists that can leverage this functionality this may not be required (e.g. a new RGB driver chip, supported by the `rgb` keymap) -- consult with the QMK Collaborators on Discord to determine if there is sufficient overlap already
- other requirements are at the discretion of QMK collaborators
- core is a lot more subjective given the breadth of posted changes
Expand Down
Loading

0 comments on commit 09b3951

Please sign in to comment.