<spanclass="line"><spanstyle="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">2003</span></span></code></pre></div><p>From the whole QMK team, a major thankyou to the community for embracing QMK as your preferred keyboard firmware!</p><h2id="notable-features"tabindex="-1">Notable Features <aclass="header-anchor"href="#notable-features"aria-label="Permalink to "Notable Features {#notable-features}""></a></h2><h3id="expanded-pointing-device"tabindex="-1">Expanded Pointing Device support (<ahref="https://github.com/qmk/qmk_firmware/pull/14343"target="_blank"rel="noreferrer">#14343</a>) <aclass="header-anchor"href="#expanded-pointing-device"aria-label="Permalink to "Expanded Pointing Device support ([#14343](https://github.com/qmk/qmk_firmware/pull/14343)) {#expanded-pointing-device}""></a></h3><p>Pointing device support has been reworked and reimplemented to allow for easier integration of new peripherals.</p><p>Usages of <code>POINTING_DEVICE_ENABLE = yes</code> in <code>rules.mk</code> files now need to be accompanied by a corresponding <code>POINTING_DEVICE_DRIVER = ???</code> line, specifying which driver to use during the build. Existing keyboards have already been migrated across to the new usage pattern, so most likely no change is required by users.</p><p>QMK now has core-supplied support for the following pointing device peripherals:</p><table><thead><tr><th><code>rules.mk</code> line</th><th>Supported device</th></tr></thead><tbody><tr><td><code>POINTING_DEVICE_DRIVER = analog_joystick</code></td><td>Analog joysticks, such as PSP joysticks</td></tr><tr><td><code>POINTING_DEVICE_DRIVER = adns5050</code></td><td>ADNS 5050 sensor</td></tr><tr><td><code>POINTING_DEVICE_DRIVER = adns9800</code></td><td>ADNS 9800 laser sensor</td></tr><tr><td><code>POINTING_DEVICE_DRIVER = cirque_pinnacle_i2c</code></td><td>Cirque touchpad, I2C mode</td></tr><tr><td><code>POINTING_DEVICE_DRIVER = cirque_pinnacle_spi</code></td><td>Cirque Touchpad, SPI mode</td></tr><tr><td><code>POINTING_DEVICE_DRIVER = pimoroni_trackball</code></td><td>Pimoroni Trackball</td></tr><tr><td><code>POINTING_DEVICE_DRIVER = pmw3360</code></td><td>PMW 3360</td></tr></tbody></table><p>See the new documentation for the <ahref="./../features/pointing_device">Pointing Device</a> feature for more information on specific configuration for each driver.</p><h3id="dynamic-tapping-term"tabindex="-1">Dynamic Tapping Term (<ahref="https://github.com/qmk/qmk_firmware/pull/11036"target="_blank"rel="noreferrer">#11036</a>) <aclass="header-anchor"href="#dynamic-tapping-term"aria-label="Permalink to "Dynamic Tapping Term ([#11036](https://github.com/qmk/qmk_firmware/pull/11036)) {#dynamic-tapping-term}""></a></h3><p>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.</p><p>If you're in this stage of discovery, you can now add <code>DYNAMIC_TAPPING_TERM_ENABLE = yes</code> to your <code>rules.mk</code>, which enables the use of the following keycodes in your keymap:</p><table><thead><tr><th>Key</th><th>Description</th></tr></thead><tbody><tr><td><code>DT_PRNT</code></td><td>"Dynamic Tapping Term Print": Types the current tapping term, in milliseconds</td></tr><tr><td><code>DT_UP</code></td><td>"Dynamic Tapping Term Up": Increases the current tapping term by 5ms</td></tr><tr><td><code>DT_DOWN</code></td><td>"Dynamic Tapping Term Down": Decreases the current tapping term by 5ms</td></tr></tbody></table><p>Coupled with the use of <code>qmk console</code> 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 <code>config.h</code> and you're good to go!</p><h3id="macros-in-keymap-json"tabindex="-1">Macros in JSON keymaps (
<spanclass="line"><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> [ </span><spanstyle="--shiki-light:#6A737D;--shiki-dark:#6A737D;">// first listed is QK_MACRO_0...</span></span>
<spanclass="line"><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">}</span></span></code></pre></div><p>In due course, <ahref="https://config.qmk.fm/"target="_blank"rel="noreferrer">QMK Configurator</a> will pick up support for defining these in its UI, but for now the json is the only way to define macros.</p><h2id="changes-requiring-user-action"tabindex="-1">Changes Requiring User Action <aclass="header-anchor"href="#changes-requiring-user-action"aria-label="Permalink to "Changes Requiring User Action {#changes-requiring-user-action}""></a></h2><h3id="updated-keyboard-codebases"tabindex="-1">Updated Keyboard Codebases <aclass="header-anchor"href="#updated-keyboard-codebases"aria-label="Permalink to "Updated Keyboard Codebases {#updated-keyboard-codebases}""></a></h3><p>The following keyboards have had their source moved within QMK:</p><table><thead><tr><th>Old Keyboard Name</th><th>New Keyboard Name</th></tr></thead><tbody><tr><td>aozora/hotswap</td><td>aozora</td></tr><tr><td>gskt00</td><td>kapcave/gskt00</td></tr><tr><td>handwired/dtisaac01</td><td>dtisaac/dtisaac01</td></tr><tr><td>kprepublic/bm60poker</td><td>kprepublic/bm60hsrgb_poker/rev1</td></tr><tr><td>kprepublic/bm60rgb</td><td>kprepublic/bm60hsrgb/rev1</td></tr><tr><td>kprepublic/bm60rgb_iso</td><td>kprepublic/bm60hsrgb_iso/rev1</td></tr><tr><td>kprepublic/bm65iso</td><td>kprepublic/bm65hsrgb_iso</td></tr><tr><td>kprepublic/bm68rgb</td><td>kprepublic/bm68hsrgb</td></tr><tr><td>paladin64</td><td>kapcave/paladin64</td></tr><tr><td>portal_66</td><td>portal_66/soldered</td></tr><tr><td>signum/3_0/elitec</td><td>signum/3_0</td></tr><tr><td>tgr/jane</td><td>tgr/jane/v2</td></tr></tbody></table><h3id="squeezing-space-from-avr"tabindex="-1">Squeezing space out of AVR (<ahref="https://github.com/qmk/qmk_firmware/pull/15243"target="_blank"rel="noreferrer">#15243</a>) <aclass="header-anchor"href="#squeezing-space-from-avr"aria-label="Permalink to "Squeezing space out of AVR ([#15243](https://github.com/qmk/qmk_firmware/pull/15243)) {#squeezing-space-from-avr}""></a></h3><p>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.</p><p>Of course, there are much fewer constraints with ARM chips... 😉</p><h3id="explicit-rgb-modes"tabindex="-1">Require explicit enabling of RGB Matrix modes (<ahref="https://github.com/qmk/qmk_firmware/pull/15018"target="_blank"rel="noreferrer">#15018</a>) <aclass="header-anchor"href="#explicit-rgb-modes"aria-label="Permalink to "Require explicit enabling of RGB Matrix modes ([#15018](https://github.com/qmk/qmk_firmware/pull/15018)) {#explicit-rgb-modes}""></a></h3><p>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.</p><p>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.</p><p>The full list of configurables to turn specific animations back on can be found at on the <ahref="./../features/rgb_matrix#rgb-matrix-effects">RGB Matrix documentation</a> page.</p><h3id="oled-task-refactor"tabindex="-1">OLED task refactoring (<ahref="https://github.com/qmk/qmk_firmware/pull/14864"target="_blank"rel="noreferrer">#14864</a>) <aclass="header-anchor"
<spanclass="line"><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">}</span></span></code></pre></div><p>Keyboard designers should now structure their keyboard-level drawing routines like the following, in order to allow for keymap overrides:</p><divclass="language-c vp-adaptive-theme"><buttontitle="Copy Code"class="copy"></button><spanclass="lang">c</span><preclass="shiki shiki-themes github-light github-dark vp-code"><code><spanclass="line"><spanstyle="--shiki-light:#D73A49;--shiki-dark:#F97583;">bool</span><spanstyle="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> oled_task_kb</span><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><spanstyle="--shiki-light:#D73A49;--shiki-dark:#F97583;">void</span><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">) {</span></span>
<spanclass="line"><spanstyle="--shiki-light:#6A737D;--shiki-dark:#6A737D;"> // Defer to the keymap if they want to override</span></span>
<spanclass="line"><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">}</span></span></code></pre></div><h3id="bootmagic-full-removal"tabindex="-1">Bootmagic Full Removal (<ahref="https://github.com/qmk/qmk_firmware/pull/15002"target="_blank"rel="noreferrer">#15002</a>) <aclass="header-anchor"href="#bootmagic-full-removal"aria-label="Permalink to "Bootmagic Full Removal ([#15002](https://github.com/qmk/qmk_firmware/pull/15002)) {#bootmagic-full-removal}""></a></h3><p>As noted during previous breaking changes cycles, QMK decided to deprecate the full Bootmagic feature and leave Bootmagic Lite as the only remaining option.</p><p>This removal is now complete!</p><p>This pull request changes the behavior of <code>BOOTMAGIC_ENABLE</code> such that specifying <code>lite</code> or <code>full</code> results in an error, allowing only <code>yes</code> or <code>no</code>, with <code>yes</code> mirroring historical <code>lite</code> functionality.</p><p>All use of the <code>lite</code> keyword within the repository has been migrated to <code>yes</code> -- any new submissions using <code>lite</code> will now fail to build and should be updated accordingly.</p><h4id="bootmagic-full-deprecation-schedule-complete"tabindex="-1">Bootmagic Full Deprecation Schedule: Complete! <aclass="header-anchor"href="#bootmagic-full-deprecation-schedule-complete"aria-label="Permalink to "Bootmagic Full Deprecation Schedule: Complete!""></a></h4><p>This is the historical timeline for the behavior of <code>BOOTMAGIC_ENABLE</code>:</p><ul><li>(done) From 2021 May 29, setting <code>BOOTMAGIC_ENABLE = yes</code> will enable Bootmagic Lite instead of full Bootmagic.</li><li>(done) From 2021 Aug 28, <code>BOOTMAGIC_ENABLE</code> must be either <code>yes</code>, <code>lite</code>, or <code>no</code>– setting <code>BOOTMAGIC_ENABLE = full</code> will cause compilation to fail.</li><li>(now) From 2021 Nov 27, <code>BOOTMAGIC_ENABLE</code> must be either <code>yes</code> or <code>no</code>– setting <code>BOOTMAGIC_ENABLE = lite</code> will cause compilation to fail.</li></ul><h3id="remove-qwiic"tabindex="-1">Remove QWIIC_DRIVERS (<ahref="https://github.com/qmk/qmk_firmware/pull/14174"target="_blank"rel="noreferrer">#14174</a>) <aclass="header-anchor"href="#remove-qwiic"aria-label="Permalink to "Remove QWIIC_DRIVERS ([#14174](https://github.com/qmk/qmk_firmware/pull/14174)) {#remove-qwiic}""></a></h3><p>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.</p><h2id="notable-core"tabindex="-1">Notable core changes <aclass="header-anchor"href="#notable-core"aria-label="Permalink to "Notable core changes {#notable-core}""></a></h2><h3id="new-mcu-support"tabindex="-1">New MCU Support <aclass="header-anchor"href="#new-mcu-support"aria-label="Permalink to "New MCU Support {#new-mcu-support}""></a></h3><p>QMK firmware picked up support for a handful of new MCU families, potentially making it a bit easier to source components.</p><p>QMK firmware is now no longer limited to AVR and ARM - it also picked up support for our first RISC-V chip, the GD32VF103.</p><ul><li>Add support for RISC-V builds and GD32VF103 MCU (<ahref="https://github.com/qmk/qmk_firmware/pull/12508"target="_blank"rel="noreferrer">#12508</a>)</li><li>Add HT32 support to core (<ahref="https://github.com/qmk/qmk_firmware/pull/14388"target="_blank"rel="noreferrer">#14388</a>)</li><li>Westberrytech pr (<ahref="https://github.com/qmk/qmk_firmware/pull/14422"target="_blank"rel="noreferrer">#14422</a>)</li><li>Initial pass of F405 support (<ahref="https://github.com/qmk/qmk_firmware/pull/14584"target="_blank"rel="noreferrer">#14584</a>)</li></ul><h3id="eeprom-changes"tabindex="-1">EEPROM Changes <aclass="header-anchor"href="#eeprom-changes"aria-label="Permalink to "EEPROM Changes {#eeprom-changes}""></a></h3><p>There were a few
