* 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.
* Adding chocV keyboard
* Fix checklist issues / community layout support
* Remove template cruft from readme
* Fix image url in readme
* Fix image url in readme to raw github content
* Change readme example to use default Keymap
* Remove vestigal config
* More informative keymap readme
* Config.h swapsies
* Remove deprecated features
* Conform / Modernize Rules
* Conform / Modernize Rules
* Clean up spacing
* Update keyboards/chocv/readme.md
Move build docs links to end 👍
* Add correct hand_swap_config matrix for planck_rev6 and planck_rev6_drop
* Make sure indentations are consistent
* Make the rev6 hand_swap_config matrix the default, also correct for ez.
* Move hand_swap_config matrix from planck.c to revision subdirectories
* crkbd:thunderbird2086
* readme
* after code review
* coding format
* minor change
* changed file name
* correct image
* updated readme
* using query to get rgb status
* minor update
* feat(keebwerk): added VIA support keymap for keebwerk nano slider
Added VIA support for keebwerk nano slider, VIA json is keebwerk_nano_via.json
Fixed midi2vol keymap where comma symbol is missing from enum "custom_layers"
* feat(keebwerk): removed VIA json as requested
* Update keyboards/keebwerk/nano_slider/keymaps/via/keymap.c
* Update keyboards/keebwerk/nano_slider/keymaps/via/keymap.c
* Fix(PR): removed file as requested
* solanis.h: add matrix diagram
* refactor keymaps: apply grid alignment
* refactor LAYOUT_all macro
Moves the matrix position identifier for the right half of Split Backspace to the number row.
* added new layout for keebio/iris
* Update keyboards/keebio/iris/keymaps/emp/config.h
* Update keyboards/keebio/iris/keymaps/emp/keymap.c
Replace #defines with enum
* Update keyboards/keebio/iris/keymaps/emp/keymap.c
Made requested changes about formatting and the license.
* Update config.h
Cleaned up formatting
* Update keyboards/keebio/iris/keymaps/emp/keymap.c
Small changes to improve readability:
* changed whitespace in license
* added more whitespace around if/else blocks
* fixed bracket style in places
* [Keyboard] Add Chocofly v1
* PR Feedback
* Small change to keymap.
* Replace KC__VOLUP and KC__VOLDOWN with single underscore version.
* Apply suggestions from code review
* Required for my PC
* Required for my PC
* Nayeon Community Layout support
- macro `LAYOUT_ansi` renamed to `LAYOUT_tkl_f13_ansi_tsangan`
- macro `LAYOUT_iso` renamed to `LAYOUT_tkl_f13_iso_tsangan`
- Community Layout support enabled in `rules.mk`
* add LAYOUT_tkl_f13_ansi_tsangan_split_bs_rshift
* add LAYOUT_tkl_f13_iso_tsangan_split_bs_rshift
* info.json: update maintainer field
Field is meant to reference the GitHub username of the maintainer.
* PMW33XX drivers overhaul
This combines the PMW3389 and PM3360 drivers as they only differ in the
firmware blobs and CPI get and set functions. The following changes have
been made:
* PMW3389 now gets the same multi-sensor feature that is already available on the
PMW3360.
* Introduced a shared pmw33xx_report_t struct is now directly readable via SPI
transactions instead of individual byte-sized reads, saving multiple
copies and bitshift operations.
* pmw33(89/60)_get_report functions had unreachable branches in their motion
detection logic these have been simplied as much as possible.
* The fast firmware upload option has been removed as this becomes obsolete by
the newly introduced polled waiting functions for ChibiOS polled waiting
* PMW33(60/89)_SPI_LSBFIRST and PMW33(60/89)_SPI_MODE config options
have been removed as they don't need to be configurable.
* All PMW3389 and PMW3360 defines have been unified to a PMW33XX prefix
to reduce code duplication and make the defines interchangeable
* Adjust keyboards to PMW33XX naming scheme
* bm80v2_iso.h: convert tabs to spaces
* bm80v2_iso.h: use ___ for KC_NO
* bm80v2_iso.h: use QMK 3-character notation
* refactor macro for tkl_iso Community Layout compatibility
- move the matrix position identifier for Enter to the home row
* info.json: correct layout data
* rules.mk: tidy-up formatting
* readme.md: tidy-up formatting
* update maintainer; re-assign copyright
* assign ISO-appropriate keycodes in keymaps
* allowing the kt60 file to be modified so I can do things while waiting for it to be fixed upstream
* 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
* shipping firmware built. Need to clean up readme and info.json layout
* removing puckbuddy files from this branch
* readme done, prepping for PR
* info.json updated prepping for PR
* Restore cirque driver that was modified from puckbuddy testing on this branch
* applying changes from review
* Update keyboards/mechwild/bbs/bbs.c
* Fixed info.json
* Apply suggestions from code review
* info.json: correct JSON syntax error
* info.json: correct key sizes
* update readme files
Moves nearly all of the information about this keyboard to the 1967st version's readme, because this readme is exposed in QMK Configurator.
Also updates the readme to align more closely with QMK's keyboard readme template.
* info.json: update metadata
Updates the keyboard name and maintainer fields.
* Use polled waiting on platforms that support it
Due to context switching overhead waiting a very short amount of time on
a sleeping thread is often not accurate and in fact not usable for timing
critical usage i.e. in a driver. Thus we use polled waiting for ranges
in the us range on platforms that support it instead. The fallback is
the thread sleeping mechanism.
This includes:
* ARM platforms with CYCCNT register (ARMv7, ARMv8) this is
incremented at CPU clock frequency
* GD32VF103 RISC-V port with CSR_MCYCLE register this is incremented at
CPU clock frequency
* RP2040 ARMv6 port which uses the integrated timer peripheral which is
incremented with a fixed 1MHz frequency
* Use wait_us() instead of chSysPolledDelayX
...as it is powered by busy waiting now.
* Add chibios waiting methods test bench
* [Layout/Keymap] kbdfans kbd67 rev2 : add new LAYOUT_65_iso_split_bs and naphaline keymap as a working example
* Update keyboards/kbdfans/kbd67/rev2/keymaps/naphtaline/keymap.c
I do trust the reviewer, here goes the change :)
Co-authored-by: Ryan <fauxpark@gmail.com>
* Remove QMK custom keycodes 1/2
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Remove QMK custom keycodes 2/2
Co-authored-by: Nick Brassel <nick@tzarc.org>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Add missing '(' to print_bin_reverse32 declaration
* Fix insufficient character buffers on satisfaction75
* Remove \0 character in format string and use corrected offset math
instead on rocketboard 16
* Replace snprintf_ with snprintf for djinn
* Explicitly ignore format checks for tracktyl manuform that uses %b
specifier
* Print properly escaped version string in command.c, as PRODUCT or
other defines can contain constructs like 'Vendor keyboard 66%' which
will be interpreted as a format specifier
mpaland printf implementation was abandoned in ~2019 and the fork by
eyalroz is now regarded to be the goto replacement of it. So this commit
incoporates the changes needed to use this fork in QMK.
Note that pointer ptrdiff_t is always supported since commit
51c90f93a97fdaef895783ecbe24569be0db7cb8
* info.json: apply friendly formatting
* info.json: remove dead space from Configurator rendering
* rename LAYOUT_all to LAYOUT_65_ansi_blocker
* rules.mk: enable Community Layout support
* Tentative Teensy 3.5 support
* Set firmware format to .hex for ARM Teensys
* Got to "device descriptor failed" by comparing with Teensy 3.6 code
* Drop down to 96MHz...
* Bump back up to 120MHz
* Disable RESET keycode because of naming conflicts
* Add Pico SDK as submodule
* Add RP2040 build support to QMK
* Adjust USB endpoint structs for RP2040
* Add RP2040 bootloader and double-tap reset routine
* Add generic and pro micro RP2040 boards
* Add RP2040 onekey keyboard
* Add WS2812 PIO DMA enabled driver and documentation
Supports regular and open-drain output configuration. RP2040 GPIOs are
sadly not 5V tolerant, so this is a bit use-less or needs extra hardware
or you take the risk to fry your hardware.
* Adjust SIO Driver for RP2040
* Adjust I2C Driver for RP2040
* Adjust SPI Driver for RP2040
* Add PIO serial driver and documentation
* Add general RP2040 documentation
* Apply suggestions from code review
Co-authored-by: Nick Brassel <nick@tzarc.org>
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Initial import of wear-leveling algorithm.
* Alignment.
* Docs tweaks.
* Lock/unlock.
* Update quantum/wear_leveling/wear_leveling_internal.h
Co-authored-by: Stefan Kerkmann <karlk90@pm.me>
* More tests, fix issue with consolidation when unlocked.
* More tests.
* Review comments.
* Add plumbing for FNV1a.
* Another test checking that checksum mismatch clears the cache.
* Check that the write log still gets played back.
Co-authored-by: Stefan Kerkmann <karlk90@pm.me>
* Refactor steno into STENO_ENABLE_[ALL|GEMINI|BOLT]
* Update stenography documentation
* STENO_ENABLE_TXBOLT → STENO_ENABLE_BOLT
TXBOLT is a better name but BOLT is more consistent with the
pre-existing TX Bolt related constants, which all drop the "TX " prefix
* Comments
* STENO_ENABLE_[GEMINI|BOLT|ALL] → STENO_PROTOCOL = [geminipr|txbolt|all]
* Add note on lacking V-USB support
* Clear chord at the end of the switch(mode){send_steno_chord} block
* Return true if NOEVENT
* update_chord_xxx → add_xxx_key_to_chord
* Enable the defines for all the protocols if STENO_PROTOCOL = all
* Mention how to use `steno_set_mode`
* Set the default steno protocol to "all"
This is done so that existing keymaps invoking `steno_set_mode` don't
all suddenly break
* Add data driver equivalents for stenography feature
* Document format of serial steno packets
(Thanks dnaq)
* Add missing comma
* move ISO Enter position to home row
This commit makes the ISO layout macros compatible with QMK's `65_iso_blocker` and `65_iso_blocker_tsangan` community layouts.
* info.json: apply friendly formatting
- add key labels
- add line breaks between physical rows
* enable Community Layout support
* chaos65.h: add matrix diagram
* avr i2c_master: Fix 1ms timeout
i2c_start() produces a minimum time_slice of 1ms for use as timeout
value.
The timer granularity is 1ms, it is entirely possible for timer_count
to tick up immediately after the last timer read and falsely trigger
timeout with a '>= 1' comparison.
* avr/drivers/i2c_master: Use timer_elapsed()
* Fix RGB heatmap to use XY positions
* lower effect area limit and make configurable
* tidy up macro
* Fix triggering in both directions.
* add docs
* fix bug when decreasing value
* performance tweak
* move USE_I2C and EE_HANDS definitions to keyboard level
Allow this keyboard to be compiled by QMK Configurator.
* remove redundant DEFAULT_FOLDER rule
* [Keyboard] Add labbeminiv1
* Adjust vendor id
The used vendor id was in use
* Remove comment in the rgb keymap
* Update keyboards/labbe/labbeminiv1/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Rename rgb matrix keymap folder
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add base FAve 84H firmware
* Update keyboards/linworks/fave84h/readme.md
Thank you, apologies for the oversight
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/linworks/fave84h/keymaps/via/keymap.c
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/linworks/fave84h/keymaps/default/keymap.c
Co-authored-by: Joel Challis <git@zvecr.com>
* Move LED config in ifdef
* update read me
* Update Product Name
* Update keyboards/linworks/fave84h/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add Via RGB Matrix Control
* Add base FAve 84H firmware
* Add Via RGB Matrix Control
* fix merge conflict
* reduce max brightness
* remove action macro and action function
Co-authored-by: Joel Challis <git@zvecr.com>
* Remove / update code to work with the build in QMK via hack
* Update Read me
* Add newline at end of rules
Co-authored-by: Wolf Van Herreweghe <wolfvh@getupgamesofficial.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* sync oled code over the keymaps
* put different product ids
* put different product ids for the rest
* put different product ids for the rest
* try to reduce code duplication
* make ifdefs nice and correct
* move the leds code out of keymap
* try to reduce code duplication
* move the rgb code outside the keymaps for reuse
* Update keyboards/mlego/m65/m65.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update keyboards/mlego/m65/m65.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
* move more code outside keymaps for reuse
* add few more xps
* add mic mute
* update to new name of macros for reset
* style for matrix
* clean split
* use tinyuf2 as bootloader
* Update keyboards/mlego/m65/rev4/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* radionalise product id and device version
* add tinyuf2 as default bootloader for stm32f4
* update tinyuf2
* update tinyuf2 and via. f411 remove tinyuf2 since is not really working. make the config more conditional
* sync the keymap with default
* revert via non building with gcc 11
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Handle timeout on UART for Redox Wireless receiver-to-keyboard communication.
- This fixes the issue of a keyboard deadlocking on the first matrix
scan with Redox Wireless keyboards
* Remove an explicit cast.
Co-authored-by: Tomasz Janeczko <tomasz.j@hey.com>
* Add files for alt34 keyboard
* Add link to hardware bill of materials for alt34
* Change keyboard image link to imgur
* Remove platform specific defines from rev1.h
* Remove bluetooth and sleep led rules etc
* Add GPL license header to all source code files
* Shorten comment for NKRO_ENABLE
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Simplify option usage comment in rules.mk
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Set imgur link to largest size option
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Move rules.mk into rev1 folder entirely
* Remove .noci file
* Update keyboards/alt34/rev1/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Move SPLIT_HAND_PIN setup to split_pre_init
* doppelganger should use old behaviour
* Add comment for future
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Joel Challis <git@zvecr.com>
* Fix Caps Word and Unicode Map
* Tests for Caps Word + Auto Shift and Unicode Map.
* Fix formatting
* Add additional keyboard report expectation macros
This commit defines five test utilities, EXPECT_REPORT, EXPECT_UNICODE,
EXPECT_EMPTY_REPORT, EXPECT_ANY_REPORT and EXPECT_NO_REPORT for use with
TestDriver.
EXPECT_REPORT sets a gmock expectation that a given keyboard report will
be sent. For instance,
EXPECT_REPORT(driver, (KC_LSFT, KC_A));
is shorthand for
EXPECT_CALL(driver,
send_keyboard_mock(KeyboardReport(KC_LSFT, KC_A)));
EXPECT_UNICODE sets a gmock expectation that a given Unicode code point
will be sent using UC_LNX input mode. For instance for U+2013,
EXPECT_UNICODE(driver, 0x2013);
expects the sequence of keys:
"Ctrl+Shift+U, 2, 0, 1, 3, space".
EXPECT_EMPTY_REPORT sets a gmock expectation that a given keyboard
report will be sent. For instance
EXPECT_EMPTY_REPORT(driver);
expects a single report without keypresses or modifiers.
EXPECT_ANY_REPORT sets a gmock expectation that a arbitrary keyboard
report will be sent, without matching its contents. For instance
EXPECT_ANY_REPORT(driver).Times(1);
expects a single arbitrary keyboard report will be sent.
EXPECT_NO_REPORT sets a gmock expectation that no keyboard report will
be sent at all.
* Add tap_key() and tap_keys() to TestFixture.
This commit adds a `tap_key(key)` method to TestFixture that taps a
given KeymapKey, optionally with a specified delay between press and
release.
Similarly, the method `tap_keys(key_a, key_b, key_c)` taps a sequence of
KeymapKeys.
* Use EXPECT_REPORT, tap_keys, etc. in most tests.
This commit uses EXPECT_REPORT, EXPECT_UNICODE, EXPECT_EMPTY_REPORT,
EXPECT_NO_REPORT, tap_key() and tap_keys() test utilities from the
previous two commits in most tests. Particularly the EXPECT_REPORT
macro is frequently useful and makes a nice reduction in boilerplate
needed to express many tests.
Co-authored-by: David Kosorin <david@kosorin.net>
This is a minor bug fix for Caps Word. Currently, Caps Word turns off
whenever a non-shift mod becomes active. This is done to avoid
interfering with hotkeys.
This commit makes an exception to continue Caps Word when AltGr (right
Alt) is held. Outside the US, the AltGr key is used to type additional
symbols (https://en.wikipedia.org/wiki/AltGr_key). Depending on the
language, these may include symbols used within words like accented
letters where it would be desirable to continue Caps Word.
* info.json: apply friendly formatting
* rename LAYOUT_all to LAYOUT_tkl_f13_ansi_tsangan
* enable Community Layout support
* refactor keymaps to use grid alignment
* phaseone.h: add matrix diagram
* add QMK Configurator data
* add LAYOUT_65_ansi_blocker_split_bs macro
* add LAYOUT_65_ansi_wkl_split_bs macro
* add LAYOUT_65_iso_blocker macro
* add LAYOUT_65_iso_blocker_split_bs macro
* add LAYOUT_65_iso_wkl macro
* add LAYOUT_65_iso_wkl_split_bs macro
* rename LAYOUT_65_ansi_wkl to LAYOUT_65_ansi_blocker_tsangan_wkl
Differentiates the layout supported here from QMK's `65_ansi_blocker_tsangan` Community Layout, which is equivalent to this but with a 1u GUI key between Left Ctrl and Left Alt.
* rename new layout macros for codebase consistency
- `LAYOUT_65_ansi_wkl_split_bs` -> `LAYOUT_65_ansi_blocker_tsangan_wkl_split_bs`
- `LAYOUT_65_iso_wkl` -> `LAYOUT_65_iso_blocker_tsangan_wkl`
- `LAYOUT_65_iso_wkl_split_bs` -> `LAYOUT_65_iso_blocker_tsangan_wkl_split_bs`
* add reference keymaps
Add keymaps which demonstrate the layout macro implementations.
* info.json: apply friendly formatting
* info.json: remove dead space from rendering
* info.json: insert line breaks between physical rows in layout data
* info.json: fix overlap in key rendering
Fixes an issue where the ANSI Enter key renders on top of the ISO Hash/Tilde key, visually hiding the latter.
* add LAYOUT_ansi_all macro with associated keymap
Duplicates `LAYOUT_all`, but with the ISO Hash/Tilde and ISO Backslash keys removed.
- ANSI Enter and 2.25u Left Shift
- Backspace, Right Shift, Numpad Plus and Numpad Enter all split
- 1.5 / 1 / 1.5 / 6.25 / 1.25 / 1.25 / 1.25 Bottom Row
* add LAYOUT_iso_all macro with associated keymap
Duplicates `LAYOUT_all`, but with the ANSI Backslash key removed.
- ISO Enter and 1.25u Left Shift
- Backspace, Right Shift, Numpad Plus and Numpad Enter all split
- 1.5 / 1 / 1.5 / 6.25 / 1.25 / 1.25 / 1.25 Bottom Row
* Fix platforms/avr/drivers/ws2812.c
`platforms/avr/drivers/ws2812.c` has been changed to use `DDRx_ADDRESS()` and `PORTx_ADDRESS()` instead of `_SFR_IO8()` in #8646. To use them, `#include <pin_defs.h>` is required.
## Error Log
* create new keyboard
```shell
bash-3.2$ qmk new-keyboard
Ψ Generating a new QMK keyboard directory
Name Your Keyboard Project
For more infomation, see:
https://docs.qmk.fm/#/hardware_keyboard_guidelines?id=naming-your-keyboardproject
Keyboard Name? ws2812_test
..................................
36. WB32F3G71
Please enter your choice: [12]
Ψ Created a new keyboard called ws2812_test.
Ψ To start working on things, `cd` into keyboards/ws2812_test,
Ψ or open the directory in your preferred text editor.
Ψ And build with qmk compile -kb ws2812_test -km default.
```
* Enable RGBLIGHT.
```shell
bash-3.2$ echo RGBLIGHT_ENABLE=yes >> ./keyboards/ws2812_test/rules.mk
bash-3.2$ echo '#define RGB_DI_PIN B1' >> ./keyboards/ws2812_test/config.h
bash-3.2$ echo '#define RGBLED_NUM 6' >> ./keyboards/ws2812_test/config.h
```
* Compile
```shell
bash-3.2$ make ws2812_test:default
QMK Firmware 0.16.9
Making ws2812_test with keymap default
avr-gcc (Homebrew AVR GCC 8.4.0_2) 8.4.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
.....................
Compiling: quantum/process_keycode/process_rgb.c [OK]
Compiling: platforms/avr/drivers/ws2812.c platforms/avr/drivers/ws2812.c: In function 'ws2812_setleds':
platforms/avr/drivers/ws2812.c:40:5: error: implicit declaration of function 'DDRx_ADDRESS' [-Werror=implicit-function-declaration]
DDRx_ADDRESS(RGB_DI_PIN) |= pinmask(RGB_DI_PIN);
^~~~~~~~~~~~
In file included from <command-line>:
./keyboards/ws2812_test/config.h:21:20: error: 'B1' undeclared (first use in this function); did you mean 'PB1'?
#define RGB_DI_PIN B1
^~
platforms/avr/drivers/ws2812.c:40:18: note: in expansion of macro 'RGB_DI_PIN'
DDRx_ADDRESS(RGB_DI_PIN) |= pinmask(RGB_DI_PIN);
^~~~~~~~~~
./keyboards/ws2812_test/config.h:21:20: note: each undeclared identifier is reported only once for each function it appears in
#define RGB_DI_PIN B1
^~
platforms/avr/drivers/ws2812.c:40:18: note: in expansion of macro 'RGB_DI_PIN'
DDRx_ADDRESS(RGB_DI_PIN) |= pinmask(RGB_DI_PIN);
^~~~~~~~~~
platforms/avr/drivers/ws2812.c:42:47: error: implicit declaration of function 'PORTx_ADDRESS' [-Werror=implicit-function-declaration]
uint8_t masklo = ~(pinmask(RGB_DI_PIN)) & PORTx_ADDRESS(RGB_DI_PIN);
^~~~~~~~~~~~~
In file included from /usr/local/Cellar/avr-gcc@8/8.4.0_2/avr/include/avr/io.h:99,
from /usr/local/Cellar/avr-gcc@8/8.4.0_2/avr/include/avr/interrupt.h:38,
from platforms/avr/drivers/ws2812.c:24:
platforms/avr/drivers/ws2812.c: In function 'ws2812_sendarray_mask':
./keyboards/ws2812_test/config.h:21:20: error: 'B1' undeclared (first use in this function); did you mean 'PB1'?
#define RGB_DI_PIN B1
^~
platforms/avr/drivers/ws2812.c:167:69: note: in expansion of macro 'RGB_DI_PIN'
: "r"(curbyte), "I"(_SFR_IO_ADDR(PORTx_ADDRESS(RGB_DI_PIN))), "r"(maskhi), "r"(masklo));
^~~~~~~~~~
cc1: all warnings being treated as errors
[ERRORS]
|
|
|
make[1]: *** [.build/obj_ws2812_test_default/ws2812.o] Error 1
make: *** [ws2812_test:default] Error 1
Make finished with errors
```
* change include order
* add users/mtei/key_blocks.h
This change does not alter the binary of the build result.
Moved common macro definitions in the following files to users/mtei/key_blocks.h.
* keyboards/helix/rev2/keymaps/five_rows/keymap.c
* keyboards/helix/rev3_5rows/keymaps/five_rows/keymap.c
* remove INIT_HELIX_OLED() in helix:five_rows
This change does not alter the binary of the build result.
* update helix/pico/keymaps/mtei/keymap.c
Changed helix/pico/keymaps/mtei/keymap.c to use users/mtei/key_blocks.h.
This change does not alter the binary of the build result.
* Remove old SSD1306OLED code from users/mtei/oled_display.c
This change does not alter the binary of the build result.
* add options ENABLE_COLEMAK, ENABLE_DVORAK and ENABLE_EUCALYN into five_rows/keymap.c
* add users/mtei/{config.h,rules.mk,user_featues.mk,user_options.mk}
* move layer_names[] from users/mtei/oled_display.c to keymaps/five_rows/keymap.c
* Update keyboards/helix/pico/keymaps/mtei/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/helix/pico/keymaps/mtei/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/helix/pico/keymaps/mtei/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/helix/rev2/keymaps/five_rows/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/helix/rev2/keymaps/five_rows/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/helix/rev2/keymaps/five_rows/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/helix/rev3_5rows/keymaps/five_rows/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/helix/rev3_5rows/keymaps/five_rows/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/helix/rev3_5rows/keymaps/five_rows/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update users/mtei/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update users/mtei/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update users/mtei/cpp_map.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update users/mtei/cpp_map.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update users/mtei/debug_config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update users/mtei/debug_config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update users/mtei/layer_number_util.h
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* LAYOUT_iso: move Enter to home row
This commit makes the layout macro compatible with QMK's `tkl_nofrow_iso` Community Layout.
* rename LAYOUT_ansi to LAYOUT_tkl_nofrow_ansi
* rename LAYOUT_iso to LAYOUT_tkl_nofrow_iso
* enable Community Layout support
...when attempting to start a receiving USB transfer. Previously, we would
check on the IN endpoint which is the transmitting part of the USB endpoint.
This is wrong and lead to two USB transfers being started immediately
after each other in case of e.g. RAW HID endpoints:
1. When finishing an OUT transfer the low level USB driver calls the out_cb
callback, which in turn initiates another OUT transfer by calling
qmkusbDataReceived.
2. When the raw hid receive channel runs empty inside the raw_hid task,
another OUT transfer is started to potentially fill the channel again. This
happens by calling ibnotify.
Both events occur directly after each other, thus triggering the bug.
* LAYOUT_tkl_f13_ansi_tsangan support
Renames `LAYOUT_ansi_tsangan` to `LAYOUT_tkl_f13_ansi_tsangan`. Also enables Community Layout support.
* LAYOUT_tkl_f13_ansi_tsangan_split_bs_rshift support
* info.json: fix key sequence error
* info.json: fix visual rendering
Clarify the physical locations of the keys.
* info.json: update maintainer field
This field is meant to reference the maintainer's GitHub username.
* add tkl_f13_ansi_split_bs_rshift Community Layout
* add tkl_f13_ansi_tsangan_split_bs_rshift Community Layout
* add tkl_f13_iso_split_bs_rshift Community Layout
* add tkl_f13_iso_tsangan_split_bs_rshift Community Layout
* Fix state updates of one-shot locked modifiers
Activating additional one-shot locked modifiers removed previously enabled locked modifiers from the state.
`get_oneshot_locked_mods` returned zero when two or more one-shot locked modifiers were enabled and then one was disabled.
* Do not delete one-shot locked modifiers on a one-shot layer toggle
Non-locked one-shot modifiers are not removed so this behavior adds inconsistency.
Also the one-shot locked modifiers state was reset without unregistering any modifiers.
* move RGB Matrix rules to keyboard level
* move PERMISSIVE_HOLD config to keyboard level
* annepro2.c: convert tabs to spaces
* refactor rules.mk files
Reformats each version's `rules.mk` file to be arranged more similarly to those of the rest of the keyboards in QMK.
No logic change.
* annepro2.c: allow compilation without RGB Matrix
Wraps the `led_enabled` definition and the `KC_AP_RGB_*` keycodes in `#ifdef RGB_MATRIX_ENABLE`, allowing successful compilation if the user sets `RGB_MATRIX_ENABLE = no`.
* rework readme files
Reworks the main `readme.md` file to be more friendly to GitHub viewing, and removes the single-line version-specific readme files (exposes the main readme to QMK Configurator users).
* info.json: update maintainer value
* info.json: apply friendly formatting
* Add GET_TAPPING_TERM macro to reduce duplicate code
The macro gives the right tapping term depending on whether per-key
tapping terms and/or dynamic tapping terms are enabled. Unnecessary
function calls and variable resolution are avoided.
Fixes#16472.
* Use GET_TAPPING_TERM for Cirque trackpads
Co-authored-by: Stefan Kerkmann <karlk90@pm.me>
* Install dependencies before executing unit tests.
* Split out UTF-8 decoder.
* Fixup python formatting rules.
* Add documentation for QGF/QFF and the RLE format used.
* Add CLI commands for converting images and fonts.
* Add stub rules.mk for QP.
* Add stream type.
* Add base driver and comms interfaces.
* Add support for SPI, SPI+D/C comms drivers.
* Include <qp.h> when enabled.
* Add base support for SPI+D/C+RST panels, as well as concrete implementation of ST7789.
* Add support for GC9A01.
* Add support for ILI9341.
* Add support for ILI9163.
* Add support for SSD1351.
* Implement qp_setpixel, including pixdata buffer management.
* Implement qp_line.
* Implement qp_rect.
* Implement qp_circle.
* Implement qp_ellipse.
* Implement palette interpolation.
* Allow for streams to work with either flash or RAM.
* Image loading.
* Font loading.
* QGF palette loading.
* Progressive decoder of pixel data supporting Raw+RLE, 1-,2-,4-,8-bpp monochrome and palette-based images.
* Image drawing.
* Animations.
* Font rendering.
* Check against 256 colours, dump out the loaded palette if debugging enabled.
* Fix build.
* AVR is not the intended audience.
* `qmk format-c`
* Generation fix.
* First batch of docs.
* More docs and examples.
* Review comments.
* Public API documentation.
* create LAYOUT_half() macro into helix/rev2/keymaps/froggy/keymap.c
* Makes QMK standerd OLED driver used by the helix:froggy keymap switchable.
* Change helix:froggy keymap to use split_common
* the size variable was redeclared (hiding the variable of the outside scope) and therefore the while check was always false, so the compiler just removed the do while loop, but it would be better to read all data and only exit the task, after this is done
* Update info.json
Fixed:
-ISO Enter Position
-Up Arrow Position
-PgDn Position
Cause of Error:
-Keyboard Layout Editor Places Iso Enter on R1 Rather Than R2 like the ANSI Enter
* Update info.json
Fixed Compile Error to Previous Change
* Update keyboards/lw67/info.json
* keeb68.h: use QMK 3-character notation
* physically arrange layout macro
Moves the keycodes for Equals and Right Bracket to their proper places on the Number and Tab rows, respectively.
Also refactors the keymaps to use QMK-native keycode aliases, grid alignment, and four-space indent.
* move `keymaps/grv_esc/readme.md` to `keymaps/default/`
The file contents say "default keymap".
* enable Community Layouts support
* add QMK Configurator data
* touch-up `rules.mk`
* CLI: Bump the 'jsonschema' version
Update the used meta-schema from Draft 7 from 2018 to the latest one,
Draft 2020-12.
Currently, the validator falls back to Draft 7 if the newer validator is
not available. Draft 2020-12 support was introduced to 'jsonschema' in
version 4.0.0.
* Fix formatting
* qk65 hotswap: Community Layout support
- renames `LAYOUT_hotswap` to `LAYOUT_65_ansi_blocker`
- adds Community Layouts rule to `rules.mk`
* refactor keymaps
Edits the keymaps to align the keycodes in a grid. Whitespace-only change.
* info.json: apply friendly formatting
* info.json: update layout data
- update labels to make them QMK CLI friendly
- update key sizes and dimensions (removes key overlaps and mis-locations)
* foundation.h: edit white space
- convert tabs to spaces
- edit alignment of arrays
* foundation.h: add matrix diagram
* rename LAYOUT to LAYOUT_ansi_split_bs
* rename LAYOUT_tkl_ansi_7u to LAYOUT_ansi_tsangan_split_bs
* rename LAYOUT_tkl_iso to LAYOUT_iso_split_bs_rshift
* rename LAYOUT_tkl_iso_7u to LAYOUT_iso_tsangan_split_bs_rshift
* refactor keymaps
- use definitions from `layer_names` enum
- use grid alignment
- use QMK-native keycode aliases
* add reference keymaps
Add `default_ansi_tsangan_split_bs`, `default_iso_split_bs_rshift`, and `default_iso_tsangan_split_bs_rshift` keymaps.
* refactor ISO layouts
Edits the ISO layout macros so that the keycode for Enter is to the end of the home row.
* info.json: fix LAYOUT_iso_tsangan_split_bs_rshift reference
Thanks to zvecr.
* Add frameworking for development board presets
* Update lib/python/qmk/info.py
Co-authored-by: Nick Brassel <nick@tzarc.org>
Co-authored-by: Nick Brassel <nick@tzarc.org>
* CLI: Lint non-data driven macros in info.json
Macros in info.json should either have the "matrix" key with the matrix
data or should should be also present in <keyboard>.h
* Add verification of matrix data
* Use generic '<keyboard>.h' in output
* Add keyboard name to output
* Make C layout macro finding more robust
The old code missed C macros if they had whitespace between '#' and
'define' or had whitespace before '#'.
* Add via to AL1
* Updated number of rows and columns, and applied suggestions from code review
* Update Vender ID
Change the Vender ID for Triangle Lab to comply with the via PR checklist.
* Gerald65 new keyboard files
* removing initial population of pck
* Initial Gerald65 Keyboard files
* Changed diode direction
* added fn layer, added picture to readme
* directed mo keycode to fn layer
* Changes to vendor id and bootloader instructions
* Changed to direct image reference
* Update keyboards/papercranekeyboards/gerald65/readme.md
* Remove no longer used features
* r2g folder groundwork
* Default mb keymap featuring mb logos
* Migrate Oled to keyboard folder
* Move rules configs to support config better
* update readmes
* Liscnece update
* Update config and fix issues caused by redef errs
* funciton name adjusts, define specific rgb modes
* move default oled font to postconfig
* update oled in line with develop merge
* fix return value
* Add some default rgb matrix defines
* del ugfx
* remove #include <stdio.h>
* create personal keymap for r2g
* reduce firmware size
* change keymap to follow physical layout
* remove RGBlight config lines to make both sides work (@Dasky on MechboardsUK Discord)
* strip down configuration, similar to crkbd/r2g:mb_via
* remove wrong oled code overwriting the r2g one
* broken code with RGB matrix (briks right side)
* remove high max brightness limit
* caps lock tap dance and RGB indicator for active caps lock
* fix caps lock led on right side
* add test macro
* remove latex macro which is too slow
* move caps lock tap dance to RALT and add space cadet shift
* switch CTL with ALT in first layer
* add tap dance for ESC/DEL
* space cadet tap dance with caps lock; shift works by needs a short pause
* add space cadet tap dance with caps lock on the right; shift works by needs a short pause and does not hold
* make more keys transparent
* enable auto shift and use logo on both oleds
* add user oled logo, slows down linking considerably
* oled name
* add arrow keys in usual configuration and add linear configuration to symbol layer
* add unicoede support
* add accents
* update to latest version
* add colemak dh layer
* report auto shift timeout
* define layer name shorcuts correctly
* disable VIA to enable more layers
* enable NKRO
* move some rules and unicode to user space
* move oled and tap dances to user space
* move tap dances fully out of keymap
* expand unicode map
* fix unicode code
* revert changes to r2g, make it equal to merged code
* revert changes to r2g, make it equal to merged code
* clang-format userspace
* clang-format config file
* Update keyboards/crkbd/keymaps/rmeli/keymap.c
* replace define with enum
* add licenses
The 'cd' subcommand was failing as the current shell's Windows path was
mangled while milc processed it.
Using 'subprocess' directly avoids this issue and an extra layer of
subshell.
* [Docs] Include ASCII diagram to explain tap-hold modes
* [Docs]: add examples for Default mode for Tap Hold
* [Docs] fix some wrong explanation in tap_hold.md
Add new keymap for GMMK with some additional mappings and led indicator for caps lock
* add chofstede keymap
* fix formatting
* fix formatting
* add readme
* Update keyboards/gmmk/pro/iso/keymaps/chofstede/keymap.c
Add rgb-light and encoder for lily58 mod
* add support for lily58 encoders (one per size) and rgb-light.
The pcb and details here https://github.com/orvisevans/Lily58-Glow-Enc
* add support for lily58 encoders (one per size) and rgb-light.
The pcb and details here https://github.com/orvisevans/Lily58-Glow-Enc
* Update keyboards/lily58/glowEnc/config.h
* add GPL License to growEnc.h
* rename folder according to requirement to lower case
Added the keymap I have been using as a daily driver for the last month.
* good firmware 26 jan, best clicky mode stability so far
* modified to reflect master branch coding style
* further modified to reflect master branch coding style
* improving clicky stability, tuned down clicky delay duration
* changed name of keymap folder to use lowercase letters
* Add macOS keymap for GMMK Pro (ANSI)
* Change macOS keymap directory name to lowercase
* Add toggleable layer with alternative keymap for function row
* Update readme
// Documentation section is used purely for `qmk xap-generate-docs`.
documentation: {
order: [
page_header
type_docs
!type_docs.md.j2
term_definitions
!term_definitions.md.j2
request_response
reserved_tokens
response_flags
!response_flags.md.j2
example_conversation
routes
!routes.md.j2
]
page_header:
'''
# QMK Firmware XAP Specs
This document describes the requirements of the QMK XAP ("extensible application protocol") API.
'''
type_docs:
'''
## Types
**All integral types are little-endian.**
'''
term_definitions:
'''
## Definitions
This list defines the terms used across the entire set of XAP protocol documentation.
'''
request_response:
'''
## Requests and Responses
Communication generally follows a request/response pattern.
Each request needs to include a _token_ -- this `u16` value prefixes each outbound request from the host application and its corresponding response.
This allows response messages to be correlated with their request, even if multiple host applications are communicating with the firmware simultaneously.
Host applications should randomly generate a token ID for **every** outbound request, unless using a reserved token defined below.
To ensure host interoperability, valid token values are within the range `0x0100`-`0xFFFF`.
This token is followed by a `u8` signifying the length of data in the request.
'''
// This documentation section reserved for next version
reserved_tokens: ''
response_flags:
'''
Response messages will always be prefixed by the originating request _token_, directly followed by that request's _response flags_, then the response payload length:
Subsystem validity should be queried through the “Enabled-in-firmware subsystem query” under the QMK subsystem (route=0x00,0x01).
This is the primary method for determining if a subsystem has been enabled in the running firmware.
'''
}
type_docs: {
u8:
'''
An unsigned 8-bit integral (octet, or byte), commonly seen as `uint8_t` from _stdint.h_.
'''
u16:
'''
An unsigned 16-bit integral, commonly seen as `uint16_t` from _stdint.h_.
'''
u32:
'''
An unsigned 32-bit integral, commonly seen as `uint32_t` from _stdint.h_.
'''
"type[n]":
'''
An array of `type`, with array extent of `N` -- e.g. `u8[2]` signifies two consecutive octets.
'''
}
term_definitions: {
Subsystem:
'''
A high-level area of functionality within XAP.
'''
Route:
'''
A sequence of _IDs_ describing the route to invoke a _handler_.
'''
Handler:
'''
A piece of code that is executed when a specific _route_ is received.
'''
Response:
'''
The data sent back to the host during execution of a _handler_.
'''
Payload:
'''
Any received data appended to the _route_, which gets delivered to the _handler_ when received.
'''
}
type_definitions: {
identifier: {
name: ID
description: A single octet / 8-bit byte, representing Subsystem or Route index.
type: u8
}
response_flags: {
name: Response Flags
description: An `u8` containing the status of the request.
type: u8
}
token: {
name: Token
description: A `u16` associated with a specific request as well as its corresponding response. Valid token values are within the range `0x0100`-`0xFFFF`.
type: u16
}
request_header: {
name: Request Header
description: Packet format for inbound data.
type: struct
struct_length: 3
struct_members: [
{
type: token
name: token
},
{
type: u8
name: length
}
]
}
response_header: {
name: Response Header
description: Packet format for outbound data.
type: struct
struct_length: 4
struct_members: [
{
type: token
name: token
},
{
type: response_flags
name: flags
},
{
type: u8
name: length
}
]
}
}
response_flags: {
define_prefix: XAP_RESPONSE_FLAG
bits: {
0: {
name: Success
define: SUCCESS
description:
'''
When this bit is set, the request was successfully handled. If not set, all payload data should be disregarded, and the request retried if appropriate (with a new token).
'''
}
}
}
routes: {
0x00: {
type: router
name: XAP
define: XAP
description:
'''
This subsystem is always present, and provides the ability to query information about the XAP protocol of the connected device.
'''
routes: {
0x00: {
type: command
name: Version Query
define: VERSION_QUERY
description:
'''
XAP protocol version query.
* Returns the BCD-encoded version in the format of XX.YY.ZZZZ => `0xXXYYZZZZ`
* e.g. 3.2.115 will match `0x03020115`, or bytes {0x15,0x01,0x02,0x03}.
Two token values are reserved: `0xFFFE` and `0xFFFF`:
* `0xFFFE`: A message sent by a host application may use this token if no response is to be sent -- a "fire and forget" message.
* `0xFFFF`: Signifies a "broadcast" message sent by the firmware without prompting from the host application. Broadcast messages are defined later in this document.
Any request will generate at least one corresponding response, with the exception of messages using reserved tokens. Maximum total message length is 128 bytes due to RAM constraints.
'''
broadcast_messages:
'''
## Broadcast messages
Broadcast messages may be sent by the firmware to the host, without a corresponding inbound request. Each broadcast message uses the token `0xFFFF`, and does not expect a response from the host. Tokens are followed by an _ID_ signifying the type of broadcast, with corresponding _payload_.
'''
}
response_flags: {
bits: {
1: {
name: Secure Failure
define: SECURE_FAILURE
description:
'''
When this bit is set, the requested _route_ was marked _secure_ but an _unlock sequence_ has not completed.
'''
}
}
}
type_docs: {
u64:
'''
An unsigned 64-bit integral, commonly seen as `uint64_t` from _stdint.h_.
'''
"struct{}":
'''
A structure of data, packing different objects together. Data is "compacted" -- there are no padding bytes between fields. Equivalent to a packed C-style `struct`. The order in which they're defined matches the order of the data in the response packet.
'''
}
term_definitions: {
Capability:
'''
A way to determine if certain functionality is enabled in the firmware. Any _subsystem_ that provides build-time restriction of functionality must provide a _route_ for a _capabilities query_.
'''
"Secure Route":
'''
A _route_ which has potentially destructive consequences, necessitating prior approval by the user before executing.
'''
"Unlock sequence":
'''
A physical sequence initiated by the user to enable execution of _secure routes_.
'''
}
type_definitions: {
broadcast_header: {
name: Broadcast Header
description: Packet format for broadcast messages.
type: struct
struct_length: 4
struct_members: [
{
type: token
name: token
},
{
type: u8
name: type
},
{
type: u8
name: length
}
]
}
}
broadcast_messages: {
define_prefix: XAP_BROADCAST
messages: {
0x00: {
name: Log message
define: LOG_MESSAGE
description:
'''
Replicates and replaces the same functionality as if using the standard QMK `CONSOLE_ENABLE = yes` in `rules.mk`. Normal prints within the firmware will manifest as log messages broadcast to the host. `hid_listen` will not be functional with XAP enabled.
Log message payloads include a `u8` signifying the length of the text, followed by the `u8[Length]` containing the text itself.
Secure status has changed. Payloads include a `u8` matching a 'Secure Status' request.
**Example Secure Status Broadcast** -- secure "Unlocking"
| Byte | 0 | 1 | 2 | 3 |
| --- | --- | --- | --- | --- |
| **Purpose** | Token | Token | Broadcast Type | Secure Status |
| **Value** | `0xFF` | `0xFF` | `0x01` | `0x01` |
'''
return_type: u8
}
0x02: {
name: Keyboard
define: KB
description:
'''
Reserved for vendor-specific functionality. No messages are defined by XAP.
'''
},
0x03: {
name: User
define: USER
description:
'''
Reserved for user-specific functionality. No messages are defined by XAP.
'''
}
}
}
routes: {
0x00: {
routes: {
0x01: {
type: command
name: Capabilities Query
define: CAPABILITIES_QUERY
description:
'''
XAP subsystem capabilities query. Each bit should be considered as a "usable" route within this subsystem.
'''
return_type: u32
return_purpose: capabilities
return_constant: XAP_ROUTE_XAP_CAPABILITIES
}
0x02: {
type: command
name: Enabled subsystem query
define: SUBSYSTEM_QUERY
description:
'''
XAP protocol subsystem query. Each bit should be considered as a "usable" subsystem. For example, checking `(value & (1 << XAP_ROUTE_QMK) != 0)` means the QMK subsystem is enabled and available for querying.
'''
return_type: u32
return_purpose: capabilities
return_constant: XAP_ROUTE_CAPABILITIES
}
0x03: {
type: command
name: Secure Status
define: SECURE_STATUS
description:
'''
Query secure route status
* 0 means secure routes are disabled
* 1 means unlock sequence initiated but incomplete
* 2 means secure routes are allowed
* any other value should be interpreted as disabled
### Caps Word ([#16588](https://github.com/qmk/qmk_firmware/pull/16588)) :id=caps-word
This is a new feature that allows for capslock-like functionality that turns itself off at the end of the word.
For instance, if you wish to type "QMK" without holding shift the entire time, you can either tap both left and right shift, or double-tap shift, to turn on _Caps Word_ -- then type `qmk` (lowercase) without holding shift. Once you hit any key other than `a`--`z`, `0`--`9`, `-`, `_`, delete, or backspace, this will go back to normal typing!
There are other activation mechanisms as well as configurable options like timeout and the like -- see the [Caps Word documentation](feature_caps_word.md) for more information.
QMK has had support for small OLED displays for some time now, but hasn't really gained too much ability to draw to panels other than the SSD1306 or SH1106 panels.
Quantum Painter is a new drawing subsystem available to suitable ARM and RISC-V boards that is capable of drawing to large panel RGB LCDs and RGB OLEDs. It also allows for a lot more flexibility with a larger set of drawing APIs -- lines, rectangles, circles, ellipses, text, images, and even animations.
The QMK CLI has new commands added to be able to generate images and fonts for Quantum Painter to digest -- it's even capable of converting animated gifs for display on screen.
See the [Quantum Painter documentation](quantum_painter.md) for more information on how to set up the displays as well as how to convert images and fonts.
!> Quantum Painter is not supported on AVR due to complexity and size constraints. Boards based on AVR such as ProMicro or Elite-C builds will not be able to leverage Quantum Painter.
One of the long-standing complaints with Encoders is that there has been no easy way to configure them in user keymaps. [#13286](https://github.com/qmk/qmk_firmware/pull/13286) added support for [Encoder Mapping](feature_encoders.md#encoder-map), which allows users to define encoder functionality in a similar way to their normal keymap.
!> This is not yet supported by QMK Configurator. It is also unlikely to ever be supported by VIA.
## Changes Requiring User Action :id=changes-requiring-user-action
QMK is always in the process of picking up support for new hardware platforms. One of the side-effects for future integrations has shown that QMK's usage of `RESET` as a keycode is causing naming collisions. As a result, [#17037](https://github.com/qmk/qmk_firmware/pull/17037) changed usages of `RESET` to the new keycode `QK_BOOT` in the majority of default-like keymaps. At this stage the old keycode is still usable but will likely be removed in the next breaking changes cycle. Users with keymaps containing `RESET` should also move to `QK_BOOT`.
Some keycodes used with `SEND_STRING` and its relatives have been deprecated and may have their old keycode usages removed at a later date. The list of [deprecated keycodes](https://github.com/qmk/qmk_firmware/blob/ebd402788346aa6e88bde1486b2a835684d40d39/quantum/send_string_keycodes.h#L456-L505) should be consulted to determine if you're using one of the older names (the first identifier after `#define`) -- you should swap to the newer variant (the second identifier on the same line).
The merge of Quantum Painter added some new dependencies in the QMK CLI, most notably _Pillow_, which requires some installation in order for the CLI to function. If you've got an existing installation, you'll need to run some commands in order to get things working:
On Windows, if using _QMK MSYS_ or _msys2_, you'll need to run the following command:
@@ -335,6 +335,90 @@ This command cleans up the `.build` folder. If `--all` is passed, any .hex or .b
qmk clean [-a]
```
## `qmk via2json`
This command an generate a keymap.json from a VIA keymap backup. Both the layers and the macros are converted, enabling users to easily move away from a VIA-enabled firmware without writing any code or reimplementing their keymaps in QMK Configurator.
This command converts images to a format usable by QMK, i.e. the QGF File Format. See the [Quantum Painter](quantum_painter.md?id=quantum-painter-cli) documentation for more information on this command.
## `qmk painter-make-font-image`
This command converts a TTF font to an intermediate format for editing, before converting to the QFF File Format. See the [Quantum Painter](quantum_painter.md?id=quantum-painter-cli) documentation for more information on this command.
## `qmk painter-convert-font-image`
This command converts an intermediate font image to the QFF File Format. See the [Quantum Painter](quantum_painter.md?id=quantum-painter-cli) documentation for more information on this command.
QMK runs on any USB-capable AVR or ARM microcontroller with enough flash space - generally 32kB+ for AVR, and 64kB+ for ARM. With significant disabling of features, QMK may *just* squeeze into 16kB AVR MCUs.
Features within QMK may or may not be compatible with every microcontroller.
## Atmel AVR
The following use [LUFA](https://www.fourwalledcubicle.com/LUFA.php) as the USB stack:
@@ -51,6 +53,7 @@ You can also use any ARM chip with USB that [ChibiOS](https://www.chibios.org) s
### WestBerryTech (WB32)
* [WB32F3G71xx](http://www.westberrytech.com)
* [WB32FQ95xx](http://www.westberrytech.com)
### NXP (Kinetis)
@@ -59,9 +62,17 @@ You can also use any ARM chip with USB that [ChibiOS](https://www.chibios.org) s
For a detailed overview about the RP2040 support by QMK see the [dedicated RP2040 page](platformdev_rp2040.md).
## Atmel ATSAM
There is limited support for one of Atmel's ATSAM microcontrollers, that being the [ATSAMD51J18A](https://www.microchip.com/wwwproducts/en/ATSAMD51J18A) used by the [Massdrop keyboards](https://github.com/qmk/qmk_firmware/tree/master/keyboards/massdrop). However, it is not recommended to design a board with this microcontroller as the support is quite specialized to Massdrop hardware.
@@ -107,8 +107,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`.
@@ -131,6 +133,8 @@ If you define these options you will disable the associated feature, which can s
If you define these options you will enable the associated feature, which may increase your code size.
*`#define ENABLE_COMPILE_KEYCODE`
* Enables the `QK_MAKE` keycode
*`#define FORCE_NKRO`
* NKRO by default requires to be turned on, this forces it on during keyboard startup regardless of EEPROM setting. NKRO can still be turned off but will be turned on again if the keyboard reboots.
*`#define STRICT_LAYER_RELEASE`
@@ -139,7 +143,7 @@ If you define these options you will enable the associated feature, which may in
## Behaviors That Can Be Configured
*`#define TAPPING_TERM 200`
* how long before a tap becomes a hold, if set above 500, a key tapped during the tapping term will turn it into a hold too
* how long before a key press becomes a hold
*`#define TAPPING_TERM_PER_KEY`
* enables handling for per key `TAPPING_TERM` settings
*`#define RETRO_TAPPING`
@@ -172,6 +176,8 @@ If you define these options you will enable the associated feature, which may in
* sets the timer for leader key chords to run on each key press rather than overall
*`#define LEADER_KEY_STRICT_KEY_PROCESSING`
* Disables keycode filtering for Mod-Tap and Layer-Tap keycodes. Eg, if you enable this, you would need to specify `MT(MOD_CTL, KC_A)` if you want to use `KC_A`.
*`#define MOUSE_EXTENDED_REPORT`
* Enables support for extended reports (-32767 to 32767, instead of -127 to 127), which may allow for smoother reporting, and prevent maxing out of the reports. Applies to both Pointing Device and Mousekeys.
@@ -44,7 +44,7 @@ In other cases you should group like options together in an `object`. This is pa
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:
*`info_key`: (required) The location within `info.json` for this value. See below.
*`value_type`: (optional) Default `str`. The format for this variable's value. See below.
*`value_type`: (optional) Default `raw`. The format for this variable's value. See below.
*`to_json`: (optional) Default `true`. Set to `false` to exclude this mapping from info.json
*`to_c`: (optional) Default `true`. Set to `false` to exclude this mapping from config.h
*`warn_duplicate`: (optional) Default `true`. Set to `false` to turn off warning when a value exists in both places
@@ -57,7 +57,7 @@ Under the hood we use [Dotty Dict](https://dotty-dict.readthedocs.io/en/latest/)
#### Value Types
By default we treat all values as simple strings. If your value is more complex you can use one of these types to intelligently parse the data:
By default we treat all values as unquoted "raw" data. If your value is more complex you can use one of these types to intelligently parse the data:
*`array`: A comma separated array of strings
*`array.int`: A comma separated array of integers
@@ -65,6 +65,7 @@ By default we treat all values as simple strings. If your value is more complex
`EEPROM_DRIVER = vendor` (default) | Uses the on-chip driver provided by the chip manufacturer. For AVR, this is provided by avr-libc. This is supported on ARM for a subset of chips -- STM32F3xx, STM32F1xx, and STM32F072xB will be emulated by writing to flash. STM32L0xx and STM32L1xx will use the onboard dedicated true EEPROM. Other chips will generally act as "transient" below.
`EEPROM_DRIVER = i2c` | Supports writing to I2C-based 24xx EEPROM chips. See the driver section below.
`EEPROM_DRIVER = spi` | Supports writing to SPI-based 25xx EEPROM chips. See the driver section below.
`EEPROM_DRIVER = transient` | Fake EEPROM driver -- supports reading/writing to RAM, and will be discarded when power is lost.
`EEPROM_DRIVER = wear_leveling` | Frontend driver for the wear_leveling system, allowing for EEPROM emulation on top of flash -- both in-MCU and external SPI NOR flash.
Currently QMK supports 25xx-series chips over SPI. As such, requires a working spi_master driver configuration. You can override the driver configuration via your config.h:
The wear-leveling driver uses an algorithm to minimise the number of erase cycles on the underlying MCU flash memory.
There is no specific configuration for this driver, but the wear-leveling system used by this driver may need configuration. See the [wear-leveling configuration](#wear_leveling-configuration) section for more information.
`WEAR_LEVELING_DRIVER = embedded_flash` | This driver is used for emulating EEPROM by writing to embedded flash on the MCU.
`WEAR_LEVELING_DRIVER = spi_flash` | This driver is used to address external SPI NOR Flash peripherals.
`WEAR_LEVELING_DRIVER = rp2040_flash` | This driver is used to write to the same storage the RP2040 executes code from.
`WEAR_LEVELING_DRIVER = legacy` | This driver is the "legacy" emulated EEPROM provided in historical revisions of QMK. Currently used for STM32F0xx and STM32F4x1, but slated for deprecation and removal once `embedded_flash` support for those MCU families is complete.
!> All wear-leveling drivers require an amount of RAM equivalent to the selected logical EEPROM size. Increasing the size to 32kB of EEPROM requires 32kB of RAM, which a significant number of MCUs simply do not have.
This driver performs writes to the embedded flash storage embedded in the MCU. In most circumstances, the last few of sectors of flash are used in order to minimise the likelihood of collision with program code.
Configurable options in your keyboard's `config.h`:
`#define WEAR_LEVELING_EFL_FIRST_SECTOR` | _unset_ | The first sector on the MCU to use. By default this is not defined and calculated at runtime based on the MCU. However, different flash sizes on MCUs may require custom configuration.
`#define WEAR_LEVELING_EFL_FLASH_SIZE` | _unset_ | Allows overriding the flash size available for use for wear-leveling. Under normal circumstances this is automatically calculated and should not need to be overridden. Specifying a size larger than the amount actually available in flash will usually prevent the MCU from booting.
`#define WEAR_LEVELING_LOGICAL_SIZE` | `1024` | Number of bytes "exposed" to the rest of QMK and denotes the size of the usable EEPROM.
`#define WEAR_LEVELING_BACKING_SIZE` | `2048` | Number of bytes used by the wear-leveling algorithm for its underlying storage, and needs to be a multiple of the logical size.
`#define BACKING_STORE_WRITE_SIZE` | _automatic_ | The byte width of the underlying write used on the MCU, and is usually automatically determined from the selected MCU family. If an error occurs in the auto-detection, you'll need to consult the MCU's datasheet and determine this value, specifying it directly.
!> If your MCU does not boot after swapping to the EFL wear-leveling driver, it's likely that the flash size is incorrectly detected, usually as an MCU with larger flash and may require overriding.
This driver performs writes to an external SPI NOR Flash peripheral. It also requires a working configuration for the SPI NOR Flash peripheral -- see the [flash driver](flash_driver.md) documentation for more information.
Configurable options in your keyboard's `config.h`:
`#define WEAR_LEVELING_EXTERNAL_FLASH_BLOCK_COUNT` | `1` | Number of blocks in the external flash used by the wear-leveling algorithm.
`#define WEAR_LEVELING_EXTERNAL_FLASH_BLOCK_OFFSET` | `0` | The index first block in the external flash used by the wear-leveling algorithm.
`#define WEAR_LEVELING_LOGICAL_SIZE` | `((block_count*block_size)/2)` | Number of bytes "exposed" to the rest of QMK and denotes the size of the usable EEPROM. Result must be <= 64kB.
`#define WEAR_LEVELING_BACKING_SIZE` | `(block_count*block_size)` | Number of bytes used by the wear-leveling algorithm for its underlying storage, and needs to be a multiple of the logical size.
`#define BACKING_STORE_WRITE_SIZE` | `8` | The write width used whenever a write is performed on the external flash peripheral.
!> There is currently a limit of 64kB for the EEPROM subsystem within QMK, so using a larger flash is not going to be beneficial as the logical size cannot be increased beyond 65536. The backing size may be increased to a larger value, but erase timing may suffer as a result.
`#define WEAR_LEVELING_RP2040_FLASH_SIZE` | `PICO_FLASH_SIZE_BYTES` | Number of bytes of flash on the board.
`#define WEAR_LEVELING_RP2040_FLASH_BASE` | `(flash_size-sector_size)` | The byte-wise location that the backing storage should be located.
`#define WEAR_LEVELING_LOGICAL_SIZE` | `4096` | Number of bytes "exposed" to the rest of QMK and denotes the size of the usable EEPROM.
`#define WEAR_LEVELING_BACKING_SIZE` | `8192` | Number of bytes used by the wear-leveling algorithm for its underlying storage, and needs to be a multiple of the logical size as well as the sector size.
`#define BACKING_STORE_WRITE_SIZE` | `2` | The write width used whenever a write is performed on the external flash peripheral.
This driver performs writes to the embedded flash storage embedded in the MCU much like the normal Embedded Flash Driver, and is only for use with STM32F0xx and STM32F4x1 devices. This flash implementation is still currently provided as the EFL driver is currently non-functional for the previously mentioned families.
By default, `1024` bytes of emulated EEPROM is provided:
MCU | EEPROM Provided | Flash Used
----------|-----------------|--------------
STM32F042 | `1024` bytes | `2048` bytes
STM32F070 | `1024` bytes | `2048` bytes
STM32F072 | `1024` bytes | `2048` bytes
STM32F401 | `1024` bytes | `16384` bytes
STM32F411 | `1024` bytes | `16384` bytes
Under normal circumstances configuration of this driver requires intimate knowledge of the MCU's flash structure -- reconfiguration is at your own risk and will require referring to the code.
This page covers questions people often have about keymaps. If you haven't you should read [Keymap Overview](keymap.md) first.
## What Keycodes Can I Use?
See [Keycodes](keycodes.md) for an index of keycodes available to you. These link to more extensive documentation when available.
Keycodes are actually defined in [quantum/keycode.h](https://github.com/qmk/qmk_firmware/blob/master/quantum/keycode.h).
@@ -25,25 +26,30 @@ Sometimes, for readability's sake, it's useful to define custom names for some k
This will allow you to use `FN_CAPS` and `ALT_TAB` in your keymap, keeping it more readable.
## My Keymap Doesn't Update When I Flash It
This is usually due to VIA, and has to do with how it deals with keymaps.
On first run, the VIA code in the firmware will copy the keymap from flash memory into EEPROM so that it can be rewritten at runtime by the VIA app. From this point QMK will use the keymap stored in EEPROM instead of flash, and so updates to your `keymap.c` will not be reflected.
The simple fix for this is to clear the EEPROM. You can do this in several ways:
* Hold the Bootmagic Lite key (usually top left/Escape) while plugging the board in, which will also place the board into bootloader mode; then unplug and replug the board.
* Press the `QK_CLEAR_EEPROM`/`EE_CLR` keycode if it is accessible on your keymap.
* Place the board into bootloader mode and hit the "Clear EEPROM" button. This may not be available for all bootloaders, and you may need to reflash the board afterwards.
## Some Of My Keys Are Swapped Or Not Working
QMK has two features, Bootmagic and Command, which allow you to change the behavior of your keyboard on the fly. This includes, but is not limited to, swapping Ctrl/Caps, disabling Gui, swapping Alt/Gui, swapping Backspace/Backslash, disabling all keys, and other behavioral modifications.
QMK has a couple of features which allow you to change the behavior of your keyboard on the fly. This includes, but is not limited to, swapping Ctrl/Caps, disabling GUI, swapping Alt/GUI, swapping Backspace/Backslash, disabling all keys, and other behavioral modifications.
As a quick fix try holding down `Space`+`Backspace` while you plug in your keyboard. This will reset the stored settings on your keyboard, returning those keys to normal operation. If that doesn't work look here:
Refer to the EEPROM clearing methods above, which should return those keys to normal operation. If that doesn't work, look here:
* [Bootmagic Lite](feature_bootmagic.md)
* [Magic Keycodes](keycodes_magic.md)
* [Command](feature_command.md)
## The Menu Key Isn't Working
The key found on most modern keyboards that is located between `KC_RGUI` and `KC_RCTL` is actually called `KC_APP`. This is because when that key was invented there was already a key named `MENU` in the relevant standards, so MS chose to call that the `APP` key.
## `KC_SYSTEM_REQUEST` Isn't Working
Use keycode for Print Screen (`KC_PRINT_SCREEN`/`KC_PSCR`) instead of `KC_SYSTEM_REQUEST`. Key combination of 'Alt + Print Screen' is recognized as 'System request'.
See [issue #168](https://github.com/tmk/tmk_keyboard/issues/168) and
* https://en.wikipedia.org/wiki/Magic_SysRq_key
* https://en.wikipedia.org/wiki/System_request
The key found on most modern keyboards that is located between `KC_RGUI` and `KC_RCTL` is actually called `KC_APP`. This is because when the key was invented, there was already a key named "Menu" in the HID specification, so for whatever reason, Microsoft chose to create a new key and call it "Application".
## Power Keys Aren't Working
@@ -52,10 +58,12 @@ Somewhat confusingly, there are two "Power" keycodes in QMK: `KC_KB_POWER` in th
The former is only recognized on macOS, while the latter, `KC_SLEP` and `KC_WAKE` are supported by all three major operating systems, so it is recommended to use those instead. Under Windows, these keys take effect immediately, however on macOS they must be held down until a dialog appears.
## One Shot Modifier
Solves my personal 'the' problem. I often got 'the' or 'THe' wrongly instead of 'The'. One Shot Shift mitigates this for me.
https://github.com/tmk/tmk_keyboard/issues/67
## Modifier/Layer Stuck
Modifier keys or layers can be stuck unless layer switching is configured properly.
For Modifier keys and layer actions you have to place `KC_TRNS` on same position of destination layer to unregister the modifier key or return to previous layer on release event.
@@ -63,12 +71,11 @@ For Modifier keys and layer actions you have to place `KC_TRNS` on same position
This feature is for *mechanical lock switch* like [this Alps one](https://deskthority.net/wiki/Alps_SKCL_Lock). You can enable it by adding this to your `config.h`:
```
```c
#define LOCKING_SUPPORT_ENABLE
#define LOCKING_RESYNC_ENABLE
```
@@ -91,6 +98,7 @@ Even worse, it is not recognized unless the keyboard's VID and PID match that of
See [this issue](https://github.com/qmk/qmk_firmware/issues/2179) for detailed information.
## Keys Supported in Mac OSX?
You can know which keycodes are supported in OSX from this source code.
Japanese JIS keyboard specific keys like `無変換(Muhenkan)`, `変換(Henkan)`, `ひらがな(hiragana)` are not recognized on OSX. You can use **Seil** to enable those keys, try following options.
* Enable NFER Key on PC keyboard
@@ -111,8 +119,8 @@ Japanese JIS keyboard specific keys like `無変換(Muhenkan)`, `変換(Henkan)`
https://pqrs.org/osx/karabiner/seil.html
## RN-42 Bluetooth Doesn't Work with Karabiner
Karabiner - Keymapping tool on Mac OSX - ignores inputs from RN-42 module by default. You have to enable this option to make Karabiner working with your keyboard.
@@ -120,37 +128,24 @@ See these for the detail of this problem.
https://github.com/tmk/tmk_keyboard/issues/213
https://github.com/tekezo/Karabiner/issues/403
## Esc and <code>`</code> on a Single Key
See the [Grave Escape](feature_grave_esc.md) feature.
## Eject on Mac OSX
`KC_EJCT` keycode works on OSX. https://github.com/tmk/tmk_keyboard/issues/250
It seems Windows 10 ignores the code and Linux/Xorg recognizes but has no mapping by default.
Not sure what keycode Eject is on genuine Apple keyboard actually. HHKB uses `F20` for Eject key(`Fn+f`) on Mac mode but this is not same as Apple Eject keycode probably.
Not sure what keycode Eject is on genuine Apple keyboard actually. HHKB uses `F20` for Eject key(`Fn+F`) on Mac mode but this is not same as Apple Eject keycode probably.
## What are "Real" and "Weak" modifiers?
## What's `weak_mods` and `real_mods` in `action_util.c`
___TO BE IMPROVED___
Real modifiers refer to the state of the real/physical modifier keys, while weakmodifiers are the state of "virtual" or temporary modifiers which should not interfere with the internal state of the real modifier keys.
real_mods is intended to retains state of real/physical modifier key state, while
weak_mods retains state of virtual or temporary modifiers which should not affect state real modifier key.
The real and weak modifier states are ORed together when the keyboard report is sent, so if you release a weak modifier while the same real modifier is still held, the report does not change:
Let's say you hold down physical left shift key and type ACTION_MODS_KEY(LSHIFT, KC_A),
with weak_mods,
* (1) hold down left shift: real_mods |= MOD_BIT(LSHIFT)
@@ -39,7 +39,7 @@ In practice, this means that you can check whether a given modifier is active wi
To check that *only* a specific set of mods is active at a time, AND the modifier state and your desired mod mask as explained above and compare the result to the mod mask itself: `get_mods() & <mod mask> == <mod mask>`.
For example, let's say you want to trigger a piece of custom code if one-shot left control and one-shot left shift are on but every other one-shot mods are off. To do so, you can compose the desired mod mask by combining the mod bits for left control and shift with `(MOD_BIT(KC_LCTL) | MOD_BIT(KC_LSFT))` and then plug it in: `get_oneshot_mods & (MOD_BIT(KC_LCTL) | MOD_BIT(KC_LSFT)) == (MOD_BIT(KC_LCTL) | MOD_BIT(KC_LSFT))`. Using `MOD_MASK_CS` instead for the mod bitmask would have forced you to press four modifier keys (both versions of control and shift) to fulfill the condition.
For example, let's say you want to trigger a piece of custom code if one-shot left control and one-shot left shift are on but every other one-shot mods are off. To do so, you can compose the desired mod mask by combining the mod bits for left control and shift with `(MOD_BIT(KC_LCTL) | MOD_BIT(KC_LSFT))` and then plug it in: `get_oneshot_mods() & (MOD_BIT(KC_LCTL) | MOD_BIT(KC_LSFT)) == (MOD_BIT(KC_LCTL) | MOD_BIT(KC_LSFT))`. Using `MOD_MASK_CS` instead for the mod bitmask would have forced you to press four modifier keys (both versions of control and shift) to fulfill the condition.
@@ -23,14 +23,35 @@ And to trigger the bootloader, you hold this key down when plugging the keyboard
## Split Keyboards
When handedness is predetermined via an option like `SPLIT_HAND_PIN`, you might need to configure a different key between halves. To do so, add these entries to your `config.h` file:
When [handedness](feature_split_keyboard.md#setting-handedness) is predetermined via options like `SPLIT_HAND_PIN` or `EE_HANDS`, you might need to configure a different key between halves. To identify the correct key for the right half, examine the split key matrix defined in the `<keyboard>.h` file, e.g.:
If you pick the top right key for the right half, it is `R05` on the top layout. Within the key matrix below, `R05` is located on row 4 columnn 4. To use that key as the right half's Bootmagic Lite trigger, add these entries to your `config.h` file:
```c
#define BOOTMAGIC_LITE_ROW_RIGHT 4
#define BOOTMAGIC_LITE_COLUMN_RIGHT 1
#define BOOTMAGIC_LITE_COLUMN_RIGHT 4
```
By default, these values are not set.
?> These values are not set by default.
## Advanced Bootmagic Lite
@@ -51,7 +72,7 @@ void bootmagic_lite(void) {
}
```
You can additional feature here. For instance, resetting the EEPROM or requiring additional keys to be pressed to trigger Bootmagic Lite. Keep in mind that `bootmagic_lite` is called before a majority of features are initialized in the firmware.
You can define additional logic here. For instance, resetting the EEPROM or requiring additional keys to be pressed to trigger Bootmagic Lite. Keep in mind that `bootmagic_lite` is called before a majority of features are initialized in the firmware.
You can also add the same `CONVERT_TO=<target>` to your keymap's `rules.mk`, which will accomplish the same thing.
?> If you get errors about `PORTB/DDRB`, etc not being defined, you'll need to convert the keyboard's code to use the [GPIO Controls](gpio_control.md) that will work for both ARM and AVR. This shouldn't affect the AVR builds at all.
### Conditional Configuration
Once a converter is enabled, it exposes the `CONVERT_TO_<target_uppercase>` flag that you can use in your code with `#ifdef`s, For example:
```c
#ifdef CONVERT_TO_PROTON_C
// Proton C code
#else
// Pro Micro code
#endif
```
## 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:
The Proton C only has one on-board LED (C13), and by default, the TXLED (D5) is mapped to it. If you want the RXLED (B0) mapped to it instead, add this line to your `config.h`:
```c
#define CONVERT_TO_PROTON_C_RXLED
```
The following defaults are based on what has been implemented for STM32 boards.
| [Backlight](feature_backlight.md) | Forces [task driven PWM](feature_backlight.md#software-pwm-driver) until ARM can provide automatic configuration |
| 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 - heavily dependent on enabled features |
### Adafruit KB2040 :id=kb2040
The following defaults are based on what has been implemented for [RP2040](platformdev_rp2040.md) boards.
| [RGB Lighting](feature_rgblight.md) | Enabled via `PIO` vendor driver |
| [Backlight](feature_backlight.md) | Forces [task driven PWM](feature_backlight.md#software-pwm-driver) until ARM can provide automatic configuration |
| 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 and Blok :id=promicro_rp2040
Currently identical to [Adafruit KB2040](#kb2040).
@@ -35,6 +35,7 @@ There are a number of options added that should allow some additional degree of
|`DYNAMIC_MACRO_SIZE` |128 |Sets the amount of memory that Dynamic Macros can use. This is a limited resource, dependent on the controller. |
|`DYNAMIC_MACRO_USER_CALL` |*Not defined* |Defining this falls back to using the user `keymap.c` file to trigger the macro behavior. |
|`DYNAMIC_MACRO_NO_NESTING` |*Not Defined* |Defining this disables the ability to call a macro from another macro (nested macros). |
|`DYNAMIC_MACRO_DELAY` |*Not Defined* |Sets the waiting time (ms unit) when sending each key. |
If the LEDs start blinking during the recording with each keypress, it means there is no more space for the macro in the macro buffer. To fit the macro in, either make the other macro shorter (they share the same buffer) or increase the buffer size by adding the `DYNAMIC_MACRO_SIZE` define in your `config.h` (default value: 128; please read the comments for it in the header).
@@ -54,9 +54,43 @@ If you are using different pinouts for the encoders on each half of a split keyb
#define ENCODER_RESOLUTIONS_RIGHT { 2, 4 }
```
If the `_RIGHT` definitions aren't specified in your `config.h`, then the non-`_RIGHT` versions will be applied to both sides of the split.
Additionally, if one side does not have an encoder, you can specify `{}` for the pins/resolution -- for example, a split keyboard with only a right-side encoder:
```c
#define ENCODERS_PAD_A { }
#define ENCODERS_PAD_B { }
#define ENCODER_RESOLUTIONS { }
#define ENCODERS_PAD_A_RIGHT { B12 }
#define ENCODERS_PAD_B_RIGHT { B13 }
#define ENCODER_RESOLUTIONS_RIGHT { 4 }
```
## 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`:
```make
ENCODER_MAP_ENABLE= yes
```
Your `keymap.c` will then need an encoder mapping defined (for four layers and two encoders):
@@ -50,22 +50,28 @@ Not all keycodes below will work depending on which haptic mechanism you have ch
### Solenoids
First you will need a build a circuit to drive the solenoid through a mosfet as most MCU will not be able to provide the current needed to drive the coil in the solenoid.
The solenoid code supports relay switches, and similar hardware, as well as solenoids.
For a regular solenoid, you will need a build a circuit to drive the solenoid through a mosfet as most MCU will not be able to provide the current needed to drive the coil in the solenoid.
[Wiring diagram provided by Adafruit](https://cdn-shop.adafruit.com/product-files/412/solenoid_driver.pdf)
For relay switches, the hardware may already contain all of that ciruitry, and just require VCC, GND and a data pin.
|`SOLENOID_PIN` | *Not defined* |Configures the pin that the switch is connected to. |
|`SOLENOID_PIN_ACTIVE_LOW` | *Not defined* |If defined then the switch trigger pin is active low.|
|`SOLENOID_PINS` | *Not defined* |Configures an array of pins to be used for switch activation. |
|`SOLENOID_PINS_ACTIVE_LOW` | *Not defined* |Allows you to specify how each pin is pulled for activation. |
|`SOLENOID_RANDOM_FIRE` | *Not defined* |When there are multiple solenoids, will select a random one to fire.|
|`SOLENOID_DEFAULT_DWELL` | `12` ms |Configures the default dwell time for the switch. |
|`SOLENOID_MIN_DWELL` | `4` ms |Sets the lower limit for the dwell. |
|`SOLENOID_MAX_DWELL` | `100` ms |Sets the upper limit for the dwell. |
|`SOLENOID_DWELL_STEP_SIZE` | `1` ms |The step size to use when `HPT_DWL*` keycodes are sent |
|`SOLENOID_DWELL_STEP_SIZE` | `1` ms |The step size to use when `HPT_DWL*` keycodes are sent. |
|`SOLENOID_DEFAULT_BUZZ` | `0` (disabled) |On HPT_RST buzz is set "on" if this is "1" |
|`SOLENOID_BUZZ_ACTUATED` | `SOLENOID_MIN_DWELL` |Actuated-time when the solenoid is in buzz mode |
|`SOLENOID_BUZZ_NONACTUATED` | `SOLENOID_MIN_DWELL` |Non-Actuated-time when the solenoid is in buzz mode |
|`SOLENOID_BUZZ_ACTUATED` | `SOLENOID_MIN_DWELL` |Actuated-time when the switch is in buzz mode. |
|`SOLENOID_BUZZ_NONACTUATED` | `SOLENOID_MIN_DWELL` |Non-Actuated-time when the switch is in buzz mode. |
* If solenoid buzz is off, then dwell time is how long the "plunger" stays activated. The dwell time changes how the solenoid sounds.
* If solenoid buzz is on, then dwell time sets the length of the buzz, while `SOLENOID_BUZZ_ACTUATED` and `SOLENOID_BUZZ_NONACTUATED` set the (non-)actuation times withing the buzz period.
This is an integration of Peter Fleury's LCD library. This page will explain the basics. [For in depth documentation visit his page.](http://www.peterfleury.epizy.com/doxygen/avr-gcc-libraries/group__pfleury__lcd.html)
## Supported Hardware
You can enable support for HD44780 Displays by setting the `HD44780_ENABLE` flag in your keyboards `rules.mk` to yes.
LCD modules using [HD44780U](https://www.sparkfun.com/datasheets/LCD/HD44780.pdf) IC or equivalent, communicating in 4-bit mode.
#define LCD_DATA0_PORT LCD_PORT //< port for 4bit data bit 0
#define LCD_DATA1_PORT LCD_PORT //< port for 4bit data bit 1
#define LCD_DATA2_PORT LCD_PORT //< port for 4bit data bit 2
#define LCD_DATA3_PORT LCD_PORT //< port for 4bit data bit 3
#define LCD_DATA0_PIN 4 //< pin for 4bit data bit 0
#define LCD_DATA1_PIN 5 //< pin for 4bit data bit 1
#define LCD_DATA2_PIN 6 //< pin for 4bit data bit 2
#define LCD_DATA3_PIN 7 //< pin for 4bit data bit 3
#define LCD_RS_PORT LCD_PORT //< port for RS line
#define LCD_RS_PIN 3 //< pin for RS line
#define LCD_RW_PORT LCD_PORT //< port for RW line
#define LCD_RW_PIN 2 //< pin for RW line
#define LCD_E_PORT LCD_PORT //< port for Enable line
#define LCD_E_PIN 1 //< pin for Enable line
#endif
````
Should you need to configure other properties you can copy them from `quantum/hd44780.h` and set them in your `config.h`
To run these modules at 3.3V, an additional MAX660 voltage converter IC must be soldered on, along with two 10µF capacitors. See [this page](https://www.codrey.com/electronic-circuits/hack-your-16x2-lcd/) for more details.
## Usage
To initialize your display, call `lcd_init()` with one of these parameters:
````
LCD_DISP_OFF : display off
LCD_DISP_ON : display on, cursor off
LCD_DISP_ON_CURSOR : display on, cursor on
LCD_DISP_ON_CURSOR_BLINK : display on, cursor on flashing
````
This is best done in your keyboards `matrix_init_kb` or your keymaps `matrix_init_user`.
It is advised to clear the display before use.
To do so call `lcd_clrscr()`.
Add the following to your `rules.mk`:
To now print something to your Display you first call `lcd_gotoxy(column, line)`. To go to the start of the first line you would call `lcd_gotoxy(0, 0)` and then print a string with `lcd_puts("example string")`.
```make
HD44780_ENABLE= yes
```
There are more methods available to control the display. [For in depth documentation please visit the linked page.](http://www.peterfleury.epizy.com/doxygen/avr-gcc-libraries/group__pfleury__lcd.html)
|`HD44780_DATA_PINS` |*Not defined* |(Required) An array of four GPIO pins connected to the display's D4-D7 pins, eg. `{ B1, B3, B2, B6 }`|
|`HD44780_RS_PIN` |*Not defined* |(Required) The GPIO connected to the display's RS pin |
|`HD44780_RW_PIN` |*Not defined* |(Required) The GPIO connected to the display's RW pin |
|`HD44780_E_PIN` |*Not defined* |(Required) The GPIO connected to the display's E pin |
|`HD44780_DISPLAY_COLS` |`16` |The number of visible characters on a single line of the display |
|`HD44780_DISPLAY_LINES`|`2` |The number of visible lines on the display |
|`HD44780_WRAP_LINES` |*Not defined* |If defined, input characters will wrap to the next line |
## Examples
### Hello World
Add the following to your `keymap.c`:
```c
voidkeyboard_post_init_user(void){
hd44780_init(true,true);// Show blinking cursor
hd44780_puts_P(PSTR("Hello, world!\n"));
}
```
### Custom Character Definition
Up to eight custom characters can be defined. This data is stored in the Character Generator RAM (CGRAM), and is not persistent across power cycles.
This example defines the QMK Psi as the first custom character. The first 16 positions in the character set are reserved for the eight custom characters duplicated.
The index of the custom character to define, from 0 to 7.
-`uint8_t *data`
An array of 8 bytes containing the 5-bit row data of the character, where the first byte is the topmost row, and the least significant bit of each byte is the rightmost column.
On ARM devices, this function is simply an alias of `hd44780_define_char()`.
#### Arguments
-`uint8_t index`
The index of the custom character to define, from 0 to 7.
-`const uint8_t *data`
A PROGMEM array of 8 bytes containing the 5-bit row data of the character, where the first byte is the topmost row, and the least significant bit of each byte is the rightmost column.
---
### `bool hd44780_busy(void)`
Indicates whether the display is currently processing, and cannot accept instructions.
Whether the byte is an instruction or character data.
---
### `uint8_t hd44780_read(bool isData)`
Read a byte from the display.
#### Arguments
-`bool isData`
Whether to read the current cursor position, or the character at the cursor.
#### Return Value
If `isData` is `true`, the returned byte will be the character at the current DDRAM address. Otherwise, it will be the current DDRAM address and the busy flag.
---
### `void hd44780_command(uint8_t command)`
Send a command to the display. Refer to the datasheet and `hd44780.h` for the valid commands and defines.
This function waits for the display to clear the busy flag before sending the command.
#### Arguments
-`uint8_t command`
The command to send.
---
### `void hd44780_data(uint8_t data)`
Send a byte of data to the display.
This function waits for the display to clear the busy flag before sending the data.
@@ -150,3 +150,5 @@ Note that the supported AVR MCUs have a 10-bit ADC, and 12-bit for most STM32 MC
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.
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).
@@ -11,13 +11,13 @@ QMK provides methods to read 5 of the LEDs defined in the HID spec:
* Kana
There are three ways to get the lock LED state:
*by specifying configuration options within `config.h`
*by implementing `bool led_update_kb(led_t led_state)` or `_user(led_t led_state)`; or
*by calling`led_t host_keyboard_led_state()`
*Configuration options in `config.h`
*Implement`led_update_*` function
*Call`led_t host_keyboard_led_state()`
!> `host_keyboard_led_state()` may already reflect a new value before `led_update_user()` is called.
!> The`host_keyboard_led_state()` may reflect an updated state before `led_update_user()` is called.
Two more deprecated functions exist that provide the LED state as a `uint8_t`:
Two deprecated functions that provide the LED state as `uint8_t`:
*`uint8_t led_set_kb(uint8_t usb_led)` and `_user(uint8_t usb_led)`
*`uint8_t host_keyboard_leds()`
@@ -37,23 +37,20 @@ To configure the indicators, `#define` these in your `config.h`:
Unless you are designing your own keyboard, you generally should not need to change the above config options.
## `led_update_*()`
## LED update function
When the configuration options do not provide enough flexibility, the API hooks provided allow custom control of the LED behavior. These functions will be called when the state of one of those 5 LEDs changes. It receives the LED state as a struct parameter.
When the configuration options do not provide enough flexibility, the following callbacks allow custom control of the LED behavior. These functions will be called when one of those 5 LEDs changes state:
By convention, return `true` from `led_update_user()` to get the `led_update_kb()` hook to run its code, and
return `false` when you would prefer not to run the code in `led_update_kb()`.
Both receives LED state as a struct parameter. Returning `true` in `led_update_user()` will allow the keyboard level code in `led_update_kb()` to run as well. Returning `false` will override the keyboard level code, depending on how the keyboard level function is set up.
- overriding the LEDs to use them for something else like layer indication
- return `false` because you do not want the `_kb()` function to run, as it would override your layer behavior.
- play a sound when an LED turns on or off.
- return `true` because you want the `_kb` function to run, and this is in addition to the default LED behavior.
?> This boolean return type of `led_update_user` allows for overriding keyboard LED controls, and is thus recommended over the void `led_set_user` function.
?> Because the `led_set_*` functions return `void` instead of `bool`, they do not allow for overriding the keyboard LED control, and thus it's recommended to use `led_update_*` instead.
### Example of keyboard LED update implementation
### Example `led_update_kb()` Implementation
This is a template indicator function that can be implemented on keyboard level code:
This incomplete example would play a sound if Caps Lock is turned on or off. It returns `true`, because you also want the LEDs to maintain their state.
This is an incomplete example will play a sound if Caps Lock is turned on or off. It returns `true` to allow keyboard LED function to maintain their state.
The `host_keyboard_led_state()` function will report the LED state returned from the host computer as `led_t`. This is useful for reading the LED state outside `led_update_*`. For example, you can get the boolean state of Caps Lock from the host with:
## `host_keyboard_led_state()`
Call this function to get the last received LED state as a `led_t`. This is useful for reading the LED state outside `led_update_*`, e.g. in [`matrix_scan_user()`](#matrix-scanning-code).
```c
boolcaps=host_keyboard_led_state().caps_lock;
```
## Setting Physical LED State
Some keyboard implementations provide convenience methods for setting the state of the physical LEDs.
Some keyboard implementations provide convenient methods for setting the state of the physical LEDs.
@@ -106,6 +106,8 @@ Only basic keycodes (prefixed by `KC_`) are supported. Do not include the `KC_`
### `SEND_STRING()` & `process_record_user`
See also: [Send String](feature_send_string.md)
Sometimes you want a key to type out words or phrases. For the most common situations, we've provided `SEND_STRING()`, which will type out a string (i.e. a sequence of characters) for you. All ASCII characters that are easily translatable to a keycode are supported (e.g. `qmk 123\n\t`).
Here is an example `keymap.c` for a two-key keyboard:
There are two MIDI systems in QMK: basic and advanced. With basic MIDI you will only be able to send Note On and Note Off messages using the note keycodes, meaning that keycodes like `MI_OCTU` and `MI_OCTD` will not work. Advanced MIDI allows you to do things like octave shifts, channel changes, velocity changes, modulation, and more.
### Caveats
MIDI requires 2 USB endpoints and as such may not work on some hardware such as V-USB controllers.
### Basic MIDI
To enable basic MIDI, add the following to your `config.h`:
@@ -254,7 +258,7 @@ For the above, the `MI_C` keycode will produce a C3 (note number 48), and so on.
|`MOUSEKEY_WHEEL_INITIAL_MOVEMENTS` |16 |Initial number of movements of the mouse wheel |
@@ -100,7 +100,7 @@ This is an extension of the accelerated mode. The kinetic mode uses a quadratic
Tips:
* The smoothness of the cursor movement depends on the `MOUSEKEY_INTERVAL` setting. The shorter the interval is set the smoother the movement will be. Setting the value too low makes the cursor unresponsive. Lower settings are possible if the micro processor is fast enough. For example: At an interval of `8` milliseconds, `125` movements per second will be initiated. With a base speed of `1000` each movement will move the cursor by `8` pixels.
* Mouse wheel movements are implemented differently from cursor movements. While it's okay for the cursor to move multiple pixels at once for the mouse wheel this would lead to jerky movements. Instead, the mouse wheel operates at step size `1`. Setting mouse wheel speed is done by adjusting the number of wheel movements per second.
* Mouse wheel movements are implemented differently from cursor movements. While it's okay for the cursor to move multiple pixels at once for the mouse wheel this would lead to jerky movements. Instead, the mouse wheel operates at step size `2`. Setting mouse wheel speed is done by adjusting the number of wheel movements per second.
This supports the Cirque Pinnacle 1CA027 Touch Controller, which is used in the TM040040, TM035035 and the TM023023 trackpads. These are I2C or SPI compatible, and both configurations are supported.
**`CIRQUE_PINNACLE_ATTENUATION`** is a measure of how much data is suppressed in regards to sensitivity. The higher the attenuation, the less sensitive the touchpad will be.
Default attenuation is set to 4X, although if you are using a thicker overlay (such as the curved overlay) you will want a lower attenuation such as 2X. The possible values are:
|`CIRQUE_PINNACLE_CLOCK_SPEED` | (Optional) Sets the clock speed that the sensor runs at. | `1000000` |
|`CIRQUE_PINNACLE_SPI_LSBFIRST` | (Optional) Sets the Least/Most Significant Byte First setting for SPI. | `false` |
|`CIRQUE_PINNACLE_SPI_MODE` | (Optional) Sets the SPI Mode for the sensor. | `1` |
|`CIRQUE_PINNACLE_SPI_DIVISOR` | (Optional) Sets the SPI Divisor used for SPI communication. | _varies_ |
|`CIRQUE_PINNACLE_SPI_CS_PIN` | (Required) Sets the Cable Select pin connected to the sensor. | _not defined_ |
Default Scaling is 1024. Actual CPI depends on trackpad diameter.
Also see the `POINTING_DEVICE_TASK_THROTTLE_MS`, which defaults to 10ms when using Cirque Pinnacle, which matches the internal update rate of the position registers (in standard configuration). Advanced configuration for pen/stylus usage might require lower values.
| `POINTING_DEVICE_GESTURES_CURSOR_GLIDE_ENABLE` | (Optional) Enable inertial cursor. Cursor continues moving after a flick gesture and slows down by kinetic friction | _not defined_ |
| `CIRQUE_PINNACLE_CIRCULAR_SCROLL_ENABLE` | (Optional) Enable circular scroll. Touch originating in outer ring can trigger scroll by moving along the perimeter. Near side triggers vertical scroll and far side triggers horizontal scroll. | _not defined_ |
| `CIRQUE_PINNACLE_TAP_ENABLE` | (Optional) Enable tap to click. This currently only works on the master side. | _not defined_ |
| `CIRQUE_PINNACLE_TAPPING_TERM` | (Optional) Length of time that a touch can be to be considered a tap. | `TAPPING_TERM`/`200` |
| `CIRQUE_PINNACLE_TOUCH_DEBOUNCE` | (Optional) Length of time that a touch can be to be considered a tap. | `TAPPING_TERM`/`200` |
**`POINTING_DEVICE_GESTURES_CURSOR_GLIDE_ENABLE`** is not specific to Cirque trackpad; any pointing device with a lift/contact status can integrate this gesture into its driver. e.g. PMW3360 can use Lift_Stat from Motion register. Note that `POINTING_DEVICE_MOTION_PIN` cannot be used with this feature; continuous polling of `pointing_device_get_report()` is needed to generate glide reports.
### PAW 3204 Sensor
To use the paw 3204 sensor, add this to your `rules.mk`
```make
POINTING_DEVICE_DRIVER= paw3204
```
The paw 3204 sensor uses a serial type protocol for communication, and requires an additional light source.
|`PIMORONI_TRACKBALL_ADDRESS` | (Required) Sets the I2C Address for the Pimoroni Trackball. | `0x0A` |
|`PIMORONI_TRACKBALL_TIMEOUT` | (Optional) The timeout for i2c communication with the trackball in milliseconds. | `100` |
|`PIMORONI_TRACKBALL_SCALE` | (Optional) The multiplier used to generate reports from the sensor. | `5` |
|`PIMORONI_TRACKBALL_DEBOUNCE_CYCLES` | (Optional) The number of scan cycles used for debouncing on the ball press. | `20` |
|`PIMORONI_TRACKBALL_ERROR_COUNT` | (Optional) Specifies the number of read/write errors until the sensor is disabled. | `10` |
### PMW 3360 Sensor
### PMW 3360 and PMW 3389 Sensor
To use the PMW 3360 sensor, add this to your `rules.mk`
This drivers supports both the PMW 3360 and PMW 3389 sensor as well as multiple sensors of the same type _per_ controller, so 2 can be attached at the same side for split keyboards (or unsplit keyboards).
To use the **PMW 3360** sensor, add this to your `rules.mk`
```make
POINTING_DEVICE_DRIVER= pmw3360
```
The PMW 3360 is an SPI driven optical sensor, that uses a built in IR LED for surface tracking.
| `PMW33XX_CS_PIN` | (Required) Sets the Cable Select pin connected to the sensor. | _not defined_ |
| `PMW33XX_CS_PINS` | (Alternative) Sets the Cable Select pins connected to multiple sensors. | _not defined_ |
| `PMW33XX_CPI` | (Optional) Sets counts per inch sensitivity of the sensor. | _varies_ |
| `PMW33XX_CLOCK_SPEED` | (Optional) Sets the clock speed that the sensor runs at. | `2000000` |
| `PMW33XX_SPI_DIVISOR` | (Optional) Sets the SPI Divisor used for SPI communication. | _varies_ |
| `PMW33XX_LIFTOFF_DISTANCE` | (Optional) Sets the lift off distance at run time | `0x02` |
| `ROTATIONAL_TRANSFORM_ANGLE` | (Optional) Allows for the sensor data to be rotated +/- 127 degrees directly in the sensor. | `0` |
To use multiple sensors, instead of setting `PMW33XX_CS_PIN` you need to set `PMW33XX_CS_PINS` and also handle and merge the read from this sensor in user code.
Note that different (per sensor) values of CPI, speed liftoff, rotational angle or flipping of X/Y is not currently supported.
```c
// in config.h:
#define PMW33XX_CS_PINS { B5, B6 }
// in keyboard.c:
#ifdef POINTING_DEVICE_ENABLE
voidpointing_device_init_kb(void){
pmw33xx_init(1);// index 1 is the second device.
pmw33xx_set_cpi(0,800);// applies to first sensor
pmw33xx_set_cpi(1,800);// applies to second sensor
pointing_device_init_user();
}
// Contains report from sensor #0 already, need to merge in from sensor #1
|`POINTING_DEVICE_ROTATION_90` | (Optional) Rotates the X and Y data by 90 degrees. | _not defined_ |
|`POINTING_DEVICE_ROTATION_180` | (Optional) Rotates the X and Y data by 180 degrees. | _not defined_ |
|`POINTING_DEVICE_ROTATION_270` | (Optional) Rotates the X and Y data by 270 degrees. | _not defined_ |
|`POINTING_DEVICE_INVERT_X` | (Optional) Inverts the X axis report. | _not defined_ |
|`POINTING_DEVICE_INVERT_Y` | (Optional) Inverts the Y axis report. | _not defined_ |
|`POINTING_DEVICE_MOTION_PIN` | (Optional) If supported, will only read from sensor if pin is active. | _not defined_ |
|`POINTING_DEVICE_TASK_THROTTLE_MS` | (Optional) Limits the frequency that the sensor is polled for motion. | _not defined_ |
!> When using `SPLIT_POINTING_ENABLE` the `POINTING_DEVICE_MOTION_PIN` functionality is not supported and `POINTING_DEVICE_TASK_THROTTLE_MS` will default to `1`. Increasing this value will increase transport performance at the cost of possible mouse responsiveness.
The following configuration options are only available when using `SPLIT_POINTING_ENABLE` see [data sync options](feature_split_keyboard.md?id=data-sync-options). The rotation and invert `*_RIGHT` options are only used with `POINTING_DEVICE_COMBINED`. If using `POINTING_DEVICE_LEFT` or `POINTING_DEVICE_RIGHT` use the common configuration above to configure your pointing device.
|`POINTING_DEVICE_LEFT` | Pointing device on the left side (Required - pick one only) | _not defined_ |
|`POINTING_DEVICE_RIGHT` | Pointing device on the right side (Required - pick one only) | _not defined_ |
|`POINTING_DEVICE_COMBINED` | Pointing device on both sides (Required - pick one only) | _not defined_ |
|`POINTING_DEVICE_ROTATION_90_RIGHT` | (Optional) Rotates the X and Y data by 90 degrees. | _not defined_ |
|`POINTING_DEVICE_ROTATION_180_RIGHT` | (Optional) Rotates the X and Y data by 180 degrees. | _not defined_ |
|`POINTING_DEVICE_ROTATION_270_RIGHT` | (Optional) Rotates the X and Y data by 270 degrees. | _not defined_ |
|`POINTING_DEVICE_INVERT_X_RIGHT` | (Optional) Inverts the X axis report. | _not defined_ |
|`POINTING_DEVICE_INVERT_Y_RIGHT` | (Optional) Inverts the Y axis report. | _not defined_ |
| `MOUSE_EXTENDED_REPORT` | (Optional) Enables support for extended mouse reports. (-32767 to 32767, instead of just -127 to 127) |
!> If there is a `_RIGHT` configuration option or callback, the [common configuration](feature_pointing_device.md?id=common-configuration) option will work for the left. For correct left/right detection you should setup a [handedness option](feature_split_keyboard?id=setting-handedness), `EE_HANDS` is usually a good option for an existing board that doesn't do handedness by hardware.
@@ -234,7 +290,7 @@ The following configuration options are only available when using `SPLIT_POINTIN
| `pointing_device_init_kb(void)` | Callback to allow for keyboard level initialization. Useful for additional hardware sensors. |
| `pointing_device_init_user(void)` | Callback to allow for user level initialization. Useful for additional hardware sensors. |
| `pointing_device_task_kb(mouse_report)` | Callback that sends sensor data, so keyboard code can intercept and modify the data. Returns a mouse report. |
@@ -254,7 +310,7 @@ The following configuration options are only available when using `SPLIT_POINTIN
The combined functions below are only available when using `SPLIT_POINTING_ENABLE` and `POINTING_DEVICE_COMBINED`. The 2 callbacks `pointing_device_task_combined_*` replace the single sided equivalents above. See the [combined pointing devices example](feature_pointing_device.md?id=combined-pointing-devices)
| `pointing_device_set_shared_report(mouse_report)` | Sets the shared mouse report to the assigned `mouse_report_t` data structured passed to the function. |
| `pointing_device_set_cpi_on_side(bool, uint16_t)` | Sets the CPI/DPI of one side, if supported. Passing `true` will set the left and `false` the right` |
| `pointing_device_combine_reports(left_report, right_report)` | Returns a combined mouse_report of left_report and right_report (as a `mouse_report_t` data structure) |
@@ -86,6 +86,7 @@ You can use between 1 and 4 IS31FL3733 IC's. Do not specify `DRIVER_ADDR_<N>` de
| `ISSI_TIMEOUT` | (Optional) How long to wait for i2c messages, in milliseconds | 100 |
| `ISSI_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 |
| `ISSI_PWM_FREQUENCY` | (Optional) PWM Frequency Setting - IS31FL3733B only | 0 |
| `ISSI_GLOBALCURRENT` | (Optional) Configuration for the Global Current Register | 0xFF |
| `ISSI_SWPULLUP` | (Optional) Set the value of the SWx lines on-chip de-ghosting resistors | PUR_0R (Disabled) |
| `ISSI_CSPULLUP` | (Optional) Set the value of the CSx lines on-chip de-ghosting resistors | PUR_0R (Disabled) |
| `DRIVER_COUNT` | (Required) How many RGB driver IC's are present | |
@@ -171,6 +172,8 @@ Configure the hardware via your `config.h`:
|----------|-------------|---------|
| `ISSI_TIMEOUT` | (Optional) How long to wait for i2c messages, in milliseconds | 100 |
| `ISSI_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 |
| `ISSI_PWM_FREQUENCY` | (Optional) PWM Frequency Setting - IS31FL3737B only | 0 |
| `ISSI_GLOBALCURRENT` | (Optional) Configuration for the Global Current Register | 0xFF |
| `ISSI_SWPULLUP` | (Optional) Set the value of the SWx lines on-chip de-ghosting resistors | PUR_0R (Disabled) |
| `ISSI_CSPULLUP` | (Optional) Set the value of the CSx lines on-chip de-ghosting resistors | PUR_0R (Disabled) |
| `DRIVER_COUNT` | (Required) How many RGB driver IC's are present | |
@@ -408,6 +411,7 @@ You can use up to 2 AW20216 IC's. Do not specify `DRIVER_<N>_xxx` defines for IC
| `DRIVER_LED_TOTAL` | (Required) How many RGB lights are present across all drivers | |
| `AW_SCALING_MAX` | (Optional) LED current scaling value (0-255, higher values mean LED is brighter at full PWM) | 150 |
| `AW_GLOBAL_CURRENT_MAX` | (Optional) Driver global current limit (0-255, higher values means the driver may consume more power) | 150 |
| `AW_SPI_MODE` | (Optional) Mode for SPI communication (0-3, defines polarity and phase of the clock) | 3 |
| `AW_SPI_DIVISOR` | (Optional) Clock divisor for SPI communication (powers of 2, smaller numbers means faster communication, should not be less than 4) | 4 |
Here is an example using 2 drivers.
@@ -519,7 +523,7 @@ All RGB keycodes are currently shared with the RGBLIGHT system:
|`RGB_VAD` | |Decrease value (brightness), increase value when Shift is held |
|`RGB_SPI` | |Increase effect speed (does not support eeprom yet), decrease speed when Shift is held|
|`RGB_SPD` | |Decrease effect speed (does not support eeprom yet), increase speed when Shift is held|
|`RGB_MODE_PLAIN` |`RGB_M_P`|Static (no animation) mode |
|`RGB_MODE_PLAIN` |`RGB_M_P`|Static (no animation) mode |
This effect will color the RGB matrix according to a heatmap of recently pressed
keys. Whenever a key is pressed its "temperature" increases as well as that of
its neighboring keys. The temperature of each key is then decreased
automatically every 25 milliseconds by default.
This effect will color the RGB matrix according to a heatmap of recently pressed keys. Whenever a key is pressed its "temperature" increases as well as that of its neighboring keys. The temperature of each key is then decreased automatically every 25 milliseconds by default.
In order to change the delay of temperature decrease define
`RGB_MATRIX_TYPING_HEATMAP_DECREASE_DELAY_MS`:
In order to change the delay of temperature decrease define`RGB_MATRIX_TYPING_HEATMAP_DECREASE_DELAY_MS`:
As heatmap uses the physical position of the leds set in the g_led_config, you may need to tweak the following options to get the best effect for your keyboard. Note the size of this grid is `224x64`.
Limit the distance the effect spreads to surrounding keys.
```c
#define RGB_MATRIX_TYPING_HEATMAP_SPREAD 40
```
Limit how hot surrounding keys get from each press.
Solid reactive effects will pulse RGB light on key presses with user configurable hues. To enable gradient mode that will automatically change reactive color, add the following define:
```c
#define RGB_MATRIX_SOLID_REACTIVE_GRADIENT_MODE
```
Gradient mode will loop through the color wheel hues over time and its duration can be controlled with the effect speed keycodes (`RGB_SPI`/`RGB_SPD`).
By setting `RGB_MATRIX_CUSTOM_USER = yes` in `rules.mk`, new effects can be defined directly from your keymap or userspace, without having to edit any QMK core files. To declare new effects, create a `rgb_matrix_user.inc` file in the user keymap directory or userspace folder.
@@ -775,6 +805,7 @@ These are defined in [`color.h`](https://github.com/qmk/qmk_firmware/blob/master
#define RGB_MATRIX_DISABLE_KEYCODES // disables control of rgb matrix by keycodes (must use code functions to control the feature)
#define RGB_MATRIX_SPLIT { X, Y } // (Optional) For split keyboards, the number of LEDs connected on each half. X = left, Y = Right.
// If RGB_MATRIX_KEYPRESSES or RGB_MATRIX_KEYRELEASES is enabled, you also will want to enable SPLIT_TRANSPORT_MIRROR
#define RGB_TRIGGER_ON_KEYDOWN // Triggers RGB keypress events on key down. This makes RGB control feel more responsive. This may cause RGB to not function properly on some boards
would turn the layer 0 (or 1) on and off again three times when `DEBUG` is pressed.
Blinking accumulates layers so if multiple layers are set blinking at the same time they will all blink for the duration and repeat times of the last layer to be blinked.
To stop these other layers from blinking use `rgblight_unblink_layer` or `rgblight_unblink_all_but_layer`:
```c
rgblight_blink_layer(1,500);
rgblight_unblink_all_but_layer(1);
```
```c
rgblight_unblink_layer(3);
rgblight_blink_layer(2,500);
```
!> Lighting layers on split keyboards will require layer state synced to the slave half (e.g. `#define SPLIT_LAYER_STATE_ENABLE`). See [data sync options](feature_split_keyboard.md#data-sync-options) for more details.
The secure feature aims to prevent unwanted interaction without user intervention.
?> Secure does **not** currently implement encryption/decryption/etc and should not be a replacement where a strong hardware/software based solution is required.
### Unlock sequence
To unlock, the user must perform a set of actions. This can optionally be configured to be multiple keys.
* While unlocking all keyboard input is ignored
* Incorrect attempts will revert back to the previously locked state
### Automatic Locking
Once unlocked, the keyboard will revert back to a locked state after the configured timeout.
The timeout can be refreshed by using the `secure_activity_event` function, for example from one of the various [hooks](custom_quantum_functions.md).
The Send String API is part of QMK's macro system. It allows for sequences of keystrokes to be sent automatically.
The full ASCII character set is supported, along with all of the keycodes in the Basic Keycode range (as these are the only ones that will actually be sent to the host).
?> Unicode characters are **not** supported with this API -- see the [Unicode](feature_unicode.md) feature instead.
## Usage
Send String is enabled by default, so there is usually no need for any special setup. However, if it is disabled, add the following to your `rules.mk`:
|`SENDSTRING_BELL`|*Not defined* |If the [Audio](feature_audio.md) feature is enabled, the `\a` character (ASCII `BEL`) will beep the speaker.|
|`BELL_SOUND` |`TERMINAL_SOUND`|The song to play when the `\a` character is encountered. By default, this is an eighth note of C5. |
## Keycodes
The Send String functions accept C string literals, but specific keycodes can be injected with the below macros. All of the keycodes in the [Basic Keycode range](keycodes_basic.md) are supported (as these are the only ones that will actually be sent to the host), but with an `X_` prefix instead of `KC_`.
|`SS_TAP(x)` |Send a keydown, then keyup, event for the given Send String keycode|
|`SS_DOWN(x)` |Send a keydown event for the given Send String keycode |
|`SS_UP(x)` |Send a keyup event for the given Send String keycode |
|`SS_DELAY(ms)`|Wait for `ms` milliseconds |
The following characters are also mapped to their respective keycodes for convenience:
|Character|Hex |ASCII|Keycode |
|---------|------|-----|--------------|
|`\b` |`\x08`|`BS` |`KC_BACKSPACE`|
|`\e` |`\x09`|`ESC`|`KC_ESCAPE` |
|`\n` |`\x0A`|`LF` |`KC_ENTER` |
|`\t` |`\x1B`|`TAB`|`KC_TAB` |
| |`\x7F`|`DEL`|`KC_DELETE` |
### Language Support
By default, Send String assumes your OS keyboard layout is set to US ANSI. If you are using a different keyboard layout, you can [override the lookup tables used to convert ASCII characters to keystrokes](reference_keymap_extras.md#sendstring-support).
## Examples
### Hello World
A simple custom keycode which types out "Hello, world!" and the Enter key when pressed.
@@ -10,6 +10,8 @@ For this, we will mostly be talking about the generic implementation used by the
!> ARM split supports most QMK subsystems when using the 'serial' and 'serial_usart' drivers. I2C slave is currently unsupported.
!> Both sides must use the same MCU family, for eg two Pro Micro-compatible controllers or two Blackpills. Currently, mixing AVR and ARM is not possible as ARM vs AVR uses different method for serial communication, and are not compatible. Moreover Blackpill's uses 3.3v logic, and atmega32u4 uses 5v logic.
## Compatibility Overview
| Transport | AVR | ARM |
@@ -141,6 +143,9 @@ Next, you will have to flash the EEPROM files once for the correct hand to the c
* ARM controllers with a DFU compatible bootloader (e.g. Proton-C):
*`:dfu-util-split-left`
*`:dfu-util-split-right`
* ARM controllers with a UF2 compatible bootloader:
*`:uf2-split-left`
*`:uf2-split-right`
Example:
@@ -365,7 +370,7 @@ There are some settings that you may need to configure, based on how the hardwar
#define MATRIX_COL_PINS_RIGHT { <col pins> }
```
This allows you to specify a different set of pins for the matrix on the right side. This is useful if you have a board with differently-shaped halves that requires a different configuration (such as Keebio's Quefrency).
This allows you to specify a different set of pins for the matrix on the right side. This is useful if you have a board with differently-shaped halves that requires a different configuration (such as Keebio's Quefrency). The number of pins in the right and left matrices must be the same, if you have a board with a different number of rows or columns on one side, pad out the extra spaces with `NO_PIN` and make sure you add the unused rows or columns to your matrix.
@@ -8,46 +8,107 @@ The [Open Steno Project](https://www.openstenoproject.org/) has built an open-so
Plover can work with any standard QWERTY keyboard, although it is more efficient if the keyboard supports NKRO (n-key rollover) to allow Plover to see all the pressed keys at once. An example keymap for Plover can be found in `planck/keymaps/default`. Switching to the `PLOVER` layer adjusts the position of the keyboard to support the number bar.
To use Plover with QMK just enable NKRO and optionally adjust your layout if you have anything other than a standard layout. You may also want to purchase some steno-friendly keycaps to make it easier to hit multiple keys.
To enable NKRO, add `NKRO_ENABLE = yes` in your `rules.mk` and make sure to press `NK_ON` to turn it on because `NKRO_ENABLE = yes` merely adds the possibility of switching to NKRO mode but it doesn't automatically switch to it. If you want to automatically switch, add `#define FORCE_NKRO` in your `config.h`.
You may also need to adjust your layout, either in QMK or in Plover, if you have anything other than a standard layout. You may also want to purchase some steno-friendly keycaps to make it easier to hit multiple keys.
## Plover with Steno Protocol :id=plover-with-steno-protocol
Plover also understands the language of several steno machines. QMK can speak a couple of these languages, TX Bolt and GeminiPR. An example layout can be found in `planck/keymaps/steno`.
Plover also understands the language of several steno machines. QMK can speak a couple of these languages: TX Bolt and GeminiPR. An example layout can be found in `planck/keymaps/steno`.
When QMK speaks to Plover over a steno protocol Plover will not use the keyboard as input. This means that you can switch back and forth between a standard keyboard and your steno keyboard, or even switch layers from Plover to standard and back without needing to activate/deactivate Plover.
When QMK speaks to Plover over a steno protocol, Plover will not use the keyboard as input. This means that you can switch back and forth between a standard keyboard and your steno keyboard, or even switch layers from Plover to standard and back without needing to activate/deactivate Plover.
In this mode Plover expects to speak with a steno machine over a serial port so QMK will present itself to the operating system as a virtual serial port in addition to a keyboard. By default QMK will speak the TX Bolt protocol but can be switched to GeminiPR; the last protocol used is stored in non-volatile memory so QMK will use the same protocol on restart.
In this mode, Plover expects to speak with a steno machine over a serial port so QMK will present itself to the operating system as a virtual serial port in addition to a keyboard.
> Note: Due to hardware limitations you may not be able to run both a virtual serial port and mouse emulation at the same time.
> Note: Due to hardware limitations, you might not be able to run both a virtual serial port and mouse emulation at the same time.
!> Serial stenography protocols are not supported on [V-USB keyboards](compatible_microcontrollers#atmel-avr).
To enable stenography protocols, add the following lines to your `rules.mk`:
```mk
STENO_ENABLE= yes
```
### TX Bolt :id=tx-bolt
TX Bolt communicates the status of 24 keys over a very simple protocol in variable-sized (1-5 byte) packets.
TX Bolt communicates the status of 24 keys over a simple protocol in variable-sized (1–4 bytes) packets.
To select TX Bolt, add the following lines to your `rules.mk`:
```mk
STENO_ENABLE= yes
STENO_PROTOCOL= txbolt
```
Each byte of the packet represents a different group of steno keys. Determining the group of a certain byte of the packet is done by checking the first two bits, the remaining bits are set if the corresponding steno key was pressed for the stroke. The last set of keys (as indicated by leading `11`) needs to keep track of less keys than there are bits so one of the bits is constantly 0.
The start of a new packet can be detected by comparing the group “ID” (the two MSBs) of the current byte to that of the previously received byte. If the group “ID” of the current byte is smaller or equal to that of the previous byte, it means that the current byte is the beginning of a new packet.
The format of TX Bolt packets is shown below.
```
00HWPKTS 01UE*OAR 10GLBPRF 110#ZDST
```
Examples of steno strokes and the associated packet:
GeminiPR encodes 42 keys into a 6-byte packet. While TX Bolt contains everything that is necessary for standard stenography, GeminiPR opens up many more options, including supporting non-English theories.
GeminiPR encodes 42 keys into a 6-byte packet. While TX Bolt contains everything that is necessary for standard stenography, GeminiPR opens up many more options, including differentiating between top and bottom `S-`, and supporting non-English theories.
To select GeminiPR, add the following lines to your `rules.mk`:
```mk
STENO_ENABLE= yes
STENO_PROTOCOL= geminipr
```
All packets in the GeminiPR protocol consist of exactly six bytes, used as bit-arrays for different groups of keys. The beginning of a packet is indicated by setting the most significant bit (MSB) to 1 while setting the MSB of the remaining five bytes to 0.
The format of GeminiPR packets is shown below.
```
1 Fn #1 #2 #3 #4 #5 #6
0 S1- S2- T- K- P- W- H-
0 R- A- O- *1 *2 res1 res2
0 pwr *3 *4 -E -U -F -R
0 -P -B -L -G -T -S -D
0 #7 #8 #9 #A #B #C -Z
```
Examples of steno strokes and the associated packet:
### Switching protocols on the fly :id=switching-protocols-on-the-fly
If you wish to switch the serial protocol used to transfer the steno chords without having to recompile your keyboard firmware every time, you can press the `QK_STENO_BOLT` and `QK_STENO_GEMINI` keycodes in order to switch protocols on the fly.
To enable these special keycodes, add the following lines to your `rules.mk`:
```mk
STENO_ENABLE= yes
STENO_PROTOCOL= all
```
If you want to switch protocols programatically, as part of a custom macro for example, don't use `tap_code(QK_STENO_*)`, as `tap_code` only supports [basic keycodes](keycodes_basic). Instead, you should use `steno_set_mode(STENO_MODE_*)`, whose valid arguments are `STENO_MODE_BOLT` and `STENO_MODE_GEMINI`.
The default protocol is Gemini PR but the last protocol used is stored in non-volatile memory so QMK will remember your choice between reboots of your keyboard — assuming that your keyboard features (emulated) EEPROM.
Naturally, this option takes the most amount of firmware space as it needs to compile the code for all the available stenography protocols. In most cases, compiling a single stenography protocol is sufficient.
The default value for `STENO_PROTOCOL` is `all`.
## Configuring QMK for Steno :id=configuring-qmk-for-steno
Firstly, enable steno in your keymap's Makefile. You may also need disable mousekeys, extra keys, or another USB endpoint to prevent conflicts. The builtin USB stack for some processors only supports a certain number of USB endpoints and the virtual serial port needed for steno fills 3 of them.
After enabling stenography and optionally selecting a protocol, you may also need disable mousekeys, extra keys, or another USB endpoint to prevent conflicts. The builtin USB stack for some processors only supports a certain number of USB endpoints and the virtual serial port needed for steno fills 3 of them.
```make
STENO_ENABLE= yes
MOUSEKEY_ENABLE= no
```
!> If you had *explicitly* set `VIRSTER_ENABLE = no`, none of the serial stenography protocols (GeminiPR, TX Bolt) will work properly. You are expected to either set it to `yes`, remove the line from your `rules.mk` or send the steno chords yourself in an alternative way using the [provided interceptable hooks](#interfacing-with-the-code).
In your keymap create a new layer for Plover. You will need to include `keymap_steno.h`. See `planck/keymaps/steno/keymap.c` for an example. Remember to create a key to switch to the layer as well as a key for exiting the layer. If you would like to switch modes on the fly you can use the keycodes `QK_STENO_BOLT` and `QK_STENO_GEMINI`. If you only want to use one of the protocols you may set it up in your initialization function:
In your keymap, create a new layer for Plover, that you can fill in with the [steno keycodes](#keycode-reference) (you will need to include `keymap_steno.h`, see `planck/keymaps/steno/keymap.c` for an example). Remember to create a key to switch to the layer as well as a key for exiting the layer.
```c
voideeconfig_init_user(){
steno_set_mode(STENO_MODE_GEMINI);// or STENO_MODE_BOLT
}
```
Once you have your keyboard flashed, launch Plover. Click the 'Configure...' button. In the 'Machine' tab, select the Stenotype Machine that corresponds to your desired protocol. Click the 'Configure...' button on this tab and enter the serial port or click 'Scan'. Baud rate is fine at 9600 (although you should be able to set as high as 115200 with no issues). Use the default settings for everything else (Data Bits: 8, Stop Bits: 1, Parity: N, no flow control).
Once you have your keyboard flashed launch Plover. Click the 'Configure...' button. In the 'Machine' tab select the Stenotype Machine that corresponds to your desired protocol. Click the 'Configure...' button on this tab and enter the serial port or click 'Scan'. Baud rate is fine at 9600 (although you should be able to set as high as 115200 with no issues). Use the default settings for everything else (Data Bits: 8, Stop Bits: 1, Parity: N, no flow control).
On the display tab click 'Open stroke display'. With Plover disabled you should be able to hit keys on your keyboard and see them show up in the stroke display window. Use this to make sure you have set up your keymap correctly. You are now ready to steno!
To test your keymap, you can chord keys on your keyboard and either look at the output of the 'paper tape' (Tools > Paper Tape) or that of the 'layout display' (Tools > Layout Display). If your strokes correctly show up, you are now ready to steno!
## Learning Stenography :id=learning-stenography
@@ -60,7 +121,7 @@ On the display tab click 'Open stroke display'. With Plover disabled you should
The steno code has three interceptable hooks. If you define these functions, they will be called at certain points in processing; if they return true, processing continues, otherwise it's assumed you handled things.
This function is called when a chord is about to be sent. Mode will be one of `STENO_MODE_BOLT` or `STENO_MODE_GEMINI`. This represents the actual chord that would be sent via whichever protocol. You can modify the chord provided to alter what gets sent. Remember to return true if you want the regular sending process to happen.
This function is called when a keypress has come in, before it is processed. The keycode should be one of `QK_STENO_BOLT`, `QK_STENO_GEMINI`, or one of the `STN_*` key values.
This function is called after a key has been processed, but before any decision about whether or not to send a chord. If `IS_PRESSED(record->event)` is false, and `pressed` is 0 or 1, the chord will be sent shortly, but has not yet been sent. This is where to put hooks for things like, say, live displays of steno chords or keys.
This function is called after a key has been processed, but before any decision about whether or not to send a chord. This is where to put hooks for things like, say, live displays of steno chords or keys.
If `IS_PRESSED(record->event)` is false, and `n_pressed_keys` is 0 or 1, the chord will be sent shortly, but has not yet been sent. This relieves you of the need of keeping track of where a packet ends and another begins.
The `chord` argument contains the packet of the current chord as specified by the protocol in use. This is *NOT* simply a list of chorded steno keys of the form `[STN_E, STN_U, STN_BR, STN_GR]`. Refer to the appropriate protocol section of this document to learn more about the format of the packets in your steno protocol/mode of choice.
The `n_pressed_keys` argument is the number of physical keys actually being held down.
This is not always equal to the number of bits set to 1 (aka the [Hamming weight](https://en.wikipedia.org/wiki/Hamming_weight)) in `chord` because it is possible to simultaneously press down four keys, then release three of those four keys and then press yet another key while the fourth finger is still holding down its key.
At the end of this scenario given as an example, `chord` would have five bits set to 1 but
`n_pressed_keys` would be set to 2 because there are only two keys currently being pressed down.
## Keycode Reference :id=keycode-reference
As defined in `keymap_steno.h`.
You must include `keymap_steno.h` to your `keymap.c` with `#include "keymap_steno.h"` before you can use these keycodes
> Note: TX Bolt does not support the full set of keys. The TX Bolt implementation in QMK will map the GeminiPR keys to the nearest TX Bolt key so that one key map will work for both.
@@ -115,8 +184,8 @@ As defined in `keymap_steno.h`.
|`STN_E`|`STN_E`| `E` vowel|
|`STN_U`|`STN_U`| `U` vowel|
|`STN_FR`|`STN_FR`| `-F`|
|`STN_PR`|`STN_PR`| `-P`|
|`STN_RR`|`STN_RR`| `-R`|
|`STN_PR`|`STN_PR`| `-P`|
|`STN_BR`|`STN_BR`| `-B`|
|`STN_LR`|`STN_LR`| `-L`|
|`STN_GR`|`STN_GR`| `-G`|
@@ -124,10 +193,10 @@ As defined in `keymap_steno.h`.
|`STN_SR`|`STN_SR`| `-S`|
|`STN_DR`|`STN_DR`| `-D`|
|`STN_ZR`|`STN_ZR`| `-Z`|
|`STN_FN`|| (GeminiPR only)|
|`STN_RES1`||(GeminiPR only)|
|`STN_RES2`||(GeminiPR only)|
|`STN_PWR`||(GeminiPR only)|
|`STN_FN`|| (Function)|
|`STN_RES1`||(Reset 1)|
|`STN_RES2`||(Reset 2)|
|`STN_PWR`||(Power)|
If you do not want to hit two keys with one finger combined keycodes can be used. These are also defined in `keymap_steno.h`, and causes both keys to be reported as pressed or released. To use these keycodes define `STENO_COMBINEDMAP` in your `config.h` file.
@@ -31,3 +31,16 @@ Note that the array indices are reversed same as the matrix and the values are o
|`SH_OS` |One shot swap hands: toggles while pressed or until next key press. |
`SH_TT` swap-hands tap-toggle key is similar to [layer tap-toggle](feature_layers.md?id=switching-and-toggling-layers). Tapping repeatedly (5 taps by default) will toggle swap-hands on or off, like `SH_TG`. Tap-toggle count can be changed by defining a value for `TAPPING_TOGGLE`.
## Encoder Mapping
When using an encoder mapping, it's also able to handle swapping encoders between sides, too.
Encoder indexes are defined as left-to-right, and the extent of the array needs to match the number of encoders on the keyboard.
As an example, if a split keyboard has a single encoder per side, you can swap the order by using the following code in your keymap:
@@ -14,55 +14,48 @@ Optionally, you might want to set a custom `TAPPING_TERM` time by adding somethi
```c
#define TAPPING_TERM 175
#define TAPPING_TERM_PER_KEY
```
The `TAPPING_TERM` time is the maximum time allowed between taps of your Tap Dance key, and is measured in milliseconds. For example, if you used the above `#define` statement and set up a Tap Dance key that sends `Space` on single-tap and `Enter` on double-tap, then this key will send `ENT` only if you tap this key twice in less than 175ms. If you tap the key, wait more than 175ms, and tap the key again you'll end up sending `SPC SPC` instead.
The `TAPPING_TERM` time is the maximum time allowed between taps of your Tap Dance key, and is measured in milliseconds. For example, if you used the above `#define` statement and set up a Tap Dance key that sends `Space` on single-tap and `Enter` on double-tap, then this key will send `ENT` only if you tap this key twice in less than 175ms. If you tap the key, wait more than 175ms, and tap the key again you'll end up sending `SPC SPC` instead. The `TAPPING_TERM_PER_KEY` definition is only needed if you control the tapping term through a [custom `get_tapping_term` function](tap_hold.md#tapping_term), which may be needed because `TAPPING_TERM` affects not just tap-dance keys.
Next, you will want to define some tap-dance keys, which is easiest to do with the `TD()` macro, that takes a number which will later be used as an index into the `tap_dance_actions` array.
Next, you will want to define some tap-dance keys, which is easiest to do with the `TD()` macro. That macro takes a number which will later be used as an index into the `tap_dance_actions` array and turns it into a tap-dance keycode.
After this, you'll want to use the `tap_dance_actions` array to specify what actions shall be taken when a tap-dance key is in action. Currently, there are five possible options:
*`ACTION_TAP_DANCE_DOUBLE(kc1, kc2)`: Sends the `kc1` keycode when tapped once, `kc2` otherwise. When the key is held, the appropriate keycode is registered: `kc1` when pressed and held, `kc2` when tapped once, then pressed and held.
*`ACTION_TAP_DANCE_LAYER_MOVE(kc, layer)`: Sends the `kc` keycode when tapped once, or moves to `layer`. (this functions like the `TO` layer keycode).
* This is the same as `ACTION_TAP_DANCE_DUAL_ROLE`, but renamed to something that is clearer about its functionality. Both names will work.
*`ACTION_TAP_DANCE_LAYER_TOGGLE(kc, layer)`: Sends the `kc` keycode when tapped once, or toggles the state of `layer`. (this functions like the `TG` layer keycode).
*`ACTION_TAP_DANCE_FN(fn)`: Calls the specified function - defined in the user keymap - with the final tap count of the tap dance action.
*`ACTION_TAP_DANCE_FN_ADVANCED(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn)`: Calls the first specified function - defined in the user keymap - on every tap, the second function when the dance action finishes (like the previous option), and the last function when the tap dance action resets.
* ~~`ACTION_TAP_DANCE_FN_ADVANCED_TIME(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn, tap_specific_tapping_term)`~~: This functions identically to the `ACTION_TAP_DANCE_FN_ADVANCED` function, but uses a custom tapping term for it, instead of the predefined `TAPPING_TERM`.
* This is deprecated in favor of the Per Key Tapping Term functionality, as outlined [here](tap_hold.md#tapping-term). You'd want to check for the specific `TD()` macro that you want to use (such as `TD(TD_ESC_CAPS)`) instead of using this specific Tap Dance function.
The first option is enough for a lot of cases, that just want dual roles. For example, `ACTION_TAP_DANCE_DOUBLE(KC_SPC, KC_ENT)` will result in `Space` being sent on single-tap, `Enter` otherwise.
!> Keep in mind that only [basic keycodes](keycodes_basic.md) are supported here. Custom keycodes are not supported.
Similar to the first option, the second option is good for simple layer-switching cases.
Similar to the first option, the second and third option are good for simple layer-switching cases.
For more complicated cases, use the third or fourth options (examples of each are listed below).
Finally, the fifth option is particularly useful if your non-Tap-Dance keys start behaving weirdly after adding the code for your Tap Dance keys. The likely problem is that you changed the `TAPPING_TERM` time to make your Tap Dance keys easier for you to use, and that this has changed the way your other keys handle interrupts.
For more complicated cases, like blink the LEDs, fiddle with the backlighting, and so on, use the fourth or fifth option. Examples of each are listed below.
## Implementation Details :id=implementation
Well, that's the bulk of it! You should now be able to work through the examples below, and to develop your own Tap Dance functionality. But if you want a deeper understanding of what's going on behind the scenes, then read on for the explanation of how it all works!
The main entry point is`process_tap_dance()`, called from `process_record_quantum()`, which is run for every keypress, and our handler gets to run early. This function checks whether the key pressed is a tap-dance key. If it is not, and a tap-dance was in action, we handle that first, and enqueue the newly pressed key. If it is a tap-dance key, then we check if it is the same as the already active one (if there's one active, that is). If it is not, we fire off the old one first, then register the new one. If it was the same, we increment the counter and reset the timer.
Let's go over the three functions mentioned in`ACTION_TAP_DANCE_FN_ADVANCED` in a little more detail. They all receive the same too arguments: a pointer to a structure that holds all dance related state information, and a pointer to a use case specific state variable. The three functions differ in when they are called. The first, `on_each_tap_fn()`, is called every time the tapdance key is *pressed*. Before it is called, the counter is incremented and the timer is reset. The second function, `on_dance_finished_fn()`, is called when the tapdance is interrupted or ends because `TAPPING_TERM` milliseconds have passed since the last tap. When the `finished` field of the dance state structure is set to `true`, the `on_dance_finished_fn()` is skipped. After `on_dance_finished_fn()` was called or would have been called, but no sooner than when the tap dance key is *released*, `on_dance_reset_fn()` is called. It is possible to end a tap dance immediately, skipping `on_dance_finished_fn()`, but not `on_dance_reset_fn`, by calling `reset_tap_dance(state)`.
To accomplish this logic, the tap dance mechanics use three entry points. The main entry point is `process_tap_dance()`, called from `process_record_quantum()`*after*`process_record_kb()` and `process_record_user()`. This function is responsible for calling `on_each_tap_fn()` and `on_dance_reset_fn()`. In order to handle interruptions of a tap dance, another entry point, `preprocess_tap_dance()` is run right at the beginning of `process_record_quantum()`. This function checks whether the key pressed is a tap-dance key. If it is not, and a tap-dance was in action, we handle that first, and enqueue the newly pressed key. If it is a tap-dance key, then we check if it is the same as the already active one (if there's one active, that is). If it is not, we fire off the old one first, then register the new one. Finally, `tap_dance_task()` periodically checks whether `TAPPING_TERM` has passed since the last key press and finishes a tap dance if that is the case.
This means that you have `TAPPING_TERM` time to tap the key again; you do not have to input all the taps within a single `TAPPING_TERM` timeframe. This allows for longer tap counts, with minimal impact on responsiveness.
Our next stop is `tap_dance_task()`. This handles the timeout of tap-dance keys.
For the sake of flexibility, tap-dance actions can be either a pair of keycodes, or a user function. The latter allows one to handle higher tap counts, or do extra things, like blink the LEDs, fiddle with the backlighting, and so on. This is accomplished by using an union, and some clever macros.
## Examples :id=examples
### Simple Example :id=simple-example
### Simple Example: Send `ESC` on Single Tap, `CAPS_LOCK` on Double Tap :id=simple-example
Here's a simple example for a single definition:
1. In your `rules.mk`, add `TAP_DANCE_ENABLE = yes`
2. In your `config.h` (which you can copy from `qmk_firmware/keyboards/planck/config.h` to your keymap directory), add `#define TAPPING_TERM 200`
3. In your `keymap.c` file, define the variables and definitions, then add to your keymap:
2. In your `keymap.c` file, define the variables and definitions, then add to your keymap:
```c
// Tap Dance declarations
@@ -92,40 +85,15 @@ All the enums used in the examples are declared like this:
```c
// Enums defined for all examples:
enum{
CT_SE,
CT_CLN,
TD_ESC_CAPS,
CT_EGG,
CT_FLSH,
X_TAP_DANCE
CT_CLN,
X_CTL,
};
```
#### Example 1: Send `:` on Single Tap, `;` on Double Tap :id=example-1
#### Example 3: Send `:` on Tap, `;` on Hold :id=example-3
With a little effort, powerful tap-hold configurations can be implemented as tap dances. To emit taps as early as possible, we need to act on releases of the tap dance key. There is no callback for this in the tap dance framework, so we use `process_record_user()`.
#### Example 4: 'Quad Function Tap-Dance' :id=example-4
By [DanielGGordon](https://github.com/danielggordon)
@@ -329,7 +356,7 @@ And then simply use `TD(X_CTL)` anywhere in your keymap.
If you want to implement this in your userspace, then you may want to check out how [DanielGGordon](https://github.com/qmk/qmk_firmware/tree/master/users/gordon) has implemented this in their userspace.
> In this configuration "hold" takes place **after** tap dance timeout (see `ACTION_TAP_DANCE_FN_ADVANCED_TIME`). To achieve instant hold, remove `state->interrupted` checks in conditions. As a result you may use comfortable longer tapping periods to have more time for taps and not to wait too long for holds (try starting with doubled `TAPPING_TERM`).
> In this configuration "hold" takes place **after** tap dance timeout. To achieve instant hold, remove `state->interrupted` checks in conditions. As a result you may use comfortable longer tapping periods to have more time for taps and not to wait too long for holds (try starting with doubled `TAPPING_TERM`).
#### Example 5: Using tap dance for advanced mod-tap and layer-tap keys :id=example-5
The above code is similar to that used in previous examples. The one point to note is that we need to be able to check which layers are active at any time so we can toggle them if needed. To do this we use the `layer_state_is(layer)` function which returns `true` if the given `layer` is active.
@@ -521,6 +558,6 @@ The use of `cur_dance()` and `ql_tap_state` mirrors the above examples.
The `case: TD_SINGLE_TAP` in `ql_finished` is similar to the above examples. The `TD_SINGLE_HOLD` case works in conjunction with `ql_reset()` to switch to `_MY_LAYER` while the tap dance key is held, and to switch away from `_MY_LAYER` when the key is released. This mirrors the use of `MO(_MY_LAYER)`. The `TD_DOUBLE_TAP` case works by checking whether `_MY_LAYER` is the active layer, and toggling it on or off accordingly. This mirrors the use of `TG(_MY_LAYER)`.
`tap_dance_actions[]` works similar to the above examples. Note that I used `ACTION_TAP_DANCE_FN_ADVANCED_TIME()` instead of `ACTION_TAP_DANCE_FN_ADVANCED()`. This is because I like my `TAPPING_TERM` to be short (\~175ms) for my non-tap-dance keys but find that this is too quick for me to reliably complete tap dance actions - thus the increased time of 275ms here.
`tap_dance_actions[]` works similar to the above examples. Note that, additionally, I set a longer tapping term for the tap dance keys. This is because I like my `TAPPING_TERM` to be short (\~175ms) for my non-tap-dance keys but find that this is too quick for me to reliably complete tap dance actions - thus the increased time of 275ms here. In order for the per-key tapping terms to take effect, `TAPPING_TERM_PER_KEY` must be defined in your `config.h`.
Finally, to get this tap dance key working, be sure to include `TD(QUOT_LAYR)` in your `keymaps[]`.
> This feature is currently *huge*, and should probably only be put on boards with a lot of memory, or for fun.
The terminal feature is a command-line-like interface designed to communicate through a text editor with keystrokes. It's beneficial to turn off auto-indent features in your editor.
To enable, stick this in your `rules.mk` or `Makefile`:
TERMINAL_ENABLE = yes
And use the `TERM_ON` and `TERM_OFF` keycodes to turn it on or off.
When enabled, a `> ` prompt will appear, where you'll be able to type, backspace (a bell will ding if you reach the beginning and audio is enabled), and hit enter to send the command. Arrow keys are currently disabled so it doesn't get confused. Moving your cursor around with the mouse is discouraged.
`#define TERMINAL_HELP` enables some other output helpers that aren't really needed with this page.
Pressing "up" and "down" will allow you to cycle through the past 5 commands entered.
## Future Ideas
* Keyboard/user-extensible commands
* Smaller footprint
* Arrow key support
* Command history - Done
* SD card support
* LCD support for buffer display
* Keycode -> name string LUT
* Layer status
* *Analog/digital port read/write*
* RGB mode stuff
* Macro definitions
* EEPROM read/write
* Audio control
## Current Commands
### `about`
Prints out the current version of QMK with a build date:
```
> about
QMK Firmware
v0.5.115-7-g80ed73-dirty
Built: 2017-08-29-20:24:44
```
### `print-buffer`
Outputs the last 5 commands entered
```
> print-buffer
0. print-buffer
1. help
2. about
3. keymap 0
4. help
5. flush-buffer
```
### `flush-buffer`
Clears command buffer
```
> flush-buffer
Buffer cleared!
```
### `help`
Prints out the available commands:
```
> help
commands available:
about help keycode keymap exit print-buffer flush-buffer
```
### `keycode <layer> <row> <col>`
Prints out the keycode value of a certain layer, row, and column:
Example uses include sending Unicode strings when a key is pressed, as described in [Macros](feature_macros.md).
### `send_unicode_hex_string()` (Deprecated)
Similar to `send_unicode_string()`, but the characters are represented by their Unicode code points, written in hexadecimal and separated by spaces. For example, the table flip above would be achieved with:
An easy way to convert your Unicode string to this format is to use [this site](https://r12a.github.io/app-conversion/) and take the result in the "Hex/UTF-32" section.
## Additional Language Support
In `quantum/keymap_extras`, you'll see various language files — these work the same way as the ones for alternative layouts such as Colemak or BÉPO. When you include one of these language headers, you gain access to keycodes specific to that language / national layout. Such keycodes are defined by a 2-letter country/language code, followed by an underscore and a 4-letter abbreviation of the character to which the key corresponds. For example, including `keymap_french.h` and using `FR_UGRV` in your keymap will output `ù` when typed on a system with a native French AZERTY layout.
* `:dfu-util`: Waits until an STM32 bootloader device is available, and then flashes the firmware.
* `:dfu-util-split-left` and `:dfu-util-split-right`: Flashes the firmware as with `:avrdude`, but also sets the handedness setting in EEPROM. This is ideal for Proton-C-based split keyboards.
* `:dfu-util-split-left` and `:dfu-util-split-right`: Flashes the firmware as with `:dfu-util`, but also sets the handedness setting in EEPROM. This is ideal for Proton-C-based split keyboards.
* `:st-link-cli`: Allows you to flash the firmware via the ST-Link CLI utility, rather than dfu-util. Requires an ST-Link dongle.
* `:st-flash`: Allows you to flash the firmware via the `st-flash` utility from [STLink Tools](https://github.com/stlink-org/stlink), rather than dfu-util. Requires an ST-Link dongle.
@@ -347,3 +347,57 @@ Flashing sequence:
2. Wait for the OS to detect the device
3. Copy the .uf2 file to the new USB disk
4. Wait for the keyboard to become available
or
CLI Flashing sequence:
1. Enter the bootloader using any of the following methods:
* `:uf2-split-left` and `:uf2-split-right`: Flashes the firmware but also sets the handedness setting in EEPROM by generating a side specific firmware.
## Raspberry Pi RP2040 UF2
The `rules.mk` setting for this bootloader is `rp2040`, and can be specified at the keymap or user level.
To ensure compatibility with the rp2040 bootloader, make sure this block is present in your `rules.mk`:
```make
# Bootloader selection
BOOTLOADER = rp2040
```
Compatible flashers:
* Any application able to copy a file from one place to another, such as _macOS Finder_ or _Windows Explorer_.
Flashing sequence:
1. Enter the bootloader using any of the following methods:
* Tap the `QK_BOOTLOADER` keycode
* Hold the `BOOTSEL` button on the PCB while plugin in the usb cable.
* Double-tap the `RESET` button on the PCB<sup>1</sup>.
2. Wait for the OS to detect the device
3. Copy the .uf2 file to the new USB disk
4. Wait for the keyboard to become available
or
CLI Flashing sequence:
1. Enter the bootloader using any of the following methods:
* Tap the `QK_BOOTLOADER` keycode
* Hold the `BOOTSEL` button on the PCB while plugin in the usb cable.
* Double-tap the `RESET` button on the PCB<sup>1</sup>.
The *scancode* is mapped to a *keycode* dependent on the keyboard [60-keyboard.hwdb at Master](https://github.com/systemd/systemd/blob/master/hwdb.d/60-keyboard.hwdb). Without this mapping, the operating system will not receive a valid keycode and will be unable to do anything useful with that key press.
The *scancode* is mapped to a *keycode* dependent on the keyboard [60-keyboard.hwdb at Main](https://github.com/systemd/systemd/blob/main/hwdb.d/60-keyboard.hwdb). Without this mapping, the operating system will not receive a valid keycode and will be unable to do anything useful with that key press.
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.