* Nix: Allow calls to `bin/qmk` even when the build was started by `qmk`
The `$PATH` modifications performed by the Nix wrapper for the `qmk`
executable prevent `bin/qmk` from working properly (the changed `$PATH`
contains a wrong `python3` executable which does not have the needed
Python modules in its module path). As a workaround, disable the
generation of that wrapper for the `qmk` Python package (there is yet
another wrapper generated while building the Python environment, which
would still set the Python module path properly when running `qmk`).
Although `bin/qmk` is officially deprecated, QMK CLI still invokes it in
some cases (at least `qmk doctor` and `qmk pytest`), therefore keeping
these invocations working is useful.
* Nix: Update `util/nix/pyproject.toml` to match `requirements*.txt`
Update the Python dependency information used by Poetry to match the
current state of the qmk_firmware code.
* Nix: Bump QMK CLI dependency to 1.0.0; bump other Python deps
Update Python dependencies for nix-shell to the most recent releases:
- dotty-dict: 1.3.0 -> no longer used
- milc: 1.4.2 -> 1.6.2
- pep8-naming: 0.11.1 -> 0.12.1
- pygments: 2.9.0 -> 2.10.0
- pyrsistent: 0.17.3 -> 0.18.0
- pyusb: 1.1.1 -> 1.2.1
- setuptools-scm: 6.0.1 -> no longer used
- qmk: 0.1.0 -> 1.0.0
- qmk-dotty-dict: not used -> 1.3.0.post1
- yapf: 0.30.0 -> 0.31.0
Note to self: The command to update Python dependencies changed to:
( cd util/nix && nix run 'nixpkgs#poetry' -- update --lock )
* Revert "Short term bodge for firmware size bloat (#14144)"
This reverts commit a8d6547346.
* Revert "Tidy up quantum.c now some of tmk_core has been merged (#14083)"
This reverts commit c4dbf4bf01.
Specifically, if you enable the shared endpoint for mouse reports (or keyboard, which force enables it for mouse), and you don't have mousekeys enabled, it does not properly enable shared mouse EP for pointing device (which uses mouse reports). This cause it to error out in compiling. This fixes up some of the logic to ensure that all use cases are supported, and consolidates some of the code.
* Add keyboard Q1
* Update keyboards/keychron/q1/readme.md
* Update keyboards/keychron/q1/rev_0100/rules.mk
* Update keyboards/keychron/q1/readme.md
* Change layer switch function to "default_layout_set"
* Update keyboards/keychron/q1/rev_0100/info.json
* Update keyboards/keychron/q1/q1.c
* Mask out the DIP switch to fix sleeping issue when switch is ON
* Added and changed readme.md
Added keyboards\q1\rev_0100\readme.md
Changed keyboards\q1\readme.md since different MCU may used in other version.
* update
* update keymap name
* update keymap for keychron/q1/rev_0102
* Update info.json
* adding uf2 flash support for blackpill 401
* forgot to add blackpill to keyboard header file
* making changes requested by drashna
* fixing tzarc s comments
* removing the keyboard
* undo the change to dactyl_manuform.h
This patch corrects 2 issues with the LED matrix of the KDBFans KBD67 Lite (v3)
* Incorrect mapping of the right-shift, down-arrow, and right-arrow. (i.e. `NO_LED` positions of the `g_led_config` key matrix in the .c file do not match the `LAYOUT_65_ansi_blocker` matrix in the .h file.
* Remapping of the *LED Index to Physical Position* using physical measurements from actual keyboard and accounting for the southpaw LED position to define the true centre of the keyboard (more relevant to circular animations).
* Make solo half of split keyboards (more) usable.
Using only one half of a split keyboard (that's using the split_common
framework to communicate) is not a great experience, since several read
timeouts per scan cycle cause an unusably slow scan rate.
This change blocks all split communication attempts for 500 ms
(configurable) after an error occurs, causing the scan rate to become at
least _more_ usable, but might need some tweaking to work fully on most
keyboards. One read timeout still needs to occur after the 500 ms has
passed, and if that timeout isn't low enough, some scan cycles may still
be too slow.
* Fix lint complaint.
* Require 25 consecutive comm errors to see comms as disconnected.
The number of max errors can be overridden by defining
`SPLIT_MAX_CONNECTION_ERRORS`.
* Add comments to new defines, and ability to disable disconnection check.
Also increase `SPLIT_MAX_CONNECTION_ERRORS` to 40, since it's divisible
by most relevant numbers for the description.
* Make lint happy ...again
* Only update `connection_check_timer` when needed.
* Add new defines to split keyboard documentation.
* Move connection timeout logic to transport.c, add `is_transport_connected`.
* Use split_common disconnection logic in matrix.c.
Instead of doing more or less the same thing twice.
* Move disconnection logic to `transport_master`.
Is a cleaner implementation, and causes the scan rate while disconnected
to increase instead of decrease.
* Lint fixes.
* Lower default `SERIAL_USART_TIMEOUT` to 20 ms.
The read timeout must be low enough to not cause exessively long scan
cycles when using a solo split half. 10 ms was determined from testing
to work fine even with the slowest defined baudrate of 19200 (5 ms was
too low for that case), so 20 ms should be fine for most cases.
* Remove `SERIAL_USART_TIMEOUT` from ergodox_infinity/config.h
Was somewhat mistakenly included in an earlier PR.
* Fix building with `USE_I2C`.
* Reduce built firmware size.
Not really sure why this works, the idea was taken from tzarc's work on
split disconnection.
* Tweak and improve opt-out for split disconnection logic.
There are now two ways to opt out from this feature:
* Set `SPLIT_MAX_CONNECTION_ERRORS` to 0. This will completely disable
the connection status checks (also affects the slave matrix reset logic in
matrix.c, though).
* Set `SPLIT_CONNECTION_CHECK_TIMEOUT` to 0. This will only disable the
communication throttling while disconnected. Will make the firmware
smaller.
* Make split disconnection logic work with custom transports.
Includes a fallback implementation for keyboards using a custom
split_util.c but not a custom matrix.c (currently no such keyboard seems
to be merged, though).
* Remove unnecessary include of timer.h
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Joel Challis <git@zvecr.com>
* Fill the oleds with right mods
* Enable double mods on x32 oleds
* Disable forced NKRO
* Make oleds fancy only on good MCUs
* Overhaul oled display
* Further enhance oled, with kitty!
* Final oled form
* Not working transport
* Transport id of woring
* Add acceleration
* fix button placement for accel macro
* Fix accelartion location and behavior
* Remove OLED sync code
* Fix alignment issue
* Remove audio hack
* Fix up zima keymap
* Add matrix slave scan function and cleanup drashna.h
* Clean up user space
* Allow userspace sync to be disable-able
* Fix weird issue with audio
* Fix alignment issue with user split sync
* Disable second rgb matrix task
* Disable additional animations
* Change dynamic keymap settings
* Hacky fix for borked corne
* Add Blackpill (F411) support to tractyl manuform
* remove manual via eeprom reset
* Remove all references to rgblight twinkle
* Fix issues with config processing
* Support using a timer for wait_us() on ChibiOS-based boards (#12198)
There are spare GPT timers that can be used to get a more accurate
wait_ms() time. This is required for the matrix scan unselect delay (30µs)
to be shorter than the system tick rate of 100µs.
This is limited to the maximum GPT duration of 65535 so values above that
will automatically use the previous implementation based on the system
tick.
Using a specific timer means it can't be shared by another thread at the
same time so when wait_us() is called from anything other than the main
thread it will use the system tick implementation too.
* Update tmk_core/common/chibios/wait.c
* Update tmk_core/common/chibios/wait.c
Co-authored-by: Joel Challis <git@zvecr.com>
* rename LAYOUT to LAYOUT_all
* add info.json
* override DYNAMIC_KEYMAP_LAYER_COUNT for via keymap
The via keymap only initialized two layers without overriding the default value of DYNAMIC_KEYMAP_LAYER_COUNT (4).
This commit sets DYNAMIC_KEYMAP_LAYER_COUNT for the via keymap to 2.
* noah_avr.h: use QMK 3-character notation for matrix positions
* Community Layout support, Stage 1
- rename LAYOUT_ansi to LAYOUT_65_ansi_blocker
- rename LAYOUT_ansi_splitbs to LAYOUT_65_ansi_blocker_split_bs
- enable Community Layout support
* info.json: add line breaks between rows
* info.json: correct LAYOUT_iso data
- unsplit the Backspace
- change ANSI Enter to ISO Enter
- split the left Shift
* Community Layout support, Stage 2
- rename LAYOUT_iso to LAYOUT_65_iso_blocker
- update Community Layout support
* Community Layout support, Stage 3
- add LAYOUT_65_iso_blocker_split_bs
- update Community Layout support
* noah_avr.h: add matrix diagram
* info.json: human-friendly formatting
* info.json: remove "w":1 instances
* info.json: correct positions of Left, Down and Right Arrow keys
* info.json: add LAYOUT_all data
* move Home key to end of home row
According to photographs of the keyboard, the fourth key down on the right side is physically on the home row. This commit moves the key argument and keycodes to the home row.
* whale75.h: use QMK 3-character notation for matrix
* whale75.h: add matrix diagram
* add keyboard-level encoder functionality
* info.json: correct key sequence on ISO layouts
* Update new community universal keymaps
* Revert bottom row to default for better use of WIN_MODS and MAC_MODS
* Revert to use public domain songs
* Update Dpad layer in junonum to tailor for StarCraft group control
* Remove junonum512
* Update junonum readme
* Define custom songs in the keymap
* Move DP_OFF location
* Update DPAD modifiers
* Update F-row placement in junonum dpad layer
* Update CapsLock location and rectify KC_APP
* Update keymap & readme
-Keymap.c: Key combinations removed for resetting and added a new way to reset. Also removed unused timer code.
-config.h & rules.mk: Removed on kemap level (these were there for the key combo's)
-Readme.md: Changed the preview image and changed the description to reset the keyboard. Also added what connector type is used.
* Update readme.md
Better wording on how to get the keyboard in bootloader mode
* Update keymap.c
Switched + and - around, same with / and *.
* add info.json for Quefrency rev1
* add info.json for Quefrency rev2
* add info.json for Quefrency rev3
* add info.json for Quefrency rev4
* remove "global" Quefrency info.json
* remove layout macro aliases from keyboard headers
These were moved into the info.json files.
* rename layout macros
The existing layout macro names were not accurate to QMK's standard for the names that were given.
- rename LAYOUT_65_ansi_blocker to LAYOUT_65_ansi_blocker_split_bs
- rename LAYOUT_65_iso_blocker to LAYOUT_65_iso_blocker_split_bs
* correct info.json data
* add LAYOUT_65_iso_blocker
* add LAYOUT_65_ansi_blocker
* add Community Layout support
* update grid alignment on layout macros
* add LAYOUT_all
* refactor default and via keymaps
- use LAYOUT_all macro
- use _______ for KC_TRNS
- via keymap fixes
- swap KC_BSPC for KC_DEL on Layer 1 (matches default keymap)
- remove KC_PGUP from Layers 2 and 3 (makes both layers fully transparent)
* Add config.h and rules.mk support for data driven keymaps
* tidy up after rebase
* Rename key as it can contain more than just keyboard overrides
* tidy up after rebase
* Add validation
* Remove hysteresis on 4x encoders
Sometimes, controller skips encoder pulses and when it returns to default position, the encoder_pulses variable isn't equals 0. And when I turn encoder in opposite direciton, it skips first click becase of encoder_pulses crosses zero. To prevent this, I add the ENCODER_DEFAULT_POS constant, and reset encoder_pulses into 0 when the state variable equals ENCODER_DEFAULT_POS.
* Documentation for ENCODER_DEFAULT_POS
* Added gmmk pro paddlegame keymap
* Replaced config.h with my own
* Adjust code to better fit style guide
* Update readme to include layout
* Fixed keymap, was missing a few keys
* Replaced all instances of _isWinKeyDisabled with keymap_config.no_gui
* Update keyboards/gmmk/pro/ansi/keymaps/paddlegame/keymap.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Tomas Guinan <bngrybt@gmail.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Add digitizer HID interface for setting the mouse cursor position at
absolute screen coordinates. Tested on Pro Micro, Proton C and
Blackpill.
* Update docs/feature_digitizer.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update tmk_core/protocol/usb_descriptor.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add missing copyrights
Add V-USB support
* Add support for digitizer dedicated endpoint for lufa and chibios.
Fix formatting issues
Move digitizer_task definition to the feature's base implementation file
* Run cformat on modified files
* Change digitizer report usage to Digitizer instead of Pen to avoid
pointer disappearing on Windows.
* Update tmk_core/protocol/vusb/vusb.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Run cformat from docker image
* Remove send_digitizer from host_driver_t and instead rely on the
declaration being the interface to the implementation in each
HW-specific usb implementation.
* Fix build : send_digitizer shouldn't be static in vusb and add
weak-linkage implementation for tests without usb implementation
* Change digitizer user interface to match pointing device's
* Update documentation with new API
Co-authored-by: a-chol <nothing@none.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add alternate ldscript for STM32duino (F103xB)
* Refactor out common ldscript stuff
* Move ldscripts into stm32duino board dir, add search path to ldflags
* Change animations to require explicet activation
* Add support for legacy config
* Make default for now
* Add LED Matrix support
* change LED Matrix docs
* add some split data to info.json
* add tags
* add half of config_options.md to info.json
* add support for designating master split
* sort out split transport and primary
* fix bad data in UNUSED_PINS
* fixup custom transport
* wip
* allow for setting split right half keyboard matrix
* add SPLIT_USB_DETECT
* minor cleanup
* fix an erroneous message
* rework split.usb_detect
* adding missing rgblight vars to info.json
* add mouse_key to info.json
* add all remaining options from docs/config_options.md
* fix audio voices
* qmk info: Change text output to use dotted notation
* tweak layout output
* resolve alias names
* break out some functions to make flake8 happy
* add a field for bootloader instructions
* qmk generate-info-json: add a write-to-file argument
Adds an argument that instructs qmk generate-info-json to write the output to a file instead of just to the terminal.
* -arg_only, +action
Because it was never my intention that one would have to specify a value for the argument that enables writing the file.
* Bring qmk generate-info-json inline with other generate commands
* pytest fixup
* fix esca/getawayvan
* fix data driven errors for bpiphany converters
* features.force_nkro -> usb.force_nkro
* split.primary->split.main
* fix esca/getawayvan_f042
* fix the bpiphany converters for real
* fix bpiphany/tiger_lily
* Apply suggestions from code review
Co-authored-by: Nick Brassel <nick@tzarc.org>
* fix generate-api errors
* fix matrix pin extraction for split boards
* fix ploopyco/trackball_nano/rev1_001
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: Nick Brassel <nick@tzarc.org>
* info.json: apply human-friendly formatting
* info.json: correct key sequence
Places the arrow keys in the proper place in sequence.
* correct maintainer's GitHub link in readme
User changed their GitHub username; previous URL was Error 404.
* correct LAYOUT_tkl_ansi data
Number row was positioned 0.25u too low.
* correct LAYOUT_tkl_ansi macro
- remove position K027 (right half of Split Backspace)
- remove position K096 (right portion of Split Right Shift)
* correct LAYOUT_tkl_iso macro
- remove position K027 (right half of Split Backspace)
- remove position K096 (right portion of Split Right Shift)
* enable Community Layout support
* add LAYOUT_tkl_ansi_split_bs_rshift and LAYOUT_tkl_iso_split_bs_rshift
* Enable sync of OLED/ST7565 display on/off state on Splits
* Only send if states are not matched
Co-authored-by: Nick Brassel <nick@tzarc.org>
Co-authored-by: Nick Brassel <nick@tzarc.org>
* new keyboard: handwired/directpins
* fix promicro keyboard_name
* add teensy2 and teensy2++ support
* align with handwired/onekey
* tweak pids
* add teensy 3.2 and teensy lc to directpins
* move directpins from handwired to ez_maker
* add docs for easy maker
* move rotary encoder to top row of layout macro
Makes the layout macro and keycodes resemble the assembled keyboard.
* update info.json data
- convert tabs to spaces
- use human-friendly formatting
- fill in key object labels
- adjust object sequence for layout macro changes
- Dump key buffer when combos are disabled.
- Recursive calls to `dump_key_buffer` need to start dumping the buffer
from index i+1 to avoid possible infinite loops.
- Handle combo key releases even though combo processing is disabled.
* rename LAYOUT_default to LAYOUT_all
* apply human-friendly formatting to info.json
* correct keyboard dimensions
* correct data for LAYOUT_tsangan
* add labels to LAYOUT_ansi data
* add labels to LAYOUT_all data
* add labels to LAYOUT_iso data
* crin.h: update grid alignment of matrix identifiers
* crin.h: add matrix diagram
* physically position matrix identifiers for LAYOUT_all
- move k2d to top row (right half of split Backspace)
- move k41 to fourth row (right half of split Left Shift [KC_NUBS])
* physically position matrix identifiers for LAYOUT_iso
- move k1d to top row ([KC_NUHS])
- add k41 to fourth row ([KC_NUBS], previously missing)
* refactor keymaps
- grid-align keycodes
- use four-space indent
* correct data for LAYOUT_iso
- move Enter key to home row
* rename LAYOUT_tsangan to LAYOUT_ansi_tsangan
* add LAYOUT_iso_tsangan
* update readme.md
- add `make` command for building
- add "Flashing example..."
- touch-up bootloader jump instructions (previous Markdown didn't render ideally on GitHub)
* extend keymap functionality
- add Grave Accent, Function keys, Print Screen, Scroll Lock and Pause keycodes to keymaps
- add RESET keycode (Fn+R)
- use KC_RGHT for Right arrow
* touch-up bootloader instructions on readme
- note that Bootmagic Lite jump erases persistent settings
- note that Fn+R is RESET keycode by default
- Remove disused dz60/jdelkins_ss keymap
- Manage configured features for firmware size
- Improve build configuration for the secrets feature
- Various keymap tweaks
- Clean up formatting in various places
* add support for m65 and simple 5x13 ortholinear
* Update keyboards/m65/keymaps/default/keymap.c
Co-authored-by: Sergey Vlasov <sigprof@gmail.com>
* Update keyboards/m65/keymaps/default/keymap.c
Co-authored-by: Sergey Vlasov <sigprof@gmail.com>
* Update keyboards/m65/keymaps/default/keymap.c
Co-authored-by: Sergey Vlasov <sigprof@gmail.com>
* Update keyboards/m65/keymaps/default/keymap.c
Co-authored-by: Sergey Vlasov <sigprof@gmail.com>
* Update keyboards/m65/keymaps/default/keymap.c
Co-authored-by: Sergey Vlasov <sigprof@gmail.com>
* Update keyboards/m65/keymaps/default/keymap.c
Co-authored-by: Sergey Vlasov <sigprof@gmail.com>
* updates as per @sigprof review plus reformat
* pins all now are defined at microcontroller level
* profuct id defined at microcontroller level
* put leds on when _ADJ is on
* add danish keymap
* make default uk centric iso as per readme
* default is now iso generic, uk is its own business
* add license
* update imgur links to reflect the layout
* leds for _ADJ layer now do not prevent the other layers leds to get on
* Update keyboards/m65/keymaps/uk/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/m65/keymaps/dk/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/m65/keymaps/uk/readme.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/m65/readme.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* add support for gd32f303cct6 by we act in rev2
* Revert "add support for gd32f303cct6 by we act in rev2"
This reverts commit 4ad3834925.
* Update keyboards/m65/rev1/rules.mk
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/m65/keymaps/dk/readme.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/m65/keymaps/uk/readme.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/m65/keymaps/default/readme.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* remove empty hal
* add capslock
* Update keyboards/m65/readme.md
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/m65/config.h
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: Alin M Elena <alin-marin.elena@stfc.ac.uk>
Co-authored-by: Sergey Vlasov <sigprof@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Support all the 0.2 Ferris variants
For the Compact, the High and the Mini, create a new directory so each
keyboard may have the correct USB descriptor and a readme with more
specific information about it.
For the Bling, also add support for the underglow functionality.
Change the "MANUFACTURER" string to "Cuddly Keyboards Ltd.", the
name of the company I incorporated to sell keyboards, and change the
default descriptor from "Ferris the keeb" to "Ferris 0.2" which is more
descriptive.
I didn't update the 0.1 variants as I don't intend to sell these kits
with "Cuddly Keyboards". The firmware is mostly there to support
existing users.
Update the "hardware availability" to point to my new website:
cuddlykeyboards.com.
* Add RGB mode toggle to my keymap and to the default keymap
* Improve wording in the readme
* squashed commits to master
* Fix in case of missing user_song_list
Substitutes missing songs with safe versions
Also updated and added detail to keymap readme
* Adjust Readme to match qmk contrib conventions
* Update keyboards/planck/keymaps/rootiest/config.h
* Update keyboards/planck/keymaps/rootiest/keymap.c
* Update keyboards/planck/keymaps/rootiest/keymap.c
* Update keyboards/planck/keymaps/rootiest/keymap.c
* Update keyboards/planck/keymaps/rootiest/keymap.c
* Fixed license header to GPLv2+
* Fix Volume key delay
Use a static number instead of removed MEDIA_KEY_DELAY
* Use TAP_CODE_DELAY
* added license to config.h
* Clean up formatting
- Fixed markdown in readme
- Removed extra commented line from config.h
* Update keyboards/planck/keymaps/rootiest/config.h
* quantum/command.c: coalesce `print()`s in `command_common_help()` & `print_version()`
Also undo some damage by clang-format in b624f32f94
* quantum/command.c: replace `print(…); print_{,val_}{dec,hex}*(…);` sequences with single `xprintf(…)`
`print_{dec,hex}*(…)` are just `#define`s for `xprintf(…)` anyway.
Each additional `xprintf(…)` costs ~8 bytes: the call instructions,
plus an additional NUL terminator.
This _really_ adds up: this commit saves 814 bytes on my ATmega32.
* quantum/command.c: optimise `mousekey_console()` for size & legibility
Made various tweaks to the interface, but still functionally identical.
Assume `KC_1`…`KC_0` to be contiguous, and removed `numkey2num(…)` entirely.
It was exported in `command.h` by 1a0bac8bcc for no obvious reason, before
which it was `static`. I doubt anyone uses it.
`mousekey_console()` is now enabled regardless of `MK_3_SPEED`.
Needs fleshing out for things other than the X11 variant though.
This commit saves 638 bytes on my ATmega32.
* disambiguate Bootmagic rules in keymaps
The files edited by this commit were added at a point in time where `BOOTMAGIC_ENABLE = yes` enabled full Bootmagic.
This commit edits the files to specify that full Bootmagic is intended.
* remove BOOTMAGIC_ENABLE=full setting
* unify commented BOOTMAGIC_ENABLE rules in keyboards
Explicitly sets `BOOTMAGIC_ENABLE = no` in keyboards where the rule was commented out.
Command:
```
find keyboards/ -type f -name 'rules.mk' -and -not -path '*/keymaps/*' -exec sed -i -e 's;#[ \t]*\(BOOTMAGIC_ENABLE\)[ \t=]\+\([a-zA-Z]\+\).*;\1 = no # Virtual DIP switch configuration;g' {} +
```
* remove commented Bootmagic rules from keymap/user level
Command:
```
find keyboards/ layouts/ users/ -type f -name 'rules.mk' -exec sed -i -e '/#.*\(BOOTMAGIC_ENABLE\)[ \t=]\+\([a-z]\+\).*/d' {} +
```
* update keyboard BOOTMAGIC_ENABLE rule formatting
Sets the formatting of BOOTMAGIC_ENABLE rules to `BOOTMAGIC_ENABLE = [value]`, without the inline comments (which will be replaced later).
Command:
```
find keyboards/ -type f -name 'rules.mk' -and -not -path '*/keymaps/*' -exec sed -i -e 's;\(BOOTMAGIC_ENABLE\)[ \t=]\+\([a-z]\+\).*;\1 = \2;g' '{}' +
```
* update keyboards' BOOTMAGIC_ENABLE settings
Updates keyboard `rules.mk` files to use `BOOTMAGIC_ENABLE = lite` where `BOOTMAGIC_ENABLE = full` was being used.
Command:
```
find keyboards/ -type f -name 'rules.mk' -and -not -path '*/keymaps/*' -exec sed -i -e 's;\(BOOTMAGIC_ENABLE = \)full;\1lite;g' '{}' +
```
* update keymap/user BOOTMAGIC_ENABLE settings
Updates keymap/user `rules.mk` files to use `BOOTMAGIC_ENABLE = lite` where `BOOTMAGIC_ENABLE = full` was being used.
Commands:
```
find keyboards/ -type f -name 'rules.mk' -and -path '*/keymaps/*' -exec sed -i -e 's;\(BOOTMAGIC_ENABLE[ \t=]\+\)full;\1lite;g' '{}' +
find layouts/community/ users/ -type f -name 'rules.mk' -exec sed -i -e 's;\(BOOTMAGIC_ENABLE[ \t=]\+\)full;\1lite;g' '{}' +
```
* remove and replace inline comments in keyboards and keymap/user files
Removes and replaces the inline comments, which have been updated to read `Enable Bootmagic Lite`.
Commands:
```
find keyboards/ -type f -name 'rules.mk' -and -path '*/keymaps/*' -exec sed -i -e 's;\(BOOTMAGIC_ENABLE\)[ \t=]\+\([a-z]\+\).*;\1 = \2;g' '{}' +
find layouts/community/ users/ -type f -name 'rules.mk' -exec sed -i -e 's;\(BOOTMAGIC_ENABLE\)[ \t=]\+\([a-z]\+\).*;\1 = \2;g' '{}' +
find keyboards/ layouts/community/ users/ -type f -name 'rules.mk' -exec sed -i -e 's;\(BOOTMAGIC_ENABLE = lite\);\1 # Enable Bootmagic Lite;g' '{}' +
find keyboards/ layouts/community/ users/ -type f -name 'rules.mk' -exec sed -i -e 's;\(BOOTMAGIC_ENABLE = yes\);\1 # Enable Bootmagic Lite;g' '{}' +
find keyboards/ layouts/community/ users/ -type f -name 'rules.mk' -exec sed -i -e 's;\(BOOTMAGIC_ENABLE = no\);\1 # Enable Bootmagic Lite;g' '{}' +
```
* rename improperly named makefiles
Some files intended to be used as makefiles had improper names causing them to not be used as intended when building.
This commit corrects the filenames of the affected files.
* update renamed file with new rule formatting
* update QMK's template files
Updates QMK's `rules.mk` templates to use the new inline comment.
* update QMK Docs
- remove documentation of full Bootmagic
- update links to Bootmagic Lite doc
- add doc for Magic Keycodes
* rules.mk patch for coarse/ixora and coarse/vinta
* Add HOLD_ON_OTHER_KEY_PRESS option for dual-role keys
Implement an additional option for dual-role keys which converts the
dual-role key press into a hold action immediately when another key is
pressed (this is different from the existing PERMISSIVE_HOLD option,
which selects the hold action when another key is tapped (pressed and
then released) while the dual-role key is pressed). The Mod-Tap keys
already behave in a similar way, unless the IGNORE_MOD_TAP_INTERRUPT
option is enabled (but with some additional delays); the added option
makes this behavior available for all other kinds of dual-role keys.
* [Docs] Update tap-hold docs for HOLD_ON_OTHER_KEY_PRESS
Document the newly added HOLD_ON_OTHER_KEY_PRESS option and update the
documentation for closely related options (PERMISSIVE_HOLD and
IGNORE_MOD_TAP_INTERRUPT).
Use Layer Tap instead of Mod Tap in examples for PERMISSIVE_HOLD and
HOLD_ON_OTHER_KEY_PRESS, because the effect of using these options with
Mod Tap keys is mostly invisible without IGNORE_MOD_TAP_INTERRUPT.
Add comments before return statements in sample implementations of
`get_ignore_mod_tap_interrupt()`, `get_hold_on_other_key_press()` and
`get_permissive_hold()`.
Thanks to @Erovia and @precondition for comments and suggestions to
improve the documentation.
* info.json: use human-friendly formatting
* info.json: fix key sequences for ISO layouts
All the ISO layouts had the Enter key out-of-sequence, causing key-assignment mismatches in QMK Configurator.
* Combo processing improvements.
Now it is possible to use ModTap and LayerTap keys as part of combos.
Overlapping combos also don't trigger all the combos, just exactly the
one that you press.
New settings:
- COMBO_MUST_HOLD_MODS
- COMBO_MOD_TERM
- COMBO_TERM_PER_COMBO
- COMBO_MUST_HOLD_PER_COMBO
- COMBO_STRICT_TIMER
- COMBO_NO_TIMER
* Remove the size flags from combo_t struct boolean members.
This in the end actually saves space as the members are accessed so many
times. The amount of operations needed to access the bits uses more
memory than setting the size saves.
* Fix `process_combo_key_release` not called correctly with tap-only combos
* Fix not passing a pointer when NO_ACTION_TAPPING is defined.
* Docs for `COMBO_ONLY_FROM_LAYER`
* Update docs/feature_combo.md
Co-authored-by: precondition <57645186+precondition@users.noreply.github.com>
* Update quantum/process_keycode/process_combo.c
Co-authored-by: precondition <57645186+precondition@users.noreply.github.com>
* Add `EXTRA_SHORT_COMBOS` option.
Stuff combo's `disabled` and `active` flags into `state`. Possibly can
save some space.
* Add more examples and clarify things with dict management system.
- Simple examples now has a combo that has modifiers included.
- The slightly more advanced examples now are actually more advanced
instead of just `tap_code16(<modded-keycode>)`.
- Added a note that `COMBO_ACTION`s are not needed anymore as you can
just use custom keycodes.
- Added a note that the `g/keymap_combo.h` macros use the
`process_combo_event` function and that it is not usable in one's
keymap afterwards.
* Update docs/feature_combo.md
Co-authored-by: precondition <57645186+precondition@users.noreply.github.com>
* Update docs/feature_combo.md
Co-authored-by: precondition <57645186+precondition@users.noreply.github.com>
* Update docs/feature_combo.md
Co-authored-by: precondition <57645186+precondition@users.noreply.github.com>
* Update docs/feature_combo.md
Co-authored-by: precondition <57645186+precondition@users.noreply.github.com>
* Update docs/feature_combo.md
Co-authored-by: precondition <57645186+precondition@users.noreply.github.com>
* Change "the" combo action example to "email" example.
* Update docs/feature_combo.md
Co-authored-by: precondition <57645186+precondition@users.noreply.github.com>
* Fix sneaky infinite loop with `combo_disable()`
No need to call `dump_key_buffer` when disabling combos because the
buffer is either being dumped if a combo-key was pressed, or the buffer is empty
if a non-combo-key is pressed.
* Update docs/feature_combo.md
Co-authored-by: precondition <57645186+precondition@users.noreply.github.com>
* Update docs/feature_combo.md
Co-authored-by: precondition <57645186+precondition@users.noreply.github.com>
Co-authored-by: precondition <57645186+precondition@users.noreply.github.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
* ps2_mouse on ARM: an interrupt-version of the ps2-mouse code ported to ARM/chibios
* ps2_mouse on ARM: link EXT callback-channel selection to the user defined PS2_LINE_CLOCK
* ps2_mouse on ARM: replace DELAY_X defines with hardware-agnostic wait_X
* ps2_mouse on ARM: replace chibios-specific defines for the pins/lines with defines from quantum/config_common.h
and drop the '_LINE' component from teh define name
* ps2_mouse on ARM: expose the software-intterupt port as a user editable define
* Update docs/feature_ps2_mouse.md
Co-Authored-By: Hugo van Kemenade <hugovk@users.noreply.github.com>
* Update feature_ps2_mouse.md
* use a define to deduce the PS_DATA_PORT instead
* reduce all-zero extcfg to oneliner
* ps2_mouse: use generic wait instead of avr-delay
* Update docs/feature_ps2_mouse.md
* ps2_mouse: changes for new chibios version
(17.6.0 -> 19.1.0)
replacing the legacy externa-interrupt driver with pal-callbacks
* ps2_mouse: use PLATFORM_KEY
Co-Authored-By: Joel Challis <git@zvecr.com>
* ps2_mouse: clang-format corrections
* ps2_mouse: add systemlocks
using the chibios equivalent to AVRs cli: chSys[Unl|L]ock
Co-authored-by: Johannes <you@example.com>
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
Co-authored-by: Joel Challis <git@zvecr.com>
* Initial Ducky One 2 Mini keyboard and keymap
* Keymap macro issue, together with general polish suggestions
* Separate default keymap into proper default, iso and ansi versions
* info.json updates (Configurator support). DEBOUNCE define adjust.
* Unused keymap defines removed.
* update requested ducky one mini2 board changes
* ducky: don't trigger app key with left shift
* ducky: make default mouse key behavior more linear
* ducky: add GRAVE_ESC_GUI_OVERRIDE to allow for win+esc to work
* ducky: playpause on fn space
* ducky: disable RGB_MATRIX until driver is merged
* ducky: clang-format matrix and one2mini.c
* ducky: update requested changes
Remove WFI_IDLE since it's already in the rules.mk CORTEX_ENABLE_WFI_IDLE=TRUE
* ducky: update requested changes
* ducky: move winkey grave esc to default keymap
* ducky: remove dipswitch from keymap and use DIP_SWITCH_MATRIX_GRID instead
* ducky: info.json lint
* ducky: enable DIP_SWITCH_ENABLE rule
* ducky: update readme
* ducky: fix backslash on default keymap
* ducky: remove unused USB_LED_CAPSLOCK_INDEX 28
* ducky: move mbi5042 led driver to ducky keyboard
* ducky: cosmetics
* ducky: requested changes
* ducky: refactor matrix.c again so we can better compare it to other boards
* ducky: remove bootmagic_lite as the boards bootloader trigger is actually handled in its own bootloader
* ducky: remove custom matrix
* ducky: update for chibios-contrib changes
* ducky: debug new USB driver
* ducky: debug usb issues
* ducky: update chibios version
* ducky: remove halconf.h
* ducky: update rules.mk
* ducky: update chconf.h
* Matching submodules.
* Restructure to explicitly define which board is in use, remove RGB driver pending followup PR.
* Revert "Matching submodules."
This reverts commit 2fbb34e0c6.
Co-authored-by: GitWellBack <48095880+GitWellBack@users.noreply.github.com>
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Add bootloader section to keyboard template
* Apply suggestions from code review
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
This change fixes the warning caused by deprecated way of configuring terminal profiles.
The warning caused by old settings.json is the following:
This is deprecated, the new recommended way to configure your default shell is by creating a terminal profile in `#terminal.integrated.profiles.windows#` and setting its profile name as the default in `#terminal.integrated.defaultProfile.windows#`. This will currently take priority over the new profiles settings but that will change in the future.
Refer to the link below for more information:
https://code.visualstudio.com/docs/editor/integrated-terminal#_configuration
* Fix overflow in WPM calculations.
First, the "fresh" WPM calculation could end up being up to 12000 (with
default `WPM_ESTIMATED_WORD_SIZE`) if keys were pressed more or less
simultaneously. This value has now been clamped down to 255, in effect
clamping WPM to its max value of 255.
Second, with `WPM_ALLOW_COUNT_REGRESSION` enabled, it was possible to
regress the WPM below 0 (i.e. to 255) by just repeatedly pressing
backspace.
* Fix WPM being limited to 235 due to float/int logic.
After a USB Reset event the device must, according to the spec wake up
from any suspend state, so the Configured event that arrives afterwards
should be interpreted as an implicit wakeup.
* Remove the #10088 hotfix for K20x MCU:s.
It seems to _cause_ the issue it intended to solve there.
* Cleaner way of removing #10088 hotfix.
Now only affects Ergodox Infinity, Whitefox and K-type, though.
Switches over Ergodox Infinity to the `IC_TEENSY_3_1` board, since that
was a nice place to implement the `restart_usb_driver` override.
However, I would guess this issue is present for other K20x/Teensy 3.1
boards as well...
* Fix comment regarding `IC_TEENSY_3_1` for all keyboards using it.
* momoka_ergo.h: use modified QMK 3-character notation
Renames the matrix position arguments to use QMK's K<row><column> notation, but using L or R for the left and right halves, respectively.
* physically arrange layout macro
Arrange the layout macro and keycodes to resemble the assembled keyboard.
* info.json: rebuild LAYOUT data
Fixes mispositioned keys in QMK Configurator.
* remove K214 from LAYOUT_1065_ansi macro
Position K214 is only used by the ISO layout (as KC_NUHS); it doesn't get used here. Removing it so the layout macro matches the info.json layout data.
Also updates info.json to use human-friendly formatting.
* add layout macros
Adds:
- LAYOUT_1065_ansi_split_bs macro
- LAYOUT_1065_iso macro
- LAYOUT_1065_iso_split_bs macro
- `default_iso` keymap
* add LAYOUT_all macro
Adds LAYOUT_all macro and a `default_all` keymap.
This PCB is unusual in that the ANSI Backslash and ANSI Enter do not share their matrix positions with the Non-US Backslash or ISO Enter keys at all. This layout macro supports both the ANSI and ISO positions in one macro/keymap.
* info.json: human-friendly formatting
- one key per line
- line breaks between physical rows
- four-space indent
* info.json: add data for LAYOUT_grid
* fix keymap paths
This commit corrects the paths for three keymaps that were in the wrong directory.
* refactor and bugfix abienz keymap
- remove extra commas
- use QMK-native aliases for KC_TRNS and KC_NO
- add include for Colemak keycode support
- use four-space indent
* refactor and bugfix michelle keymap
- remove inline comments for keymap layout
- remove extra commas
- use QMK-native aliases for KC_TRNS and KC_NO
- use four-space indent
* refactor and bugfix twolayer keymap
- remove extra commas
- refactor action_get_macro() keycode to QMK-native keycode
- use QMK-native aliases for KC_TRNS
- use four-space indent
- adjust grid alignment
* rename LAYOUT_grid to LAYOUT_ortho_5x15
* refactor config.h file
- use #pragma once include guard
- update MANUFACTURER and PRODUCT strings to be consistent with other OLKB boards
- remove Magic config (all settings are default)
* refactor atomic.c
- add license header
- use GPIO control functions
* refactor atomic.h
- add license header
- use #pragma once include guard
- remove redundant file includes
* refactor rules.mk
- remove Bootloader selection comments
- unify Build Option header comment to QMK template
- unify Build Option rules and inline comments
* alias LAYOUT_grid to LAYOUT_ortho_5x15
* info.json: human-friendly formatting
* use QMK 3-character notation for layout macro/data
* alu84.h: use #pragma once include guard
* clean up alu84.c
Remove unnecessary includes and functions.
* refactor config.h
- use #pragma once include guard
- enable Backlight Breathing
- align comments to QMK AVR template
* refactor default keymap
- add license header
- use layer_names enum
- refactor keymap to be more generic
- remove unnecessary and empty functions
* refactor turbomech keymap.c
- edit license header
- refactor keymap for readability (use QMK-native keycode aliases)
- remove unnecessary and empty functions
* refactor turbomech config.h
- use #pragma once include guard
- align to QMK template
* refactor turbomech rules.mk
Edit the file to make it conform to QMK template.
* align rules.mk to QMK template
* touch-up default keymap
* touch-up alu84.h
* rename LAYOUT to LAYOUT_75_ansi
Also enables Community Layout Support
* modernize readme.md
- update description
- convert keyboard data to list
- add flashing and bootloader instructions
- update Docs links
* alias LAYOUT to LAYOUT_75_ansi
* change readme image URL per fauxpark
* touch up turbomech keymap rules.mk per fauxpark
* rules.mk: convert tab to spaces
* info.json: human-friendly formatting
- one key object per line; line breaks between physical rows
- four-space indent
- remove trailing whitespace
* info.json: correct key object order for LAYOUT_numpad_6x4
Added a `default` case in `switch(ql_tap_state.state)` at line 493 and 494.
Without it compile firmware with Example 6 code will encounter 2 errors:
`enumeration value 'TD_NONE' not handled in switch`
`enumeration value 'TD_UNKNOWN' not handled in switch`
* Add bootloader size
Bootloader size needs to be 6144 to allow QMK to jump to the correct location with bootmagic
* Include dz60rgb v2.1
Add boot loader size to this pcb also
* [Keyboard] Added Compound keyboard support
* Small fixes for Compound keyboard
* Fixed readme and header file for Compound keyboard
* Update keyboards/compound/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Changed info.json and readme.md for Compound Keyboard
info.json - removed key_count
readme.md - changed PCB picture url to low-resolution
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
This takes up about 700 bytes of space, and needs to be swapped to
opt-in, rather than opt-out. Build failures in general on AVR due to the
scarcity of available flash. People can re-enable it by adding to their
keymap's config.h files:
```
#define RGBLIGHT_EFFECT_TWINKLE
```
PR #13296 changed the name of the `cformat` and `pyformat` commands to
`format-c` and `format-py` respectively. This PR updates the documentation
and some parts of the CLI to use the new names.
Also add documentation for the new `format-text` subcommand, introduced
in the same PR.
Currently, this feature isn't supported on splits, spent about an hour troubleshooting my board and firmware before asking, and turns out it's not in place. Note added to save others from this in the future.
* use human-friendly formatting in info.json
* move layout macro aliases to info.json
* correct and complete layout data
Corrects the layout data for a few layouts, adds the missing data, and renames some of the layout macros.
- rename LAYOUT_wkl_ansi_2_right_mods to LAYOUT_65_ansi_wkl
- rename LAYOUT_wkl_ansi_3_right_mods to LAYOUT_65_ansi_lwkl
- rename LAYOUT_wkl_iso_2_right_mods to LAYOUT_65_iso_wkl
- rename LAYOUT_wkl_iso_3_right_mods to LAYOUT_65_iso_lwkl
* modernize acr60.h
- use #pragma once include guard
- add license header
- use four-space indent
- use QMK three-character notation for layout macro arguments
* human-friendly format info.json
* remove `key_count` keys from info.json
* rename LAYOUT_2_shifts to LAYOUT_all
* move LAYOUT_all to top
* use QMK three-character notation in info.json
* refactor default keymap
- add license header
- remove third layer (does nothing)
- replace Shift-Escape keycode with KC_GESC
- use LAYOUT_all macro instead of LAYOUT
* modernize readme.md
- update header
- convert metadata section to list
- add flashing and bootloader jump instructions
- update Docs links
* use #pragma once include guard in config.h
* update LED Indicator API
* add license headers
* correct layout macro references
The keyboard's header file and info.json referenced different layout macro names.
* correct layout data
Insert an object for the Non-US Backslash key, which was previously missing.
* 2x1800 2021
* add support for writing a whole frame at a time
* improvements
* wip
* fix scrolling
* small tweak
* add a buffer that's larger than the display
* add the start of a font
* working upper and lower case letters
* add qmk animation
* integrate the message sign into the qmk task system
* add encoder defaults
* add MAX7219_LED_CUSTOM to config.h
* tweaks
* remove unneeded keymaps
* add a keymap showing how to control the signboard
* cleanup
* cleanup
* add a way to disable the startup test
* make it easier to define options at the keymap level
* Fix define names
Co-authored-by: Greg Cochard <gcochard@users.noreply.github.com>
* Apply suggestions from gcochard
Co-authored-by: Greg Cochard <gcochard@users.noreply.github.com>
* feedback from noroads
* format info.json
Co-authored-by: Greg Cochard <gcochard@users.noreply.github.com>
* Added iso layer support for the GMMK Pro iso version
* Adjusted the mapping
* aligning with best practises
* aligning with comments from PR
* Added iso layout to info.json
Moves the ISO Enter keycode to the home row for more consistency with the rest of QMK. Also grid-aligns the keycodes and adds a block comment for the layout macro.
* human-friendly formatting
Add line breaks between rows and halves.
* fix rounding issues
Fixes issues with y-offset values due to rounding in KLE.
* remove layout dead space; re-mirror halves
Removes the empty white space from the layout, and aligns the keys on the right half so they are a mirror of the left half.
* rename LAYOUT to LAYOUT_all
* refactor default keymap
- add license header
- use layer_names enum
- use LAYOUT_all macro
- update keymap to be more generic
- use QMK-native keycode aliases
* info.json: human-friendly formatting
* convert LAYOUT_iso into a proper LAYOUT_60_iso
* LAYOUT_all bugfix
In the physical sense, position k3d is to the left of k3c.
* rework LAYOUT_max into LAYOUT_60_ansi_split_bs_rshift
* remove LAYOUT_iso_splitrshift and iso_split_rshift keymap
* rework LAYOUT_hhkb into LAYOUT_60_hhkb
* amj60.h cleanup
- add license header
- use #pragma once include guard
- concatenate layout block comments
- remove unnecessary function headers
* add license header to amj60.c
* align config.h to QMK template
* align rules.mk to QMK template
* enable Community Layout support
* modernize readme.md
- add PCB image
- convert keyboard data to list
- add flashing and bootloader instructions
- update Docs links
The prototype of matrix_output_unselect_delay() has been changed as follows.
```c
void matrix_output_unselect_delay(uint8_t line, bool key_pressed);
```
Currently, no keyboard seems to be redefining `matrix_output_unselect_delay()`, so there is no change in the system behavior.
With this change, the keyboard level code can get some optimization hints, for example, the following.
```c
void matrix_output_unselect_delay(uint8_t line, bool key_pressed) {
/* If none of the keys are pressed,
* there is no need to wait for time for the next line. */
if (key_pressed) {
#ifdef MATRIX_IO_DELAY
# if MATRIX_IO_DELAY > 0
wait_us(MATRIX_IO_DELAY);
# endif
#else
wait_us(30);
#endif
}
}
```
* scale layout data
Seems the KLE data that was imported to make the original file was scaled 1.25x. This commit removes the scaling.
* human-friendly formatting
Insert line breaks between physical layout rows.
* remove instances where width or height is set to 1
The width and height of a key is defaulted to 1 if not provided by the JSON data, so there's no reason to set it manually.
* correct layout data
Fix incorrect key sizes/positions.
* rename LAYOUT to LAYOUT_65_ansi_blocker
* tweak human-friendly formatting for info.json
Add new lines for new rows.
* adjust keycode alignment in via keymap
* clean up extra lines in readme file
* enable 65_ansi_blocker Community Layout support
* clean up rules.mk
Aligns the inline comments.
Two occurrences of `MATRIX_ROWS` weren't properly changed to
`ROWS_PER_HAND` in #13330, causing a crash during boot on at least my
Ergodox Infinity (including #13481).
According to `helix/rev2/keymaps/fraanrosi/readme.md`, this keymap should be compiled with the following command:
```
make helix/rev2/under:fraanrosi
```
Therefore, when compiling all helix keymaps with the following command, an error occurs when compiling `fraanrosi`.
```
make helix:all
```
Therefore, add `LED_UNDERGLOW_ENABLE = yes` to `keymaps/fraanrosi/rules.mk` to suppress the error.
- Major change in the keymap to work with EurKey. Which relaxes some
constraints it had before when it had to take in consideration two
layouts.
With this the parenthesis can be moved to a better location instead
of being in the top right corner.
This also allows esc, del and rctrl to be moved to the base layer.
Only downside is that ctrl+lalt needed to be removed and instead
AltGr takes it's place. Add rctrl on right thumb cluster to
compensate for this which need some reorganization on the thumb
cluster.
- Split the symbol and function keys layer into two layers, one for
each hand. Make it easier to press symbols and function keys.
- Add some symbols specific for the EurKey layout.
- Change from running C-<tab> S-C-<tab> to page up/down for the right
rotary. As holding ctrl and using page up/down works the same in
firefox. Which allows the rotary to be useful for other things.
- Move scroll lock and insert to right rotary.
- Introducing close tap (CLO_TAP), which is a combination of the
double tap feature and my macros. E.g. pressing CLO_TAP and ( will
generate ()←. Which removes the need of the macros and makes it more
useful than DBL_TAP as it now saves me some keypresses. CLO_TAP exist
on both the left and right hand layers to make it easy to use.
- Use text for the secondary oled, firmware is too big after rebasing
on upstream master.
- Update image in the readme to reflect my new layout.
* Updated docs/ja/proton_c_conversion.md original tag.
* Updated docs/ja/other_vscode.md original tag.
* Updated docs/ja/feature_swap_hands.md original tag.
* Updated docs/ja/faq_general.md original tag.
* Updated docs/ja/feature_userspace.md original tag.
* Updated git co docs/ja/config_options.md original tag.
* [Keyboard] Set reasonable defaults for Corne keyboard
* Add note about bootmagic
* Make bootmagic config super weak
* cleanup
* Apply suggestions from code review
* Update keyboards/crkbd/readme.md
This prevents gcc from incorrectly trying to validate array bounds.
```
tmk_core/common/chibios/bootloader.c: error: '__builtin_memcpy' offset [0, 21] is out of the bounds [0, 0] [-Werror=array-bounds]
107 | __builtin_memcpy((void *) VBAT, (const void *)sys_reset_to_loader_magic, sizeof(sys_reset_to_loader_magic));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c16Fixes#12925
* correct info.json data
Removes an extra key object, and corrects the layout macro reference.
* refactor rules.mk file
- remove invalid `LAYOUTS` rule
- edits the rules.mk file to more closely resemble the file from QMK's AVR template.
* additional rules.mk cleanup per fauxpark
Apply suggestions from code review
* adjust key positioning in Configurator
Some of the keys were visually overlapping when rendered. Adjusted the key positioning to remove the overlaps.
* update readme.md
- fix a broken URL
- rewrite the Bootloader access instructions
- remove trailing whitespace
* added support for inverting the hand pin for split keyboards
* Added docs about SPLIT_HAND_LOW_IS_LEFT
* Update docs/feature_split_keyboard.md
bring #define for split hand pin low for left half name in line with grid pin define
Co-authored-by: Joel Challis <git@zvecr.com>
* Update quantum/split_common/split_util.c
update split hand pin low is left name to match split hand grid define
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Fix reddit link
Duplicate open parenthesis next to close parenthesis on NSSL
Add customisation instructions
Add lily58
Add gergo
Co-authored-by: Jonathan Dayton <jonathandayton23@gmail.com>
Clean up LAYOUT macro formatting
Add alternative vi-style navigation layout
Add kyria
Add minidox
Change order of keyboards
Add iris
Expand TOC
Re-order userspace subheadings
Add atreus
Add customisation section
Add split_3x5_3 and split_3x6_3 layouts
Add for_science
Fix wrong paths in keyboard config.h and keymap.c headings
Fix keyboard ordering
Fix blank lines around headings
Add compatibility with new org-mode version.
Remove keyboards/crkbd now covered by layouts/split_3x6_3
Add Halmak
Alphabetise alternative alpha arrangements
Move build options out of base layer alphas headings
Add list of keyboards supporting split_3x5_3 layout
Enable Auto Shift and Retro Shift
Add Retro Shift (Auto Shift for Tap Hold via Retro Tapping)
Change kyria thumb key mapping
Add planck_mit layout
Remove alternative bottom row support from ortho_4x12
Remove minidox
- Covered by split_3x5_3 layout
Add moonlander
Remove KC_ macros
Add 60_ansi layout
Add ortho_5x15 layout
Closesmanna-harbour/qmk_firmware#5
Co-authored-by: Rob <rob@debank.tv>
Fix typo (manna-harbour/qmk_firmware#7)
Author: sonnius <sonnius@users.noreply.github.com>
Add redox_w (manna-harbour/qmk_firmware#8)
Author: Brian Romanko <hello@bromanko.com>
Co-authored-by: Manna Harbour <51143715+manna-harbour@users.noreply.github.com>
Add AUTO_SHIFT_NO_SETUP to reduce firmware size
Update image paths
Add instructions to checkout development branch
Add kyria extended thumbs option, change default, add KLE
Change clipboard keys
- Change order to be mirror of windows bindings
- Change default to use CUA bindings for Cut, Copy, and Paste, and Fun Cluster
bindings for Undo and Redo
- Add alternative bindings
- Fun Cluster (original miryoku bindings)
- Mac
- Windows
- Change prefix for local macros from X_ to U_
Disable Retro Shift, enable Auto Shift for non-alphas
Revert "Add Retro Shift (Auto Shift for Tap Hold via Retro Tapping)"
Add Experimental Features section
Update miryoku image link
Update cover image link
Add dactyl_manuform/4x5
Add cutomisation examples
Add https to remote example
Fix dactyl_manuform/4x5 subset mapping
Add extended thumbs to ortho_4x12
Update Colemak Mod-DH naming
Closesmanna-harbour/qmk_firmware#13
Add dactyl_manuform/5x6
Resolvesmanna-harbour/qmk_firmware#14
Co-authored-by: Sebastian Morales <sebastian.moralesd@gmail.com>
Add note on FORCE_LAYOUT
- Needed to use EXTENDED_THUMBS on planck
Add parent directories to keyboard headings and re-order
Add keyboardio/atreus
Resolvesmanna-harbour/qmk_firmware#15
Add torn
Resolvesmanna-harbour/qmk_firmware#16
Author: Brian Romanko <hello@bromanko.com>
Co-authored-by: Manna Harbour <51143715+manna-harbour@users.noreply.github.com>
Change map to zip
- Adds support for python3, still compatible with python2.
Resolvesmanna-harbour/qmk_firmware#10Resolvesmanna-harbour/qmk_firmware#19
Co-authored-by: Ori <ori@oribarbut.com>
Add python-version
Add sofle
Add ergotravel
Add ortho_5x12
Add ortho_4x10
Add :main no header argument to C code blocks
resolvesmanna-harbour/qmk_firmware#11resolvesmanna-harbour/qmk_firmware#12
Co-authored-by: RubioJr9 <u0893472@utah.edu>
Add flipped layers and inverted-T nav alternative layouts
- Separate tap_table into alphas_table and thumbs_table
- Add mode argument to table-layout-half
- Remove layer_name
- Rename layers
- Add mods and clipboard to MBO and mirror
- Add MIRYOKU_LAYERS=FLIP
- Add MIRYOKU_NAV=INVERTEDT
Add layer diagrams
Update contact section
Update links for Bilateral Combinations and Retro Shift
Add description and no reverse angle option to 60_ansi layout
Update list of keyboards supporting community layouts
- and example build command lines
Change moonlander thumb keys
Update list of keyboards supporting split_3x5_3
Add license to tangled C source files
* Unite half-duplex and full-duplex serial driver.
* Add full duplex operation mode to the interrupt based driver
* Delete DMA UART based full duplex driver
* The new driver targets #11930
* Fix freezes with failing transactions in half-duplex
* Increase default serial TX/RX buffer size to 128 bytes
* Correctly use bool instead of size_t
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Updated docs/ja/how_a_matrix_works.md original tag.
* Updated docs/ja/api_overview.md original tag.
* Updated docs/ja/contributing.md original tag
* Updated docs/ja/coding_conventions_c.md original tag
* Updated docs/ja/reference_configurator_support.md original tag
* Updated docs/ja/reference_glossary.md original tag
* Updated docs/ja/api_docs.md original tag
* Updated docs/ja/feature_stenography.md original tag
* Updated docs/ja/documentation_templates.md original tag
* Updated docs/ja/faq_keymap.md original tag
* Updated docs/ja/understanding_qmk.md original tag
* cleaning up
* deleting to undelete
* Stub out defaults
* Jabberwocky firmware WIP
* Stubbing out keymap spacing
* Default keymap and layout updates
* start stubbing out JSON for configurator
* more WIP
* Update jabberwocky.h
* Add Readme
* Apply suggestions from code review
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Fix layout capitalization
* Updates to personal and default keymaps
* Add instructions for jumping the bootloader
* Update keyboards/nopunin10did/jabberwocky/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add easier ctrl-alt-del to my keymap
* Undo changes from other master
* Add back DYNAMIC_KEYMAP_LAYER_COUNT constant
* Fix readme markup to use list items
* Give my layout VIA compatibility
Co-authored-by: Rossman360 <rmontsinger@gmail.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* grid align layout macro and keymaps
* physically arrange layout macro, phase 1
* physically arrange layout macro, phase 2
* replace KC_PAUSE with KC_PAUS
Makes the grid alignment nice. :)
* rename LAYOUT_65_ansi to LAYOUT_all
The included layout macro isn't actually correct for QMK's 65% ANSI community layout.
* add an actual LAYOUT_65_ansi
This is a semi-educated guess as to this macro; it may be wrong.
* error log cleanup: 40percentclub/25
40percentclub/25: Claims to support a community layout that does not exist: ortho_5x5
* error log cleanup: 40percentclub/4x4
☒ 40percentclub/4x4: Claims to support a community layout that does not exist: ortho_4x8
☒ 40percentclub/4x4: Claims to support a community layout that does not exist: ortho_4x16
* error log cleanup: 40percentclub/5x5
☒ 40percentclub/5x5: Claims to support a community layout that does not exist: ortho_5x5
* error log cleanup: 40percentclub/nori
☒ 40percentclub/nori: Claims to support a community layout that does not exist: ortho_4x8
* error log cleanup: barracuda
☒ barracuda: Claims to support a community layout that does not exist: ortho_3x11
* error log cleanup: bpiphany/frosty_flake
☒ keyboards/bpiphany/frosty_flake/frosty_flake.h: LAYOUT_tkl_ansi: Nested layout macro detected. Matrix data not available!
* error log cleanup: bpiphany/pegasushoof/2013
☒ keyboards/bpiphany/pegasushoof/2013/2013.h: LAYOUT_tkl_ansi: Nested layout macro detected. Matrix data not available!
* error cleanup: bpiphany/pegasushoof/2015
☒ keyboards/bpiphany/pegasushoof/2015/2015.h: LAYOUT_tkl_ansi: Nested layout macro detected. Matrix data not available!
☒ keyboards/bpiphany/pegasushoof/2015/2015.h: LAYOUT_tkl_iso: Nested layout macro detected. Matrix data not available!
* error log cleanup: 40percentclub
☒ 40percentclub/25: Claims to support a community layout that does not exist: ortho_5x10
☒ 40percentclub/5x5: Claims to support a community layout that does not exist: ortho_5x10
* error cleanup: converter/usb_usb
☒ keyboards/converter/usb_usb/usb_usb.h: LAYOUT_ansi: Nested layout macro detected. Matrix data not available!
☒ keyboards/converter/usb_usb/usb_usb.h: LAYOUT_iso: Nested layout macro detected. Matrix data not available!
☒ keyboards/converter/usb_usb/usb_usb.h: LAYOUT_jis: Nested layout macro detected. Matrix data not available!
☒ keyboards/converter/usb_usb/usb_usb.h: LAYOUT_ansi: Nested layout macro detected. Matrix data not available!
☒ keyboards/converter/usb_usb/usb_usb.h: LAYOUT_iso: Nested layout macro detected. Matrix data not available!
☒ keyboards/converter/usb_usb/usb_usb.h: LAYOUT_jis: Nested layout macro detected. Matrix data not available!
☒ keyboards/converter/usb_usb/usb_usb.h: LAYOUT_ansi: Nested layout macro detected. Matrix data not available!
☒ keyboards/converter/usb_usb/usb_usb.h: LAYOUT_iso: Nested layout macro detected. Matrix data not available!
☒ keyboards/converter/usb_usb/usb_usb.h: LAYOUT_jis: Nested layout macro detected. Matrix data not available!
* error cleanup: ergo42
☒ ergo42/rev1: Claims to support a community layout that does not exist: ortho_4x14
* error cleanup: handwired/412_64
☒ handwired/412_64: Claims to support a community layout that does not exist: ortho_4x16
* error log cleanup: handwired/tritium_numpad
☒ handwired/tritium_numpad: Claims to support a community layout that does not exist: nontra_6x4
* error log cleanup: handwired/xealous/rev1
☒ handwired/xealous/rev1: Claims to support a community layout that does not exist: split60
* error log cleanup: kbdfans/kbd67/rev2
⚠ kbdfans/kbd67/rev2: info.json uses alias name LAYOUT_65_ansi_blocker_splitbs instead of LAYOUT_65_ansi_blocker_split_bs
* error cleanup: keebio/nyquist
☒ keyboards/keebio/nyquist/nyquist.h: LAYOUT_ortho_4x12: Nested layout macro detected. Matrix data not available!
☒ keyboards/keebio/nyquist/nyquist.h: LAYOUT_ortho_4x12: Nested layout macro detected. Matrix data not available!
☒ keyboards/keebio/nyquist/nyquist.h: LAYOUT_ortho_4x12: Nested layout macro detected. Matrix data not available!
* error cleanup: kindakeyboards/conone65
☒ kindakeyboards/conone65: Claims to support a community layout that does not exist: 65_iso_split_bs
* error cleanup: latinpadble
☒ latinpadble: Claims to support a community layout that does not exist: pad
* error cleanup: masterworks/classy_tkl/rev_a
☒ masterworks/classy_tkl/rev_a: Claims to support a community layout that does not exist: tkl_ansi_wkl
* error cleanup: meira
⚠ meira/featherble: info.json uses alias name LAYOUT_ortho_4x12 instead of LAYOUT
⚠ meira/promicro: info.json uses alias name LAYOUT_ortho_4x12 instead of LAYOUT
* error cleanup: nopunin10did/jabberwocky
⚠ nopunin10did/jabberwocky: MANUFACTURER in config.h is overwriting manufacturer in info.json
* error cleanup: ok60
☒ ok60: Claims to support a community layout that does not exist: 60_ansi_split_bksp_rshift
* error cleanup: ok60
☒ ok60: Claims to support a community layout that does not exist: 60_ansi_split_bksp_rshift
* error cleanup: planck
☒ keyboards/planck/ez/ez.h: LAYOUT_ortho_4x12: Nested layout macro detected. Matrix data not available!
☒ keyboards/planck/ez/ez.h: LAYOUT_ortho_4x12: Nested layout macro detected. Matrix data not available!
⚠ planck/thk: DEBOUNCE in config.h is overwriting debounce in info.json
⚠ planck/thk: DEVICE_VER in config.h is overwriting usb.device_ver in info.json
⚠ planck/thk: DIODE_DIRECTION in config.h is overwriting diode_direction in info.json
⚠ planck/thk: MANUFACTURER in config.h is overwriting manufacturer in info.json
⚠ planck/thk: PRODUCT_ID in config.h is overwriting usb.pid in info.json
⚠ planck/thk: VENDOR_ID in config.h is overwriting usb.vid in info.json
⚠ planck/thk: QMK_ESC_OUTPUT in config.h is overwriting qmk_lufa_bootloader.esc_output in info.json
⚠ planck/thk: QMK_ESC_INPUT in config.h is overwriting qmk_lufa_bootloader.esc_input in info.json
⚠ planck/thk: QMK_LED in config.h is overwriting qmk_lufa_bootloader.led in info.json
⚠ planck/thk: QMK_SPEAKER in config.h is overwriting qmk_lufa_bootloader.speaker in info.json
⚠ planck/thk: Matrix pins are specified in both info.json and config.h, the config.h values win.
⚠ planck/thk: LAYOUTS in rules.mk is overwriting community_layouts in info.json
⚠ planck/thk: Feature mousekey is specified in both info.json and rules.mk, the rules.mk value wins.
⚠ planck/thk: Feature extrakey is specified in both info.json and rules.mk, the rules.mk value wins.
⚠ planck/thk: Feature console is specified in both info.json and rules.mk, the rules.mk value wins.
⚠ planck/thk: Feature command is specified in both info.json and rules.mk, the rules.mk value wins.
⚠ planck/thk: Feature sleep_led is specified in both info.json and rules.mk, the rules.mk value wins.
⚠ planck/thk: Feature nkro is specified in both info.json and rules.mk, the rules.mk value wins.
⚠ planck/thk: Feature backlight is specified in both info.json and rules.mk, the rules.mk value wins.
⚠ planck/thk: Feature rgblight is specified in both info.json and rules.mk, the rules.mk value wins.
⚠ planck/thk: Feature bluetooth is specified in both info.json and rules.mk, the rules.mk value wins.
⚠ planck/thk: Feature audio is specified in both info.json and rules.mk, the rules.mk value wins.
⚠ planck/thk: Feature encoder is specified in both info.json and rules.mk, the rules.mk value wins.
⚠ planck/thk: Feature dip_switch is specified in both info.json and rules.mk, the rules.mk value wins.
⚠ planck/thk: Feature bootmagic_lite is specified in both info.json and rules.mk, the rules.mk value wins.
* error cleanup: primekb/prime_m
☒ primekb/prime_m: Claims to support a community layout that does not exist: ortho_5x6
* error cleanup: rgbkb/sol/rev2
⚠ rgbkb/sol/rev2: RGBLED_NUM->rgblight.led_count: invalid literal for int() with base 10: '(BACKLIGHT_LEDS + FULLHAND_LEDS)'
* error log cleanup: shk9
☒ shk9: Claims to support a community layout that does not exist: ortho_3x3
* error log cleanup: sowbug
⚠ sowbug/68keys: RGBLED_NUM->rgblight.led_count: invalid literal for int() with base 10: 'DRIVER_LED_TOTAL'
⚠ sowbug/ansi_tkl: RGBLED_NUM->rgblight.led_count: invalid literal for int() with base 10: '(DRIVER_LED_TOTAL)'
* error log cleanup: torn
☒ torn: Claims to support a community layout that does not exist: split_3x6_4
* error cleanup: ymdk/np24/u4rgb6
☒ ymdk/np24/u4rgb6: Claims to support a community layout that does not exist: ortho_4x6
* error cleanup: masterworks/classy_tkl/rev_a
☒ masterworks/classy_tkl/rev_a: Claims to support a community layout that does not exist: tkl_iso_wkl
* physically arrange layout macro
Arranges the layout macro and keycodes to resemble the assembled keyboard.
* correct info.json data
Corrects the key sequence and positioning in info.json.
* correct layout data
* use LAYOUT as layout macro name
The defined LAYOUT_daisy is functional, but Configurator expects LAYOUT through the info.json file. As the board only supports one layout according to the open-source PCB files, use LAYOUT as the defined macro per QMK guidelines.
* add layout macro alias
* fix some broken info.json files
* optimize our jsonschema using refs
* fix formatting after vscode broke it
* make flake8 happy
* cleanup
* make our schema validation more compact and flexible
* grid-align layout macro and keymaps
* physically align layout macro and keycodes
Arrange the layout macro and keycodes to resemble the assembled keyboard.
* update info.json data
Updates the info.json data to be correct to the new layout macro.
The Teensy 3.6 comes with 4096 bytes of EEPROM.
This is commit 1 of 2 to make the EEPROM work.
The next commit changes the core code to wire up the EEPROM.
* Add SquishyTKL
* Add SquishyTKL-FRL
* Adjust readme.md and info.json
* Add JIS support for SquishyTKL
* Fix JIS layout macro
* Fix via layout and keymap
* Migrate SquishyTKL to STM32duino bootloader
* Make chibios conf files generic
* Change TKL via keymap to match number of layers
* Apply chibios changes to FRL as well
* Adjust README regarding flashing with dfu-util
* Add license and header guard
* Added custom Keymap
* Added Images to README
* Added Layer 1 Keys for RGB control
* Added GPL2+ License to keymap.c
* Removed extra json files and added a few lines to README
It so happens that when releasing the control key prior to the main key (C-h, C-i, C-n,
...), the substituted keycode was continuously sent in a loop after that (even when
releasing said key). The workaround so far was to type any other key to stop the loop.
This commit fixes such behavior by resetting the substitution keycode sent when the ctrl
released situation conditional is detected (and that the substitution keycode was on).
* add keyboard new macro pad "Kuro"
* change main readme.md
* remove not used code from default/keymap.c
* Remove unnecessary code
* Supports info.json
* removed back slash and not used functions.
* update at product link. add japanese messages.
* Merge All
* [Shiro]Add MacKeymap
* Change key code. Numpad→Numkey
* Made OLED splash screen optional to reduce memory and fixed OLED i2c execution time saving
* moved OLED address updates into their respective conditional checks
* Avoid zero or overflow from user's rgb_matrix_config.speed
* Avoid zero tick for reactive splash.
* Avoid zero time for animation runner.
Co-authored-by: filterpaper <filterpaper@localhost>
* adding revision A
* Update keyboards/4pplet/eagle_viper_rep/rev_a/rev_a.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update keyboards/4pplet/eagle_viper_rep/rev_a/rev_a.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update keyboards/4pplet/eagle_viper_rep/rev_a/rev_a.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update keyboards/4pplet/eagle_viper_rep/rev_a/rev_a.h
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update keyboards/4pplet/eagle_viper_rep/rev_a/rev_a.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update readme.md
Adding instruction on how to enter bootloader
* adding instruction on how to enter bootloader (DFU)
adding instruction on how to enter bootloader (DFU)
* updated description
* Update keyboards/4pplet/eagle_viper_rep/rev_a/halconf.h
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Update keyboards/4pplet/eagle_viper_rep/rev_a/rev_a.c
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Update keyboards/4pplet/eagle_viper_rep/rev_a/config.h
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Update keyboards/4pplet/eagle_viper_rep/rev_a/chconf.h
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Update keyboards/4pplet/eagle_viper_rep/rev_a/chconf.h
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Update keyboards/4pplet/eagle_viper_rep/keymaps/default/keymap.c
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Restoring palSetLineMode for working underglow
I was experiencing the same issue as this: https://github.com/qmk/qmk_firmware/issues/12655#issuecomment-844104659
sigprof helped me resolve this issue.
* Update rev_a.c
removing palSetLineMode again, works great after rebase. Thanks!
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Nick Brassel <nick@tzarc.org>
The rev3 boards use RGBLIGHT_ENABLE now instead of BACKLIGHT_ENABLE.
This resolves the issue of flashing and losing functionality with the default keymap.
Added missing closing comment bit */
This seems to cause the QMK configurator to break when clicking the compile button:
Compiling: keyboards/handwired/split89/split89.c In file included from [K:
ent]
/* COL2ROW, ROW2COL */
[K
cc1: all warnings being treated as errors
|
|
|
make: *** ine/keyboards/handwired/split89/split89.o] Error 1
* Extensible split data sync capability through transactions.
- Split common transport has been split up between the transport layer
and data layer.
- Split "transactions" model used, with convergence between I2C and
serial data definitions.
- Slave matrix "generation count" is used to determine if the full slave
matrix needs to be retrieved.
- Encoders get the same "generation count" treatment.
- All other blocks of data are synchronised when a change is detected.
- All transmissions have a globally-configurable deadline before a
transmission is forced (`FORCED_SYNC_THROTTLE_MS`, default 100ms).
- Added atomicity for all core-synced data, preventing partial updates
- Added retries to AVR i2c_master's i2c_start, to minimise the number of
failed transactions when interrupts are disabled on the slave due to
atomicity checks.
- Some keyboards have had slight modifications made in order to ensure
that they still build due to firmware size restrictions.
* Fixup LED_MATRIX compile.
* Parameterise ERROR_DISCONNECT_COUNT.
* Intended usage is data validation in split transport code.
* Default space efficient algorithm.
* Opt-in fast table based algorithmn with #define CRC8_USE_TABLE switch.
* Define switches for size and speed optimized versions, the default is size
optimized by using uint_least8_t as datatype for calculations.
* #define CRC8_OPTIMIZE_SPEED uses uint_fast8_t as datatype for
calculations, this only affects 32-bit Archs like ARM and RISC-V.
* Placeholder crc_init() function for hardware backed crc calculation,
not implemented yet.
This binary keymap for ANAVI Macro Pad 2 helps with 0 and 1:
left key: 0
right key: 1
Combo press both keys to control the backlit.
Suggested-by: Chris <christopher.walker@crowdsupply.com>
Signed-off-by: Leon Anavi <leon@anavi.org>
* Top level heading for common config
Prior to this, the some of the common config looks like a detail of the APA102 driver
* Change heading to Common Config (RGB Matrix)
This commit makes atmel-dfu and chibios-dfu bootloaders retry to detect the bootloader
every 0,5 seconds (now configurable via the BOOTLOADER_RETRY_TIME makefile variable),
and a period is printed after every try. This is a much more pleasant behaviour than
the 5s retry timeout.
* Set saturation limit to jellybean_raindrops_anim.h
* Use faster bit-shift maths and qadd8
* Remove extra parenthesis
* Single bitmask operation is sufficient.
Co-authored-by: filterpaper <filterpaper@localhost>
This keymap for ANAVI Macro Pad 2 contains a couple of Skype
shortcuts for MS Windows and GNU/Linux distributions:
- Ctrl+M: Mute/unmute microphone
- Ctrl+Shift+K: Start/stop camera
Signed-off-by: Leon Anavi <leon@anavi.org>
* Enable SPI1 for GMMK pro
* Setup initial boilerplate for new LED driver
* RGB matrix minimally functional
* Map full LED matrix
* Return keymap to default
* Fix printscreen LED mapping
* Reduce max brightness
* Default values for AW20216
* Add documentation for AW20216
* Disable console and warnings
* Run cformat
* Update drivers/awinic/aw20216.h
Co-authored-by: Drashna Jaelre <drashna@live.com>
* make aw struct match issi struct
Co-authored-by: Drashna Jaelre <drashna@live.com>
* add led location defines
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Use led pin definitions in keyboard.c
* Add driver indices to led map
* Fix elif typo
* Run cformat
* Update docs
* Fix typo in docs
* Document global brightness limits
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Add fast_timer_t that is 16-bit or 32-bit based on architecture
A 16-bit timer will overflow sooner but be faster to compare on AVR.
* Avoid 8-bit timer overflows in debounce algorithms
Count down remaining elapsed time instead of trying to do 8-bit timer
comparisons.
Add a "none" implementation that is automatically used if DEBOUNCE is
0 otherwise it will break the _pk/_pr count down.
* Avoid unnecessary polling of the entire matrix in sym_eager_pk
The matrix only needs to be updated when a debounce timer expires.
* Avoid unnecessary polling of the entire matrix in sym_eager_pr
The matrix only needs to be updated when a debounce timer expires.
The use of the "needed_update" variable is trying to do what
"matrix_need_update" was added to fix but didn't work because it only
applied when all keys finished debouncing.
* Fix sym_defer_g timing inconsistency compared to other debounce algorithms
DEBOUNCE=5 should process the key after 5ms, not 6ms
* Add debounce tests
* Use memcmp to determine if matrix changed.
* Firmware size issues.
* Add documentation for the lack of need of MATRIX_ROW_PINS/MATRIX_COL_PINS, when overriding low-level matrix functions.
* add readPort() and some API to 'tmk_core/common/*/gpio.h'
The following macros have been added to gpio.h.
* readPort(port)
* setPortBitInput(port, bit)
* setPortBitInputHigh(port, bit)
* setPortBitOutput(port, bit)
* writePortBitLow(port, bit)
* writePortBitHigh(port, bit)
* add data type 'port_data_t' into gpio.h
* rename qmk_pin to pin
Debian bullseye (testing at the moment, but seems close to release) has
avr-libc 1:2.0.0+Atmel3.6.2-1.1 with some changes taken from the
Atmel-distributed toolchain. In particular, the <avr/io.h> header for
ATmega32A (avr/iom32a.h) now defines the FLASHEND constant as `0x7FFFU`,
and that `U` suffix breaks the firmware size check code, because the
shell arithmetic expansion that is used to calculate `MAX_SIZE` does not
support those C-specific suffixes.
As a workaround, add `-D__ASSEMBLER__` to the C preprocessor invocation
that is used to expand those macros; in this case avr/iom32a.h defines
`FLASHEND` without the `U` suffix, and everything works as it did before
with older avr-libc versions.
The exact same code is present in two places; they are both changed,
even though the code in `tmk_core/avr.mk` is actually never used for
ATmega32A (and the header for ATmega32U4 does not add that `U` suffix to
`FLASHEND` for some reason).
* Update ChibiOS, ChibiOS-Contrib.
* Add instructions.
* Wrong remote name
* Explicit version tag.
* Add link to procedure on the breaking changes page.
I noticed this discrepancy (last row of the matrix treated differently than the
others) when optimizing the input latency of my keyboard controller, see also
https://michael.stapelberg.ch/posts/2021-05-08-keyboard-input-latency-qmk-kinesis/
Before this commit, when tuning the delays I noticed ghost key presses when
pressing the F2 key, which is on the last row of the keyboard matrix: the
dead_grave key, which is on the first row of the keyboard matrix, would be
incorrectly detected as pressed.
After this commit, all keyboard matrix rows are interpreted correctly.
I suspect that my setup is more susceptible to this nuance than others because I
use GPIO_INPUT_PIN_DELAY=0 and hence don’t have another delay that might mask
the problem.
* Implement function rgblight_blink_layer_repeat to allow repeated blinking of one layer at a time
* Update doc
* Rework rgblight blinking according to requested change
* optimize storage
This converts the array that the Swap Hands feature uses to use PROGMEM,
and to read from that array, as such. Since this array never changes at
runtime, there is no reason to keep it in memory. Especially for AVR
boards, as memory is a precious resource.
* stash poc
* stash
* tidy up implementation
* Tidy up slightly for review
* Tidy up slightly for review
* Bodge environment to make tests pass
* Refactor away from asyncio due to windows issues
* Filter devices
* align vid/pid printing
* Add hidapi to the installers
* start preparing for multiple hid_listeners
* udev rules for hid_listen
* refactor to move closer to end state
* very basic implementation of the threaded model
* refactor how vid/pid/index are supplied and parsed
* windows improvements
* read the report directly when usage page isn't available
* add per-device colors, the choice to show names or numbers, and refactor
* add timestamps
* Add support for showing bootloaders
* tweak the color for bootloaders
* Align bootloader disconnect with connect color
* add support for showing all bootloaders
* fix the pyusb check
* tweaks
* fix exception
* hide a stack trace behind -v
* add --no-bootloaders option
* add documentation for qmk console
* Apply suggestions from code review
Co-authored-by: Ryan <fauxpark@gmail.com>
* pyformat
* clean up and flesh out KNOWN_BOOTLOADERS
Co-authored-by: zvecr <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add support for MCU = STM32F446
* Update platforms/chibios/GENERIC_STM32_F446XE/configs/config.h
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Restore mcuconf.h to the one used by RT-STM32F446RE-NUCLEO64
* stm32f446: update mcuconf.h and board.h for 16MHz operation, with USB enabled, and other peripherals disabled.
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Fix default ADC_RESOLUTION for ADCv3 (and ADCv4)
Recent ChibiOS update removed ADC_CFGR1_RES_10BIT from the ADCv3 headers
(that macro should not have been there, because ADCv3 has CFGR instead of
CFGR1). Fix the default value for ADC_RESOLUTION to use ADC_CFGR_RES_10BITS
if it is defined (that name is used for ADCv3 and ADCv4).
* Update ADC docs to match the actually used resolution
ADC driver for ChibiOS actually uses the 10-bit resolution by default
(probably to match AVR); fix the documentation accordingly. Also add
both ADC_CFGR_RES_10BITS and ADC_CFGR1_RES_10BIT constants (these names
differ according to the ADC implementation in the particular MCU).
* Fix pinToMux() for B12 and B13 on STM32F3xx
Testing on STM32F303CCT6 revealed that the ADC mux values for B12 and
B13 pins were wrong.
* Add support for all possible analog pins on STM32F1xx
Added ADC mux values for pins A0...A7, B0, B1, C0...C5 on STM32F1xx
(they are the same at least for STM32F103x8 and larger F103 devices, and
also F102, F105, F107 families). Actually tested on STM32F103C8T6
(therefore pins C0...C5 were not tested).
Pins F6...F10, which are present on STM32F103x[C-G] in 144-pin packages,
cannot be supported at the moment, because those pins are connected only
to ADC3, but the ChibiOS ADC driver for STM32F1xx supports only ADC1.
* Add support for all possible analog pins on STM32F4xx
Added ADC mux values for pins A0...A7, B0, B1, C0...C5 and optionally
F3...F10 (if STM32_ADC_USE_ADC3 is enabled). These mux values are
apparently the same for all F4xx devices, except some smaller devices may
not have ADC3.
Actually tested on STM32F401CCU6, STM32F401CEU6, STM32F411CEU6 (using
various WeAct “Blackpill” boards); only pins A0...A7, B0, B1 were tested.
Pins F3...F10 are inside `#if STM32_ADC_USE_ADC3` because some devices
which don't have ADC3 also don't have the GPIOF port, therefore the code
which refers to Fx pins does not compile.
* Fix STM32F3xx ADC mux table in documentation
The ADC driver documentation had some errors in the mux table for STM32F3xx.
Fix this table to match the datasheet and the actual code (mux settings for
B12 and B13 were also tested on a real STM32F303CCT6 chip).
* Add STM32F1xx ADC pins to the documentation
* Add STM32F4xx ADC pins to the documentation
This moves the config_common.h into the files that include ../config.h,
so that the kint36/config.h does not include it (which would cause
compilation errors).
* In split keyboards fix connection issue when slave and OLED are connected via I2C. Fix#9335
* Revert "In split keyboards fix connection issue when slave and OLED are connected via I2C. Fix#9335"
This reverts commit 3ee639e1f3.
* In split keyboards fix connection issue when slave and OLED are connected via I2C. Fix#9335
* Update drivers/oled/oled_driver.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: osenchenko <osechenko@chiefmate.io>
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Durgod keyboard refactor in preparation for adding additional durgod keyboards
* Moving Durgod board configuration into a common location
* Reformatting layout macro whitespace
* Moving TGUI key functionality to the keyboard level
* Replacing default keymap.c with keymap.json
* Changing default and default_toggle_mac_windows keymaps to LAYOUT_all
* Increasing EEPROM size to support more VIA layers
* Fixing media keys; KC_MRWD/KC_MFFD => KC_MPRV/KC_NXT
* Move ISO Enter key to the correct row in Durgod K320
* Minor whitespace and readme cleanup for K320
* Changing durgod/k320 debounce back to default
* Simplifying DURGOD_STM32_F070's chconf.h
Co-authored-by: Simon Arlott <sa.me.uk>
Co-authored-by: Tyler Tidman <tyler.tidman@draak.ca>
Because the matrix scanning is slower for splits, in general,
the frequent updating of the OLEDs can slow down the matrix scanning.
To help prevent that, set the update interval for the OLEDs to not
update as frequently.
* Initial refactor of ARM SLEEP_LED to enable more platforms
* fix build issues
* Disable SLEEP_LED for boards with no caps lock code
* Enable GPT14 for boards with caps lock code and SLEEP_LED enabled
* Enable GPT for boards with caps lock code and SLEEP_LED enabled
QMK strives to be an inclusive, tolerant, and welcoming community. We encourage participation from anyone regardless of age, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, political belief, race, religion, or sexual identity and orientation.
> “A gentle word turns away wrath, but a harsh word stirs up anger."
Our users, contributors, and collaborators are expected to treat each other with kindness and respect, to assume good intentions, and to gently correct, where possible, rather than react with escalation. While our goal is to be as accurate as possible, kindness and understanding are more valuable than correctness. Some examples of behavior we will not tolerate include, but is not limited to:
* The use of sexualized language or imagery
* Unwelcome advances, sexual or otherwise
* Deliberate intimidation, stalking, or following
* Insults or derogatory comments, or personal or political attacks
* Publishing others’ private information without explicit permission
* Sustained disruption of talks or other events
* Other conduct which could reasonably be considered inappropriate in a professional setting
* Advocating for, or encouraging, any of the above behaviour
# Reporting
If someone is violating this Code of Conduct, please email hello@qmk.fm or reach out to one of the Collaborators to bring it to our attention. All complaints will be reviewed and investigated.
QMK will seek to use the least punitive means available to resolve an issue. If the circumstances require asking an offender to leave, we will do that.
Reports will be taken and kept in strict confidence. You will not be required to confront an offender directly.
* Hardware Availability: *Links to where you can find this hardware*
Make example for this keyboard (after setting up your build environment):
make %KEYBOARD%:default
Flashing example for this keyboard:
make %KEYBOARD%:default:flash
See the [build environment setup](https://docs.qmk.fm/#/getting_started_build_tools) and the [make instructions](https://docs.qmk.fm/#/getting_started_make_guide) for more information. Brand new to QMK? Start with our [Complete Newbs Guide](https://docs.qmk.fm/#/newbs).
## Bootloader
Enter the bootloader in 3 ways:
* **Bootmagic reset**: Hold down the key at (0,0) in the matrix (usually the top left key or Escape) and plug in the keyboard
* **Physical reset button**: Briefly press the button on the back of the PCB - some may have pads you must short instead
* **Keycode in layout**: Press the key mapped to `RESET` if it is available
* Hardware Availability: *Links to where you can find this hardware*
Make example for this keyboard (after setting up your build environment):
make %KEYBOARD%:default
Flashing example for this keyboard ([after setting up the bootloadHID flashing environment](https://docs.qmk.fm/#/flashing_bootloadhid))
make %KEYBOARD%:default:flash
See the [build environment setup](https://docs.qmk.fm/#/getting_started_build_tools) and the [make instructions](https://docs.qmk.fm/#/getting_started_make_guide) for more information. Brand new to QMK? Start with our [Complete Newbs Guide](https://docs.qmk.fm/#/newbs).
## Bootloader
Enter the bootloader in 3 ways:
* **Bootmagic reset**: Hold down the key at (0,0) in the matrix (usually the top left key or Escape) and plug in the keyboard
* **BootloadHID reset**: Hold down the key connected to the `A0` and `B0` pins on the MCU if it is known (often top left or bottom left) and plug in the keyboard
* **Physical reset button**: Briefly press the button on the back of the PCB - some may have pads you must short instead
* **Keycode in layout**: Press the key mapped to `RESET` if it is available
Combo processing has been reordered with respect to keypress handling, allowing for much better compatibility with mod taps.
It is also now possible to define combos that have keys overlapping with other combos, triggering only one. For example, a combo of `A`, `B` can coexist with a longer combo of `A`, `B`, `C` -- previous functionality would trigger both combos if all three keys were pressed.
QMK now has a new feature: [key overrides](https://docs.qmk.fm/#/feature_key_overrides). This feature allows for overriding the output of key combinations involving modifiers. As an example, pressing <kbd>Shift+2</kbd> normally results in an <kbd>@</kbd> on US-ANSI keyboard layouts -- the new key overrides allow for adding similar functionality, but for any <kbd>modifier + key</kbd> press.
To illustrate, it's now possible to use the key overrides feature to translate <kbd>Shift + Backspace</kbd> into <kbd>Delete</kbd> -- an often-requested example of where this functionality comes in handy.
There's far more to describe that what lives in this changelog, so head over to the [key overrides documentation](https://docs.qmk.fm/#/feature_key_overrides) for more examples and info.
### Digitizer support ([#12851](https://github.com/qmk/qmk_firmware/pull/12851))
QMK gained the ability to pretend to be a digitizer device -- much like a tablet device. A mouse uses delta-coordinates -- move up, move right -- but a digitizer works with absolute coordinates -- top left, bottom right.
## Changes Requiring User Action :id=changes-requiring-user-action
### Bootmagic Full Removal ([#13846](https://github.com/qmk/qmk_firmware/pull/13846)) :id=bootmagic-full-removal
As noted during last breaking changes cycle, QMK has decided to deprecate the full Bootmagic feature and leave Bootmagic Lite as the only remaining option.
This pull request changes the behavior of `BOOTMAGIC_ENABLE` such that specifying `full` results in an error, allowing only `no`, `yes`, or `lite`.
Currently `lite` is the equivalent of `yes` in `rules.mk`. Next cycle the use of the `lite` keyword will be prevented in favour of `yes` -- any new submissions should now be using `yes` or `no` to minimise disruption.
#### Bootmagic Full Deprecation Schedule
This is the current roadmap for the behavior of `BOOTMAGIC_ENABLE`:
- (done) From 2021 May 29, setting `BOOTMAGIC_ENABLE = yes` will enable Bootmagic Lite instead of full Bootmagic.
- (now) From 2021 Aug 28, `BOOTMAGIC_ENABLE` must be either `yes`, `lite`, or `no`– setting `BOOTMAGIC_ENABLE = full` will cause compilation to fail.
- (next) From 2021 Nov 27, `BOOTMAGIC_ENABLE` must be either `yes` or `no`– setting `BOOTMAGIC_ENABLE = lite` will cause compilation to fail.
### DIP switch callbacks are now boolean ([#13399](https://github.com/qmk/qmk_firmware/pull/13399)) :id=dip-switch-boolean
To match the encoder change last breaking changes cycle, DIP switch callbacks now return `bool`, too.
returntrue;// Returning true allows keyboard code to execute, false will tell the keyboard code "I've already handled it".
}
```
## Notable core changes :id=notable-core
### Split transport improvements :id=split-transport-improvements
Split keyboards gained a significant amount of improvements during this breaking changes cycle, specifically:
* Extensible split data sync ([#11930](https://github.com/qmk/qmk_firmware/pull/11930)) -- rewritten data sharing between sides, allowing for data transfer only when required, as well as enabling keyboards and keymaps to define their own shared data.
* Full-duplex ARM USART split ([#13081](https://github.com/qmk/qmk_firmware/pull/13081)) -- adds to the previous half-duplex driver and now allows for full-duplex support on ARM.
* Make solo half of split keyboards (more) usable. ([#13523](https://github.com/qmk/qmk_firmware/pull/13523)) -- allows the slave to be disconnected, enabling one-handed use.
* Switch split_common to CRC subsystem ([#13418](https://github.com/qmk/qmk_firmware/pull/13418))
!> If you're updating your split keyboard, you will need to flash both sides of the split with the your firmware.
### Teensy 4.x support ([#13056](https://github.com/qmk/qmk_firmware/pull/13056), [#13076](https://github.com/qmk/qmk_firmware/pull/13076), [#13077](https://github.com/qmk/qmk_firmware/pull/13077)) :id=teensy-4-x-support
Updated ChibiOS and ChibiOS-Contrib, which brought in support for Teensy 4.x dev boards, running NXP i.MX1062.
### Data Driven Improvements ([#13366](https://github.com/qmk/qmk_firmware/pull/13366))
QMK's pursuit of data-driven keyboards has progressed, allowing substantially more configurable options to be specified in `info.json`.
#### Tags
Tags will let you categorize your keyboard, and will be used in the future to allow browsing and sorting through keyboards in QMK. Tags are free-form text identifiers that identify attributes about your keyboard. To add tags you simply add a `tags` key to your `info.json`:
"tags": ["tkl", "backlight", "encoder"]
#### Dot Notation
With this release we are moving towards using JSON dot notation in more places. For example, when using `qmk info -f text`:
```
$ qmk info -f text -kb clueboard/card
bootloader: atmel-dfu
debounce: 20
diode_direction: ROW2COL
features.audio: True
features.backlight: True
features.bluetooth: False
features.bootmagic: False
features.command: True
features.console: True
features.extrakey: True
features.lto: True
features.midi: False
features.mousekey: True
features.nkro: False
features.rgblight: True
features.unicode: False
height: 8
keyboard_folder: clueboard/card
keyboard_name: Cluecard
layout_aliases.LAYOUT: LAYOUT_all
layouts: LAYOUT_all
maintainer: skullydazed
manufacturer: Clueboard
matrix_pins.cols: F1, F6, F7
matrix_pins.rows: B4, F0, F4, F5
platform: unknown
processor: atmega32u4
processor_type: avr
protocol: LUFA
rgblight.brightness_steps: 17
rgblight.hue_steps: 10
rgblight.led_count: 4
rgblight.pin: E6
rgblight.saturation_steps: 17
split.transport.protocol: serial
usb.device_ver: 0x0001
usb.pid: 0x2330
usb.vid: 0xC1ED
width: 10
```
#### New configuration keys
We've added dozens of new keys to `info.json` so that you can configure more than ever without writing a single line of code. A quick overview of the new items you can configure:
### Codebase restructure and cleanup :id=codebase-restructure
QMK was originally based on TMK, and has grown in size considerably since its first inception. To keep moving things forward, restructure of some of the core areas of the code is needed to support new concepts and new hardware, and progress is happening along those lines:
* Move RGBLight code into its own folder ([#13312](https://github.com/qmk/qmk_firmware/pull/13312))
* Migrate platform independent code from tmk_core -> quantum ([#13673](https://github.com/qmk/qmk_firmware/pull/13673))
ChibiOS and ChibiOS-Contrib need to be updated in tandem -- the latter has a branch tied to the ChibiOS version in use and should not be mixed with different versions.
## Getting ChibiOS
*`svn` Initialisation:
* Only needed to be done once
* You might need to separately install `git-svn` package in your OS's package manager
It is possible to speed up compilation by adding the `-j`/`--parallel` flag.
```
qmk compile -j <num_jobs> -kb <keyboard_name>
```
The `num_jobs` argument determines the maximum number of jobs that can be used. Setting it to zero will enable parallel compilation without limiting the maximum number of jobs.
```
qmk compile -j 0 -kb <keyboard_name>
```
## `qmk flash`
This command is similar to `qmk compile`, but can also target a bootloader. The bootloader is optional, and is set to `:flash` by default. To specify a different bootloader, use `-bl <bootloader>`. Visit the [Flashing Firmware](flashing.md) guide for more details of the available bootloaders.
@@ -82,13 +93,13 @@ This command is directory aware. It will automatically fill in KEYBOARD and/or K
This command lets you connect to keyboard consoles to get debugging messages. It only works if your keyboard firmware has been compiled with `CONSOLE_ENABLED=yes`.
This command lets you connect to keyboard consoles to get debugging messages. It only works if your keyboard firmware has been compiled with `CONSOLE_ENABLE=yes`.
This command creates a new keyboard based on available templates.
This command will prompt for input to guide you though the generation process.
Any arguments that are not provided will prompt for input. If `-u` is not passed and `user.name` is set in .gitconfig, it will be used as the default username in the prompt.
This command formats text files to have proper line endings.
Every text file in the repository needs to have Unix (LF) line ending.
If you are working on **Windows**, you must ensure that line endings are corrected in order to get your PRs merged.
```
qmk format-text
```
## `qmk format-c`
This command formats C code using clang-format.
@@ -325,35 +347,36 @@ Run it with `-a` to format all core code, or pass filenames on the command line
**Usage for specified files**:
```
qmk cformat [file1] [file2] [...] [fileN]
qmk format-c [file1] [file2] [...] [fileN]
```
**Usage for all core files**:
```
qmk cformat -a
qmk format-c -a
```
**Usage for only changed files against origin/master**:
```
qmk cformat
qmk format-c
```
**Usage for only changed files against branch_name**:
```
qmk cformat -b branch_name
qmk format-c -b branch_name
```
## `qmk docs`
This command starts a local HTTP server which you can use for browsing or improving the docs. Default port is 8936.
Use the `-b`/`--browser` flag to automatically open the local webserver in your default browser.
**Usage**:
```
qmk docs [-p PORT]
qmk docs [-b] [-p PORT]
```
## `qmk generate-docs`
@@ -368,7 +391,7 @@ qmk generate-docs
## `qmk generate-rgb-breathe-table`
This command generates a lookup table (LUT) header file for the [RGB Lighting](feature_rgblight.md) feature's breathing animation. Place this file in your keyboard or keymap directory as `rgblight_breathe_table.h` to override the default LUT in `quantum/`.
This command generates a lookup table (LUT) header file for the [RGB Lighting](feature_rgblight.md) feature's breathing animation. Place this file in your keyboard or keymap directory as `rgblight_breathe_table.h` to override the default LUT in `quantum/rgblight/`.
@@ -51,8 +51,10 @@ This is a C header file that is one of the first things included, and will persi
* the number of columns in your keyboard's matrix
*`#define MATRIX_ROW_PINS { D0, D5, B5, B6 }`
* pins of the rows, from top to bottom
* may be omitted by the keyboard designer if matrix reads are handled in an alternate manner. See [low-level matrix overrides](custom_quantum_functions.md?id=low-level-matrix-overrides) for more information.
* may be omitted by the keyboard designer if matrix reads are handled in an alternate manner. See [low-level matrix overrides](custom_quantum_functions.md?id=low-level-matrix-overrides) for more information.
*`#define MATRIX_IO_DELAY 30`
* the delay in microseconds when between changing matrix pin state and reading values
*`#define UNUSED_PINS { D1, D2, D3, B1, B2, B3 }`
@@ -186,13 +188,27 @@ If you define these options you will enable the associated feature, which may in
few ms of delay from this. But if you're doing chording on something with 3-4ms
scan times? You probably want this.
*`#define COMBO_COUNT 2`
* Set this to the number of combos that you're using in the [Combo](feature_combo.md) feature.
* Set this to the number of combos that you're using in the [Combo](feature_combo.md) feature. Or leave it undefined and programmatically set the count.
*`#define COMBO_TERM 200`
* how long for the Combo keys to be detected. Defaults to `TAPPING_TERM` if not defined.
*`#define COMBO_MUST_HOLD_MODS`
* Flag for enabling extending timeout on Combos containing modifers
*`#define COMBO_MOD_TERM 200`
* Allows for extending COMBO_TERM for mod keys while mid-combo.
*`#define COMBO_MUST_HOLD_PER_COMBO`
* Flag to enable per-combo COMBO_TERM extension and `get_combo_must_hold()` function
*`#define COMBO_TERM_PER_COMBO`
* Flag to enable per-combo COMBO_TERM extension and `get_combo_term()` function
*`#define COMBO_STRICT_TIMER`
* Only start the combo timer on the first key press instead of on all key presses.
*`#define COMBO_NO_TIMER`
* Disable the combo timer completely for relaxed combos.
*`#define TAP_CODE_DELAY 100`
* Sets the delay between `register_code` and `unregister_code`, if you're having issues with it registering properly (common on VUSB boards). The value is in milliseconds.
*`#define TAP_HOLD_CAPS_DELAY 80`
* Sets the delay for Tap Hold keys (`LT`, `MT`) when using `KC_CAPSLOCK` keycode, as this has some special handling on MacOS. The value is in milliseconds, and defaults to 80 ms if not defined. For macOS, you may want to set this to 200 or higher.
*`#define KEY_OVERRIDE_REPEAT_DELAY 500`
* Sets the key repeat interval for [key overrides](feature_key_overrides.md).
## RGB Light Configuration
@@ -272,7 +288,7 @@ There are a few different ways to set handedness for split keyboards (listed in
### Other Options
*`#define USE_I2C`
* For using I2C instead of Serial (defaults to serial)
* For using I2C instead of Serial (default is serial; serial transport is supported on ARM -- I2C is AVR-only)
*`#define SOFT_SERIAL_PIN D0`
* When using serial, define this. `D0` or `D1`,`D2`,`D3`,`E6`.
@@ -280,6 +296,7 @@ There are a few different ways to set handedness for split keyboards (listed in
*`#define MATRIX_ROW_PINS_RIGHT { <row pins> }`
*`#define MATRIX_COL_PINS_RIGHT { <col pins> }`
* If you want to specify a different pinout for the right half than the left half, you can define `MATRIX_ROW_PINS_RIGHT`/`MATRIX_COL_PINS_RIGHT`. Currently, the size of `MATRIX_ROW_PINS` must be the same as `MATRIX_ROW_PINS_RIGHT` and likewise for the definition of columns.
* may be omitted by the keyboard designer if matrix reads are handled in an alternate manner. See [low-level matrix overrides](custom_quantum_functions.md?id=low-level-matrix-overrides) for more information.
* If you want to specify a different direct pinout for the right half than the left half, you can define `DIRECT_PINS_RIGHT`. Currently, the size of `DIRECT_PINS` must be the same as `DIRECT_PINS_RIGHT`.
@@ -300,7 +317,7 @@ There are a few different ways to set handedness for split keyboards (listed in
*`#define SPLIT_USB_DETECT`
* Detect (with timeout) USB connection when delegating master/slave
* Default behavior for ARM
* Required for AVR Teensy
* Required for AVR Teensy (without hardware mods)
*`#define SPLIT_USB_TIMEOUT 2000`
* Maximum timeout when detecting master/slave when using `SPLIT_USB_DETECT`
@@ -308,6 +325,34 @@ There are a few different ways to set handedness for split keyboards (listed in
*`#define SPLIT_USB_TIMEOUT_POLL 10`
* Poll frequency when detecting master/slave when using `SPLIT_USB_DETECT`
*`#define FORCED_SYNC_THROTTLE_MS 100`
* Deadline for synchronizing data from master to slave when using the QMK-provided split transport.
*`#define SPLIT_TRANSPORT_MIRROR`
* Mirrors the master-side matrix on the slave when using the QMK-provided split transport.
*`#define SPLIT_LAYER_STATE_ENABLE`
* Ensures the current layer state is available on the slave when using the QMK-provided split transport.
*`#define SPLIT_LED_STATE_ENABLE`
* Ensures the current host indicator state (caps/num/scroll) is available on the slave when using the QMK-provided split transport.
*`#define SPLIT_MODS_ENABLE`
* Ensures the current modifier state (normal, weak, and oneshot) is available on the slave when using the QMK-provided split transport.
*`#define SPLIT_WPM_ENABLE`
* Ensures the current WPM is available on the slave when using the QMK-provided split transport.
*`#define SPLIT_OLED_ENABLE`
* Syncs the on/off state of the OLED between the halves.
*`#define SPLIT_ST7565_ENABLE`
* Syncs the on/off state of the ST7565 screen between the halves.
*`#define SPLIT_TRANSACTION_IDS_KB .....`
*`#define SPLIT_TRANSACTION_IDS_USER .....`
* Allows for custom data sync with the slave when using the QMK-provided split transport. See [custom data sync between sides](feature_split_keyboard.md#custom-data-sync) for more information.
# The `rules.mk` File
This is a [make](https://www.gnu.org/software/make/manual/make.html) file that is included by the top-level `Makefile`. It is used to set some information about the MCU that we will be compiling for as well as enabling and disabling certain features.
@@ -375,6 +420,8 @@ Use these to enable or disable building certain features. The more you have enab
* USB N-Key Rollover - if this doesn't work, see here: https://github.com/tmk/tmk_keyboard/wiki/FAQ#nkro-doesnt-work
This page describes the web architecture behind QMK Configurator at a high level. If you are interested in the architecture of the QMK Configurator code itself you should start at the [qmk_configurator](https://github.com/qmk/qmk_configurator) repository.
QMK Configurator is a [Single Page Application](https://en.wikipedia.org/wiki/Single-page_application) that allows users to create custom keymaps for their QMK-compatible keyboard. They can export JSON representation of their keymaps and compile firmware binaries that can be flashed to their keyboard using a tool like [QMK Toolbox](https://github.com/qmk/qmk_toolbox).
Configurator gets metadata about keyboards from the Keyboard Metadata store and submits compile requests to the QMK API. The results of those compile requests will be made available on [Digital Ocean Spaces](https://www.digitalocean.com/products/spaces/), an S3-compatible data store.
## Configurator Frontend
Address: <https://config.qmk.fm>
The [Configurator Frontend](https://config.qmk.fm) is compiled into a set of static files that are served by Github Pages. This action happens every time a commit is pushed to the [qmk_configurator `master`](https://github.com/qmk/qmk_configurator) branch. You can view the status of these jobs on the [qmk_configurator actions tab](https://github.com/qmk/qmk_configurator/actions/workflows/build.yml).
## Keyboard Metadata
Address: <https://keyboards.qmk.fm>
The Keyboard Metadata is generated every time a keyboard in [qmk_firmware](https://github.com/qmk/qmk_firmware) changes. The resulting JSON files are uploaded to Spaces and used by Configurator to generate UI for each keyboard. You can view the status of this job on the [qmk_firmware actions tab](https://github.com/qmk/qmk_firmware/actions/workflows/api.yml). If you are a QMK Collaborator you can manually run this job using the `workflow_dispatch` event trigger.
## QMK API
Address: <http://api.qmk.fm>
The QMK API accepts `keymap.json` files for compilation. These are the same files you can use directly with `qmk compile` and `qmk flash`. When a `keymap.json` is submitted the browser will poll the status of the job periodically (every 2 seconds or longer, preferably) until the job has completed. The final status JSON will contain pointers to source and binary downloads for the keymap.
QMK API always presents the source and binary downloads side-by-side to comply with the GPL.
There are 3 non-error status responses from the API-
1. Compile Job Queued
2. Compile Job Running
3. Compile Job Finished
### Compile Job Queued
This status indicates that the job has not yet been picked up by a [QMK Compiler](#qmk-compiler) node. Configurator shows this status as "Waiting for an oven".
### Compile Job Running
This status indicates that the job has started compiling. Configurator shows this status as "Baking".
### Compile Job Finished
This status indicates that the job has completed. There will be keys in the status JSON for source and binary downloads.
## Redis/RQ
QMK API uses RQ to distribute jobs to the available [QMK Compiler](#qmk-compiler) nodes. When a `keymap.json` is received it's put into the RQ queue, where a `qmk_compiler` node will pick it up from.
## QMK Compiler
[QMK Compiler](https://github.com/qmk/qmk_compiler) is what actually performs the compilation of the `keymap.json`. It does so by checking out the requested `qmk_firmware` branch, running `qmk compile keymap.json`, and then uploading the resulting source and binary to Digital Ocean Spaces.
When users download their source/binary, API will redirect them to the authenticated Spaces download URL.
@@ -148,7 +148,7 @@ Feature and Bug Fix PR's affect all keyboards. We are also in the process of res
Here are some things to keep in mind when working on your feature or bug fix.
* **Disabled by default** - memory is a pretty limited on most chips QMK supports, and it's important that current keymaps aren't broken, so please allow your feature to be turned **on**, rather than being turned off. If you think it should be on by default, or reduces the size of the code, please talk with us about it.
* **Compile locally before submitting** - hopefully this one is obvious, but things need to compile! Our Travis system will catch any issues, but it's generally faster for you to compile a few keyboards locally instead of waiting for the results to come back.
* **Compile locally before submitting** - hopefully this one is obvious, but things need to compile! You should always make sure your changes compile before opening a pull request.
* **Consider revisions and different chip-bases** - there are several keyboards that have revisions that allow for slightly different configurations, and even different chip-bases. Try to make a feature supported in ARM and AVR, or automatically disabled on platforms it doesn't work on.
* **Explain your feature** - Document it in `docs/`, either as a new file or as part of an existing file. If you don't document it other people won't be able to benefit from your hard work.
* This needs to perform the low-level initialisation of all row and column pins. By default this will initialise the input/output state of each of the GPIO pins listed in `MATRIX_ROW_PINS` and `MATRIX_COL_PINS`, based on whether or not the keyboard is set up for `ROW2COL`, `COL2ROW`, or `DIRECT_PINS`. Should the keyboard designer override this function, no initialisation of pin state will occur within QMK itself, instead deferring to the keyboard's override.
* These three functions need to perform the low-level retrieval of matrix state of relevant input pins, based on the matrix type. Only one of the functions should be implemented, if needed. By default this will iterate through `MATRIX_ROW_PINS` and `MATRIX_COL_PINS`, configuring the inputs and outputs based on whether or not the keyboard is set up for `ROW2COL`, `COL2ROW`, or `DIRECT_PINS`. Should the keyboard designer override this function, no manipulation of matrix GPIO pin state will occur within QMK itself, instead deferring to the keyboard's override.
And lastly, you want to add the `eeconfig_init_user` function, so that when the EEPROM is reset, you can specify default values, and even custom actions. To force an EEPROM reset, use the `EEP_RST` keycode or [Bootmagic](feature_bootmagic.md) functionallity. For example, if you want to set rgb layer indication by default, and save the default valued.
And lastly, you want to add the `eeconfig_init_user` function, so that when the EEPROM is reset, you can specify default values, and even custom actions. To force an EEPROM reset, use the `EEP_RST` keycode or [Bootmagic Lite](feature_bootmagic.md) functionallity. For example, if you want to set rgb layer indication by default, and save the default valued.
```c
voideeconfig_init_user(void){// EEPROM is getting reset!
Dieser Befehl formatiert C-Code im clang-Format. Benutze ihn ohne Argumente, um den core-Code zu formatieren, oder benutze Namen von Dateien in der CLI, um den Befehl auf bestimmte Dateien anzuwenden.
**Anwendung**:
```
qmk cformat [file1] [file2] [...] [fileN]
qmk format-c [file1] [file2] [...] [fileN]
```
## `qmk config`
@@ -148,14 +148,14 @@ Dieser Befehl erstellt eine neue Keymap basierend auf einer existierenden Standa
qmk new-keymap [-kb KEYBOARD] [-km KEYMAP]
```
## `qmk pyformat`
## `qmk format-py`
Dieser Befehl formatiert Python-Code in `qmk_firmware`.
@@ -8,8 +8,8 @@ We recommend the use of the [Zadig](https://zadig.akeo.ie/) utility. If you have
## Installation
Put your keyboard into bootloader mode, either by hitting the `RESET` keycode (which may be on a different layer), or by pressing the reset switch that's usually located on the underside of the board. If your keyboard has neither, try holding Escape or Space+`B` as you plug it in (see the [Bootmagic](feature_bootmagic.md) docs for more details). Some boards use [Command](feature_command.md) instead of Bootmagic; in this case, you can enter bootloader mode by hitting Left Shift+Right Shift+`B` or Left Shift+Right Shift+Escape at any point while the keyboard is plugged in.
Some keyboards may have specific instructions for entering the bootloader. For example, the [Bootmagic Lite](feature_bootmagic.md#bootmagic-lite) key (default: Escape) might be on a different key, e.g. Left Control; or the magic combination for Command (default: Left Shift+Right Shift) might require you to hold something else, e.g. Left Control+Right Control. Refer to the board's README file if you are unsure.
Put your keyboard into bootloader mode, either by hitting the `RESET` keycode (which may be on a different layer), or by pressing the reset switch that's usually located on the underside of the board. If your keyboard has neither, try holding Escape or Space+`B` as you plug it in (see the [Bootmagic Lite](feature_bootmagic.md) docs for more details). Some boards use [Command](feature_command.md) instead of Bootmagic; in this case, you can enter bootloader mode by hitting Left Shift+Right Shift+`B` or Left Shift+Right Shift+Escape at any point while the keyboard is plugged in.
Some keyboards may have specific instructions for entering the bootloader. For example, the [Bootmagic Lite](feature_bootmagic.md) key (default: Escape) might be on a different key, e.g. Left Control; or the magic combination for Command (default: Left Shift+Right Shift) might require you to hold something else, e.g. Left Control+Right Control. Refer to the board's README file if you are unsure.
To put a device in bootloader mode with USBaspLoader, tap the `RESET` button while holding down the `BOOT` button.
Alternatively, hold `BOOT` while inserting the USB cable.
@@ -30,18 +30,38 @@ If you find that you can no longer type with the keyboard, you may have accident

Open the Device Manager and look for a device that looks like your keyboard.
Open the Device Manager, select **View → Devices by container**, and look for an entry with your keyboard's name.


Right-click it and hit **Uninstall device**. Make sure to tick **Delete the driver software for this device** first.
Right-click each entry and hit **Uninstall device**. Make sure to tick **Delete the driver software for this device** first if it appears.

Click **Action → Scan for hardware changes**. At this point, you should be able to type again. Double check in Zadig that the keyboard device(s) are using the `HidUsb` driver. If so, you're all done, and your board should be functional again! Otherwise, repeat the process until Zadig reports the correct driver.
Click **Action → Scan for hardware changes**. At this point, you should be able to type again. Double check in Zadig that the keyboard device(s) are using the `HidUsb` driver. If so, you're all done, and your board should be functional again! Otherwise, repeat this process until Zadig reports the correct driver.
?> A full reboot of your computer may sometimes be necessary at this point, to get Windows to pick up the new driver.
## Uninstallation
Uninstallation of bootloader devices is a little more involved than installation.
Open the Device Manager, select **View → Devices by container**, and look for the bootloader device. Match up the USB VID and PID in Zadig with one from [the table below](#list-of-known-bootloaders).
Find the `Inf name` value in the Details tab of the device properties. This should generally be something like `oemXX.inf`:

Then, open a new Command Prompt window as an Administrator (type in `cmd` into the Start menu and press Ctrl+Shift+Enter). Run `pnputil /enum-drivers` to verify the `Inf name` matches the `Published Name` field of one of the entries:

Run `pnputil /delete-driver oemXX.inf /uninstall`. This will delete the driver and remove it from any devices using it. Note that this will not uninstall the device itself.
As with the previous section, this process may need to be repeated multiple times, as multiple drivers can be applicable to the same device.
!> **WARNING:** Be *extremely careful* when doing this! You could potentially uninstall the driver for some other critical device. If you are unsure, double check the output of `/enum-drivers`, and omit the `/uninstall` flag when running `/delete-driver`.
## List of Known Bootloaders
This is a list of known bootloader devices and their USB vendor and product IDs, as well as the correct driver to assign for flashing with QMK. Note that the usbser and HidUsb drivers are built in to Windows, and cannot be assigned with Zadig - if your device has an incorrect driver, you must use the Device Manager to uninstall it as described in the previous section.
@@ -75,3 +95,4 @@ The device name here is the name that appears in Zadig, and may not be what the
# Easy Maker - Build One-Off Projects In Configurator
Have you ever needed an easy way to program a controller, such as a Proton C or Teensy 2.0, for a one-off project you're building? QMK has you covered with the Easy Maker. Now you can create a firmware in minutes using QMK Configurator.
There are different styles of Easy Maker available depending on your needs:
* [Direct Pin](https://config.qmk.fm/#/?filter=ez_maker/direct) - Connect a single switch to a single pin
* Direct Pin + Backlight (Coming Soon) - Like Direct Pin but dedicates a single pin to [Backlight](feature_backlight.md) control
* Direct Pin + Numlock (Coming Soon) - Like Direct Pin but dedicates a single pin to the Numlock LED
* Direct Pin + Capslock (Coming Soon) - Like Direct Pin but dedicates a single pin to the Numlock LED
* Direct Pin + Encoder (Coming Soon) - Like Direct Pin but uses 2 pins to add a single rotary encoder
## Quickstart
The easiest way to get started is with the Direct Pin boards. This will assign a single key to each pin and you can short that pin to ground to activate it. Select your MCU from the Keyboard dropdown here:
For more details see the [Direct Pin](#direct-pin) section.
# Direct Pin
As its name implies Direct Pin works by connecting one switch per pin. The other side of the switch should be connected to ground (VSS or GND.) You don't need any other components, your MCU has internal pull-up resistors so that the switch sensing can work.
Here is a schematic showing how we connect a single button to pin A3 on a ProMicro:

Once you have wired your switches you can assign keycodes to each pin and build a firmware by selecting the MCU you are using from the Keyboard dropdown. Use this link to show only Easy Maker Direct Pin:
@@ -31,6 +31,9 @@ Currently QMK supports 24xx-series chips over I2C. As such, requires a working i
`#define EXTERNAL_EEPROM_PAGE_SIZE` | Page size of the EEPROM in bytes, as specified in the datasheet | 32
`#define EXTERNAL_EEPROM_ADDRESS_SIZE` | The number of bytes to transmit for the memory location within the EEPROM | 2
`#define EXTERNAL_EEPROM_WRITE_TIME` | Write cycle time of the EEPROM, as specified in the datasheet | 5
`#define EXTERNAL_EEPROM_WP_PIN` | If defined the WP pin will be toggled appropriately when writing to the EEPROM. | _none_
Some I2C EEPROM manufacturers explicitly recommend against hardcoding the WP pin to ground. This is in order to protect the eeprom memory content during power-up/power-down/brown-out conditions at low voltage where the eeprom is still operational, but the i2c master output might be unpredictable. If a WP pin is configured, then having an external pull-up on the WP pin is recommended.
Default values and extended descriptions can be found in `drivers/eeprom/eeprom_i2c.h`.
@@ -6,26 +6,28 @@ Si aún no lo has hecho, debes leer las [Pautas de teclados](hardware_keyboard_g
## Añadir tu Teclado AVR a QMK
QMK tiene varias características para simplificar el trabajo con teclados AVR. Para la mayoría de los teclados no tienes que escribir ni una sola línea de código. Para empezar, ejecuta el archivo `util/new_keyboard.sh`:
QMK tiene varias características para simplificar el trabajo con teclados AVR. Para la mayoría de los teclados no tienes que escribir ni una sola línea de código. Para empezar, ejecuta `qmk new-keyboard`:
```
$ ./util/new_keyboard.sh
Generating a new QMK keyboard directory
$ qmk new-keyboard
Ψ Generating a new QMK keyboard directory
Keyboard Name: mycoolkb
Keyboard Type [avr]:
Your Name [John Smith]:
Keyboard Name: mycoolkeeb
Keyboard Type:
1. avr
2. ps2avrgb
Please enter your choice: [1]
Your Name: [John Smith]
Ψ Copying base template files...
Ψ Copying avr template files...
Ψ Renaming keyboard.[ch] to mycoolkeeb.[ch]...
Ψ Replacing %YEAR% with 2021...
Ψ Replacing %KEYBOARD% with mycoolkeeb...
Ψ Replacing %YOUR_NAME% with John Smith...
Copying base template files... done
Copying avr template files... done
Renaming keyboard files... done
Replacing %KEYBOARD% with mycoolkb... done
Replacing %YOUR_NAME% with John Smith... done
Created a new keyboard called mycoolkb.
To start working on things, cd into keyboards/mycoolkb,
or open the directory in your favourite text editor.
Ψ Created a new keyboard called mycoolkeeb.
Ψ To start working on things, `cd` into keyboards/mycoolkeeb,
Ψ or open the directory in your preferred text editor.
```
Esto creará todos los archivos necesarios para tu nuevo teclado, y rellenará la configuración con valores predeterminados. Ahora sólo tienes que personalizarlo para tu teclado.
@@ -28,7 +28,7 @@ For compatible platforms, [QMK Toolbox](https://github.com/qmk/qmk_toolbox) can
Prefer a terminal based solution? [hid_listen](https://www.pjrc.com/teensy/hid_listen.html), provided by PJRC, can also be used to display debug messages. Prebuilt binaries for Windows,Linux,and MacOS are available.
## Sending Your Own Debug Messages
## Sending Your Own Debug Messages :id=debug-api
Sometimes it's useful to print debug messages from within your [custom code](custom_quantum_functions.md). Doing so is pretty simple. Start by including `print.h` at the top of your file:
@@ -31,7 +31,7 @@ QMK has two features, Bootmagic and Command, which allow you to change the behav
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:
These allow you to combine a modifier with a keycode. When pressed, the keydown event for the modifier, then `kc` will be sent. On release, the keyup event for `kc`, then the modifier will be sent.
@@ -131,12 +131,14 @@ You can override the default songs by doing something like this in your `config.
```c
#ifdef AUDIO_ENABLE
#define STARTUP_SONG SONG(STARTUP_SOUND)
#define STARTUP_SONG SONG(STARTUP_SOUND)
#endif
```
A full list of sounds can be found in [quantum/audio/song_list.h](https://github.com/qmk/qmk_firmware/blob/master/quantum/audio/song_list.h) - feel free to add your own to this list! All available notes can be seen in [quantum/audio/musical_notes.h](https://github.com/qmk/qmk_firmware/blob/master/quantum/audio/musical_notes.h).
Additionally, if you with to maintain your own list of songs (such as ones that may be copyrighted) and not have them added to the repo, you can create a `user_song_list.h` file and place it in your keymap (or userspace) folder. This file will be automatically included, it just needs to exist.
To play a custom sound at a particular time, you can define a song like this (near the top of the file):
```c
@@ -165,6 +167,32 @@ The available keycodes for audio are:
!> These keycodes turn all of the audio functionality on and off. Turning it off means that audio feedback, audio clicky, music mode, etc. are disabled, completely.
|`AUDIO_PIN` | *Not defined* |Configures the pin that the speaker is connected to. |
|`AUDIO_PIN_ALT` | *Not defined* |Configures the pin for a second speaker or second pin connected to one speaker.|
|`AUDIO_PIN_ALT_AS_NEGATIVE` | *Not defined* |Enables support for one speaker connected to two pins. |
|`AUDIO_INIT_DELAY` | *Not defined* |Enables delay during startup song to accomidate for USB startup issues. |
|`AUDIO_ENABLE_TONE_MULTIPLEXING` | *Not defined* |Enables time splicing/multiplexing to create multiple tones simutaneously. |
|`STARTUP_SONG` | `STARTUP_SOUND` |Plays when the keyboard starts up (audio.c) |
|`GOODBYE_SONG` | `GOODBYE_SOUND` |Plays when you press the RESET key (quantum.c) |
|`AG_NORM_SONG` | `AG_NORM_SOUND` |Plays when you press AG_NORM (process_magic.c) |
|`AG_SWAP_SONG` | `AG_SWAP_SOUND` |Plays when you press AG_SWAP (process_magic.c) |
|`CG_NORM_SONG` | `AG_NORM_SOUND` |Plays when you press CG_NORM (process_magic.c) |
|`CG_SWAP_SONG` | `AG_SWAP_SOUND` |Plays when you press CG_SWAP (process_magic.c) |
|`MUSIC_ON_SONG` | `MUSIC_ON_SOUND` |Plays when music mode is activated (process_music.c) |
|`MUSIC_OFF_SONG` | `MUSIC_OFF_SOUND` |Plays when music mode is deactivated (process_music.c) |
|`MIDI_ON_SONG` | `MUSIC_ON_SOUND` |Plays when midi mode is activated (process_music.c) |
|`MIDI_OFF_SONG` | `MUSIC_OFF_SOUND` |Plays when midi mode is deactivated (process_music.c) |
|`CHROMATIC_SONG` | `CHROMATIC_SOUND` |Plays when the chromatic music mode is selected (process_music.c) |
|`GUITAR_SONG` | `GUITAR_SOUND` |Plays when the guitar music mode is selected (process_music.c) |
|`VIOLIN_SONG` | `VIOLIN_SOUND` |Plays when the violin music mode is selected (process_music.c) |
|`MAJOR_SONG` | `MAJOR_SOUND` |Plays when the major music mode is selected (process_music.c) |
|`DEFAULT_LAYER_SONGS` | *Not defined* |Plays song when switched default layers with [`set_single_persistent_default_layer(layer)`](ref_functions.md#setting-the-persistent-default-layer)(quantum.c) |
|`SENDSTRING_BELL` | *Not defined* |Plays chime when the "enter" ("\a") character is sent (send_string.c) |
## Tempo
the 'speed' at which SONGs are played is dictated by the set Tempo, which is measured in beats-per-minute. Note lengths are defined relative to that.
The initial/default tempo is set to 120 bpm, but can be configured by setting `TEMPO_DEFAULT` in `config.c`.
There are three separate but related features that allow you to change the behavior of your keyboard without reflashing. While each of them have similar functionality, it is accessed in different ways depending on how your keyboard is configured.
**Bootmagic** is a system for configuring your keyboard while it initializes. To trigger a Bootmagic command, hold down the Bootmagic key and one or more command keys.
**Bootmagic Keycodes** are prefixed with `MAGIC_`, and allow you to access the Bootmagic functionality *after* your keyboard has initialized. To use the keycodes, assign them to your keymap as you would any other keycode.
**Command**, formerly known as **Magic**, is another feature that allows you to control different aspects of your keyboard. While it shares some functionality with Bootmagic, it also allows you to do things that Bootmagic does not, such as printing version information to the console. For more information, see [Command](feature_command.md).
On some keyboards Bootmagic is disabled by default. If this is the case, it must be explicitly enabled in your `rules.mk` with:
```make
BOOTMAGIC_ENABLE= full
```
?> You may see `yes` being used in place of `full`, and this is okay. However, `yes` is deprecated, and ideally `full` (or `lite`) should be used instead.
Additionally, you can use [Bootmagic Lite](#bootmagic-lite) (a scaled down, very basic version of Bootmagic) by adding the following to your `rules.mk` file:
```make
BOOTMAGIC_ENABLE= lite
```
## Hotkeys
Hold down the Bootmagic key (Space by default) and the desired hotkey while plugging in your keyboard. For example, holding Space+`B` should cause it to enter the bootloader.
|`BOOTMAGIC_KEY_DEFAULT_LAYER_0` |`KC_0` |Make layer 0 the default layer |
|`BOOTMAGIC_KEY_DEFAULT_LAYER_1` |`KC_1` |Make layer 1 the default layer |
|`BOOTMAGIC_KEY_DEFAULT_LAYER_2` |`KC_2` |Make layer 2 the default layer |
|`BOOTMAGIC_KEY_DEFAULT_LAYER_3` |`KC_3` |Make layer 3 the default layer |
|`BOOTMAGIC_KEY_DEFAULT_LAYER_4` |`KC_4` |Make layer 4 the default layer |
|`BOOTMAGIC_KEY_DEFAULT_LAYER_5` |`KC_5` |Make layer 5 the default layer |
|`BOOTMAGIC_KEY_DEFAULT_LAYER_6` |`KC_6` |Make layer 6 the default layer |
|`BOOTMAGIC_KEY_DEFAULT_LAYER_7` |`KC_7` |Make layer 7 the default layer |
# Bootmagic Lite :id=bootmagic-lite
In addition to the full blown Bootmagic feature, is the Bootmagic Lite feature that only handles jumping into the bootloader. This is great for boards that don't have a physical reset button but you need a way to jump into the bootloader, and don't want to deal with the headache that Bootmagic can cause.
The Bootmagic Lite feature that only handles jumping into the bootloader. This is great for boards that don't have a physical reset button, giving you a way to jump into the bootloader
To enable this version of Bootmagic, you need to enable it in your `rules.mk` with:
On some keyboards Bootmagic Lite is disabled by default. If this is the case, it must be explicitly enabled in your `rules.mk` with:
```make
BOOTMAGIC_ENABLE=lite
BOOTMAGIC_ENABLE=yes
```
?> You may see `lite` being used in place of `yes`.
Additionally, you may want to specify which key to use. This is especially useful for keyboards that have unusual matrices. To do so, you need to specify the row and column of the key that you want to use. Add these entries to your `config.h` file:
```c
@@ -142,11 +21,11 @@ By default, these are set to 0 and 0, which is usually the "ESC" key on a majori
And to trigger the bootloader, you hold this key down when plugging the keyboard in. Just the single key.
!> Using bootmagic lite will **always reset** the EEPROM, so you will lose any settings that have been saved.
!> Using Bootmagic Lite will **always reset** the EEPROM, so you will lose any settings that have been saved.
## Split Keyboards
When handedness is predetermined via an option like `SPLIT_HAND_PIN`, you might need to configure a different key between halves. This To do so, add these entries to your `config.h` file:
When handedness is predetermined via an option like `SPLIT_HAND_PIN`, you might need to configure a different key between halves. To do so, add these entries to your `config.h` file:
```c
#define BOOTMAGIC_LITE_ROW_RIGHT 4
@@ -174,4 +53,10 @@ void bootmagic_lite(void) {
}
```
You can additional feature here. For instance, resetting the eeprom or requiring additional keys to be pressed to trigger bootmagic. Keep in mind that `bootmagic_lite` is called before a majority of features are initialized in the firmware.
You can additional feature here. For instance, resetting the EEPROM or requiring additional keys to be pressed to trigger Bootmagic Lite. Keep in mind that `bootmagic_lite` is called before a majority of features are initialized in the firmware.
## Addenda
To manipulate settings that were formerly configured through the now-deprecated full Bootmagic feature, see [Magic Keycodes](keycodes_magic.md).
The Command feature, formerly known as Magic, also allows you to control different aspects of your keyboard. While it shares some functionality with Magic Keycodes, it also allows you to do things that Magic Keycodes cannot, such as printing version information to the console. For more information, see [Command](feature_command.md).
The Combo feature is a chording type solution for adding custom actions. It lets you hit multiple keys at once and produce a different effect. For instance, hitting `A` and `S` within the tapping term would hit `ESC` instead, or have it perform even more complex tasks.
The Combo feature is a chording type solution for adding custom actions. It lets you hit multiple keys at once and produce a different effect. For instance, hitting `A` and `S` within the combo term would hit `ESC` instead, or have it perform even more complex tasks.
To enable this feature, you need to add `COMBO_ENABLE = yes` to your `rules.mk`.
Additionally, in your `config.h`, you'll need to specify the number of combos that you'll be using, by adding `#define COMBO_COUNT 1` (replacing 1 with the number that you're using).
<!-- At this time, this is necessary -->
Additionally, in your `config.h`, you'll need to specify the number of combos that you'll be using, by adding `#define COMBO_COUNT 1` (replacing 1 with the number that you're using). It is also possible to not define this and instead set the variable `COMBO_LEN` yourself. There's a trick where we don't need to think about this variable at all. More on this later.
Also, by default, the tapping term for the Combos is set to the same value as `TAPPING_TERM` (200 by default on most boards). But you can specify a different value by defining it in your `config.h`. For instance: `#define COMBO_TERM 300` would set the time out period for combos to 300ms.
Then, your `keymap.c` file, you'll need to define a sequence of keys, terminated with `COMBO_END`, and a structure to list the combination of keys, and it's resulting action.
Then, in your `keymap.c` file, you'll need to define a sequence of keys, terminated with `COMBO_END`, and a structure to list the combination of keys, and its resulting action.
COMBO(test_combo2,LCTL(KC_Z)),// keycodes with modifiers are possible too!
};
```
This will send "Escape" if you hit the A and B keys.
This will send "Escape" if you hit the A and B keys, and Ctrl+Z when you hit the C and D keys.
!> This method only supports [basic keycodes](keycodes_basic.md). See the examples for more control.
As of [PR#8591](https://github.com/qmk/qmk_firmware/pull/8591/), it is possible to fire combos from ModTap keys and LayerTap keys. So in the above example you could have keys `LSFT_T(KC_A)` and `LT(_LAYER, KC_B)` and it would work. So Home Row Mods and Home Row Combos at same time is now a thing!
It is also now possible to overlap combos. Before, with the example below both combos would activate when all three keys were pressed. Now only the three key combo will activate.
This will send Ctrl+C if you hit Z and C, and Ctrl+V if you hit X and V. But you could change this to do stuff like change layers, play sounds, or change settings.
This will send "john.doe@example.com" if you chord E and M together, and clear the current line with Backspace and Left-Shift. You could change this to do stuff like play sounds or change settings.
## Additional Configuration
It is worth noting that `COMBO_ACTION`s are not needed anymore. As of [PR#8591](https://github.com/qmk/qmk_firmware/pull/8591/), it is possible to run your own custom keycodes from combos. Just define the custom keycode, program its functionality in `process_record_user`, and define a combo with `COMBO(<key_array>, <your_custom_keycode>)`.
If you're using long combos, or even longer combos, you may run into issues with this, as the structure may not be large enough to accommodate what you're doing.
In this case, you can add either `#define EXTRA_LONG_COMBOS` or `#define EXTRA_EXTRA_LONG_COMBOS` in your `config.h` file.
You may also be able to enable action keys by defining `COMBO_ALLOW_ACTION_KEYS`.
## Keycodes
You can enable, disable and toggle the Combo feature on the fly. This is useful if you need to disable them temporarily, such as for a game.
## Keycodes
You can enable, disable and toggle the Combo feature on the fly. This is useful if you need to disable them temporarily, such as for a game. The following keycodes are available for use in your `keymap.c`
|Keycode |Description |
|----------|---------------------------------|
@@ -91,6 +111,187 @@ You can enable, disable and toggle the Combo feature on the fly. This is useful
|`CMB_OFF` |Turns off Combo feature |
|`CMB_TOG` |Toggles Combo feature on and off |
# Advanced Configuration
These configuration settings can be set in your `config.h` file.
## Combo Term
By default, the timeout for the Combos to be recognized is set to 50ms. This can be changed if accidental combo misfires are happening or if you're having difficulties pressing keys at the same time. For instance, `#define COMBO_TERM 40` would set the timeout period for combos to 40ms.
## Buffer and state sizes
If you're using long combos, or you have a lot of overlapping combos, you may run into issues with this, as the buffers may not be large enough to accommodate what you're doing. In this case, you can configure the sizes of the buffers used. Be aware, larger combo sizes and larger buffers will increase memory usage!
To configure the amount of keys a combo can be composed of, change the following:
| Keys | Define to be set |
|------|-----------------------------------|
| 6 | `#define EXTRA_SHORT_COMBOS` |
| 8 | QMK Default |
| 16 | `#define EXTRA_LONG_COMBOS` |
| 32 | `#define EXTRA_EXTRA_LONG_COMBOS` |
Defining `EXTRA_SHORT_COMBOS` combines a combo's internal state into just one byte. This can, in some cases, save some memory. If it doesn't, no point using it. If you do, you also have to make sure you don't define combos with more than 6 keys.
Processing combos has two buffers, one for the key presses, another for the combos being activated. Use the following options to configure the sizes of these buffers:
If a combo resolves to a Modifier, the window for processing the combo can be extended independently from normal combos. By default, this is disabled but can be enabled with `#define COMBO_MUST_HOLD_MODS`, and the time window can be configured with `#define COMBO_HOLD_TERM 150` (default: `TAPPING_TERM`). With `COMBO_MUST_HOLD_MODS`, you cannot tap the combo any more which makes the combo less prone to misfires.
## Per Combo Timing, Holding and Tapping
For each combo, it is possible to configure the time window it has to pressed in, if it needs to be held down, or if it needs to be tapped.
For example, tap-only combos are useful if any (or all) of the underlying keys is a Mod-Tap or a Layer-Tap key. When you tap the combo, you get the combo result. When you press the combo and hold it down, the combo doesn't actually activate. Instead the keys are processed separately as if the combo wasn't even there.
In order to use these features, the following configuration options and functions need to be defined. Coming up with useful timings and configuration is left as an exercise for the reader.
| `COMBO_MUST_HOLD_PER_COMBO` | bool get_combo_must_hold(uint16_t index, combo_t \*combo) | Controls if a given combo should fire immediately on tap or if it needs to be held. (default: `false`) |
| `COMBO_MUST_TAP_PER_COMBO` | bool get_combo_must_tap(uint16_t index, combo_t \*combo) | Controls if a given combo should fire only if tapped within `COMBO_HOLD_TERM`. (default: `false`) |
If you leave `COMBO_COUNT` undefined in `config.h`, it allows you to programmatically declare the size of the Combo data structure and avoid updating `COMBO_COUNT`. Instead a variable called `COMBO_LEN` has to be set. It can be set with something similar to the following in `keymap.c`: `uint16_t COMBO_LEN = sizeof(key_combos) / sizeof(key_combos[0]);` or by adding `COMBO_LENGTH` as the *last* entry in the combo enum and then `uint16_t COMBO_LEN = COMBO_LENGTH;` as such:
```c
enummyCombos{
...,
COMBO_LENGTH
};
uint16_tCOMBO_LEN=COMBO_LENGTH;
```
Regardless of the method used to declare `COMBO_LEN`, this also requires to convert the `combo_t key_combos[COMBO_COUNT] = {...};` line to `combo_t key_combos[] = {...};`.
## Combo timer
Normally, the timer is started on the first key press and then reset on every subsequent key press within the `COMBO_TERM`.
Inputting combos is relaxed like this, but also slightly more prone to accidental misfires.
The next two options alter the behaviour of the timer.
### `#define COMBO_STRICT_TIMER`
With `COMBO_STRICT_TIMER`, the timer is started only on the first key press.
Inputting combos is now less relaxed; you need to make sure the full chord is pressed within the `COMBO_TERM`.
Misfires are less common but if you type multiple combos fast, there is a
chance that the latter ones might not activate properly.
### `#define COMBO_NO_TIMER`
By defining `COMBO_NO_TIMER`, the timer is disabled completely and combos are activated on the first key release.
This also disables the "must hold" functionalities as they just wouldn't work at all.
## Customizable key releases
By defining `COMBO_PROCESS_KEY_RELEASE` and implementing the function `bool process_combo_key_release(uint16_t combo_index, combo_t *combo, uint8_t key_index, uint16_t keycode)`, you can run your custom code on each key release after a combo was activated. For example you could change the RGB colors, activate haptics, or alter the modifiers.
You can also release a combo early by returning `true` from the function.
Here's an example where a combo resolves to two modifiers, and on key releases the modifiers are unregistered one by one, depending on which key was released.
If you, for example, use multiple base layers for different key layouts, one for QWERTY, and another one for Colemak, you might want your combos to work from the same key positions on all layers. Defining the same combos again for another layout is redundant and takes more memory. The solution is to just check the keycodes from one layer.
With `#define COMBO_ONLY_FROM_LAYER _LAYER_A` the combos' keys are always checked from layer `_LAYER_A` even though the active layer would be `_LAYER_B`.
## User callbacks
In addition to the keycodes, there are a few functions that you can use to set the status, or check it:
@@ -101,3 +302,28 @@ In addition to the keycodes, there are a few functions that you can use to set t
| `combo_disable()` | Disables the combo feature, and clears the combo buffer |
| `combo_toggle()` | Toggles the state of the combo feature |
| `is_combo_enabled()` | Returns the status of the combo feature state (true or false) |
# Dictionary Management
Having 3 places to update when adding new combos or altering old ones does become cumbersome when you have a lot of combos. We can alleviate this with some magic! ... If you consider C macros magic.
First, you need to add `VPATH += keyboards/gboards` to your `rules.mk`. Next, include the file `g/keymap_combo.h` in your `keymap.c`.
!> This functionality uses the same `process_combo_event` function as `COMBO_ACTION` macros do, so you cannot use the function yourself in your keymap. Instead, you have to define the `case`s of the `switch` statement by themselves within `inject.h`, which `g/keymap_combo.h` will then include into the function.
Then, write your combos in `combos.def` file in the following manner:
```c
// name result chord keys
COMB(AB_ESC,KC_ESC,KC_A,KC_B)
COMB(JK_TAB,KC_TAB,KC_J,KC_K)
COMB(JKL_SPC,KC_SPC,KC_J,KC_K,KC_L)
COMB(BSSL_CLR,KC_NO,KC_BSPC,KC_LSFT)// using KC_NO as the resulting keycode is the same as COMBO_ACTION before.
COMB(QW_UNDO,C(KC_Z),KC_Q,KC_W)
SUBS(TH_THE,"the",KC_T,KC_H)// SUBS uses SEND_STRING to output the given string.
...
```
Now, you can update only one place to add or alter combos. You don't even need to remember to update the `COMBO_COUNT` or the `COMBO_LEN` variables at all. Everything is taken care of. Magic!
For small to huge ready made dictionaries of combos, you can check out http://combos.gboards.ca/.
Command, formerly known as Magic, is a way to change your keyboard's behavior without having to flash or unplug it to use [Bootmagic](feature_bootmagic.md). There is a lot of overlap between this functionality and the [Bootmagic Keycodes](feature_bootmagic.md#keycodes). Wherever possible we encourage you to use that feature instead of Command.
Command, formerly known as Magic, is a way to change your keyboard's behavior without having to flash or unplug it to use [Bootmagic Lite](feature_bootmagic.md). There is a lot of overlap between this functionality and the [Magic Keycodes](keycodes_magic.md). Wherever possible we encourage you to use that feature instead of Command.
On some keyboards Command is disabled by default. If this is the case, it must be explicitly enabled in your `rules.mk`:
@@ -121,16 +112,16 @@ DEBOUNCE_TYPE = <name of algorithm>
Where name of algorithm is one of:
* ```sym_defer_g``` - debouncing per keyboard. On any state change, a global timer is set. When ```DEBOUNCE``` milliseconds of no changes has occurred, all input changes are pushed.
* This is the current default algorithm. This is the highest performance algorithm with lowest memory usage, and it's also noise-resistant.
* ```sym_eager_pr``` - debouncing per row. On any state change, response is immediate, followed by locking the row ```DEBOUNCE``` milliseconds of no further input for that row.
* ```sym_eager_pr``` - debouncing per row. On any state change, response is immediate, followed by locking the row ```DEBOUNCE``` milliseconds of no further input for that row.
For use in keyboards where refreshing ```NUM_KEYS``` 8-bit counters is computationally expensive / low scan rate, and fingers usually only hit one row at a time. This could be
appropriate for the ErgoDox models; the matrix is rotated 90°, and hence its "rows" are really columns, and each finger only hits a single "row" at a time in normal use.
* ```sym_eager_pk``` - debouncing per key. On any state change, response is immediate, followed by ```DEBOUNCE``` milliseconds of no further input for that key
* ```sym_defer_pk``` - debouncing per key. On any state change, a per-key timer is set. When ```DEBOUNCE``` milliseconds of no changes have occurred on that key, the key status change is pushed.
* ```asym_eager_defer_pk``` - debouncing per key. On a key-down state change, response is immediate, followed by ```DEBOUNCE``` milliseconds of no further input for that key. On a key-up state change, a per-key timer is set. When ```DEBOUNCE``` milliseconds of no changes have occurred on that key, the key-up status change is pushed.
### A couple algorithms that could be implemented in the future:
* ```sym_defer_pr```
* ```sym_eager_g```
* ```asym_eager_defer_pk```
### Use your own debouncing code
You have the option to implement you own debouncing algorithm. To do this:
@@ -140,11 +131,3 @@ You have the option to implement you own debouncing algorithm. To do this:
* Debouncing occurs after every raw matrix scan.
* Use num_rows rather than MATRIX_ROWS, so that split keyboards are supported correctly.
* If the algorithm might be applicable to other keyboards, please consider adding it to ```quantum/debounce```
### Old names
The following old names for existing algorithms will continue to be supported, however it is recommended to use the new names instead.
The digitizer HID interface allows setting the mouse cursor position at absolute coordinates, unlike the Pointing Device feature that applies relative displacements.
To enable the digitizer interface, add the following line to your rules.mk:
```makefile
DIGITIZER_ENABLE= yes
```
In order to change the mouse cursor position from your keymap.c file, include the digitizer header :
```c
#include"digitizer.h"
```
This gives you access to the `digitizer` structure which members allow you to change the cursor position.
The coordinates are normalized, meaning there value must be set between 0 and 1. For the `x` coordinate, the value `0` is the leftmost position, whereas the value `1` is the rightmost position.
For the `y` coordinate, `0` is at the top and `1` at the bottom.
Here is an example setting the cursor in the middle of the screen:
```c
digitizer_tdigitizer;
digitizer.x=0.5;
digitizer.y=0.5;
digitizer.tipswitch=0;
digitizer.inrange=1;
digitizer_set_report(digitizer);
```
The `tipswitch` member triggers what equates to a click when set to `1`. The `inrange` member is required for the change in coordinates to be taken. It can then be set to `0` in a new report to signal the end of the digitizer interaction, but it is not strictly required.
Once all members are set to the desired value, the `status` member needs its bitmask `DZ_UPDATED` to be set so the report is sent during the next main loop iteration.
@@ -38,6 +38,12 @@ It can also be defined per-encoder, by instead defining:
#define ENCODER_RESOLUTIONS { 4, 2 }
```
For 4× encoders you also can assign default position if encoder skips pulses when it changes direction. For example, if your encoder send high level on both pins by default, define this:
```c
#define ENCODER_DEFAULT_POS 0x3
```
## Split Keyboards
If you are using different pinouts for the encoders on each half of a split keyboard, you can define the pinout (and optionally, resolutions) for the right half like this:
@@ -162,4 +162,28 @@ This will set what sequence HPT_RST will set as the active mode. If not defined,
### DRV2605L Continuous Haptic Mode
This mode sets continuous haptic feedback with the option to increase or decrease strength.
This mode sets continuous haptic feedback with the option to increase or decrease strength.
## Haptic Key Exclusion
The Haptic Exclusion is implemented as `__attribute__((weak)) bool get_haptic_enabled_key(uint16_t keycode, keyrecord_t *record)` in haptic.c. This allows a re-definition at the required level with the specific requirement / exclusion.
### NO_HAPTIC_MOD
With the entry of `#define NO_HAPTIC_MOD` in config.h, modifiers from Left Control to Right GUI will not trigger a feedback. This also includes modifiers in a Mod Tap configuration.
### NO_HAPTIC_FN
With the entry of `#define NO_HAPTIC_FN` in config.h, layer keys will not rigger a feedback.
### NO_HAPTIC_ALPHA
With the entry of `#define NO_HAPTIC_ALPHA` in config.h, none of the alpha keys (A ... Z) will trigger a feedback.
### NO_HAPTIC_PUNCTUATION
With the entry of `#define NO_HAPTIC_PUNCTUATION` in config.h, none of the following keys will trigger a feedback: Enter, ESC, Backspace, Space, Minus, Equal, Left Bracket, Right Bracket, Backslash, Non-US Hash, Semicolon, Quote, Grave, Comma, Slash, Dot, Non-US Backslash.
### NO_HAPTIC_LOCKKEYS
With the entry of `#define NO_HAPTIC_LOCKKEYS` in config.h, none of the following keys will trigger a feedback: Caps Lock, Scroll Lock, Num Lock.
### NO_HAPTIC_NAV
With the entry of `#define NO_HAPTIC_NAV` in config.h, none of the following keys will trigger a feedback: Print Screen, Pause, Insert, Delete, Page Down, Page Up, Left Arrow, Up Arrow, Right Arrow, Down Arrow, End, Home.
### NO_HAPTIC_NUMERIC
With the entry of `#define NO_HAPTIC_NUMERIC` in config.h, none of the following keys between 0 and 9 (KC_1 ... KC_0) will trigger a feedback.
Key overrides allow you to override modifier-key combinations to send a different modifier-key combination or perform completely custom actions. Don't want `shift` + `1` to type `!` on your computer? Use a key override to make your keyboard type something different when you press `shift` + `1`. The general behavior is like this: If `modifiers w` + `key x` are pressed, replace these keys with `modifiers y` + `key z` in the keyboard report.
You can use key overrides in a similar way to momentary layer/fn keys to activate custom keycodes/shortcuts, with a number of benefits: You completely keep the original use of the modifier keys, while being able to save space by removing fn keys from your keyboard. You can also easily configure _combinations of modifiers_ to trigger different actions than individual modifiers, and much more. The possibilities are quite vast and this documentation contains a few examples for inspiration throughout.
##### A few more examples to get started: You could use key overrides to...
- Send `brightness up/down` when pressing `ctrl` + `volume up/down`.
- Send `delete` when pressing `shift` + `backspace`.
- Create custom shortcuts or change existing ones: E.g. Send `ctrl`+`shift`+`z` when `ctrl`+`y` is pressed.
- Run custom code when `ctrl` + `alt` + `esc` is pressed.
## Setup
To enable this feature, you need to add `KEY_OVERRIDE_ENABLE = yes` to your `rules.mk`.
Then, in your `keymap.c` file, you'll need to define the array `key_overrides`, which defines all key overrides to be used. Each override is a value of type `key_override_t`. The array `key_overrides` is `NULL`-terminated and contains pointers to `key_override_t` values (`const key_override_t **`).
## Creating Key Overrides
The `key_override_t` struct has many options that allow you to precisely tune your overrides. The full reference is shown below. Instead of manually creating a `key_override_t` value, it is recommended to use these dedicated initializers:
#### `ko_make_basic(modifiers, key, replacement)`
Returns a `key_override_t`, which sends `replacement` (can be a key-modifer combination), when `key` and `modifiers` are all pressed down. This override still activates if any additional modifiers not specified in `modifiers` are also pressed down. See `ko_make_with_layers_and_negmods` to customize this behavior.
Additionally takes a bitmask `options` that specifies additional options. See `ko_option_t` for available options.
For more customization possibilities, you may directly create a `key_override_t`, which allows you to customize even more behavior. Read further below for details and examples.
## Simple Example
This shows how the mentioned example of sending `delete` when `shift` + `backspace` are pressed is realized:
The [Grave Escape feature](https://docs.qmk.fm/using-qmk/advanced-keycodes/feature_grave_esc) is limited in its configurability and has [bugs when used on macOS](https://docs.qmk.fm/using-qmk/advanced-keycodes/feature_grave_esc#caveats). Key overrides can be used to achieve a similar functionality as Grave Escape, but with more customization and without bugs on macOS.
In addition to not encountering unexpected bugs on macOS, you can also change the behavior as you wish. Instead setting `GUI` + `ESC` = `` ` `` you may change it to an arbitrary other modifier, for example `Ctrl` + `ESC` = `` ` ``.
## Advanced Examples
### Modifiers as Layer Keys
Do you really need a dedicated key to toggle your fn layer? With key overrides, perhaps not. This example shows how you can configure to use `rGUI` + `rAlt` (right GUI and right alt) to access a momentary layer like an fn layer. With this you completely eliminate the need to use a dedicated layer key. Of course the choice of modifier keys can be changed as needed, `rGUI` + `rAlt` is just an example here.
```c
// This is called when the override activates and deactivates. Enable the fn layer on activation and disable on deactivation
|`KEY_OVERRIDE_ON` |Turns on Key Override feature | `key_override_on(void)`|
|`KEY_OVERRIDE_OFF` |Turns off Key Override feature |`key_override_off(void)`|
|`KEY_OVERRIDE_TOGGLE` |Toggles Key Override feature on and off |`key_override_toggle(void)`|
## Reference for `key_override_t`
Advanced users may need more customization than what is offered by the simple `ko_make` initializers. For this, directly create a `key_override_t` value and set all members. Below is a reference for all members of `key_override_t`.
| `uint16_t trigger` | The non-modifier keycode that triggers the override. This keycode, and the necessary modifiers (`trigger_mods`) must be pressed to activate this override. Set this to the keycode of the key that should activate the override. Set to `KC_NO` to require only the necessary modifiers to be pressed and no non-modifier. |
| `uint8_t trigger_mods` | Which mods need to be down for activation. If both sides of a modifier are set (e.g. left ctrl and right ctrl) then only one is required to be pressed (e.g. left ctrl suffices). Use the `MOD_MASK_XXX` and `MOD_BIT()` macros for this. |
| `layer_state_t layers` | This is a BITMASK (!), defining which layers this override applies to. To use this override on layer i set the ith bit `(1 <<i)`. |
| `uint8_tnegative_mod_mask` | Which modifiers cannot be down. It must hold that `(active_modifiers&negative_mod_mask)==0`, otherwise the key override will not be activated. An active override will be deactivated once this is no longer true. |
| `uint8_tsuppressed_mods` | Modifiers to 'suppress' while the override is active. To suppress a modifier means that even though the modifier key is held down, the host OS sees the modifier as not pressed. Can be used to suppress the trigger modifiers, as a trivial example. |
| `uint16_treplacement` | The complex keycode to send as replacement when this override is triggered. This can be a simple keycode, a key-modifier combination (e.g. `C(KC_A)`), or `KC_NO` (to register no replacement keycode). Use in combination with suppressed_mods to get the correct modifiers to be sent. |
| `ko_option_toptions` | Options controlling the behavior of the override, such as what actions are allowed to activate the override. |
| `bool(*custom_action)(boolactivated,void*context)` | If not NULL, this function will be called right before the replacement key is registered, along with the provided context and a flag indicating whether the override was activated or deactivated. This function allows you to run some custom actions for specific key overrides. If you return `false`, the replacement key is not registered/unregistered as it would normally. Return `true` to register and unregister the override normally. |
| `void*context` | A context that will be passed to the custom action function. |
| `bool*enabled` | If this points to false this override will not be used. Set to NULL to always have this override enabled. |
### Reference for `ko_option_t`
Bitfield with various options controlling the behavior of a key override.
| `ko_option_activation_trigger_down` | Allow activating when the trigger key is pressed down. |
| `ko_option_activation_required_mod_down` | Allow activating when a necessary modifier is pressed down. |
| `ko_option_activation_negative_mod_up` | Allow activating when a negative modifier is released. |
| `ko_option_one_mod` | If set, any of the modifiers in `trigger_mods` will be enough to activate the override (logical OR of modifiers). If not set, all the modifiers in `trigger_mods` have to be pressed (logical AND of modifiers). |
| `ko_option_no_unregister_on_other_key_down` | If set, the override will not deactivate when another key is pressed down. Use only if you really know you need this. |
| `ko_option_no_reregister_trigger` | If set, the trigger key will never be registered again after the override is deactivated. |
| `ko_options_default` | The default options used by the `ko_make_xxx` functions |
## For Advanced Users: Inner Workings
This section explains how a key override works in detail, explaining where each member of `key_override_t` comes into play. Understanding this is essential to be able to take full advantage of all the options offered by key overrides.
#### Activation
When the necessary keys are pressed (`trigger_mods` + `trigger`), the override is 'activated' and the replacement key is registered in the keyboard report (`replacement`), while the `trigger` key is removed from the keyboard report. The trigger modifiers may also be removed from the keyboard report upon activation of an override (`suppressed_mods`). The override will not activate if any of the `negative_modifiers` are pressed.
Overrides can activate in three different cases:
1. The trigger key is pressed down and necessary modifiers are already down.
2. A necessary modifier is pressed down, while the trigger key and other necessary modifiers are already down.
3. A negative modifier is released, while all necessary modifiers and the trigger key are already down.
Use the `option` member to customize which of these events are allowed to activate your overrides (default: all three).
In any case, a key override can only activate if the `trigger` key is the _last_ non-modifier key that was pressed down. This emulates the behavior of how standard OSes (macOS, Windows, Linux) handle normal key input (to understand: Hold down `a`, then also hold down `b`, then hold down `shift`; `B` will be typed but not `A`).
#### Deactivation
An override is 'deactivated' when one of the trigger keys (`trigger_mods`, `trigger`) is lifted, another non-modifier key is pressed down, or one of the `negative_modifiers` is pressed down. When an override deactivates, the `replacement` key is removed from the keyboard report, while the `suppressed_mods` that are still held down are re-added to the keyboard report. By default, the `trigger` key is re-added to the keyboard report if it is still held down and no other non-modifier key has been pressed since. This again emulates the behavior of how standard OSes handle normal key input (To understand: hold down `a`, then also hold down `b`, then also `shift`, then release `b`; `A` will not be typed even though you are holding the `a` and `shift` keys). Use the `option` field `ko_option_no_reregister_trigger` to prevent re-registering the trigger key in all cases.
#### Key Repeat Delay
A third way in which standard OS-handling of modifier-key input is emulated in key overrides is with a ['key repeat delay'](https://www.dummies.com/computers/pcs/set-your-keyboards-repeat-delay-and-repeat-rate/). To explain what this is, let's look at how normal keyboard input is handled by mainstream OSes again: If you hold down `a`, followed by `shift`, you will see the letter `a` is first typed, then for a short moment nothing is typed and then repeating `A`s are typed. Take note that, although shift is pressed down just after `a` is pressed, it takes a moment until `A` is typed. This is caused by the aforementioned key repeat delay, and it is a feature that prevents unwanted repeated characters from being typed.
This applies equally to releasing a modifier: When you hold `shift`, then press `a`, the letter `A` is typed. Now if you release `shift` first, followed by `a` shortly after, you will not see the letter `a` being typed, even though for a short moment of time you were just holding down the key `a`. This is because no modified characters are typed until the key repeat delay has passed.
This exact behavior is implemented in key overrides as well: If a key override for `shift` + `a` = `b` exists, and `a` is pressed and held, followed by `shift`, you will not immediately see the letter `b` being typed. Instead, this event is deferred for a short moment, until the key repeat delay has passed, measured from the moment when the trigger key (`a`) was pressed down.
The duration of the key repeat delay is controlled with the `KEY_OVERRIDE_REPEAT_DELAY` macro. Define this value in your `config.h` file to change it. It is 500ms by default.
## Difference to Combos
Note that key overrides are very different from [combos](https://docs.qmk.fm/#/feature_combo). Combos require that you press down several keys almost _at the same time_ and can work with any combination of non-modifier keys. Key overrides work like keyboard shortcuts (e.g. `ctrl` + `z`):Theytakecombinationsof_multiple_modifiersand_one_non-modifierkeytothenperformsomecustomaction.Keyoverridesareimplementedwithmuchcaretobehavejustlikenormalkeyboardshortcutswouldinregardstotheorderofpressedkeys,timing,andinteractonwithotherpressedkeys.Thereareanumberofoptionalsettingsthatcanbeusedtoreallyfine-tunethebehaviorofeachkeyoverrideaswell.Usingkeyoverridesalsodoesnotdelaykeyinputforregularkeypresses,whichinherentlyhappensincombosandmaybeundesirable.
Where `Cx_y` is the location of the LED in the matrix defined by [the datasheet](https://www.issi.com/WW/pdf/31FL3731.pdf) and the header file `drivers/issi/is31fl3731-simple.h`. The `driver` is the index of the driver you defined in your `config.h` (`0`, `1`, `2`, or `3` ).
Where `Cx_y` is the location of the LED in the matrix defined by [the datasheet](https://www.issi.com/WW/pdf/31FL3731.pdf) and the header file `drivers/led/issi/is31fl3731-simple.h`. The `driver` is the index of the driver you defined in your `config.h` (`0`, `1`, `2`, or `3` ).
---
## Common Configuration :id=common-configuration
From this point forward the configuration is the same for all the drivers. The `led_config_t` struct provides a key electrical matrix to led index lookup table, what the physical position of each LED is on the board, and what type of key or usage the LED if the LED represents. Here is a brief example:
```c
@@ -162,26 +164,26 @@ You can disable a single effect by defining `DISABLE_[EFFECT_NAME]` in your `con
#define LED_DISABLE_TIMEOUT 0 // number of milliseconds to wait until led automatically turns off
#define LED_DISABLE_AFTER_TIMEOUT 0 // OBSOLETE: number of ticks to wait until disabling effects
#define LED_DISABLE_WHEN_USB_SUSPENDED false // turn off effects when suspended
#define LED_DISABLE_WHEN_USB_SUSPENDED // turn off effects when suspended
#define LED_MATRIX_LED_PROCESS_LIMIT (DRIVER_LED_TOTAL + 4) / 5 // limits the number of LEDs to process in an animation per task run (increases keyboard responsiveness)
#define LED_MATRIX_LED_FLUSH_LIMIT 16 // limits in milliseconds how frequently an animation will update the LEDs. 16 (16ms) is equivalent to limiting to 60fps (increases keyboard responsiveness)
#define LED_MATRIX_MAXIMUM_BRIGHTNESS 255 // limits maximum brightness of LEDs
In split keyboards, it is very common to have two OLED displays that each render different content and are oriented or flipped differently. You can do this by switching which content to render by using the return value from `is_keyboard_master()` or `is_keyboard_left()` found in `split_util.h`, e.g:
Where `Cx_y` is the location of the LED in the matrix defined by [the datasheet](https://www.issi.com/WW/pdf/31FL3731.pdf) and the header file `drivers/issi/is31fl3731.h`. The `driver` is the index of the driver you defined in your `config.h` (`0`, `1`, `2`, or `3`).
Where `Cx_y` is the location of the LED in the matrix defined by [the datasheet](https://www.issi.com/WW/pdf/31FL3731.pdf) and the header file `drivers/led/issi/is31fl3731.h`. The `driver` is the index of the driver you defined in your `config.h` (`0`, `1`, `2`, or `3`).
---
### IS31FL3733 :id=is31fl3733
@@ -122,7 +122,7 @@ Currently only 4 drivers are supported, but it would be trivial to support all 8
Define these arrays listing all the LEDs in your `<keyboard>.c`:
Where `X_Y` is the location of the LED in the matrix defined by [the datasheet](https://www.issi.com/WW/pdf/31FL3733.pdf) and the header file `drivers/issi/is31fl3733.h`. The `driver` is the index of the driver you defined in your `config.h` (`0`, `1`, `2`, or `3` for now).
Where `X_Y` is the location of the LED in the matrix defined by [the datasheet](https://www.issi.com/WW/pdf/31FL3733.pdf) and the header file `drivers/led/issi/is31fl3733.h`. The `driver` is the index of the driver you defined in your `config.h` (`0`, `1`, `2`, or `3` for now).
---
### IS31FL3737 :id=is31fl3737
@@ -145,9 +145,22 @@ There is basic support for addressable RGB matrix lighting with the I2C IS31FL37
RGB_MATRIX_ENABLE= yes
RGB_MATRIX_DRIVER= IS31FL3737
```
You can use between 1 and 2 IS31FL3737 IC's. Do not specify `DRIVER_ADDR_2` define for second IC if not present on your keyboard.
Configure the hardware via your `config.h`:
| Variable | Description | Default |
|----------|-------------|---------|
| `ISSI_TIMEOUT` | (Optional) How long to wait for i2c messages, in milliseconds | 100 |
| `ISSI_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 |
| `DRIVER_COUNT` | (Required) How many RGB driver IC's are present | |
| `DRIVER_LED_TOTAL` | (Required) How many RGB lights are present across all drivers | |
| `DRIVER_ADDR_1` | (Required) Address for the first RGB driver | |
| `DRIVER_ADDR_2` | (Optional) Address for the second RGB driver | |
Here is an example using 2 drivers.
```c
// This is a 7-bit address, that gets left-shifted and bit 0
// set to 0 for write, 1 for read (as per I2C protocol)
@@ -159,19 +172,21 @@ Configure the hardware via your `config.h`:
// ADDR represents A3:A0 of the 7-bit address.
// The result is: 0b101(ADDR)
#define DRIVER_ADDR_1 0b1010000
#define DRIVER_ADDR_2 0b1010000 // this is here for compliancy reasons.
!> Note the parentheses, this is so when `DRIVER_LED_TOTAL` is used in code and expanded, the values are added together before any additional math is applied to them. As an example, `rand() % (DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL)` will give very different results than `rand() % DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL`.
Currently only a single drivers is supported, but it would be trivial to support all 4 combinations. For now define `DRIVER_ADDR_2` as `DRIVER_ADDR_1`
Currently only 2 drivers are supported, but it would be trivial to support all 4 combinations.
Define these arrays listing all the LEDs in your `<keyboard>.c`:
Where `X_Y` is the location of the LED in the matrix defined by [the datasheet](https://www.issi.com/WW/pdf/31FL3737.pdf) and the header file `drivers/issi/is31fl3737.h`. The `driver` is the index of the driver you defined in your `config.h` (Only `0` right now).
Where `X_Y` is the location of the LED in the matrix defined by [the datasheet](https://www.issi.com/WW/pdf/31FL3737.pdf) and the header file `drivers/led/issi/is31fl3737.h`. The `driver` is the index of the driver you defined in your `config.h` (Only `0`, `1` for now).
---
@@ -228,6 +243,77 @@ Configure the hardware via your `config.h`:
```
---
### AW20216 :id=aw20216
There is basic support for addressable RGB matrix lighting with the SPI AW20216 RGB controller. To enable it, add this to your `rules.mk`:
```makefile
RGB_MATRIX_ENABLE= yes
RGB_MATRIX_DRIVER= AW20216
```
You can use up to 2 AW20216 IC's. Do not specify `DRIVER_<N>_xxx` defines for IC's that are not present on your keyboard. You can define the following items in `config.h`:
| Variable | Description | Default |
|----------|-------------|---------|
| `DRIVER_1_CS` | (Required) MCU pin connected to first RGB driver chip select line | B13 |
| `DRIVER_2_CS` | (Optional) MCU pin connected to second RGB driver chip select line | |
| `DRIVER_1_EN` | (Required) MCU pin connected to first RGB driver hardware enable line | C13 |
| `DRIVER_2_EN` | (Optional) MCU pin connected to second RGB driver hardware enable line | |
| `DRIVER_1_LED_TOTAL` | (Required) How many RGB lights are connected to first RGB driver | |
| `DRIVER_2_LED_TOTAL` | (Optional) How many RGB lights are connected to second RGB driver | |
| `DRIVER_COUNT` | (Required) How many RGB driver IC's are present | |
| `DRIVER_LED_TOTAL` | (Required) How many RGB lights are present across all drivers | |
| `AW_SCALING_MAX` | (Optional) LED current scaling value (0-255, higher values mean LED is brighter at full PWM) | 150 |
| `AW_GLOBAL_CURRENT_MAX` | (Optional) Driver global current limit (0-255, higher values means the driver may consume more power) | 150 |
| `AW_SPI_DIVISOR` | (Optional) Clock divisor for SPI communication (powers of 2, smaller numbers means faster communication, should not be less than 4) | 4 |
Here is an example using 2 drivers.
```c
#define DRIVER_1_CS B13
#define DRIVER_2_CS B14
// Hardware enable lines may be connected to the same pin
!> Note the parentheses, this is so when `DRIVER_LED_TOTAL` is used in code and expanded, the values are added together before any additional math is applied to them. As an example, `rand() % (DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL)` will give very different results than `rand() % DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL`.
Define these arrays listing all the LEDs in your `<keyboard>.c`:
```c
constaw_led__flashg_aw_leds[DRIVER_LED_TOTAL]={
/* Each AW20216 channel is controlled by a register at some offset between 0x00
* and 0xD7 inclusive.
* See drivers/awinic/aw20216.h for the mapping between register offsets and
* driver pin locations.
* driver
* | R location
* | | G location
* | | | B location
* | | | | */
{0,CS1_SW1,CS2_SW1,CS3_SW1},
{0,CS4_SW1,CS5_SW1,CS6_SW1},
{0,CS7_SW1,CS8_SW1,CS9_SW1},
{0,CS10_SW1,CS11_SW1,CS12_SW1},
{0,CS13_SW1,CS14_SW1,CS15_SW1},
...
{1,CS1_SW1,CS2_SW1,CS3_SW1},
{1,CS13_SW1,CS14_SW1,CS15_SW1},
{1,CS16_SW1,CS17_SW1,CS18_SW1},
{1,CS4_SW2,CS5_SW2,CS6_SW2},
...
};
```
---
## Common Configuration :id=common-configuration
From this point forward the configuration is the same for all the drivers. The `led_config_t` struct provides a key electrical matrix to led index lookup table, what the physical position of each LED is on the board, and what type of key or usage the LED if the LED represents. Here is a brief example:
@@ -362,46 +448,46 @@ You can disable a single effect by defining `DISABLE_[EFFECT_NAME]` in your `con
This example sets the modifiers to be a specific color based on the layer state. You can use a switch case here, instead, if you would like. This uses HSV and then converts to RGB, because this allows the brightness to be limited (important when using the WS2812 driver).
@@ -119,7 +119,7 @@ if `RGBLIGHT_EFFECT_xxxx` or `RGBLIGHT_ANIMATIONS` is defined, you also have a n
Check out [this video](https://youtube.com/watch?v=VKrpPAHlisY) for a demonstration.
Note: For versions older than 0.6.117, The mode numbers were written directly. In `quantum/rgblight.h` there is a contrast table between the old mode number and the current symbol.
Note: For versions older than 0.6.117, The mode numbers were written directly. In `quantum/rgblight/rgblight.h` there is a contrast table between the old mode number and the current symbol.
### Effect and Animation Toggles
@@ -326,9 +326,13 @@ would turn the layer 0 (or 1) on and off again three times when `DEBUG` is press
Normally lighting layers are not shown when RGB Lighting is disabled (e.g. with `RGB_TOG` keycode). If you would like lighting layers to work even when the RGB Lighting is otherwise off, add `#define RGBLIGHT_LAYERS_OVERRIDE_RGB_OFF` to your `config.h`.
### Retain brightness
Usually lighting layers apply their configured brightness once activated. If you would like lighting layers to retain the currently used brightness (as returned by `rgblight_get_val()`), add `#define RGBLIGHT_LAYERS_RETAIN_VAL` to your `config.h`.
## Functions
If you need to change your RGB lighting in code, for example in a macro to change the color whenever you switch layers, QMK provides a set of functions to assist you. See [`rgblight.h`](https://github.com/qmk/qmk_firmware/blob/master/quantum/rgblight.h) for the full list, but the most commonly used functions include:
If you need to change your RGB lighting in code, for example in a macro to change the color whenever you switch layers, QMK provides a set of functions to assist you. See [`rgblight.h`](https://github.com/qmk/qmk_firmware/blob/master/quantum/rgblight/rgblight.h) for the full list, but the most commonly used functions include:
### Utility Functions
|Function |Description |
@@ -449,26 +453,27 @@ rgblight_sethsv_at(HSV_GREEN, 2); // led 2
These are shorthands to popular colors. The `RGB` ones can be passed to the `setrgb` functions, while the `HSV` ones to the `sethsv` functions.
@@ -8,8 +8,7 @@ QMK Firmware has a generic implementation that is usable by any board, as well a
For this, we will mostly be talking about the generic implementation used by the Let's Split and other keyboards.
!> ARM is not yet fully supported for Split Keyboards and has many limitations. Progress is being made, but we have not yet reached 100% feature parity.
!> ARM split supports most QMK subsystems when using the 'serial' and 'serial_usart' drivers. I2C slave is currently unsupported.
## Compatibility Overview
@@ -60,6 +59,7 @@ The 3 wires of the TRS/TRRS cable need to connect GND, VCC, and D0/D1/D2/D3 (aka
The 4 wires of the TRRS cable need to connect GND, VCC, and SCL and SDA (aka PD0/pin 3 and PD1/pin 2, respectively) between the two Pro Micros.
The pull-up resistors may be placed on either half. If you wish to use the halves independently, it is also possible to use 4 resistors and have the pull-ups in both halves.
Note that the total resistance for the connected system should be within spec at 2.2k-10kOhm, with an 'ideal' at 4.7kOhm, regardless of the placement and number.
@@ -89,7 +89,13 @@ You can configure the firmware to read a pin on the controller to determine hand
#define SPLIT_HAND_PIN B7
```
This will read the specified pin. If it's high, then the controller assumes it is the left hand, and if it's low, it's assumed to be the right side.
This will read the specified pin. By default, if it's high, then the controller assumes it is the left hand, and if it's low, it's assumed to be the right side.
This behaviour can be flipped by adding this to you `config.h` file:
```c
#define SPLIT_HAND_PIN_LOW_IS_LEFT
```
#### Handedness by Matrix Pin
@@ -168,7 +174,7 @@ Because not every split keyboard is identical, there are a number of additional
#define USE_I2C
```
This enables I<sup>2</sup>C support for split keyboards. This isn't strictly for communication, but can be used for OLED or other I<sup>2</sup>C-based devices.
This configures the use of I<sup>2</sup>C support for split keyboard transport (AVR only).
```c
#define SOFT_SERIAL_PIN D0
@@ -192,20 +198,143 @@ If you're having issues with serial communication, you can change this value, as
* **`5`**: about 20kbps
```c
#define SPLIT_MODS_ENABLE
#define FORCED_SYNC_THROTTLE_MS 100
```
This enables transmitting modifier state (normal, weak and oneshot) to the non
primary side of the split keyboard. This adds a few bytes of data to the split
communication protocol and may impact the matrix scan speed when enabled.
The purpose of this feature is to support cosmetic use of modifer state (e.g.
displaying status on an OLED screen).
This sets the maximum number of milliseconds before forcing a synchronization of data from master to slave. Under normal circumstances this sync occurs whenever the data _changes_, for safety a data transfer occurs after this number of milliseconds if no change has been detected since the last sync.
```c
#define SPLIT_MAX_CONNECTION_ERRORS 10
```
This sets the maximum number of failed communication attempts (one per scan cycle) from the master part before it assumes that no slave part is connected. This makes it possible to use a master part without the slave part connected.
Set to 0 to disable the disconnection check altogether.
```c
#define SPLIT_CONNECTION_CHECK_TIMEOUT 500
```
How long (in milliseconds) the master part should block all connection attempts to the slave after the communication has been flagged as disconnected (see `SPLIT_MAX_CONNECTION_ERRORS` above).
One communication attempt will be allowed everytime this amount of time has passed since the last attempt. If that attempt succeeds, the communication is seen as working again.
Set to 0 to disable this throttling of communications while disconnected. This can save you a couple of bytes of firmware size.
```c
#define SPLIT_TRANSPORT_MIRROR
```
This mirrors the master side matrix to the slave side for features that react or require knowledge of master side key presses on the slave side. This adds a few bytes of data to the split communication protocol and may impact the matrix scan speed when enabled. The purpose of this feature is to support cosmetic use of key events (e.g. RGB reacting to Keypresses).
This mirrors the master side matrix to the slave side for features that react or require knowledge of master side key presses on the slave side. The purpose of this feature is to support cosmetic use of key events (e.g. RGB reacting to keypresses). This adds overhead to the split communication protocol and may negatively impact the matrix scan speed when enabled.
```c
#define SPLIT_LAYER_STATE_ENABLE
```
This enables syncing of the layer state between both halves of the split keyboard. The main purpose of this feature is to enable support for use of things like OLED display of the currently active layer. This adds overhead to the split communication protocol and may negatively impact the matrix scan speed when enabled.
```c
#define SPLIT_LED_STATE_ENABLE
```
This enables syncing of the Host LED status (caps lock, num lock, etc) between both halves of the split keyboard. The main purpose of this feature is to enable support for use of things like OLED display of the Host LED status. This adds overhead to the split communication protocol and may negatively impact the matrix scan speed when enabled.
```c
#define SPLIT_MODS_ENABLE
```
This enables transmitting modifier state (normal, weak and oneshot) to the non primary side of the split keyboard. The purpose of this feature is to support cosmetic use of modifer state (e.g. displaying status on an OLED screen). This adds overhead to the split communication protocol and may negatively impact the matrix scan speed when enabled.
```c
#define SPLIT_WPM_ENABLE
```
This enables transmitting the current WPM to the slave side of the split keyboard. The purpose of this feature is to support cosmetic use of WPM (e.g. displaying the current value on an OLED screen). This adds overhead to the split communication protocol and may negatively impact the matrix scan speed when enabled.
```c
#define SPLIT_OLED_ENABLE
```
This enables transmitting the current OLED on/off status to the slave side of the split keyboard. The purpose of this feature is to support state (on/off state only) syncing. This adds overhead to the split communication protocol and may negatively impact the matrix scan speed when enabled.
```c
#define SPLIT_ST7565_ENABLE
```
This enables transmitting the current ST7565 on/off status to the slave side of the split keyboard. The purpose of this feature is to support state (on/off state only) syncing. This adds overhead to the split communication protocol and may negatively impact the matrix scan speed when enabled.
### Custom data sync between sides :id=custom-data-sync
QMK's split transport allows for arbitrary data transactions at both the keyboard and user levels. This is modelled on a remote procedure call, with the master invoking a function on the slave side, with the ability to send data from master to slave, process it slave side, and send data back from slave to master.
To leverage this, a keyboard or user/keymap can define a comma-separated list of _transaction IDs_:
The master side can then invoke the slave-side handler - for normal keyboard functionality to be minimally affected, any keyboard- or user-level code attempting to sync data should be throttled:
dprintf("Slave value: %d\n",s2m.s2m_data);// this will now be 11, as the slave adds 5
}else{
dprint("Slave sync failed!\n");
}
}
}
}
```
!> It is recommended that any data sync between halves happens during the master side's _housekeeping task_. This ensures timely retries should failures occur.
If only one-way data transfer is needed, helper methods are provided:
For some purposes, you may need to read the current state of the display buffer. The `st7565_read_raw` function can be used to safely read bytes from the buffer.
In this example, calling `fade_display` in the `st7565_task_user` function will slowly fade away whatever is on the screen by turning random pixels off over time.
```c
//Setup some mask which can be or'd with bytes to turn off pixels
//increment the pointer to fetch a new byte during the next loop
reader.current_element++;
}
}
}
```
## Other Examples
In split keyboards, it is very common to have two displays that each render different content and are oriented or flipped differently. You can do this by switching which content to render by using the return value from `is_keyboard_master()` or `is_keyboard_left()` found in `split_util.h`, e.g:
@@ -128,3 +128,18 @@ As defined in `keymap_steno.h`.
|`STN_RES1`||(GeminiPR only)|
|`STN_RES2`||(GeminiPR only)|
|`STN_PWR`||(GeminiPR only)|
If you do not want to hit two keys with one finger combined keycodes can be used. These are also defined in `keymap_steno.h`, and causes both keys to be reported as pressed or released. To use these keycodes define `STENO_COMBINEDMAP` in your `config.h` file
@@ -50,7 +50,7 @@ The main entry point is `process_tap_dance()`, called from `process_record_quant
This means that you have `TAPPING_TERM` time to tap the key again; you do not have to input all the taps within a single `TAPPING_TERM` timeframe. This allows for longer tap counts, with minimal impact on responsiveness.
Our next stop is `matrix_scan_tap_dance()`. This handles the timeout of tap-dance keys.
Our next stop is `tap_dance_task()`. This handles the timeout of tap-dance keys.
For the sake of flexibility, tap-dance actions can be either a pair of keycodes, or a user function. The latter allows one to handle higher tap counts, or do extra things, like blink the LEDs, fiddle with the backlighting, and so on. This is accomplished by using an union, and some clever macros.
Additionally, if `WPM_ALLOW_COUNT_REGRESSION` is defined, there is the `uint8_t wpm_regress_count(uint16_t keycode)` function that allows you to decrease the WPM. This is useful if you want to be able to penalize certain keycodes (or even combinations).
@@ -48,7 +48,7 @@ QMK maintains [a fork of the LUFA DFU bootloader](https://github.com/qmk/lufa/tr
//#define QMK_LED E6
//#define QMK_SPEAKER C6
```
Currently we do not recommend making `QMK_ESC` the same key as the one designated for [Bootmagic Lite](feature_bootmagic.md#bootmagic-lite), as holding it down will cause the MCU to loop back and forth between entering and exiting the bootloader.
Currently we do not recommend making `QMK_ESC` the same key as the one designated for [Bootmagic Lite](feature_bootmagic.md), as holding it down will cause the MCU to loop back and forth between entering and exiting the bootloader.
The manufacturer and product strings are automatically pulled from `config.h`, with " Bootloader" appended to the product string.
@@ -171,6 +171,52 @@ Flashing sequence:
3. Flash a .hex file
4. Reset the device into application mode (may be done automatically)
### QMK HID
QMK maintains [a fork of the LUFA HID bootloader](https://github.com/qmk/lufa/tree/master/Bootloaders/HID), which uses a USB HID Endpoint for flashing in the way that the PJRC's Teensy Loader flasher and HalfKay bootloader work. Additionally, it performs a simple matrix scan for exiting the bootloader and returning to the application, as well as flashing an LED/making a ticking noise with a speaker when things are happening.
To ensure compatibility with the QMK HID bootloader, make sure this block is present in your `rules.mk`:
```make
# Bootloader selection
BOOTLOADER= qmk-hid
```
To enable the additional features, add the following defines to your `config.h`:
```c
#define QMK_ESC_OUTPUT F1 // COL pin if COL2ROW
#define QMK_ESC_INPUT D5 // ROW pin if COL2ROW
// Optional:
//#define QMK_LED E6
//#define QMK_SPEAKER C6
```
Currently we do not recommend making `QMK_ESC` the same key as the one designated for [Bootmagic Lite](feature_bootmagic.md), as holding it down will cause the MCU to loop back and forth between entering and exiting the bootloader.
The manufacturer and product strings are automatically pulled from `config.h`, with " Bootloader" appended to the product string.
To generate this bootloader, use the `bootloader` target, eg. `make planck/rev4:default:bootloader`. To generate a production-ready .hex file (combining QMK and the bootloader), use the `production` target, eg. `make planck/rev4:default:production`.
Compatible flashers:
* TBD
* Currently, you need to either use the [Python script](https://github.com/qmk/lufa/tree/master/Bootloaders/HID/HostLoaderApp_python), or compile [`hid_bootloader_cli`](https://github.com/qmk/lufa/tree/master/Bootloaders/HID/HostLoaderApp), from the LUFA repo. Homebrew may (will) have support for this directly (via `brew install qmk/qmk/hid_bootloader_cli`).
Flashing sequence:
1. Enter the bootloader using any of the following methods:
* Press the `RESET` keycode
* Press the `RESET` button on the PCB if available
* short RST to GND quickly
2. Wait for the OS to detect the device
3. Flash a .hex file
4. Reset the device into application mode (may be done automatically)
### `make` Targets
*`:qmk-hid`: Checks every 5 seconds until a DFU device is available, and then flashes the firmware.
## STM32/APM32 DFU
All STM32 and APM32 MCUs, except for F103 (see the [STM32duino section](#stm32duino)) come preloaded with a factory bootloader that cannot be modified nor deleted.
@@ -252,7 +298,7 @@ Flashing sequence:
## tinyuf2
Keyboards may opt into supporting the tinyuf2 bootloader. This is currently only supported on the F411 blackpill.
Keyboards may opt into supporting the tinyuf2 bootloader. This is currently only supported on the F401/F411 blackpill.
The `rules.mk` setting for this bootloader is `tinyuf2`, and can be specified at the keymap or user level.
QMK (*Quantum Mechanical Keyboard*) est une communauté open source qui maintient le firmware QMK, la QMK Toolbox (*Boite à outil*), qmk.fm et leurs documentations. QMKFirmware est un firmware dédié aux claviers qui est basé sur [tmk\_keyboard](https://github.com/tmk/tmk_keyboard). Il offre des fonctionnalités très utiles pour les contrôleurs Atmel AVR, et, plus spécifiquement pour [les produits d'OLKB](https://olkb.com), le clavier [ErgoDox EZ](https://www.ergodox-ez.com), et pour les [produits Clueboard](https://clueboard.co/). Il prend désormais aussi en charge les processeurs ARM qui utilisent ChibiOS. Vous pouvez l'utiliser pour contrôler un clavier personnalisé soudé à la main ou alors sur un clavier avec un PCB personnalisé.
QMK (*Quantum Mechanical Keyboard*) est une communauté open source qui maintient le firmware QMK, la QMK Toolbox (*Boite à outil*), qmk.fm et leurs documentations. QMKFirmware est un firmware dédié aux claviers qui est basé sur [tmk\_keyboard](https://github.com/tmk/tmk_keyboard). Il offre des fonctionnalités très utiles pour les contrôleurs Atmel AVR, et, plus spécifiquement pour [les produits d'OLKB](https://olkb.com), le clavier [ErgoDox EZ](https://www.ergodox-ez.com), et pour les [produits Clueboard](https://clueboard.co/). Il prend désormais aussi en charge les processeurs ARM qui utilisent ChibiOS. Vous pouvez l'utiliser pour contrôler un clavier personnalisé soudé à la main ou alors sur un clavier avec un PCB personnalisé.
## Comment l'obtenir
@@ -23,7 +22,7 @@ Avant d'être prêt à compiler vous allez devoir [installer un environnement](f
make planck/rev4:default
Cette commande compilera la révision `rev4` du clavier `planck` avec la disposition `default`. Notez que tous les claviers n'ont pas forcément de révisions (aussi appelées sous-projects ou dossiers, ou en anglais «subprojects» ou «folder»). Cette option peut donc être omise:
Cette commande compilera la révision `rev4` du clavier `planck` avec la disposition `default`. Notez que tous les claviers n'ont pas forcément de révisions (aussi appelées sous-projects ou dossiers, ou en anglais «subprojects» ou «folder»). Cette option peut donc être omise:
Cette commande formatte le code C en utilisant clang-format. Lancez-la sans arguments pour formatter tout le code core, ou passez les noms de fichiers à la ligne de commande pour la lancer sur des fichiers spécifiques.
**Utilisation**:
```
qmk cformat [file1] [file2] [...] [fileN]
qmk format-c [file1] [file2] [...] [fileN]
```
## `qmk config`
@@ -125,14 +125,14 @@ Cette commande crée une nouvelle keymap basée sur une keymap par défaut d'un
qmk new-keymap [-kb KEYBOARD] [-km KEYMAP]
```
## `qmk pyformat`
## `qmk format-py`
Cette commande formate le code python dans `qmk_firmware`.
@@ -134,7 +134,7 @@ Les PR de nouvelles fonctionnalités de de correction de bug affectent tous les
Voici quelques choses à garder en tête lorsque vous travaillez sur une fonctionnalité ou un bug fix.
* **Désactivé par défaut** - la mémoire est plutôt limitée sur la plupart des puces que QMK supporte, et il est important que les keymaps courantes ne soient pas cassées. S'il vous plaît faites que vos features doivent être **activées** plutôt que désactivées. Si vous pensez qu'elle devrait être activée par défaut, ou que cela réduit la taille du code, parlez-nous-en.
* **Compilez localement avant de soumettre** - Cela devrait aller sans dire, mais votre code doit compiler! Notre système Travis devrait relever les problèmes, mais il est généralement plus rapide de compiler quelques claviers en local plutôt que d'attendre le retour des résultats
* **Compilez localement avant de soumettre** - Cela devrait aller sans dire, mais votre code doit compiler! Vous devriez toujours faire gaffe à ce que vos changements compilent avant d'ouvrir une pull request.
* **Faites attention aux révisions et différentes bases de puces** - beaucoup de claviers ont des révisions qui permettent des changements de configuration mineurs, voir des bases de chip différentes. Essayez de faire que votre fonctionnalité soit supportée à la fois sur ARM et AVR, ou désactivez-là automatiquement sur les plateformes non supportées.
* **Expliquez votre fonctionnalité** - Documentez-là dans `docs/`, soit dans un nouveau fichier, ou dans une partie d'un fichier existant. Si vous ne la documentez pas, personne ne pourra bénéficier de votre dur labeur.
@@ -9,7 +9,7 @@ Nous vous recommandons d'utiliser l'utilitaire [Zadig](https://zadig.akeo.ie/).
## Installation
Passez votre clavier en mode bootloader, soit en appuyant sur le keycode `RESET` (qui peut se trouver dans un calque différent) ou en appuyant sur le bouton reset qui se trouve en général sous la board. Si votre clavier n'a aucune de ces options, essayez de le brancher en maintenant Escape ou Espace+`B` appuyés (voir la documentation de [Bootmagic](feature_bootmagic.md) pour plus de détails). Certaines boards utilisent [Command](feature_command.md) à la place de Bootmagic. Dans ce cas, vous pouvez entrer en mode bootloader en appuyant, à n'importe quel moment lorsque le clavier est branché, sur les combinaisons de touches Shift Gauche+Shift Droit+`B` ou Shift Gauche+Shift Droit+Escape.
Certains claviers ont des instructions spécifiques pour passer en mode bootloader. Par exemple, la touche [Bootmagic Lite]](feature_bootmagic.md#bootmagic-lite) (défaut:Échap) peut être sur une touche différente telle que Contrôle Gauche. La combinaison pour la Command (défaut:Shift Gauche+Shift Droit) peut être différente, par exemple Contrôle Gauche+Contrôle Droit. Référez-vous au fichier README de votre clavier.
Certains claviers ont des instructions spécifiques pour passer en mode bootloader. Par exemple, la touche [Bootmagic Lite]](feature_bootmagic.md#bootmagic-lite) (défaut: Échap) peut être sur une touche différente telle que Contrôle Gauche. La combinaison pour la Command (défaut: Shift Gauche+Shift Droit) peut être différente, par exemple Contrôle Gauche+Contrôle Droit. Référez-vous au fichier README de votre clavier.
Pour mettre un clavier en mode bootloader avec USBaspLoader, appuyez sur le bouton `RESET` tout en maintenant le bouton `BOOT`. Vous pouvez aussi maintenir le bouton `BOOT` en branchant le câble USB.
@@ -43,4 +43,4 @@ Cliquez dessus avec le bouton droit et sélectionner **Désinstaller le périph

Appuyez sur **Action → Analyser les changements de hardware**. A ce stade, vous devriez pouvoir saisir à nouveau. Vérifiez dans Zadig que les périphériques utilisent bien le pilote `HidUsb`. Si c'est le cas, vous avez corrigé le problème, votre clavier devrait fonctionner à nouveau!
Appuyez sur **Action → Analyser les changements de hardware**. A ce stade, vous devriez pouvoir saisir à nouveau. Vérifiez dans Zadig que les périphériques utilisent bien le pilote `HidUsb`. Si c'est le cas, vous avez corrigé le problème, votre clavier devrait fonctionner à nouveau!
@@ -20,7 +20,7 @@ Veuillez noter que lancer `make` avec `sudo` est généralement une **mauvaise**
### Règles `udev` pour Linux
Sous Linux, vous aurez besoin des permissions appropriées pour accéder au MCU (le micro-contrôleur). Vous avez le choix d'utiliser `sudo` en flashant le firmware, ou placer ces fichiers dans `/etc/udev/rules.d`. Une fois ajouté, lancez les commandes suivantes:
Sous Linux, vous aurez besoin des permissions appropriées pour accéder au MCU (le micro-contrôleur). Vous avez le choix d'utiliser `sudo` en flashant le firmware, ou placer ces fichiers dans `/etc/udev/rules.d`. Une fois ajouté, lancez les commandes suivantes:
@@ -6,13 +6,13 @@ Cette page détaille diverses questions fréquemment posées par les utilisateur
## `hid_listen` ne reconnaît pas de périphérique
Lorsque la console de débugage sur votre périphérique n'est pas prêt, vous obtiendrez un message similaire:
Lorsque la console de débugage sur votre périphérique n'est pas prêt, vous obtiendrez un message similaire:
```
Waiting for device:.........
```
Une fois le périphérique connecté, *hid_listen* le trouve et vous obtiendrez ce message:
Une fois le périphérique connecté, *hid_listen* le trouve et vous obtiendrez ce message:
```
Waiting for new device:.........................
@@ -61,7 +61,7 @@ Vous ne voulez probablement pas "briquer" votre clavier, rendre impossible d'éc
- Si votre map de clavier n'inclut pas de RESET, pour entrer en mode DFU, vous devrez appuyer sur le bouton reset du PCB. Cela implique que vous devrez certainement dévisser certaines pièces de votre clavier pour y accéder.
- Modifier les fichiers tmk_core / common peut rendre le clavier inutilisable
- Si un fichier .hex trop large est la cause du problème: `make dfu` supprime le bloc puis teste la taille (il ne fait pas les choses dans le bon ordre), ce qui provoque une erreur. En résultat, le flash n’aura pas été fait et le clavier restera en mode DFU.
- Si un fichier .hex trop large est la cause du problème: `make dfu` supprime le bloc puis teste la taille (il ne fait pas les choses dans le bon ordre), ce qui provoque une erreur. En résultat, le flash n’aura pas été fait et le clavier restera en mode DFU.
- Pour finir, notez que la taille maximale d'un fichier .hex sur un Plank est de 7000h (28672 decimal)
```
@@ -118,7 +118,7 @@ Sous Windows, activez l'option `Permettre au périphérique de sortir l'ordinate
Appuyer sur n'importe quelle touche en mode veille devrait sortir l'ordinateur de veille.
## Vous utilisez un Arduino?
## Vous utilisez un Arduino?
**Faites attention au fait que le nommage des pin d'un Arduino diffère de la puce**. Par exemple, la pin `D0` n'est pas `PD0`. Vérifiez le circuit avec la fiche technique.
@@ -44,7 +44,7 @@ Le premier n'est reconnu que sur macOS, alors que le dernier, `KC_SLEP` et `KC_W
## Modificateur "One Shot"
Cette fonctionnalité permet de corriger un problème avec la touche Shift. En effet, il arrive de saisir plusieurs majuscules en ne voulant en saisir qu'une sur un mot. Ex:`CEtte` à la place de `Cette`. La fonctionnalité «One shot» shift permet de corriger ça.
Cette fonctionnalité permet de corriger un problème avec la touche Shift. En effet, il arrive de saisir plusieurs majuscules en ne voulant en saisir qu'une sur un mot. Ex: `CEtte` à la place de `Cette`. La fonctionnalité «One shot» shift permet de corriger ça.
https://github.com/tmk/tmk_keyboard/issues/67
@@ -59,7 +59,7 @@ Pour les touches de modification et les actions de calque, vous devez placer `KC
## Support de touche à verrouillage mécanique
Cette fonctionnalité permet l'usage de *touches à verrouillage mécanique* comme [ces interrupteurs Alps](https://deskthority.net/wiki/Alps_SKCL_Lock). Vous pouvez l'activer en ajoutant ceci à votre `config.h`:
Cette fonctionnalité permet l'usage de *touches à verrouillage mécanique* comme [ces interrupteurs Alps](https://deskthority.net/wiki/Alps_SKCL_Lock). Vous pouvez l'activer en ajoutant ceci à votre `config.h`:
* [dfu-programmer](https://github.com/dfu-programmer/dfu-programmer) / `:dfu` avec QMK (outil en ligne de commande recommandé)
Ordre des actions:
Ordre des actions:
1. Pressez le keycode `RESET`, ou appuyez sur le bouton physique RESET ou alors créez un contact entre RST et GND.
2. Attendez que l'OS detecte l'appareil.
3. Éffacez la mémoire, cela peut être fait automatiquement.
4. Flasher le fichier .hex.
5. Redémarrez l'appareil en mode «application», cela peut être fait automatiquement.
5. Redémarrez l'appareil en mode «application», cela peut être fait automatiquement.
Alternativement:
Alternativement:
make <keyboard>:<keymap>:dfu
@@ -48,11 +48,11 @@ QMK a un fork du bootloader LUFA DFU qui vous permet de faire un simple scan de
#define QMK_LED E6
#define QMK_SPEAKER C6
Le fabricant et le nom du produit proviennent de vos définitions dans fichier `config.h`, et la chaîne de caractère «bootloader» est ajoutée au nom du produit.
Le fabricant et le nom du produit proviennent de vos définitions dans fichier `config.h`, et la chaîne de caractère «bootloader» est ajoutée au nom du produit.
Pour génerer le bootloader, utilisez la cible `bootloader`. Exemple:`make planck/rev4:default:bootloader`.
Pour génerer le bootloader, utilisez la cible `bootloader`. Exemple: `make planck/rev4:default:bootloader`.
Pour génerer un fichier .hex prêt pour la production qui contiendra tant l'application que le bootloader, utilisez la cible `production`. Exemple:`make planck/rev4:default:production`.
Pour génerer un fichier .hex prêt pour la production qui contiendra tant l'application que le bootloader, utilisez la cible `production`. Exemple: `make planck/rev4:default:production`.
### Commandes DFU
@@ -67,7 +67,7 @@ Il y a plusieurs commandes DFU que vous pouvez utiliser pour flasher le firmware
Les cartes arduinos et leurs clones utilisent le [bootloader Caterina](https://github.com/arduino/ArduinoCore-avr/tree/master/bootloaders/caterina) (tous les claviers utilisant un Pro Micro, ou un clone). Ils utilisent aussi le protocole avr109 pour communiquer en virtuellement en série (serial en anglais). Les bootloaders comme le [A-Star](https://www.pololu.com/docs/0J61/9) sont basés sur Caterina.
Pour vérifier la compatibilité avec un bootloader Caterina, vérifiez que ce bloc est présent dans votre fichier `rules.mk`:
Pour vérifier la compatibilité avec un bootloader Caterina, vérifiez que ce bloc est présent dans votre fichier `rules.mk`:
```make
# Bootloader selection
@@ -81,20 +81,20 @@ Pour vérifier la compatibilité avec un bootloader Caterina, vérifiez que ce b
1. Pressez la touche avec le keycode `RESET`, ou reliez les ports GND et RST. Vous n'avez que 7 secondes pour flasher une fois que l'opération a été faite.
2. Attendez que l'OS détecte l'appareil.
3. Flasher le fichier .hex.
4. Attendez que l'appareil redémarre automatiquement.
ou, utilisez:
ou, utilisez:
make <keyboard>:<keymap>:avrdude
@@ -111,7 +111,7 @@ Il existe un certain nombre de commandes DFU que vous pouvez utiliser pour mettr
Halfkay est un protocole ultra-simple développé par PJRC qui utilise HID et qui est fourni avec tous les Teensys après le modèle 2.0.
Pour vérifier la compatibilité avec le booloader Halfkay, vérifiez que ce bloc est présent dans votre fichier `rules.mk`:
Pour vérifier la compatibilité avec le booloader Halfkay, vérifiez que ce bloc est présent dans votre fichier `rules.mk`:
```make
# Bootloader selection
@@ -125,24 +125,24 @@ Pour vérifier la compatibilité avec le booloader Halfkay, vérifiez que ce blo
[Teensy Loader en ligne de commande](https://www.pjrc.com/teensy/loader_cli.html) (Outil en ligne de commande recommandé)
Séquence de flash:
Séquence de flash:
1. Pressez la touche du keycode `RESET`, ou reliez les ports RST et GND rapidement. Vous avez ensuite 7 secondes pour réaliser le flash.
2. Attendez que l'OS détecte l'appareil.
3. Flasher le fichier .hex.
4. Redémarrez l'appareil en mode «application». Cela peut être fait automatiquement.
4. Redémarrez l'appareil en mode «application». Cela peut être fait automatiquement.
## USBasploader
USBasploader est un bootloader développé par matrixstorm. Il est utilisé sur des processeurs AVR non-USB comme le ATmega328P, qui fonctionne grâce à V-USB.
Pour vérifier la compatibilité avec le booloader USBasploader, vérifiez que ce bloc est présent dans votre fichier `rules.mk`:
Pour vérifier la compatibilité avec le booloader USBasploader, vérifiez que ce bloc est présent dans votre fichier `rules.mk`:
```make
# Bootloader selection
@@ -156,24 +156,24 @@ Pour vérifier la compatibilité avec le booloader USBasploader, vérifiez que c
1. Pressez la touche du keycode `RESET`, ou reliez le port de boot pendant que RST et GND snt reliés. Cela doit être fait très rapidement.
2. Attendez que l'OS détecte l'appareil.
3. Flasher le fichier .hex.
4. Redémarrez l'appareil en mode «application». Cela peut être fait automatiquement.
4. Redémarrez l'appareil en mode «application». Cela peut être fait automatiquement.
## BootloadHID
BootloadHID est un bootloader pour les microcontrôleurs AVR. L'utilitaire de téleversement ne demande pas de drivers au niveau du kernel et peut être lancé sans installer aucune DLLs.
Pour vérifier la compatibilité avec le bootloader bootloadHID, vérifiez que ce bloc existe dans votre fichier `rules.mk` :
Pour vérifier la compatibilité avec le bootloader bootloadHID, vérifiez que ce bloc existe dans votre fichier `rules.mk` :
```make
# Bootloader selection
@@ -187,50 +187,50 @@ Pour vérifier la compatibilité avec le bootloader bootloadHID, vérifiez que c
BOOTLOADER= bootloadHID
```
Utilitaires de flash compatibles:
Utilitaires de flash compatibles:
* [HIDBootFlash](http://vusb.wikidot.com/project:hidbootflash) (Utilitaire avec interface graphique recommandé)
* [bootloadhid Command Line](https://www.obdev.at/products/vusb/bootloadhid.html) / `:BootloadHID` avec QMK (utilitaire en ligne de commande recommandé)
Séquence de flash
1. Entrez dans le bootloader en utilisant l'une de ces méthodes:
1. Entrez dans le bootloader en utilisant l'une de ces méthodes:
* Pressez la touche du keycode `RESET` (Cela ne fonctionnera pas sur certains appareils).
* Verrouillez la touche «Salt» tout en branchant le clavier (Généralement ce principe est documenté dans le fichier readme du clavier)
* Verrouillez la touche «Salt» tout en branchant le clavier (Généralement ce principe est documenté dans le fichier readme du clavier)
2. Attendez que l'OS détecte l'appareil.
3. Flasher le fichier .hex.
4. Redémarrez l'appareil en mode «application». Cela peut être fait automatiquement.
4. Redémarrez l'appareil en mode «application». Cela peut être fait automatiquement.
Ou alors:
Ou alors:
make <keyboard>:<keymap>:bootloadHID
## STM32
Tous les processeurs STM32 contiennent un bootloader installé en usine qui ne peut pas être modifié ou supprimé. Certains processeurs STM32 ont des bootloaders qui ne peuvent pas être programmés par USB (ex:STM32F103) mais le processus reste le même.
Tous les processeurs STM32 contiennent un bootloader installé en usine qui ne peut pas être modifié ou supprimé. Certains processeurs STM32 ont des bootloaders qui ne peuvent pas être programmés par USB (ex: STM32F103) mais le processus reste le même.
Pour le moment, aucune variable `BOOTLOADER` n'est nécessaire dans le fichier `rules.mk`.
* [dfu-util](https://github.com/Stefan-Schmidt/dfu-util) / `:dfu-util` (utilitaire en ligne de commande recommandé)
Séquence pour flasher:
1. Entrez dans le bootloader en utilisant l'une de ces méthodes:
1. Entrez dans le bootloader en utilisant l'une de ces méthodes:
* Utilisez une touche sur laquelle le keycode `RESET` (Cela peut ne pas fonctionner sur les appareils STM32F042)
* Si un circuit de réinitialisation (Reset) est présent alors utilisé le bouton qui lui est dédié.
* Autrement, vous devez réaliser une liaison entre BOOT0 et VCC (en appuyant sur le bouton ou à l'aide d'un pont) puis faire un pont entre RESET et GND et enfin relacher le pont BOOT0.
2. Attendre que l'os détecte l'appareil.
3. Flasher un fichier `.bin`.h
* Vous allez recevoir un avertissement à propos de la signature DFU. Ignorez-la.
4. Réinitialisez l'appareil en mode «application». Cela peut être fait automatiquement.
* Si vous êtes en train de travailler en ligne de commande, par exemple avec un `make planck/rev6:default:dfu-util` alors soyez bien sur que l'argument `:leave` est passé aux arguments DFU grâce à la variable `DFU_ARGS` à l'intérieur de votre fichier `rules.mk` (Ex:`DFU_ARGS = -d 0483:df11 -a 0 -s 0x08000000:leave`) afin que votre appareil redémarre après avoir été flashé.
4. Réinitialisez l'appareil en mode «application». Cela peut être fait automatiquement.
* Si vous êtes en train de travailler en ligne de commande, par exemple avec un `make planck/rev6:default:dfu-util` alors soyez bien sur que l'argument `:leave` est passé aux arguments DFU grâce à la variable `DFU_ARGS` à l'intérieur de votre fichier `rules.mk` (Ex: `DFU_ARGS = -d 0483:df11 -a 0 -s 0x08000000:leave`) afin que votre appareil redémarre après avoir été flashé.
### Commandes STM32
Il y a différentes commandes que vous pouvez utiliser pour flasher un firmware dans un appareil STM32:
Il y a différentes commandes que vous pouvez utiliser pour flasher un firmware dans un appareil STM32:
*`:dfu-util` - C'est l'option standard pour flasher un appareil STM32. Le script attendra qu'un bootloader STM32 soit présent.
*`:dfu-util-split-left` - Permet de flasher un firmware normalement, tout comme l'option précédente mais permet de configurer le côté gauche des paramètres EEPROM sur un clavier scindé.
@@ -88,7 +88,7 @@ Par exemple, si votre keymap s'appelle "xyverz" et que vous fabriquez une keymap
La commande va vérifier la configuration du clavier, puis tentera de le flasher en fonction du bootloader (chargeur d’amorçage) spécifié. Cela signifie que vous n'avez pas besoin de savoir quel bootloader votre clavier utilise. Exécutez simplement la commande et laissez-le faire le gros du travail.
Cependant, tout dépend du bootloader qui est installé sur le clavier. Si cette information n’est pas configurée ou si vous tentez de flasher un clavier qui ne permet pas d’être flashé alors vous obtiendrez cette erreur:
Cependant, tout dépend du bootloader qui est installé sur le clavier. Si cette information n’est pas configurée ou si vous tentez de flasher un clavier qui ne permet pas d’être flashé alors vous obtiendrez cette erreur:
WARNING: This board's bootloader is not specified or is not supported by the ":flash" target at this time.
@@ -326,7 +326,7 @@ Il y aun certain nombre de commandes du DFU que vous pouvez utiliser pour flash
### BootloadHID
Pour les claviers basés sur Bootmapper Client(BMC)/bootloadHID/ATmega32A, si vous êtes prêts à compiler et flasher le firmware, ouvrez votre fenêtre de terminal et lancez la commande suivante:
Pour les claviers basés sur Bootmapper Client(BMC)/bootloadHID/ATmega32A, si vous êtes prêts à compiler et flasher le firmware, ouvrez votre fenêtre de terminal et lancez la commande suivante:
make <my_keyboard>:<my_keymap>:bootloaderHID
@@ -351,7 +351,7 @@ Error opening HIDBoot device: The specified device was not found
Trying again in 5s.
```
Une fois ce résultat obtenu, réinitialisez le contrôleur. Le résultat suivant devrait s’afficher:
Une fois ce résultat obtenu, réinitialisez le contrôleur. Le résultat suivant devrait s’afficher:
@@ -24,7 +24,7 @@ The "easy" way to flash the firmware is using a tool from your host OS:
If you want to program via the command line you can uncomment the ['modifyvm'] lines in the Vagrantfile to enable the USB passthrough into Linux and then program using the command line tools like dfu-util/dfu-programmer or you can install the Teensy CLI version.
## Vagrantfile Overview
The development environment is configured to run the QMK Docker image, `qmkfm/base_container`. This not only ensures predictability between systems, it also mirrors the CI environment.
The development environment is configured to run the QMK Docker image, `qmkfm/qmk_cli`. This not only ensures predictability between systems, it also mirrors the CI environment.
@@ -113,7 +113,7 @@ Don't hold the iron on the solder/joint longer than necessary. Heat will be cond
#### Soldering the Diodes
Starting at the top-left switch, place the diode (with tweezers if you have them) on the switch so that the diode itself is vertically aligned, and the black line is facing toward you. The input lead of the diode should be touching the left contact on the switch, and the bent, output end should be facing to the right and resting on the switch there, like this:
Starting at the top-left switch, place the diode (with tweezers if you have them) on the switch so that the diode itself is vertically aligned, and the black line is facing toward you. Make sure the diodes are soldered in parallel (diode outputs shouldn't connect to diode inputs). The input lead of the diode should be touching the left contact on the switch, and the bent, output end should be facing to the right and resting on the switch there, like this:
@@ -6,26 +6,28 @@ If you have not yet you should read the [Keyboard Guidelines](hardware_keyboard_
## Adding Your AVR Keyboard to QMK
QMK has a number of features to simplify working with AVR keyboards. For most keyboards you don't have to write a single line of code. To get started, run the `util/new_keyboard.sh` script:
QMK has a number of features to simplify working with AVR keyboards. For most keyboards you don't have to write a single line of code. To get started, run `qmk new-keyboard`:
```
$ ./util/new_keyboard.sh
Generating a new QMK keyboard directory
$ qmk new-keyboard
Ψ Generating a new QMK keyboard directory
Keyboard Name: mycoolkb
Keyboard Type [avr]:
Your Name [John Smith]:
Keyboard Name: mycoolkeeb
Keyboard Type:
1. avr
2. ps2avrgb
Please enter your choice: [1]
Your Name: [John Smith]
Ψ Copying base template files...
Ψ Copying avr template files...
Ψ Renaming keyboard.[ch] to mycoolkeeb.[ch]...
Ψ Replacing %YEAR% with 2021...
Ψ Replacing %KEYBOARD% with mycoolkeeb...
Ψ Replacing %YOUR_NAME% with John Smith...
Copying base template files... done
Copying avr template files... done
Renaming keyboard files... done
Replacing %KEYBOARD% with mycoolkb... done
Replacing %YOUR_NAME% with John Smith... done
Created a new keyboard called mycoolkb.
To start working on things, cd into keyboards/mycoolkb,
or open the directory in your favourite text editor.
Ψ Created a new keyboard called mycoolkeeb.
Ψ To start working on things, `cd` into keyboards/mycoolkeeb,
Ψ or open the directory in your preferred text editor.
```
This will create all the files needed to support your new keyboard, and populate the settings with default values. Now you just need to customize it for your keyboard.
@@ -189,9 +189,9 @@ Hardware files (such as plates, cases, pcb) can be contributed to the [qmk.fm re
Given the amount of functionality that QMK exposes it's very easy to confuse new users. When putting together the default firmware for your keyboard we recommend limiting your enabled features and options to the minimal set needed to support your hardware. Recommendations for specific features follow.
### Bootmagic and Command
### Magic Keycodes and Command
[Bootmagic](feature_bootmagic.md) and [Command](feature_command.md) are two related features that allow a user to control their keyboard in non-obvious ways. We recommend you think long and hard about if you're going to enable either feature, and how you will expose this functionality. Keep in mind that users who want this functionality can enable it in their personal keymaps without affecting all the novice users who may be using your keyboard as their first programmable board.
[Magic Keycodes](keycodes_magic.md) and [Command](feature_command.md) are two related features that allow a user to control their keyboard in non-obvious ways. We recommend you think long and hard about if you're going to enable either feature, and how you will expose this functionality. Keep in mind that users who want this functionality can enable it in their personal keymaps without affecting all the novice users who may be using your keyboard as their first programmable board.
By far the most common problem new users encounter is accidentally triggering Bootmagic while they're plugging in their keyboard. They're holding the keyboard by the bottom, unknowingly pressing in alt and spacebar, and then they find that these keys have been swapped on them. We recommend leaving this feature disabled by default, but if you do turn it on consider setting `BOOTMAGIC_KEY_SALT` to a key that is hard to press while plugging your keyboard in.
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.