* Refactor some led_set_kb instances
* Apply suggestions from code review
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Fix up bastardkb boards since blackpill support is officially added.
* Check for blackpill version, not elite c.
* Add checks in chibiOS config since multiple ARM controllers supported.
* Rework rules.mk for keymaps to better handle arm vs avr support
* Start moving away from `matrix_*_*` functions.
* `housekeeping_task_*` instead of `matrix_scan_*`
* `keyboard_(pre|post)_init_*` instead of `matrix_init_*`
* Add ℂℴmⅈℂ unicode input method.
* Clean up unicode code to be more compact and flexible.
* Remove/move Pro Micro LED commands to userspace and better filter them
* Fixup OLED code
* Use newer quantum keycode functions/preprocessors rather than manual bit manipulation
* Make unicode mode render much more compact/simple.
* Make qmk secrets more self contained
* Remove custom implementation of split watchdog
* [Docs] Update reference_info_json.md
- Makes it easier to find keyboard.jsonschema.
- Adds a reference to the Data Driven page.
* Update docs/reference_info_json.md
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Rename `eeprom_stm32` to `eeprom_legacy_emulated_flash`.
* Rename `flash_stm32` to `legacy_flash_ops`.
* Rename `eeprom_teensy` to `eeprom_kinetis_flexram`.
* add split space and ISO
* Update wkl.h
* update ISO
* update
* change KC_LGUI to KC_RGUI
* delete RGUI
* format
* update promise87 readme.md
* update promise87 wkl readme.md
* Update readme.md
* Update readme.md
* change KC_SLCK to KC_SCRL
* wuque/promise87/ansi: standardize Layout Macro names
- rename `LAYOUT_tkl_f13_ansi` to `LAYOUT_tkl_f13_ansi_tsangan`
- convert `LAYOUT_tkl_f13_ansi_iso` to `LAYOUT_tkl_f13_iso_tsangan` (adds position `K41`)
- rename `LAYOUT_tkl_f13_ansi_split_space` to `LAYOUT_tkl_f13_ansi_tsangan_split_space`
- rename `LAYOUT_tkl_f13_ansi_split_bs` to `LAYOUT_tkl_f13_ansi_tsangan_split_bs`
- rename `LAYOUT_tkl_f13_ansi_split_lshift` to `LAYOUT_tkl_f13_ansi_tsangan_split_lshift`
- rename `LAYOUT_tkl_f13_ansi_split_rshift` to `LAYOUT_tkl_f13_ansi_tsangan_split_rshift`
- rename `LAYOUT_tkl_f13_ansi_split_bs_rshift` to `LAYOUT_tkl_f13_ansi_tsangan_split_bs_rshift`
* wuque/promise87/wkl: refactor LAYOUT_tkl_f13_ansi_wkl_iso
Refactors `LAYOUT_tkl_f13_ansi_wkl_iso` into `LAYOUT_tkl_f13_iso_wkl` by adding position `K41` (Non-US Backslash) to the layout macro.
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
ANAVI Knob 1 is a mini mechanical keyboard with a clickable rotary
encoder, USB-C, RP2040 microcontroller and I2C slot for a display.
Signed-off-by: Leon Anavi <leon.anavi@konsulko.com>
Signed-off-by: Leon Anavi <leon.anavi@konsulko.com>
* bastardkb: cleanup blackpill configuration
Fixes#17
* bastardkb: fix splinky configuration
The pinout of the splinky changed between the last beta batch, and the
production one. This commit updates the keyboard definition to support
the new pinout by default, while offering backward compatibility.
Define `SPLINKY_BETA_PINOUT` to build the firmware with pre-production
pinout.
Fixes#15
* bastardkb: add support for STeMCell
* Update scylla/tbkmini/skeletyl outdated readmes
* bastardkb/dilemma: enable circular scroll
* bastardkb/dilemma: add initial version of the `via` keymap
* bastardkb/dilemma/assembled: add new keyboard
Fixes#20
* bastardkb/dilemma: remove elite-c
* Initial support for the Dilemma 3x5+3 Assembled RGB
* Address code review comments
* Address more comments
* Address review comments
* Address more nits
* bastardkb: split splinky-based keyboards to distinguish between Splinky v2 and v3 pinout
* Set up Bonsai C4 as a platform board file
* corrections and improvements based on testing and feedback
* Added VBUS sensing as default capability for improved split support using Bonsai C4
* Update clock divisor for SPI flash
Co-authored-by: Nick Brassel <nick@tzarc.org>
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Add macros to extract parameters from keycode values
Implement both encoding and decoding for keycodes like TO(layer) or
LM(layer, mod) in one place, so that the decoding won't get out of sync
with the encoding.
While at it, fix some macros for creating keycode values that did not
apply the appropriate masks to parameters (and therefore could allow the
result to be out of range if a wrong parameter was passed).
* keymap_common: Use extraction macros for keycodes
* pointing_device_auto_mouse: Use extraction macros for keycodes
Fixes#18970.
* process_autocorrect: Use extraction macros for keycodes
* process_caps_word: Use extraction macros for keycodes
(Also fix a minor bug - SH_TG was not handled properly)
* process_leader: Use extraction macros for keycodes
(Technically the code is not 100% correct, because it always assumes
that the LT() or MT() action was a tap, but it's a separate issue that
already existed before the keycode changes.)
* process_unicode: Use extraction macros for keycodes
* process_unicodemap: Use extraction macros for keycodes
* mj6xy.h: convert tabs to spaces
* info.json: convert tabs to spaces
* info.json: apply friendly formatting
Whitespace-only change.
* rename LAYOUT_60_ansi_7u_spc to LAYOUT_60_ansi_tsangan
- rename `60_ansi_7u_spc` keymap to `default_ansi_tsangan`
* add K31 position to LAYOUT_60_iso
* rename LAYOUT_60_iso_7u_spc_split_rshift to LAYOUT_60_iso_tsangan_split_rshift
- rename `60_iso_7u_spc_split_rshift` keymap to `default_iso_tsangan_split_rshift`
* add K31 position to LAYOUT_60_iso_arrow
* add K31 position to LAYOUT_60_iso_arrow_6u_spc
* add K31 position to LAYOUT_60_iso_arrow_3u_spc
* refactor LAYOUT_60_iso_7u_spc into LAYOUT_60_iso_tsangan
- add K31 position to layout macro
- rename `60_iso_7u_spc` keymap to `default_iso_tsangan`
* add K31 position to LAYOUT_64_iso
- rename `64_iso` keymap to `default_64_iso`
* add K31 position to LAYOUT_64_iso_3u_spc
- rename `64_iso_3u_spc` keymap to `default_64_iso_3u_spc`
* add K31 position to LAYOUT_64_iso_split_3u_spc
- rename `64_iso_split_3u_spc` keymap to `default_64_iso_split_3u_spc`
* remove LAYOUT_60_iso_1u_lshift_split_rshift macro and keymap
Functionally identical to `LAYOUT_60_iso_split_rshift`.
* remove LAYOUT_60_iso_1u_lshift_7u_spc_split_rshift macro and keymap
Functionally identical to `LAYOUT_60_iso_tsangan_split_rshift`.
* rename LAYOUT_60_ansi_7u_spc_split_bs to LAYOUT_60_ansi_tsangan_split_bs
- rename `60_ansi_7u_spc_split_bs` keymap to `default_60_ansi_tsangan_split_bs`
* add K31 position to LAYOUT_60_iso_split_bs
* rename LAYOUT_60_iso_7u_spc_split_bs_rshift to LAYOUT_60_iso_tsangan_split_bs_rshift
- rename `60_iso_7u_spc_split_bs_rshift` keymap to `default_60_iso_tsangan_split_bs_rshift`
* add K31 position to LAYOUT_60_iso_arrow_split_bs
* add K31 position to LAYOUT_60_iso_arrow_3u_spc_split_bs
- rename `60_iso_arrow_3u_spc_split_bs` keymap to `default_60_iso_arrow_3u_spc_split_bs`
* add K31 position to LAYOUT_60_iso_arrow_split_bs_3u_spc
- rename `60_iso_arrow_split_bs_3u_spc` keymap to `default_60_iso_arrow_split_bs_3u_spc`
* refactor LAYOUT_60_iso_7u_spc_split_bs into LAYOUT_60_iso_tsangan_split_bs
- add K31 position to layout macro
- rename `60_iso_7u_spc_split_bs` keymap to `default_60_iso_tsangan_split_bs`
* add K31 position to LAYOUT_64_iso_split_bs
- rename `64_iso_split_bs` keymap to `default_64_iso_split_bs`
* add K31 position to LAYOUT_64_iso_3u_spc_split_bs
rename `64_iso_3u_spc_split_bs` keymap to `default_64_iso_3u_spc_split_bs`
* add K31 position to LAYOUT_64_iso_split_bs_3u_spc
- rename `64_iso_split_bs_3u_spc` keymap to `default_64_iso_split_bs_3u_spc`
* remove LAYOUT_60_ansi_arrow_6u_spc macro and keymap
Functionally identical to `LAYOUT_60_ansi_arrow`.
* remove LAYOUT_64_ansi_6u_spc macro and keymap
Functionally identical to `LAYOUT_64_ansi`.
* remove LAYOUT_60_iso_arrow_6u_spc macro and keymap
Functionally identical to `LAYOUT_60_iso_arrow`.
* remove LAYOUT_64_iso_6u_spc macro and keymap
Functionally identical to `LAYOUT_64_iso`.
* remove LAYOUT_60_ansi_arrow_6u_spc_split_bs macro and keymap
Functionally identical to `LAYOUT_60_ansi_arrow_split_bs`.
* remove LAYOUT_64_ansi_6u_spc_split_bs macro and keymap
Functionally identical to `LAYOUT_64_ansi_split_bs`.
* remove LAYOUT_60_iso_arrow_6u_spc_split_bs macro and keymap
Functionally identical to `LAYOUT_60_iso_arrow_split_bs`.
* remove LAYOUT_64_iso_6u_spc_split_bs macro and keymap
Functionally identical to `LAYOUT_64_iso_split_bs`.
* remove LAYOUT_60_iso_1u_lshift_split_bs_rshift macro and keymap
Functionally identical to `LAYOUT_60_iso_split_bs_rshift`.
* remove LAYOUT_60_iso_1u_lshift_7u_spc_split_bs_rshift macro and keymap
Functionally identical to `LAYOUT_60_iso_tsangan_split_bs_rshift`.
* refactor keymaps
- convert tabs to spaces
- update keycode grid alignment
* remove LAYOUT_60_ansi_arrow_3u_spc macro and keymap
Subset of `LAYOUT_60_ansi_arrow_3u_spc_split_bs`.
* remove LAYOUT_60_iso_arrow_3u_spc macro and keymap
Subset of `LAYOUT_60_iso_arrow_3u_spc_split_bs`.
* remove LAYOUT_60_iso_tsangan_split_bs macro and keymap
Subset of `LAYOUT_60_iso_tsangan_split_bs_rshift`.
* remove LAYOUT_60_iso_tsangan_split_rshift macro and keymap
Subset of `LAYOUT_60_iso_tsangan_split_bs_rshift`.
* remove LAYOUT_64_ansi_3u_spc macro and keymap
Subset of `LAYOUT_64_ansi_3u_spc_split_bs`.
* remove LAYOUT_64_iso_3u_spc macro and keymap
Subset of `LAYOUT_64_iso_3u_spc_split_bs`.
* remove LAYOUT_60_iso_split_bs macro and keymap
Subset of `LAYOUT_60_iso_split_bs_rshift`.
* remove LAYOUT_60_iso_split_rshift macro and keymap
Subset of `LAYOUT_60_iso_split_bs_rshift`.
* add LAYOUT_60_ansi_split_bs_rshift macro and keymap
* remove LAYOUT_60_ansi_split_bs macro and keymap
Subset of `LAYOUT_60_ansi_split_bs_rshift`.
* add LAYOUT_60_tsangan_hhkb macro and keymap
* remove LAYOUT_60_ansi_tsangan_split_bs macro and keymap
Subset of `LAYOUT_60_tsangan_hhkb`.
* standardize keymap names
Rename all keymaps per QMK guidelines (e.g. keymap using `LAYOUT_60_ansi_arrow` should be named `default_60_ansi_arrow`).
* add LAYOUT_all; refactor default keymap
Add a `LAYOUT_all` macro, and update the `default` keymap to use the new macro.
* refactor via keymap
Update the `via` keymap to match the behaviour of the `default` keymap.
* improve keyboard readme
- fix broken image reference
- improve grammar on keyboard description
- fix Hardware Availability link
- fix `make` instructions
- add bootloader and flashing instructions
* fix default_60_tsangan_hhkb keymap
Fix a keycode count mismatch.
* mj6xy.h: add matrix diagram
* KC_GESC -> QK_GESC per fauxpark
* KC_SLCK -> KC_SCRL per fauxpark
* [miryoku] Revert "[Keymap] manna-harbour_miryoku RESET to QK_BOOT (#18755)"
This reverts commit 89dbc18161.
* [miryoku] Add keyboardio/model01
* [miryoku] Add handwired/dactyl_manuform/4x6
* [miryoku] Update BT keycodes
- Update BT keycodes on Media inner index:
- Move OUT_AUTO to bottom row
- Move RGB_TOG in vi to pinkie column to match other TOG keycodes, and rotate row
* [miryoku] Add Extra and Tap layers
* [miryoku] Rename config workflow option to custom_config
* [miryoku] Update custom_config.h and custom_rules.mk behaviour
* [miryoku] Make mapping macro customisable globally and per layer
* [miryoku] Add layer lock
* [miryoku] Update RGB order in media-l-invertedt
* [miryoku] Change mouse button order
* [miryoku] Change to X macros for layer list
- Supports adding and removing layers from custom_config.h
- Add "U_" prefix to layer names
- Add layer name strings
- Populate keymaps array from X macro
- Populate layers enum from X macro
- Move layers enum to manna-harbour_miryoku.h
- Rename miryoku_alternatives.h to miryoku_layer_alternatives.h
- Rename miryoku_layer.h to miryoku_layer_selection.h
- Remove miryoku_layer_names.h
- Add miryoku_layer_list.h
* [miryoku] Reformat split_3x6_3 mapping
* [miryoku] Add merge field to workflows
* [miryoku] Update thumb combos with new layer names
* [miryoku] Update cover image
* [miryoku] Add satt/vision
* [miryoku] Update Branches and Building docs
* [miryoku] Update reset keycode
* [miryoku] Add xmk
* [miryoku] Add boardsource/lulu
* [miryoku] Fix keyboardio/model01
* Initial work on adding Sinc Rev. 3
* Add RGB Matrix support
* Add encoder map support
* Set I2C pins
* Update LED locations for right half
* Move USB definitions to info.json
* Update RGB modes
* Replace pin mappings for right half with correct ones
* Move config.h back to rev1/rev2 due to addition of rev3
* Convert initial Rev. 3 config work to be data-driven
* Convert RGB Matrix config to DD format
* More config cleanup
* Use full-duplex PIO
* Add MCU/bootloader settings for Rev. 2
* Change ISO Enter location since it shares location with Backslash
* Adjust build settings to reduce flash/EEPROM usage
* Deprecate SECURE_* keycodes for QK_SECURE_*
* Update keycode process
* Update process_secure.c
* Apply suggestions from code review
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* m65hi_alpha.h: add matrix diagram
* rename LAYOUT_all to LAYOUT_65_iso_blocker
* add LAYOUT_65_iso_blocker_tsangan
* tidy-up keymaps
- use four-space indent
- polish keycode grid alignment
* touch-up keymaps
Switch one Page Down keycode for Page Up on the `default` keymap, and switch the Page Down and Page Up keycodes on the `via` keymap.
* Add H50 keyboard from huytbt
Add H50 keyboard
The H50 is a mini keyboard with a 50 percent layout. The keyboard consists of 53 keys.
* Optimize code
* Optimize keymap code
* Optimize code H50 keyboard
* refactor default keymap
- shorten layer names
- KM_QWERTY -> _QW
- KM_MEDIA -> _MD
- KM_GUI_LOCK -> _GL
- use QMK-native keycode aliases
- use four-space indent
- grid-align keycodes
* remove third layer from default keymap
The third layer only serves to disable the GUI keys, which we can do with a keycode.
* update default keymap readme
* ghost_squid.h: add matrix diagram
* add LAYOUT_fullsize_ansi
* add LAYOUT_fullsize_iso
* use LAYOUT_fullsize_iso macro in default keymap
Refactor the default keymap to use the new LAYOUT_fullsize_iso macro.
* remove LAYOUT macro
Same matrix as LAYOUT_fullsize_iso, but in a different assignment order.
* enable Community Layout support
* rename LAYOUT_65_ansi_blocker_tsangan to LAYOUT_65_ansi_blocker_tsangan_split_bs
Layout was implemented with Split Backspace.
* rename LAYOUT_65_iso_blocker_7u_spc to LAYOUT_65_iso_blocker_tsangan_split_bs
* rules.mk: update Community Layout support setting
* mb65s.h: update matrix diagram
* add LAYOUT_65_ansi_blocker
* add LAYOUT_65_iso_blocker
* add LAYOUT_65_ansi_blocker_tsangan
* add LAYOUT_65_iso_blocker_tsangan
* move Community Layout support to info.json
* update Community Layout support
In #18631 some IN notification callbacks that were doing nothing were
removed, which should be a valid thing to do (ChibiOS HAL checks the
`in_cb` and `out_cb` pointers for being non-NULL before invoking those
optional callbacks). However, it turned out that some less popular USB
LLDs (KINETIS and MIMXRT1062) have their own checks for those pointers,
and (incorrectly) skip the ChibiOS callback handling when those pointers
are NULL, which breaks the code for the `USB_USE_WAIT` configuration
option (the waiting thread never gets resumed if the corresponding
callback pointer is NULL).
Add those dummy callbacks again (but use a single function for all of
them instead of individual ones for each endpoint); this restores the
KINETIS and MIMXRT1062 boards to the working state while the LLDs are
getting fixed.
Fixes an issue in Ocean Dream that causes flashing after the oled screen
times out and turns off.
This occurs because writing to an OLED screen turns it on as well and we
are both writing then immediately turning the screen off, but only if
the timeout has occurred (no WPM, 30 seconds has passed).
* info.json: apply friendly formatting
* nz67v2.h: use ____ for KC_NO
* nz67v2.h: add matrix diagram
* add LAYOUT_all
Same matrix as `LAYOUT`, but physically arranged to mimic the keyboard layout.
Rotary encoder positions move from the bottom row to the top row.
* refactor keymaps to use LAYOUT_all macro
* info.json: add LAYOUT_all data
* remove LAYOUT macro
Now unused.
* add LAYOUT_65_ansi_blocker
* add LAYOUT_65_ansi_blocker_split_space
* remove dead space from layouts
Remove empty space from `LAYOUT_65_ansi_blocker` and `LAYOUT_65_ansi_blocker_split_space` layouts.
* add matrix diagrams
* add LAYOUT_60_ansi
* add LAYOUT_60_ansi_tsangan
* add LAYOUT_60_tsangan_hhkb
* enable Community Layout support
* enable Community Layout support, phase 2
Remove the `LAYOUTS` rules from the `rules.mk` files, now that the data is in `info.json`.
* qmk art 2020+
* fix compilation
* remove functions. translation matrix
* fix edgecases
* whitespace
* fix memory oddity changing the keymap with every string print
* return edge cases
* support workman layout for git strings
* subm
* secrets
* fix git ignore
* rename var
* workman HW feature toggle
* remember lenght for inserting secrets
* blink leds on secret finish
* 75:fix LEDs not reflecting state on boot
* move common led functions to user file
* move common led funcs to separate file
* move funcs file to separate folder
* capsword
* move string functions to a separate file
* consolidate led funcs
* tidy up variables
* email
* fix printing random keys on Mac + temp disable dynamic macro
* make switch lang shortcut configurable
* revert ergodone behaviour
* move git ignore to userspace folder
* ergodone clean up + saving space
* navigation combos
* shift caps always turns on caps lock. more combos
* convert led funcs into header file
* convert string funcs into header file
* fix compilation for split75
* remove git cherry pick
* update legal headers
* more legal headers
* home row macros
* refactor combo names
* redo combos for homerow + f10 11 12
* custom strings implementation (like secrets)
* ergodone: more consistent f keys
* tweak left right combos to minimise typing interference
* ctr z shortcut
* ergodone: move del to a more convenient key
* rename secrets file to a shorter length
* ergodone tweaks
* fix after merge
* removed included .c files
* Update keyboards/ktec/ergodone/keymaps/art/user_config.c.example
* Update keyboards/mt/split75/keymaps/art/user_config.c.example
* Update users/art/secr.h.example
* Update users/art/custom_definitions.h.example
* Update users/art/art_user_config.h.example
* Update users/art/art.h
* initial upload
* adjust keymap
* Delete config.h
* Update post.rules.mk
* remapped to correct pins
* add idobao keymap
* disable underglow
* minor fix
* right menu on windows
* imgur
* ID61_process_special_k() function
* KC_APP fix
* Update keymap.c
* pre-pr touchups
* enum layouts
* review changes recommended by tzarc
* refactor special keys to common lib
* rename layout and add info.json labels
* account for 15 possible USER keys
* post drashna review
* Fn Arrow keys added
* post review edits
* use bitmask instead of bool array in specialk.c
* move to community layout
* Rotary encoder setting is revised to solve a mulfunction. UNUSED_PINS deleted.
* Encoder map applied.
* ENCODER_MAP_ENABLE moved to keymap level.
* Settings in rules.mk moved to info.json.
* picture sent to imgur. config.h streamlined.
* rename LAYOUT_all to LAYOUT_65_ansi_blocker_tsangan_split_bs
* enable Community Layouts support
* info.json: format whitespace
- apply four-space indent
- remove trailing whitespace
* info.json: correct maintainer value
Field is intended to reference the maintainer's GitHub username.
* * info.json: fix key position and order
* fix json format
* Update keyboards/fungo/rev1/info.json
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Joel Challis <git@zvecr.com>
...by moving the actually timing critical `enter_rx_state()` and
`leave_rx_state()` functions to RAM in order to not be affected by XIP
cache spikes. This commit also reverts the hacky USB interrupt disabling
that was done in 293c53d774
* Add encoder map to Quefrency VIA keymap
* Explicitly define which RGB animations are enabled
* Set different PID to prep for different VIA .json usage
* Add ifdefs to handle if ENCODER_ENABLE is set to NO
* Fix ordering of entries for RGB matrix.
* Fix typos in RGB matrix definition.
These matrix indices overlapped.
* Improve positions in RGB matrix.
The rotary encoder and the key below that are in a new column.
The rotary encoder's height is inbetween rows.
The key below is kind of off-axis and thus hard to pin down to a
specific location.
The modifer keys in the bottom row are staggered compared to the other
columns.
* fmh.h: add matrix diagram
* info.json: apply friendly formatting
* physically arrange LAYOUT_all macro
Move position `K5D` (right half of Split Backspace) to the end of the top row.
* rename LAYOUT_all to LAYOUT_60_tsangan_hhkb
* add LAYOUT_60_ansi_tsangan
* add LAYOUT_60_hhkb
* add LAYOUT_60_ansi_wkl
* add LAYOUT_60_ansi_wkl_split_bs_rshift
* enable Community Layouts support
* Move Bluetooth-related function calls up to host/keyboard level
* Remove pointless set_output() call
* Move bluetooth (rn42) init to end of keyboard_init()
* Enable SPI/UART for ChibiOS targets
* Some more slight tweaks
* Discourage use of ENCODER_MAP at keyboard level (#18286)
* Discourage use of ENCODER_MAP at keyboard level
* Update docs/feature_encoders.md
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Fungo rev1: fix QMK Configurator key sequence (#18293)
* info.json: correct JSON syntax; friendly formatting
* info.json: fix key sequence
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Discourage use of ENCODER_MAP at keyboard level
* Update docs/feature_encoders.md
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* [Core] Rework PS/2 driver selection
Enabling and selecting PS/2 driver was using old approach,
so it was reworked to current approach, inspired by Serial
and WS2812 driver selections.
* [Keyboard] Update keyboards using PS/2 to use new PS/2 driver selection
* [Docs] Update PS/2 documentation to use new PS/2 driver selection
* Fix indentation
* [Core] Add PS2 to data driver
* Fix oversight in property name
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Add PS/2 pins to data driven mappings
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Add ARRAY_SIZE and CEILING utility macros
* Apply a coccinelle patch to use ARRAY_SIZE
* fix up some straggling items
* Fix 'make test:secure'
* Enhance ARRAY_SIZE macro to reject acting on pointers
The previous definition would not produce a diagnostic for
```
int *p;
size_t num_elem = ARRAY_SIZE(p)
```
but the new one will.
* explicitly get definition of ARRAY_SIZE
* Convert to ARRAY_SIZE when const is involved
The following spatch finds additional instances where the array is
const and the division is by the size of the type, not the size of
the first element:
```
@ rule5a using "empty.iso" @
type T;
const T[] E;
@@
- (sizeof(E)/sizeof(T))
+ ARRAY_SIZE(E)
@ rule6a using "empty.iso" @
type T;
const T[] E;
@@
- sizeof(E)/sizeof(T)
+ ARRAY_SIZE(E)
```
* New instances of ARRAY_SIZE added since initial spatch run
* Use `ARRAY_SIZE` in docs (found by grep)
* Manually use ARRAY_SIZE
hs_set is expected to be the same size as uint16_t, though it's made
of two 8-bit integers
* Just like char, sizeof(uint8_t) is guaranteed to be 1
This is at least true on any plausible system where qmk is actually used.
Per my understanding it's universally true, assuming that uint8_t exists:
https://stackoverflow.com/questions/48655310/can-i-assume-that-sizeofuint8-t-1
* Run qmk-format on core C files touched in this branch
Co-authored-by: Stefan Kerkmann <karlk90@pm.me>
* Add an ez_maker directpins for rp2040
This allows all exposed pins on the Raspberry Pi Pico to be used
as up to 26 individual keys. Keys use a common ground arrangement.
The firmware is also expected to work on generic RP2040 boards, check
manufacturer pinout diagrams or use trial and error to find out the GP#s
of the pins.
* Update keyboards/ez_maker/directpins/rp2040/info.json
Co-authored-by: Joel Challis <git@zvecr.com>
* Changes based on review comments
Co-authored-by: Joel Challis <git@zvecr.com>
* shell.nix: Update `tomlkit` to 0.11.4 using a Nixpkgs overlay
The used Nixpkgs snapshot contains `tomlkit` version 0.7.0, which is
affected by https://www.github.com/sdispater/tomlkit/issues/148; that
bug is triggered by `pyproject.toml` from `jsonschema` >= 4.11.0,
preventing the build of that module.
Just adding `tomlkit = "*"` to the `[tool.poetry.dev-dependencies]`
section of `nix/pyproject.toml` does not fix the `jsonschema` build,
because `makeRemoveSpecialDependenciesHook` inside `poetry2nix` is not
affected by `nix/pyproject.toml`. Add a Nixpkgs overlay which updates
the `tomlkit` Python module globally, so that `poetry2nix` would also
use the updated version internally.
* shell.nix: Bump `poetry2nix` to the most recent version
The new `poetry2nix` version includes overrides which are required for
recent versions of some Python packages (in particular, `jsonschema` and
`dotty-dict`).
* shell.nix: Bump QMK CLI to 1.1.1; update other Python deps
Update `pyproject.toml` to match `requirements*.txt`:
- add `pyserial = "*"`
- replace `qmk-dotty-dict = "*"` with `dotty-dict = "*"` (#18117, also
required for compatibility with `qmk` 1.1.1, where this replacement
had already been performed)
Add build dependencies of various Python modules to `pyproject.toml`:
- `hatchling`, `hatch-vcs`, `hatch-fancy-pypi-readme` (required by
`jsonschema` >= 4.11.0)
- `pytest` (a newer version is required to solve the dependency conflict
with the `hatchling` module due to the upper bound on `pluggy`)
- `flit-core` (a more recent version is required to build `tomli`)
- `poetry-core` (required for `dotty-dict` >= 1.3.1, and the version
from Nixpkgs does not build on Darwin due to NixOS/nix#4758)
Update `poetry.lock` to use the most recent versions of Python modules.
The complete list of Python module updates as listed in `poetry.lock`
(note that other modules might be present in the Python environment,
e.g., if they come from Nixpkgs):
- `atomicwrites`: none -> 1.4.1 (but this module is not actually used,
because the corresponding dependency of `pytest` is win32-only)
- `attrs`: 21.4.0 -> 22.1.0
- `colorama`: 0.4.4 -> 0.4.5
- `coverage`: 6.4 -> none
- `dotty-dict`: none -> 1.3.1 (used instead of `qmk-dotty-dict`)
- `editables`: none -> 0.3
- `flake8`: 4.0.1 -> 5.0.4
- `flake8-polyfill`: 1.0.2 -> none
- `flit-core`: none -> 3.7.1
- `hatch-fancy-pypi-readme`: none -> 22.3.0
- `hatch-vcs`: none -> 0.2.0
- `hatchling`: none -> 1.8.0
- `hjson`: 3.0.2 -> 3.1.0
- `importlib-resources`: 5.7.1 -> 5.9.0
- `iniconfig`: none -> 1.1.1
- `jsonschema`: 4.5.1 -> 4.14.0
- `mccabe`: 0.6.1 -> 0.7.0
- `nose2`: 0.11.0 -> 0.12.0
- `packaging`: none -> 21.3
- `pathspec`: none -> 0.9.0
- `pep8-naming`: 0.12.1 -> 0.13.2
- `pillow`: 9.1.1 -> 9.2.0
- `pkgutil-resolve-name`: none -> 1.3.10
- `pluggy`: none -> 1.0.0
- `poetry-core`: none -> 1.0.8
- `py`: none -> 1.11.0
- `pycodestyle`: 2.8.0 -> 2.9.1
- `pyflakes`: 2.4.0 -> 2.5.0
- `pygments`: 2.12.0 -> 2.13.0
- `pyparsing`: none -> 3.0.9
- `pyserial`: none -> 3.5
- `pytest`: none -> 7.1.2
- `qmk`: 1.1.0 -> 1.1.1
- `qmk-dotty-dict`: 1.3.0.post1 -> none (replaced by `dotty-dict`)
- `setuptools-scm`: none -> 7.0.5
- `tomli`: none -> 2.0.1
- `typing-extensions`: none -> 4.3.0
- `zipp`: 3.8.0 -> 3.8.1
break statements are missing from the switch for both registering and unregistering key codes. Neither have a default: case either. The code as exists in the repository right now does not compile. It does with this changes.
* Fix Caps Word to treat mod-taps more consistently.
Previously, holding any mod-tap key while Caps Word is active stops Caps
Word, and this happens regardless of `caps_word_press_user()`. Yet for
regular mod keys, AltGr (KC_RALT) is ignored, Shift keys are passed to
`caps_word_press_user()` to determine whether to continue, and
similarly, a key `RSFT(KC_RALT)` representing Right Shift + Alt is
passed to `caps_word_press_user()` to determine whether to continue.
This commit makes held mod-tap keys consistent with regular mod keys:
* Holding a `RALT_T` mod-tap is ignored.
* When holding a shift mod-tap key, `KC_LSFT` or `KC_RSFT` is passed to
`caps_word_press_user()` to determine whether to continue.
* When holding a Right Shift + Alt (`RSA_T`) mod-tap, `RSFT(KC_RALT)` is
passed to `caps_word_press_user()`.
Particularly, with this fix a user may choose to continue Caps Word when
a shift mod-tap key is held by adding `KC_LSFT` and `KC_RSFT` cases in
`caps_word_press_user()`. For instance as
```
bool caps_word_press_user(uint16_t keycode) {
switch (keycode) {
// Keycodes that continue Caps Word, with shift applied.
case KC_A ... KC_Z:
case KC_MINS:
add_weak_mods(MOD_BIT(KC_LSFT)); // Apply shift to the next key.
return true;
// Keycodes that continue Caps Word, without shifting.
case KC_1 ... KC_0:
case KC_BSPC:
case KC_DEL:
case KC_UNDS:
case KC_LSFT: // <<< Added here.
case KC_RSFT:
return true;
default:
return false; // Deactivate Caps Word.
}
}
```
* Fix Caps Word to treat mod-taps more consistently.
Previously, holding any mod-tap key while Caps Word is active stops Caps
Word, and this happens regardless of `caps_word_press_user()`. Yet for
regular mod keys, AltGr (KC_RALT) is ignored, Shift keys are passed to
`caps_word_press_user()` to determine whether to continue, and
similarly, a key `RSFT(KC_RALT)` representing Right Shift + Alt is
passed to `caps_word_press_user()` to determine whether to continue.
This commit makes held mod-tap keys consistent with regular mod keys:
* Holding a `RALT_T` mod-tap is ignored.
* When holding a shift mod-tap key, `KC_LSFT` or `KC_RSFT` is passed to
`caps_word_press_user()` to determine whether to continue.
* When holding a Right Shift + Alt (`RSA_T`) mod-tap, `RSFT(KC_RALT)` is
passed to `caps_word_press_user()`.
Particularly, with this fix a user may choose to continue Caps Word when
a shift mod-tap key is held by adding `KC_LSFT` and `KC_RSFT` cases in
`caps_word_press_user()`. For instance as
```
bool caps_word_press_user(uint16_t keycode) {
switch (keycode) {
// Keycodes that continue Caps Word, with shift applied.
case KC_A ... KC_Z:
case KC_MINS:
add_weak_mods(MOD_BIT(KC_LSFT)); // Apply shift to the next key.
return true;
// Keycodes that continue Caps Word, without shifting.
case KC_1 ... KC_0:
case KC_BSPC:
case KC_DEL:
case KC_UNDS:
case KC_LSFT: // <<< Added here.
case KC_RSFT:
return true;
default:
return false; // Deactivate Caps Word.
}
}
```
* Update quantum/process_keycode/process_caps_word.c
Co-authored-by: Joel Challis <git@zvecr.com>
* [Keymap] adding new user (p4yne) layout with complex lighting features (per layer, per key, per type) and usefull layers DE/US, etc.
Co-authored-by: Drashna Jaelre <drashna@live.com>
* SPLIT_USB_DETECT added.
* lednotg keymap added.
* lednotg missing modification fixed.
* VERSION is available.
* USER00 is used instead of SAFE_RANGE in via/keymap.c
* Working on new dactyl
* Preliminary build and keymap in place for 4x5_5 dactyl manuform
* Removing first attempt to use 4x5
* Updating to match c style guide
* Fixing issues after merge, deletion of dactyl_manuform.h
* Spliting out custom keymap
* Adding license headers
* Fixing EE_HANDS detection on Pro-Micro
The pro-micro was not working when I plugged into the elite-c on the
right hand side of my keyboard. Adding the SPLIT_USB_DIRECT definition
fixed the issue.
* Apply suggestions from code review
Adding Drashna's delete comments
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Removed config.h for keymaps and tweaked keymap
Per Drashna's pr review, I have removed the config.h files for the
keymaps.
Also tweaked my keymap to switch backspace and enter. Added tapping
toggle for RAISE.
* Further tweaking ssedrick keymap for dactyl_manuform 4x5_5
As with most new keyboards, they take some getting used to.
I've rearranged my thumb cluster to hopfully a more long
term solution.
* Adding missing KC_BSLS to ssedrick keymap for 4x5_5
Co-authored-by: Drashna Jaelre <drashna@live.com>
* 46: Copy from 52 and file rename
* 46: File internals refer to 46, not 52
* 46: Board remove row
* 46: Keymap: Lshift becomes ctrl, Rshift a symbol
- ESC and CAPs on upper thumbs
- AltGr and App on upper thumbs
- Page up/down on upper thumbs
- F11, F12 and mods for them on adjust
* 46: Readme update for json script, tweaks
* 46: Board fix LED count
* 46: Keymap: Arrows right, symmetric layer keys
* 46: Readme: Image link with and w/o outer pinkie
* 46: Keymap: link fixed image of nav layer
* 46: Keymap: fix reaching adj layer
Co-authored-by: mmccoyd <mmccoyd@cs.berkley.edu>
* Fixed Left Shift tapdance in general and for gaming mode. (#12)
* update ISO readme
* left shift fixed in general, including for gaming mode
* fixed toggle menu rendering on ISO layouts
* updated readme's and cosmetics
* update readme's
* update readme's again
* readme cosmetics
* consolidate readme's
* more readme cosmetics
* clarification for bootloader mode on ISO
* Autocorrect added with 400 word English dictionary (#13)
* autocorrect added with 400 word dictionary
* update readme's for autocorrect
* Add FN-B as shortcut to bootloader
* Update .gitignore
Co-authored-by: Joel Challis <git@zvecr.com>
* RGB changes to system numlock and ISO extended alphas
- hide system numlock off indicator (primarily for Mac users) by moving it to numpad and FN layers instead
- give users with extended alpha ISO languages a config option to add RGB highlights for extras alphas on capslock
* readme updates
* Fixed [FN]B and [FN]N shortcuts not working on numpad layer
Co-authored-by: Joel Challis <git@zvecr.com>
* 52 Keymap.json: Set for Hillside 52
- Change script rows
* 52 Keymap.c: mirror .json
CAPSWORD, QK_BOOT, readme cleanup, EE_RST
* 52 Keymap.json: Initial files copy from 56
* 52 Keymap.json nav/edit lay, thumb shift, syms
- Del in backspace spot on sym layer
- Thumb shift OSM instead of extra space
- Nav/edit on num/fn: arrows cut copy paste undo redo, page up/down
- Fn keys bottom row to allow nav edit keys
- App and AltGr on lower row, on their layer
- Braces on index, so more common -= on middle ring.
- Adjust has Ctrl/GUI swap
- EE_RST, CAPSWORD, QK_BOOT, SPLIT_DETECT
* 52 Family: readme image and folder link
* 52 Board: initial copy from 56
* 52 Keymap via
* 52 Board: remove keys, cant columns, better ids
- .json: vid: MM, pid: H52
* 52 Keymap.c: initial.c copy from 48
* QK_BOOT EE_CLR, not ANY(), as config.qmk supports
- CAPSWRD instead of ANY, though config.qmk still converts to ANY()
* Cleanup readme
* 52 Keymap: Remove redundant key, cleanup script
* 52 Keymap: Fix template
* 52 Readme: Link lower res image better for readme
Co-authored-by: Drashna Jaelre <drashna@live.com>
* 52 Keymap: Move pretty-print script to GitHub wiki
* 52 Keymap: Link to 1024 res image thumbnails
* 52 Keymap: fix whitespace before image link
* Family: Fix image link to 1024 thumb
Co-authored-by: Drashna Jaelre <drashna@live.com>
* 52: Keymap: Caps word on a layer home row
* 52: Keymap: Arrows on right. Symmetric layer keys.
- Nav:
- Arrows on right so up/down more intuitive. Page up/down on ends
- Cut on home row, as more common
- Sym:
- Layer mods on activate hand, extras symbols on left
- Common digits on lower row
- Base:
- Layer keys symmetric, on most extended, not resting, thumb
- Mute on util key for easy use
- Swap layers 3 and 4 to match swapped thumbs
Co-authored-by: mmccoyd <mmccoyd@cs.berkley.edu>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Unfortunately, the crippled versions of “Bluepill” boards with
STM32F103C6xx chips instead of STM32F103C8xx are now sold all over the
place, sometimes advertised in a confusing way to make the difference
not noticeable until too late. Add minimal support for these MCUs in
the common “Bluepill with stm32duino” configuration, so that it could be
possible to make something useful from those boards (although fitting
QMK into the available 24 KiB of flash may be rather hard).
(In fact, I'm not sure whether the “STM32” part of the chip name is
actually correct for those boards of uncertain origin, so the onekey
board name is `bluepill_f103c6`; another reason for that name is to
match the existing `blackpill_f401` and `blackpill_f411`.)
The EEPROM emulation support is not included on purpose, because
enabling it without having a working firmware size check would be
irresponsible with such flash size (the chance that someone would build
a firmware where the EEPROM backing store ends up overlapping some
firmware code is really high). Other than that, enabling the EEPROM
emulation code is mostly trivial (the `wear_leveling` driver with the
`embedded_flash` backing store even works without any custom
configuration, although its code is significantly larger than the
`vendor` driver, which may also be important for such flash size).
* Initial commit
* testing modes
* working on puckbuddy firmware. This is all working for now but need to clean it up and personalize it.
* needs to be updated from vial build
* prepping for PR
* added rgb mode cycling to fn1 since it isn't on the encoder for these maps
* readme written in preparation for pr
* reverting driver print line
* Removed old reference to OBE in the readme from copypaste error
* applying changes based on review
* applying changes from review
* Update keyboards/mechwild/puckbuddy/puckbuddy.c
* trailing whitespaces removed
* added clear screen condition for switching back to name rendering
* Added uf2 keymap and fixed display glitch for the logo render art.
* Removed extra definition of FEE_PAGE_BASE_ADDRESS
* Removed the uf2 keymap and made it automatic when selecting bootloader instead
* Fixed the bad bootloader check
* moved the uf2 check from rules.mk to post_rules.mk to satisfy lint
* changing it back to stm32-dfu bootloader default
* Fixed RGBLIGHT enable oversight.
* Added persistent dynamic tapping configuration for the cirque touchpad tap term
* new lines at end of files for formatting and diff sanity
* changing default bootloader back to stm32-dfu
* Had to completely redefine the tap keycodes instead of using the DT_UP and DT_DOWN keycodes because I was not able to specify them easily in the via/vial configs and this allows me to keep the original functionality instead of tying it to eeprom like these are.
* Added tap toggling keycodes to quick enable and disable the tapping term
* working out an issue where the tap status keeps turning to off on power cycle
* correcting submodule garbo
* Fixed display issue and rewrote TAP config approach to make it a little easier to control
* removing backup puckbuddy.c code
* Added some comment, removed some commented out old code, removed trailing whitespace
* Changed to handle tinyuf2 by expecting emulated eeprom so that adding other forms of eeprom can be handled for the memory offset separately, and added user oled conditional inside the keyboard oled code block
* Updated default keymaps to have the tap and dpi keys on by default
* Apply suggestions from code review
* Apply suggestions from code review
* Reverted to most usable configuration for RDP usage.
* Added some HSV color definitions without the value portion to allow using the existing value.
* Switched to using HSV and HS color definitions.
* Added media keys to the convenience layer.
* Updated make rules to enable media keys.
* Cleaned up planck make rules.
* boardsource/the_mark: add QMK Configurator layout data
* add keyboard maintainers to info.json
Adds the individual and organization accounts as listed maintainers.
* skergo.h: use ___ for KC_NO
* skergo.h: use 3-character notation
* skergo.h: add matrix diagram
* add LAYOUT_all macro
* update grid alignment of LAYOUT macro and keymaps
* refactor keymaps
Refactor keymaps to use the `LAYOUT_all` macro. Converts tabs to spaces.
This change necessitates the following changes to keymaps:
- The keycodes for Page Up, Page Down, and End each move up one row - all as the last keys on their new rows.
- The keycode for the secondary B key moves up one row, inserted between the primary (left side) B and the N.
* remove LAYOUT macro
* rename LAYOUT_all macro to LAYOUT_split_bs
* add LAYOUT_2u_bs macro
* readme.md: add flashing example
* info.json: correct maintainer value
Update to reference maintainer's GitHub username.
* Fix typo for POINTING_DEVICE_GESTURES_SCROLL_ENABLE
Follow the name written in documentation which follows
POINTING_DEVICE_GESTURES_CURSOR_GLIDE_ENABLE
* Reword the blurb about POINTING_DEVICE_GESTURES_CURSOR_GLIDE_ENABLE in docs
* info.json: apply friendly formatting
* info.json: correct layout data
Fix the size and position of the Backslash key.
* readme.md: touch-up formatting
* readme.md: switch Bootloader and Docs sections
* correct keyboard maintainer
* kbdfans/bounce/75/hotswap: keymap readability fix
Update grid alignment to disambiguate which keycodes correspond in different layers.
----
Layer 0 had 13 and 9 keycodes on the bottom two rows respectively, while Layers 1-3 had 14 and 8.
* kbdfans/bounce/75/soldered: keymap readability fix
Update grid alignment to disambiguate which keycodes correspond in different layers.
----
Layer 0 had 14 and 9 keycodes on the bottom two rows respectively, while Layers 1-3 had 15 and 8.
* kbdfans/bounce/75/soldered: fix layer index in keymaps
Layer indexes were 0,1,2,1 instead of 0,1,2,3.
* Start of dz65v2 map for sbennett13
* No wpm, disable some rgb, ~copyright~
* No more raindrops
* Remove more rgb modes and set default
* Almost orgot this crappy thing
* cannot define startup :(
* Layered esc is kc_grv
* Start of dz65v2 map for sbennett13
* No wpm, disable some rgb, ~copyright~
* No more raindrops
* Remove more rgb modes and set default
* Almost orgot this crappy thing
* cannot define startup :(
* Layered esc is kc_grv
* Add license to config and keymap
From the ChibiOS HAL I2C driver pages:
After a timeout the driver must be stopped and restarted because the bus is in
an uncertain state.
This commit does that stopping explicitly on any error that occurred, not only
timeouts. As all the i2c functions restart the peripheral if necessary it is
safe to do so.
Co-authored-by: Dasky <32983009+daskygit@users.noreply.github.com>
Co-authored-by: Dasky <32983009+daskygit@users.noreply.github.com>
Static x & y should be the same type as touchData.xValue &
touchData.yValue: uint16_t.
Their delta could be larger than int8_t and should be constrained to
mouse_xy_report_t.
* skjoldr.h: use ___ for KC_NO
* skjoldr.h: use K<row><column> notation
Matrix was previously defined using identifiers in the format of K<column><row>.
* skjoldr.h: add matrix diagram
* info.json: apply friendly formatting
- key legends as labels
- correct key sizes and positioning
* refactor keymaps
Refactors the `default` and `via` keymaps.
- use QMK-native keycode aliases
- grid-align keycodes for readability
* rename LAYOUT macro to LAYOUT_60_ansi_arrow
* enable Community Layout support
* info.json: correct maintainer value
Field is meant to reference the maintainer's GitHub username.
* bastardkb: restructure folder hierarchy ahead of supporting other adapters/mcus
Upcoming support for the following (adapter, mcu) pairs will be
submitted in follow-up PRs:
- `v2/elitec`
- `v2/stemcell`
- `blackpill`
This PR contains the following changes:
- Move previous implementation to an inner `v1/elitec` folder
- Move keyboard USB IDs and strings to data driven
- Update headers to update maintainers list
- Run `qmk format-c`
* bastardkb/charybdis: remove broken acceleration implementation
* bastardkb/charybdis: fix debug output
* bastardkb: add support for BastardKb the `v2/elitec` (adapter, mcu) pair
* bastardkb: add Blackpill support
* bastardkb/charybdis/3x5: add `bstiq` keymap
* bastardkb/charybdis: add fake LEDs to the configuration
For the Charybdis 3x5 (respectively 4x6), the LED config now simulates
36 (respectively 58) LEDs instead of the actual 35 (respectively 56) to
prevent confusion when testing LEDs during assembly when handedness is
not set correctly. Those fake LEDs are bound to the physical
bottom-left corner.
* bastardkbk/charybdis/readme.md: update build commands
Merge pull request #5 from Nathancooke7/update_charybdis_readme_v2_shield.
* bastardkb/charybdis: fix Via keymap with blackpill
* bastardkb/charybdis: add 3x6 configuration
* bastardkb/charybdis: remove unnecessary files
* bastardkb/charybdis: remove obsolete code
* bastardkb/charybdis/3x6: add Via keymap
* bastardkb: add support for Splinky (RP2040) board
* bastardkb: initial configuration for the Splinky (SPI not working yet)
* bastardkb/charybdis/3x5/v2/splinky: tentative change to enable trackball
* bastardkb/charybdis/3x5/v2/splinky: fix SCK, MISO, MOSI pins
* bastardkb/charybdis/3x5/v2/splinky: fix SCK, MISO, MOSI pins
* bastardkb/charybdis/4x6/v2/splinky: add SPI configuration and enable trackball
* bastardkb/charybdis/3x6: add splinky config
* bastardkb/*/v2/splinky: update drivers to `vendor`
* bastardkb/dilemma: add new board
* bastardkb/charybdis: fix infinite loop in `layer_state_set_user(…)` in the `via` keymaps
* bastardkb/dilemma: add `bstiq` keymap
* bastardkb: specify blackpill boards
* bastardkb/charybdis: fix blackpill-specific define syntax
* bastardkb: remove `NO_ACTION_MACRO` and `NO_ACTION_FUNCTION` which are no longer valid options
* bastardkb: fix `QK_BOOT` keycodes
* bastardkb/dilemma: fix mouse direction on X axis
* bastardkb/charybdis/3x6: adjust CS
* bastardkb/dilemma: adjust trackpad configuration
* charybdis: fix `PWM33XX_CS_PIN` defines
This is a follow-up of https://github.com/qmk/qmk_firmware/pull/17613.
* bastardkb: remove Vial mentions from `bstiq` keymaps
* Cleanup unnecessary comments
Co-authored-by: Nathan <nathan.cooke@compass.com>
Co-authored-by: Charly Delay <0xcharly@codesink.dev>
* sinanju.h: add matrix diagram
* add LAYOUT_60_ansi_wkl_split_bs_rshift macro
Same matrix as `LAYOUT_all`, but with position K2D (right half of split Backspace) moved to the end of the top row.
* refactor keymaps
- use `LAYOUT_60_ansi_wkl_split_bs_rshift` macro instead of `LAYOUT_all`
- polish four-space indent
- update grid alignment
- replace `RESET` keycode with `QK_BOOT`
* remove now-unused LAYOUT_all macro
* add LAYOUT_60_ansi_wkl macro with keymap
Add a layout with 2u Backspace and 2.75u right Shift.
* info.json: correct maintainer value
* Initial Apollo87H support
* Define RGB animations and default animation
* Add proper per-key RGB support
* Adjust LED positions
* Separate delta-gamma
* Fine-tune LED positions
* fix up GAMMA revision
* fix up tabs indentation to spaces indentation
* Fixed positioning and CS-SW defs for some LEDs
* Fix INS RGB position
* Fine-tune LED positions, fix default RGB
* Update readme's
* Rename LAYOUT_87H to lowercase 87h
* Formatting gamma's rules.mk
* Formatting delta's rules.mk
* Use smaller readme image
* Use smaller README image
* First support for 87H-T-SC and 88H-T-SC
* Update README
* Fix layout naming
* Remove
* Remove EEPROM definitions, fix missing RGB LED mod/alpha definer
* Add suggestions from noroadsleft
* chiffre refactor for new revisions
* updated led matrix config
* updated per suggestions
* add tapdance enable
* revert tapdance (none defined in the default keymaps)
* clean up rules
* add readme for HE
* remove notes in readme
* fix perm
* fix perms
* Fix spacing on readme
* fix perm
* fix perms again?
Python will evaluate first the left and then the right side of the and operator.
The left side would previously return True based on the truthiness logic that treats any non-emptry string as true.
It would not check if the desired keymap exists.
If the left side is true it will evaluate the right side which will check for the existance of a specific keymap.
With this change the check for existance of two keymaps is implemented.
* Added autoclicker, better mouse, vim like FN layer and more.
* Updated docs to comply with guidelines
* Fixed Imgur links
* increased step sizes
* updated readme to reflect step size
* Added second delay array for autoclicker to compensate for RGB animation CPU loads
* better RGB effects and updated docs
* better README.md formatting
* added DEBONCE libinput workaround for Linux
* fixed formatting
* fixed typos and clarified
* fixed layer picture order
* Update keyboards/dztech/dz65rgb/keymaps/yuannan/keymap.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update keyboards/dztech/dz65rgb/keymaps/yuannan/README.md
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Updated Docs and rules
* Updated with the new deferred exec API to ensure more consistant CPS
* renamed README.md to be lower case to comply with fauxpark's request
* Remapped alt to be left instead of right for compatibility reasons
* Update keyboards/dztech/dz65rgb/keymaps/yuannan/config.h
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Move Pointing Device Initialization to after Split Post Initialization
If both pointing device and split is enabled, the pointing device init needs to be called after the split post init, otherwise the connection (serial/etc) isn't initialized yet, and any commands that need to send data over (such as calling the set cpi command) never get sent over.
* added files for EVO70
* updated info.json and readme
* ran qmk lint and fixed typo in info.json
* removed defines from config.h in favor of info.json
* removed an unnecssary include
* removed unnecessary code
* updated rules.mk to remove mention of Bluetooth
* corrected edit to rules.mk
* added code for OLED menu display
* removed extraneous comments and spaces
* added bongo cat animation
* Update keyboards/custommk/evo70/rules.mk
* Update keyboards/custommk/evo70/config.h
* Modified Bongocat graphics to match original proportions
* updated info.json device version
* updated OLED splash screen display timing
* improved bongo cat tap detection and added backlight breathing to OLED menu
* various improvements to OLED, saving settings, and VIA keymap fix
* removed extraneous define
* custom encoder assignment retained upon powerup, backlight sleep upon suspend
* corrected bongo cat tap detection
* Changed splash screen and bongo cat encoder rotation to use the custom assignments
* removed _default from LAYOUT naming and changed keyboard image to be hosted from imgur
* Force smaller version of image to be used in readme
The `poetry` package from the used Nixpkgs snapshot triggers the regex
compatibility issue in Nix >= 2.10.0 binaries for `x86_64-darwin`:
https://www.github.com/NixOS/nix/issues/4758
Remove the `poetry` package from the Nix shell environment for now
(it is not really required to compile QMK, only to develop the Nix shell
environment itself).
In addition, all `poetry` version earlier than 1.1.14 became effectively
non-functional after a breaking change of the PyPI JSON API:
https://www.github.com/python-poetry/poetry/pull/5973
Updating the `poetry` package is not trivial (just adding it it to
`pyproject.toml` does not work due to dependency version conflicts with
other modules), therefore removing it seems to be the easiest solution
to restore compatibility with new Nix versions while not creating any
major inconvenience for QMK users.
* allowing the kt60 file to be modified so I can do things while waiting for it to be fixed upstream
* initial commit for mokulua keyboard
* Split the board into mirrored and standard layouts.
* Prepping for PR. Silly keymap added.
* prepped for PR
* Apply suggestions from code review
* Fixing firmware from the refactor that removed the mirrored layout.
* Small tweaks using changes from refactor
* Changed the name of the layouts back to match the original to resolve conflict in info.json
* these files needed to be removed as well, they were added as a part of the refactor
* info.json moveds to be different for each build
* Another file had to be removed and the mirrored.c file changed to call mirrored.h instead of standard.h
* fixing chibios ver
* force deleting to revert
* fixing chibios shit
* Update keyboards/mechwild/mokulua/mirrored/mirrored.c
* Update keyboards/mechwild/mokulua/standard/standard.c
* Removing tabs and replacing with 4 spaces. Small style and formatting changes.
- [ ] Alteration (enhancement/optimization) of existing feature(s)
- [ ] New behavior
## Description
<!-- A few sentences describing what it is that you'd like to see in QMK. Additional information (such as links to spec sheets, licensing info, other related issues or PRs, etc) would be helpful. -->
description:Suggest a new feature or changes to existing features.
title:"[Feature Request] "
labels:["enhancement","help wanted"]
body:
- type:markdown
attributes:
value:|
Provide a general summary of the changes you want in the title above.
- type:checkboxes
attributes:
label:Feature Request Type
options:
- label:Core functionality
- label:Add-on hardware support (eg. audio, RGB, OLED screen, etc.)
- label:Alteration (enhancement/optimization) of existing feature(s)
- label:New behavior
- type:textarea
attributes:
label:Description
description:A few sentences describing what it is that you'd like to see in QMK. Additional information (such as links to spec sheets, licensing info, other related issues or PRs, etc) would be helpful.
about: Anything else that doesn't fall into the above categories.
title: ''
labels: help wanted, question
assignees: ''
---
<!--- Provide a general summary of the changes you want in the title above. -->
<!--- Anything on lines wrapped in comments like these will not show up in the final text. -->
<!-- Please check https://docs.qmk.fm/#/support for additional resources first. If that doesn't answer your question, choose the bug report template instead, as that may be more appropriate. -->
description:Anything else that doesn't fall into the above categories.
labels:["help wanted","question"]
body:
- type:markdown
attributes:
value:|
Provide a general summary of the changes you want in the title above.
- type:markdown
attributes:
value:|
Please check [https://docs.qmk.fm/#/support](https://docs.qmk.fm/#/support) for additional resources first. If that doesn't answer your question, choose the bug report template instead, as that may be more appropriate.
- type:textarea
attributes:
label:Issue Description
description:Describe your issue in as much detail as possible.
### 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
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.
### Allow `qmk flash` to use prebuilt firmware binaries ([#16584](https://github.com/qmk/qmk_firmware/pull/16584)) :id=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.
## Changes Requiring User Action :id=changes-requiring-user-action
### 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.
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`.
### Data-driven USB IDs Refactoring ([#18152](https://github.com/qmk/qmk_firmware/pull/18152)) :id=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.
A significant number of keyboards have already been changed on `master` in a like-for-like fashion, and [#18152](https://github.com/qmk/qmk_firmware/pull/18152) performs the same transformations for keyboards already on `develop`.
Previously in `config.h`:
```c
#define VENDOR_ID 0x1234
#define PRODUCT_ID 0x5678
#define DEVICE_VER 0x0001
#define MANUFACTURER Me
#define PRODUCT MyKeyboard
```
Replaced by `info.json`:
```json
{
"keyboard_name":"MyKeyboard",
"manufacturer":"Me",
"usb":{
"vid":"0x1234",
"pid":"0x5678",
"device_version":"0.0.1"
},
// ... layouts, etc. ...
}
```
#### Deprecation Schedule
- 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.
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.
### Add cli command to import keyboard|keymap|kbfirmware ([#16668](https://github.com/qmk/qmk_firmware/pull/16668)) :id=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.
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
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.
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.
Both the PMW33xx and the Cirque Pinnacle implementations have seen a lot of improvement to their code, as has the mouse code in general. Features like circular/edge scrolling for the Cirque, and Kinetic movement for any sensor with "lift detection" ([#17482](https://github.com/qmk/qmk_firmware/pull/17482)). Additionally, for those that make fast motions with their pointing devices, support for much larger mouse movement reports has been added ([#16371](https://github.com/qmk/qmk_firmware/pull/16371)).
Other related changes:
* Add support for large Mouse Reports ([#16371](https://github.com/qmk/qmk_firmware/pull/16371))
* Adafruit Macropad: Add VIA keymap, fix default km ([#17735](https://github.com/qmk/qmk_firmware/pull/17735))
* Fix compilation issues for Charybdis/Dilemma ([#17791](https://github.com/qmk/qmk_firmware/pull/17791))
* bastardkb: fix info.json changes that got reverted during the last merge from `master` to `develop` ([#17800](https://github.com/qmk/qmk_firmware/pull/17800))
_@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).
## Changes Requiring User Action :id=changes-requiring-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.
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.
!> 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.
### Data-driven USB IDs Refactoring ([#18152](https://github.com/qmk/qmk_firmware/pull/18152)) :id=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.
Previously in `config.h`:
```c
#define VENDOR_ID 0x1234
#define PRODUCT_ID 0x5678
#define DEVICE_VER 0x0001
#define MANUFACTURER Me
#define PRODUCT MyKeyboard
```
Replaced by `info.json`:
```json
{
"keyboard_name":"MyKeyboard",
"manufacturer":"Me",
"usb":{
"vid":"0x1234",
"pid":"0x5678",
"device_version":"0.0.1"
}
}
```
### LED Indicator callback refactoring ([#14864](https://github.com/qmk/qmk_firmware/pull/18450)) :id=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.
This changes the standard callback model to allow for a base implementation to be provided by a keyboard, but also still allow for keymap-level overrides without needing to modify the keyboard's code.
The old RGB Matrix keymap code went something like this:
```c
voidrgb_matrix_indicators_user(void){
// keymap LED code
}
```
...but the new RGB Matrix keymap code looks like this:
```c
boolrgb_matrix_indicators_user(void){
// keymap LED code
returnfalse;
}
```
Keyboard designers should now structure their keyboard-level routines like the following, in order to allow for keymap overrides:
```c
boolrgb_matrix_indicators_kb(void){
// Defer to the keymap if they want to override
if(!rgb_matrix_indicators_user()){returnfalse;}
// keyboard LED code
returntrue;
}
```
The equivalent transformations should be done for LED Matrix boards.
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.
## Notable core changes :id=notable-core
This breaking changes cycle, a lot of the core changes are related to cleanup and refactoring -- commonly called "tech debt".
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:
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:
* Add Bonsai C4 as a platform board file ([#18901](https://github.com/qmk/qmk_firmware/pull/18901))
* Add converter support to keymap.json ([#18776](https://github.com/qmk/qmk_firmware/pull/18776))
* Add Elite-C to converters ([#18309](https://github.com/qmk/qmk_firmware/pull/18309))
* 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.
### Pointing and Digitizer device updates :id=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!
* add "inertia" mode for mouse keys ([#18774](https://github.com/qmk/qmk_firmware/pull/18774))
* Fixup aurora/corne on develop ([#19144](https://github.com/qmk/qmk_firmware/pull/19144))
* Minor lint fixes for various info.json ([#19146](https://github.com/qmk/qmk_firmware/pull/19146))
Others:
* Add DD mapping for LED/RGB Matrix max brightness ([#18403](https://github.com/qmk/qmk_firmware/pull/18403))
* Add DD mapping for LED/RGB Matrix split count ([#18408](https://github.com/qmk/qmk_firmware/pull/18408))
* Add DD mapping for LED/RGB Matrix HSVS steps ([#18414](https://github.com/qmk/qmk_firmware/pull/18414))
* Remove RGBLIGHT_ANIMTION and clean up effect defines for 0-F ([#18725](https://github.com/qmk/qmk_firmware/pull/18725))
* Merge API update workflow ([#19121](https://github.com/qmk/qmk_firmware/pull/19121))
Bugs:
* Fix layer switching from tap dances by redoing the keymap lookup ([#17935](https://github.com/qmk/qmk_firmware/pull/17935))
* ws2812: replace RGBLED_NUM with driver-owned constant to decouple driver from RGBLEDs/RGBMATRIX defines ([#18036](https://github.com/qmk/qmk_firmware/pull/18036))
* Prevent USB peripheral fault when restarting USB on WB32 MCUs ([#18058](https://github.com/qmk/qmk_firmware/pull/18058))
* Fix mouse report comparison failing on shared EP (fixes KB preventing sleep) ([#18060](https://github.com/qmk/qmk_firmware/pull/18060))
As you can see the payload describes all aspects of a keyboard necessary to create and generate a firmware. Each layer is a single list of QMK keycodes the same length as the keyboard's `LAYOUT` macro. If a keyboard supports mulitple `LAYOUT` macros you can specify which macro to use.
As you can see the payload describes all aspects of a keyboard necessary to create and generate a firmware. Each layer is a single list of QMK keycodes the same length as the keyboard's `LAYOUT` macro. If a keyboard supports multiple `LAYOUT` macros you can specify which macro to use.
## Submitting a Compile Job
@@ -66,3 +66,41 @@ Once your compile job has finished you'll check the `result` key. The value of t
*`firmware_keymap_url`: A list of URLs for the `keymap.c`
*`firmware_source_url`: A list of URLs for the full firmware source code
*`output`: The stdout and stderr for this compile job. Errors will be found here.
## Constants :id=qmk-constants
If you're writing a tool that leverages constants used within QMK, the API is used to publish "locked-in" versions of those constants in order to ensure that any third-party tooling has a canonical set of information to work with.
The list of available constants can be retrieved by accessing one of the following endpoints:
```
$ curl https://keyboards.qmk.fm/v1/constants_metadata.json # For `master`
!> Versions exported by the `master` endpoint are locked-in. Any extra versions that exist on the `develop` endpoint which don't exist in `master` are subject to change.
?> Only keycodes are currently published, but over time all other "externally visible" IDs are expected to appear on these endpoints.
To retrieve the constants associated with a subsystem, the endpoint format is as follows:
| `AUDIO_DAC_SAMPLE_MAX` | `4095U` | Highest value allowed. Lower value means lower volume. And 4095U is the upper limit, since this is limited to a 12 bit value. Only effects non-pregenerated samples. |
| `AUDIO_DAC_OFF_VALUE` | `AUDIO_DAC_SAMPLE_MAX / 2` | The value of the DAC when notplaying anything. Some setups may require a high (`AUDIO_DAC_SAMPLE_MAX`) or low (`0`) value here. |
| `AUDIO_DAC_OFF_VALUE` | `AUDIO_DAC_SAMPLE_MAX / 2` | The value of the DAC when notplaying anything. Some setups may require a high (`AUDIO_DAC_SAMPLE_MAX`) or low (`0`) value here. |
| `AUDIO_MAX_SIMULTANEOUS_TONES` | __see next table__ | The number of tones that can be played simultaneously. A value that is too high may freeze the controller or glitch out when too many tones are being played. |
| `AUDIO_DAC_SAMPLE_RATE` | __see next table__ | Effective bit rate of the DAC (in hertz), higher limits simultaneous tones, and lower sacrifices quality. |
| `AUDIO_DAC_SAMPLE_RATE` | __see next table__ | Effective bit rate of the DAC (in hertz), higher limits simultaneous tones, and lower sacrifices quality. |
There are a number of predefined quality settings that you can use, with "sane minimum" being the default. You can use custom values by simply defining the sample rate and number of simultaneous tones, instead of using one of the listed presets.
@@ -8,6 +8,8 @@ The breaking change period is when we will merge PR's that change QMK in dangero
## What has been included in past Breaking Changes?
* [2022 Nov 26](ChangeLog/20221126.md)
* [2022 Aug 27](ChangeLog/20220827.md)
* [2022 May 28](ChangeLog/20220528.md)
* [2022 Feb 26](ChangeLog/20220226.md)
* [2021 Nov 27](ChangeLog/20211127.md)
@@ -22,17 +24,18 @@ The breaking change period is when we will merge PR's that change QMK in dangero
## When is the next Breaking Change?
The next Breaking Change is scheduled for August 27, 2022.
The next Breaking Change is scheduled for February 26, 2023.
### Important Dates
* [x] 2022 May 28 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
* [ ] 2022 Jul 31 - `develop` closed to new PR's.
* [ ] 2022 Jul 31 - Call for testers.
* [ ] 2022 Aug 13 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
* [ ] 2022 Aug 25 - `master` is locked, no PR's merged.
* [ ] 2022 Aug 27 - Merge `develop` to `master`.
* [ ] 2022 Aug 27 - `master` is unlocked. PR's can be merged again.
* 2022 Nov 26 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
* 2023 Jan 29 - `develop` closed to new PR's.
* 2023 Jan 29 - Call for testers.
* 2023 Feb 12 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
* 2023 Feb 19 - `develop` is locked, only critical bugfix PR's merged.
* 2023 Feb 24 - `master` is locked, no PR's merged.
* 2023 Feb 26 - Merge `develop` to `master`.
* 2023 Feb 26 - `master` is unlocked. PR's can be merged again.
## What changes will be included?
@@ -43,7 +46,7 @@ If you want your breaking change to be included in this round you need to create
Criteria for acceptance:
* The PR is complete and ready to merge
* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20220827`.
* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20221126`.
* This should be in Markdown format, with a name in the format `PR12345.md`, substituting the digits for your PR's ID.
* One strong recommendation that the ChangeLog document matches the PR description on GitHub, so as to ensure traceability.
@@ -54,53 +57,47 @@ This section documents various processes we use when running the Breaking Change
### 4 Weeks Before Merge
*`develop` is now closed to new PR's, only fixes for current PR's may be merged
* Post call for testers
* [ ] Discord
* [ ] GitHub PR
* [ ] https://reddit.com/r/olkb
* Post call for testers: message `@Breaking Changes Updates` on `#qmk_firmware` in Discord:
* `@Breaking Changes Updates -- Hey folks, last day for functional PRs to be raised against qmk_firmware for this breaking changes cycle is today.`
### 2 Weeks Before Merge
*`develop` is now closed to existing PR merges, only bugfixes for previous merges may be included
* Post call for testers
* [ ] Discord
* [ ] GitHub PR
* [ ] https://reddit.com/r/olkb
* Post call for testers: message `@Breaking Changes Updates` on `#qmk_firmware` in Discord.
* `@Breaking Changes Updates -- Hey folks, last day for functional PRs to be merged into qmk_firmware for this breaking changes cycle is today. After that, we're handling bugfixes only.`
### 1 Week Before Merge
*Announce that master will be closed from <2DaysBefore> to <DayofMerge>
* [ ] Discord
* [ ] GitHub PR
* [ ] https://reddit.com/r/olkb
*`develop` is now closed to PR merges, only critical bugfixes may be included
* Announce that master will be closed from <2DaysBefore> to <DayofMerge> -- message `@Breaking Changes Updates` on `#qmk_firmware` in Discord:
* `@Breaking Changes Updates -- Hey folks, last day for functional PRs to be merged into qmk_firmware for this breaking changes cycle is today. After that, we're handling bugfixes only.`
### 2 Days Before Merge
*`master` is now closed to PR merges
* Announce that master is closed for 2 days
* [ ] Discord
* [ ] GitHub PR
* [ ] https://reddit.com/r/olkb
* `@Breaking Changes Updates -- Hey folks, the master branch of qmk_firmware is now locked for the next couple of days while we prepare to merge the newest batch of changes from develop.`
### Day Of Merge
*`qmk_firmware` git commands
* [ ]`git checkout develop`
* [ ]`git pull --ff-only`
* [ ] Edit `readme.md`
* [ ] Remove the notes about `develop`
* [ ] Roll up the ChangeLog into one file.
* [ ]`git commit -m 'Merge point for <DATE> Breaking Change'`
* [ ]`git push upstream develop`
*`git checkout develop`
*`git pull --ff-only`
* Edit `readme.md`
* Remove the notes about `develop`
* Roll up the ChangeLog into one file.
*`git commit -m 'Merge point for <DATE> Breaking Change'`
*`git push upstream develop`
* GitHub Actions
* [ ] Create a PR for `develop`
* [ ]**Turn off 'Automatically delete head branches' for the repository** -- confirm with @qmk/directors that it is done before continuing
* Create a PR for `develop`
* **Turn off 'Automatically delete head branches' for the repository** -- confirm with @qmk/directors that it is done before continuing
*`qmk_firmware` git commands
* [ ]`git checkout master`
* [ ]`git pull --ff-only`
* [ ]`git merge --no-ff develop`
* [ ]`git tag <next_version>` # Prevent the breakpoint tag from confusing version incrementing
* [ ]`git push upstream <next_version>`
* [ ]`git push upstream master`
*`git checkout master`
*`git pull --ff-only`
*`git merge --no-ff develop`
*`git tag <next_version>` # Prevent the breakpoint tag from confusing version incrementing
*`git push upstream <next_version>`
*`git push upstream master`
## Post-merge operations
@@ -109,28 +106,72 @@ This section documents various processes we use when running the Breaking Change
This happens immediately after the previous `develop` branch is merged to `master`.
*`qmk_firmware` git commands
* [ ]`git checkout master`
* [ ]`git pull --ff-only`
* [ ]`git checkout develop`
* [ ]`git pull --ff-only`
* [ ]`git merge --no-ff master`
* [ ] Edit `readme.md`
* [ ] Add a big notice at the top that this is a testing branch.
* [ ] Include a link to this document
* [ ]`git commit -m 'Branch point for <DATE> Breaking Change'`
| Topic | Last `develop` functionality PRs to be raised |
| Start Date | ((5 weeks before merge)), 12:00am |
| End Date | ((4 weeks before merge)), 12:00am |
| Description | This is the last window for functional PRs to be raised against `develop` for the current breaking changes cycle. After ((4 weeks before merge)), any new PRs targeting `develop` will be deferred to the next cycle. |
| Topic | Last `develop` functionality PRs to be merged |
| Start Date | ((4 weeks before merge)), 12:00am |
| End Date | ((2 weeks before merge)), 12:00am |
| Description | This is the last window for functional PRs to be merged into `develop` for the current breaking changes cycle. After ((2 weeks before merge)), only bugfix PRs targeting `develop` will be considered for merge. |
| Start Date | ((2 weeks before merge)), 12:00am |
| End Date | ((day of merge)), 12:00am |
| Description | This is the deadline for functionality bugfix PRs to be merged into `develop` for the current breaking changes cycle. After ((1 week before merge)), only critical bugfix PRs targeting `develop` will be considered for merge. |
| Description | At some point, QMK will merge `develop` into `master` and everyone will be able to reap the benefits of the newest batch of functionality. |
@@ -206,7 +223,7 @@ Check your environment and report problems only:
## `qmk format-json`
Formats a JSON file in a (mostly) human-friendly way. Will usually correctly detect the format of the JSON (info.json or keymap.json) but you can override this with `--format` if neccesary.
Formats a JSON file in a (mostly) human-friendly way. Will usually correctly detect the format of the JSON (info.json or keymap.json) but you can override this with `--format` if necessary.
The configuration is not written out when it is changed. Most commands do not need to do this. We prefer to have the user change their configuration deliberitely using `qmk config`.
The configuration is not written out when it is changed. Most commands do not need to do this. We prefer to have the user change their configuration deliberately using `qmk config`.
You can use `cli.save_config()` to write out the configuration.
@@ -24,7 +24,7 @@ Most of our style is pretty easy to pick up on, but right now it's not entirely
* Readability is more important than consistency.
* Follow the file's existing style. If the file is mixed, follow the style that makes sense for the section you are modifying.
* When indenting, keep the hash at the start of the line and add whitespace between `#` and `if`, starting with 4 spaces after the `#`.
* You can follow the indention level of the surrounding C code, or preprocessor directives can have their own indentation levels. Choose the style that best communicates the intent of your code.
* You can follow the indentation level of the surrounding C code, or preprocessor directives can have their own indentation levels. Choose the style that best communicates the intent of your code.
Most of our style follows PEP8 with some local modifications to make things less nit-picky.
* We target Python 3.7 for compatability with all supported platforms.
* We target Python 3.7 for compatibility with all supported platforms.
* We indent using four (4) spaces (soft tabs)
* We encourage liberal use of comments
* Think of them as a story describing the feature
@@ -21,7 +21,7 @@ You can use [yapf](https://github.com/google/yapf) to style your code. We provid
We don't have a hard and fast rule for when to use `import ...` vs `from ... import ...`. Understandability and maintainability is our ultimate goal.
Generally we prefer to import specific function and class names from a module to keep code shorter and easier to understand. Sometimes this results in a name that is ambiguous, and in such cases we prefer to import the module instead. You should avoid using the "as" keyword when importing, unless you are importing a compatability module.
Generally we prefer to import specific function and class names from a module to keep code shorter and easier to understand. Sometimes this results in a name that is ambiguous, and in such cases we prefer to import the module instead. You should avoid using the "as" keyword when importing, unless you are importing a compatibility module.
Imports should be one line per module. We group import statements together using the standard python rules- system, 3rd party, local.
QMK is nearly infinitely configurable. Wherever possible we err on the side of allowing users to customize their keyboard, even at the expense of code size. That level of flexibility makes for a daunting configuration experience, however.
There are two main types of configuration files in QMK- `config.h` and `rules.mk`. These files exist at various levels in QMK and all files of the same type are combined to build the final configuration. The levels, from lowest priority to highest priority, are:
There are three main types of configuration files in QMK:
*`config.h`, which contains various preprocessor directives (`#define`, `#ifdef`)
*`rules.mk`, which contains additional variables
*`info.json`, which is utilized for [data-driven configuration](https://docs.qmk.fm/#/data_driven_config)
This page will only discuss the first two types, `config.h` and `rules.mk`.
?> While not all settings have data-driven equivalents yet, keyboard makers are encouraged to utilize the `info.json` file to set the metadata for their boards when possible. See the [`info.json` Format](https://docs.qmk.fm/#/reference_info_json) page for more details.
These files exist at various levels in QMK and all files of the same type are combined to build the final configuration. The levels, from lowest priority to highest priority, are:
* QMK Default
* Keyboard
@@ -39,11 +49,11 @@ This is a C header file that is one of the first things included, and will persi
* defines your VID, and for most DIY projects, can be whatever you want
*`#define PRODUCT_ID 0x5678`
* defines your PID, and for most DIY projects, can be whatever you want
*`#define DEVICE_VER 0`
*`#define DEVICE_VER 0x0100`
* defines the device version (often used for revisions)
*`#define MANUFACTURER Me`
*`#define MANUFACTURER "Me"`
* generally who/whatever brand produced the board
*`#define PRODUCT Board`
*`#define PRODUCT "Board"`
* the name of the keyboard
*`#define MATRIX_ROWS 5`
* the number of rows in your keyboard's matrix
@@ -57,8 +67,6 @@ This is a C header file that is one of the first things included, and will persi
* may be omitted by the keyboard designer if matrix reads are handled in an alternate manner. See [low-level matrix overrides](custom_quantum_functions.md?id=low-level-matrix-overrides) for more information.
*`#define MATRIX_IO_DELAY 30`
* the delay in microseconds when between changing matrix pin state and reading values
*`#define UNUSED_PINS { D1, D2, D3, B1, B2, B3 }`
* pins unused by the keyboard for reference
*`#define MATRIX_HAS_GHOST`
* define is matrix has ghost (unlikely)
*`#define MATRIX_UNSELECT_DRIVE_HIGH`
@@ -107,8 +115,10 @@ This is a C header file that is one of the first things included, and will persi
* sets the maximum power (in mA) over USB for the device (default: 500)
*`#define USB_POLLING_INTERVAL_MS 10`
* sets the USB polling rate in milliseconds for the keyboard, mouse, and shared (NKRO/media keys) interfaces
*`#define USB_SUSPEND_WAKEUP_DELAY 200`
* set the number of milliseconde to pause after sending a wakeup packet
*`#define USB_SUSPEND_WAKEUP_DELAY 0`
* sets the number of milliseconds to pause after sending a wakeup packet.
Disabled by default, you might want to set this to 200 (or higher) if the
keyboard does not wake up properly after suspending.
*`#define F_SCL 100000L`
* sets the I2C clock rate speed for keyboards using I2C. The default is `400000L`, except for keyboards using `split_common`, where the default is `100000L`.
@@ -180,23 +190,14 @@ If you define these options you will enable the associated feature, which may in
* how long before oneshot times out
*`#define ONESHOT_TAP_TOGGLE 2`
* how many taps before oneshot toggle is triggered
*`#define QMK_KEYS_PER_SCAN 4`
* Allows sending more than one key per scan. By default, only one key event gets
sent via `process_record()` per scan. This has little impact on most typing, but
if you're doing a lot of chords, or your scan rate is slow to begin with, you can
have some delay in processing key events. Each press and release is a separate
event. For a keyboard with 1ms or so scan times, even a very fast typist isn't
going to produce the 500 keystrokes a second needed to actually get more than a
few ms of delay from this. But if you're doing chording on something with 3-4ms
scan times? You probably want this.
*`#define COMBO_COUNT 2`
* Set this to the number of combos that you're using in the [Combo](feature_combo.md) feature. Or leave it undefined and programmatically set the count.
*`#define COMBO_TERM 200`
* how long for the Combo keys to be detected. Defaults to `TAPPING_TERM` if not defined.
*`#define COMBO_MUST_HOLD_MODS`
* Flag for enabling extending timeout on Combos containing modifers
* Flag for enabling extending timeout on Combos containing modifiers
*`#define COMBO_MOD_TERM 200`
* Allows for extending COMBO_TERM for mod keys while mid-combo.
* Allows for extending COMBO_TERM for mod keys while mid-combo.
*`#define COMBO_MUST_HOLD_PER_COMBO`
* Flag to enable per-combo COMBO_TERM extension and `get_combo_must_hold()` function
*`#define COMBO_TERM_PER_COMBO`
@@ -206,7 +207,7 @@ If you define these options you will enable the associated feature, which may in
*`#define COMBO_NO_TIMER`
* Disable the combo timer completely for relaxed combos.
*`#define TAP_CODE_DELAY 100`
* Sets the delay between `register_code` and `unregister_code`, if you're having issues with it registering properly (common on VUSB boards). The value is in milliseconds.
* Sets the delay between `register_code` and `unregister_code`, if you're having issues with it registering properly (common on VUSB boards). The value is in milliseconds and defaults to `0`.
*`#define TAP_HOLD_CAPS_DELAY 80`
* Sets the delay for Tap Hold keys (`LT`, `MT`) when using `KC_CAPS_LOCK` keycode, as this has some special handling on MacOS. The value is in milliseconds, and defaults to 80 ms if not defined. For macOS, you may want to set this to 200 or higher.
*`#define KEY_OVERRIDE_REPEAT_DELAY 500`
@@ -216,14 +217,12 @@ If you define these options you will enable the associated feature, which may in
*`#define RGB_DI_PIN D7`
* pin the DI on the WS2812 is hooked-up to
*`#define RGBLIGHT_ANIMATIONS`
* run RGB animations
*`#define RGBLIGHT_LAYERS`
* Lets you define [lighting layers](feature_rgblight.md?id=lighting-layers) that can be toggled on or off. Great for showing the current keyboard layer or caps lock state.
*`#define RGBLIGHT_MAX_LAYERS`
* Defaults to 8. Can be expanded up to 32 if more [lighting layers](feature_rgblight.md?id=lighting-layers) are needed.
* Note: Increasing the maximum will increase the firmware size and slow sync on split keyboards.
*`#define RGBLIGHT_LAYER_BLINK`
*`#define RGBLIGHT_LAYER_BLINK`
* Adds ability to [blink](feature_rgblight.md?id=lighting-layer-blink) a lighting layer for a specified number of milliseconds (e.g. to acknowledge an action).
*`#define RGBLIGHT_LAYERS_OVERRIDE_RGB_OFF`
* If defined, then [lighting layers](feature_rgblight?id=overriding-rgb-lighting-onoff-status) will be shown even if RGB Light is off.
@@ -326,6 +325,13 @@ There are a few different ways to set handedness for split keyboards (listed in
*`#define SPLIT_USB_TIMEOUT_POLL 10`
* Poll frequency when detecting master/slave when using `SPLIT_USB_DETECT`
*`#define SPLIT_WATCHDOG_ENABLE`
* Reboot slave if no communication from master within timeout.
* Helps resolve issue where both sides detect as slave using `SPLIT_USB_DETECT`
*`#define SPLIT_WATCHDOG_TIMEOUT 3000`
* Maximum slave timeout when waiting for communication from master when using `SPLIT_WATCHDOG_ENABLE`
*`#define FORCED_SYNC_THROTTLE_MS 100`
* Deadline for synchronizing data from master to slave when using the QMK-provided split transport.
@@ -368,8 +374,8 @@ This is a [make](https://www.gnu.org/software/make/manual/make.html) file that i
*`SRC`
* Used to add files to the compilation/linking list.
*`LIB_SRC`
* Used to add files as a library to the compilation/linking list.
The files specified by `LIB_SRC` is linked after the files specified by `SRC`.
* Used to add files as a library to the compilation/linking list.
The files specified by `LIB_SRC` is linked after the files specified by `SRC`.
For example, if you specify:
```
SRC += a.c
@@ -422,7 +428,7 @@ Use these to enable or disable building certain features. The more you have enab
* `NKRO_ENABLE`
* USB N-Key Rollover - if this doesn't work, see here: https://github.com/tmk/tmk_keyboard/wiki/FAQ#nkro-doesnt-work
* `RING_BUFFERED_6KRO_REPORT_ENABLE`
* USB 6-Key Rollover - Instead of stopping any new input once 6 keys are pressed, the oldest key is released and the new key is pressed.
* USB 6-Key Rollover - Instead of stopping any new input once 6 keys are pressed, the oldest key is released and the new key is pressed.
The `state` is the bitmask of the active layers, as explained in the [Keymap Overview](keymap.md#keymap-layer-status)
# Persistent Configuration (EEPROM)
This allows you to configure persistent settings for your keyboard. These settings are stored in the EEPROM of your controller, and are retained even after power loss. The settings can be read with `eeconfig_read_kb` and `eeconfig_read_user`, and can be written to using `eeconfig_update_kb` and `eeconfig_update_user`. This is useful for features that you want to be able to toggle (like toggling rgb layer indication). Additionally, you can use `eeconfig_init_kb` and `eeconfig_init_user` to set the default values for the EEPROM.
The complicated part here, is that there are a bunch of ways that you can store and access data via EEPROM, and there is no "correct" way to do this. However, you only have a DWORD (4 bytes) for each function.
Keep in mind that EEPROM has a limited number of writes. While this is very high, it's not the only thing writing to the EEPROM, and if you write too often, you can potentially drastically shorten the life of your MCU.
* If you don't understand the example, then you may want to avoid using this feature, as it is rather complicated.
### Example Implementation
This is an example of how to add settings, and read and write it. We're using the user keymap for the example here. This is a complex function, and has a lot going on. In fact, it uses a lot of the above functions to work!
In your keymap.c file, add this to the top:
```c
typedefunion{
uint32_traw;
struct{
boolrgb_layer_change:1;
};
}user_config_t;
user_config_tuser_config;
```
This sets up a 32 bit structure that we can store settings with in memory, and write to the EEPROM. Using this removes the need to define variables, since they're defined in this structure. Remember that `bool` (boolean) values use 1 bit, `uint8_t` uses 8 bits, `uint16_t` uses up 16 bits. You can mix and match, but changing the order can cause issues, as it will change the values that are read and written.
We're using `rgb_layer_change`, for the `layer_state_set_*` function, and use `keyboard_post_init_user` and `process_record_user` to configure everything.
Now, using the `keyboard_post_init_user` code above, you want to add `eeconfig_read_user()` to it, to populate the structure you've just created. And you can then immediately use this structure to control functionality in your keymap. And It should look like:
```c
voidkeyboard_post_init_user(void){
// Call the keymap level matrix init.
// Read the user config from EEPROM
user_config.raw=eeconfig_read_user();
// Set default layer, if enabled
if(user_config.rgb_layer_change){
rgblight_enable_noeeprom();
rgblight_sethsv_noeeprom_cyan();
rgblight_mode_noeeprom(1);
}
}
```
The above function will use the EEPROM config immediately after reading it, to set the default layer's RGB color. The "raw" value of it is converted in a usable structure based on the "union" that you created above.
This will cause the RGB underglow to be changed ONLY if the value was enabled. Now to configure this value, create a new keycode for `process_record_user` called `RGB_LYR`. Additionally, we want to make sure that if you use the normal RGB codes, that it turns off Using the example above, make it look this:
returnfalse;// Skip all further processing of this key
caseKC_ENTER:
// Play a tone when enter is pressed
if(record->event.pressed){
PLAY_SONG(tone_qwerty);
}
returntrue;// Let QMK send the enter press/release events
caseRGB_LYR:// This allows me to use underglow as layer indication, or as normal
if(record->event.pressed){
user_config.rgb_layer_change^=1;// Toggles the status
eeconfig_update_user(user_config.raw);// Writes the new status to EEPROM
if(user_config.rgb_layer_change){// if layer state indication is enabled,
layer_state_set(layer_state);// then immediately update the layer color
}
}
returnfalse;
caseRGB_MODE_FORWARD...RGB_MODE_GRADIENT:// For any of the RGB codes (see quantum_keycodes.h, L400 for reference)
if(record->event.pressed){//This disables layer indication, as it's assumed that if you're changing this ... you want that disabled
if(user_config.rgb_layer_change){// only if this is enabled
user_config.rgb_layer_change=false;// disable it, and
eeconfig_update_user(user_config.raw);// write the setings to EEPROM
}
}
returntrue;break;
default:
returntrue;// Process all other keycodes normally
}
}
```
And lastly, you want to add the `eeconfig_init_user` function, so that when the EEPROM is reset, you can specify default values, and even custom actions. To force an EEPROM reset, use the `EEP_RST` keycode or [Bootmagic Lite](feature_bootmagic.md) functionallity. For example, if you want to set rgb layer indication by default, and save the default valued.
```c
voideeconfig_init_user(void){// EEPROM is getting reset!
user_config.raw=0;
user_config.rgb_layer_change=true;// We want this enabled by default
eeconfig_update_user(user_config.raw);// Write default value to EEPROM now
// use the non noeeprom versions, to write these values to EEPROM too
rgblight_enable();// Enable RGB by default
rgblight_sethsv_cyan();// Set it to CYAN by default
rgblight_mode(1);// set to solid by default
}
```
And you're done. The RGB layer indication will only work if you want it to. And it will be saved, even after unplugging the board. And if you use any of the RGB codes, it will disable the layer indication, so that it stays on the mode and color that you set it to.
### 'EECONFIG' Function Documentation
* Keyboard/Revision: `void eeconfig_init_kb(void)`, `uint32_t eeconfig_read_kb(void)` and `void eeconfig_update_kb(uint32_t val)`
* Keymap: `void eeconfig_init_user(void)`, `uint32_t eeconfig_read_user(void)` and `void eeconfig_update_user(uint32_t val)`
The `val` is the value of the data that you want to write to EEPROM. And the `eeconfig_read_*` function return a 32 bit (DWORD) value from the EEPROM.
### Deferred Execution :id=deferred-execution
# Deferred Execution :id=deferred-execution
QMK has the ability to execute a callback after a specified period of time, rather than having to manually manage timers. To enable this functionality, set `DEFERRED_EXEC_ENABLE = yes` in rules.mk.
#### Deferred executor callbacks
## Deferred executor callbacks
All _deferred executor callbacks_ have a common function signature and look like:
@@ -430,7 +251,7 @@ The return value is the number of milliseconds to use if the function should be
?> Note that the returned delay will be applied to the intended trigger time, not the time of callback invocation. This allows for generally consistent timing even in the face of occasional late execution.
#### Deferred executor registration
## Deferred executor registration
Once a callback has been defined, it can be scheduled using the following API:
@@ -444,7 +265,7 @@ The third parameter is the `cb_arg` that gets passed to the callback at the poin
The return value is a `deferred_token` that can consequently be used to cancel the deferred executor callback before it's invoked. If a failure occurs, the returned value will be `INVALID_DEFERRED_TOKEN`. Usually this will be as a result of supplying `0` to the delay, or a `NULL` for the callback. The other failure case is if there are too many deferred executions "in flight" -- this can be increased by changing the limit, described below.
#### Extending a deferred execution
## Extending a deferred execution
The `deferred_token` returned by `defer_exec()` can be used to extend a the duration a pending execution waits before it gets invoked:
```c
@@ -452,7 +273,7 @@ The `deferred_token` returned by `defer_exec()` can be used to extend a the dura
extend_deferred_exec(my_token,800);
```
#### Cancelling a deferred execution
## Cancelling a deferred execution
The `deferred_token` returned by `defer_exec()` can be used to cancel a pending execution before it gets invoked:
Once a token has been canceled, it should be considered invalid. Reusing the same token is not supported.
#### Deferred callback limits
## Deferred callback limits
There are a maximum number of deferred callbacks that can be scheduled, controlled by the value of the define `MAX_DEFERRED_EXECUTORS`.
@@ -471,3 +292,15 @@ If registrations fail, then you can increase this value in your keyboard or keym
```c
#define MAX_DEFERRED_EXECUTORS 16
```
# Advanced topics :id=advanced-topics
This page used to encompass a large set of features. We have moved many sections that used to be part of this page to their own pages. Everything below this point is simply a redirect so that people following old links on the web find what they're looking for.
@@ -22,7 +22,7 @@ You will then need to add support for your new configuration to `info.json`. The
1. Add it to the schema in `data/schemas/keyboards.jsonschema`
1. Add a mapping in `data/maps`
1. (optional and discoraged) Add code to extract/generate it to:
1. (optional and discouraged) Add code to extract/generate it to:
*`lib/python/qmk/info.py`
*`lib/python/qmk/cli/generate/config_h.py`
*`lib/python/qmk/cli/generate/rules_mk.py`
@@ -41,7 +41,7 @@ In other cases you should group like options together in an `object`. This is pa
### Add a mapping
In most cases you can add a simple mapping. These are maintained as JSON files in `data/mappings/info_config.json` and `data/mappings/info_rules.json`, and control mapping for `config.h` and `rules.mk`, respectively. Each mapping is keyed by the `config.h` or `rules.mk` variable, and the value is a hash with the following keys:
In most cases you can add a simple mapping. These are maintained as JSON files in `data/mappings/info_config.hjson` and `data/mappings/info_rules.hjson`, and control mapping for `config.h` and `rules.mk`, respectively. Each mapping is keyed by the `config.h` or `rules.mk` variable, and the value is a hash with the following keys:
*`info_key`: (required) The location within `info.json` for this value. See below.
*`value_type`: (optional) Default `raw`. The format for this variable's value. See below.
Most keymaps have an image depicting the layout. You can use [Keyboard Layout Editor](https://keyboard-layout-editor.com) to create an image. Upload it to [Imgur](https://imgur.com) or another hosting service, please do not include images in your Pull Request.
Most keymaps have an image depicting the layout. You can use [Keyboard Layout Editor](http://keyboard-layout-editor.com) to create an image. Upload it to [Imgur](https://imgur.com) or another hosting service, please do not include images in your Pull Request.
Below the image you should write a short description to help people understand your keymap.
@@ -8,7 +8,7 @@ We recommend the use of the [Zadig](https://zadig.akeo.ie/) utility. If you have
## Installation
Put your keyboard into bootloader mode, either by hitting the `RESET` keycode (which may be on a different layer), or by pressing the reset switch that's usually located on the underside of the board. If your keyboard has neither, try holding Escape or Space+`B` as you plug it in (see the [Bootmagic Lite](feature_bootmagic.md) docs for more details). Some boards use [Command](feature_command.md) instead of Bootmagic; in this case, you can enter bootloader mode by hitting Left Shift+Right Shift+`B` or Left Shift+Right Shift+Escape at any point while the keyboard is plugged in.
Put your keyboard into bootloader mode, either by hitting the `QK_BOOT` keycode (which may be on a different layer), or by pressing the reset switch that's usually located on the underside of the board. If your keyboard has neither, try holding Escape or Space+`B` as you plug it in (see the [Bootmagic Lite](feature_bootmagic.md) docs for more details). Some boards use [Command](feature_command.md) instead of Bootmagic; in this case, you can enter bootloader mode by hitting Left Shift+Right Shift+`B` or Left Shift+Right Shift+Escape at any point while the keyboard is plugged in.
Some keyboards may have specific instructions for entering the bootloader. For example, the [Bootmagic Lite](feature_bootmagic.md) key (default: Escape) might be on a different key, e.g. Left Control; or the magic combination for Command (default: Left Shift+Right Shift) might require you to hold something else, e.g. Left Control+Right Control. Refer to the board's README file if you are unsure.
To put a device in bootloader mode with USBaspLoader, tap the `RESET` button while holding down the `BOOT` button.
@@ -4,7 +4,7 @@ This page details various common questions people have about troubleshooting the
## Debugging :id=debugging
Your keyboard will output debug information if you have `CONSOLE_ENABLE = yes` in your `rules.mk`. By default the output is very limited, but you can turn on debug mode to increase the amount of debug output. Use the `DEBUG` keycode in your keymap, use the [Command](feature_command.md) feature to enable debug mode, or add the following code to your keymap.
Your keyboard will output debug information if you have `CONSOLE_ENABLE = yes` in your `rules.mk`. By default the output is very limited, but you can turn on debug mode to increase the amount of debug output. Use the `DB_TOGG` keycode in your keymap, use the [Command](feature_command.md) feature to enable debug mode, or add the following code to your keymap.
```c
voidkeyboard_post_init_user(void){
@@ -59,7 +59,7 @@ When porting, or when attempting to diagnose pcb issues, it can be useful to kno
This page used to encompass a large set of features. We have moved many sections that used to be part of this page to their own pages. Everything below this point is simply a redirect so that people following old links on the web find what they're looking for.
|`QK_AUDIO_OFF` |`AU_OFF` |Turns off Audio Feature |
|`QK_AUDIO_TOGGLE` |`AU_TOGG`|Toggles Audio state |
!> These keycodes turn all of the audio functionality on and off. Turning it off means that audio feedback, audio clicky, music mode, etc. are disabled, completely.
@@ -177,7 +179,7 @@ The available keycodes for audio are:
|`AUDIO_INIT_DELAY` | *Not defined* |Enables delay during startup song to accomidate for USB startup issues. |
|`AUDIO_ENABLE_TONE_MULTIPLEXING` | *Not defined* |Enables time splicing/multiplexing to create multiple tones simutaneously. |
|`STARTUP_SONG` | `STARTUP_SOUND` |Plays when the keyboard starts up (audio.c) |
|`GOODBYE_SONG` | `GOODBYE_SOUND` |Plays when you press the RESET key (quantum.c) |
|`GOODBYE_SONG` | `GOODBYE_SOUND` |Plays when you press the QK_BOOT key (quantum.c) |
|`AG_NORM_SONG` | `AG_NORM_SOUND` |Plays when you press AG_NORM (process_magic.c) |
|`AG_SWAP_SONG` | `AG_SWAP_SOUND` |Plays when you press AG_SWAP (process_magic.c) |
|`CG_NORM_SONG` | `AG_NORM_SOUND` |Plays when you press CG_NORM (process_magic.c) |
@@ -219,6 +221,12 @@ Aka "audio effects", different ones can be enabled by setting in `config.h` thes
`#define AUDIO_VOICES` to enable the feature, and `#define AUDIO_VOICE_DEFAULT something` to select a specific effect
|`QK_MUSIC_TOGGLE` |`MU_TOGG`|Toggles Music Mode |
|`QK_MUSIC_MODE_NEXT` |`MU_NEXT`|Cycles through the music modes |
Available Modes:
*`CHROMATIC_MODE` - Chromatic scale, row changes the octave
*`GUITAR_MODE` - Chromatic scale, but the row changes the string (+5 st)
*`VIOLIN_MODE` - Chromatic scale, but the row changes the string (+7 st)
@@ -300,13 +312,16 @@ You can look at the [Planck Keyboard](https://github.com/qmk/qmk_firmware/blob/e
This adds a click sound each time you hit a button, to simulate click sounds from the keyboard. And the sounds are slightly different for each keypress, so it doesn't sound like a single long note, if you type rapidly.
*`CK_TOGG` - Toggles the status (will play sound if enabled)
*`CK_ON` - Turns on Audio Click (plays sound)
*`CK_OFF` - Turns off Audio Click (doesn't play sound)
*`CK_RST` - Resets the frequency to the default state (plays sound at default frequency)
*`CK_UP` - Increases the frequency of the clicks (plays sound at new frequency)
*`CK_DOWN` - Decreases the frequency of the clicks (plays sound at new frequency)
There are a lot of words that are prone to being typed incorrectly, due to habit, sequence or just user error. This feature leverages your firmware to automatically correct these errors, to help reduce typos.
## How does it work? :id=how-does-it-work
The feature maintains a small buffer of recent key presses. On each key press, it checks whether the buffer ends in a recognized typo, and if so, automatically sends keystrokes to correct it.
The tricky part is how to efficiently check the buffer for typos. We don’t want to spend too much memory or time on storing or searching the typos. A good solution is to represent the typos with a trie data structure. A trie is a tree data structure where each node is a letter, and words are formed by following a path to one of the leaves.

Since we search whether the buffer ends in a typo, we store the trie writing in reverse. The trie is queried starting from the last letter, then second to last letter, and so on, until either a letter doesn’t match or we reach a leaf, meaning a typo was found.
## How do I enable Autocorrection :id=how-do-i-enable-autocorrection
In your `rules.mk`, add this:
```make
AUTOCORRECT_ENABLE= yes
```
Additionally, you will need a library for autocorrection. A small sample library is included by default, so that you can get up and running right away, but you can provide a customized library.
By default, autocorrect is disabled. To enable it, you need to use the `AC_TOGG` keycode to enable it. The status is stored in persistent memory, so you shouldn't need to enabled it again.
To provide a custom library, you need to create a text file with the corrections. For instance:
```text
:thier -> their
fitler -> filter
lenght -> length
ouput -> output
widht -> width
```
The syntax is `typo -> correction`. Typos and corrections are case insensitive, and any whitespace before or after the typo and correction is ignored. The typo must be only the letters a–z, or the special character : representing a word break. The correction may have any non-unicode characters.
This will process the file and produce an `autocorrect_data.h` file with the trie library, in the folder that you are at. You can specify the keyboard and keymap (eg `-kb planck/rev6 -km jackhumbert`), and it will place the file in that folder instead. But as long as the file is located in your keymap folder, or user folder, it should be picked up automatically.
By default, typos are searched within words, to find typos within longer identifiers like maxFitlerOuput. While this is useful, a consequence is that autocorrection will falsely trigger when a typo happens to be a substring of a correctly-spelled word. For instance, if we had thier -> their as an entry, it would falsely trigger on (correct, though relatively uncommon) words like “wealthier” and “filthier.”
The solution is to set a word break : before and/or after the typo to constrain matching. : matches space, period, comma, underscore, digits, and most other non-alpha characters.
:thier: is most restrictive, matching only when thier is a whole word.
The `qmk generate-autocorrect-data` commands can make an effort to check for entries that would false trigger as substrings of correct words. It searches each typo against a dictionary of 25K English words from the english_words Python package, provided it’s installed. (run `python3 -m pip install english_words` to install it.)
?> Unfortunately, this is limited to just english words, at this point.
## Overriding Autocorrect
Occasionally you might actually want to type a typo (for instance, while editing autocorrection_dict.txt) without being autocorrected. There are a couple of ways to do this:
1. Begin typing the typo.
2. Before typing the last letter, press and release the Ctrl or Alt key.
3. Type the remaining letters.
This works because the autocorrection implementation doesn’t understand hotkeys, so it resets itself whenever a modifier other than shift is held.
Additionally, you can use the `AC_TOGG` keycode to toggle the on/off status for Autocorrect.
|`QK_AUTOCORRECT_ON` |`AC_ON` |Turns on the Autocorrect feature. |
|`QK_AUTOCORRECT_OFF` |`AC_OFF` |Turns off the Autocorrect feature. |
|`QK_AUTOCORRECT_TOGGLE`|`AC_TOGG`|Toggles the status of the Autocorrect feature.|
## User Callback Functions
### Process Autocorrect
Callback function `bool process_autocorrect_user(uint16_t *keycode, keyrecord_t *record, uint8_t *typo_buffer_size, uint8_t *mods)` is available to customise incoming keycodes and handle exceptions. You can use this function to sanitise input before they are passed onto the autocorrect engine
?> Sanitisation of input is required because autocorrect will only match 8-bit [basic keycodes](keycodes_basic.md) for typos. If valid modifier keys or 16-bit keycodes that are part of a user's word input (such as Shift + A) is passed through, they will fail typo letter detection. For example a [Mod-Tap](mod_tap.md) key such as `LCTL_T(KC_A)` is 16-bit and should be masked for the 8-bit `KC_A`.
The default user callback function is found inside `quantum/process_keycode/process_autocorrect.c`. It covers most use-cases for QMK special functions and quantum keycodes, including [overriding autocorrect](#overriding-autocorrect) with a modifier other than shift. The `process_autocorrect_user` function is `weak` defined to allow user's copy inside `keymap.c` (or code files) to overwrite it.
#### Process Autocorrect Example
If you have a custom keycode `QMKBEST` that should be ignored as part of a word, and another custom keycode `QMKLAYER` that should override autocorrect, both can be added to the bottom of the `process_autocorrect_user``switch` statement in your source code:
// See quantum_keycodes.h for reference on these matched ranges.
switch(*keycode){
// Exclude these keycodes from processing.
caseKC_LSFT:
caseKC_RSFT:
caseKC_CAPS:
caseQK_TO...QK_ONE_SHOT_LAYER_MAX:
caseQK_LAYER_TAP_TOGGLE...QK_LAYER_MOD_MAX:
caseQK_ONE_SHOT_MOD...QK_ONE_SHOT_MOD_MAX:
returnfalse;
// Mask for base keycode from shifted keys.
caseQK_LSFT...QK_LSFT+255:
caseQK_RSFT...QK_RSFT+255:
if(*keycode>=QK_LSFT&&*keycode<=(QK_LSFT+255)){
*mods|=MOD_LSFT;
}else{
*mods|=MOD_RSFT;
}
*keycode&=0xFF;// Get the basic keycode.
returntrue;
#ifndef NO_ACTION_TAPPING
// Exclude tap-hold keys when they are held down
// and mask for base keycode when they are tapped.
caseQK_LAYER_TAP...QK_LAYER_TAP_MAX:
# ifdef NO_ACTION_LAYER
// Exclude Layer Tap, if layers are disabled
// but action tapping is still enabled.
returnfalse;
# endif
caseQK_MOD_TAP...QK_MOD_TAP_MAX:
// Exclude hold if mods other than Shift is not active
if(!record->tap.count){
returnfalse;
}
*keycode&=0xFF;
break;
#else
caseQK_MOD_TAP...QK_MOD_TAP_MAX:
caseQK_LAYER_TAP...QK_LAYER_TAP_MAX:
// Exclude if disabled
returnfalse;
#endif
// Exclude swap hands keys when they are held down
// and mask for base keycode when they are tapped.
caseQK_SWAP_HANDS...QK_SWAP_HANDS_MAX:
#ifdef SWAP_HANDS_ENABLE
if(*keycode>=0x56F0||!record->tap.count){
returnfalse;
}
*keycode&=0xFF;
break;
#else
// Exclude if disabled
returnfalse;
#endif
// Handle custom keycodes
caseQMKBEST:
returnfalse;
caseQMKLAYER:
*typo_buffer_size=0;
returnfalse;
}
// Disable autocorrect while a mod other than shift is active.
if((*mods&~MOD_MASK_SHIFT)!=0){
*typo_buffer_size=0;
returnfalse;
}
returntrue;
}
```
?> In this callback function, `return false` will skip processing of that keycode for autocorrect. Adding `*typo_buffer_size = 0` will also reset the autocorrect buffer at the same time, cancelling any current letters already stored in the buffer.
### Apply Autocorrect
Additionally, `apply_autocorrect(uint8_t backspaces, const char *str)` allows for users to add additional handling to the autocorrection, or replace the functionality entirely. This passes on the number of backspaces needed to replace the words, as well as the replacement string (partial word, not the full word).
#### Apply Autocorrect Example
This following example will play a sound when a typo is autocorrected and execute the autocorrection itself:
?> In this callback function, `return false` will stop the normal processing of autocorrect, which requires manually handling of removing the "bad" characters and typing the new characters.
!> ***IMPORTANT***: `str` is a pointer to `PROGMEM` data for the autocorrection. If you return false, and want to send the string, this needs to use `send_string_P` and not `send_string` or `SEND_STRING`.
You can also use `apply_autocorrect` to detect and display the event but allow internal code to execute the autocorrection with `return true`:
This section details how the trie is serialized to byte data in autocorrection_data. You don’t need to care about this to use this autocorrection implementation. But it is documented for the record in case anyone is interested in modifying the implementation, or just curious how it works.
What I did here is fairly arbitrary, but it is simple to decode and gets the job done.
### Encoding :id=encoding
All autocorrection data is stored in a single flat array autocorrection_data. Each trie node is associated with a byte offset into this array, where data for that node is encoded, beginning with root at offset 0. There are three kinds of nodes. The highest two bits of the first byte of the node indicate what kind:
* 00 ⇒ chain node: a trie node with a single child.
* 01 ⇒ branching node: a trie node with multiple children.
* 10 ⇒ leaf node: a leaf, corresponding to a typo and storing its correction.

**Branching node**. Each branch is encoded with one byte for the keycode (KC_A–KC_Z) followed by a link to the child node. Links between nodes are 16-bit byte offsets relative to the beginning of the array, serialized in little endian order.
All branches are serialized this way, one after another, and terminated with a zero byte. As described above, the node is identified as a branch by setting the two high bits of the first byte to 01, done by bitwise ORing the first keycode with 64. keycode. The root node for the above figure would be serialized like:
**Chain node**. Tries tend to have long chains of single-child nodes, as seen in the example above with f-i-t-l in fitler. So to save space, we use a different format to encode chains than branching nodes. A chain is encoded as a string of keycodes, beginning with the node closest to the root, and terminated with a zero byte. The child of the last node in the chain is encoded immediately after. That child could be either a branching node or a leaf.
In the figure above, the f-i-t-l chain is encoded as
```
+-------+-------+-------+-------+-------+
| L | T | I | F | 0 |
+-------+-------+-------+-------+-------+
```
If we were to encode this chain using the same format used for branching nodes, we would encode a 16-bit node link with every node, costing 8 more bytes in this example. Across the whole trie, this adds up. Conveniently, we can point to intermediate points in the chain and interpret the bytes in the same way as before. E.g. starting at the i instead of the l, and the subchain has the same format.
**Leaf node**. A leaf node corresponds to a particular typo and stores data to correct the typo. The leaf begins with a byte for the number of backspaces to type, and is followed by a null-terminated ASCII string of the replacement text. The idea is, after tapping backspace the indicated number of times, we can simply pass this string to the `send_string_P` function. For fitler, we need to tap backspace 3 times (not 4, because we catch the typo as the final ‘r’ is pressed) and replace it with lter. To identify the node as a leaf, the two high bits are set to 10 by ORing the backspace count with 128:
```
+-------+-------+-------+-------+-------+-------+
| 3|128 | 'l' | 't' | 'e' | 'r' | 0 |
+-------+-------+-------+-------+-------+-------+
```
### Decoding :id=decoding
This format is by design decodable with fairly simple logic. A 16-bit variable state represents our current position in the trie, initialized with 0 to start at the root node. Then, for each keycode, test the highest two bits in the byte at state to identify the kind of node.
* 00 ⇒ **chain node**: If the node’s byte matches the keycode, increment state by one to go to the next byte. If the next byte is zero, increment again to go to the following node.
* 01 ⇒ **branching node**: Search the branches for one that matches the keycode, and follow its node link.
* 10 ⇒ **leaf node**: a typo has been found! We read its first byte for the number of backspaces to type, then pass its following bytes to send_string_P to type the correction.
## Credits
Credit goes to [getreuer](https://github.com/getreuer) for originally implementing this [here](https://getreuer.info/posts/keyboards/autocorrection/#how-does-it-work). As well as to [filterpaper](https://github.com/filterpaper) for converting the code to use PROGMEM, and additional improvements.
@@ -39,8 +39,8 @@ BLUETOOTH_DRIVER = BluefruitLE # or RN42
This is used when multiple keyboard outputs can be selected. Currently this only allows for switching between USB and Bluetooth on keyboards that support both.
@@ -105,11 +105,11 @@ It is worth noting that `COMBO_ACTION`s are not needed anymore. As of [PR#8591](
## Keycodes
You can enable, disable and toggle the Combo feature on the fly. This is useful if you need to disable them temporarily, such as for a game. The following keycodes are available for use in your `keymap.c`
If you leave `COMBO_COUNT` undefined in `config.h`, it allows you to programmatically declare the size of the Combo data structure and avoid updating `COMBO_COUNT`. Instead a variable called `COMBO_LEN` has to be set. It can be set with something similar to the following in `keymap.c`: `uint16_t COMBO_LEN = sizeof(key_combos) / sizeof(key_combos[0]);` or by adding `COMBO_LENGTH` as the *last* entry in the combo enum and then `uint16_t COMBO_LEN = COMBO_LENGTH;` as such:
If you leave `COMBO_COUNT` undefined in `config.h`, it allows you to programmatically declare the size of the Combo data structure and avoid updating `COMBO_COUNT`. Instead a variable called `COMBO_LEN` has to be set. It can be set with something similar to the following in `keymap.c`: `uint16_t COMBO_LEN = ARRAY_SIZE(key_combos);` or by adding `COMBO_LENGTH` as the *last* entry in the combo enum and then `uint16_t COMBO_LEN = COMBO_LENGTH;` as such:
If you, for example, use multiple base layers for different key layouts, one for QWERTY, and another one for Colemak, you might want your combos to work from the same key positions on all layers. Defining the same combos again for another layout is redundant and takes more memory. The solution is to just check the keycodes from one layer.
With `#define COMBO_ONLY_FROM_LAYER _LAYER_A` the combos' keys are always checked from layer `_LAYER_A` even though the active layer would be `_LAYER_B`.
With `#define COMBO_ONLY_FROM_LAYER 0` in config.h, the combos' keys are always checked from layer `0`, even if other layers are active.
@@ -13,6 +13,13 @@ Currently the following converters are available:
| `promicro` | `proton_c` |
| `promicro` | `kb2040` |
| `promicro` | `promicro_rp2040` |
| `promicro` | `blok` |
| `promicro` | `bit_c_pro` |
| `promicro` | `stemcell` |
| `promicro` | `bonsai_c4` |
| `promicro` | `elite_pi` |
| `elite_c` | `stemcell` |
| `elite_c` | `elite_pi` |
See below for more in depth information on each converter.
@@ -43,15 +50,37 @@ Once a converter is enabled, it exposes the `CONVERT_TO_<target_uppercase>` flag
#endif
```
### Pin Compatibility
To ensure compatibility, provide validation, and power future workflows, a keyboard should declare its `pin compatibility`. For legacy reasons, this is currently assumed to be `promicro`.
Currently the following pin compatibility interfaces are defined:
To declare the base for conversions, add this line to your keyboard's `rules.mk`:
```makefile
PIN_COMPATIBLE= elite_c
```
## Pro Micro
If a board currently supported in QMK uses a [Pro Micro](https://www.sparkfun.com/products/12640) (or compatible board), the supported alternative controllers are:
@@ -90,6 +124,59 @@ The following defaults are based on what has been implemented for [RP2040](platf
| USB Host (e.g. USB-USB converter) | Not supported (USB host code is AVR specific and is not currently supported on ARM) |
| [Split keyboards](feature_split_keyboard.md) | Partial via `PIO` vendor driver - heavily dependent on enabled features |
### SparkFun Pro Micro - RP2040 :id=promicro_rp2040
### SparkFun Pro Micro - RP2040, Blok, Bit-C PRO, and Elite-Pi :id=promicro_rp2040
Currently identical to [Adafruit KB2040](#kb2040).
Currently identical to [Adafruit KB2040](#kb2040).
### STeMCell :id=stemcell
Feature set currently identical to [Proton C](#proton_c).
There are two versions of STeMCell available, with different pinouts:
- v1.0.0
- v2.0.0 (pre-release v1.0.1, v1.0.2)
Default official firmware only supports v2.0.0 STeMCell.
STeMCell has support to swap UART and I2C pins, to enable single-wire uart communication in STM chips.
The following additional flags has to be used while compiling, based on the pin used for split communication.
| Split Pin | Compile flags |
|-----------|---------------|
| D3 | -e STMC_US=yes|
| D2 | Not needed |
| D1 | -e STMC_IS=yes|
| D0 | Not needed |
### Bonsai C4 :id=bonsai_c4
The Bonsai C4 only has one on-board LED (B2), and by default, both the Pro Micro TXLED (D5) and RXLED (B0) are mapped to it. If you want only one of them mapped, you can undefine one and redefine it to another pin by adding these line to your `config.h`:
```c
#undef B0
// If Vbus detection is unused, we can send RXLED to the Vbus detect pin instead
#define B0 PAL_LINE(GPIOA, 9)
```
## Elite-C
If a board currently supported in QMK uses an [Elite-C](https://keeb.io/products/elite-c-low-profile-version-usb-c-pro-micro-replacement-atmega32u4), the supported alternative controllers are:
The digitizer HID interface allows setting the mouse cursor position at absolute coordinates, unlike the Pointing Device feature that applies relative displacements.
Digitizers allow the mouse cursor to be placed at absolute coordinates, unlike the [Pointing Device](feature_pointing_device.md) feature which applies relative displacements.
To enable the digitizer interface, add the following line to your rules.mk:
This feature implements a stylus device with a tip switch and barrel switch (generally equivalent to the primary and secondary mouse buttons respectively). Tip pressure is not currently implemented.
## Usage :id=usage
Add the following to your `rules.mk`:
```make
DIGITIZER_ENABLE= yes
```
In order to change the mouse cursor position from your keymap.c file, include the digitizer header :
## Positioning :id=positioning
The X and Y coordinates are normalized, meaning their value must be set between 0 and 1. For the X component, the value `0` is the leftmost position, whereas the value `1` is the rightmost position. Similarly for the Y component, `0` is at the top and `1` at the bottom.
?> Since there is no display attached, the OS will likely map these coordinates to the virtual desktop. This may be important to know if you have multiple monitors.
## Examples :id=examples
This example simply places the cursor in the middle of the screen:
```c
#include"digitizer.h"
digitizer_in_range_on();
digitizer_set_position(0.5,0.5);
```
This gives you access to the `digitizer` structure which members allow you to change the cursor position.
The "in range" indicator is required to be on for the change in coordinates to be taken. It can then be turned off again to signal the end of the digitizer interaction, but it is not strictly required.
The coordinates are normalized, meaning there value must be set between 0 and 1. For the `x` coordinate, the value `0` is the leftmost position, whereas the value `1` is the rightmost position.
For the `y` coordinate, `0` is at the top and `1` at the bottom.
Here is an example setting the cursor in the middle of the screen:
You can also modify the digitizer state directly, if you need to change multiple fields in a single report:
```c
digitizer_tdigitizer;
digitizer.x=0.5;
digitizer.y=0.5;
digitizer.tipswitch=0;
digitizer.inrange=1;
digitizer_set_report(digitizer);
digitizer_state.in_range=true;
digitizer_state.dirty=true;
digitizer_flush();
```
The `tipswitch` member triggers what equates to a click when set to `1`. The `inrange` member is required for the change in coordinates to be taken. It can then be set to `0` in a new report to signal the end of the digitizer interaction, but it is not strictly required.
`digitizer_state` is a struct of type `digitizer_t`.
Once all members are set to the desired value, the `status` member needs its bitmask `DZ_UPDATED` to be set so the report is sent during the next main loop iteration.
## API :id=api
### `struct digitizer_t` :id=api-digitizer-t
Contains the state of the digitizer.
#### Members :id=api-digitizer-t-members
-`bool in_range`
Indicates to the host that the contact is within range (ie. close to or in contact with the digitizer surface).
-`bool tip`
The state of the tip switch.
-`bool barrel`
The state of the barrel switch.
-`float x`
The X coordinate of the digitizer contact.
-`float y`
The Y coordinate of the digitizer contact.
-`bool dirty`
Whether the current state needs to be sent to the host.
|`QK_DYNAMIC_MACRO_RECORD_STOP` |`DM_RSTP`|Finish the macro that is currently being recorded.|
That should be everything necessary.
To start recording the macro, press either `DYN_REC_START1` or `DYN_REC_START2`.
To start recording the macro, press either `DM_REC1` or `DM_REC2`.
To finish the recording, press the `DYN_REC_STOP` layer button. You can also press `DYN_REC_START1` or `DYN_REC_START2` again to stop the recording.
To finish the recording, press the `DM_RSTP` layer button. You can also press `DM_REC1` or `DM_REC2` again to stop the recording.
To replay the macro, press either `DYN_MACRO_PLAY1` or `DYN_MACRO_PLAY2`.
To replay the macro, press either `DM_PLY1` or `DM_PLY2`.
It is possible to replay a macro as part of a macro. It's ok to replay macro 2 while recording macro 1 and vice versa but never create recursive macros i.e. macro 1 that replays macro 1. If you do so and the keyboard will get unresponsive, unplug the keyboard and plug it again. You can disable this completely by defining `DYNAMIC_MACRO_NO_NESTING` in your `config.h` file.
@@ -43,10 +43,10 @@ If the LEDs start blinking during the recording with each keypress, it means the
### DYNAMIC_MACRO_USER_CALL
For users of the earlier versions of dynamic macros: It is still possible to finish the macro recording using just the layer modifier used to access the dynamic macro keys, without a dedicated `DYN_REC_STOP` key. If you want this behavior back, add `#define DYNAMIC_MACRO_USER_CALL` to your `config.h` and insert the following snippet at the beginning of your `process_record_user()` function:
For users of the earlier versions of dynamic macros: It is still possible to finish the macro recording using just the layer modifier used to access the dynamic macro keys, without a dedicated `DM_RSTP` key. If you want this behavior back, add `#define DYNAMIC_MACRO_USER_CALL` to your `config.h` and insert the following snippet at the beginning of your `process_record_user()` function:
This allows you to configure persistent settings for your keyboard. These settings are stored in the EEPROM of your controller, and are retained even after power loss. The settings can be read with `eeconfig_read_kb` and `eeconfig_read_user`, and can be written to using `eeconfig_update_kb` and `eeconfig_update_user`. This is useful for features that you want to be able to toggle (like toggling rgb layer indication). Additionally, you can use `eeconfig_init_kb` and `eeconfig_init_user` to set the default values for the EEPROM.
The complicated part here, is that there are a bunch of ways that you can store and access data via EEPROM, and there is no "correct" way to do this. However, you only have a DWORD (4 bytes) for each function.
Keep in mind that EEPROM has a limited number of writes. While this is very high, it's not the only thing writing to the EEPROM, and if you write too often, you can potentially drastically shorten the life of your MCU.
* If you don't understand the example, then you may want to avoid using this feature, as it is rather complicated.
## Example Implementation
This is an example of how to add settings, and read and write it. We're using the user keymap for the example here. This is a complex function, and has a lot going on. In fact, it uses a lot of the above functions to work!
In your keymap.c file, add this to the top:
```c
typedefunion{
uint32_traw;
struct{
boolrgb_layer_change:1;
};
}user_config_t;
user_config_tuser_config;
```
This sets up a 32 bit structure that we can store settings with in memory, and write to the EEPROM. Using this removes the need to define variables, since they're defined in this structure. Remember that `bool` (boolean) values use 1 bit, `uint8_t` uses 8 bits, `uint16_t` uses up 16 bits. You can mix and match, but changing the order can cause issues, as it will change the values that are read and written.
We're using `rgb_layer_change`, for the `layer_state_set_*` function, and use `keyboard_post_init_user` and `process_record_user` to configure everything.
Now, using the `keyboard_post_init_user` code above, you want to add `eeconfig_read_user()` to it, to populate the structure you've just created. And you can then immediately use this structure to control functionality in your keymap. And It should look like:
```c
voidkeyboard_post_init_user(void){
// Call the keymap level matrix init.
// Read the user config from EEPROM
user_config.raw=eeconfig_read_user();
// Set default layer, if enabled
if(user_config.rgb_layer_change){
rgblight_enable_noeeprom();
rgblight_sethsv_noeeprom(HSV_CYAN);
rgblight_mode_noeeprom(1);
}
}
```
The above function will use the EEPROM config immediately after reading it, to set the default layer's RGB color. The "raw" value of it is converted in a usable structure based on the "union" that you created above.
This will cause the RGB underglow to be changed ONLY if the value was enabled. Now to configure this value, create a new keycode for `process_record_user` called `RGB_LYR`. Additionally, we want to make sure that if you use the normal RGB codes, that it turns off Using the example above, make it look this:
returnfalse;// Skip all further processing of this key
caseKC_ENTER:
// Play a tone when enter is pressed
if(record->event.pressed){
PLAY_SONG(tone_qwerty);
}
returntrue;// Let QMK send the enter press/release events
caseRGB_LYR:// This allows me to use underglow as layer indication, or as normal
if(record->event.pressed){
user_config.rgb_layer_change^=1;// Toggles the status
eeconfig_update_user(user_config.raw);// Writes the new status to EEPROM
if(user_config.rgb_layer_change){// if layer state indication is enabled,
layer_state_set(layer_state);// then immediately update the layer color
}
}
returnfalse;
caseRGB_MODE_FORWARD...RGB_MODE_GRADIENT:// For any of the RGB codes (see quantum_keycodes.h, L400 for reference)
if(record->event.pressed){//This disables layer indication, as it's assumed that if you're changing this ... you want that disabled
if(user_config.rgb_layer_change){// only if this is enabled
user_config.rgb_layer_change=false;// disable it, and
eeconfig_update_user(user_config.raw);// write the setings to EEPROM
}
}
returntrue;break;
default:
returntrue;// Process all other keycodes normally
}
}
```
And lastly, you want to add the `eeconfig_init_user` function, so that when the EEPROM is reset, you can specify default values, and even custom actions. To force an EEPROM reset, use the `EE_CLR` keycode or [Bootmagic Lite](feature_bootmagic.md) functionallity. For example, if you want to set rgb layer indication by default, and save the default valued.
```c
voideeconfig_init_user(void){// EEPROM is getting reset!
user_config.raw=0;
user_config.rgb_layer_change=true;// We want this enabled by default
eeconfig_update_user(user_config.raw);// Write default value to EEPROM now
// use the non noeeprom versions, to write these values to EEPROM too
rgblight_enable();// Enable RGB by default
rgblight_sethsv(HSV_CYAN);// Set it to CYAN by default
rgblight_mode(1);// set to solid by default
}
```
And you're done. The RGB layer indication will only work if you want it to. And it will be saved, even after unplugging the board. And if you use any of the RGB codes, it will disable the layer indication, so that it stays on the mode and color that you set it to.
## 'EECONFIG' Function Documentation
* Keyboard/Revision: `void eeconfig_init_kb(void)`, `uint32_t eeconfig_read_kb(void)` and `void eeconfig_update_kb(uint32_t val)`
* Keymap: `void eeconfig_init_user(void)`, `uint32_t eeconfig_read_user(void)` and `void eeconfig_update_user(uint32_t val)`
The `val` is the value of the data that you want to write to EEPROM. And the `eeconfig_read_*` function return a 32 bit (DWORD) value from the EEPROM.
@@ -67,9 +67,11 @@ Additionally, if one side does not have an encoder, you can specify `{}` for the
#define ENCODER_RESOLUTIONS_RIGHT { 4 }
```
!> Keep in mind that whenver you change the encoder resolution, you will need to reflash the half that has the encoder affected by the change.
## Encoder map :id=encoder-map
Encoder mapping may be added to your `keymap.c`, which replicates the normal keyswitch layer handling functionality, but with encoders. Add this to your `rules.mk`:
Encoder mapping may be added to your `keymap.c`, which replicates the normal keyswitch layer handling functionality, but with encoders. Add this to your keymap's `rules.mk`:
?> This should only be enabled at the keymap level.
Using encoder mapping pumps events through the normal QMK keycode processing pipeline, resulting in a _keydown/keyup_ combination pushed through `process_record_xxxxx()`. To configure the amount of time between the encoder "keyup" and "keydown", you can add the following to your `config.h`:
```c
#define ENCODER_MAP_KEY_DELAY 10
```
?> By default, the encoder map delay matches the value of `TAP_CODE_DELAY`.
## Callbacks
When not using `ENCODER_MAP_ENABLE = yes`, the callback functions can be inserted into your `<keyboard>.c`:
!> If you return `true`, it will allow the keyboard level code to run as well. Returning `false` will override the keyboard level code, depending on how the keyboard function is set up.
!> If you return `true`, it will allow the keyboard level code to run as well. Returning `false` will override the keyboard level code, depending on how the keyboard function is set up.
Layer conditions can also be used with the callback function like the following:
@@ -169,7 +184,7 @@ The A an B lines of the encoders should be wired directly to the MCU, and the C/
Multiple encoders may share pins so long as each encoder has a distinct pair of pins when the following conditions are met:
- using detent encoders
- pads must be high at the detent stability point which is called 'default position' in QMK
- no more than two encoders sharing a pin can be turned at the same time
- no more than two encoders sharing a pin can be turned at the same time
For example you can support two encoders using only 3 pins like this
```
@@ -182,4 +197,4 @@ You could even support three encoders using only three pins (one per encoder) ho
#define ENCODERS_PAD_A { B1, B1, B2 }
#define ENCODERS_PAD_B { B2, B3, B3 }
```
Here rotating Encoder 0 `B1 B2` and Encoder 1 `B1 B3` could be interpreted as rotating Encoder 2 `B2 B3` or `B3 B2` depending on the timing. This may still be a useful configuration depending on your use case
Here rotating Encoder 0 `B1 B2` and Encoder 1 `B1 B3` could be interpreted as rotating Encoder 2 `B2 B3` or `B3 B2` depending on the timing. This may still be a useful configuration depending on your use case
The keyboard can be made to be recognized as a joystick HID device by the operating system.
This feature provides game controller input as a joystick device supporting up to 6 axes and 32 buttons. Axes can be read either from an [ADC-capable input pin](adc_driver.md), or can be virtual, so that its value is provided by your code.
!> Joystick support is not currently available on V-USB devices.
An analog device such as a [potentiometer](https://en.wikipedia.org/wiki/Potentiometer) found on an analog joystick's axes is based on a voltage divider, where adjusting the movable wiper controls the output voltage which can then be read by the microcontroller's ADC.
The joystick feature provides two services:
* reading analog input devices (eg. potentiometers)
* sending gamepad HID reports
## Usage :id=usage
Both services can be used without the other, depending on whether you just want to read a device but not send gamepad reports (for volume control for instance)
or send gamepad reports based on values computed by the keyboard.
### Analog Input
To use analog input you must first enable it in `rules.mk`:
Add the following to your `rules.mk`:
```make
JOYSTICK_ENABLE= yes
JOYSTICK_DRIVER= analog # or 'digital'
```
An analog device such as a potentiometer found on a gamepad's analog axes is based on a [voltage divider](https://en.wikipedia.org/wiki/Voltage_divider).
It is composed of three connectors linked to the ground, the power input and power output (usually the middle one). The power output holds the voltage that varies based on the position of the cursor,
which value will be read using your MCU's [ADC](https://en.wikipedia.org/wiki/Analog-to-digital_converter).
Depending on which pins are already used by your keyboard's matrix, the rest of the circuit can get a little bit more complicated,
feeding the power input and ground connection through pins and using diodes to avoid bad interactions with the matrix scanning procedures.
By default the joystick driver is `analog`, but you can change this with:
### Configuring the Joystick
```make
JOYSTICK_DRIVER= digital
```
By default, two axes and eight buttons are defined. This can be changed in your `config.h`:
## Configuration :id=configuration
By default, two axes and eight buttons are defined, with a reported resolution of 8 bits (-127 to +127). This can be changed in your `config.h`:
```c
// Max 32
// Min 0, max 32
#define JOYSTICK_BUTTON_COUNT 16
// Max 6: X, Y, Z, Rx, Ry, Rz
#define JOYSTICK_AXES_COUNT 3
// Min 0, max 6: X, Y, Z, Rx, Ry, Rz
#define JOYSTICK_AXIS_COUNT 3
// Min 8, max 16
#define JOYSTICK_AXIS_RESOLUTION 10
```
When defining axes for your joystick, you have to provide a definition array. You can do this from your keymap.c file.
A joystick will either be read from an input pin that allows the use of the ADC, or can be virtual, so that its value is provided by your code.
You have to define an array of type ''joystick_config_t'' and of proper size.
?> You must define at least one button or axis. Also note that the maximum ADC resolution of the supported AVR MCUs is 10-bit, and 12-bit for most STM32 MCUs.
There are three ways for your circuit to work with the ADC, that relies on the use of 1, 2 or 3 pins of the MCU:
* 1 pin: your analog device is directly connected to your device GND and VCC. The only pin used is the ADC pin of your choice.
* 2 pins: your analog device is powered through a pin that allows toggling it on or off. The other pin is used to read the input value through the ADC.
* 3 pins: both the power input and ground are connected to pins that must be set to a proper state before reading and restored afterwards.
### Axes :id=axes
The configuration of each axis is performed using one of four macros:
*`JOYSTICK_AXIS_VIRTUAL`: no ADC reading must be performed, that value will be provided by keyboard/keymap-level code
*`JOYSTICK_AXIS_IN(INPUT_PIN, LOW, REST, HIGH)`: a voltage will be read on the provided pin, which must be an ADC-capable pin.
*`JOYSTICK_AXIS_IN_OUT(INPUT_PIN, OUTPUT_PIN, LOW, REST, HIGH)`: the provided `OUTPUT_PIN` will be set high before `INPUT_PIN` is read.
*`JOYSTICK_AXIS_IN_OUT_GROUND(INPUT_PIN, OUTPUT_PIN, GROUND_PIN, LOW, REST, HIGH)`: the `OUTPUT_PIN` will be set high and `GROUND_PIN` will be set low before reading from `INPUT_PIN`.
When defining axes for your joystick, you must provide a definition array typically in your `keymap.c`.
In any case where an ADC reading takes place (when`INPUT_PIN` is provided), additional `LOW`, `REST` and `HIGH` parameters are used.
These implement the calibration of the analog device by defining the range of read values that will be mapped to the lowest, resting position and highest possible value for the axis (-127 to 127).
In practice, you have to provide the lowest/highest raw ADC reading, and the raw reading at resting position, when no deflection is applied. You can provide inverted `LOW` and `HIGH` to invert the axis.
For instance, an axes configuration can be defined in the following way:
For instance, the below example configures two axes. The X axis is read from the `A4` pin. With the default axis resolution of 8 bits, the range of values between 900 and 575 are scaled to -127 through 0, and values 575 to 285 are scaled to 0 through 127. The Y axis is configured as a virtual axis, and its value is not read from any pin. Instead, the user must update the axis value programmatically.
When the ADC reads 900 or higher, the returned axis value will be -127, whereas it will be 127 when the ADC reads 285 or lower. Zero is returned when 575 is read.
Axes can be configured using one of the following macros:
In this example, the first axis will be read from the `A4` pin while `B0` is set high and `A7` is set low, using `analogReadPin()`, whereas the second axis will not be read.
*`JOYSTICK_AXIS_IN(input_pin, low, rest, high)`
The ADC samples the provided pin. `low`, `high` and `rest` correspond to the minimum, maximum, and resting (or centered) analog values of the axis, respectively.
Same as `JOYSTICK_AXIS_IN_OUT()`, but the provided `ground_pin` will be pulled low before reading from `input_pin`.
*`JOYSTICK_AXIS_VIRTUAL`
No ADC reading is performed. The value should be provided by user code.
In order to give a value to the second axis, you can do so in any customizable entry point: as an action, in `process_record_user()` or in `matrix_scan_user()`, or even in `joystick_task()` which is called even when no key has been pressed.
You assign a value by writing to `joystick_status.axes[axis_index]` a signed 8-bit value (ranging from -127 to 127). Then it is necessary to assign the flag `JS_UPDATED` to `joystick_status.status` in order for an updated HID report to be sent.
The `low` and `high` values can be swapped to effectively invert the axis.
The following example writes two axes based on keypad presses, with `KC_P5` as a precision modifier:
#### Virtual Axes :id=virtual-axes
The following example adjusts two virtual axes (X and Y) based on keypad presses, with `KC_P0` as a precision modifier:
By default, the resolution of each axis is 8 bit, giving a range of -127 to +127. If you need higher precision, you can increase it by defining eg. `JOYSTICK_AXES_RESOLUTION 12` in your `config.h`. The resolution must be between 8 and 16.
|Key |Aliases|Description|
|-----------------------|-------|-----------|
|`QK_JOYSTICK_BUTTON_0` |`JS_0` |Button 0 |
|`QK_JOYSTICK_BUTTON_1` |`JS_1` |Button 1 |
|`QK_JOYSTICK_BUTTON_2` |`JS_2` |Button 2 |
|`QK_JOYSTICK_BUTTON_3` |`JS_3` |Button 3 |
|`QK_JOYSTICK_BUTTON_4` |`JS_4` |Button 4 |
|`QK_JOYSTICK_BUTTON_5` |`JS_5` |Button 5 |
|`QK_JOYSTICK_BUTTON_6` |`JS_6` |Button 6 |
|`QK_JOYSTICK_BUTTON_7` |`JS_7` |Button 7 |
|`QK_JOYSTICK_BUTTON_8` |`JS_8` |Button 8 |
|`QK_JOYSTICK_BUTTON_9` |`JS_9` |Button 9 |
|`QK_JOYSTICK_BUTTON_10`|`JS_10`|Button 10 |
|`QK_JOYSTICK_BUTTON_11`|`JS_11`|Button 11 |
|`QK_JOYSTICK_BUTTON_12`|`JS_12`|Button 12 |
|`QK_JOYSTICK_BUTTON_13`|`JS_13`|Button 13 |
|`QK_JOYSTICK_BUTTON_14`|`JS_14`|Button 14 |
|`QK_JOYSTICK_BUTTON_15`|`JS_15`|Button 15 |
|`QK_JOYSTICK_BUTTON_16`|`JS_16`|Button 16 |
|`QK_JOYSTICK_BUTTON_17`|`JS_17`|Button 17 |
|`QK_JOYSTICK_BUTTON_18`|`JS_18`|Button 18 |
|`QK_JOYSTICK_BUTTON_19`|`JS_19`|Button 19 |
|`QK_JOYSTICK_BUTTON_20`|`JS_20`|Button 20 |
|`QK_JOYSTICK_BUTTON_21`|`JS_21`|Button 21 |
|`QK_JOYSTICK_BUTTON_22`|`JS_22`|Button 22 |
|`QK_JOYSTICK_BUTTON_23`|`JS_23`|Button 23 |
|`QK_JOYSTICK_BUTTON_24`|`JS_24`|Button 24 |
|`QK_JOYSTICK_BUTTON_25`|`JS_25`|Button 25 |
|`QK_JOYSTICK_BUTTON_26`|`JS_26`|Button 26 |
|`QK_JOYSTICK_BUTTON_27`|`JS_27`|Button 27 |
|`QK_JOYSTICK_BUTTON_28`|`JS_28`|Button 28 |
|`QK_JOYSTICK_BUTTON_29`|`JS_29`|Button 29 |
|`QK_JOYSTICK_BUTTON_30`|`JS_30`|Button 30 |
|`QK_JOYSTICK_BUTTON_31`|`JS_31`|Button 31 |
Note that the supported AVR MCUs have a 10-bit ADC, and 12-bit for most STM32 MCUs.
## API :id=api
### Triggering Joystick Buttons
### `struct joystick_t` :id=api-joystick-t
Joystick buttons are normal Quantum keycodes, defined as `JS_BUTTON0` to `JS_BUTTON31`, depending on the number of buttons you have configured.
To trigger a joystick button, just add the corresponding keycode to your keymap.
Contains the state of the joystick.
You can also trigger joystick buttons in code with `register_joystick_button(button)` and `unregister_joystick_button(button)`, where `button` is the 0-based button index (0 = button 1).
#### Members :id=api-joystick-t-members
-`uint8_t buttons[]`
A bit-packed array containing the joystick button states. The size is calculated as `(JOYSTICK_BUTTON_COUNT - 1) / 8 + 1`.
-`int16_t axes[]`
An array of analog values for each defined axis.
-`bool dirty`
Whether the current state needs to be sent to the host.
Sometimes you may find yourself needing to hold down a specific key for a long period of time. Key Lock holds down the next key you press for you. Press it again, and it will be released.
Let's say you need to type in ALL CAPS for a few sentences. Hit `KC_LOCK`, and then Shift. Now, Shift will be considered held until you tap it again. You can think of Key Lock as Caps Lock, but supercharged.
Let's say you need to type in ALL CAPS for a few sentences. Hit `QK_LOCK`, and then Shift. Now, Shift will be considered held until you tap it again. You can think of Key Lock as Caps Lock, but supercharged.
## Usage
First, enable Key Lock by setting `KEY_LOCK_ENABLE = yes` in your `rules.mk`. Then pick a key in your keymap and assign it the keycode `KC_LOCK`.
First, enable Key Lock by setting `KEY_LOCK_ENABLE = yes` in your `rules.mk`. Then pick a key in your keymap and assign it the keycode `QK_LOCK`.
|`KC_LOCK`|Hold down the next key pressed, until the key is pressed again|
|`QK_LOCK`|Hold down the next key pressed, until the key is pressed again|
## Caveats
Key Lock is only able to hold standard action keys and [One Shot modifier](one_shot_keys.md) keys (for example, if you have your Shift defined as `OSM(KC_LSFT)`).
Key Lock is only able to hold standard action keys and [One Shot modifier](one_shot_keys.md) keys (for example, if you have your Shift defined as `OSM(MOD_LSFT)`).
This does not include any of the QMK special functions (except One Shot modifiers), or shifted versions of keys such as `KC_LPRN`. If it's in the [Basic Keycodes](keycodes_basic.md) list, it can be held.
Switching layers will not cancel the Key Lock. The Key Lock can be cancelled by calling the `cancel_key_lock()` function.
|`QK_KEY_OVERRIDE_ON` |`KO_ON` |Turn on key overrides |
|`QK_KEY_OVERRIDE_OFF` |`KO_OFF` |Turn off keyoverrides|
## Reference for `key_override_t`
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.