lunny/qmk_firmware-mirror
1
0
Fork 0
mirror of https://github.com/qmk/qmk_firmware synced 2024-12-22 08:26:21 +00:00
Code Issues Packages Projects Releases Wiki Activity

Vitepress conversion of docs. (#23795)

Browse Source
This commit is contained in:
Nick Brassel 2024-05-30 12:00:41 +10:00 committed by GitHub
parent 395766657f
commit 6ef9717288
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
357 changed files with 3611 additions and 24208 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
.github/workflows/docs.yml vendored
View File

@ -7,20 +7,26 @@ on:
push: push:
branches: branches:
- master - master
- vitepress
paths: paths:
- 'builddefs/docsgen/**'
- 'tmk_core/**' - 'tmk_core/**'
- 'quantum/**' - 'quantum/**'
- 'platforms/**' - 'platforms/**'
- 'docs/**' - 'docs/**'
- '.github/workflows/docs.yml' - '.github/workflows/docs.yml'
defaults:
run:
shell: bash
jobs: jobs:
generate: generate:
runs-on: ubuntu-latest runs-on: ubuntu-latest
container: ghcr.io/qmk/qmk_cli container: ghcr.io/qmk/qmk_cli
# protect against those who develop with their fork on master # protect against those who develop with their fork on master
if: github.repository == 'qmk/qmk_firmware' if: github.repository == 'qmk/qmk_firmware' || (github.repository == 'tzarc/qmk_firmware' && github.ref == 'refs/heads/vitepress')
steps: steps:
- uses: actions/checkout@v4 - uses: actions/checkout@v4
@ -29,18 +35,51 @@ jobs:
- name: Install dependencies - name: Install dependencies
run: | run: |
apt-get update && apt-get install -y rsync nodejs npm doxygen apt-get update && apt-get install -y rsync doxygen curl
# install nvm
touch $HOME/.bashrc
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
- name: Install node
run: |
source $HOME/.bashrc
nvm install 20
nvm use 20
corepack enable
npm install -g moxygen npm install -g moxygen
- name: Build docs - name: Build docs
run: | run: |
source $HOME/.bashrc
nvm use 20
qmk --verbose generate-docs qmk --verbose generate-docs
touch '.build/docs/.nojekyll'
- name: Set CNAME
if: github.repository == 'qmk/qmk_firmware'
run: |
# Override target CNAME
echo 'docs.qmk.fm' > .build/docs/CNAME
- name: Override CNAME
if: github.repository == 'tzarc/qmk_firmware'
run: |
# Temporarily override target CNAME during development
echo 'vitepress.qmk.fm' > .build/docs/CNAME
- name: Deploy - name: Deploy
if: github.repository == 'qmk/qmk_firmware'
uses: JamesIves/github-pages-deploy-action@v4.6.1 uses: JamesIves/github-pages-deploy-action@v4.6.1
with: with:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} token: ${{ secrets.GITHUB_TOKEN }}
BASE_BRANCH: master branch: gh-pages
BRANCH: gh-pages folder: .build/docs
FOLDER: .build/docs git-config-name: QMK Bot
GIT_CONFIG_EMAIL: hello@qmk.fm git-config-email: hello@qmk.fm
- name: Deploy
if: github.repository == 'tzarc/qmk_firmware'
uses: JamesIves/github-pages-deploy-action@v4.6.1
with:
branch: gh-pages
folder: .build/docs

70
Doxyfile
View File

@ -21,7 +21,7 @@ DOXYFILE_ENCODING = UTF-8
PROJECT_NAME = "QMK Firmware" PROJECT_NAME = "QMK Firmware"
PROJECT_NUMBER = https://github.com/qmk/qmk_firmware PROJECT_NUMBER = https://github.com/qmk/qmk_firmware
PROJECT_BRIEF = "Keyboard controller firmware for Atmel AVR and ARM USB families" PROJECT_BRIEF = "Keyboard controller firmware for Atmel AVR and ARM USB families"
OUTPUT_DIRECTORY = .build/doxygen OUTPUT_DIRECTORY = .build/docs/static/doxygen
ALLOW_UNICODE_NAMES = NO ALLOW_UNICODE_NAMES = NO
OUTPUT_LANGUAGE = English OUTPUT_LANGUAGE = English
BRIEF_MEMBER_DESC = YES BRIEF_MEMBER_DESC = YES
@ -40,8 +40,8 @@ ABBREVIATE_BRIEF = "The $name class" \
ALWAYS_DETAILED_SEC = NO ALWAYS_DETAILED_SEC = NO
INLINE_INHERITED_MEMB = NO INLINE_INHERITED_MEMB = NO
FULL_PATH_NAMES = YES FULL_PATH_NAMES = YES
STRIP_FROM_PATH = STRIP_FROM_PATH =
STRIP_FROM_INC_PATH = STRIP_FROM_INC_PATH =
SHORT_NAMES = NO SHORT_NAMES = NO
JAVADOC_AUTOBRIEF = NO JAVADOC_AUTOBRIEF = NO
QT_AUTOBRIEF = NO QT_AUTOBRIEF = NO
@ -49,13 +49,13 @@ MULTILINE_CPP_IS_BRIEF = NO
INHERIT_DOCS = YES INHERIT_DOCS = YES
SEPARATE_MEMBER_PAGES = NO SEPARATE_MEMBER_PAGES = NO
TAB_SIZE = 4 TAB_SIZE = 4
ALIASES = ALIASES =
TCL_SUBST = TCL_SUBST =
OPTIMIZE_OUTPUT_FOR_C = YES OPTIMIZE_OUTPUT_FOR_C = YES
OPTIMIZE_OUTPUT_JAVA = NO OPTIMIZE_OUTPUT_JAVA = NO
OPTIMIZE_FOR_FORTRAN = NO OPTIMIZE_FOR_FORTRAN = NO
OPTIMIZE_OUTPUT_VHDL = NO OPTIMIZE_OUTPUT_VHDL = NO
EXTENSION_MAPPING = EXTENSION_MAPPING =
MARKDOWN_SUPPORT = YES MARKDOWN_SUPPORT = YES
TOC_INCLUDE_HEADINGS = 2 TOC_INCLUDE_HEADINGS = 2
AUTOLINK_SUPPORT = YES AUTOLINK_SUPPORT = YES
@ -104,14 +104,14 @@ GENERATE_TODOLIST = YES
GENERATE_TESTLIST = YES GENERATE_TESTLIST = YES
GENERATE_BUGLIST = YES GENERATE_BUGLIST = YES
GENERATE_DEPRECATEDLIST= YES GENERATE_DEPRECATEDLIST= YES
ENABLED_SECTIONS = ENABLED_SECTIONS =
MAX_INITIALIZER_LINES = 30 MAX_INITIALIZER_LINES = 30
SHOW_USED_FILES = YES SHOW_USED_FILES = YES
SHOW_FILES = YES SHOW_FILES = YES
SHOW_NAMESPACES = YES SHOW_NAMESPACES = YES
FILE_VERSION_FILTER = FILE_VERSION_FILTER =
LAYOUT_FILE = LAYOUT_FILE =
CITE_BIB_FILES = CITE_BIB_FILES =
#--------------------------------------------------------------------------- #---------------------------------------------------------------------------
# Configuration options related to warning and progress messages # Configuration options related to warning and progress messages
@ -124,7 +124,7 @@ WARN_IF_DOC_ERROR = YES
WARN_NO_PARAMDOC = NO WARN_NO_PARAMDOC = NO
WARN_AS_ERROR = NO WARN_AS_ERROR = NO
WARN_FORMAT = "$file:$line: $text" WARN_FORMAT = "$file:$line: $text"
WARN_LOGFILE = WARN_LOGFILE =
#--------------------------------------------------------------------------- #---------------------------------------------------------------------------
# Configuration options related to the input files # Configuration options related to the input files
@ -143,19 +143,19 @@ FILE_PATTERNS = *.c \
*.hpp \ *.hpp \
*.h++ *.h++
RECURSIVE = YES RECURSIVE = YES
EXCLUDE = EXCLUDE =
EXCLUDE_SYMLINKS = NO EXCLUDE_SYMLINKS = NO
EXCLUDE_PATTERNS = */protocol/arm_atsam/* EXCLUDE_PATTERNS = */protocol/arm_atsam/*
EXCLUDE_SYMBOLS = EXCLUDE_SYMBOLS =
EXAMPLE_PATH = EXAMPLE_PATH =
EXAMPLE_PATTERNS = * EXAMPLE_PATTERNS = *
EXAMPLE_RECURSIVE = NO EXAMPLE_RECURSIVE = NO
IMAGE_PATH = IMAGE_PATH =
INPUT_FILTER = INPUT_FILTER =
FILTER_PATTERNS = FILTER_PATTERNS =
FILTER_SOURCE_FILES = NO FILTER_SOURCE_FILES = NO
FILTER_SOURCE_PATTERNS = FILTER_SOURCE_PATTERNS =
USE_MDFILE_AS_MAINPAGE = USE_MDFILE_AS_MAINPAGE =
#--------------------------------------------------------------------------- #---------------------------------------------------------------------------
# Configuration options related to source browsing # Configuration options related to source browsing
@ -177,7 +177,7 @@ VERBATIM_HEADERS = YES
ALPHABETICAL_INDEX = YES ALPHABETICAL_INDEX = YES
COLS_IN_ALPHA_INDEX = 5 COLS_IN_ALPHA_INDEX = 5
IGNORE_PREFIX = IGNORE_PREFIX =
#--------------------------------------------------------------------------- #---------------------------------------------------------------------------
# Configuration options related to disabled outputs # Configuration options related to disabled outputs
@ -207,18 +207,18 @@ ENABLE_PREPROCESSING = YES
MACRO_EXPANSION = NO MACRO_EXPANSION = NO
EXPAND_ONLY_PREDEF = NO EXPAND_ONLY_PREDEF = NO
SEARCH_INCLUDES = YES SEARCH_INCLUDES = YES
INCLUDE_PATH = INCLUDE_PATH =
INCLUDE_FILE_PATTERNS = INCLUDE_FILE_PATTERNS =
PREDEFINED = __DOXYGEN__ PROGMEM PREDEFINED = __DOXYGEN__ PROGMEM
EXPAND_AS_DEFINED = EXPAND_AS_DEFINED =
SKIP_FUNCTION_MACROS = YES SKIP_FUNCTION_MACROS = YES
#--------------------------------------------------------------------------- #---------------------------------------------------------------------------
# Configuration options related to external references # Configuration options related to external references
#--------------------------------------------------------------------------- #---------------------------------------------------------------------------
TAGFILES = TAGFILES =
GENERATE_TAGFILE = GENERATE_TAGFILE =
ALLEXTERNALS = NO ALLEXTERNALS = NO
EXTERNAL_GROUPS = YES EXTERNAL_GROUPS = YES
EXTERNAL_PAGES = YES EXTERNAL_PAGES = YES
@ -229,14 +229,14 @@ PERL_PATH = /usr/bin/perl
#--------------------------------------------------------------------------- #---------------------------------------------------------------------------
CLASS_DIAGRAMS = YES CLASS_DIAGRAMS = YES
MSCGEN_PATH = MSCGEN_PATH =
DIA_PATH = DIA_PATH =
HIDE_UNDOC_RELATIONS = YES HIDE_UNDOC_RELATIONS = YES
HAVE_DOT = NO HAVE_DOT = NO
DOT_NUM_THREADS = 0 DOT_NUM_THREADS = 0
DOT_FONTNAME = Helvetica DOT_FONTNAME = Helvetica
DOT_FONTSIZE = 10 DOT_FONTSIZE = 10
DOT_FONTPATH = DOT_FONTPATH =
CLASS_GRAPH = YES CLASS_GRAPH = YES
COLLABORATION_GRAPH = YES COLLABORATION_GRAPH = YES
GROUP_GRAPHS = YES GROUP_GRAPHS = YES
@ -251,13 +251,13 @@ GRAPHICAL_HIERARCHY = YES
DIRECTORY_GRAPH = YES DIRECTORY_GRAPH = YES
DOT_IMAGE_FORMAT = png DOT_IMAGE_FORMAT = png
INTERACTIVE_SVG = NO INTERACTIVE_SVG = NO
DOT_PATH = DOT_PATH =
DOTFILE_DIRS = DOTFILE_DIRS =
MSCFILE_DIRS = MSCFILE_DIRS =
DIAFILE_DIRS = DIAFILE_DIRS =
PLANTUML_JAR_PATH = PLANTUML_JAR_PATH =
PLANTUML_CFG_FILE = PLANTUML_CFG_FILE =
PLANTUML_INCLUDE_PATH = PLANTUML_INCLUDE_PATH =
DOT_GRAPH_MAX_NODES = 50 DOT_GRAPH_MAX_NODES = 50
MAX_DOT_GRAPH_DEPTH = 0 MAX_DOT_GRAPH_DEPTH = 0
DOT_TRANSPARENT = NO DOT_TRANSPARENT = NO

5
builddefs/docsgen/.gitignore vendored Normal file
View File

@ -0,0 +1,5 @@
node_modules
.vitepress/cache
.vitepress/.temp
.vitepress/dist
docs

51
builddefs/docsgen/.vitepress/config.mts Normal file
View File

@ -0,0 +1,51 @@
import { defineConfig } from "vitepress";
import { tabsMarkdownPlugin } from "vitepress-plugin-tabs";
import sidebar from "../../../docs/_sidebar.json";
// https://vitepress.dev/reference/site-config
export default defineConfig(({ mode }) => {
const prod = mode === "production";
return {
title: "QMK Firmware",
description: "Documentation for QMK Firmware",
srcDir: prod ? "docs" : "../../docs",
outDir: "../../.build/docs",
cleanUrls: true,
markdown: {
config(md) {
md.use(tabsMarkdownPlugin);
},
},
vite: {
resolve: {
preserveSymlinks: true,
},
},
themeConfig: {
// https://vitepress.dev/reference/default-theme-config
logo: {
light: "/badge-community-light.svg",
dark: "/badge-community-dark.svg",
},
siteTitle: false,
nav: [{ text: "Home", link: "./" }],
search: {
provider: "local",
},
sidebar: sidebar,
socialLinks: [
{ icon: { svg: '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 50 50" width="50px" height="50px"><path d="M 29 3 C 28.0625 3 27.164063 3.382813 26.5 4 C 25.835938 4.617188 25.363281 5.433594 25 6.40625 C 24.355469 8.140625 24.085938 10.394531 24.03125 13.03125 C 19.234375 13.179688 14.820313 14.421875 11.28125 16.46875 C 10.214844 15.46875 8.855469 14.96875 7.5 14.96875 C 6.089844 14.96875 4.675781 15.511719 3.59375 16.59375 C 1.425781 18.761719 1.425781 22.238281 3.59375 24.40625 L 3.84375 24.65625 C 3.3125 26.035156 3 27.488281 3 29 C 3 33.527344 5.566406 37.585938 9.5625 40.4375 C 13.558594 43.289063 19.007813 45 25 45 C 30.992188 45 36.441406 43.289063 40.4375 40.4375 C 44.433594 37.585938 47 33.527344 47 29 C 47 27.488281 46.6875 26.035156 46.15625 24.65625 L 46.40625 24.40625 C 48.574219 22.238281 48.574219 18.761719 46.40625 16.59375 C 45.324219 15.511719 43.910156 14.96875 42.5 14.96875 C 41.144531 14.96875 39.785156 15.46875 38.71875 16.46875 C 35.195313 14.433594 30.800781 13.191406 26.03125 13.03125 C 26.09375 10.546875 26.363281 8.46875 26.875 7.09375 C 27.164063 6.316406 27.527344 5.757813 27.875 5.4375 C 28.222656 5.117188 28.539063 5 29 5 C 29.460938 5 29.683594 5.125 30.03125 5.40625 C 30.378906 5.6875 30.785156 6.148438 31.3125 6.6875 C 32.253906 7.652344 33.695313 8.714844 36.09375 8.9375 C 36.539063 11.238281 38.574219 13 41 13 C 43.75 13 46 10.75 46 8 C 46 5.25 43.75 3 41 3 C 38.605469 3 36.574219 4.710938 36.09375 6.96875 C 34.3125 6.796875 33.527344 6.109375 32.75 5.3125 C 32.300781 4.851563 31.886719 4.3125 31.3125 3.84375 C 30.738281 3.375 29.9375 3 29 3 Z M 41 5 C 42.667969 5 44 6.332031 44 8 C 44 9.667969 42.667969 11 41 11 C 39.332031 11 38 9.667969 38 8 C 38 6.332031 39.332031 5 41 5 Z M 25 15 C 30.609375 15 35.675781 16.613281 39.28125 19.1875 C 42.886719 21.761719 45 25.226563 45 29 C 45 32.773438 42.886719 36.238281 39.28125 38.8125 C 35.675781 41.386719 30.609375 43 25 43 C 19.390625 43 14.324219 41.386719 10.71875 38.8125 C 7.113281 36.238281 5 32.773438 5 29 C 5 25.226563 7.113281 21.761719 10.71875 19.1875 C 14.324219 16.613281 19.390625 15 25 15 Z M 7.5 16.9375 C 8.203125 16.9375 8.914063 17.148438 9.53125 17.59375 C 7.527344 19.03125 5.886719 20.769531 4.75 22.71875 C 3.582031 21.296875 3.660156 19.339844 5 18 C 5.714844 17.285156 6.609375 16.9375 7.5 16.9375 Z M 42.5 16.9375 C 43.390625 16.9375 44.285156 17.285156 45 18 C 46.339844 19.339844 46.417969 21.296875 45.25 22.71875 C 44.113281 20.769531 42.472656 19.03125 40.46875 17.59375 C 41.085938 17.148438 41.796875 16.9375 42.5 16.9375 Z M 17 22 C 14.800781 22 13 23.800781 13 26 C 13 28.199219 14.800781 30 17 30 C 19.199219 30 21 28.199219 21 26 C 21 23.800781 19.199219 22 17 22 Z M 33 22 C 30.800781 22 29 23.800781 29 26 C 29 28.199219 30.800781 30 33 30 C 35.199219 30 37 28.199219 37 26 C 37 23.800781 35.199219 22 33 22 Z M 17 24 C 18.117188 24 19 24.882813 19 26 C 19 27.117188 18.117188 28 17 28 C 15.882813 28 15 27.117188 15 26 C 15 24.882813 15.882813 24 17 24 Z M 33 24 C 34.117188 24 35 24.882813 35 26 C 35 27.117188 34.117188 28 33 28 C 31.882813 28 31 27.117188 31 26 C 31 24.882813 31.882813 24 33 24 Z M 34.15625 33.84375 C 34.101563 33.851563 34.050781 33.859375 34 33.875 C 33.683594 33.9375 33.417969 34.144531 33.28125 34.4375 C 33.28125 34.4375 32.757813 35.164063 31.4375 36 C 30.117188 36.835938 28.058594 37.6875 25 37.6875 C 21.941406 37.6875 19.882813 36.835938 18.5625 36 C 17.242188 35.164063 16.71875 34.4375 16.71875 34.4375 C 16.492188 34.082031 16.066406 33.90625 15.65625 34 C 15.332031 34.082031 15.070313 34.316406 14.957031 34.632813 C 14.84375 34.945313 14.894531 35.292969 15.09375 35.5625 C 15.09375 35.5625 15.863281 36.671875 17.46875 37.6875 C 19.074219 38.703125 21.558594 39.6875 25 39.6875 C 28.441406 39.6875 30.925781 38.703125 32.53125 37.6875 C 34.136719 36.671875 34.90625 35.5625 34.90625 35.5625 C 35.207031 35.273438 35.296875 34.824219 35.128906 34.441406 C 34.960938 34.058594 34.574219 33.820313 34.15625 33.84375 Z"/></svg>' }, link: "https://reddit.com/r/olkb" },
{ icon: "discord", link: "https://discord.gg/qmk" },
{ icon: "github", link: "https://github.com/qmk/qmk_firmware" },
],
}
};
});

18
builddefs/docsgen/.vitepress/theme/QMKLayout.vue Normal file
View File

@ -0,0 +1,18 @@
<script setup>
import DefaultTheme from 'vitepress/theme'
import { useRouter } from 'vitepress'
import { onBeforeMount } from 'vue';
const router = useRouter()
onBeforeMount(async () => {
if (window.location.href.includes('/#/')) {
const newUrl = window.location.href.replace(/\/#\//, '/').replace(/\?id=/, '#');
window.history.replaceState({}, '', newUrl);
await router.go(newUrl);
}
});
</script>
<template>
<DefaultTheme.Layout/>
</template>

19
builddefs/docsgen/.vitepress/theme/custom.css Normal file
View File

@ -0,0 +1,19 @@
/* Override <kbd> as vitepress doesn't put them with borders */
kbd {
border: 1px solid var(--vp-c-text-1);
border-radius: 0.6em;
margin: 0.2em;
padding: 0.2em;
}
:root {
--vp-nav-logo-height: 100%;
}
.logo {
padding-bottom: 0.2em;
}
.VPNavBarTitle.has-sidebar .title {
border-bottom: 0;
}

