* kbdfans/bounce/75/hotswap: keymap readability fix
Update grid alignment to disambiguate which keycodes correspond in different layers.
----
Layer 0 had 13 and 9 keycodes on the bottom two rows respectively, while Layers 1-3 had 14 and 8.
* kbdfans/bounce/75/soldered: keymap readability fix
Update grid alignment to disambiguate which keycodes correspond in different layers.
----
Layer 0 had 14 and 9 keycodes on the bottom two rows respectively, while Layers 1-3 had 15 and 8.
* kbdfans/bounce/75/soldered: fix layer index in keymaps
Layer indexes were 0,1,2,1 instead of 0,1,2,3.
* Start of dz65v2 map for sbennett13
* No wpm, disable some rgb, ~copyright~
* No more raindrops
* Remove more rgb modes and set default
* Almost orgot this crappy thing
* cannot define startup :(
* Layered esc is kc_grv
* Start of dz65v2 map for sbennett13
* No wpm, disable some rgb, ~copyright~
* No more raindrops
* Remove more rgb modes and set default
* Almost orgot this crappy thing
* cannot define startup :(
* Layered esc is kc_grv
* Add license to config and keymap
* skjoldr.h: use ___ for KC_NO
* skjoldr.h: use K<row><column> notation
Matrix was previously defined using identifiers in the format of K<column><row>.
* skjoldr.h: add matrix diagram
* info.json: apply friendly formatting
- key legends as labels
- correct key sizes and positioning
* refactor keymaps
Refactors the `default` and `via` keymaps.
- use QMK-native keycode aliases
- grid-align keycodes for readability
* rename LAYOUT macro to LAYOUT_60_ansi_arrow
* enable Community Layout support
* info.json: correct maintainer value
Field is meant to reference the maintainer's GitHub username.
* sinanju.h: add matrix diagram
* add LAYOUT_60_ansi_wkl_split_bs_rshift macro
Same matrix as `LAYOUT_all`, but with position K2D (right half of split Backspace) moved to the end of the top row.
* refactor keymaps
- use `LAYOUT_60_ansi_wkl_split_bs_rshift` macro instead of `LAYOUT_all`
- polish four-space indent
- update grid alignment
- replace `RESET` keycode with `QK_BOOT`
* remove now-unused LAYOUT_all macro
* add LAYOUT_60_ansi_wkl macro with keymap
Add a layout with 2u Backspace and 2.75u right Shift.
* info.json: correct maintainer value
* Initial Apollo87H support
* Define RGB animations and default animation
* Add proper per-key RGB support
* Adjust LED positions
* Separate delta-gamma
* Fine-tune LED positions
* fix up GAMMA revision
* fix up tabs indentation to spaces indentation
* Fixed positioning and CS-SW defs for some LEDs
* Fix INS RGB position
* Fine-tune LED positions, fix default RGB
* Update readme's
* Rename LAYOUT_87H to lowercase 87h
* Formatting gamma's rules.mk
* Formatting delta's rules.mk
* Use smaller readme image
* Use smaller README image
* First support for 87H-T-SC and 88H-T-SC
* Update README
* Fix layout naming
* Remove
* Remove EEPROM definitions, fix missing RGB LED mod/alpha definer
* Add suggestions from noroadsleft
* chiffre refactor for new revisions
* updated led matrix config
* updated per suggestions
* add tapdance enable
* revert tapdance (none defined in the default keymaps)
* clean up rules
* add readme for HE
* remove notes in readme
* fix perm
* fix perms
* Fix spacing on readme
* fix perm
* fix perms again?
Python will evaluate first the left and then the right side of the and operator.
The left side would previously return True based on the truthiness logic that treats any non-emptry string as true.
It would not check if the desired keymap exists.
If the left side is true it will evaluate the right side which will check for the existance of a specific keymap.
With this change the check for existance of two keymaps is implemented.
* Added autoclicker, better mouse, vim like FN layer and more.
* Updated docs to comply with guidelines
* Fixed Imgur links
* increased step sizes
* updated readme to reflect step size
* Added second delay array for autoclicker to compensate for RGB animation CPU loads
* better RGB effects and updated docs
* better README.md formatting
* added DEBONCE libinput workaround for Linux
* fixed formatting
* fixed typos and clarified
* fixed layer picture order
* Update keyboards/dztech/dz65rgb/keymaps/yuannan/keymap.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update keyboards/dztech/dz65rgb/keymaps/yuannan/README.md
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Updated Docs and rules
* Updated with the new deferred exec API to ensure more consistant CPS
* renamed README.md to be lower case to comply with fauxpark's request
* Remapped alt to be left instead of right for compatibility reasons
* Update keyboards/dztech/dz65rgb/keymaps/yuannan/config.h
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
* 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.
* 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.
* [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>
* 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
* 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
* 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>
* 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
* 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
* 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>
### 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:
| `AUDIO_DAC_SAMPLE_MAX` | `4095U` | Highest value allowed. Lower value means lower volume. And 4095U is the upper limit, since this is limited to a 12 bit value. Only effects non-pregenerated samples. |
| `AUDIO_DAC_OFF_VALUE` | `AUDIO_DAC_SAMPLE_MAX / 2` | The value of the DAC when notplaying anything. Some setups may require a high (`AUDIO_DAC_SAMPLE_MAX`) or low (`0`) value here. |
| `AUDIO_DAC_OFF_VALUE` | `AUDIO_DAC_SAMPLE_MAX / 2` | The value of the DAC when notplaying anything. Some setups may require a high (`AUDIO_DAC_SAMPLE_MAX`) or low (`0`) value here. |
| `AUDIO_MAX_SIMULTANEOUS_TONES` | __see next table__ | The number of tones that can be played simultaneously. A value that is too high may freeze the controller or glitch out when too many tones are being played. |
| `AUDIO_DAC_SAMPLE_RATE` | __see next table__ | Effective bit rate of the DAC (in hertz), higher limits simultaneous tones, and lower sacrifices quality. |
| `AUDIO_DAC_SAMPLE_RATE` | __see next table__ | Effective bit rate of the DAC (in hertz), higher limits simultaneous tones, and lower sacrifices quality. |
There are a number of predefined quality settings that you can use, with "sane minimum" being the default. You can use custom values by simply defining the sample rate and number of simultaneous tones, instead of using one of the listed presets.
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
@@ -131,6 +131,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.
@@ -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
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)
* [Command](feature_command.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.
@@ -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_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 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.
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.
|`PMW3360_CS_PIN` | (Required) Sets the Cable Select pin connected to the sensor. | _not defined_ |
|`PMW3360_CS_PINS` | (Alternative) Sets the Cable Select pins connected to multiple sensors. | _not defined_ |
|`PMW3360_CLOCK_SPEED` | (Optional) Sets the clock speed that the sensor runs at. | `2000000` |
|`PMW3360_SPI_LSBFIRST` | (Optional) Sets the Least/Most Significant Byte First setting for SPI. | `false` |
|`PMW3360_SPI_MODE` | (Optional) Sets the SPI Mode for the sensor. | `3` |
@@ -155,6 +157,36 @@ The PMW 3360 is an SPI driven optical sensor, that uses a built in IR LED for su
The CPI range is 100-12000, in increments of 100. Defaults to 1600 CPI.
To use multiple sensors, instead of setting `PMW3360_CS_PIN` you need to set `PMW3360_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 PMW3360_CS_PINS { B5, B6 }
// in keyboard.c:
#ifdef POINTING_DEVICE_ENABLE
voidpointing_device_init_kb(void){
pmw3360_init(1);// index 1 is the second device.
pointing_device_set_cpi(800);// applies to both sensors
pointing_device_init_user();
}
// Contains report from sensor #0 already, need to merge in from sensor #1
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`:
Heatmap effect may not light up the correct adjacent LEDs for certain key matrix layout such as split keyboards. The following define will limit the effect to pressed keys only:
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 +777,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).
@@ -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.
@@ -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:
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,14 @@ 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:
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.
@@ -27,30 +27,24 @@ QMK maintains a Bundle of MSYS2, the CLI and all necessary dependencies. It also
You will need to install [QMK MSYS](https://msys.qmk.fm/). The latest release is available [here](https://github.com/qmk/qmk_distro_msys/releases/latest).
Alternatively, if you'd like to manually install MSYS2, the following section will walk you through the process.
<details>
<summary>Manual Install</summary>
<summary>Advanced Users</summary>
?> Ignore the following steps if you use `QMK MSYS`.
!> <bstyle="font-size:150%">This process is not recommended for new users.</b>
If you'd like to manually install MSYS2, the following sections will walk you through the process.
#### Prerequisites
You will need to install MSYS2, Git and Python. Follow the installation instructions on https://www.msys2.org.
Once MSYS2 is installed, close any open MSYS terminals and open a new MinGW 64-bit terminal.
You will need to install [MSYS2](https://www.msys2.org). Once installed, close any open MSYS terminals (purple icon) and open a new MinGW 64-bit terminal (blue icon) from the Start Menu.
!> **NOTE:** The MinGW 64-bit terminal is *not* the same as the MSYS terminal that opens when installation is completed. Your prompt should say "MINGW64" in purple text, rather than "MSYS". See [this page](https://www.msys2.org/wiki/MSYS2-introduction/#subsystems) for more information on the differences.
This installs a bunch of Git related tools that may make using Git with QMK Firmware easier.
* [EditorConfig for VS Code](https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig) - _[Optional]_ - Helps to keep the code to the QMK Coding Conventions.
* [Bracket Pair Colorizer 2](https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer-2) - _[Optional]_ - This color codes the brackets in your code, to make it easier to reference nested code.
* [GitHub Markdown Preview](https://marketplace.visualstudio.com/items?itemName=bierner.github-markdown-preview) - _[Optional]_ - Makes the markdown preview in VS Code more like GitHub's.
* [VS Live Share Extension Pack](https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare-pack) - _[Optional]_ - This extension allows somebody else to access your workspace (or you to access somebody else's workspace) and help out. This is great if you're having issues and need some help from somebody.
* [VIM Keymap](https://marketplace.visualstudio.com/items?itemName=GiuseppeCesarano.vim-keymap) - _[Optional]_ - For those that prefer VIM style keybindings. There are other options for this, too.
The WeAct Blackpill is a popular choice for handwired boards, as it offers a powerful micro controller, USB Type C, a good number of pins to use, and a large amount of firmware space. All for a ~$6 USD price tag.
* [WeAct GitHub for F411 Blackpill](https://github.com/WeActTC/MiniSTM32F4x1)
* Unfortunately, due to supply issues official WeAct F411 based blackpills may not be available.
While the Blackpill is a great choice to use in your keyboard, there are a number of caveats in regards to using them. The first is that a number of exposed pins cannot be used, or have special considerations/hardware tweaks that are required for proper opertion.
### Unusable pins
* Pins `A11` and `A12` are not useable because they're used for USB connection, and cannot be shared.
* In theory, these pins can be used. However, doing so may disable USB connectivity, outright, if used for anything other than a USB port
* Pin `B2` is used by `BOOT1` and cannot be used, without causing problems.
*`VBAT` is not a usable pin.
*`NRST` is not a usable pin.
### Pins to be avoided
* Pin `A9` is meant for VBUS Sense and should not be used, if it can be avoided. It has an internal pull-down resesitor, which may cause issues with usage. However, a pull-up resistor can work (~5.1k), but should be avoided.
* Pin `A10` can be used, but should be avoided. Any connection on this pin can prevent the bootloader from entering the proper mode for DFU flashing. A pull-up resistor (~22k) on this pin fixes the bootloader issue.
### Shared Usage
* Pin `A0` is shared with the User Key (button) on the controller. It can be used.
* Pin `C13` is shared with the onboard LED indicator, and is connected to +3.3V. This can be used, but may cause the LED to blink intermittently, depending on activity on the pin.
*
* Pins `A4`, `A5`, `A6` and `A7` are used by the SOI8 footprint on the back of the controller, that can be used for either an SPI Flash chip, or an SPI EEPROM chip. `A4` is the Chip Select pin, and cannot be shared. However, `A5`, `A6`, and `A7` are the `SCK`, `MISO`, and `MOSI` pins, respectively, and can be shared with other SPI devices.
### Limited Usage
* Pins `C13`, `C14`, and `C15` have limits on output current. They should be used only as input. Eg, they should not be used for row pins in COL2ROW matrix configurations, but can be used as column pins.
* This is because the column pins (in COL2ROW) are pulled up (the pullup strength is independant of the current sourcing limitation) and the ROW is driven low and sinks current, then we check the state of the COLs to look for keypresses.
* Pins `A0` and `B5` are not 5V tolerant, and should only be used with 3.3V compatible functionality.
## Additional Information
### Bootloader issuse
Due to the use of a 25MHz crystal, the controller may have issues entering the bootloader. Heating up the controller can help with this issue.
Also, if pin `A10` is connected to anything at all, it needs to have a pullup resistor (see [Pins to be avoided](#pins-to-be-avoided), above)
### Tiny UF2 Support
There is [tinyuf2 support for the WeAct Blackpill](https://github.com/adafruit/tinyuf2/tree/master/ports/stm32f4/boards/stm32f411ce_blackpill). Instructions on how to compile the bootloadr can be found [here](https://github.com/adafruit/tinyuf2#build-and-flash). Setting `BOOTLOADER = tinyuf2` will enable support for this user bootloader, and the correct configuration to prevent it from being overwritten when flashing firmware.
- modified `# Enable Bluetooth with the Adafruit EZ-Key HID` -> `# Enable Bluetooth`
- no `(-/+size)` comments related to enabling features
- remove the list of alternate bootloaders if one has been specified
- no re-definitions of the default MCU parameters if same value, when compared to the equivalent MCU in [mcu_selection.mk](https://github.com/qmk/qmk_firmware/blob/master/quantum/mcu_selection.mk)
- no re-definitions of the default MCU parameters if same value, when compared to the equivalent MCU in [mcu_selection.mk](https://github.com/qmk/qmk_firmware/blob/master/builddefs/mcu_selection.mk)
- keyboard `config.h`
- don't repeat `MANUFACTURER` in the `PRODUCT` value
-`matrix_init_board()` etc. migrated to `keyboard_pre_init_kb()`, see: [keyboard_pre_init*](custom_quantum_functions.md?id=keyboard_pre_init_-function-documentation)
- prefer `CUSTOM_MATRIX = lite` if custom matrix used, allows for standard debounce, see [custom matrix 'lite'](custom_matrix.md?id=lite)
- prefer LED indicator [Configuration Options](feature_led_indicators.md?id=configuration-options) to custom `led_update_*()` implementations where possible
- Encoder support should not be hacked into the keymap here -- no `tap_code(dynamic_keymap_get_keycode())` or `action_exec()` hacks. The [Encoder Map](feature_encoders.md?id=encoder-map) feature already supports the dynamic keymap feature (what power's VIA's "live keymap updates" capability).
- If support is absolutely necessary, it should be implemented exclusively at the keymap level, with none of the implementation bleeding into the keyboard level (no empty rows/columns, no encoder specific layouts, etc.), as those configurations can be redefined at the keymap level. Keymaps can then choose to use the `action_exec` hack. <!-- because people will complain, give them a way to implement it, in the meanwhile. To be removed. -->
- [Request for official proper VIA support](https://github.com/the-via/app/issues/26)
-`<keyboard>.h`
-`#include "quantum.h"` appears at the top
-`LAYOUT` macros should use standard definitions if applicable
@@ -20,7 +20,7 @@ This exposes the `CONVERT_TO_PROTON_C` flag that you can use in your code with `
#endif
```
If you get errors about `PORTB/DDRB`, etc not being defined, so you'll need to convert the keyboard's code to use the [GPIO Controls](internals_gpio_control.md) that will work for both ARM and AVR. This shouldn't affect the AVR builds at all.
If you get errors about `PORTB/DDRB`, etc not being defined, so 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.
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 like to your `config.h`:
Quantum Painter is the standardised API for graphical displays. It currently includes support for basic drawing primitives, as well as custom images, animations, and fonts.
Due to the complexity, there is no support for Quantum Painter on AVR-based boards.
To enable overall Quantum Painter to be built into your firmware, add the following to `rules.mk`:
```make
QUANTUM_PAINTER_ENABLE= yes
QUANTUM_PAINTER_DRIVERS= ......
```
You will also likely need to select an appropriate driver in `rules.mk`, which is listed below.
!> Quantum Painter is not currently integrated with system-level operations such as disabling displays after a configurable timeout, or when the keyboard goes into suspend. Users will need to handle this manually at the current time.
The QMK CLI can be used to convert from normal images such as PNG files or animated GIFs, as well as fonts from TTF files.
Hardware supported:
| Display Panel | Panel Type | Size | Comms Transport | Driver |
| `QUANTUM_PAINTER_NUM_IMAGES` | `8` | The maximum number of images/animations that can be loaded at any one time. |
| `QUANTUM_PAINTER_NUM_FONTS` | `4` | The maximum number of fonts that can be loaded at any one time. |
| `QUANTUM_PAINTER_CONCURRENT_ANIMATIONS` | `4` | The maximum number of animations that can be executed at the same time. |
| `QUANTUM_PAINTER_LOAD_FONTS_TO_RAM` | `FALSE` | Whether or not fonts should be loaded to RAM. Relevant for fonts stored in off-chip persistent storage, such as external flash. |
| `QUANTUM_PAINTER_PIXDATA_BUFFER_SIZE` | `32` | The limit of the amount of pixel data that can be transmitted in one transaction to the display. Higher values require more RAM on the MCU. |
| `QUANTUM_PAINTER_SUPPORTS_256_PALETTE` | `FALSE` | If 256-color palettes are supported. Requires significantly more RAM on the MCU. |
| `QUANTUM_PAINTER_DEBUG` | _unset_ | Prints out significant amounts of debugging information to CONSOLE output. Significant performance degradation, use only for debugging. |
Drivers have their own set of configurable options, and are described in their respective sections.
## Quantum Painter Drawing API :id=quantum-painter-api
All APIs require a `painter_device_t` object as their first parameter -- this object comes from the specific device initialisation, and instructions on creating it can be found in each driver's respective section.
To use any of the APIs, you need to include `qp.h`:
```c
#include<qp.h>
```
### General Notes :id=quantum-painter-api-general
The coordinate system used in Quantum Painter generally accepts `left`, `top`, `right`, and `bottom` instead of x/y/width/height, and each coordinate is inclusive of where pixels should be drawn. This is required as some datatypes used by display panels have a maximum value of `255` -- for any value or geometry extent that matches `256`, this would be represented as a `0`, instead.
?> Drawing a horizontal line 8 pixels long, starting from 4 pixels inside the left side of the display, will need `left=4`, `right=11`.
All color data matches the standard QMK HSV triplet definitions:
* Hue is of the range `0...255` and is internally mapped to 0...360 degrees.
* Saturation is of the range `0...255` and is internally mapped to 0...100% saturation.
* Value is of the range `0...255` and is internally mapped to 0...100% brightness.
?> Colors used in Quantum Painter are not subject to the RGB lighting CIE curve, if it is enabled.
### Device Control :id=quantum-painter-api-device-control
The `qp_init` function is used to initialise a display device after it has been created. This accepts a rotation parameter (`QP_ROTATION_0`, `QP_ROTATION_90`, `QP_ROTATION_180`, `QP_ROTATION_270`), which makes sure that the orientation of what's drawn on the display is correct.
```c
staticpainter_device_tdisplay;
voidkeyboard_post_init_kb(void){
display=qp_make_.......;// Create the display
qp_init(display,QP_ROTATION_0);// Initialise the display
The `qp_power` function instructs the display whether or not the display panel should be on or off.
!> If there is a separate backlight controlled through the normal QMK backlight API, this is not controlled by the `qp_power` function and needs to be manually handled elsewhere.
```c
staticuint8_tlast_backlight=255;
voidsuspend_power_down_user(void){
if(last_backlight==255){
last_backlight=get_backlight_level();
}
backlight_set(0);
rgb_matrix_set_suspend_state(true);
qp_power(display,false);
}
voidsuspend_wakeup_init_user(void){
qp_power(display,true);
rgb_matrix_set_suspend_state(false);
if(last_backlight!=255){
backlight_set(last_backlight);
}
last_backlight=255;
}
```
#### Display Clear :id=quantum-painter-api-clear
```c
boolqp_clear(painter_device_tdevice);
```
The `qp_clear` function clears the display's screen.
#### Display Flush :id=quantum-painter-api-flush
```c
boolqp_flush(painter_device_tdevice);
```
The `qp_flush` function ensures that all drawing operations are "pushed" to the display. This should be done as the last operation whenever a sequence of draws occur, and guarantees that any changes are applied.
!> Some display panels may seem to work even without a call to `qp_flush` -- this may be because the driver cannot queue drawing operations and needs to display them immediately when invoked. In general, calling `qp_flush` at the end is still considered "best practice".
```c
voidhousekeeping_task_user(void){
staticuint32_tlast_draw=0;
if(timer_elapsed32(last_draw)>33){// Throttle to 30fps
The `qp_setpixel` can be used to set a specific pixel on the screen to the supplied color.
?> Using `qp_setpixel` for large amounts of drawing operations is inefficient and should be avoided unless they cannot be achieved with other drawing APIs.
```c
voidhousekeeping_task_user(void){
staticuint32_tlast_draw=0;
if(timer_elapsed32(last_draw)>33){// Throttle to 30fps
last_draw=timer_read32();
// Draw a 240px high vertical rainbow line on X=0:
The `qp_rect` can be used to draw rectangles on the screen with the supplied color, with or without a background fill. If not filled, any pixels inside the rectangle will be left as-is.
```c
voidhousekeeping_task_user(void){
staticuint32_tlast_draw=0;
if(timer_elapsed32(last_draw)>33){// Throttle to 30fps
last_draw=timer_read32();
// Draw 8px-wide rainbow filled rectangles down the left side of the display
The `qp_circle` can be used to draw circles on the screen with the supplied color, with or without a background fill. If not filled, any pixels inside the circle will be left as-is.
```c
voidhousekeeping_task_user(void){
staticuint32_tlast_draw=0;
if(timer_elapsed32(last_draw)>33){// Throttle to 30fps
last_draw=timer_read32();
// Draw r=4 filled circles down the left side of the display
The `qp_ellipse` can be used to draw ellipses on the screen with the supplied color, with or without a background fill. If not filled, any pixels inside the ellipses will be left as-is.
```c
voidhousekeeping_task_user(void){
staticuint32_tlast_draw=0;
if(timer_elapsed32(last_draw)>33){// Throttle to 30fps
last_draw=timer_read32();
// Draw 16x8 filled ellipses down the left side of the display
The `qp_load_image_mem` function loads a QGF image from memory or flash.
`qp_load_image_mem` returns a handle to the loaded image, which can then be used to draw to the screen using `qp_drawimage`, `qp_drawimage_recolor`, `qp_animate`, or `qp_animate_recolor`. If an image is no longer required, it can be unloaded by calling `qp_close_image` below.
See the [CLI Commands](quantum_painter.md?id=quantum-painter-cli) for instructions on how to convert images to [QGF](quantum_painter_qgf.md).
?> The total number of images available to load at any one time is controlled by the configurable option `QUANTUM_PAINTER_NUM_IMAGES` in the table above. If more images are required, the number should be increased in `config.h`.
Image information is available through accessing the handle:
The `qp_drawimage` and `qp_drawimage_recolor` functions draw the supplied image to the screen at the supplied location, with the latter function allowing for monochrome-based images to be recolored.
```c
// Draw an image on the bottom-right of the 240x320 display on initialisation
The `qp_animate` and `qp_animate_recolor` functions draw the supplied image to the screen at the supplied location, with the latter function allowing for monochrome-based animations to be recolored. They also set up internal timing such that each frame is rendered at the correct time as per the animated image.
Once an image has been set to animate, it will loop indefinitely until stopped, with no user intervention required.
Both functions return a `deferred_token`, which can then be used to stop the animation, using `qp_stop_animation` below.
```c
// Animate an image on the bottom-right of the 240x320 display on initialisation
The `qp_load_font_mem` function loads a QFF font from memory or flash.
`qp_load_font_mem` returns a handle to the loaded font, which can then be measured using `qp_textwidth`, or drawn to the screen using `qp_drawtext`, or `qp_drawtext_recolor`. If a font is no longer required, it can be unloaded by calling `qp_close_font` below.
See the [CLI Commands](quantum_painter.md?id=quantum-painter-cli) for instructions on how to convert TTF fonts to [QFF](quantum_painter_qff.md).
?> The total number of fonts available to load at any one time is controlled by the configurable option `QUANTUM_PAINTER_NUM_FONTS` in the table above. If more fonts are required, the number should be increased in `config.h`.
Font information is available through accessing the handle:
| Property | Accessor |
|-------------|----------------------|
| Line Height | `image->line_height` |
#### Unload Font :id=quantum-painter-api-close-font
```c
boolqp_close_font(painter_font_handle_tfont);
```
The `qp_close_font` function releases resources related to the loading of the supplied font.
#### Measure Text :id=quantum-painter-api-textwidth
The `qp_drawtext` and `qp_drawtext_recolor` functions draw the supplied string to the screen at the given location using the font supplied, with the latter function allowing for monochrome-based fonts to be recolored.
```c
// Draw a text message on the bottom-right of the 240x320 display on initialisation
The `qp_set_viewport_offsets` function can be used to offset all subsequent drawing operations. For example, if a display controller is internally 240x320, but the display panel is 240x240 and has a Y offset of 80 pixels, you could invoke `qp_set_viewport_offsets(display, 0, 80);` and the drawing positioning would be corrected.
#### Set Viewport :id=quantum-painter-api-viewport
The `qp_pixdata` function allows raw pixel data to be streamed to the display. It requires a native pixel count rather than the number of bytes to transfer, to ensure display panel data alignment is respected. E.g. for display panels using RGB565 internal format, sending 10 pixels will result in 20 bytes of transfer.
!> Under normal circumstances, users will not need to manually call either `qp_viewport` or `qp_pixdata`. These allow for writing of raw pixel information, in the display panel's native format, to the area defined by the viewport.
The device handle returned from the `qp_st7789_make_spi_device` function can be used to perform all other drawing operations.
The maximum number of displays can be configured by changing the following in your `config.h` (default is 1):
```c
// 3 displays:
#define ST7789_NUM_DEVICES 3
```
!> Some ST7789 devices are known to have different drawing offsets -- despite being a 240x320 pixel display controller internally, some display panels are only 240x240, or smaller. These may require an offset to be applied; see `qp_set_viewport_offsets` above for information on how to override the offsets if they aren't correctly rendered.
QMK uses a font format _("Quantum Font Format" - QFF)_ specifically for resource-constrained systems.
This format is capable of encoding 1-, 2-, 4-, and 8-bit-per-pixel greyscale- and palette-based images into a font. It also includes RLE for pixel data for some basic compression.
All integer values are in little-endian format.
The QFF is defined in terms of _blocks_ -- each _block_ contains a _header_ and an optional _blob_ of data. The _header_ contains the block's _typeid_, and the length of the _blob_ that follows. Each block type is denoted by a different _typeid_ has its own block definition below. All blocks are defined as packed structs, containing zero padding between fields.
The general structure of the file is:
* _Font descriptor block_
* _ASCII glyph block_ (optional, only if ASCII glyphs are included)
* _Unicode glyph block_ (optional, only if Unicode glyphs are included)
* _Font palette block_ (optional, depending on frame format)
* _Font data block_
## Block Header :id=qff-block-header
The block header is identical to [QGF's block header](quantum_painter_qgf.md#qgf-block-header), and is present for all blocks, including the font descriptor.
## Font descriptor block :id=qff-font-descriptor
* _typeid_ = 0x00
* _length_ = 20
This block must be located at the start of the file contents, and can exist a maximum of once in an entire QGF file. It is always followed by either the _ASCII glyph table_ or the _Unicode glyph table_, depending on which glyphs are included in the font.
uint24_tmagic;// constant, equal to 0x464651 ("QFF")
uint8_tqff_version;// constant, equal to 0x01
uint32_ttotal_file_size;// total size of the entire file, starting at offset zero
uint32_tneg_total_file_size;// negated value of total_file_size, used for detecting parsing errors
uint8_tline_height;// glyph height in pixels
boolhas_ascii_table;// whether the font has an ascii table of glyphs (0x20...0x7E)
uint16_tnum_unicode_glyphs;// the number of glyphs in the unicode table -- no table specified if zero
uint8_tformat;// frame format, see below.
uint8_tflags;// frame flags, see below.
uint8_tcompression_scheme;// compression scheme, see below.
uint8_ttransparency_index;// palette index used for transparent pixels (not yet implemented)
}qff_font_descriptor_v1_t;
// _Static_assert(sizeof(qff_font_descriptor_v1_t) == (sizeof(qgf_block_header_v1_t) + 20), "qff_font_descriptor_v1_t must be 25 bytes in v1 of QFF");
```
The values for `format`, `flags`, `compression_scheme`, and `transparency_index` match [QGF's frame descriptor block](quantum_painter_qgf.md#qgf-frame-descriptor), with the exception that the `delta` flag is ignored by QFF.
## ASCII glyph table :id=qff-ascii-table
* _typeid_ = 0x01
* _length_ = 290
If the font contains ascii characters, the _ASCII glyph block_ must be located directly after the _font descriptor block_.
uint24_tglyph[95];// 95 glyphs, 0x20..0x7E, see bits/masks above for values
}qff_ascii_glyph_table_v1_t;
// _Static_assert(sizeof(qff_ascii_glyph_table_v1_t) == (sizeof(qgf_block_header_v1_t) + 285), "qff_ascii_glyph_table_v1_t must be 290 bytes in v1 of QFF");
```
## Unicode glyph table :id=qff-unicode-table
* _typeid_ = 0x02
* _length_ = variable
If this font contains unicode characters, the _unicode glyph block_ must be located directly after the _ASCII glyph table block_, or the _font descriptor block_ if the font does not contain ASCII characters.
struct__attribute__((packed)){// container for a single unicode glyph
uint24_tcode_point;// the unicode code point
uint24_tglyph;// the glyph information, as per ASCII glyphs above
}glyph[N];// N glyphs worth of data
}qff_unicode_glyph_table_v1_t;
```
## Font palette block :id=qff-palette-descriptor
* _typeid_ = 0x03
* _length_ = variable
The _font palette block_ is identical to [QGF's frame palette block](quantum_painter_qgf.md#qgf-frame-palette-descriptor), retaining the same _typeid_ of 0x03.
It is only specified in the QFF if the font is palette-based, and follows the _unicode glyph block_ if the font contains any Unicode glyphs, or the _ASCII glyph block_ if the font contains only ASCII glyphs.
## Font data block :id=qff-data-descriptor
* _typeid_ = 0x04
* _length_ = variable
The _font data block_ is the last block in the file and is identical to [QGF's frame data block](quantum_painter_qgf.md#qgf-frame-data-descriptor), however has a different _typeid_ of 0x04 in QFF.
QMK uses a graphics format _("Quantum Graphics Format" - QGF)_ specifically for resource-constrained systems.
This format is capable of encoding 1-, 2-, 4-, and 8-bit-per-pixel greyscale- and palette-based images. It also includes RLE for pixel data for some basic compression.
All integer values are in little-endian format.
The QGF is defined in terms of _blocks_ -- each _block_ contains a _header_ and an optional _blob_ of data. The _header_ contains the block's _typeid_, and the length of the _blob_ that follows. Each block type is denoted by a different _typeid_ has its own block definition below. All blocks are defined as packed structs, containing zero padding between fields.
The general structure of the file is:
* _Graphics descriptor block_
* _Frame offset block_
* Repeating list of frames:
* _Frame descriptor block_
* _Frame palette block_ (optional, depending on frame format)
* _Frame delta block_ (optional, depending on delta flag)
* _Frame data block_
Different frames within the file should be considered "isolated" and may have their own image format and/or palette.
## Block Header :id=qgf-block-header
This block header is present for all blocks, including the graphics descriptor.
uint8_tneg_type_id;// Negated type ID, used for detecting parsing errors
uint24_tlength;// 24-bit blob length, allowing for block sizes of a maximum of 16MB
}qgf_block_header_v1_t;
// _Static_assert(sizeof(qgf_block_header_v1_t) == 5, "qgf_block_header_v1_t must be 5 bytes in v1 of QGF");
```
The _length_ describes the number of octets in the data following the block header -- a block header may specify a _length_ of `0` if no blob is specified.
This block must be located at the start of the file contents, and can exist a maximum of once in an entire QGF file. It is always followed by the _frame offset block_.
uint24_tmagic;// constant, equal to 0x464751 ("QGF")
uint8_tqgf_version;// constant, equal to 0x01
uint32_ttotal_file_size;// total size of the entire file, starting at offset zero
uint32_tneg_total_file_size;// negated value of total_file_size, used for detecting parsing errors
uint16_timage_width;// in pixels
uint16_timage_height;// in pixels
uint16_tframe_count;// minimum of 1
}qgf_graphics_descriptor_v1_t;
// _Static_assert(sizeof(qgf_graphics_descriptor_v1_t) == (sizeof(qgf_block_header_v1_t) + 18), "qgf_graphics_descriptor_v1_t must be 23 bytes in v1 of QGF");
This block denotes the offsets within the file to each frame's _frame descriptor block_, relative to the start of the file. The _frame offset block_ always immediately follows the _graphics descriptor block_. The contents of this block are an array of U32's, with one entry for each frame.
Duplicate frame offsets in this block are allowed, if a certain frame is to be shown multiple times during animation.
uint8_tcompression_scheme;// Compression scheme, see below.
uint8_ttransparency_index;// palette index used for transparent pixels (not yet implemented)
uint16_tdelay;// frame delay time for animations (in units of milliseconds)
}qgf_frame_v1_t;
// _Static_assert(sizeof(qgf_frame_v1_t) == (sizeof(qgf_block_header_v1_t) + 6), "qgf_frame_v1_t must be 11 bytes in v1 of QGF");
```
If this frame is grayscale, the _frame descriptor block_ (or _frame delta block_ if flags denote a delta frame) is immediately followed by this frame's corresponding _frame data block_.
If the frame uses an indexed palette, the _frame descriptor block_ (or _frame delta block_ if flags denote a delta frame) is immediately followed by this frame's corresponding _frame palette block_.
Frame format possible values:
*`0x00`: 1bpp grayscale, no palette, `0` = black, `1` = white, LSb first pixel
*`0x01`: 2bpp grayscale, no palette, `0` = black, `3` = white, linear interpolation of brightness, LSb first pixel
*`0x02`: 4bpp grayscale, no palette, `0` = black, `15` = white, linear interpolation of brightness, LSb first pixel
*`0x03`: 8bpp grayscale, no palette, `0` = black, `255` = white, linear interpolation of brightness, LSb first pixel
*`0x04`: 1bpp indexed palette, 2 colors, LSb first pixel
*`0x05`: 2bpp indexed palette, 4 colors, LSb first pixel
*`0x06`: 4bpp indexed palette, 16 colors, LSb first pixel
*`0x07`: 8bpp indexed palette, 256 colors, LSb first pixel
Frame flags is a bitmask with the following format:
*`[1]` -- Delta: Signifies that the current frame is a delta frame, which specifies only a sub-image. The _frame delta block_ follows the _frame palette block_ if the image format specifies a palette, otherwise it directly follows the _frame descriptor block_.
*`[0]` -- Transparency: The transparent palette index in the _blob_ is considered valid and should be used when considering which pixels should be transparent during rendering this frame, if possible.
This block describes the palette used for the frame. The _blob_ contains an array of palette entries -- one palette entry is present for each color used -- each palette entry is in QMK HSV888 format:
uint16_tleft;// The left pixel location to draw the delta image
uint16_ttop;// The top pixel location to draw the delta image
uint16_tright;// The right pixel location to to draw the delta image
uint16_tbottom;// The bottom pixel location to to draw the delta image
}qgf_delta_v1_t;
// _Static_assert(sizeof(qgf_delta_v1_t) == 13, "qgf_delta_v1_t must be 13 bytes in v1 of QGF");
```
## Frame data block :id=qgf-frame-data-descriptor
* _typeid_ = 0x05
* _length_ = variable
This block describes the data associated with the frame. The _blob_ contains an array of bytes containing the data corresponding to the frame's image format:
@@ -87,9 +87,13 @@ To configure the default layer sounds, you would want to define this in your `co
## Resetting the keyboard
There is the `RESET` quantum keycode that you can use. But if you want to reset the board as part of a macro, rather than hitting a key separately, you can do that.
There is the `QK_REBOOT` or `QK_RBT` quantum keycode that you can use. But if you want to reset the board as part of a macro, rather than hitting a key separately, you can do that.
And to do so, add `reset_keyboard()` to your function or macro, and this will reset to bootloader.
And to do so, add `soft_reset_keyboard()` to your function or macro.
## Reset to bootloader
To reset to the bootloader use `QK_BOOTLOADER` or `QK_BOOT` keycode or `reset_keyboard()` function.
Direct pins are when you connect one side of the switch to GND and the other side to a GPIO pin on your MCU. No diode is required, but there is a 1:1 mapping between switches and pins.
When specifying direct pins you need to arrange them in nested arrays. The outer array consists of rows, while the inner array is a text string corresponding to a pin. You can use `null` to indicate an empty spot in the matrix.
When specifying direct pins you need to arrange them in nested arrays. The outer array consists of rows, while the inner array uses text strings to identify the pins used in each row. You can use `null` to indicate an empty spot in the matrix.
Example:
@@ -108,7 +108,58 @@ Example:
}
```
### RGB Lighting
## Non-RGB LED Lighting
This section controls basic 2-pin LEDs, which typically pass through keyswitches and are soldered into the PCB, or are placed in PCB sockets.
### Backlight
*`breathing`
* Enable backlight breathing, if supported
*`breathing_period`
* The length of one backlight “breath” in seconds
*`levels`
* The number of brightness levels (maximum 31, excluding off)
*`pin`
* The pin that controls the backlight LED(s)
Example:
```json
{
"backlight":{
"breathing":true,
"breathing_period":5,
"levels":15,
"pin":"B7"
}
}
```
### LED Indicators
Used for indicating Num Lock, Caps Lock, and Scroll Lock. May be soldered in-switch or in a dedicated area.
*`num_lock`
* The pin that controls the `Num Lock` LED
*`caps_lock`
* The pin that controls the `Caps Lock` LED
*`scroll_lock`
* The pin that controls the `Scroll Lock` LED
Example:
```json
{
"indicators":{
"num_lock":"B6",
"caps_lock":"D2",
"scroll_lock":"A3"
}
}
```
## RGB Lighting
This section controls the legacy WS2812 support in QMK. This should not be confused with the RGB Matrix feature, which can be used to control both WS2812 and ISSI RGB LEDs.
@@ -152,7 +203,7 @@ Example:
}
```
#### RGBLight Animations
### RGBLight Animations
The following animations can be enabled:
@@ -187,3 +238,25 @@ Example:
```
The device version is a BCD (binary coded decimal) value, in the format `MMmr`, so the below value would look like `0x0100` in the generated code. This also means the maximum valid values for each part are `99.9.9`, despite it being a hexadecimal value under the hood.
These features are enabled by default, but may not be needed. Double check to make sure, though.
Largest in size is "magic" -- the QMK magic keycodes -- which control things like NKRO toggling, GUI and ALT/CTRL swapping, etc. Disabling it will disable those functions.
If you use `sprintf` or `snprintf` functions you can save around ~400 Bytes by enabling this option.
```make
AVR_USE_MINIMAL_PRINTF= yes
```
This will include smaller implementations from AVRs libc into your Firmware. They are [not fully featured](https://www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html#gaa3b98c0d17b35642c0f3e4649092b9f1), for instance zero padding and field width specifiers are not supported. So if you use `sprintf` or `snprintf` like this:
If you've done all of that, and you don't want to disable features like RGB, Audio, OLEDs, etc, there are some additional options that you can add to your config.h that can help.
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.