mirror of
https://github.com/qmk/qmk_firmware.git
synced 2026-09-29 21:38:47 +02:00
Merge remote-tracking branch 'upstream/develop' into xap
This commit is contained in:
Nick Brassel
@@ -0,0 +1,135 @@
|
||||
# QMK Breaking Changes - 2025 February 23 Changelog
|
||||
|
||||
## Notable Features
|
||||
|
||||
### Community Modules ([#24848](https://github.com/qmk/qmk_firmware/pull/24848))
|
||||
|
||||
Community Modules are a feature within QMK which allows code to be implemented by third parties, making it available for other people to import into their own builds.
|
||||
|
||||
These modules can provide implementations which override or enhance normal QMK processing; initialization, key processing, suspend, and shutdown are some of the provided hooks which modules may currently implement.
|
||||
|
||||
See the [Community Modules documentation](../features/community_modules) for more information, including the full list of available hooks.
|
||||
|
||||
First-class support for [External Userspace](../newbs_external_userspace) is included out of the box, so there's even more reason to take the plunge and convert your keymap builds to a userspace repository!
|
||||
|
||||
::: tip
|
||||
An example with a new keycode and some debugging information in the QMK repository [lives here](https://github.com/qmk/qmk_firmware/tree/master/modules/qmk/hello_world), and a community module port of [getreuer's SOCD Cleaner](https://getreuer.info/posts/keyboards/socd-cleaner/) can be found in [tzarc's modules repo](https://github.com/tzarc/qmk_modules).
|
||||
:::
|
||||
|
||||
### Chordal Hold ([#24560](https://github.com/qmk/qmk_firmware/pull/24560))
|
||||
|
||||
Chordal Hold implements, by default, an "opposite hands" rule. Suppose a tap-hold key is pressed and then, before the tapping term, another key is pressed. With Chordal Hold, the tap-hold key is settled as tapped if the two keys are on the same hand.
|
||||
|
||||
Chordal Hold may be useful to avoid accidental modifier activation with mod-taps, particularly in rolled keypresses when using home row mods.
|
||||
|
||||
See the [Chordal Hold documentation](../tap_hold#chordal-hold) for more information.
|
||||
|
||||
## Changes Requiring User Action
|
||||
|
||||
### Updated Keyboard Codebases
|
||||
|
||||
| Old Keyboard Name | New Keyboard Name |
|
||||
|-------------------------|-----------------------------|
|
||||
| cxt_studio | cxt_studio/12e4 |
|
||||
| ergodox_stm32 | handwired/ergodox_stm32 |
|
||||
| ploopyco/mouse | ploopyco/mouse/rev1_002 |
|
||||
| ploopyco/trackball/rev1 | ploopyco/trackball/rev1_004 |
|
||||
| ymdk/id75 | ymdk/id75/f103 |
|
||||
|
||||
## Deprecation Notices
|
||||
|
||||
In line with the [notice period](../support_deprecation_policy#how-much-advance-notice-will-be-given), deprecation notices for larger items are listed here.
|
||||
|
||||
### DEFAULT_FOLDER removal ([#24836](https://github.com/qmk/qmk_firmware/pull/24836))
|
||||
|
||||
`DEFAULT_FOLDER` was originally introduced to work around limitations within the build system.
|
||||
Parent folders containing common configuration would create invalid build targets.
|
||||
|
||||
With the introduction of [`keyboard.json`](./20240526#keyboard-json) as a configuration file, the build system now has a consistent method to detect build targets.
|
||||
The `DEFAULT_FOLDER` functionality is now redundant and the intent is for `rules.mk` to become pure configuration.
|
||||
|
||||
Backwards compatibility of build targets has been maintained where possible.
|
||||
|
||||
## Full changelist
|
||||
|
||||
Core:
|
||||
* Chaining OSL and MO ([#23065](https://github.com/qmk/qmk_firmware/pull/23065))
|
||||
* Add extra keymap for EurKEY layout ([#24241](https://github.com/qmk/qmk_firmware/pull/24241))
|
||||
* Add leader_add_user callback ([#24266](https://github.com/qmk/qmk_firmware/pull/24266))
|
||||
* always return audio pin to 0 on ARM ([#24503](https://github.com/qmk/qmk_firmware/pull/24503))
|
||||
* Update Starlight matrix effects ([#24521](https://github.com/qmk/qmk_firmware/pull/24521))
|
||||
* Refactor Hue Breathing matrix effect with runner ([#24525](https://github.com/qmk/qmk_firmware/pull/24525))
|
||||
* Ensure timer_read() is safe to call from interrupt handlers on ARM ([#24529](https://github.com/qmk/qmk_firmware/pull/24529))
|
||||
* Update Raindrops effect to respect LED range limits ([#24531](https://github.com/qmk/qmk_firmware/pull/24531))
|
||||
* Add Chordal Hold, an "opposite hands rule" tap-hold option similar to Achordion, Bilateral Combinations. ([#24560](https://github.com/qmk/qmk_firmware/pull/24560))
|
||||
* Azoteq - improve I2C behaviour while polling. ([#24611](https://github.com/qmk/qmk_firmware/pull/24611))
|
||||
* macOS install: remove bad ARM toolchains ([#24637](https://github.com/qmk/qmk_firmware/pull/24637))
|
||||
* small refactoring of TIMER_DIFF ([#24678](https://github.com/qmk/qmk_firmware/pull/24678))
|
||||
* Subscript alef correction ([#24707](https://github.com/qmk/qmk_firmware/pull/24707))
|
||||
* Created SH1107 driver for quantum painter ([#24724](https://github.com/qmk/qmk_firmware/pull/24724))
|
||||
* [CI] Regenerate Files ([#24772](https://github.com/qmk/qmk_firmware/pull/24772))
|
||||
* Patch up issue for inverted complementary output on Backlight ([#24794](https://github.com/qmk/qmk_firmware/pull/24794))
|
||||
* Patch up issue when compile with APA102 driver ([#24800](https://github.com/qmk/qmk_firmware/pull/24800))
|
||||
* Consolidate send_string implementations. ([#24817](https://github.com/qmk/qmk_firmware/pull/24817))
|
||||
* Consolidate timer_elapsed implementations ([#24830](https://github.com/qmk/qmk_firmware/pull/24830))
|
||||
* `i2c_master`: remove deprecated functions ([#24832](https://github.com/qmk/qmk_firmware/pull/24832))
|
||||
* Resolve keyboard_aliases when processing keyboard make targets ([#24834](https://github.com/qmk/qmk_firmware/pull/24834))
|
||||
* LED drivers: remove deprecated defines ([#24837](https://github.com/qmk/qmk_firmware/pull/24837))
|
||||
* `ferris/0_1`: update I2C API usage ([#24839](https://github.com/qmk/qmk_firmware/pull/24839))
|
||||
* Unify i2c_master headers ([#24846](https://github.com/qmk/qmk_firmware/pull/24846))
|
||||
* Community modules ([#24848](https://github.com/qmk/qmk_firmware/pull/24848))
|
||||
* Relocate base WS2812 code ([#24850](https://github.com/qmk/qmk_firmware/pull/24850))
|
||||
* Unify UART headers ([#24855](https://github.com/qmk/qmk_firmware/pull/24855))
|
||||
* Unify spi_master headers ([#24857](https://github.com/qmk/qmk_firmware/pull/24857))
|
||||
* Invoke `process_record_via` after `_user`/`_kb` have a chance to handle it. ([#24879](https://github.com/qmk/qmk_firmware/pull/24879))
|
||||
|
||||
CLI:
|
||||
* Extend lint to reject 'blank' files ([#23994](https://github.com/qmk/qmk_firmware/pull/23994))
|
||||
* `qmk docs`: restore `--port` and `--browser` arguments ([#24623](https://github.com/qmk/qmk_firmware/pull/24623))
|
||||
* Update via2json layout macro searching ([#24640](https://github.com/qmk/qmk_firmware/pull/24640))
|
||||
* Change `new-keymap` keymap name prompt ([#24701](https://github.com/qmk/qmk_firmware/pull/24701))
|
||||
* default_keyboard.h generation tweaks ([#24715](https://github.com/qmk/qmk_firmware/pull/24715))
|
||||
* Ensure `qmk flash` rejects invalid files for uf2 compatible bootloaders ([#24802](https://github.com/qmk/qmk_firmware/pull/24802))
|
||||
* Reject readme dummy content ([#24913](https://github.com/qmk/qmk_firmware/pull/24913))
|
||||
|
||||
Submodule updates:
|
||||
* chibios: usb_main: remove OTG sof workaround ([#24259](https://github.com/qmk/qmk_firmware/pull/24259))
|
||||
* Update ChibiOS to latest stable branch. ([#24651](https://github.com/qmk/qmk_firmware/pull/24651))
|
||||
* Update ChibiOS `stable_21.11.x`. ([#24714](https://github.com/qmk/qmk_firmware/pull/24714))
|
||||
* Update ChibiOS-Contrib. ([#24803](https://github.com/qmk/qmk_firmware/pull/24803))
|
||||
|
||||
Keyboards:
|
||||
* refactor: move ymdk/id75 to revision ([#24590](https://github.com/qmk/qmk_firmware/pull/24590))
|
||||
* skyloong/gk61: Remove overriding of core keycode behaviour ([#24655](https://github.com/qmk/qmk_firmware/pull/24655))
|
||||
* moky/moky88: Remove use of deprecated defines ([#24656](https://github.com/qmk/qmk_firmware/pull/24656))
|
||||
* Updating Promenade keyboard (Missing keys in matrix, other minor changes to keymap) ([#24705](https://github.com/qmk/qmk_firmware/pull/24705))
|
||||
* Moving cxt_studio keyboard to own folder ([#24748](https://github.com/qmk/qmk_firmware/pull/24748))
|
||||
* Add CXT Studio 12E3 keyboard ([#24749](https://github.com/qmk/qmk_firmware/pull/24749))
|
||||
* Add Silakka54 keyboard ([#24757](https://github.com/qmk/qmk_firmware/pull/24757))
|
||||
* Add more layout for skiller_sgk50_s4 ([#24784](https://github.com/qmk/qmk_firmware/pull/24784))
|
||||
* Add watchdog service to RGBKB Sol 3 ([#24786](https://github.com/qmk/qmk_firmware/pull/24786))
|
||||
* Migrate some DEFAULT_FOLDER to keyboard_aliases.hjson ([#24835](https://github.com/qmk/qmk_firmware/pull/24835))
|
||||
* Remove DEFAULT_FOLDER where keyboard aliases already exists ([#24838](https://github.com/qmk/qmk_firmware/pull/24838))
|
||||
* Migrate some DEFAULT_FOLDER to keyboard_aliases.hjson ([#24845](https://github.com/qmk/qmk_firmware/pull/24845))
|
||||
* Update for 'A-JAZZ AKC084' ('A-JAZZ AKP846') ([#24868](https://github.com/qmk/qmk_firmware/pull/24868))
|
||||
* handwired/xealous - Remove DEFAULT_FOLDER ([#24877](https://github.com/qmk/qmk_firmware/pull/24877))
|
||||
* Updates to Ploopy Classic, Mouse, and Thumb for RP2040 hardware upgrade ([#24880](https://github.com/qmk/qmk_firmware/pull/24880))
|
||||
* Move Ergodox STM32 to handwired folder ([#24903](https://github.com/qmk/qmk_firmware/pull/24903))
|
||||
* Remove readme dummy content ([#24912](https://github.com/qmk/qmk_firmware/pull/24912))
|
||||
* Migrate some DEFAULT_FOLDER to keyboard_aliases.hjson ([#24915](https://github.com/qmk/qmk_firmware/pull/24915))
|
||||
* Migrate some DEFAULT_FOLDER to keyboard_aliases.hjson ([#24938](https://github.com/qmk/qmk_firmware/pull/24938))
|
||||
|
||||
Keyboard fixes:
|
||||
* Fix up CI with `DEFAULT_FOLDER`. ([#24842](https://github.com/qmk/qmk_firmware/pull/24842))
|
||||
* rgbkb/pan - Remove invalid build target ([#24844](https://github.com/qmk/qmk_firmware/pull/24844))
|
||||
|
||||
Others:
|
||||
* Formally deprecate DEFAULT_FOLDER ([#24836](https://github.com/qmk/qmk_firmware/pull/24836))
|
||||
* Correct I2C API reference ([#24840](https://github.com/qmk/qmk_firmware/pull/24840))
|
||||
|
||||
Bugs:
|
||||
* Retro Tapping Re-Write; Key Roll Fix ([#23641](https://github.com/qmk/qmk_firmware/pull/23641))
|
||||
* Fix Quantum Painter compiliation issues with heavy optimization ([#24667](https://github.com/qmk/qmk_firmware/pull/24667))
|
||||
* Bugfix and update for AT32F415 ([#24807](https://github.com/qmk/qmk_firmware/pull/24807))
|
||||
* Fix for Chordal Hold: stuck mods when mod-taps are pressed in a stuttered sequence. ([#24878](https://github.com/qmk/qmk_firmware/pull/24878))
|
||||
* fix EEPROM driver for STM32L0/1 cat.1 devices ([#24928](https://github.com/qmk/qmk_firmware/pull/24928))
|
||||
+2
-1
@@ -60,6 +60,7 @@
|
||||
"items": [
|
||||
{ "text": "Customizing Functionality", "link": "/custom_quantum_functions" },
|
||||
{ "text": "Driver Installation with Zadig", "link": "/driver_installation_zadig" },
|
||||
{ "text": "Community Modules", "link": "/features/community_modules" },
|
||||
{ "text": "Keymap Overview", "link": "/keymap" },
|
||||
{
|
||||
"text": "Development Environments",
|
||||
@@ -207,7 +208,7 @@
|
||||
{ "text": "My Pull Request Was Flagged", "link": "/breaking_changes_instructions" },
|
||||
{
|
||||
"text": "Most Recent ChangeLog",
|
||||
"link": "/ChangeLog/20241124"
|
||||
"link": "/ChangeLog/20250223"
|
||||
},
|
||||
{ "text": "Past Breaking Changes", "link": "/breaking_changes_history" },
|
||||
{ "text": "Deprecation Policy", "link": "/support_deprecation_policy" }
|
||||
|
||||
+10
-10
@@ -10,25 +10,25 @@ Practically, this means QMK merges the `develop` branch into the `master` branch
|
||||
|
||||
## What has been included in past Breaking Changes?
|
||||
|
||||
* [2025 Feb 23](ChangeLog/20250223)
|
||||
* [2024 Nov 24](ChangeLog/20241124)
|
||||
* [2024 Aug 25](ChangeLog/20240825)
|
||||
* [2024 May 26](ChangeLog/20240526)
|
||||
* [Older Breaking Changes](breaking_changes_history)
|
||||
|
||||
## When is the next Breaking Change?
|
||||
|
||||
The next Breaking Change is scheduled for February 23, 2025.
|
||||
The next Breaking Change is scheduled for May 25, 2025.
|
||||
|
||||
### Important Dates
|
||||
|
||||
* 2024 Nov 24 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
|
||||
* 2025 Jan 26 - `develop` closed to new PRs.
|
||||
* 2025 Jan 26 - Call for testers.
|
||||
* 2025 Feb 9 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
|
||||
* 2025 Feb 16 - `develop` is locked, only critical bugfix PRs merged.
|
||||
* 2024 Nov 21 - `master` is locked, no PRs merged.
|
||||
* 2025 Feb 23 - Merge `develop` to `master`.
|
||||
* 2025 Feb 23 - `master` is unlocked. PRs can be merged again.
|
||||
* 2025 Feb 23 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
|
||||
* 2025 Apr 27 - `develop` closed to new PRs.
|
||||
* 2025 Apr 27 - Call for testers.
|
||||
* 2025 May 11 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
|
||||
* 2025 May 18 - `develop` is locked, only critical bugfix PRs merged.
|
||||
* 2025 May 23 - `master` is locked, no PRs merged.
|
||||
* 2025 May 25 - Merge `develop` to `master`.
|
||||
* 2025 May 25 - `master` is unlocked. PRs can be merged again.
|
||||
|
||||
## What changes will be included?
|
||||
|
||||
|
||||
@@ -2,6 +2,7 @@
|
||||
|
||||
This page links to all previous changelogs from the QMK Breaking Changes process.
|
||||
|
||||
* [2025 Feb 23](ChangeLog/20250223) - version 0.28.0
|
||||
* [2024 Nov 24](ChangeLog/20241124) - version 0.27.0
|
||||
* [2024 Aug 25](ChangeLog/20240825) - version 0.26.0
|
||||
* [2024 May 26](ChangeLog/20240526) - version 0.25.0
|
||||
|
||||
@@ -9,12 +9,19 @@ This page does not assume any special knowledge about QMK, but reading [Understa
|
||||
We have structured QMK as a hierarchy:
|
||||
|
||||
* Core (`_quantum`)
|
||||
* Community Module (`_<module>`)
|
||||
* Community Module -> Keyboard/Revision (`_<module>_kb`)
|
||||
* Community Module -> Keymap (`_<module>_user`)
|
||||
* Keyboard/Revision (`_kb`)
|
||||
* Keymap (`_user`)
|
||||
|
||||
Each of the functions described below can be defined with a `_kb()` suffix or a `_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.
|
||||
When defining functions at the Keyboard/Revision level it is important that your `_kb()` implementation call `_user()` at an appropriate location, otherwise the keymap level function will never be called.
|
||||
|
||||
Functions at the `_<module>_xxx()` level are intended to allow keyboards or keymaps to override or enhance the processing associated with a [community module](/features/community_modules).
|
||||
|
||||
When defining module overrides such as `process_record_<module>()`, the same pattern should be used; the module must invoke `process_record_<module>_kb()` as appropriate.
|
||||
|
||||
# Custom Keycodes
|
||||
|
||||
@@ -99,7 +106,7 @@ These are the three main initialization functions, listed in the order that they
|
||||
* `keyboard_post_init_*` - Happens at the end of the firmware's startup process. This is where you'd want to put "customization" code, for the most part.
|
||||
|
||||
::: warning
|
||||
For most people, the `keyboard_post_init_user` function is what you want to call. For instance, this is where you want to set up things for RGB Underglow.
|
||||
For most people, the `keyboard_post_init_user` function is what you want to implement. For instance, this is where you want to set up things for RGB Underglow.
|
||||
:::
|
||||
|
||||
## Keyboard Pre Initialization code
|
||||
|
||||
@@ -0,0 +1,142 @@
|
||||
# Community Modules
|
||||
|
||||
Community Modules are a feature within QMK which allows code to be implemented by third parties, making it available for other people to import into their own builds.
|
||||
|
||||
These modules can provide implementations which override or enhance normal QMK processing; initialization, key processing, suspend, and shutdown are some of the provided hooks which modules may implement.
|
||||
|
||||
## Adding a Community Module to your build
|
||||
|
||||
Community Modules have first-class support for [External Userspace](/newbs_external_userspace), and QMK strongly recommends using External Userspace for hosting keymaps and Community Modules together.
|
||||
|
||||
Modules must live in either of two locations:
|
||||
|
||||
* `<QMK_USERSPACE>/modules/`
|
||||
* `<QMK_FIRMWARE>/modules/`
|
||||
|
||||
A basic module is provided within QMK itself -- `qmk/hello_world` -- which prints out a notification over [HID console](/faq_debug) after 10 seconds, and adds a new keycode, `COMMUNITY_MODULE_HELLO` (aliased to `CM_HELO`) which types `Hello there.` to the active application when the corresponding key is pressed.
|
||||
|
||||
To add this module to your build, in your keymap's directory create a `keymap.json` with the following content:
|
||||
|
||||
```json
|
||||
{
|
||||
"modules": [
|
||||
"qmk/hello_world"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
If you already have a `keymap.json`, you'll need to manually merge the `modules` section into your keymap.
|
||||
|
||||
::: warning
|
||||
Community Modules are not supported by QMK Configurator. If you wish to use Community Modules, you must build your own firmware.
|
||||
:::
|
||||
|
||||
## Adding a Community Module to your External Userspace
|
||||
|
||||
Module authors are encouraged to provide a git repository on GitHub which may be imported into a user's external userspace. If a user wishes to import a module repository, they can do the following:
|
||||
|
||||
```sh
|
||||
cd /path/to/your/external/userspace
|
||||
mkdir -p modules
|
||||
# Replace the following {user} and {repo} with the author's community module repository
|
||||
git submodule add https://github.com/{user}/{repo}.git modules/{user}
|
||||
git submdule update --init --recursive
|
||||
```
|
||||
|
||||
This will ensure the copy of the module is made in your userspace.
|
||||
|
||||
Add a new entry into your `keymap.json` with the desired modules, replacing `{user}` and `{module_name}` as appropriate:
|
||||
|
||||
```json
|
||||
{
|
||||
"modules": [
|
||||
"qmk/hello_world",
|
||||
"{user}/{module_name}"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
::: info
|
||||
The module listed in `keymap.json` is the relative path within the `modules/` directory. So long as the module is present _somewhere_ under `modules/`, then the `keymap.json` can refer to that path.
|
||||
:::
|
||||
|
||||
## Writing a QMK Community Module
|
||||
|
||||
As stated earlier, Community Module authors are strongly encouraged to provide their modules through git, allowing users to leverage submodules to import functionality.
|
||||
|
||||
### `qmk_module.json`
|
||||
|
||||
A Community Module is denoted by a `qmk_module.json` file such as the following:
|
||||
|
||||
```json
|
||||
{
|
||||
"module_name": "Hello World",
|
||||
"maintainer": "QMK Maintainers",
|
||||
"features": {
|
||||
"deferred_exec": true
|
||||
},
|
||||
"keycodes": [
|
||||
{
|
||||
"key": "COMMUNITY_MODULE_HELLO",
|
||||
"aliases": ["CM_HELO"]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
At minimum, the module must provide the `module_name` and `maintainer` fields.
|
||||
|
||||
The use of `features` matches the definition normally provided within `keyboard.json` and `info.json`, allowing a module to signal to the build system that it has its own dependencies. In the example above, it enables the _deferred executor_ feature whenever the above module is used in a build.
|
||||
|
||||
The `keycodes` array allows a module to provide new keycodes (as well as corresponding aliases) to a keymap.
|
||||
|
||||
### `rules.mk` / `post_rules.mk`
|
||||
|
||||
These two files follows standard QMK build system logic, allowing for `Makefile`-style customisation as if it were present in the keyboard or keymap.
|
||||
|
||||
### `<module>.c`
|
||||
|
||||
This file will be automatically added to the build if the filename matches the directory name. For example, the `qmk/hello_world` module contains a `hello_world.c` file, which is automatically added to the build.
|
||||
|
||||
::: info
|
||||
Other files intended to be included must use the normal method of `SRC += my_file.c` inside `rules.mk`.
|
||||
:::
|
||||
|
||||
::: tip
|
||||
This file should use `ASSERT_COMMUNITY_MODULES_MIN_API_VERSION(1,0,0);` to enforce a minimum version of the API that it requires, ensuring the Community Module is built with a compatible version of QMK. The list of APIs and corresponding version is given at the bottom of this document. Note the use of commas instead of periods.
|
||||
:::
|
||||
|
||||
### `introspection.c` / `introspection.h`
|
||||
|
||||
These two files hook into the keymap introspection logic -- the header is prepended before the user keymap, and the C source file is appended after the user keymap.
|
||||
|
||||
The header may provide definitions which are useful to the user's `keymap.c`.
|
||||
|
||||
The source file may provide functions which allow access to information specified in the user's `keymap.c`.
|
||||
|
||||
::: warning
|
||||
Introspection is a relatively advanced topic within QMK, and existing patterns should be followed. If you need help please [open an issue](https://github.com/qmk/qmk_firmware/issues/new) or [chat with us on Discord](https://discord.gg/qmk).
|
||||
:::
|
||||
|
||||
### Compatible APIs
|
||||
|
||||
Community Modules may provide specializations for the following APIs:
|
||||
|
||||
| Base API | API Format | Example (`hello_world` module) | API Version |
|
||||
|----------------------------|-------------------------------------|----------------------------------------|-------------|
|
||||
| `keyboard_pre_init` | `keyboard_pre_init_<module>` | `keyboard_pre_init_hello_world` | `0.1.0` |
|
||||
| `keyboard_post_init` | `keyboard_post_init_<module>` | `keyboard_post_init_hello_world` | `0.1.0` |
|
||||
| `pre_process_record` | `pre_process_record_<module>` | `pre_process_record_hello_world` | `0.1.0` |
|
||||
| `process_record` | `process_record_<module>` | `process_record_hello_world` | `0.1.0` |
|
||||
| `post_process_record` | `post_process_record_<module>` | `post_process_record_hello_world` | `0.1.0` |
|
||||
| `housekeeping_task` | `housekeeping_task_<module>` | `housekeeping_task_hello_world` | `1.0.0` |
|
||||
| `suspend_power_down` | `suspend_power_down_<module>` | `suspend_power_down_hello_world` | `1.0.0` |
|
||||
| `suspend_wakeup_init` | `suspend_wakeup_init_<module>` | `suspend_wakeup_init_hello_world` | `1.0.0` |
|
||||
| `shutdown` | `shutdown_<module>` | `shutdown_hello_world` | `1.0.0` |
|
||||
| `process_detected_host_os` | `process_detected_host_os_<module>` | `process_detected_host_os_hello_world` | `1.0.0` |
|
||||
|
||||
::: info
|
||||
An unspecified API is disregarded if a Community Module does not provide a specialization for it.
|
||||
:::
|
||||
|
||||
Each API has an equivalent `_<module>_kb()` and `_<module>_user()` hook, as per the normal QMK [`_quantum`, `_kb`, and `_user` functions](/custom_quantum_functions#a-word-on-core-vs-keyboards-vs-keymap).
|
||||
Reference in New Issue
Block a user