13
builddefs/docsgen/.vitepress/theme/index.ts Normal file
View File

@ -0,0 +1,13 @@
import type { Theme } from 'vitepress'
import DefaultTheme from 'vitepress/theme'
import { enhanceAppWithTabs } from 'vitepress-plugin-tabs/client'
import QMKLayout from './QMKLayout.vue'
import './custom.css'
export default {
extends: DefaultTheme,
Layout: QMKLayout,
enhanceApp({ app }) {
enhanceAppWithTabs(app)
}
} satisfies Theme

6
builddefs/docsgen/build-docs.sh Executable file
View File

@ -0,0 +1,6 @@
#!/usr/bin/env bash
cd "$(dirname "$(realpath "${BASH_SOURCE[0]}")")"
yarn install
[[ -e docs ]] || ln -sf ../../docs docs
DEBUG='vitepress:*,vite:*' yarn run docs:build

14
builddefs/docsgen/package.json Normal file
View File

@ -0,0 +1,14 @@
{
"license": "GPL-2.0-or-later",
"devDependencies": {
"vite": "^5.2.10",
"vitepress": "^1.1.0",
"vitepress-plugin-tabs": "^0.5.0",
"vue": "^3.4.24"
},
"scripts": {
"docs:dev": "vitepress dev --host 0.0.0.0",
"docs:build": "vitepress build",
"docs:preview": "vitepress preview --host 0.0.0.0"
}
}

5
builddefs/docsgen/start-docs.sh Executable file
View File

@ -0,0 +1,5 @@
#!/usr/bin/env bash
cd "$(dirname "$(realpath "${BASH_SOURCE[0]}")")"
yarn install
DEBUG='vitepress:*,vite:*' yarn run docs:dev

797
builddefs/docsgen/yarn.lock Normal file
View File

File diff suppressed because it is too large Load Diff

0
docs/.nojekyll
View File

1
docs/CNAME
View File

@ -1 +0,0 @@
docs.qmk.fm

4
docs/ChangeLog/20190830.md
View File

@ -20,7 +20,7 @@ This document marks the inaugural Breaking Change merge. A list of changes follo
* `fn_actions` is deprecated, and its functionality has been superseded by direct keycodes and `process_record_user()` * `fn_actions` is deprecated, and its functionality has been superseded by direct keycodes and `process_record_user()`
* The end result of removing this obsolete feature should result in a decent reduction in firmware size and code complexity * The end result of removing this obsolete feature should result in a decent reduction in firmware size and code complexity
* All keymaps affected are recommended to switch away from `fn_actions` in favour of the [custom keycode](https://docs.qmk.fm/#/custom_quantum_functions) and [macro](https://docs.qmk.fm/#/feature_macros) features * All keymaps affected are recommended to switch away from `fn_actions` in favour of the [custom keycode](../custom_quantum_functions) and [macro](../feature_macros) features
## Update Atreus to current code conventions ## Update Atreus to current code conventions
@ -43,7 +43,7 @@ This document marks the inaugural Breaking Change merge. A list of changes follo
* `fn_actions` is deprecated, and its functionality has been superseded by direct keycodes and `process_record_user()` * `fn_actions` is deprecated, and its functionality has been superseded by direct keycodes and `process_record_user()`
* All keymaps using these actions have had the relevant `KC_FN*` keys replaced with the equivalent `BL_*` keys * All keymaps using these actions have had the relevant `KC_FN*` keys replaced with the equivalent `BL_*` keys
* If you currently use `KC_FN*` you will need to replace `fn_actions` with the [custom keycode](https://docs.qmk.fm/#/custom_quantum_functions) and [macro](https://docs.qmk.fm/#/feature_macros) features * If you currently use `KC_FN*` you will need to replace `fn_actions` with the [custom keycode](../custom_quantum_functions) and [macro](../feature_macros) features
## Remove `KC_DELT` alias in favor of `KC_DEL` ## Remove `KC_DELT` alias in favor of `KC_DEL`

2
docs/ChangeLog/20200229.md
View File

@ -51,7 +51,7 @@ Four times a year QMK runs a process for merging Breaking Changes. A Breaking Ch
* `fn_actions` is deprecated, and its functionality has been superseded by direct keycodes and `process_record_user()` * `fn_actions` is deprecated, and its functionality has been superseded by direct keycodes and `process_record_user()`
* The end result of removing this obsolete feature should result in a decent reduction in firmware size and code complexity * The end result of removing this obsolete feature should result in a decent reduction in firmware size and code complexity
* All keymaps affected are recommended to switch away from `fn_actions` in favour of the [custom keycode](https://docs.qmk.fm/#/custom_quantum_functions) and [macro](https://docs.qmk.fm/#/feature_macros) features * All keymaps affected are recommended to switch away from `fn_actions` in favour of the [custom keycode](../custom_quantum_functions) and [macro](../feature_macros) features
## Moving backlight keycode handling to `process_keycode/` ## Moving backlight keycode handling to `process_keycode/`

18
docs/ChangeLog/20200829.md
View File

@ -3,9 +3,9 @@
Four times a year QMK runs a process for merging Breaking Changes. A Breaking Change is any change which modifies how QMK behaves in a way that is incompatible or potentially dangerous. We limit these changes to 4 times per year so that users can have confidence that updating their QMK tree will not break their keymaps. Four times a year QMK runs a process for merging Breaking Changes. A Breaking Change is any change which modifies how QMK behaves in a way that is incompatible or potentially dangerous. We limit these changes to 4 times per year so that users can have confidence that updating their QMK tree will not break their keymaps.
## Changes Requiring User Action :id=changes-requiring-user-action ## Changes Requiring User Action {#changes-requiring-user-action}
### Relocated Keyboards :id=relocated-keyboards ### Relocated Keyboards {#relocated-keyboards}
#### The Key Company project consolidation ([#9547](https://github.com/qmk/qmk_firmware/pull/9547)) #### The Key Company project consolidation ([#9547](https://github.com/qmk/qmk_firmware/pull/9547))
#### relocating boards by flehrad to flehrad/ folder ([#9635](https://github.com/qmk/qmk_firmware/pull/9635)) #### relocating boards by flehrad to flehrad/ folder ([#9635](https://github.com/qmk/qmk_firmware/pull/9635))
@ -24,7 +24,7 @@ handwired/numbrero | flehrad/numbrero
snagpad | flehrad/snagpad snagpad | flehrad/snagpad
handwired/tradestation | flehrad/tradestation handwired/tradestation | flehrad/tradestation
### Updated Keyboard Codebases :id=keyboard-updates ### Updated Keyboard Codebases {#keyboard-updates}
#### Keebio RGB wiring update ([#7754](https://github.com/qmk/qmk_firmware/pull/7754)) #### Keebio RGB wiring update ([#7754](https://github.com/qmk/qmk_firmware/pull/7754))
@ -46,7 +46,7 @@ This change affects:
* Quefrency rev1 * Quefrency rev1
* Viterbi, revs. 1 and 2 * Viterbi, revs. 1 and 2
### Changes to Core Functionality :id=core-updates ### Changes to Core Functionality {#core-updates}
* Bigger Combo index ([#9318](https://github.com/qmk/qmk_firmware/pull/9318)) * Bigger Combo index ([#9318](https://github.com/qmk/qmk_firmware/pull/9318))
@ -58,14 +58,14 @@ Any fork that uses `process_combo_event` needs to update the function's first ar
* New function: `void process_combo_event(uint16_t combo_index, bool pressed)` * New function: `void process_combo_event(uint16_t combo_index, bool pressed)`
## Core Changes :id=core-changes ## Core Changes {#core-changes}
### Fixes :id=core-fixes ### Fixes {#core-fixes}
* Mousekeys: scrolling acceleration is no longer coupled to mouse movement acceleration ([#9174](https://github.com/qmk/qmk_firmware/pull/9174)) * Mousekeys: scrolling acceleration is no longer coupled to mouse movement acceleration ([#9174](https://github.com/qmk/qmk_firmware/pull/9174))
* Keymap Extras: correctly assign Question Mark in Czech layout ([#9987](https://github.com/qmk/qmk_firmware/pull/9987)) * Keymap Extras: correctly assign Question Mark in Czech layout ([#9987](https://github.com/qmk/qmk_firmware/pull/9987))
### Additions and Enhancements :id=core-additions ### Additions and Enhancements {#core-additions}
* allow for WS2812 PWM to work on DMAMUX-capable devices ([#9471](https://github.com/qmk/qmk_firmware/pull/9471)) * allow for WS2812 PWM to work on DMAMUX-capable devices ([#9471](https://github.com/qmk/qmk_firmware/pull/9471))
* Newer STM32 MCUs have a DMAMUX peripheral, which allows mapping of DMAs to different DMA streams, rather than hard-defining the target streams in silicon. * Newer STM32 MCUs have a DMAMUX peripheral, which allows mapping of DMAs to different DMA streams, rather than hard-defining the target streams in silicon.
@ -109,7 +109,7 @@ Any fork that uses `process_combo_event` needs to update the function's first ar
* The K-Type has been refactored to use QMK's native matrix scanning routine, and now has partial support for the RGB Matrix feature. * The K-Type has been refactored to use QMK's native matrix scanning routine, and now has partial support for the RGB Matrix feature.
* Joysticks can now be used without defining analog pins ([#10169](https://github.com/qmk/qmk_firmware/pull/10169)) * Joysticks can now be used without defining analog pins ([#10169](https://github.com/qmk/qmk_firmware/pull/10169))
### Clean-ups and Optimizations :id=core-optimizations ### Clean-ups and Optimizations {#core-optimizations}
* iWRAP protocol removed ([#9284](https://github.com/qmk/qmk_firmware/pull/9284)) * iWRAP protocol removed ([#9284](https://github.com/qmk/qmk_firmware/pull/9284))
* work begun for consolidation of ChibiOS platform files ([#8327](https://github.com/qmk/qmk_firmware/pull/8327) and [#9315](https://github.com/qmk/qmk_firmware/pull/9315)) * work begun for consolidation of ChibiOS platform files ([#8327](https://github.com/qmk/qmk_firmware/pull/8327) and [#9315](https://github.com/qmk/qmk_firmware/pull/9315))
@ -140,7 +140,7 @@ Any fork that uses `process_combo_event` needs to update the function's first ar
* remove support for Adafruit EZ Key Bluetooth controller ([#10103](https://github.com/qmk/qmk_firmware/pull/10103)) * remove support for Adafruit EZ Key Bluetooth controller ([#10103](https://github.com/qmk/qmk_firmware/pull/10103))
## QMK Infrastructure and Internals :id=qmk-internals ## QMK Infrastructure and Internals {#qmk-internals}
* Attempt to fix CI for non-master branches. ([#9308](https://github.com/qmk/qmk_firmware/pull/9308)) * Attempt to fix CI for non-master branches. ([#9308](https://github.com/qmk/qmk_firmware/pull/9308))
* Actually fetch the branch we're attempting to compare against. * Actually fetch the branch we're attempting to compare against.

16
docs/ChangeLog/20201128.md
View File

@ -3,9 +3,9 @@
Four times a year QMK runs a process for merging Breaking Changes. A Breaking Change is any change which modifies how QMK behaves in a way that is incompatible or potentially dangerous. We limit these changes to 4 times per year so that users can have confidence that updating their QMK tree will not break their keymaps. Four times a year QMK runs a process for merging Breaking Changes. A Breaking Change is any change which modifies how QMK behaves in a way that is incompatible or potentially dangerous. We limit these changes to 4 times per year so that users can have confidence that updating their QMK tree will not break their keymaps.
## Changes Requiring User Action :id=changes-requiring-user-action ## Changes Requiring User Action {#changes-requiring-user-action}
### Relocated Keyboards :id=relocated-keyboards ### Relocated Keyboards {#relocated-keyboards}
#### Reduce Helix keyboard build variation ([#8669](https://github.com/qmk/qmk_firmware/pull/8669)) #### Reduce Helix keyboard build variation ([#8669](https://github.com/qmk/qmk_firmware/pull/8669))
@ -88,21 +88,21 @@ The Valor and Dawn60 keyboards by Xelus22 both now require their revisions to be
| xelus/valor | xelus/valor/rev1 | | xelus/valor | xelus/valor/rev1 |
### Updated Keyboard Codebases :id=keyboard-updates ### Updated Keyboard Codebases {#keyboard-updates}
#### AEboards EXT65 Refactor ([#10820](https://github.com/qmk/qmk_firmware/pull/10820)) #### AEboards EXT65 Refactor ([#10820](https://github.com/qmk/qmk_firmware/pull/10820))
The EXT65 codebase has been reworked so keymaps can be used with either revision. The EXT65 codebase has been reworked so keymaps can be used with either revision.
## Core Changes :id=core-changes ## Core Changes {#core-changes}
### Fixes :id=core-fixes ### Fixes {#core-fixes}
* Reconnect the USB if users wake up a computer from the keyboard to restore the USB state ([#10088](https://github.com/qmk/qmk_firmware/pull/10088)) * Reconnect the USB if users wake up a computer from the keyboard to restore the USB state ([#10088](https://github.com/qmk/qmk_firmware/pull/10088))
* Fix cursor position bug in oled_write_raw functions ([#10800](https://github.com/qmk/qmk_firmware/pull/10800)) * Fix cursor position bug in oled_write_raw functions ([#10800](https://github.com/qmk/qmk_firmware/pull/10800))
### Additions and Enhancements :id=core-additions ### Additions and Enhancements {#core-additions}
* Allow MATRIX_ROWS to be greater than 32 ([#10183](https://github.com/qmk/qmk_firmware/pull/10183)) * Allow MATRIX_ROWS to be greater than 32 ([#10183](https://github.com/qmk/qmk_firmware/pull/10183))
* Add support for soft serial to ATmega32U2 ([#10204](https://github.com/qmk/qmk_firmware/pull/10204)) * Add support for soft serial to ATmega32U2 ([#10204](https://github.com/qmk/qmk_firmware/pull/10204))
@ -119,7 +119,7 @@ The EXT65 codebase has been reworked so keymaps can be used with either revision
* Add AT90USB support for serial.c ([#10706](https://github.com/qmk/qmk_firmware/pull/10706)) * Add AT90USB support for serial.c ([#10706](https://github.com/qmk/qmk_firmware/pull/10706))
* Auto shift: support repeats and early registration (#9826) * Auto shift: support repeats and early registration (#9826)
### Clean-ups and Optimizations :id=core-optimizations ### Clean-ups and Optimizations {#core-optimizations}
* Haptic and solenoid cleanup ([#9700](https://github.com/qmk/qmk_firmware/pull/9700)) * Haptic and solenoid cleanup ([#9700](https://github.com/qmk/qmk_firmware/pull/9700))
* XD75 cleanup ([#10524](https://github.com/qmk/qmk_firmware/pull/10524)) * XD75 cleanup ([#10524](https://github.com/qmk/qmk_firmware/pull/10524))
@ -129,7 +129,7 @@ The EXT65 codebase has been reworked so keymaps can be used with either revision
* Remove references to HD44780 ([#10735](https://github.com/qmk/qmk_firmware/pull/10735)) * Remove references to HD44780 ([#10735](https://github.com/qmk/qmk_firmware/pull/10735))
## QMK Infrastructure and Internals :id=qmk-internals ## QMK Infrastructure and Internals {#qmk-internals}
* Add ability to build a subset of all keyboards based on platform. ([#10420](https://github.com/qmk/qmk_firmware/pull/10420)) * Add ability to build a subset of all keyboards based on platform. ([#10420](https://github.com/qmk/qmk_firmware/pull/10420))
* Initialise EEPROM drivers at startup, instead of upon first execution ([#10438](https://github.com/qmk/qmk_firmware/pull/10438)) * Initialise EEPROM drivers at startup, instead of upon first execution ([#10438](https://github.com/qmk/qmk_firmware/pull/10438))

32
docs/ChangeLog/20210529.md
View File

@ -1,30 +1,30 @@
# QMK Breaking Changes - 2021 May 29 Changelog # QMK Breaking Changes - 2021 May 29 Changelog
## Notable Changes :id=notable-changes ## Notable Changes {#notable-changes}
### RGB Matrix support for split common ([#11055](https://github.com/qmk/qmk_firmware/pull/11055)) :id=rgb-matrix-split-common ### RGB Matrix support for split common ([#11055](https://github.com/qmk/qmk_firmware/pull/11055)) {#rgb-matrix-split-common}
Split boards can now use RGB Matrix without defining a custom matrix. Split boards can now use RGB Matrix without defining a custom matrix.
### Teensy 3.6 support ([#12258](https://github.com/qmk/qmk_firmware/pull/12258)) :id=teensy-3-6-support ### Teensy 3.6 support ([#12258](https://github.com/qmk/qmk_firmware/pull/12258)) {#teensy-3-6-support}
Added support for MK66F18 (Teensy 3.6) microcontroller. Added support for MK66F18 (Teensy 3.6) microcontroller.
### New command: qmk console ([#12828](https://github.com/qmk/qmk_firmware/pull/12828)) :id=new-command-qmk-console ### New command: qmk console ([#12828](https://github.com/qmk/qmk_firmware/pull/12828)) {#new-command-qmk-console}
A new `qmk console` command has been added for attaching to your keyboard's console. It operates similiarly to QMK Toolbox by allowing you to connect to one or more keyboard consoles to display debugging messages. A new `qmk console` command has been added for attaching to your keyboard's console. It operates similiarly to QMK Toolbox by allowing you to connect to one or more keyboard consoles to display debugging messages.
### Improved command: qmk config :id=improve-command-qmk-config ### Improved command: qmk config {#improve-command-qmk-config}
We've updated the `qmk config` command to show only the configuration items you have actually set. You can now display (almost) all of the available configuration options, along with their default values, using `qmk config -a`. We've updated the `qmk config` command to show only the configuration items you have actually set. You can now display (almost) all of the available configuration options, along with their default values, using `qmk config -a`.
### LED Matrix Improvements ([#12509](https://github.com/qmk/qmk_firmware/pull/12509), [#12580](https://github.com/qmk/qmk_firmware/pull/12580), [#12588](https://github.com/qmk/qmk_firmware/pull/12588), [#12633](https://github.com/qmk/qmk_firmware/pull/12633), [#12651](https://github.com/qmk/qmk_firmware/pull/12651), [#12685](https://github.com/qmk/qmk_firmware/pull/12685)) :id=led-matrix-improvements ### LED Matrix Improvements ([#12509](https://github.com/qmk/qmk_firmware/pull/12509), [#12580](https://github.com/qmk/qmk_firmware/pull/12580), [#12588](https://github.com/qmk/qmk_firmware/pull/12588), [#12633](https://github.com/qmk/qmk_firmware/pull/12633), [#12651](https://github.com/qmk/qmk_firmware/pull/12651), [#12685](https://github.com/qmk/qmk_firmware/pull/12685)) {#led-matrix-improvements}
LED Matrix has been improved with effects, CIE1931 curves, and a task system. LED Matrix has been improved with effects, CIE1931 curves, and a task system.
## Changes Requiring User Action :id=changes-requiring-user-action ## Changes Requiring User Action {#changes-requiring-user-action}
### Updated Keyboard Codebases :id=updated-keyboard-codebases ### Updated Keyboard Codebases {#updated-keyboard-codebases}
* Durgod keyboard refactor in preparation for adding additional durgod keyboards ([#11978](https://github.com/qmk/qmk_firmware/pull/11978)) * Durgod keyboard refactor in preparation for adding additional durgod keyboards ([#11978](https://github.com/qmk/qmk_firmware/pull/11978))
* Updated Function96 with V2 files and removed chconf.h and halconf.h ([#12613](https://github.com/qmk/qmk_firmware/pull/12613)) * Updated Function96 with V2 files and removed chconf.h and halconf.h ([#12613](https://github.com/qmk/qmk_firmware/pull/12613))
@ -52,7 +52,7 @@ The codebase for the [Durgod K320](https://github.com/qmk/qmk_firmware/tree/0.13
Additionally, the `crkbd/rev1/legacy` keyboard has been removed. Additionally, the `crkbd/rev1/legacy` keyboard has been removed.
### Bootmagic Deprecation and Refactor ([#12172](https://github.com/qmk/qmk_firmware/pull/12172)) :id=bootmagic-deprecation-and-refactor ### Bootmagic Deprecation and Refactor ([#12172](https://github.com/qmk/qmk_firmware/pull/12172)) {#bootmagic-deprecation-and-refactor}
QMK has decided to deprecate the full Bootmagic feature and leave Bootmagic Lite as the only remaining option. QMK has decided to deprecate the full Bootmagic feature and leave Bootmagic Lite as the only remaining option.
@ -68,11 +68,11 @@ This is the current planned roadmap for the behavior of `BOOTMAGIC_ENABLE`:
- From 2021 Aug 28, `BOOTMAGIC_ENABLE` must be either `yes`, `lite`, or `no` – setting `BOOTMAGIC_ENABLE = full` will cause compilation to fail. - From 2021 Aug 28, `BOOTMAGIC_ENABLE` must be either `yes`, `lite`, or `no` – setting `BOOTMAGIC_ENABLE = full` will cause compilation to fail.
- From 2021 Nov 27, `BOOTMAGIC_ENABLE` must be either `yes` or `no` – setting `BOOTMAGIC_ENABLE = lite` will cause compilation to fail. - From 2021 Nov 27, `BOOTMAGIC_ENABLE` must be either `yes` or `no` – setting `BOOTMAGIC_ENABLE = lite` will cause compilation to fail.
### Removal of LAYOUT_kc ([#12160](https://github.com/qmk/qmk_firmware/pull/12160)) :id=removal-of-layout-kc ### Removal of LAYOUT_kc ([#12160](https://github.com/qmk/qmk_firmware/pull/12160)) {#removal-of-layout-kc}
We've removed support for `LAYOUT_kc` macros, if your keymap uses one you will need to update it use a regular `LAYOUT` macro. We've removed support for `LAYOUT_kc` macros, if your keymap uses one you will need to update it use a regular `LAYOUT` macro.
### Encoder callbacks are now boolean ([#12805](https://github.com/qmk/qmk_firmware/pull/12805), [#12985](https://github.com/qmk/qmk_firmware/pull/12985)) :id=encoder-callback-boolean ### Encoder callbacks are now boolean ([#12805](https://github.com/qmk/qmk_firmware/pull/12805), [#12985](https://github.com/qmk/qmk_firmware/pull/12985)) {#encoder-callback-boolean}
To allow for keyboards to override (or not) keymap level code the `encoder_update_kb` function has been changed from `void` to `bool`. You will need to update your function definition to reflect this and ensure that you return a `true` or `false` value. To allow for keyboards to override (or not) keymap level code the `encoder_update_kb` function has been changed from `void` to `bool`. You will need to update your function definition to reflect this and ensure that you return a `true` or `false` value.
@ -127,9 +127,9 @@ bool encoder_update_user(uint8_t index, bool clockwise) {
} }
``` ```
## Core Changes :id=core-changes ## Core Changes {#core-changes}
### Fixes :id=core-fixes ### Fixes {#core-fixes}
* Fix connection issue in split keyboards when slave and OLED display are connected via I2C (fixes #9335) ([#11487](https://github.com/qmk/qmk_firmware/pull/11487)) * Fix connection issue in split keyboards when slave and OLED display are connected via I2C (fixes #9335) ([#11487](https://github.com/qmk/qmk_firmware/pull/11487))
* Terrazzo: Fix wrong LED Matrix function names ([#12561](https://github.com/qmk/qmk_firmware/pull/12561)) * Terrazzo: Fix wrong LED Matrix function names ([#12561](https://github.com/qmk/qmk_firmware/pull/12561))
@ -147,7 +147,7 @@ bool encoder_update_user(uint8_t index, bool clockwise) {
* [Keyboard] Fix Terrazzo build failure ([#12977](https://github.com/qmk/qmk_firmware/pull/12977)) * [Keyboard] Fix Terrazzo build failure ([#12977](https://github.com/qmk/qmk_firmware/pull/12977))
* Do not hard set config in CPTC files ([#11864](https://github.com/qmk/qmk_firmware/pull/11864)) * Do not hard set config in CPTC files ([#11864](https://github.com/qmk/qmk_firmware/pull/11864))
### Additions and Enhancements :id=core-additions ### Additions and Enhancements {#core-additions}
* ARM - Refactor SLEEP_LED to support more platforms ([#8403](https://github.com/qmk/qmk_firmware/pull/8403)) * ARM - Refactor SLEEP_LED to support more platforms ([#8403](https://github.com/qmk/qmk_firmware/pull/8403))
* Add ability to toggle One Shot functionality ([#4198](https://github.com/qmk/qmk_firmware/pull/4198)) * Add ability to toggle One Shot functionality ([#4198](https://github.com/qmk/qmk_firmware/pull/4198))
@ -193,7 +193,7 @@ bool encoder_update_user(uint8_t index, bool clockwise) {
* Backlight: add defines for default level and breathing state ([#12560](https://github.com/qmk/qmk_firmware/pull/12560), [#13024](https://github.com/qmk/qmk_firmware/pull/13024)) * Backlight: add defines for default level and breathing state ([#12560](https://github.com/qmk/qmk_firmware/pull/12560), [#13024](https://github.com/qmk/qmk_firmware/pull/13024))
* Add dire message about LUFA mass storage bootloader ([#13014](https://github.com/qmk/qmk_firmware/pull/13014)) * Add dire message about LUFA mass storage bootloader ([#13014](https://github.com/qmk/qmk_firmware/pull/13014))
### Clean-ups and Optimizations :id=core-optimizations ### Clean-ups and Optimizations {#core-optimizations}
* Overhaul bootmagic logic to have single entrypoint ([#8532](https://github.com/qmk/qmk_firmware/pull/8532)) * Overhaul bootmagic logic to have single entrypoint ([#8532](https://github.com/qmk/qmk_firmware/pull/8532))
* Refactor of USB code within split_common ([#11890](https://github.com/qmk/qmk_firmware/pull/11890)) * Refactor of USB code within split_common ([#11890](https://github.com/qmk/qmk_firmware/pull/11890))
@ -218,7 +218,7 @@ bool encoder_update_user(uint8_t index, bool clockwise) {
* Deprecate `send_unicode_hex_string()` ([#12602](https://github.com/qmk/qmk_firmware/pull/12602)) * Deprecate `send_unicode_hex_string()` ([#12602](https://github.com/qmk/qmk_firmware/pull/12602))
* [Keyboard] Remove redundant legacy and common headers for crkbd ([#13023](https://github.com/qmk/qmk_firmware/pull/13023)) * [Keyboard] Remove redundant legacy and common headers for crkbd ([#13023](https://github.com/qmk/qmk_firmware/pull/13023))
### QMK Infrastructure and Internals :id=qmk-internals ### QMK Infrastructure and Internals {#qmk-internals}
* trivial change to trigger api update ([`b15288fb87`](https://github.com/qmk/qmk_firmware/commit/b15288fb87)) * trivial change to trigger api update ([`b15288fb87`](https://github.com/qmk/qmk_firmware/commit/b15288fb87))
* fix some references to bin/qmk that slipped in ([#12832](https://github.com/qmk/qmk_firmware/pull/12832)) * fix some references to bin/qmk that slipped in ([#12832](https://github.com/qmk/qmk_firmware/pull/12832))

30
docs/ChangeLog/20210828.md
View File

@ -1,28 +1,28 @@
# QMK Breaking Changes - 2021 August 28 Changelog # QMK Breaking Changes - 2021 August 28 Changelog
## Notable Features :id=notable-features ## Notable Features {#notable-features}
### Combo processing improvements ([#8591](https://github.com/qmk/qmk_firmware/pull/8591)) :id=combo-processing-improvements ### Combo processing improvements ([#8591](https://github.com/qmk/qmk_firmware/pull/8591)) {#combo-processing-improvements}
Combo processing has been reordered with respect to keypress handling, allowing for much better compatibility with mod taps. Combo processing has been reordered with respect to keypress handling, allowing for much better compatibility with mod taps.
It is also now possible to define combos that have keys overlapping with other combos, triggering only one. For example, a combo of `A`, `B` can coexist with a longer combo of `A`, `B`, `C` -- previous functionality would trigger both combos if all three keys were pressed. It is also now possible to define combos that have keys overlapping with other combos, triggering only one. For example, a combo of `A`, `B` can coexist with a longer combo of `A`, `B`, `C` -- previous functionality would trigger both combos if all three keys were pressed.
### Key Overrides ([#11422](https://github.com/qmk/qmk_firmware/pull/11422)) :id=key-overrides ### Key Overrides ([#11422](https://github.com/qmk/qmk_firmware/pull/11422)) {#key-overrides}
QMK now has a new feature: [key overrides](https://docs.qmk.fm/#/feature_key_overrides). This feature allows for overriding the output of key combinations involving modifiers. As an example, pressing <kbd>Shift+2</kbd> normally results in an <kbd>@</kbd> on US-ANSI keyboard layouts -- the new key overrides allow for adding similar functionality, but for any <kbd>modifier + key</kbd> press. QMK now has a new feature: [key overrides](../feature_key_overrides). This feature allows for overriding the output of key combinations involving modifiers. As an example, pressing <kbd>Shift+2</kbd> normally results in an <kbd>@</kbd> on US-ANSI keyboard layouts -- the new key overrides allow for adding similar functionality, but for any <kbd>modifier + key</kbd> press.
To illustrate, it's now possible to use the key overrides feature to translate <kbd>Shift + Backspace</kbd> into <kbd>Delete</kbd> -- an often-requested example of where this functionality comes in handy. To illustrate, it's now possible to use the key overrides feature to translate <kbd>Shift + Backspace</kbd> into <kbd>Delete</kbd> -- an often-requested example of where this functionality comes in handy.
There's far more to describe that what lives in this changelog, so head over to the [key overrides documentation](https://docs.qmk.fm/#/feature_key_overrides) for more examples and info. There's far more to describe that what lives in this changelog, so head over to the [key overrides documentation](../feature_key_overrides) for more examples and info.
### Digitizer support ([#12851](https://github.com/qmk/qmk_firmware/pull/12851)) ### Digitizer support ([#12851](https://github.com/qmk/qmk_firmware/pull/12851))
QMK gained the ability to pretend to be a digitizer device -- much like a tablet device. A mouse uses delta-coordinates -- move up, move right -- but a digitizer works with absolute coordinates -- top left, bottom right. QMK gained the ability to pretend to be a digitizer device -- much like a tablet device. A mouse uses delta-coordinates -- move up, move right -- but a digitizer works with absolute coordinates -- top left, bottom right.
## Changes Requiring User Action :id=changes-requiring-user-action ## Changes Requiring User Action {#changes-requiring-user-action}
### Updated Keyboard Codebases :id=updated-keyboard-codebases ### Updated Keyboard Codebases {#updated-keyboard-codebases}
The following keyboards have had their source moved within QMK: The following keyboards have had their source moved within QMK:
@ -69,7 +69,7 @@ xd84pro | xiudi/xd84pro
xd87 | xiudi/xd87 xd87 | xiudi/xd87
xd96 | xiudi/xd96 xd96 | xiudi/xd96
### Bootmagic Full Removal ([#13846](https://github.com/qmk/qmk_firmware/pull/13846)) :id=bootmagic-full-removal ### Bootmagic Full Removal ([#13846](https://github.com/qmk/qmk_firmware/pull/13846)) {#bootmagic-full-removal}
As noted during last breaking changes cycle, QMK has decided to deprecate the full Bootmagic feature and leave Bootmagic Lite as the only remaining option. As noted during last breaking changes cycle, QMK has decided to deprecate the full Bootmagic feature and leave Bootmagic Lite as the only remaining option.
@ -85,7 +85,7 @@ This is the current roadmap for the behavior of `BOOTMAGIC_ENABLE`:
- (now) From 2021 Aug 28, `BOOTMAGIC_ENABLE` must be either `yes`, `lite`, or `no` – setting `BOOTMAGIC_ENABLE = full` will cause compilation to fail. - (now) From 2021 Aug 28, `BOOTMAGIC_ENABLE` must be either `yes`, `lite`, or `no` – setting `BOOTMAGIC_ENABLE = full` will cause compilation to fail.
- (next) From 2021 Nov 27, `BOOTMAGIC_ENABLE` must be either `yes` or `no` – setting `BOOTMAGIC_ENABLE = lite` will cause compilation to fail. - (next) From 2021 Nov 27, `BOOTMAGIC_ENABLE` must be either `yes` or `no` – setting `BOOTMAGIC_ENABLE = lite` will cause compilation to fail.
### DIP switch callbacks are now boolean ([#13399](https://github.com/qmk/qmk_firmware/pull/13399)) :id=dip-switch-boolean ### DIP switch callbacks are now boolean ([#13399](https://github.com/qmk/qmk_firmware/pull/13399)) {#dip-switch-boolean}
To match the encoder change last breaking changes cycle, DIP switch callbacks now return `bool`, too. To match the encoder change last breaking changes cycle, DIP switch callbacks now return `bool`, too.
@ -149,9 +149,9 @@ bool dip_switch_update_mask_user(uint32_t state) {
} }
``` ```
## Notable core changes :id=notable-core ## Notable core changes {#notable-core}
### Split transport improvements :id=split-transport-improvements ### Split transport improvements {#split-transport-improvements}
Split keyboards gained a significant amount of improvements during this breaking changes cycle, specifically: Split keyboards gained a significant amount of improvements during this breaking changes cycle, specifically:
@ -160,9 +160,11 @@ Split keyboards gained a significant amount of improvements during this breaking
* Make solo half of split keyboards (more) usable. ([#13523](https://github.com/qmk/qmk_firmware/pull/13523)) -- allows the slave to be disconnected, enabling one-handed use. * Make solo half of split keyboards (more) usable. ([#13523](https://github.com/qmk/qmk_firmware/pull/13523)) -- allows the slave to be disconnected, enabling one-handed use.
* Switch split_common to CRC subsystem ([#13418](https://github.com/qmk/qmk_firmware/pull/13418)) * Switch split_common to CRC subsystem ([#13418](https://github.com/qmk/qmk_firmware/pull/13418))
!> If you're updating your split keyboard, you will need to flash both sides of the split with the your firmware. ::: warning
If you're updating your split keyboard, you will need to flash both sides of the split with the your firmware.
:::
### Teensy 4.x support ([#13056](https://github.com/qmk/qmk_firmware/pull/13056), [#13076](https://github.com/qmk/qmk_firmware/pull/13076), [#13077](https://github.com/qmk/qmk_firmware/pull/13077)) :id=teensy-4-x-support ### Teensy 4.x support ([#13056](https://github.com/qmk/qmk_firmware/pull/13056), [#13076](https://github.com/qmk/qmk_firmware/pull/13076), [#13077](https://github.com/qmk/qmk_firmware/pull/13077)) {#teensy-4-x-support}
Updated ChibiOS and ChibiOS-Contrib, which brought in support for Teensy 4.x dev boards, running NXP i.MX1062. Updated ChibiOS and ChibiOS-Contrib, which brought in support for Teensy 4.x dev boards, running NXP i.MX1062.
@ -243,7 +245,7 @@ We've added dozens of new keys to `info.json` so that you can configure more tha
* `usb.force_nkro`, `usb.max_power`, `usb.no_startup_check`, `usb.polling_interval`, `usb.shared_endpoint.keyboard`, `usb.shared_endpoint.mouse`, `usb.suspend_wakeup_delay`, `usb.wait_for` * `usb.force_nkro`, `usb.max_power`, `usb.no_startup_check`, `usb.polling_interval`, `usb.shared_endpoint.keyboard`, `usb.shared_endpoint.mouse`, `usb.suspend_wakeup_delay`, `usb.wait_for`
* `qmk.keys_per_scan`, `qmk.tap_keycode_delay`, `qmk.tap_capslock_delay` * `qmk.keys_per_scan`, `qmk.tap_keycode_delay`, `qmk.tap_capslock_delay`
### Codebase restructure and cleanup :id=codebase-restructure ### Codebase restructure and cleanup {#codebase-restructure}
QMK was originally based on TMK, and has grown in size considerably since its first inception. To keep moving things forward, restructure of some of the core areas of the code is needed to support new concepts and new hardware, and progress is happening along those lines: QMK was originally based on TMK, and has grown in size considerably since its first inception. To keep moving things forward, restructure of some of the core areas of the code is needed to support new concepts and new hardware, and progress is happening along those lines:

40
docs/ChangeLog/20211127.md
View File

@ -1,6 +1,6 @@
# QMK Breaking Changes - 2021 November 27 Changelog # QMK Breaking Changes - 2021 November 27 Changelog
## 2000 keyboards! :id=qmk-2000th-keyboard ## 2000 keyboards! {#qmk-2000th-keyboard}
QMK had it's 2000th keyboard submitted during this breaking changes cycle.... and it only _just_ made the cut-off! QMK had it's 2000th keyboard submitted during this breaking changes cycle.... and it only _just_ made the cut-off!
@ -11,9 +11,9 @@ QMK had it's 2000th keyboard submitted during this breaking changes cycle.... an
From the whole QMK team, a major thankyou to the community for embracing QMK as your preferred keyboard firmware! From the whole QMK team, a major thankyou to the community for embracing QMK as your preferred keyboard firmware!
## Notable Features :id=notable-features ## Notable Features {#notable-features}
### Expanded Pointing Device support ([#14343](https://github.com/qmk/qmk_firmware/pull/14343)) :id=expanded-pointing-device ### Expanded Pointing Device support ([#14343](https://github.com/qmk/qmk_firmware/pull/14343)) {#expanded-pointing-device}
Pointing device support has been reworked and reimplemented to allow for easier integration of new peripherals. Pointing device support has been reworked and reimplemented to allow for easier integration of new peripherals.
@ -31,9 +31,9 @@ QMK now has core-supplied support for the following pointing device peripherals:
| `POINTING_DEVICE_DRIVER = pimoroni_trackball` | Pimoroni Trackball | | `POINTING_DEVICE_DRIVER = pimoroni_trackball` | Pimoroni Trackball |
| `POINTING_DEVICE_DRIVER = pmw3360` | PMW 3360 | | `POINTING_DEVICE_DRIVER = pmw3360` | PMW 3360 |
See the new documentation for the [Pointing Device](../feature_pointing_device.md) feature for more information on specific configuration for each driver. See the new documentation for the [Pointing Device](../feature_pointing_device) feature for more information on specific configuration for each driver.
### Dynamic Tapping Term ([#11036](https://github.com/qmk/qmk_firmware/pull/11036)) :id=dynamic-tapping-term ### Dynamic Tapping Term ([#11036](https://github.com/qmk/qmk_firmware/pull/11036)) {#dynamic-tapping-term}
For people who are starting out with tapping keys, or for people who think tapping keys don't "feel right", it's sometimes quite difficult to determine what duration of tapping term to use to make things seem natural. For people who are starting out with tapping keys, or for people who think tapping keys don't "feel right", it's sometimes quite difficult to determine what duration of tapping term to use to make things seem natural.
@ -47,9 +47,9 @@ If you're in this stage of discovery, you can now add `DYNAMIC_TAPPING_TERM_ENAB
Coupled with the use of `qmk console` or QMK Toolbox to show console output from your keyboard, you can tweak the tapping term dynamically in order to narrow down what "feels right" to you. Once you're happy, drop in the resulting number into your keymap's `config.h` and you're good to go! Coupled with the use of `qmk console` or QMK Toolbox to show console output from your keyboard, you can tweak the tapping term dynamically in order to narrow down what "feels right" to you. Once you're happy, drop in the resulting number into your keymap's `config.h` and you're good to go!
### Macros in JSON keymaps ([#14374](https://github.com/qmk/qmk_firmware/pull/14374)) :id=macros-in-keymap-json ### Macros in JSON keymaps ([#14374](https://github.com/qmk/qmk_firmware/pull/14374)) {#macros-in-keymap-json}
You can now define up to 32 macros in your `keymap.json` file, as used by [QMK Configurator](newbs_building_firmware_configurator.md), and `qmk compile`. You can define these macros in a list under the `macros` keyword, like this: You can now define up to 32 macros in your `keymap.json` file, as used by [QMK Configurator](../newbs_building_firmware_configurator), and `qmk compile`. You can define these macros in a list under the `macros` keyword, like this:
```json ```json
{ {
@ -83,9 +83,9 @@ You can now define up to 32 macros in your `keymap.json` file, as used by [QMK C
In due course, [QMK Configurator](https://config.qmk.fm/) will pick up support for defining these in its UI, but for now the json is the only way to define macros. In due course, [QMK Configurator](https://config.qmk.fm/) will pick up support for defining these in its UI, but for now the json is the only way to define macros.
## Changes Requiring User Action :id=changes-requiring-user-action ## Changes Requiring User Action {#changes-requiring-user-action}
### Updated Keyboard Codebases :id=updated-keyboard-codebases ### Updated Keyboard Codebases {#updated-keyboard-codebases}
The following keyboards have had their source moved within QMK: The following keyboards have had their source moved within QMK:
@ -104,21 +104,21 @@ The following keyboards have had their source moved within QMK:
| signum/3_0/elitec | signum/3_0 | | signum/3_0/elitec | signum/3_0 |
| tgr/jane | tgr/jane/v2 | | tgr/jane | tgr/jane/v2 |
### Squeezing space out of AVR ([#15243](https://github.com/qmk/qmk_firmware/pull/15243)) :id=squeezing-space-from-avr ### Squeezing space out of AVR ([#15243](https://github.com/qmk/qmk_firmware/pull/15243)) {#squeezing-space-from-avr}
The AVR platform has been problematic for some time, in the sense that it is severely resource-constrained -- this makes life difficult for anyone attempting to add new functionality such as display panels to their keymap code. The illustrious Drashna has contributed some newer documentation on how to attempt to free up some space on AVR-based keyboards that are in short supply. The AVR platform has been problematic for some time, in the sense that it is severely resource-constrained -- this makes life difficult for anyone attempting to add new functionality such as display panels to their keymap code. The illustrious Drashna has contributed some newer documentation on how to attempt to free up some space on AVR-based keyboards that are in short supply.
Of course, there are much fewer constraints with ARM chips... ;) Of course, there are much fewer constraints with ARM chips... ;)
### Require explicit enabling of RGB Matrix modes ([#15018](https://github.com/qmk/qmk_firmware/pull/15018)) :id=explicit-rgb-modes ### Require explicit enabling of RGB Matrix modes ([#15018](https://github.com/qmk/qmk_firmware/pull/15018)) {#explicit-rgb-modes}
Related to the previous section -- RGB Matrix modes have now been made to be opt-in, rather than opt-out. As these animations are now opt-in, you may find that your keyboard no longer has all the RGB modes you're expecting -- you may need to configure and recompile your firmware and enable your animations of choice... with any luck they'll still fit in the space available. Related to the previous section -- RGB Matrix modes have now been made to be opt-in, rather than opt-out. As these animations are now opt-in, you may find that your keyboard no longer has all the RGB modes you're expecting -- you may need to configure and recompile your firmware and enable your animations of choice... with any luck they'll still fit in the space available.
Most keyboards keep their original functionality, but over time the QMK maintainers have found that removal of animations ends up being the quickest way to free up space... and some keyboards have had animations such as reactive effects disabled by default in order to still fit within the flash space available. Most keyboards keep their original functionality, but over time the QMK maintainers have found that removal of animations ends up being the quickest way to free up space... and some keyboards have had animations such as reactive effects disabled by default in order to still fit within the flash space available.
The full list of configurables to turn specific animations back on can be found at on the [RGB Matrix documentation](feature_rgb_matrix.md#rgb-matrix-effects) page. The full list of configurables to turn specific animations back on can be found at on the [RGB Matrix documentation](../feature_rgb_matrix#rgb-matrix-effects) page.
### OLED task refactoring ([#14864](https://github.com/qmk/qmk_firmware/pull/14864)) :id=oled-task-refactor ### OLED task refactoring ([#14864](https://github.com/qmk/qmk_firmware/pull/14864)) {#oled-task-refactor}
OLED display code was traditionally difficult to override in keymaps as they did not follow the standard pattern of `bool *_kb()` deferring to `bool *_user()` functions, allowing signalling to the higher level that processing had already been done. OLED display code was traditionally difficult to override in keymaps as they did not follow the standard pattern of `bool *_kb()` deferring to `bool *_user()` functions, allowing signalling to the higher level that processing had already been done.
@ -152,7 +152,7 @@ bool oled_task_kb(void) {
} }
``` ```
### Bootmagic Full Removal ([#15002](https://github.com/qmk/qmk_firmware/pull/15002)) :id=bootmagic-full-removal ### Bootmagic Full Removal ([#15002](https://github.com/qmk/qmk_firmware/pull/15002)) {#bootmagic-full-removal}
As noted during previous breaking changes cycles, QMK decided to deprecate the full Bootmagic feature and leave Bootmagic Lite as the only remaining option. As noted during previous breaking changes cycles, QMK decided to deprecate the full Bootmagic feature and leave Bootmagic Lite as the only remaining option.
@ -170,13 +170,13 @@ This is the historical timeline for the behavior of `BOOTMAGIC_ENABLE`:
- (done) From 2021 Aug 28, `BOOTMAGIC_ENABLE` must be either `yes`, `lite`, or `no` – setting `BOOTMAGIC_ENABLE = full` will cause compilation to fail. - (done) From 2021 Aug 28, `BOOTMAGIC_ENABLE` must be either `yes`, `lite`, or `no` – setting `BOOTMAGIC_ENABLE = full` will cause compilation to fail.
- (now) From 2021 Nov 27, `BOOTMAGIC_ENABLE` must be either `yes` or `no` – setting `BOOTMAGIC_ENABLE = lite` will cause compilation to fail. - (now) From 2021 Nov 27, `BOOTMAGIC_ENABLE` must be either `yes` or `no` – setting `BOOTMAGIC_ENABLE = lite` will cause compilation to fail.
### Remove QWIIC_DRIVERS ([#14174](https://github.com/qmk/qmk_firmware/pull/14174)) :id=remove-qwiic ### Remove QWIIC_DRIVERS ([#14174](https://github.com/qmk/qmk_firmware/pull/14174)) {#remove-qwiic}
Due to minimal QWIIC adoption and other options for similar functionality, the QWIIC drivers were removed from QMK. Existing OLED usages have been migrated across to the normal QMK OLED driver instead. Due to minimal QWIIC adoption and other options for similar functionality, the QWIIC drivers were removed from QMK. Existing OLED usages have been migrated across to the normal QMK OLED driver instead.
## Notable core changes :id=notable-core ## Notable core changes {#notable-core}
### New MCU Support :id=new-mcu-support ### New MCU Support {#new-mcu-support}
QMK firmware picked up support for a handful of new MCU families, potentially making it a bit easier to source components. QMK firmware picked up support for a handful of new MCU families, potentially making it a bit easier to source components.
@ -187,7 +187,7 @@ QMK firmware is now no longer limited to AVR and ARM - it also picked up support
* Westberrytech pr ([#14422](https://github.com/qmk/qmk_firmware/pull/14422)) * Westberrytech pr ([#14422](https://github.com/qmk/qmk_firmware/pull/14422))
* Initial pass of F405 support ([#14584](https://github.com/qmk/qmk_firmware/pull/14584)) * Initial pass of F405 support ([#14584](https://github.com/qmk/qmk_firmware/pull/14584))
### EEPROM Changes :id=eeprom-changes ### EEPROM Changes {#eeprom-changes}
There were a few EEPROM-related changes that landed during this breaking changes cycle, most prominently the long-awaited ability for the Drop boards to gain persistent storage. Any users of the Drop CTRL or Drop ALT should update QMK Toolbox as well -- coupled with a QMK firmware update settings should now be saved. There were a few EEPROM-related changes that landed during this breaking changes cycle, most prominently the long-awaited ability for the Drop boards to gain persistent storage. Any users of the Drop CTRL or Drop ALT should update QMK Toolbox as well -- coupled with a QMK firmware update settings should now be saved.
@ -197,7 +197,7 @@ There were a few EEPROM-related changes that landed during this breaking changes
* Further tidy up of STM32 eeprom emulation ([#14591](https://github.com/qmk/qmk_firmware/pull/14591)) * Further tidy up of STM32 eeprom emulation ([#14591](https://github.com/qmk/qmk_firmware/pull/14591))
* Enable eeprom with F401xE ld ([#14752](https://github.com/qmk/qmk_firmware/pull/14752)) * Enable eeprom with F401xE ld ([#14752](https://github.com/qmk/qmk_firmware/pull/14752))
### Compilation Database :id=compile-commands ### Compilation Database {#compile-commands}
A clang-compatible compilation database generator has been added as an option in order to help development environments such as Visual Studio Code. A clang-compatible compilation database generator has been added as an option in order to help development environments such as Visual Studio Code.
@ -208,7 +208,7 @@ Do note that switching keyboards will require re-generation of this file.
* New CLI subcommand to create clang-compatible compilation database (`compile_commands.json`) ([#14370](https://github.com/qmk/qmk_firmware/pull/14370)) * New CLI subcommand to create clang-compatible compilation database (`compile_commands.json`) ([#14370](https://github.com/qmk/qmk_firmware/pull/14370))
* compiledb: query include paths from gcc directly. ([#14462](https://github.com/qmk/qmk_firmware/pull/14462)) * compiledb: query include paths from gcc directly. ([#14462](https://github.com/qmk/qmk_firmware/pull/14462))
### Codebase restructure and cleanup :id=codebase-restructure ### Codebase restructure and cleanup {#codebase-restructure}
QMK continues on its restructuring journey, in order to make it easier to integrate newer features and add support for new hardware. This quarter's batch of changes include: QMK continues on its restructuring journey, in order to make it easier to integrate newer features and add support for new hardware. This quarter's batch of changes include:

14
docs/ChangeLog/20220226.md
View File

@ -1,6 +1,6 @@
# QMK Breaking Changes - 2022 February 26 Changelog # QMK Breaking Changes - 2022 February 26 Changelog
## Notable Features :id=notable-features ## Notable Features {#notable-features}
### Default USB Polling rate now 1kHz ([#15352](https://github.com/qmk/qmk_firmware/pull/15352)) ### Default USB Polling rate now 1kHz ([#15352](https://github.com/qmk/qmk_firmware/pull/15352))
@ -12,13 +12,13 @@ Something something *Lets go gamers!*
Pointing devices can now be shared across a split keyboard with support for a single pointing device or a pointing device on each side. Pointing devices can now be shared across a split keyboard with support for a single pointing device or a pointing device on each side.
See the [Pointing Device](feature_pointing_device.md) documentation for further configuration options. See the [Pointing Device](../feature_pointing_device) documentation for further configuration options.
## Changes Requiring User Action :id=changes-requiring-user-action ## Changes Requiring User Action {#changes-requiring-user-action}
### Legacy macro and action_function system removed ([#16025](https://github.com/qmk/qmk_firmware/pull/16025)) ### Legacy macro and action_function system removed ([#16025](https://github.com/qmk/qmk_firmware/pull/16025))
The long time deprecated `MACRO()` and `action_get_macro` methods have been removed. Where possible, existing usages have been migrated over to core [Macros](feature_macros.md). The long time deprecated `MACRO()` and `action_get_macro` methods have been removed. Where possible, existing usages have been migrated over to core [Macros](../feature_macros).
### Create a build error if no bootloader is specified ([#16181](https://github.com/qmk/qmk_firmware/pull/16181)) ### Create a build error if no bootloader is specified ([#16181](https://github.com/qmk/qmk_firmware/pull/16181))
@ -31,7 +31,7 @@ Bootloader configuration is no longer assumed. Keyboards must now set either:
In preparation of future bluetooth work, the `AdafruitBLE` integration has been renamed to allow potential for any other Adafruit BLE products. In preparation of future bluetooth work, the `AdafruitBLE` integration has been renamed to allow potential for any other Adafruit BLE products.
### Updated Keyboard Codebases :id=updated-keyboard-codebases ### Updated Keyboard Codebases {#updated-keyboard-codebases}
The following keyboards have had their source moved within QMK: The following keyboards have had their source moved within QMK:
@ -241,9 +241,9 @@ The following keyboards have had their source moved within QMK:
| zinc/rev1 | 25keys/zinc/rev1 | | zinc/rev1 | 25keys/zinc/rev1 |
| zinc/reva | 25keys/zinc/reva | | zinc/reva | 25keys/zinc/reva |
## Notable core changes :id=notable-core ## Notable core changes {#notable-core}
### New MCU Support :id=new-mcu-support ### New MCU Support {#new-mcu-support}
Building on previous cycles, QMK firmware picked up support for a couple extra MCU variants: Building on previous cycles, QMK firmware picked up support for a couple extra MCU variants:

34
docs/ChangeLog/20220528.md
View File

@ -1,16 +1,16 @@
# QMK Breaking Changes - 2022 May 28 Changelog # QMK Breaking Changes - 2022 May 28 Changelog
## Notable Features :id=notable-features ## Notable Features {#notable-features}
### Caps Word ([#16588](https://github.com/qmk/qmk_firmware/pull/16588)) :id=caps-word ### Caps Word ([#16588](https://github.com/qmk/qmk_firmware/pull/16588)) {#caps-word}
This is a new feature that allows for capslock-like functionality that turns itself off at the end of the word. This is a new feature that allows for capslock-like functionality that turns itself off at the end of the word.
For instance, if you wish to type "QMK" without holding shift the entire time, you can either tap both left and right shift, or double-tap shift, to turn on _Caps Word_ -- then type `qmk` (lowercase) without holding shift. Once you hit any key other than `a`--`z`, `0`--`9`, `-`, `_`, delete, or backspace, this will go back to normal typing! For instance, if you wish to type "QMK" without holding shift the entire time, you can either tap both left and right shift, or double-tap shift, to turn on _Caps Word_ -- then type `qmk` (lowercase) without holding shift. Once you hit any key other than `a`--`z`, `0`--`9`, `-`, `_`, delete, or backspace, this will go back to normal typing!
There are other activation mechanisms as well as configurable options like timeout and the like -- see the [Caps Word documentation](feature_caps_word.md) for more information. There are other activation mechanisms as well as configurable options like timeout and the like -- see the [Caps Word documentation](../feature_caps_word) for more information.
### Quantum Painter ([#10174](https://github.com/qmk/qmk_firmware/pull/10174)) :id=quantum-painter ### Quantum Painter ([#10174](https://github.com/qmk/qmk_firmware/pull/10174)) {#quantum-painter}
QMK has had support for small OLED displays for some time now, but hasn't really gained too much ability to draw to panels other than the SSD1306 or SH1106 panels. QMK has had support for small OLED displays for some time now, but hasn't really gained too much ability to draw to panels other than the SSD1306 or SH1106 panels.
@ -18,27 +18,31 @@ Quantum Painter is a new drawing subsystem available to suitable ARM and RISC-V
The QMK CLI has new commands added to be able to generate images and fonts for Quantum Painter to digest -- it's even capable of converting animated gifs for display on screen. The QMK CLI has new commands added to be able to generate images and fonts for Quantum Painter to digest -- it's even capable of converting animated gifs for display on screen.
See the [Quantum Painter documentation](quantum_painter.md) for more information on how to set up the displays as well as how to convert images and fonts. See the [Quantum Painter documentation](../quantum_painter) for more information on how to set up the displays as well as how to convert images and fonts.
!> Quantum Painter is not supported on AVR due to complexity and size constraints. Boards based on AVR such as ProMicro or Elite-C builds will not be able to leverage Quantum Painter. ::: warning
Quantum Painter is not supported on AVR due to complexity and size constraints. Boards based on AVR such as ProMicro or Elite-C builds will not be able to leverage Quantum Painter.
:::
### Encoder Mapping ([#13286](https://github.com/qmk/qmk_firmware/pull/13286)) :id=encoder-mapping ### Encoder Mapping ([#13286](https://github.com/qmk/qmk_firmware/pull/13286)) {#encoder-mapping}
One of the long-standing complaints with Encoders is that there has been no easy way to configure them in user keymaps. [#13286](https://github.com/qmk/qmk_firmware/pull/13286) added support for [Encoder Mapping](feature_encoders.md#encoder-map), which allows users to define encoder functionality in a similar way to their normal keymap. One of the long-standing complaints with Encoders is that there has been no easy way to configure them in user keymaps. [#13286](https://github.com/qmk/qmk_firmware/pull/13286) added support for [Encoder Mapping](../feature_encoders#encoder-map), which allows users to define encoder functionality in a similar way to their normal keymap.
!> This is not yet supported by QMK Configurator. It is also unlikely to ever be supported by VIA. ::: warning
This is not yet supported by QMK Configurator. It is also unlikely to ever be supported by VIA.
:::
## Changes Requiring User Action :id=changes-requiring-user-action ## Changes Requiring User Action {#changes-requiring-user-action}
### `RESET` => `QK_BOOT` ([#17037](https://github.com/qmk/qmk_firmware/pull/17037)) :id=reset-2-qk_boot ### `RESET` => `QK_BOOT` ([#17037](https://github.com/qmk/qmk_firmware/pull/17037)) {#reset-2-qk_boot}
QMK is always in the process of picking up support for new hardware platforms. One of the side-effects for future integrations has shown that QMK's usage of `RESET` as a keycode is causing naming collisions. As a result, [#17037](https://github.com/qmk/qmk_firmware/pull/17037) changed usages of `RESET` to the new keycode `QK_BOOT` in the majority of default-like keymaps. At this stage the old keycode is still usable but will likely be removed in the next breaking changes cycle. Users with keymaps containing `RESET` should also move to `QK_BOOT`. QMK is always in the process of picking up support for new hardware platforms. One of the side-effects for future integrations has shown that QMK's usage of `RESET` as a keycode is causing naming collisions. As a result, [#17037](https://github.com/qmk/qmk_firmware/pull/17037) changed usages of `RESET` to the new keycode `QK_BOOT` in the majority of default-like keymaps. At this stage the old keycode is still usable but will likely be removed in the next breaking changes cycle. Users with keymaps containing `RESET` should also move to `QK_BOOT`.
### Sendstring keycode overhaul ([#16941](https://github.com/qmk/qmk_firmware/pull/16941)) :id=sendstring-keycodes ### Sendstring keycode overhaul ([#16941](https://github.com/qmk/qmk_firmware/pull/16941)) {#sendstring-keycodes}
Some keycodes used with `SEND_STRING` and its relatives have been deprecated and may have their old keycode usages removed at a later date. The list of [deprecated keycodes](https://github.com/qmk/qmk_firmware/blob/ebd402788346aa6e88bde1486b2a835684d40d39/quantum/send_string_keycodes.h#L456-L505) should be consulted to determine if you're using one of the older names (the first identifier after `#define`) -- you should swap to the newer variant (the second identifier on the same line). Some keycodes used with `SEND_STRING` and its relatives have been deprecated and may have their old keycode usages removed at a later date. The list of [deprecated keycodes](https://github.com/qmk/qmk_firmware/blob/ebd402788346aa6e88bde1486b2a835684d40d39/quantum/send_string_keycodes.h#L456-L505) should be consulted to determine if you're using one of the older names (the first identifier after `#define`) -- you should swap to the newer variant (the second identifier on the same line).
### Pillow Installation ([#17133](https://github.com/qmk/qmk_firmware/pull/17133)) :id=pillow-install ### Pillow Installation ([#17133](https://github.com/qmk/qmk_firmware/pull/17133)) {#pillow-install}
The merge of Quantum Painter added some new dependencies in the QMK CLI, most notably _Pillow_, which requires some installation in order for the CLI to function. If you've got an existing installation, you'll need to run some commands in order to get things working: The merge of Quantum Painter added some new dependencies in the QMK CLI, most notably _Pillow_, which requires some installation in order for the CLI to function. If you've got an existing installation, you'll need to run some commands in order to get things working:
@ -62,7 +66,7 @@ On Linux or WSL:
python3 -m pip install --user --upgrade qmk python3 -m pip install --user --upgrade qmk
``` ```
### Updated Keyboard Codebases :id=updated-keyboard-codebases ### Updated Keyboard Codebases {#updated-keyboard-codebases}
The following keyboards have had their source moved within QMK: The following keyboards have had their source moved within QMK:
@ -97,7 +101,7 @@ The following keyboards have had their source moved within QMK:
--- ---
## Full changelist :id=full-changelist ## Full changelist {#full-changelist}
Core: Core:
* Quantum Painter ([#10174](https://github.com/qmk/qmk_firmware/pull/10174)) * Quantum Painter ([#10174](https://github.com/qmk/qmk_firmware/pull/10174))

32
docs/ChangeLog/20220827.md
View File

@ -1,28 +1,28 @@
# QMK Breaking Changes - 2022 August 27 Changelog # QMK Breaking Changes - 2022 August 27 Changelog
## Notable Features :id=notable-features ## Notable Features {#notable-features}
### Add Raspberry Pi RP2040 support ([#14877](https://github.com/qmk/qmk_firmware/pull/14877), [#17514](https://github.com/qmk/qmk_firmware/pull/17514), [#17516](https://github.com/qmk/qmk_firmware/pull/17516), [#17519](https://github.com/qmk/qmk_firmware/pull/17519), [#17612](https://github.com/qmk/qmk_firmware/pull/17612), [#17512](https://github.com/qmk/qmk_firmware/pull/17512), [#17557](https://github.com/qmk/qmk_firmware/pull/17557), [#17817](https://github.com/qmk/qmk_firmware/pull/17817), [#17839](https://github.com/qmk/qmk_firmware/pull/17839), [#18100](https://github.com/qmk/qmk_firmware/pull/18100)) :id=rp2040-support ### Add Raspberry Pi RP2040 support ([#14877](https://github.com/qmk/qmk_firmware/pull/14877), [#17514](https://github.com/qmk/qmk_firmware/pull/17514), [#17516](https://github.com/qmk/qmk_firmware/pull/17516), [#17519](https://github.com/qmk/qmk_firmware/pull/17519), [#17612](https://github.com/qmk/qmk_firmware/pull/17612), [#17512](https://github.com/qmk/qmk_firmware/pull/17512), [#17557](https://github.com/qmk/qmk_firmware/pull/17557), [#17817](https://github.com/qmk/qmk_firmware/pull/17817), [#17839](https://github.com/qmk/qmk_firmware/pull/17839), [#18100](https://github.com/qmk/qmk_firmware/pull/18100)) {#rp2040-support}
QMK _finally_ picked up support for RP2040-based boards, such as the Raspberry Pi Pico, the Sparkfun Pro Micro RP2040, and the Adafruit KB2040. One of QMK's newest collaborators, _@KarlK90_, effectively did `/micdrop` with RP2040, with a massive set of changes to both QMK and the repository QMK uses for the base platform support, ChibiOS[-Contrib]. There has been a flurry of development this breaking changes cycle related to RP2040 from a large number of contributors -- so much so that almost all standard QMK hardware subsystems are supported. QMK _finally_ picked up support for RP2040-based boards, such as the Raspberry Pi Pico, the Sparkfun Pro Micro RP2040, and the Adafruit KB2040. One of QMK's newest collaborators, _@KarlK90_, effectively did `/micdrop` with RP2040, with a massive set of changes to both QMK and the repository QMK uses for the base platform support, ChibiOS[-Contrib]. There has been a flurry of development this breaking changes cycle related to RP2040 from a large number of contributors -- so much so that almost all standard QMK hardware subsystems are supported.
Check the [RP2040 platform development page](platformdev_rp2040.md) for all supported peripherals and other hardware implementation details. Check the [RP2040 platform development page](../platformdev_rp2040) for all supported peripherals and other hardware implementation details.
### Allow `qmk flash` to use prebuilt firmware binaries ([#16584](https://github.com/qmk/qmk_firmware/pull/16584)) :id=cli-flash-binaries ### Allow `qmk flash` to use prebuilt firmware binaries ([#16584](https://github.com/qmk/qmk_firmware/pull/16584)) {#cli-flash-binaries}
A long-requested capability of the QMK CLI has been the ability to flash binaries directly, without needing to build a firmware. QMK provides prebuilt `develop`-based default firmwares on our [CI page](https://qmk.tzarc.io/) -- normally people would need [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases/latest) to flash them. This new functionality written by _@Erovia_ allows `qmk flash` to be provided the prebuilt file instead, simplifying the workflow for people who haven't got Toolbox available. A long-requested capability of the QMK CLI has been the ability to flash binaries directly, without needing to build a firmware. QMK provides prebuilt `develop`-based default firmwares on our [CI page](https://qmk.tzarc.io/) -- normally people would need [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases/latest) to flash them. This new functionality written by _@Erovia_ allows `qmk flash` to be provided the prebuilt file instead, simplifying the workflow for people who haven't got Toolbox available.
## Changes Requiring User Action :id=changes-requiring-user-action ## Changes Requiring User Action {#changes-requiring-user-action}
### Default layers dropped from 32 to 16 ([#15286](https://github.com/qmk/qmk_firmware/pull/15286)) ### Default layers dropped from 32 to 16 ([#15286](https://github.com/qmk/qmk_firmware/pull/15286))
QMK allows for controlling the maximum number of layers it supports through `LAYER_STATE_(8|16|32)BIT`. Each definition allows for the same number of maximum layers -- `LAYER_STATE_8BIT` => 8 layers. There is also a corresponding firmware size decrease that goes along with smaller numbers -- given the vast majority of users don't use more than 16 layers the default has been swapped to 16. AVR users who were not previously specifying their max layer count may see some space freed up as a result. QMK allows for controlling the maximum number of layers it supports through `LAYER_STATE_(8|16|32)BIT`. Each definition allows for the same number of maximum layers -- `LAYER_STATE_8BIT` => 8 layers. There is also a corresponding firmware size decrease that goes along with smaller numbers -- given the vast majority of users don't use more than 16 layers the default has been swapped to 16. AVR users who were not previously specifying their max layer count may see some space freed up as a result.
### `RESET` => `QK_BOOT` ([#17940](https://github.com/qmk/qmk_firmware/pull/17940)) :id=reset-2-qk_boot ### `RESET` => `QK_BOOT` ([#17940](https://github.com/qmk/qmk_firmware/pull/17940)) {#reset-2-qk_boot}
Following the last breaking changes cycle, QMK has been migrating usages of `RESET` to `QK_BOOT` due to naming collisions with our upstream board support packages. [#17940](https://github.com/qmk/qmk_firmware/pull/17940) converts user keymaps across to use the new keycode name. `RESET` should also move to `QK_BOOT`. Following the last breaking changes cycle, QMK has been migrating usages of `RESET` to `QK_BOOT` due to naming collisions with our upstream board support packages. [#17940](https://github.com/qmk/qmk_firmware/pull/17940) converts user keymaps across to use the new keycode name. `RESET` should also move to `QK_BOOT`.
### Updated Keyboard Codebases :id=updated-keyboard-codebases ### Updated Keyboard Codebases {#updated-keyboard-codebases}
The following keyboards have had their source moved within QMK: The following keyboards have had their source moved within QMK:
@ -33,7 +33,7 @@ The following keyboards have had their source moved within QMK:
| idobao/id80/v1/ansi | idobao/id80/v2/ansi | | idobao/id80/v1/ansi | idobao/id80/v2/ansi |
| idobao/id80/v1/iso | idobao/id80/v2/iso | | idobao/id80/v1/iso | idobao/id80/v2/iso |
### Data-driven USB IDs Refactoring ([#18152](https://github.com/qmk/qmk_firmware/pull/18152)) :id=usb-ids-Refactoring ### Data-driven USB IDs Refactoring ([#18152](https://github.com/qmk/qmk_firmware/pull/18152)) {#usb-ids-Refactoring}
QMK has decided to deprecate the specification of USB IDs inside `config.h` in favour of `info.json`, eventually leaving data-driven as the only method to specify USB information. QMK has decided to deprecate the specification of USB IDs inside `config.h` in favour of `info.json`, eventually leaving data-driven as the only method to specify USB information.
@ -67,25 +67,25 @@ Replaced by `info.json`:
- From 2022 Aug 27, specifying USB information in `config.h` will produce warnings during build but will still function as previously. - From 2022 Aug 27, specifying USB information in `config.h` will produce warnings during build but will still function as previously.
- From 2022 Nov 26, specifying USB information in `config.h` will cause compilation to fail. - From 2022 Nov 26, specifying USB information in `config.h` will cause compilation to fail.
## Notable core changes :id=notable-core ## Notable core changes {#notable-core}
### Board converters ([#17514](https://github.com/qmk/qmk_firmware/pull/17514), [#17603](https://github.com/qmk/qmk_firmware/pull/17603), [#17711](https://github.com/qmk/qmk_firmware/pull/17711), [#17827](https://github.com/qmk/qmk_firmware/pull/17827), [#17593](https://github.com/qmk/qmk_firmware/pull/17593), [#17652](https://github.com/qmk/qmk_firmware/pull/17652), [#17595](https://github.com/qmk/qmk_firmware/pull/17595)) :id=board-converters ### Board converters ([#17514](https://github.com/qmk/qmk_firmware/pull/17514), [#17603](https://github.com/qmk/qmk_firmware/pull/17603), [#17711](https://github.com/qmk/qmk_firmware/pull/17711), [#17827](https://github.com/qmk/qmk_firmware/pull/17827), [#17593](https://github.com/qmk/qmk_firmware/pull/17593), [#17652](https://github.com/qmk/qmk_firmware/pull/17652), [#17595](https://github.com/qmk/qmk_firmware/pull/17595)) {#board-converters}
Historically QMK had a `CONVERT_TO_PROTON_C` directive for `rules.mk` to allow people to replace an AVR-based Pro Micro with a QMK Proton C. Global parts shortages have prompted people to create their own pin-compatible boards -- QMK has made this conversion generic and now allows for drop-in replacements for a lot more boards. see the [Converters Feature](feature_converters.md) documentation for the full list of supported replacement boards -- in this breaking changes cycle we've gone from 1 to 7. Historically QMK had a `CONVERT_TO_PROTON_C` directive for `rules.mk` to allow people to replace an AVR-based Pro Micro with a QMK Proton C. Global parts shortages have prompted people to create their own pin-compatible boards -- QMK has made this conversion generic and now allows for drop-in replacements for a lot more boards. see the [Converters Feature](../feature_converters) documentation for the full list of supported replacement boards -- in this breaking changes cycle we've gone from 1 to 7.
### Add cli command to import keyboard|keymap|kbfirmware ([#16668](https://github.com/qmk/qmk_firmware/pull/16668)) :id=cli-import ### Add cli command to import keyboard|keymap|kbfirmware ([#16668](https://github.com/qmk/qmk_firmware/pull/16668)) {#cli-import}
To help with importing keyboards and keymaps from other sources, _@zvecr_ added [#16668](https://github.com/qmk/qmk_firmware/pull/16668) which adds a new set of commands to the CLI to automatically import keyboards (`qmk import-keyboard -h`), keymaps (`qmk import-keymap -h`), and kbfirmware definitions (`qmk import-kbfirmware -h`) into QMK. To help with importing keyboards and keymaps from other sources, _@zvecr_ added [#16668](https://github.com/qmk/qmk_firmware/pull/16668) which adds a new set of commands to the CLI to automatically import keyboards (`qmk import-keyboard -h`), keymaps (`qmk import-keymap -h`), and kbfirmware definitions (`qmk import-kbfirmware -h`) into QMK.
The now-EOL kbfirmware allowed people who aren't set up with QMK the ability to create keyboard firmwares without requiring a full installation of QMK. Unfortunately, it targets a 7-year-old version of QMK -- adding frustration for users who want the newest features, as well as for QMK maintainers who have to spend time explaining why QMK can't just accept a drive-by code drop from kbfirmware. With any luck, this new command helps both camps! The now-EOL kbfirmware allowed people who aren't set up with QMK the ability to create keyboard firmwares without requiring a full installation of QMK. Unfortunately, it targets a 7-year-old version of QMK -- adding frustration for users who want the newest features, as well as for QMK maintainers who have to spend time explaining why QMK can't just accept a drive-by code drop from kbfirmware. With any luck, this new command helps both camps!
### Generic wear-leveling for EEPROM emulation ([#16996](https://github.com/qmk/qmk_firmware/pull/16996), [#17376](https://github.com/qmk/qmk_firmware/pull/17376), [#18102](https://github.com/qmk/qmk_firmware/pull/18102)) :id=wear-leveling ### Generic wear-leveling for EEPROM emulation ([#16996](https://github.com/qmk/qmk_firmware/pull/16996), [#17376](https://github.com/qmk/qmk_firmware/pull/17376), [#18102](https://github.com/qmk/qmk_firmware/pull/18102)) {#wear-leveling}
QMK has had the ability to write to internal MCU flash in order to emulate EEPROM for some time now, but it was only limited to a small number of MCUs. The base HAL used by QMK for a large number of ARM devices provides a "proper" embedded MCU flash driver, so _@tzarc_ decoupled the wear-leveling algorithm from the old flash writing code, improved it, wrote some tests, and enabled its use for a much larger number of other devices... including RP2040's XIP flash, and external SPI NOR Flash. QMK has had the ability to write to internal MCU flash in order to emulate EEPROM for some time now, but it was only limited to a small number of MCUs. The base HAL used by QMK for a large number of ARM devices provides a "proper" embedded MCU flash driver, so _@tzarc_ decoupled the wear-leveling algorithm from the old flash writing code, improved it, wrote some tests, and enabled its use for a much larger number of other devices... including RP2040's XIP flash, and external SPI NOR Flash.
See the [EEPROM Driver](eeprom_driver.md) documentation for more information. See the [EEPROM Driver](../eeprom_driver) documentation for more information.
### Pointing Device Improvements ([#16371](https://github.com/qmk/qmk_firmware/pull/16371), [#17111](https://github.com/qmk/qmk_firmware/pull/17111), [#17176](https://github.com/qmk/qmk_firmware/pull/17176), [#17482](https://github.com/qmk/qmk_firmware/pull/17482), [#17776](https://github.com/qmk/qmk_firmware/pull/17776), [#17613](https://github.com/qmk/qmk_firmware/pull/17613)) :id=pointing-device-improvements ### Pointing Device Improvements ([#16371](https://github.com/qmk/qmk_firmware/pull/16371), [#17111](https://github.com/qmk/qmk_firmware/pull/17111), [#17176](https://github.com/qmk/qmk_firmware/pull/17176), [#17482](https://github.com/qmk/qmk_firmware/pull/17482), [#17776](https://github.com/qmk/qmk_firmware/pull/17776), [#17613](https://github.com/qmk/qmk_firmware/pull/17613)) {#pointing-device-improvements}
Ever since Pointing Device Driver support and Split Pointing Device support were added by _@drashna_ and _@daskygit_, there has been increased interest in the development of the pointing device subsystem and its associated code. Ever since Pointing Device Driver support and Split Pointing Device support were added by _@drashna_ and _@daskygit_, there has been increased interest in the development of the pointing device subsystem and its associated code.
@ -102,7 +102,7 @@ Other related changes:
--- ---
## Full changelist :id=full-changelist ## Full changelist {#full-changelist}
Core: Core:
* Tentative Teensy 3.5 support ([#14420](https://github.com/qmk/qmk_firmware/pull/14420)) * Tentative Teensy 3.5 support ([#14420](https://github.com/qmk/qmk_firmware/pull/14420))

40
docs/ChangeLog/20221126.md
View File

@ -1,14 +1,14 @@
# QMK Breaking Changes - 2022 November 26 Changelog # QMK Breaking Changes - 2022 November 26 Changelog
## Notable Features :id=notable-features ## Notable Features {#notable-features}
### Autocorrect ([#15699](https://github.com/qmk/qmk_firmware/pull/15699)) :id=autocorrect ### Autocorrect ([#15699](https://github.com/qmk/qmk_firmware/pull/15699)) {#autocorrect}
_@getreuer_ in their infinite wisdom decided that autocorrect was a feature needed by QMK. As is customary, _@drashna_ adapted it to core and got it into a state that everyone else can use it. See [Feature: Autocorrect](feature_autocorrect.md) for more ifnormation (grin). _@getreuer_ in their infinite wisdom decided that autocorrect was a feature needed by QMK. As is customary, _@drashna_ adapted it to core and got it into a state that everyone else can use it. See [Feature: Autocorrect](../feature_autocorrect) for more ifnormation (grin).
## Changes Requiring User Action :id=changes-requiring-user-action ## Changes Requiring User Action {#changes-requiring-user-action}
### Updated Keyboard Codebases :id=updated-keyboard-codebases ### Updated Keyboard Codebases {#updated-keyboard-codebases}
The following keyboards have had their source moved within QMK: The following keyboards have had their source moved within QMK:
@ -23,17 +23,19 @@ The following keyboards have had their source moved within QMK:
| handwired/hillside/52 | hillside/52 | | handwired/hillside/52 | hillside/52 |
| maple_computing/christmas_tree/V2017 | maple_computing/christmas_tree/v2017 | | maple_computing/christmas_tree/V2017 | maple_computing/christmas_tree/v2017 |
### Keycodes refactoring :id=keycodes-overhaul-user-action ### Keycodes refactoring {#keycodes-overhaul-user-action}
QMK's keycodes got a very significant overhaul this breaking changes cycle, with the bulk of the work done by _@zvecr_ and _@fauxpark_ -- renaming, reordering, removing has been their focus in this area. In an attempt to standardise interoperation with host applications, keycode values now have strong versioning so that any connected application has confidence that the keys it thinks exist on the board actually match up with what's compiled in. These strongly-versioned keycode definitions are now published online and will not change, so tools that remap keycodes have a reference to work with. In future versions of QMK, any new or changed keycodes will result in a new version specification. See [API docs](api_docs.md#qmk-constants) for more information on the published versions if you're writing a tool to manage keycodes. QMK's keycodes got a very significant overhaul this breaking changes cycle, with the bulk of the work done by _@zvecr_ and _@fauxpark_ -- renaming, reordering, removing has been their focus in this area. In an attempt to standardise interoperation with host applications, keycode values now have strong versioning so that any connected application has confidence that the keys it thinks exist on the board actually match up with what's compiled in. These strongly-versioned keycode definitions are now published online and will not change, so tools that remap keycodes have a reference to work with. In future versions of QMK, any new or changed keycodes will result in a new version specification. See [API docs](../api_docs#qmk-constants) for more information on the published versions if you're writing a tool to manage keycodes.
In most cases user keymaps in the repository have already been updated to reflect the new naming scheme. In some cases user keymaps outside the repository may strike a missing keycode with the old name -- it's highly likely that the name had already been deprecated for some time, and should have been updated previously. In most cases user keymaps in the repository have already been updated to reflect the new naming scheme. In some cases user keymaps outside the repository may strike a missing keycode with the old name -- it's highly likely that the name had already been deprecated for some time, and should have been updated previously.
See below for the full list of changesets. See below for the full list of changesets.
!> Keycode aliases have been put in place in most cases to cater for "old names" being mapped to "new names" -- the documentation already reflects all the new naming of keys. ::: warning
Keycode aliases have been put in place in most cases to cater for "old names" being mapped to "new names" -- the documentation already reflects all the new naming of keys.
:::
### Configuration Item Refactoring :id=config-refactoring ### Configuration Item Refactoring {#config-refactoring}
A number of configuration items have been renamed for consistency. A number of configuration items have been renamed for consistency.
@ -66,7 +68,7 @@ Joystick configuration:
| JOYSTICK_AXES_COUNT | JOYSTICK_AXIS_COUNT | | JOYSTICK_AXES_COUNT | JOYSTICK_AXIS_COUNT |
| JOYSTICK_AXES_RESOLUTION | JOYSTICK_AXIS_RESOLUTION | | JOYSTICK_AXES_RESOLUTION | JOYSTICK_AXIS_RESOLUTION |
### Data-driven USB IDs Refactoring ([#18152](https://github.com/qmk/qmk_firmware/pull/18152)) :id=usb-ids-Refactoring ### Data-driven USB IDs Refactoring ([#18152](https://github.com/qmk/qmk_firmware/pull/18152)) {#usb-ids-Refactoring}
QMK has decided to deprecate the specification of USB IDs inside `config.h` in favour of `info.json`, leaving data-driven as the only method to specify USB information. As per the deprecation schedule put forward last breaking changes cycle, USB information must be specified in `info.json` instead. QMK has decided to deprecate the specification of USB IDs inside `config.h` in favour of `info.json`, leaving data-driven as the only method to specify USB information. As per the deprecation schedule put forward last breaking changes cycle, USB information must be specified in `info.json` instead.
@ -92,7 +94,7 @@ Replaced by `info.json`:
} }
``` ```
### LED Indicator callback refactoring ([#14864](https://github.com/qmk/qmk_firmware/pull/18450)) :id=led-callback-refactor ### LED Indicator callback refactoring ([#14864](https://github.com/qmk/qmk_firmware/pull/18450)) {#led-callback-refactor}
_RGB Matrix_ and _LED Matrix_ Indicator display code was traditionally difficult to override in keymaps as they did not follow the standard pattern of `bool *_kb()` deferring to `bool *_user()` functions, allowing signalling to the higher level that processing had already been done. _RGB Matrix_ and _LED Matrix_ Indicator display code was traditionally difficult to override in keymaps as they did not follow the standard pattern of `bool *_kb()` deferring to `bool *_user()` functions, allowing signalling to the higher level that processing had already been done.
@ -128,15 +130,15 @@ bool rgb_matrix_indicators_kb(void) {
The equivalent transformations should be done for LED Matrix boards. The equivalent transformations should be done for LED Matrix boards.
### Unicode mode refactoring :id=unicode-mode-renaming ### Unicode mode refactoring {#unicode-mode-renaming}
Unicode modes were renamed in order to prevent collision with equivalent keycodes. The available values for `UNICODE_SELECTED_MODES` changed -- see [Feature: Unicode](feature_unicode.md#setting-the-input-mode) for the new list of values and how to configure them. Unicode modes were renamed in order to prevent collision with equivalent keycodes. The available values for `UNICODE_SELECTED_MODES` changed -- see [Feature: Unicode](../feature_unicode#setting-the-input-mode) for the new list of values and how to configure them.
## Notable core changes :id=notable-core ## Notable core changes {#notable-core}
This breaking changes cycle, a lot of the core changes are related to cleanup and refactoring -- commonly called "tech debt". This breaking changes cycle, a lot of the core changes are related to cleanup and refactoring -- commonly called "tech debt".
### Keycodes refactoring :id=keycodes-overhaul-core-changes ### Keycodes refactoring {#keycodes-overhaul-core-changes}
We aren't going to list each and every change -- they're far too numerous -- instead, we'll just list the related PRs in order to convey just how wide-reaching these changes were: We aren't going to list each and every change -- they're far too numerous -- instead, we'll just list the related PRs in order to convey just how wide-reaching these changes were:
@ -181,7 +183,7 @@ We aren't going to list each and every change -- they're far too numerous -- ins
* Remove legacy sendstring keycodes ([#18749](https://github.com/qmk/qmk_firmware/pull/18749)) * Remove legacy sendstring keycodes ([#18749](https://github.com/qmk/qmk_firmware/pull/18749))
* Reworked backlight keycodes. ([#18961](https://github.com/qmk/qmk_firmware/pull/18961)) * Reworked backlight keycodes. ([#18961](https://github.com/qmk/qmk_firmware/pull/18961))
### Board Converters :id=board-converters ### Board Converters {#board-converters}
There was additional work in the space of board converters -- historically QMK allowed for "converting" a Pro Micro build to a QMK Proton-C build. The last few versions of QMK have added support for replacement boards much like the Proton-C, and this quarter was no exception: There was additional work in the space of board converters -- historically QMK allowed for "converting" a Pro Micro build to a QMK Proton-C build. The last few versions of QMK have added support for replacement boards much like the Proton-C, and this quarter was no exception:
@ -191,9 +193,9 @@ There was additional work in the space of board converters -- historically QMK a
* Add Elite-Pi converter ([#18236](https://github.com/qmk/qmk_firmware/pull/18236)) * Add Elite-Pi converter ([#18236](https://github.com/qmk/qmk_firmware/pull/18236))
* Allow QK_MAKE to work with converters ([#18637](https://github.com/qmk/qmk_firmware/pull/18637)) * Allow QK_MAKE to work with converters ([#18637](https://github.com/qmk/qmk_firmware/pull/18637))
See [Feature: Converters](feature_converters.md) for the full list of board conversions available. See [Feature: Converters](../feature_converters) for the full list of board conversions available.
### Pointing and Digitizer device updates :id=pointing-and-digitizer ### Pointing and Digitizer device updates {#pointing-and-digitizer}
Both pointing devices and digitizer got a host of updates this cycle. Inertia, automatic mouse layers, fixes for preventing sleep... you even get more buttons with digitizers! Both pointing devices and digitizer got a host of updates this cycle. Inertia, automatic mouse layers, fixes for preventing sleep... you even get more buttons with digitizers!
@ -207,7 +209,7 @@ Both pointing devices and digitizer got a host of updates this cycle. Inertia, a
* Invert pointing device motion pin for cirque touchpads ([#18404](https://github.com/qmk/qmk_firmware/pull/18404)) * Invert pointing device motion pin for cirque touchpads ([#18404](https://github.com/qmk/qmk_firmware/pull/18404))
* Refactor more host code (programmable button & digitizer) ([#18565](https://github.com/qmk/qmk_firmware/pull/18565)) * Refactor more host code (programmable button & digitizer) ([#18565](https://github.com/qmk/qmk_firmware/pull/18565))
## Full changelist :id=full-changelist ## Full changelist {#full-changelist}
Core: Core:
* quantum: led: split out led_update_ports() for customization of led behaviour ([#14452](https://github.com/qmk/qmk_firmware/pull/14452)) * quantum: led: split out led_update_ports() for customization of led behaviour ([#14452](https://github.com/qmk/qmk_firmware/pull/14452))

20
docs/ChangeLog/20230226.md
View File

@ -1,8 +1,8 @@
# QMK Breaking Changes - 2023 February 26 Changelog # QMK Breaking Changes - 2023 February 26 Changelog
## Changes Requiring User Action :id=changes-requiring-user-action ## Changes Requiring User Action {#changes-requiring-user-action}
### `IGNORE_MOD_TAP_INTERRUPT` behaviour changes ([#15741](https://github.com/qmk/qmk_firmware/pull/15741)) :id=i-m-t-i ### `IGNORE_MOD_TAP_INTERRUPT` behaviour changes ([#15741](https://github.com/qmk/qmk_firmware/pull/15741)) {#i-m-t-i}
`IGNORE_MOD_TAP_INTERRUPT_PER_KEY` has been removed and `IGNORE_MOD_TAP_INTERRUPT` deprecated as a stepping stone towards making `IGNORE_MOD_TAP_INTERRUPT` the new default behavior for mod-taps in the future. `IGNORE_MOD_TAP_INTERRUPT_PER_KEY` has been removed and `IGNORE_MOD_TAP_INTERRUPT` deprecated as a stepping stone towards making `IGNORE_MOD_TAP_INTERRUPT` the new default behavior for mod-taps in the future.
@ -46,9 +46,9 @@ bool get_hold_on_other_key_press(uint16_t keycode, keyrecord_t *record) {
} }
``` ```
For more information, you are invited to read the sections on [IGNORE_MOD_TAP_INTERRUPT](tap_hold.md#ignore-mod-tap-interrupt) and [HOLD_ON_OTHER_KEY_PRESS](tap_hold.md#hold-on-other-key-press) in the page on [Tap-Hold configuration options](tap_hold.md). For more information, you are invited to read the sections on [IGNORE_MOD_TAP_INTERRUPT](../tap_hold#ignore-mod-tap-interrupt) and [HOLD_ON_OTHER_KEY_PRESS](../tap_hold#hold-on-other-key-press) in the page on [Tap-Hold configuration options](../tap_hold).
### `TAPPING_FORCE_HOLD` => `QUICK_TAP_TERM` ([#17007](https://github.com/qmk/qmk_firmware/pull/17007)) :id=quick-tap-term ### `TAPPING_FORCE_HOLD` => `QUICK_TAP_TERM` ([#17007](https://github.com/qmk/qmk_firmware/pull/17007)) {#quick-tap-term}
`TAPPING_FORCE_HOLD` feature is now replaced by `QUICK_TAP_TERM`. Instead of turning off auto-repeat completely, user will have the option to configure a `QUICK_TAP_TERM` in milliseconds. When the user holds a tap-hold key after tapping it within `QUICK_TAP_TERM`, QMK will send the tap keycode to the host, enabling auto-repeat. `TAPPING_FORCE_HOLD` feature is now replaced by `QUICK_TAP_TERM`. Instead of turning off auto-repeat completely, user will have the option to configure a `QUICK_TAP_TERM` in milliseconds. When the user holds a tap-hold key after tapping it within `QUICK_TAP_TERM`, QMK will send the tap keycode to the host, enabling auto-repeat.
@ -80,9 +80,9 @@ uint16_t get_quick_tap_term(uint16_t keycode, keyrecord_t *record) {
} }
``` ```
For more details, please read the updated documentation section on [Quick Tap Term](tap_hold.md#quick-tap-term). For more details, please read the updated documentation section on [Quick Tap Term](../tap_hold#quick-tap-term).
### Leader Key Rework :id=leader-key-rework ([#19632](https://github.com/qmk/qmk_firmware/pull/19632)) ### Leader Key Rework {#leader-key-rework ([#19632](https://github.com/qmk/qmk_firmware/pull/19632))}
The Leader Key feature API has been significantly improved, along with some bugfixes and added tests. The Leader Key feature API has been significantly improved, along with some bugfixes and added tests.
@ -106,9 +106,9 @@ void leader_end_user(void) {
} }
``` ```
For more information please see the [Leader Key documentation](feature_leader_key.md). For more information please see the [Leader Key documentation](../feature_leader_key).
### Updated Keyboard Codebases :id=updated-keyboard-codebases ### Updated Keyboard Codebases {#updated-keyboard-codebases}
The following keyboards have had their source moved within QMK: The following keyboards have had their source moved within QMK:
@ -130,7 +130,7 @@ The following keyboards have had their source moved within QMK:
| the_uni | stenothe_uni | | the_uni | stenothe_uni |
| xelus/xs60 | xelus/xs60/soldered | | xelus/xs60 | xelus/xs60/soldered |
## Notable core changes :id=notable-core ## Notable core changes {#notable-core}
As per last breaking changes cycle, there has been _a lot_ of emphasis on behind-the-scenes changes, mainly around consolidation of core subsystems and constant values, as well as addressing tech debt. Whilst not outwardly visible, this cleanup and refactoring should start paying dividends as it simplifies future development and maintenance. As per last breaking changes cycle, there has been _a lot_ of emphasis on behind-the-scenes changes, mainly around consolidation of core subsystems and constant values, as well as addressing tech debt. Whilst not outwardly visible, this cleanup and refactoring should start paying dividends as it simplifies future development and maintenance.
@ -142,7 +142,7 @@ A handful of examples:
* Many more configuration options have moved into `info.json`, such as backlight, encoders * Many more configuration options have moved into `info.json`, such as backlight, encoders
* Additional unit tests to ensure keycode behaviours don't accidentally change * Additional unit tests to ensure keycode behaviours don't accidentally change
## Full changelist :id=full-changelist ## Full changelist {#full-changelist}
Core: Core:
* Remove IGNORE_MOD_TAP_INTERRUPT_PER_KEY in favour of HOLD_ON_OTHER_KEY_PRESS_PER_KEY ([#15741](https://github.com/qmk/qmk_firmware/pull/15741)) * Remove IGNORE_MOD_TAP_INTERRUPT_PER_KEY in favour of HOLD_ON_OTHER_KEY_PRESS_PER_KEY ([#15741](https://github.com/qmk/qmk_firmware/pull/15741))

32
docs/ChangeLog/20230528.md
View File

@ -1,6 +1,6 @@
# QMK Breaking Changes - 2023 May 28 Changelog # QMK Breaking Changes - 2023 May 28 Changelog
## Notable Changes :id=notable-changes ## Notable Changes {#notable-changes}
As per last breaking changes cycle, there has been _a lot_ of emphasis on behind-the-scenes changes, mainly around migration of configurables into `info.json` files, cleanup of `info.json` files, additional layout definitions for keyboards, adding support for general community layouts to keyboards, as well as addressing technical debt. As per last breaking changes cycle, there has been _a lot_ of emphasis on behind-the-scenes changes, mainly around migration of configurables into `info.json` files, cleanup of `info.json` files, additional layout definitions for keyboards, adding support for general community layouts to keyboards, as well as addressing technical debt.
@ -20,11 +20,11 @@ Of note for keyboard designers:
* `encoder_map[][NUM_ENCODERS][2]` => `encoder_map[][NUM_ENCODERS][NUM_DIRECTIONS]` * `encoder_map[][NUM_ENCODERS][2]` => `encoder_map[][NUM_ENCODERS][NUM_DIRECTIONS]`
* Users assumed the `2` referred to the number of encoders, rather than the number of directions (which is always 2) * Users assumed the `2` referred to the number of encoders, rather than the number of directions (which is always 2)
### Repeat last key ([#19700](https://github.com/qmk/qmk_firmware/pull/19700)) :id=repeat-last-key ### Repeat last key ([#19700](https://github.com/qmk/qmk_firmware/pull/19700)) {#repeat-last-key}
A new pair of keys has been added to QMK -- namely `QK_REPEAT_KEY` and `QK_ALT_REPEAT_KEY` (shortened: `QK_REP`/`QK_AREP`). These allow you to repeat the last key pressed, or in the case of the alternate key, press the "opposite" of the last key. For example, if you press `KC_LEFT`, pressing `QK_REPEAT_KEY` afterwards repeats `KC_LEFT`, but pressing `QK_ALT_REPEAT_KEY` instead sends `KC_RIGHT`. A new pair of keys has been added to QMK -- namely `QK_REPEAT_KEY` and `QK_ALT_REPEAT_KEY` (shortened: `QK_REP`/`QK_AREP`). These allow you to repeat the last key pressed, or in the case of the alternate key, press the "opposite" of the last key. For example, if you press `KC_LEFT`, pressing `QK_REPEAT_KEY` afterwards repeats `KC_LEFT`, but pressing `QK_ALT_REPEAT_KEY` instead sends `KC_RIGHT`.
The full list of default alternate keys is available on the [Repeat Key](feature_repeat_key.md) documentation. The full list of default alternate keys is available on the [Repeat Key](../feature_repeat_key) documentation.
To enable these keys, in your keymap's `rules.mk`, add: To enable these keys, in your keymap's `rules.mk`, add:
@ -34,27 +34,27 @@ REPEAT_KEY_ENABLE = yes
...and add them to your keymap. ...and add them to your keymap.
### User callback for pre process record ([#20584](https://github.com/qmk/qmk_firmware/pull/20584)) :id=user-callback-for-pre-process-record ### User callback for pre process record ([#20584](https://github.com/qmk/qmk_firmware/pull/20584)) {#user-callback-for-pre-process-record}
Two new boolean callback functions, `pre_process_record_kb` and `pre_process_record_user`, have been added. They are called at the beginning of `process_record`, right before `process_combo`. Two new boolean callback functions, `pre_process_record_kb` and `pre_process_record_user`, have been added. They are called at the beginning of `process_record`, right before `process_combo`.
Similar to existing `*_kb` and `*_user` callback functions, returning `false` will halt further processing of key events. The `pre_process_record_user` function will allow user space opportunity to handle or capture an input before it undergoes quantum processing. For example, while action tapping is still resolving the tap or hold output of a mod-tap key, `pre_process_record_user` can capture the next key record of an input event that follows. That key record can be used to influence the [decision of the mod-tap](https://docs.qmk.fm/#/tap_hold) key that is currently undergoing quantum processing. Similar to existing `*_kb` and `*_user` callback functions, returning `false` will halt further processing of key events. The `pre_process_record_user` function will allow user space opportunity to handle or capture an input before it undergoes quantum processing. For example, while action tapping is still resolving the tap or hold output of a mod-tap key, `pre_process_record_user` can capture the next key record of an input event that follows. That key record can be used to influence the [decision of the mod-tap](../tap_hold) key that is currently undergoing quantum processing.
### Consolidate modelm ([#14996](https://github.com/qmk/qmk_firmware/pull/14996) :id=consolidate-modelm ### Consolidate modelm ([#14996](https://github.com/qmk/qmk_firmware/pull/14996) {#consolidate-modelm}
Several build targets for the IBM Model M were cluttered in different folders. The maintainers of several Model M replacement controller projects agreed to consolidate them under one common folder. Several build targets for the IBM Model M were cluttered in different folders. The maintainers of several Model M replacement controller projects agreed to consolidate them under one common folder.
The list of all moved keyboard locations is listed [below](20230528.md#updated-keyboard-codebases). The list of all moved keyboard locations is listed [below](20230528#updated-keyboard-codebases).
## Changes Requiring User Action :id=changes-requiring-user-action ## Changes Requiring User Action {#changes-requiring-user-action}
### `IGNORE_MOD_TAP_INTERRUPT` behaviour changes ([#20211](https://github.com/qmk/qmk_firmware/pull/20211)) :id=i-m-t-i ### `IGNORE_MOD_TAP_INTERRUPT` behaviour changes ([#20211](https://github.com/qmk/qmk_firmware/pull/20211)) {#i-m-t-i}
Following up from the last breaking changes cycle, `IGNORE_MOD_TAP_INTERRUPT` has been removed and if present in keymap code, will now fail to build. The previous functionality for `IGNORE_MOD_TAP_INTERRUPT` is now default, and should you wish to revert to the old behaviour, you can use `HOLD_ON_OTHER_KEY_PRESS` instead. Following up from the last breaking changes cycle, `IGNORE_MOD_TAP_INTERRUPT` has been removed and if present in keymap code, will now fail to build. The previous functionality for `IGNORE_MOD_TAP_INTERRUPT` is now default, and should you wish to revert to the old behaviour, you can use `HOLD_ON_OTHER_KEY_PRESS` instead.
For more information, you are invited to read the section on [HOLD_ON_OTHER_KEY_PRESS](tap_hold.md#hold-on-other-key-press) in the page on [Tap-Hold configuration options](tap_hold.md). For more information, you are invited to read the section on [HOLD_ON_OTHER_KEY_PRESS](../tap_hold#hold-on-other-key-press) in the page on [Tap-Hold configuration options](../tap_hold).
### Updated Keyboard Codebases :id=updated-keyboard-codebases ### Updated Keyboard Codebases {#updated-keyboard-codebases}
| Old Keyboard Name | New Keyboard Name | | Old Keyboard Name | New Keyboard Name |
|---------------------------------|-------------------------------------| |---------------------------------|-------------------------------------|
@ -77,9 +77,9 @@ For more information, you are invited to read the section on [HOLD_ON_OTHER_KEY_
| tronguylabs/m122_3270/teensy | ibm/model_m_122/m122_3270/teensy | | tronguylabs/m122_3270/teensy | ibm/model_m_122/m122_3270/teensy |
| yugo_m/model_m_101 | ibm/model_m/yugo_m | | yugo_m/model_m_101 | ibm/model_m/yugo_m |
## Notable core changes :id=notable-core ## Notable core changes {#notable-core}
### Encoder functionality fallback ([#20320](https://github.com/qmk/qmk_firmware/pull/20320)) :id=encoder-functionality-fallback ### Encoder functionality fallback ([#20320](https://github.com/qmk/qmk_firmware/pull/20320)) {#encoder-functionality-fallback}
For keyboards who have not yet been migrated to encoder map, a default set of encoder functionality is now enabled, gracefully degrading functionality depending on which flags are enabled by the keyboard: For keyboards who have not yet been migrated to encoder map, a default set of encoder functionality is now enabled, gracefully degrading functionality depending on which flags are enabled by the keyboard:
@ -89,13 +89,13 @@ For keyboards who have not yet been migrated to encoder map, a default set of en
Additionally, this ensures that builds on QMK Configurator produce some sort of usable encoder mapping. Additionally, this ensures that builds on QMK Configurator produce some sort of usable encoder mapping.
### OLED Driver Improvements ([#20331](https://github.com/qmk/qmk_firmware/pull/20331)) :id=oled-driver-improvements ### OLED Driver Improvements ([#20331](https://github.com/qmk/qmk_firmware/pull/20331)) {#oled-driver-improvements}
The "classic" OLED driver picked up support for additional sizes of OLED displays, support for the SH1107 controller, and SPI-based OLED support. The "classic" OLED driver picked up support for additional sizes of OLED displays, support for the SH1107 controller, and SPI-based OLED support.
Other configurable items are available and can be found on the [OLED Driver page](https://docs.qmk.fm/#/feature_oled_driver). Other configurable items are available and can be found on the [OLED Driver page](../feature_oled_driver).
## Full changelist :id=full-changelist ## Full changelist {#full-changelist}
Core: Core:
* Refactor `keyevent_t` for 1ms timing resolution ([#15847](https://github.com/qmk/qmk_firmware/pull/15847)) * Refactor `keyevent_t` for 1ms timing resolution ([#15847](https://github.com/qmk/qmk_firmware/pull/15847))

22
docs/ChangeLog/20230827.md
View File

@ -1,14 +1,14 @@
# QMK Breaking Changes - 2023 Aug 27 Changelog # QMK Breaking Changes - 2023 Aug 27 Changelog
## Notable Changes :id=notable-changes ## Notable Changes {#notable-changes}
As per last few breaking changes cycles, there have been _a lot_ of behind-the-scenes changes, mainly around migration of configurables into `info.json` files, cleanup of `info.json` files, additional layout definitions for keyboards, adding support for general community layouts to keyboards, as well as addressing technical debt. As per last few breaking changes cycles, there have been _a lot_ of behind-the-scenes changes, mainly around migration of configurables into `info.json` files, cleanup of `info.json` files, additional layout definitions for keyboards, adding support for general community layouts to keyboards, as well as addressing technical debt.
One thing to note for this release -- `qmk/qmk_firmware` is no longer accepting PRs for keymaps other than for manufacturer-supported keymaps. User keymap workflow has been documented [here](https://docs.qmk.fm/#/newbs) for several years. This change is to progressively reduce the maintenance burden on the project, and to allow us to focus on the core features of QMK. One thing to note for this release -- `qmk/qmk_firmware` is no longer accepting PRs for keymaps other than for manufacturer-supported keymaps. User keymap workflow has been documented [here](../newbs) for several years. This change is to progressively reduce the maintenance burden on the project, and to allow us to focus on the core features of QMK.
Existing user keymaps and userspace areas will likely be relocated/removed in the future -- non-building keymaps and userspace will be first targets, likely during the new breaking changes cycle. We will provide more information on Discord regarding this initiative as it becomes available. Existing user keymaps and userspace areas will likely be relocated/removed in the future -- non-building keymaps and userspace will be first targets, likely during the new breaking changes cycle. We will provide more information on Discord regarding this initiative as it becomes available.
### RGB Matrix optimizations ([#21134](https://github.com/qmk/qmk_firmware/pull/21134), [#21135](https://github.com/qmk/qmk_firmware/pull/21135)) :id=rgb-matrix-optimizations ### RGB Matrix optimizations ([#21134](https://github.com/qmk/qmk_firmware/pull/21134), [#21135](https://github.com/qmk/qmk_firmware/pull/21135)) {#rgb-matrix-optimizations}
Most RGB Matrix implementations now check whether or not RGB LED data has changed and skip transmission if it hasn't. This was measured to improve scan frequency in cases of static or infrequently-changing colors. Most RGB Matrix implementations now check whether or not RGB LED data has changed and skip transmission if it hasn't. This was measured to improve scan frequency in cases of static or infrequently-changing colors.
@ -18,9 +18,9 @@ Some audio code relating to "notes" used `double` datatypes, which are implement
AVR sees minimal (if any) benefit -- `double` was interpreted as `float` on AVR anyway. AVR sees minimal (if any) benefit -- `double` was interpreted as `float` on AVR anyway.
## Changes Requiring User Action :id=changes-requiring-user-action ## Changes Requiring User Action {#changes-requiring-user-action}
### Updated Keyboard Codebases :id=updated-keyboard-codebases ### Updated Keyboard Codebases {#updated-keyboard-codebases}
| Old Keyboard Name | New Keyboard Name | | Old Keyboard Name | New Keyboard Name |
|---------------------------------------|-------------------------------------| |---------------------------------------|-------------------------------------|
@ -40,11 +40,11 @@ AVR sees minimal (if any) benefit -- `double` was interpreted as `float` on AVR
| modelh | ibm/model_m/modelh | | modelh | ibm/model_m/modelh |
| vinta | coarse/vinta | | vinta | coarse/vinta |
### Remove encoder in-matrix workaround code ([#20389](https://github.com/qmk/qmk_firmware/pull/20389)) :id=remove-encoder-in-matrix-workaround-code ### Remove encoder in-matrix workaround code ([#20389](https://github.com/qmk/qmk_firmware/pull/20389)) {#remove-encoder-in-matrix-workaround-code}
Some keyboards "hacked" encoder support into spare slots in the key matrix in order to interoperate with VIA. This workaround is no longer necessary, and the code has been removed. If you have a keyboard that uses this workaround, you will need to update your keymap to use the new [Encoder Map](feature_encoders.md#encoder-map) API instead. Some keyboards "hacked" encoder support into spare slots in the key matrix in order to interoperate with VIA. This workaround is no longer necessary, and the code has been removed. If you have a keyboard that uses this workaround, you will need to update your keymap to use the new [Encoder Map](../feature_encoders#encoder-map) API instead.
### Unicodemap keycodes rename ([#21092](https://github.com/qmk/qmk_firmware/pull/21092)) :id=unicodemap-keycodes-rename ### Unicodemap keycodes rename ([#21092](https://github.com/qmk/qmk_firmware/pull/21092)) {#unicodemap-keycodes-rename}
The Unicodemap keycodes have been renamed: The Unicodemap keycodes have been renamed:
@ -53,11 +53,11 @@ The Unicodemap keycodes have been renamed:
| `X(i)` | `UM(i)` | | `X(i)` | `UM(i)` |
| `XP(i,j)` | `UP(i,j)` | | `XP(i,j)` | `UP(i,j)` |
### Remove old OLED API code ([#21651](https://github.com/qmk/qmk_firmware/pull/21651)) :id=remove-old-oled-api-code ### Remove old OLED API code ([#21651](https://github.com/qmk/qmk_firmware/pull/21651)) {#remove-old-oled-api-code}
Old OLED code using `ssd1306.c` `ssd1306.h`, and `SSD1306OLED` and other similar files have been consolidated to use the standard OLED driver. External user keymaps will need to be updated to use the standard OLED driver accordingly. Old OLED code using `ssd1306.c` `ssd1306.h`, and `SSD1306OLED` and other similar files have been consolidated to use the standard OLED driver. External user keymaps will need to be updated to use the standard OLED driver accordingly.
### Driver naming consolidation ([#21551](https://github.com/qmk/qmk_firmware/pull/21551), [#21558](https://github.com/qmk/qmk_firmware/pull/21558), [#21580](https://github.com/qmk/qmk_firmware/pull/21580), [#21594](https://github.com/qmk/qmk_firmware/pull/21594), [#21624](https://github.com/qmk/qmk_firmware/pull/21624), [#21710](https://github.com/qmk/qmk_firmware/pull/21710)) :id=driver-naming-consolidation ### Driver naming consolidation ([#21551](https://github.com/qmk/qmk_firmware/pull/21551), [#21558](https://github.com/qmk/qmk_firmware/pull/21558), [#21580](https://github.com/qmk/qmk_firmware/pull/21580), [#21594](https://github.com/qmk/qmk_firmware/pull/21594), [#21624](https://github.com/qmk/qmk_firmware/pull/21624), [#21710](https://github.com/qmk/qmk_firmware/pull/21710)) {#driver-naming-consolidation}
In most circumstances this won't affect users -- only keyboard designers with currently-unmerged boards. The only users affected are people who have modified existing keyboards in order to add/modify haptics, lighting, or bluetooth -- and only if the base keyboard did not configure them already. Driver naming has been modified to be lowercase. In most circumstances this won't affect users -- only keyboard designers with currently-unmerged boards. The only users affected are people who have modified existing keyboards in order to add/modify haptics, lighting, or bluetooth -- and only if the base keyboard did not configure them already. Driver naming has been modified to be lowercase.
@ -116,7 +116,7 @@ Bluetooth (`BLUETOOTH_DRIVER` / `bluetooth.driver`):
| `BluefruitLE` | `bluefruit_le` | | `BluefruitLE` | `bluefruit_le` |
| `RN42` | `rn42` | | `RN42` | `rn42` |
## Full changelist :id=full-changelist ## Full changelist {#full-changelist}
Core: Core:
* On-each-release tap dance function ([#20255](https://github.com/qmk/qmk_firmware/pull/20255)) * On-each-release tap dance function ([#20255](https://github.com/qmk/qmk_firmware/pull/20255))

34
docs/ChangeLog/20231126.md
View File

@ -1,14 +1,14 @@
# QMK Breaking Changes - 2023 November 26 Changelog # QMK Breaking Changes - 2023 November 26 Changelog
## Notable Features :id=notable-features ## Notable Features {#notable-features}
As per last few breaking changes cycles, there have been _a lot_ of behind-the-scenes changes, mainly around consolidation of config into `info.json` files, cleanup of `info.json` files, cleaning up driver naming, as well as addressing technical debt. As per last few breaking changes cycles, there have been _a lot_ of behind-the-scenes changes, mainly around consolidation of config into `info.json` files, cleanup of `info.json` files, cleaning up driver naming, as well as addressing technical debt.
As a followup to last cycle's [notable changes](20230827.md#notable-changes), as `qmk/qmk_firmware` is no longer accepting PRs for keymaps we're pleased to announce that storing and building keymaps externally from the normal QMK Firmware repository is now possible. This is done through the new [External Userspace](newbs_external_userspace.md) feature, more details below! As a followup to last cycle's [notable changes](20230827#notable-changes), as `qmk/qmk_firmware` is no longer accepting PRs for keymaps we're pleased to announce that storing and building keymaps externally from the normal QMK Firmware repository is now possible. This is done through the new [External Userspace](../newbs_external_userspace) feature, more details below!
## Changes Requiring User Action :id=changes-requiring-user-action ## Changes Requiring User Action {#changes-requiring-user-action}
### Updated Keyboard Codebases :id=updated-keyboard-codebases ### Updated Keyboard Codebases {#updated-keyboard-codebases}
| Old Keyboard Name | New Keyboard Name | | Old Keyboard Name | New Keyboard Name |
|---------------------------------------|-------------------------------| |---------------------------------------|-------------------------------|
@ -29,29 +29,31 @@ As a followup to last cycle's [notable changes](20230827.md#notable-changes), as
| studiokestra/line_tkl | studiokestra/line_friends_tkl | | studiokestra/line_tkl | studiokestra/line_friends_tkl |
| ymdk/melody96 | ymdk/melody96/soldered | | ymdk/melody96 | ymdk/melody96/soldered |
## Notable core changes :id=notable-core ## Notable core changes {#notable-core}
### External Userspace ([#22222](https://github.com/qmk/qmk_firmware/pull/22222)) ### External Userspace ([#22222](https://github.com/qmk/qmk_firmware/pull/22222))
As mentioned above, the new External Userspace feature allows for keymaps to be stored and built externally from the main QMK Firmware repository. This allows for keymaps to be stored separately -- usually in their own repository -- and for users to be able to maintain and build their keymaps without needing to fork the main QMK Firmware repository. As mentioned above, the new External Userspace feature allows for keymaps to be stored and built externally from the main QMK Firmware repository. This allows for keymaps to be stored separately -- usually in their own repository -- and for users to be able to maintain and build their keymaps without needing to fork the main QMK Firmware repository.
See the [External Userspace documentation](newbs_external_userspace.md) for more details. See the [External Userspace documentation](../newbs_external_userspace) for more details.
A significant portion of user keymaps have already been removed from `qmk/qmk_firmware` and more will follow in coming weeks. You can still recover your keymap from the tag [user-keymaps-still-present](https://github.com/qmk/qmk_firmware/tree/user-keymaps-still-present) if required -- a perfect time to migrate to the new External Userspace! A significant portion of user keymaps have already been removed from `qmk/qmk_firmware` and more will follow in coming weeks. You can still recover your keymap from the tag [user-keymaps-still-present](https://github.com/qmk/qmk_firmware/tree/user-keymaps-still-present) if required -- a perfect time to migrate to the new External Userspace!
!> This feature is still in beta, and we're looking for feedback on it. Please try it out and let us know what you think -- a new `#help-userspace` channel has been set up on Discord. ::: warning
This feature is still in beta, and we're looking for feedback on it. Please try it out and let us know what you think -- a new `#help-userspace` channel has been set up on Discord.
:::
### Improve and Cleanup Shutdown callbacks ([#21060](https://github.com/qmk/qmk_firmware/pull/20160)) :id=improve-and-cleanup-shutdown-callbacks ### Improve and Cleanup Shutdown callbacks ([#21060](https://github.com/qmk/qmk_firmware/pull/20160)) {#improve-and-cleanup-shutdown-callbacks}
Shutdown callbacks at the keyboard level were never present, preventing safe shutdown sequencing for peripherals such as OLEDs, RGB LEDs, and other devices. This PR adds a new `shutdown_kb` function, as well as amending `shutdown_user`, allowing for safe shutdown of peripherals at both keyboard and keymap level. Shutdown callbacks at the keyboard level were never present, preventing safe shutdown sequencing for peripherals such as OLEDs, RGB LEDs, and other devices. This PR adds a new `shutdown_kb` function, as well as amending `shutdown_user`, allowing for safe shutdown of peripherals at both keyboard and keymap level.
See the [Keyboard Shutdown/Reboot Code](custom_quantum_functions.md#keyboard-shutdown-reboot-code) documentation for more details. See the [Keyboard Shutdown/Reboot Code](../custom_quantum_functions#keyboard-shutdown-reboot-code) documentation for more details.
### OLED Force Flush ([#20953](https://github.com/qmk/qmk_firmware/pull/20953)) :id=oled-force-flush ### OLED Force Flush ([#20953](https://github.com/qmk/qmk_firmware/pull/20953)) {#oled-force-flush}
Along with the new `shutdown_kb` function, a new API `oled_render_dirty(bool)` function has been added. This allows OLED contents to be written deterministically when supplied with `true` -- that is, the OLED will be updated immediately, rather than waiting for the next OLED update cycle. This allows for OLEDs to show things such as "BOOTLOADER MODE" and the like if resetting to bootloader from QMK. Along with the new `shutdown_kb` function, a new API `oled_render_dirty(bool)` function has been added. This allows OLED contents to be written deterministically when supplied with `true` -- that is, the OLED will be updated immediately, rather than waiting for the next OLED update cycle. This allows for OLEDs to show things such as "BOOTLOADER MODE" and the like if resetting to bootloader from QMK.
### Switch statement helpers for keycode ranges ([#20059](https://github.com/qmk/qmk_firmware/pull/20059)) :id=switch-statement-helpers-for-keycode-ranges ### Switch statement helpers for keycode ranges ([#20059](https://github.com/qmk/qmk_firmware/pull/20059)) {#switch-statement-helpers-for-keycode-ranges}
Predefined ranges usable within switch statements have been added for groups of similar keycodes, where people who wish to handle entire blocks at once can do so. This allows keymaps to be immune to changes in keycode values, and also allows for more efficient code generation. Predefined ranges usable within switch statements have been added for groups of similar keycodes, where people who wish to handle entire blocks at once can do so. This allows keymaps to be immune to changes in keycode values, and also allows for more efficient code generation.
@ -98,17 +100,17 @@ Becomes:
/* do stuff with basic and modifier keycodes */ /* do stuff with basic and modifier keycodes */
``` ```
### Quantum Painter OLED support ([#19997](https://github.com/qmk/qmk_firmware/pull/19997)) :id=quantum-painter-oled-support ### Quantum Painter OLED support ([#19997](https://github.com/qmk/qmk_firmware/pull/19997)) {#quantum-painter-oled-support}
Quantum Painter has picked up support for SH1106 displays -- commonly seen as 128x64 OLEDs. Support for both I2C and SPI displays is available. Quantum Painter has picked up support for SH1106 displays -- commonly seen as 128x64 OLEDs. Support for both I2C and SPI displays is available.
If you're already using OLED through `OLED_DRIVER_ENABLE = yes` or equivalent in `info.json` and wish to use Quantum Painter instead, you'll need to disable the old OLED system, instead enabling Quantum Painter as well as enabling the appropriate SH1106 driver. See the [Quantum Painter driver documentation](quantum_painter.md#quantum-painter-drivers) for more details. The old OLED driver is still available, and keymaps do not require migrating to Quantum Painter if you don't want to do so. If you're already using OLED through `OLED_DRIVER_ENABLE = yes` or equivalent in `info.json` and wish to use Quantum Painter instead, you'll need to disable the old OLED system, instead enabling Quantum Painter as well as enabling the appropriate SH1106 driver. See the [Quantum Painter driver documentation](../quantum_painter#quantum-painter-drivers) for more details. The old OLED driver is still available, and keymaps do not require migrating to Quantum Painter if you don't want to do so.
### RGB/LED lighting driver naming and cleanup ([#21890](https://github.com/qmk/qmk_firmware/pull/21890), [#21891](https://github.com/qmk/qmk_firmware/pull/21891), [#21892](https://github.com/qmk/qmk_firmware/pull/21892), [#21903](https://github.com/qmk/qmk_firmware/pull/21903), [#21904](https://github.com/qmk/qmk_firmware/pull/21904), [#21905](https://github.com/qmk/qmk_firmware/pull/21905), [#21918](https://github.com/qmk/qmk_firmware/pull/21918), [#21929](https://github.com/qmk/qmk_firmware/pull/21929), [#21938](https://github.com/qmk/qmk_firmware/pull/21938), [#22004](https://github.com/qmk/qmk_firmware/pull/22004), [#22008](https://github.com/qmk/qmk_firmware/pull/22008), [#22009](https://github.com/qmk/qmk_firmware/pull/22009), [#22071](https://github.com/qmk/qmk_firmware/pull/22071), [#22090](https://github.com/qmk/qmk_firmware/pull/22090), [#22099](https://github.com/qmk/qmk_firmware/pull/22099), [#22126](https://github.com/qmk/qmk_firmware/pull/22126), [#22133](https://github.com/qmk/qmk_firmware/pull/22133), [#22163](https://github.com/qmk/qmk_firmware/pull/22163), [#22200](https://github.com/qmk/qmk_firmware/pull/22200), [#22308](https://github.com/qmk/qmk_firmware/pull/22308), [#22309](https://github.com/qmk/qmk_firmware/pull/22309), [#22311](https://github.com/qmk/qmk_firmware/pull/22311), [#22325](https://github.com/qmk/qmk_firmware/pull/22325), [#22365](https://github.com/qmk/qmk_firmware/pull/22365), [#22379](https://github.com/qmk/qmk_firmware/pull/22379), [#22380](https://github.com/qmk/qmk_firmware/pull/22380), [#22381](https://github.com/qmk/qmk_firmware/pull/22381), [#22383](https://github.com/qmk/qmk_firmware/pull/22383), [#22436](https://github.com/qmk/qmk_firmware/pull/22436)) ### RGB/LED lighting driver naming and cleanup ([#21890](https://github.com/qmk/qmk_firmware/pull/21890), [#21891](https://github.com/qmk/qmk_firmware/pull/21891), [#21892](https://github.com/qmk/qmk_firmware/pull/21892), [#21903](https://github.com/qmk/qmk_firmware/pull/21903), [#21904](https://github.com/qmk/qmk_firmware/pull/21904), [#21905](https://github.com/qmk/qmk_firmware/pull/21905), [#21918](https://github.com/qmk/qmk_firmware/pull/21918), [#21929](https://github.com/qmk/qmk_firmware/pull/21929), [#21938](https://github.com/qmk/qmk_firmware/pull/21938), [#22004](https://github.com/qmk/qmk_firmware/pull/22004), [#22008](https://github.com/qmk/qmk_firmware/pull/22008), [#22009](https://github.com/qmk/qmk_firmware/pull/22009), [#22071](https://github.com/qmk/qmk_firmware/pull/22071), [#22090](https://github.com/qmk/qmk_firmware/pull/22090), [#22099](https://github.com/qmk/qmk_firmware/pull/22099), [#22126](https://github.com/qmk/qmk_firmware/pull/22126), [#22133](https://github.com/qmk/qmk_firmware/pull/22133), [#22163](https://github.com/qmk/qmk_firmware/pull/22163), [#22200](https://github.com/qmk/qmk_firmware/pull/22200), [#22308](https://github.com/qmk/qmk_firmware/pull/22308), [#22309](https://github.com/qmk/qmk_firmware/pull/22309), [#22311](https://github.com/qmk/qmk_firmware/pull/22311), [#22325](https://github.com/qmk/qmk_firmware/pull/22325), [#22365](https://github.com/qmk/qmk_firmware/pull/22365), [#22379](https://github.com/qmk/qmk_firmware/pull/22379), [#22380](https://github.com/qmk/qmk_firmware/pull/22380), [#22381](https://github.com/qmk/qmk_firmware/pull/22381), [#22383](https://github.com/qmk/qmk_firmware/pull/22383), [#22436](https://github.com/qmk/qmk_firmware/pull/22436))
As you can probably tell by the list of PRs just above, there has been a lot of cleanup and consolidation this cycle when it comes to RGB/LED lighting drivers. The number of changes is too large to list here, but the general theme has been focusing on consistency of naming, both of drivers themselves and their respective implementation and configuration. Most changes only affect keyboard designers -- if you find that your in-development keyboard is no longer building due to naming of defines changing, your best bet is to refer to another board already in the repository which has had the changes applied. As you can probably tell by the list of PRs just above, there has been a lot of cleanup and consolidation this cycle when it comes to RGB/LED lighting drivers. The number of changes is too large to list here, but the general theme has been focusing on consistency of naming, both of drivers themselves and their respective implementation and configuration. Most changes only affect keyboard designers -- if you find that your in-development keyboard is no longer building due to naming of defines changing, your best bet is to refer to another board already in the repository which has had the changes applied.
### Peripheral subsystem enabling ([#22253](https://github.com/qmk/qmk_firmware/pull/22253), [#22448](https://github.com/qmk/qmk_firmware/pull/22448), [#22106](https://github.com/qmk/qmk_firmware/pull/22106)) :id=peripheral-subsystem-enabling ### Peripheral subsystem enabling ([#22253](https://github.com/qmk/qmk_firmware/pull/22253), [#22448](https://github.com/qmk/qmk_firmware/pull/22448), [#22106](https://github.com/qmk/qmk_firmware/pull/22106)) {#peripheral-subsystem-enabling}
When enabling peripherals such as I2C, SPI, or Analog/ADC, some required manual inclusion of source files in order to provide driver support, and in some cases, when multiple drivers were using the same underlying peripheral, files were being added to the build multiple times. When enabling peripherals such as I2C, SPI, or Analog/ADC, some required manual inclusion of source files in order to provide driver support, and in some cases, when multiple drivers were using the same underlying peripheral, files were being added to the build multiple times.
@ -125,11 +127,11 @@ For a concrete example, users or keyboard designers who previously added `SRC +=
| `UART_DRIVER_REQUIRED = yes` | `SRC += uart.c` | | `UART_DRIVER_REQUIRED = yes` | `SRC += uart.c` |
| `WS2812_DRIVER_REQUIRED = yes` | `SRC += ws2812.c` | | `WS2812_DRIVER_REQUIRED = yes` | `SRC += ws2812.c` |
### NKRO on V-USB boards ([#22398](https://github.com/qmk/qmk_firmware/pull/22398)) :id=vusb-nkro ### NKRO on V-USB boards ([#22398](https://github.com/qmk/qmk_firmware/pull/22398)) {#vusb-nkro}
NKRO is now available for ATmega32A and 328P-based keyboards (including PS2AVRGB/Bootmapper boards), thanks to some internal refactoring and cleanup. To enable it, the process is the same as always - add `NKRO_ENABLE = yes` to your `rules.mk`, then assign and press the `NK_TOGG` keycode to switch modes. NKRO is now available for ATmega32A and 328P-based keyboards (including PS2AVRGB/Bootmapper boards), thanks to some internal refactoring and cleanup. To enable it, the process is the same as always - add `NKRO_ENABLE = yes` to your `rules.mk`, then assign and press the `NK_TOGG` keycode to switch modes.
## Full changelist :id=full-changelist ## Full changelist {#full-changelist}
Core: Core:
* Compilation warning if both `keymap.json` and `keymap.c` exist ([#19939](https://github.com/qmk/qmk_firmware/pull/19939)) * Compilation warning if both `keymap.json` and `keymap.c` exist ([#19939](https://github.com/qmk/qmk_firmware/pull/19939))

26
docs/ChangeLog/20240225.md
View File

@ -1,6 +1,6 @@
# QMK Breaking Changes - 2024 February 25 Changelog # QMK Breaking Changes - 2024 February 25 Changelog
## Notable Features :id=notable-features ## Notable Features {#notable-features}
_0.24.0_ is mainly a maintenance release of QMK Firmware -- as per last few breaking changes cycles, there have been a lot of behind-the-scenes changes, mainly: _0.24.0_ is mainly a maintenance release of QMK Firmware -- as per last few breaking changes cycles, there have been a lot of behind-the-scenes changes, mainly:
@ -10,17 +10,17 @@ _0.24.0_ is mainly a maintenance release of QMK Firmware -- as per last few brea
* keyboard relocations * keyboard relocations
* addressing technical debt * addressing technical debt
## Changes Requiring User Action :id=changes-requiring-user-action ## Changes Requiring User Action {#changes-requiring-user-action}
### Windows Driver Changes ([QMK Toolbox 0.3.0 Release](https://github.com/qmk/qmk_toolbox/releases/tag/0.3.0)) ### Windows Driver Changes ([QMK Toolbox 0.3.0 Release](https://github.com/qmk/qmk_toolbox/releases/tag/0.3.0))
Flashing keyboards that target `atmel-dfu` or `qmk-dfu` on Windows using `qmk flash` or QMK Toolbox have traditionally used _libusb_ for access to the DFU USB device. Since QMK Toolbox 0.3.0, this has changed to WinUSB. Flashing keyboards that target `atmel-dfu` or `qmk-dfu` on Windows using `qmk flash` or QMK Toolbox have traditionally used _libusb_ for access to the DFU USB device. Since QMK Toolbox 0.3.0, this has changed to WinUSB.
If you update QMK Toolbox or update QMK MSYS, you may find that flashing Atmel DFU keyboards no longer functions as intended. If you strike such issues when flashing new firmware, you will need to replace the _libusb_ driver with _WinUSB_ using Zadig. You can follow the [Recovering from Installation to Wrong Device](driver_installation_zadig.md#recovering-from-installation-to-wrong-device) instructions to replace the driver associated with the Atmel DFU bootloader, skipping the section about removal as Zadig will safely replace the driver instead. Please ensure your keyboard is in bootloader mode and has _libusb_ as the existing driver before attempting to use Zadig to replace the driver. If instead you see _HidUsb_ you're not in bootloader mode and should not continue with driver replacement. If you update QMK Toolbox or update QMK MSYS, you may find that flashing Atmel DFU keyboards no longer functions as intended. If you strike such issues when flashing new firmware, you will need to replace the _libusb_ driver with _WinUSB_ using Zadig. You can follow the [Recovering from Installation to Wrong Device](../driver_installation_zadig#recovering-from-installation-to-wrong-device) instructions to replace the driver associated with the Atmel DFU bootloader, skipping the section about removal as Zadig will safely replace the driver instead. Please ensure your keyboard is in bootloader mode and has _libusb_ as the existing driver before attempting to use Zadig to replace the driver. If instead you see _HidUsb_ you're not in bootloader mode and should not continue with driver replacement.
### Updated Keyboard Codebases :id=updated-keyboard-codebases ### Updated Keyboard Codebases {#updated-keyboard-codebases}
One note with updated keyboard names -- historical keyboard names are still considered valid when using [External Userspace](newbs_external_userspace.md) for builds. If you're already using External Userspace, you do not need to move your keymap inside your repository. One note with updated keyboard names -- historical keyboard names are still considered valid when using [External Userspace](../newbs_external_userspace) for builds. If you're already using External Userspace, you do not need to move your keymap inside your repository.
| Old Keyboard Name | New Keyboard Name | | Old Keyboard Name | New Keyboard Name |
|-------------------------|---------------------------------| |-------------------------|---------------------------------|
@ -77,9 +77,9 @@ One note with updated keyboard names -- historical keyboard names are still cons
| z12 | zigotica/z12 | | z12 | zigotica/z12 |
| z34 | zigotica/z34 | | z34 | zigotica/z34 |
## Notable core changes :id=notable-core ## Notable core changes {#notable-core}
### Renaming Arduino-style GPIO pin functions ([#23085](https://github.com/qmk/qmk_firmware/pull/23085), [#23093](https://github.com/qmk/qmk_firmware/pull/23093)) :id=gpio-rename ### Renaming Arduino-style GPIO pin functions ([#23085](https://github.com/qmk/qmk_firmware/pull/23085), [#23093](https://github.com/qmk/qmk_firmware/pull/23093)) {#gpio-rename}
QMK has long used Arduino-style GPIO naming conventions. This has been confusing for users, as over time they've had new variations added, as well as users mistakenly thinking that QMK supports the rest of the Arduino ecosystem. QMK has long used Arduino-style GPIO naming conventions. This has been confusing for users, as over time they've had new variations added, as well as users mistakenly thinking that QMK supports the rest of the Arduino ecosystem.
@ -110,17 +110,17 @@ Much like the GPIO refactoring, I2C APIs were also updated to conform to QMK nam
| `i2c_writeReg()` | `i2c_write_register()` | | `i2c_writeReg()` | `i2c_write_register()` |
| `i2c_writeReg16()` | `i2c_write_register16()` | | `i2c_writeReg16()` | `i2c_write_register16()` |
### Renaming _Bootmagic Lite_ => _Bootmagic_ ([#22970](https://github.com/qmk/qmk_firmware/pull/22970), [#22979](https://github.com/qmk/qmk_firmware/pull/22979)) :id=bootmagic-rename ### Renaming _Bootmagic Lite_ => _Bootmagic_ ([#22970](https://github.com/qmk/qmk_firmware/pull/22970), [#22979](https://github.com/qmk/qmk_firmware/pull/22979)) {#bootmagic-rename}
Bootmagic "Lite" had no real meaning once the historical Bootmagic "Full" was deprecated and removed. Any references to _Bootmagic Lite_ should now just refer to _Bootmagic_. We hope we got the majority of the code and the documentation, so if you find any more, let us know! Bootmagic "Lite" had no real meaning once the historical Bootmagic "Full" was deprecated and removed. Any references to _Bootmagic Lite_ should now just refer to _Bootmagic_. We hope we got the majority of the code and the documentation, so if you find any more, let us know!
### Threshold for automatic mouse layer activation ([#21398](https://github.com/qmk/qmk_firmware/pull/21398)) :id=auto-mouse-layer ### Threshold for automatic mouse layer activation ([#21398](https://github.com/qmk/qmk_firmware/pull/21398)) {#auto-mouse-layer}
In some cases, accidental automatic activation of the mouse layer made it difficult to continue typing, such as when brushing across a trackball. `AUTO_MOUSE_THRESHOLD` is now a configurable option in `config.h` which allows for specifying what the movement threshold is before automatically activating the mouse layer. In some cases, accidental automatic activation of the mouse layer made it difficult to continue typing, such as when brushing across a trackball. `AUTO_MOUSE_THRESHOLD` is now a configurable option in `config.h` which allows for specifying what the movement threshold is before automatically activating the mouse layer.
### DIP Switch Mapping ([#22543](https://github.com/qmk/qmk_firmware/pull/22543)) :id=dip-switch-map ### DIP Switch Mapping ([#22543](https://github.com/qmk/qmk_firmware/pull/22543)) {#dip-switch-map}
Much like Encoder Mapping, DIP Switch Mapping allows for specifying a table of actions to execute when a DIP switch state changes. See the [DIP Switch Documentation](feature_dip_switch.md#dip-switch-map) for more information. Much like Encoder Mapping, DIP Switch Mapping allows for specifying a table of actions to execute when a DIP switch state changes. See the [DIP Switch Documentation](../feature_dip_switch#dip-switch-map) for more information.
```c ```c
#if defined(DIP_SWITCH_MAP_ENABLE) #if defined(DIP_SWITCH_MAP_ENABLE)
@ -131,7 +131,7 @@ const uint16_t PROGMEM dip_switch_map[NUM_DIP_SWITCHES][NUM_DIP_STATES] = {
#endif #endif
``` ```
### Quantum Painter updates ([#18521](https://github.com/qmk/qmk_firmware/pull/18521), [#20645](https://github.com/qmk/qmk_firmware/pull/20645), [#22358](https://github.com/qmk/qmk_firmware/pull/22358)) :id=qp-updates ### Quantum Painter updates ([#18521](https://github.com/qmk/qmk_firmware/pull/18521), [#20645](https://github.com/qmk/qmk_firmware/pull/20645), [#22358](https://github.com/qmk/qmk_firmware/pull/22358)) {#qp-updates}
Quantum Painter picked up support for the following: Quantum Painter picked up support for the following:
@ -141,7 +141,7 @@ Quantum Painter picked up support for the following:
Quantum Painter now supports the majority of common OLED panels supported by the basic OLED driver, so if you're using an ARM-based board you may find Quantum Painter a much more feature-rich API in comparison. Quantum Painter now supports the majority of common OLED panels supported by the basic OLED driver, so if you're using an ARM-based board you may find Quantum Painter a much more feature-rich API in comparison.
## Full changelist :id=full-changelist ## Full changelist {#full-changelist}
Core: Core:
* [Driver] ILI9486 on Quantum Painter ([#18521](https://github.com/qmk/qmk_firmware/pull/18521)) * [Driver] ILI9486 on Quantum Painter ([#18521](https://github.com/qmk/qmk_firmware/pull/18521))

28
docs/ChangeLog/20240526.md
View File

@ -1,14 +1,14 @@
# QMK Breaking Changes - 2024 May 26 Changelog # QMK Breaking Changes - 2024 May 26 Changelog
## Notable Features :id=notable-features ## Notable Features {#notable-features}
May 2024 brings about another heavy maintenance release of QMK. Of the 209 PRs created this breaking changes cycle against the `develop` branch, 174 behind-the-scenes PRs (83%!) were aimed at converting, consolidating, and cleaning up keyboards and their configuration data. Not the most glamorous work, but it means QMK is in a much more manageable spot than what it was 3 months prior. The work steadily continues! May 2024 brings about another heavy maintenance release of QMK. Of the 209 PRs created this breaking changes cycle against the `develop` branch, 174 behind-the-scenes PRs (83%!) were aimed at converting, consolidating, and cleaning up keyboards and their configuration data. Not the most glamorous work, but it means QMK is in a much more manageable spot than what it was 3 months prior. The work steadily continues!
## Changes Requiring User Action :id=changes-requiring-user-action ## Changes Requiring User Action {#changes-requiring-user-action}
### Updated Keyboard Codebases :id=updated-keyboard-codebases ### Updated Keyboard Codebases {#updated-keyboard-codebases}
One note with updated keyboard names -- historical keyboard names are still considered valid when using [External Userspace](newbs_external_userspace.md) for builds. If you're already using External Userspace, you do not need to move your keymap inside your repository. One note with updated keyboard names -- historical keyboard names are still considered valid when using [External Userspace](../newbs_external_userspace) for builds. If you're already using External Userspace, you do not need to move your keymap inside your repository.
| Old Keyboard Name | New Keyboard Name | | Old Keyboard Name | New Keyboard Name |
|------------------------------|-----------------------------------| |------------------------------|-----------------------------------|
@ -40,7 +40,7 @@ A bunch of legacy keycodes have been removed -- check [the affected keycodes](ht
The latest of these were officially deprecated within QMK in the August 2023 breaking changes -- the new keycodes are the way forward. The latest of these were officially deprecated within QMK in the August 2023 breaking changes -- the new keycodes are the way forward.
### P3D Spacey Layout Updates ([#23329](https://github.com/qmk/qmk_firmware/pull/23329)) :id=spacey-layout-updates ### P3D Spacey Layout Updates ([#23329](https://github.com/qmk/qmk_firmware/pull/23329)) {#spacey-layout-updates}
This PR removed the `LAYOUT` macro that was configured for the Spacey. This PR removed the `LAYOUT` macro that was configured for the Spacey.
If you have a keymap for this keyboard, you will need to update your If you have a keymap for this keyboard, you will need to update your
@ -54,7 +54,7 @@ keymap using the following steps:
4. Move the keycode for the Right Arrow to the end of the Shift row, 4. Move the keycode for the Right Arrow to the end of the Shift row,
after the Down Arrow key. after the Down Arrow key.
### MechKeys ACR60 Layout Updates ([#23309](https://github.com/qmk/qmk_firmware/pull/23309)) :id=acr60-layout-updates ### MechKeys ACR60 Layout Updates ([#23309](https://github.com/qmk/qmk_firmware/pull/23309)) {#acr60-layout-updates}
This PR removed and changed some of the layouts that were configured for the ACR60. If you use one of the following layouts, you will need to update your keymap: This PR removed and changed some of the layouts that were configured for the ACR60. If you use one of the following layouts, you will need to update your keymap:
@ -63,17 +63,17 @@ This PR removed and changed some of the layouts that were configured for the ACR
- [`LAYOUT_directional`](#layout-directional) - [`LAYOUT_directional`](#layout-directional)
- [`LAYOUT_mitchsplit`](#layout-mitchsplit) - [`LAYOUT_mitchsplit`](#layout-mitchsplit)
#### `LAYOUT_hhkb` :id=acr60-layout-hhkb #### `LAYOUT_hhkb` {#acr60-layout-hhkb}
1. Change your layout macro to `LAYOUT_60_hhkb`. 1. Change your layout macro to `LAYOUT_60_hhkb`.
1. Remove any keycodes for the key between Left Shift and QWERTY Z. 1. Remove any keycodes for the key between Left Shift and QWERTY Z.
#### `LAYOUT_true_hhkb` :id=acr60-layout-true-hhkb #### `LAYOUT_true_hhkb` {#acr60-layout-true-hhkb}
1. Change your layout macro to `LAYOUT_60_true_hhkb`. 1. Change your layout macro to `LAYOUT_60_true_hhkb`.
1. Remove any keycodes for the key between Left Shift and QWERTY Z. 1. Remove any keycodes for the key between Left Shift and QWERTY Z.
#### `LAYOUT_directional` :id=acr60-layout-directional #### `LAYOUT_directional` {#acr60-layout-directional}
1. Change your layout macro to `LAYOUT_60_ansi_arrow_split_bs`. 1. Change your layout macro to `LAYOUT_60_ansi_arrow_split_bs`.
1. Remove any keycodes for the key between Left Shift and QWERTY Z. 1. Remove any keycodes for the key between Left Shift and QWERTY Z.
@ -81,16 +81,16 @@ This PR removed and changed some of the layouts that were configured for the ACR
If you need split spacebars, you may implement `LAYOUT_60_ansi_arrow_split_space_split_bs` and change your layout to it, removing the keycode between Left Shift and QWERTY Z. If you need split spacebars, you may implement `LAYOUT_60_ansi_arrow_split_space_split_bs` and change your layout to it, removing the keycode between Left Shift and QWERTY Z.
#### `LAYOUT_mitchsplit` :id=acr60-layout-mitchsplit #### `LAYOUT_mitchsplit` {#acr60-layout-mitchsplit}
1. Use `LAYOUT_60_ansi_split_space_split_rshift`. 1. Use `LAYOUT_60_ansi_split_space_split_rshift`.
## Notable core changes :id=notable-core ## Notable core changes {#notable-core}
### Introduction of `keyboard.json` ([22891](https://github.com/qmk/qmk_firmware/pull/22891)) :id=keyboard-json ### Introduction of `keyboard.json` ([22891](https://github.com/qmk/qmk_firmware/pull/22891)) {#keyboard-json}
One longer term goal of QMK is increased maintainability. One longer term goal of QMK is increased maintainability.
As part of the continued push towards [Data Driven Configuration](data_driven_config.md), the build system has been updated to simplify the existing codebase, and power future workflows. As part of the continued push towards [Data Driven Configuration](../data_driven_config), the build system has been updated to simplify the existing codebase, and power future workflows.
The `keyboard.json` configuration file allows the support of a single data file for keyboard level config. The `keyboard.json` configuration file allows the support of a single data file for keyboard level config.
@ -109,7 +109,7 @@ Essentially, changes were made in the internals of how QMK interacts with USB fo
Compliance checks were run against QMK firmwares for the most popular ARM microcontrollers, as well as suspend/resume tests. As far as we can tell, a whole host of hard-to-reproduce issues are mitigated by this change. Compliance checks were run against QMK firmwares for the most popular ARM microcontrollers, as well as suspend/resume tests. As far as we can tell, a whole host of hard-to-reproduce issues are mitigated by this change.
## Full changelist :id=full-changelist ## Full changelist {#full-changelist}
Core: Core:
* Refactor vusb to protocol use pre/post task ([#14944](https://github.com/qmk/qmk_firmware/pull/14944)) * Refactor vusb to protocol use pre/post task ([#14944](https://github.com/qmk/qmk_firmware/pull/14944))

Some files were not shown because too many files have changed in this diff Show More