* Update how_keyboards_work.md
bridged the gap between scancodes and keycodes, the doc didn't make the distinction and was ambiguous.
* Update docs/how_keyboards_work.md
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Update docs/how_keyboards_work.md
fix typo
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* Update Layer functions to use layer_state_t in ZSA Boards
* Update Music Mask for ZSA boards
Fixes an issue with the board getting stuck on Adjust layer when activating music mode
* Add Support for SMART LED Toggle to Planck EZ
* Add support for SMART LED toggle in Ergodox EZ
* Ifdef swiss cheeze for Oryx Configurator
* Documentation and updates
* Add Oryx Keymap
* Add option to configure the layers for the Layer Indicator
* Update keymap with better examples
* Make sure eeprom is initialized before reading from it
* Force flush of LED matrix when suspending board
This fixes an issue where the LEDs don't fully clear sometimes when the host system goes to sleep
* Enable RGB Sleeping by default
* Add clarification about planck ez led layer config
* A little easier to read the definition of the GPIO control macro for AVR.
No change in build result.
* Changed to not use GNU statement expression extension.
No change in build result.
* Modified split_common/serial.c to use qmk_firmware standard GPIO control macro.
No change in build result.
* fix PE6 -> E6
* remove some space
* add some comment to config_common.h
* Changed split_common/serial.c to use a newer version of qmk_firmware standard GPIO control macro.
* Additional changes for Layer State typedef compatibility
* Replace biton32 with get_highest_layer in docs
* Change additional layer structure code
* Fix uGFX reference issue
* Remove dynamic_keymap check
* Where did all these extra spaces come from
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Add MAGIC_SWAP_CONTROL_LGUI and MAGIC_UNSWAP_CONTROL_LGUI keycodes
Key codes to swap and unswap the control and windows/cmd keys
* Fix issues with pull request #6110
Renamed swap/unswap lctl and lgui key codes, added key codes to swap/unswap rctl and rgui, and moved new bool inside keycode_config.h struct to the end
* Move new keycodes to the end of the enum (#6110)
* add cases for swapped control and OS keys to mod_config (#6110)
* Add new keycodes to feature_bootmagic.md (#6110)
* Add R+L swap codes to keep in parity with AG_* codes
* Extend Magic range check to include new magic codes
* Update audio docs
* Combine 2 byte ranges into 1 word for EECONFG
Fix names for Keymap config EEPROM
* Update docs/feature_bootmagic.md
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* Update docs/feature_bootmagic.md
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* Update docs/feature_bootmagic.md
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* Update docs/feature_bootmagic.md
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* Optimize RGB Matrix rendering for Ergodox EZ
* Optimize RGB Matrix rendering for Planck EZ
* Update keyboards/planck/ez/config.h
Co-Authored-By: Joel Challis <git@zvecr.com>
* Remove superfluous JTAG disable code
* 32A has differently named register
* Accidentally some operators
* 32A also has different JTAG pins
* Wrap disable_jtag() in an ifndef
* Document this new define
* Rename the define, it conflicts with a LUFA thing
Also, move the ifndef wrapping to the call in keyboard_setup()
* removed some debug prints
* removed unnecessary files, tweaked some things
* rotary encoder button now connected into column 0, row 3
* tweaked keymap and moved encoder control into keymap
* tweaks
* added test keymap
* updated some things to make it easier to work with QMK configurator
* updates after merging latest master in
* fixed a few things
* removed test keymap and all related #ifdefs
* changed some dumbpad default keys, added KC_LOCK
* added image to readme
* added link to PCB github repo
* moved lock key to the rotary encoder pushbutton
* making suggested changes from @fauxpark in https://github.com/qmk/qmk_firmware/pull/6452
* adding bootmagic lite since i'm lazy and haven't soldered on the reset button...
* renamed to
* using 7 underscores for KC_TRNS
* adding my layout (default is for wife)
* updated my own layout, tweaked default keymap to use cleaner switch for encoder control
* removed commented out import from imchipwood keymap, removed unnecessary comment from default layout
* added LED layer control
* flash the layer indicator LEDs at startup
* change layer_state_set_user to layer_state_set_kb
Co-Authored-By: Joel Challis <git@zvecr.com>
* in layer_state_set_kb, return layer_state_set_user
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* remove include of upper level config.h, add pragma once
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* changing default keymap slightly, added config.h for default layout
* change _delay_ms to wait_ms
* replaced locking numlock with numlock
* Update keyboards/dumbpad/dumbpad.c
change `keyboard_pre_init_user` to `keyboard_pre_init_kb`
Co-Authored-By: Joel Challis <git@zvecr.com>
* Update keyboards/dumbpad/dumbpad.c
adding `keyboard_pre_init_user()` to `keyboard_pre_init_kb()`
Co-Authored-By: Joel Challis <git@zvecr.com>
* fixed some comments about the layer key (MO to TT) and the SUB layer rotary encoder control
* Move default keymap's rules to keyboard level
* Concatenate the two sets of rules
This sets CONSOLE_ENABLE to no, which was being set at the keymap level.
* Wrap the USB Device Description in quotes
Some preventative maintenance. The firmware for the_ruler can't be compiled without this change if `CONSOLE_ENABLE = yes` because this string has a comma, which gets picked up as two arguments by the Command code, instead of one as it should be.
* Linting
- remove firmware size impacts
- remove trailing white space
- visual alignment of rules
* Use QMK's pre-loaded default rules for atmega32u4
* Update readme
- markdown formatting
- update Hardware Availability link (Maple Computing's site has disappeared)
- update Docs links
* Update header files to use #pragma once
* Add universal flash command
* Add bootloader info to I:C boards
* Add support for ATSAM
* Add messages for flash target
* Message cleanup
* Add USB ASP Flashing target
* Make usbasp target more universal
* Add phoney target for usbasp
* Clarify error message when bootloader isn't matched
* Fix Clueboard hotswap gen1 not compiling when LED Matrix is disabled
* Move keymap.json to default keymap folder
* Revert "Move keymap.json to default keymap folder"
This reverts commit 7f28df909d.
* Add an alternative method for keyboard discovery to speed up build
* Chain MAKEFLAGS for docker_build.sh
* Slight improvement to number of items sent to sort
* Remove debug line
* Fix line escape
* Added Bulbizarre keymap for the XD75
* Fixed no newline at the end of file
* Update keyboards/xd75/keymaps/bulbizarre/readme.md
Co-Authored-By: MechMerlin <30334081+mechmerlin@users.noreply.github.com>
* Update led status check
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Remove unnecessary define
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* remove led layer code
* enable PWM on STM32F303
* Unusable PWM code
* Updated PWM Stuff?
* PWM Semi-working
* Both LEDs working at the same time
* Update names
* Add led level functions
* Add LED levels and persistent settings
* Revert change due to issues with timing related code
* Review feedback and minor cleanup
* add Userspace and keymaps
* Adding keymaps for zeal60 and iris
* Created my own tap dance that toggles RGB Mode based on whether I toggled caps lock or not
* parent 578ed42a7f
author Seth Barberee <seth.barberee@gmail.com> 1565065903 -0500
committer Seth Barberee <seth.barberee@gmail.com> 1565065903 -0500
move to userspace
add zeal60
* update based on review
* move userspace to github name
* Add some defaults for ATmega32A to mcu_selection.mk
* Remove boilerplate from templates
* Relax INTERRUPT_CONTROL_ENDPOINT and PROGRAM_CMD
* Apply suggestions from code review
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Extend allowed range of tappable keycodes to include modifiers
* Get rid of the magic numbers altogether
* Remove some more magic numbers
* Extract LM() functionality from ACT_LAYER_TAP
* Use ACTION() macro everywhere
* Improve backlight PWM pin support
* I accidentally an equals sign
* Another typo
* Order by pin number
* Throw an error if backlight pin is C4 or C5 on 16/32U4
* Use else for clarity
* Minor alignment adjustments
* Add Kudox Keyboard profile.
* Modified info.json and image link on readme.
* Remove unnecessary codes.
* Set BootLoader caterina.
* Remove duplicated settings on rules.mk.
* Clean up config.h.
* Modified include header path.
* Modified info.json to adjust 4th row keys y position.
* Separate default keymap and my keymap.
* Modified RGB_LED_* settings on kudox/rev1/config.h.
* Add configurations for Kudox Game Keyboard rev1.
* Modified Kudox Game Keyboard readme and keymap.
* Remove unnecessary codes.
* Set BootLoader caterina.
* Remove wrong settings on rules.mk.
* Clean up config.h.
* Modified MATRIX_ROWS on kudox_game/rev1/config.h.
* Modified RGB_LED_NUM on kudox_game/rev1/config.h.
* new keymap for projectkb alice
* update documentation for resetting PCB
* actually need a grave key more than a tilde
* move DFU_ARGS to top level
* cleanup unused keycodes and others
* align with typical ergo layouts. move enter and keep function layer reachable
* Delete null key
`__` key in keymap.c doesn't actually exist on the physical hardware.
Removed key from keymap.c and removed its argument from the layout macro.
* Delete unused keycode aliases
* Replace layer index definitions with an enum
* Replace redundant numpad keycodes with native aliases
* Use native layer change keycodes instead of aliases
* Visually align the keycodes
It makes the keymap pretty.
* Correct Configurator layout data
* Clean up header files
- convert to pragma once include guard
- remove redundant definitions
- remove commented code blocks
* Delete LAYOUT_kc macro
Was copied from ergotravel; not valid for this keyboard.
* Consolidate rev1 rules.mk settings to keyboard level
Previous codebase enabled Backlight at keyboard level then disabled it at revision level.
* Delete unused rules
* Consolidate config.h settings from keymap level to keyboard level
* Modernize keyboard's config.h file
Aligns the keyboard-level config.h file more closely with the current QMK template for AVR keyboards.
* Added nearly perfect config for AMJ66, only missing top right key.
* Correct the layout macro
* Add layout mock-up to amj66.h
* Update and comment out the backlight definitions in config.h
The backlight pin was found to be D4, but there appears to be a bug in QMK that affects this keyboard.
Commenting out for now.
* Try to make a sensible default keymap
* Add testing keymap for FSund
Include the keymap that was being used for testing.
Don't forget to refactor this later into an actually useful keymap.
* Suggestions by fauxpark
- uncomment the backlight configuration
- fix the default keymap
- remove commented MCU rule
- specify the bootloader
- make mental note to not try to write code at 3:30 in the morning
* Add LAYOUT_66_ansi and LAYOUT_66_iso macros
- include QMK Configurator data
- enable Community Layout support
* Add comments about layout variants to amj66.h
* Add #define BACKLIGHT_ON_STATE 1
Partial fix for backlight breathing.
- Requires #5983 to fix fully (confirmed by FSund and fauxpark)
Co-Authored-By: fauxpark <fauxpark@gmail.com>
Co-Authored-By: Filip Sund <filip.sund@gmail.com>
* DEBOUNCING_DELAY -> DEBOUNCE
* Move AMJ66 files into new AMJKeyboard directory
* Correct Manufacturer in USB Device Descriptor
* Remove comment regarding source fork
* Correct the readme
* Update default keymap to match the details given in its readme
* White-space edit fsund_test keymap
Makes its formatting more consistent with other 66% keymaps. No logic changes.
* Linting info.json
Debug-style linting (one key object per line) and minor edits to key labels.
* Remove fsund_test keymap
* Add FSund as a maintainer in info.json
* removed some debug prints
* removed unnecessary files, tweaked some things
* rotary encoder button now connected into column 0, row 3
* tweaked keymap and moved encoder control into keymap
* tweaks
* added test keymap
* updated some things to make it easier to work with QMK configurator
* updates after merging latest master in
* fixed a few things
* removed test keymap and all related #ifdefs
* changed some dumbpad default keys, added KC_LOCK
* added image to readme
* added link to PCB github repo
* moved lock key to the rotary encoder pushbutton
* making suggested changes from @fauxpark in https://github.com/qmk/qmk_firmware/pull/6452
* adding bootmagic lite since i'm lazy and haven't soldered on the reset button...
* renamed to
* using 7 underscores for KC_TRNS
Currently OLED Dirver only supports LF (\n) character in a string to clear out the rest of the current line and advance to the next line for writing. This PR adds support for CR (\r) character as well to advance to the next line, however not clear out the rest of the current line. This is extremely useful when you want to display a multi-line logo using a single array without wiping out exiting lines and flagging the OLED as dirty unnecessarily.
* personal keymap for the planck with sounds
* need that minus and underscore where I can see them
* remove unused block
* some, shall we call them, minor changes?
* I don't think this is required anymore
* initial commit TGR Jane
* lighting support
* use the default keymap lifted from community layouts for LAYOUT_tkl_ansi
* add information regarding reset key, hardware supported, and hardware availability
* document that it supports v1.1 as well thanks to nickheller's confirmation
* update some verbage in the readme
* add QMK Configurator support
* establish switch matrix for three main layouts
* add community layout support
* readme fixes
* Update keyboards/tgr/jane/info.json
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/tgr/jane/rules.mk
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Update keyboards/tgr/jane/config.h
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update MODERN_DOLCH_RED color
* Remove unused RAL_LAL tap dance
* Disable Space Cadet on all boards
* Rework SEND_STRING_CLEAN into CLEAN_MODS, fix DST_P_R/DST_N_A
* Disable unnecessary underglow animations
* Rearrange feature flags in rules.mk files
* Change custom colors from structs to defines
* Add some explicit initializers
* Add MODERN_DOLCH_CYAN color
* Add IS_LAYER_ON_STATE()/IS_LAYER_OFF_STATE() macros
* Add led_set_keymap() template function
* Change underglow color based on Caps/Fn state
* Preserve val when changing underglow colors
* Only trigger Fn light for Fn layer
* Refactor fn_light() and caps_light() slightly
* Add comments to fn_light() and caps_light()
* Xulkal changes
Refactor rgb & encoder menu
Hadron Keymap
Refactor oled menu
* Fixing horizontal OLED data display
* Reverting changes to take to separate prs
* Add Sections and MO(layer)/TG(layer) Example
Major changes:
1. Added sub-section headings to the portion before the examples.
2. Added a new Example 6, that allows MO(layer) and TG(layer) functionality to be embedded within tap dance functions.
Minor Changes:
1. Edited some text to better fit with new sub-headings.
* Update feature_tap_dance.md
* Update feature_tap_dance.md
* basic layout v1.0
* changed KC_TRNS to _______
* most symbols are on double tap, except quote, that was cancer
* better formatting and set toggle for game layer
* added colors to layers to make knowing your current layer easy
* have an empty macro working
* enabled unicode
* moved stuff to my folder and removed edits from communal files
* cleanup
* removed the game layer. Never used it
* made changes requested by drashna and vomindoraan
* got rid of some unnecessary code
* got very basic unicode on mac working
* added ctrl_esc
* more changes as requested by noroadsleft
* more leader additions, removed macros because leader stuff replaces that functionality
* removed an old macro I forgot to remove earlier
* final deletion at noroadsleft request
* changed a line to explicitly specify a purple color.
* Fix my Tap Dance issues after I broke them
* Cleanup and organization of userspace documentation
As well as some additional cleanup of functions due to review of documentation.
* Enable Tapdance on Glow and remove more animations
* Revert to Eager PR debouncing
* Add better check for startup animation
* Move where RGB Matrix defines are listed
* Limit RGB Matrix max val
* Update keyboard for Iris Rev 3 conflicts
* Enable encoder support on planck ez
* Remove is_master check from corne\'s OLED code
* Overhaul OLED screens for my Corne
* One last removal
* Show RGB valu On both sides
* Updates for OLED display info
* Fix compile issues for rgb config
* Disabled Space Cadet for all drashna keymaps
* Fix OLED Screen configs
* Minor OLED Tweaks
* Revert some Iris changes
* Fix song include
* Handle MAKE macro for the Corne boards better
* Add super hacky-hack for eeconfig initialization
* Add audio support for Fractal since Elite Cs support it
* Add defines for keycode steps
* Add White layout
* Update Corne RGB info
* Add fun effects to layer indication for RGB Matrix enabled boards
* Use proper define for product name detection
* Update formatting
* Use custom timeout mechanism for OLED timeout
* Fix up OLED screen HSV code for new HSV structure
* Better handle turning off RGB Matrix when sleeping
* Disable MultiSplash Animation
* Change Iris back to using serial
* Why was RGB disabled?!?!?!
* Limit val in rgb_matrix_layer_helper function
* Remove EECONFIG setting for RGB matrix
* Basic Rev 2 implementation
* Updated LED defines and added Extra encoder support
* Fixed rgb pin assignment
* Physically accurate LED positions
* Single Color Band scrolling left to right effects
* Spirals, Pinwheels, and Documentation....Oh My!
* Spiral effect band thickness adjustments
* Fixing animation spin directions
* Full hand LED positions
* Basic Rev 2 implementation
Updated LED defines and added Extra encoder support
Fixed rgb pin assignment
Physically accurate LED positions
Full hand LED positions
Moving rev2 folder
* RGB Center Point LED position update
* Fixing led config commas
* Fixing led config commas
* fix enter key
* fix enter
* Small changes to default
* update default
* typo fix
* update default
* Fixing defines & led config, turned full hand & extra encoders into rules.mk feature
* Refactored rules.mk to have a post_rules.mk
* Forgot to offset the matrix to led map due to the edge led additions
* Updated LED flags and fixed my keymap
* Update keymap.c
include speed controls for RGB
* Fixing more rules.mk and adding keymap like encoders functionality
* Sol Rev 2 Implementation
* Minor fixes
* Keymap fixes
* Fix Colemak, add lock keys
* fix default keymap to not have Q in the 1 position.
* add tsangan hhkb layout
* add a tsangan default keymap
* clean up the default keymap
* add qmk configurator support for new layout
* [Layout] KBP V60 Type R ISO default
* Remove ifdef
* Apply suggestions from code review
@noroadsleft I've accepted your suggestions. Tried locally any everything works as expected.
Thanks again - this if my first keyboard and first time looking at/ using/ contributing to qmk so I appreciate the feedback 👍
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
info.json file had the wrong name for the JSON key; the macro that is normally named LAYOUT_all by convention is named LAYOUT_60_all on the Zeal60.
Bug flagged by drashna for flight505 on QMK Discord.
* Update snagpad.h
White-space changes only. Making this file easier to read.
* Update info.json
Refactor:
- add labels
- debug linting (one key object per line)
- reorder keys for LAYOUT_numpad_5x4 (fixes QMK Configurator assigning keys to incorrect positions)
* Update readme.md
Refactor to conform to QMK template.
Updated link to The Board Podcast (old link was Error 404).
* Refactor splittest to support multiple dev boards
* Refactor splittest to support multiple dev boards - revert change to number of RGB led
* Refactor splittest to support multiple dev boards - update docs
* Refactor splittest to support multiple dev boards - correct docs
* Refactor splittest to support multiple dev boards - update teensy master logic
* Update IS_COMMAND definition in templates to use MOD_MASK_SHIFT
* Update IS_COMMAND in docs
* Update IS_COMMAND default definition in tmk_core
* Update table in Command docs based on suggestion
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Add Configurator layout data for LAYOUT_hotswap
* Add LAYOUT_std60_split_num0
Requested by 李小安#9728 on QMK Discord.
Standard 60% ANSI layout for the alphanumeric region, with a split-0 Numpad.
Includes a sample keymap.
* Update Docs links on readme
* Change melody96.h to use #pragma once include guard
* Change config.h to use #pragma once include guard
* Add readme for default_std60_split_num0 keymap
* Update x11.h
The original json file that was given by the designer was incorrect. The Print Screen and Pause button is swapped.
* Update space65.c
Fixing the Caps Lock LED.
* Revert "Update space65.c"
This reverts commit 1f5de1abae.
* Remove the need to set NUM_OF_ENCODERS
Instead, calculate the size of the array, and use that instead
* Add hack for split common support
* Remove NUM_OF_ENCODERS from keyboard config
Can be reverted, if needed
* Update the :bootloader target to pass along correct hardware info
* Update make scripts to properly grab the settings (a big thanks to @yanfali)
* Remove LUFA debug warnings
* Initial conversion of vagrant to use qmkfm/base_container
* Fix vagrant when using docker provider
* Workaround for VirtualBox VM restarts
* Generalise Vagrant docs slightly and add FAQ
* Store backlight breathing state in EEPROM
* Reduce backlight_config.level from 6 bits to 4 (max 15 "on" levels)
* Error out if BACKLIGHT_LEVELS is > 15
* Remove mention of default backlight pin in rules.mk template
* Remove pointless comment
Zeroing out spd in eeconfig_init_quantum
Switched to block read & update
Update tmk_core/common/eeconfig.h
Co-Authored-By: Drashna Jaelre <drashna@live.com>
Fixing init compile error
Update eeconfig.c
Dead / Missing API cleanup
alignment
* Enable Mousekeys on Corne Keyboard by default
For Tessachka and Configurator support
* ENable for default image too
* Remove most of rules.mk for default keymap
* make sure rgblight is enabled by default
from default keymap
* Add out of bound check for Leader Key sequence array
* A shot at advanced C stuff for Leader Key optimization
* Revert most changes
* Change default back
* Include string.h if compiling for ARM
* Use sizeof instead of a number
* Align sendstring LUTs to 9 characters wide
* Replace 0 with XXXXXXX
* Use decimal 128 for LUT size
* Align heading comments
* Add ASCII table comments
* Add missing AltGr LUTs and adjust keycode LUTs accordingly
* Use pragma once
* Correct a couple more keycodes
* Capitalise "BÉPO"
* Also clean up the default tables
* Tidy up Belgian and Norman LUTs
* Add user-overridable callback for cancelling UCIS input
To clean up things from qk_ucis_start_user() for instance.
* restore lost newline to quantum/process_keycode/process_ucis.c
Co-Authored-By: shinmai <aapo.saaristo@gmail.com>
* Script to generate keymap.c from JSON file.
* Support for keymap.json
* Add a warning about the keymap.c getting overwritten.
* Fix keymap generating
* Install the python deps
* Flesh out more of the python environment
* Remove defunct json2keymap
* Style everything with yapf
* Polish up python support
* Hide json keymap.c into the .build dir
* Polish up qmk-compile-json
* Make milc work with positional arguments
* Fix a couple small things
* Fix some errors and make the CLI more understandable
* Make the qmk wrapper more robust
* Add basic QMK Doctor
* Clean up docstrings and flesh them out as needed
* remove unused compile_firmware() function
* Add support for XD004
Also applying the following suggested edits:
Add hardware availability link in readme
Co-Authored-By: Drashna Jaelre <drashna@live.com>
Enable lite bootmagic
Co-Authored-By: Drashna Jaelre <drashna@live.com>
Remove commented out MCU
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Add more ellaborate keymap
Correcting usage of tap_code_16 for modified key, thanks to @drashna
* Add information about bootloader type
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* 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.
* Added initial files for the Adron 3-key macro pad
* Refactor of "adron_pad" to "ivy", cleaned up the readme and removed un-needed keymap as well.
* Made suggested changes to commit for PR
* Removed unneeded define block from SUBPROJECT_rev1 as it is redundant (Thanks drashna ;) )
* Add missing TD_RSF_RCT tap dance
* Use standard QMK HSV and RGB structs, fix Godspeed colors
* Move PROGMEM after the type in RGB intervals
* Add MODERN_DOLCH_RED color, use it on KBD6X
* Use 255 instead of RGBLIGHT_LIMIT_VAL in color definitions
* Remove IS_COMMAND override on Whitefox
* Hightlight that sudo may be needed
Also added "dfu-programmer: no device present" in so that anyone searching for that particular error can hopefully find the page.
* Use new style of indicating a warning
* Indicate that the FAQ should be read instead of blindly using sudo
* Switch version incrementing to the command put together by @noroadsleft.
* Update util/travis_compiled_push.sh
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* added files for KeyHive Maypad
* updated maypad files and moved honeycomb inside keyhive dir
* fixed file paths, incorporated changes with fauxpark's suggestions, undid honeycomb move
* updated with fixes from PR
* added new lines to end of honeycomb files to fix compiling
* Updated info.json to match the macro name from maypad.h
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* reordered layout in info.json
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* removed KEYMAP from maypad.h
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* removed extraneous keymap files
* pulled qmk/master for honeycomb
* added ortho_5x4 and keymap cleanup
* matched identities in maypad.h
* added bootmagic functionality to maypad
* changed bootmagic to lite
* Clarify the rules.mk setup for Unicode
* code point
Co-Authored-By: Konstantin Đorđević <vomindoraan@gmail.com>
* Remove "your"
Co-Authored-By: Konstantin Đorđević <vomindoraan@gmail.com>
* Undo a line change
Co-Authored-By: Konstantin Đorđević <vomindoraan@gmail.com>
* dot the comma
Co-Authored-By: Konstantin Đorđević <vomindoraan@gmail.com>
* Update docs/feature_unicode.md
Co-Authored-By: Konstantin Đorđević <vomindoraan@gmail.com>
* added handwired keyboard wulkan
* added info.json for qmk configurator
* fixed spelling
* enum dont need to be assigned to zero
* removed cflag from readme
* updated rules.mk
* removed unneeded rows from config
* moved unicode to keymap conf
* fix adjust layer and comments for keymap
* Fix up GPIO macros
* Fix up send string macros
`string` arguments must not be parenthesized
* Fix up miscellaneous macros
* Make indentation uniform (4 spaces)
* Make #ifdef vs #if defined usage consistent
* Reorder standard includes
* Revert indentation changes as per review comments
* Revert #if defined(__AVR__) → #ifdef __AVR__ change
* Change 2 space indent to 4 spaces on a couple of lines
* Replace include guard with #pragma once
Using QUANTUM_LIB_SRC prevents the warning when multiple sources add the i2c_master.c file. Boards such as the Ergodox EZ Glow see this warning every time they compile because the board uses the file in general, and because the RGB LED Matrix requires it, as well.
* Add wasdat:konstantin keymap
TODO: Move it to layouts/
* Use HHKB arrow arrangement for mouse keys on KBD6X
* Move KC_APP from Ctrl to M on all boards
* Use RCT_RSF on Melody96
* Set TAP_HOLD_CAPS_DELAY to 50 in userspace
* Use RSF_RCT instead of RCT_RSF
* added iris rev 3 keymap
* stuff
* Update config.h
* Removed personal mapping folder so that I can branch it
* Added personal Iris keymap folder
* added enums, removed break after return, and removed line 3 of keymap.c
* removed process record function
* greenshadowmaker keymap for idobo xd75 massdrop
* remove uneeded config.h
* corrected format to match convention instead of xd75 where I accidentally started from
* fixed errors and added arrows bottom right to match my other layouts
* updated readme
* right arrow fix
* Update keyboards/idobo/keymaps/greenshadowmaker/keymap.c
removing unnecessary part, copied from different keymap
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* added suggested changes
* removed unneded elements
* updates to my iris keymap
* some rational updates to the keymap - let's see how this works
* updates to my iris keymap
* some rational updates to the keymap - let's see how this works
* add mouse keys and remove unused keys and some cleanup
* a little bit more cleanup
* actually enable mousekeys
* fix markdown lint complaints
* fix capitalization
* changes made per suggestions
* initial commit, copied from singa
* default 60_ansi LAYOUT implemented and tested workin
* add rgb underglow support bounded by ifdefs
* edit readme to provide information on reset procedure and on rgb underglow support
* improve the default keymap to have a second layer with function keys and even a RESET
* Add LAYOUT_all macro and discovered that split backspace uses an additional pin on the microcontroller
* fix up last line in readme
* Add QMK Configurator support
* Convert gh60.h to #pragma once include guard
* Lint gh60.h
This commit only changes white space.
* Convert info.json to debug linting
Making this file easier to read.
* Put the label keys first for LAYOUT_60_ansi
* Complete and correct key labels in info.json
* Duplicate LAYOUT as LAYOUT_all
Doing this for backwards compatibility. Has implications for user keymaps.
* Update LAYOUT_all to make sense
The original macro LAYOUT submitted for the GH60 gets a couple of things wrong:
- K49 is placed between Space and Right Alt, when it's actually the right half of a split Backspace
- K3C is assigned before K3D, when K3C is the 1u portion of a 1.75u/1u split Right Shift, and therefore K3D is actually to the left of K3C
The LAYOUT_all macro corrects these issues, but the LAYOUT macro is unchanged, so as to not break user keymaps that depend on it.
This commit also updates the default keymap to use the LAYOUT_all macro, and makes a minor change to the base layer to be more as a user would expect for the corresponding physical layout.
* Correct the layout data for the LAYOUT macro in info.json
Gives proper Configurator rendering.
* Modernize default keymap
Update the default keymap to use more modern QMK conventions.
* Modernize the LED management code
Update the LED management functions to use the GPIO functions, and clean up the led_set_kb() function.
* Update key labels in info.json for LAYOUT_60_ansi_split_rshift
Makes them consistent with the the rest of the file.
* Update Docs links in readme file
* Snowkuma's planck layout.
Heavily influenced by both Planck and SDOTHUMs layouts. I have tried to
implement a comfortable layout with a wide stagger and a minimal set of
key usage.
Still a work in progress, hope it is useful to others.
* Adds simple readme file and images of layout
* Removes unused experimental definitions
* Update readme.md
Adds images of layout to readme.
* Removes accidentally added test keymap .swn .swo .swp files
* Updates config.h replaces include guard
As suggested by @noroadsleft replaces the include guard (ifndef, define
and endif) with just `#pragma once`.
* Replaces two extra KC with inbuilt QMK equivalents
custom_keycodes.h
Replaces `___f___` with the equivalent QMK alias `_______` KC_TRNS
`___x___` with the equivalent QMK alias `XXXXXXX` KC_NO
Updates keymap.c to reflect the changes made.
* Changes keymap.c to include QMK_KEYBOARD_H
Replaces planck.h and action_layer.h includes with the single inclusion
of QMK_KEYBOARD_H which includes action_layer.h automatically.
* Update keyboards/planck/keymaps/snowkuma/keymap.c
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* Update keymap.c
removes unused Coleman key code from enum planck_keycodes
* Update keymap.c removes COLEMAK key code logic
* Initial keymapping
* Removed unneccessary config files
* Update readme.md
* Updated symbol locations, tap dance on parentheses for brackets.
* Update readme.md
* Fixed layout image inconsistencies
* More quality shift key layer control, swapped enter + shift enter
* Keyap tweaks and config cleanup
* Almost compiling, still has layout reference issues.
* Finally compiling. 2x2u layout (default, not mine) had nonexistent keys on it
* Super minor changes
* Ctrl+Bksp after first tap
* Changed bind so un/lock is explicit to work with remote un/locking
* Added keyboard passwords please don't hate me
* Changed backspace functionality and added em dash
* Changed to send_string because it's preferred for macros
* Minor fixes
* Removed global redefinition and fixed possible issue between 6KRO and NKRO
* Cleanup
* Layer names, password layer is OSL over toggle
* Hopefully now in QMK preferred format.
* Blank passwords.c
I realized with me excluding this it wouldn't compile - so adding a blank one.
* Fixed OSLs not cancelling after tapping term
* Matrix change.
KC_NO instead of repeating.
* Unneeded line.
Co-Authored-By: IsaacElenbaas <34344969+IsaacElenbaas@users.noreply.github.com>
* Fixed return statements to work with after-press functions
* External image host
* Removed image from github
* Removed unneccessary rules.mk lines and fixed tabbing
* Typos
* Fixes upon part arrival.
* Final changes and bug fixes
* Preventing KC_NO from waking monitors.
* Fix to rest of matrices
In response to https://github.com/evillemez/qmk_firmware/issues/1—the rest have the same problem.
The switch of k37 for k36 is just for consistency between that and the 2x2u.
* Workaround for #6214, minor changes, CRLF change in passwords because it won't leave my modified no matter what I do.
* Add Pulse 4k, a macropad by Maxr1998
* Some config tweaks
* Remove image note
* Add license headers
* Fix media keys
* Remove Play/pause again as it doesn't work on Linux
* Initial refactor of onekey to support multiple development boards
* Fixes to get teensy lc && 3.2 working
* Add pin tables
* Add caveats to Teensy boards
* Correct bootloader for Elite-C
* [Keyboard] Modernize the KMAC implementation
This brings the matrix implementation more in line with the current
default matrix code.
It also simplifies the implementation quite a bit.
* [Keyboard] Add layout support to KMAC
* Rename layout macros
The Instant60's info.json was updated in #6157. The intention seems to have been supporting Community Layouts, but that feature was not implemented. After checking that the layouts conform, rename the appropriate layout macros.
- rename LAYOUT_ansi as LAYOUT_60_ansi
- rename LAYOUT_tsangan as LAYOUT_60_tsangan_hhkb
- update `default` and `tsangan` keymaps
* Enable Community Layout support
Supported Community Layouts:
- 60_ansi (Instant60 ANSI version)
- 60_tsangan_hhkb (Instant60 Tsangan version)
* keymap simplification and fancy alt tab behaviour
* move symbols around and try ergo numbers
* mess with symbol positions
* f11 and f12 for volume control (for ease of remapping)
* slack unread navigation
* experiment with mods on home row
* mods on symbol layer
* dedicated tab left and tab right keys
* swap next and prev
* remove hold to shift on a and o
* revert to simpler keymap
* restore readme
* point to keymap image
* cmd + cmd -> cmd + ctrl
* expand readme
* slack unread channel navigation
* Update keyboards/planck/keymaps/callum/keymap.c
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* return true from cmd handling block
* [keyboard] TA-65 by maartenwut
Add ta65 to QMK with 4 layouts
* Simplify config.h
* Simplify keymap
* Update bootloader
- confirmed to be qmk-dfu by maartenwut
* Update keyboards/ta65/readme.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Review feedback
- fauxpark recommendations
- noroadsleft recommendations
* Repair info.json structure
JSON objects were not properly nested according to the QMK specification.
* Switch info.json to "debug linting"
So I can read the file more easily.
* Remove k2c and k31 from LAYOUT_tsangan
k2c was the Non-US Hash position, and k31 was the Non-US Backslash position, but this layout is intended for ANSI.
* Correct LAYOUT_tsangan data in info.json
* Update tsangan keymap to use updated LAYOUT_tsangan macro correctly
* Rename LAYOUT_tsangan to LAYOUT_ansi_tsangan
Increased clarity.
* Rename tsangan keymap as default_ansi_tsangan
Per QMK Keyboard Guidelines.
* Fix object ordering for ISO layouts in info.json
ISO Enter's object was out of sequence in both layouts.
* Rename ISO keymaps per QMK Keyboard Guidelines
- rename iso keymap as default_iso
- rename iso_tsangan keymap as default_iso_tsangan
* Add default_ansi keymap
For user reference.
* Enable Community Layout support
LAYOUT_ansi and LAYOUT_iso conform to the 65_ansi and 65_iso Community Layouts, respectively.
- rename LAYOUT_ansi to LAYOUT_65_ansi
- rename LAYOUT_iso to LAYOUT_65_iso
- update keymaps as appropriate
- add LAYOUTS rule to rules.mk
* Disambiguate key labels in info.json
* Remove trailing white space from info.json
* Update keyboards/ta65/keymaps/maartenwut/config.h
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Add omnikeyish keyboard support.
* remove out of date comment
* PCB Rev 1.1 moved Row5's pin to E6, because the teensy++ hangs an onboard LED off D6.
* Move string.h include to .c file
* Add pcb kicad link.
* Add info.json
* Move macro programming to numlock's keyposition, the most useless key on the post model M layout. Force numlock enabled on host at init time, so you're not stuck without a numpad (hopefully)
* Make the macro blink function toggle LEDs from their previous state.
* Use incorrect but code style compliant opening curly bracing style.
* Make PCB rev 1.1 the default Omnikeyish config, as the author has the only rev 1.0 boards that'll ever be.
* Fix silly spelling error in 3 defines
* First set of review changes.
* Layout macro and keymap defined using it.
* Layout macros for the northgate factory plates.
* minor rearrangements
* ALL the layouts.
* Forgot ultra-t in info.json
* fixed issue with LED indicators
corrected error in info.json
* fixed issue with led indictors
* added fix for key_count to info.json for westfoxtrot/aanzee
* fix to support config.qmk.fm correctly and remove unused key from matrix for westfoxtrot/aanzee
* fix for caps_lock led
* Update readme.md
* Fix breathing always on for soft PWM
* Remove reference to hardware PWM pins in BACKLIGHT_BREATHING description
Now, breathing will only be unsupported when Timers 1 and 3 are both used by Audio
* Document BACKLIGHT_ON_STATE and its purpose
* Move layout macros to revision folders
* Update Planck EZ layout macros
Planck EZ only supports one layout (centered 2u spacebar). Deleted all the other macros.
* Flesh out QMK Configurator support
Give each Planck revision its own info.json file.
* Readme updates
- give each revision its own readme
- add the Planck EZ to the main Planck readme
* Fix layout macro for Planck EZ
Previous matrix didn't compile because the electrical matrix defined a k3b location, which was unused by the physical arguments.
Drashna was kind enough to confirm the Planck EZ's matrix for me.
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Pretend the Planck EZ supports ortho_4x12 layout
The hardware doesn't, but doing so prevents CI errors because the default keymap uses LAYOUT_planck_grid.
Going to pretend LAYOUT_ortho_4x12 is a valid layout for the Planck EZ.
* Update Planck EZ's URL in info.json
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* added keyboard_layout_jopr
* making it compile
* #pragma once instead of #ifndef and #define
* renamed and added keymap
renamed old "default" to "modded_white", added new "default" that resembles an ISO 105-key layout
* reordered keyboards/jopr/info.json to match order o layout array
* implemented most suggestions
* fixed missing ;
* fixed bootloader setting for rules.mk
* adopted standard layout matrix naming convention
* "fixed" commented-out code in keymaps
* changes to keymap layers and LEDs
Turns out adding a layer for ROYA-modified keycodes is more trouble than it's worth and works better by just defining a ROYA key.
Also, LEDs were set up incorrectly.
Lastly, implemented SysReq-Warning LED.
* moved forced NumLock code
just in case either it or the CapsLock & ScrlLock update code wouldn't both work otherwise
* rearranged media keycodes
* replaced Shifted keycodes with basic ones
* Apply suggestions from code review
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* implemented suggestions by noroadsleft
* Apply suggestions from code review
Make ISO-Enter QMK Configurator-friendly
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* Update readme.md
* Update keyboards/jopr/info.json
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* moved keyboard to handwired folder
It was said that personal passion projects belong in there, even if they're not actually handwired
* Update readme.md
* added personal CTRL keymap
* added personal dz60rgb keymap
* enabled new rgb effect
* added space cadet shift
* media player track buttons now orange
* updated keymaps with rgb setting and visual HSV setting preview
* fixed source stuff?
* added support for underglow toggle (bugged to all hell)
* everything now behaves as expected when ti comes to RGB toggles, thank god
* removed ifdefs
* changed color of MAS_CRM
* uh, whitespace
* changed rgb positions and modifiers within RGB matrix thing for CTRL and DZ60RGB
* updated keymap to work kindof
* KEYMAP: changed list of rgb effects
* changed CTRL rgb defaults
* KEYMAP: new LED layout for ctrl
* fixed white LED position in indicator
* changed capslock tap timing
* Fix backlight breathing on C6
* Account for ATmega32A's single TIMSK register (MT40)
* Document hardware PWM on D4 for ATmega32A
* Add C6 and D4 to BACKLIGHT_PIN description
* new keymap for the hasu with media keys and mac layout
* switch escape and grave
* switch to the usual default
* with play and stop
* add reset on fn layer
* add mouse buttons, move reset, update copyright
* changes to keymaps
* changes to userspace
* changes to userspace
* removed reference to fc660c keymap which no longer exists from userspace readme
* removed preonic keymap
* Fix typo for RGBLIGHT config values
It doesn't make a difference right now since these are the defaults in
rgblight.h (which I'm just setting explicitly since some of the keyboard
configs change these defaults). However, I'd rather be explicit, so
fixing my typo. :)
* Remove mouse keys layer from Quefrency keymap
It's a fun idea, but I never use it in practice.
* Planck: layout macro refactor
Unified layout macro names across AVR and ARM boards.
Currently certain layout macros are specific to either AVR or ARM when used in the QMK Configurator. If an AVR-specific macro is used for a Planck rev. 6, or an ARM-specific macro on a rev. 5 or earlier, the user receives a compile error.
* Update keyboards/planck/planck.h per @drashna
Changed KC_LAYOUT_ortho_4x12 alias to LAYOUT_kc_ortho_4x12.
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* Add KC_KEYMAP alias for LAYOUT_kc macro
per @drashna
Update keyboards/planck/planck.h
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* Fix LAYOUT_planck_1x2uC macro for Planck rev6
Thanks to drashna for testing.
* Fix inline comment regarding revisions
* Add specific info.json file for Planck rev6
* Adding led support for Plaid
* Adding led support for Plaid
* Update readme.md
Fixing bad markdown
* Adding my personal keymap
* Clarifying LED instructions / formatting
* modify oled_driver to support SH1106
also:
- improve mechanism to specify which OLED IC we use
- comment calc_bounds()
- give OLED_COLUMN_OFFSET a default value
- inline comment re: OLED MEMORY_MODE and SH1106
- update docs/feature_oled_driver.h for SH1106 support and related changes
- docs: OLED: note we have tested SSD1306 on ARM boards (per @XScorpion2)
- define out MEMORY_MODE when using SH1106 OLED driver
* document that SSD1306 128x64 on AVR works
Per @XScorpion2: https://github.com/qmk/qmk_firmware/pull/5787#discussion_r291837842
* Add vlukash CrKbd keymap to support trackpad adapter.
The trackpad adapter uses Elite-C board that has five extra pins.
Also SPI pins are taken for trackpad, keymap config updates column data
pins for matrix scan.
* Update vlukash keymap
* Enable pointing devide, configure mouse BTN1
* Set TAPPING_TERM to 300
* Add support for the BlackBerry 8520 trackpad
* Add vlukash keymap for master-right no-trackpad version
* Remap backspace
* Set EXTRAKEY_ENABLE = yes
* Update thumb keys mappings
* Set bootloader to atmel-dfu
* Sync keymap
* Add scrolling support
* Make debug LEDS conditional
* Add support for both flex and no-flex PCBs
* Add readme and rename root folders
* Update readme file with blog link
* Fix readme file formatting
* Remove ADJUST keycode, code cleanup.
* Add Win key to the keymap.
* add calbatr0ss dz60 layout
* add media controls
* add media next/prev controls
* add base layer for windows and macos
* swap right ctrl and menu
* missing bracket
* update gitignore
* niu_mini uses dfu bootloader rather than the afrdude bootloader
modified: readme.md
* Change rules in rules.mk to reflect the bootloader change
modified: keyboards/niu_mini/rules.mk
* Add 60_ansi_split_bs_rshift layout to DZ60
I know there's already a lot of DZ60 layout macros, and #4668 suggests
they should be refactored at some point, but since this is one of the
standard layouts already in QMK that this PCB supports, I figured it was
okay to add so that DZ60 keyboards can share this layout with other
keyboards.
* New 60% ANSI split backspace/right-shift layout
I'm using this on a DZ60, but it should work fine on most 60% PCBs. It's
basically a HHKB layout with a standard ANSI bottom row (3x 1.25U mods,
6.25U spacebar, 4x 1.25U mods).
* martenwuut's original code commit
* delete random directory that is the same as the parent directory
* get this compiling
* update readmes
* add manufacturer
* fix up the keymap error and replace KC_A with KC_1
* add verc support which is basically just at trimmed down verb
* update keymap readme to specify which redscarf it is
* add parent level readme
* fix grammar
* fix up readmes and put in alternative name for PCBs
* add configurator support for the ver.c pcb
* add configurator support for Ver.B (RS78) pcb
* add iso support for Ver.C (RS68)
* change DEBOUNCING_DELAY to just DEBOUNCE
* remove K2C to fit the default layouts
* fix keymap
* fixup configurator layout with split backspace
A delay of 10ms seems sufficient. Otherwise, media keys tapped from the
encoder of my BDN9 macropad only seem to get picked up by the OS
(Windows 10) some of the time.
* Candybar: updated rules.mk
Disabled console and command to get compiled size under flash space limitations.
* Candybar: Enable LINK_TIME_OPTIMIZATION_ENABLE
* [Keymap] iris@nstickney: improve RGB init
Perfecting the rgb backlight initialization with a delay for each
color; also start and stop the animation at the "default layer"
color.
* [Keymap] iris,ergodox@nstickney fix FN on SYMB
The function key was not operational on the SYMB and SYSH layers due
to other keycodes being mapped over MO() on those layers. The
offending keycodes have been moved to other keys.
* [Keymap] add @nstickney's userspace
Pulled common code out to a userspace directory for my iris and
ergodox keymaps.
* [Keymap] iris@nstickney add image to README
Added an image from keyboard-layout-editor.com to meet the README
standard.
* iris@nstickney hue values now `uint8_t` (#6050)
* Remove all Copyrighted Sounds and Songs
This removes any song that has a license/copyright on them.
Additionally, it adds the license information for any song that remains.
* Add removed song list
Can be reverted if we'd rather do that
* Use newer coding conventions
* Fix typo
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* Revert copyright date
* Update quantum/audio/song_list.h
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* faq_general.md to Chinese
faq_general.md to Chinese
faq finished
* custom_quantum_functions.md to Chinese
custom_quantum_functions.md to Chinese
* custom_quantum_functions.md fix
custom_quantum_functions.md fix
* custom_quantum_functions.md fix translate
custom_quantum_functions.md fix translate
* !ver.English! _summary.md bug fix
_summary.md bug fix of English doc. add".md" behind "feature_combo"
* !ver.English! custom_quantum_functions.md fix#5869
custom_quantum_functions.md in English : delete redundant "is" . issue#5869
* !ver.English! how_keyboards_work.md link fix
change
https://en.wikipedia.org/wiki/Unicode_input#Hexadecimal_code_input
to
https://en.wikipedia.org/wiki/Unicode_input#Hexadecimal_input
"#Hexadecimal_code_input" not exist
* !English! how_keyboards_work.md add missing "t"
Tied to a specific OS a a time (need recompilation when changing OS);
change to
Tied to a specific OS at a time (need recompilation when changing OS);
* _summary.md improve translation
_summary.md improve translation
* reference_glossary.md into Chinese
reference_glossary.md into Chinese
术语表翻译,这个术语表英文版似乎不太全,应该补充英文版,并在中文版添加其他具有中国特色的术语。
* Dimple: fix unintended LED behaviour
The LED was always-on if the custom keymap did not call dimple_led_off()
at least once.
* Dimple: LED code fixup
* correct indicator light states.
function of indicator lights was inverted. these changes correct that.
* flesh out keymaps pre production
* Enable extrakey in rules
* 8-Pack Macropad
* Added MANUFACTUTER to config.h
* Fix the mirrored keymaps by creating rev1.1 and rev1.2 layouts, then using them in the keymaps
* fixes from code review comments
* Use revisions to manage the different layouts for rev1.1 and rev1.2
* Add DEFAULT_FOLDER to fix default build failures
* code review comments fixes
* code review comments fixes
I2C timing parameters were seemingly set up for an STM32F303 target MCU, at a specific clock speed. This commit allows specifying the timing parameters via config.h, allowing other STM32 MCUs to be targeted, potentially at different clock frequencies.
Alternate function modes for the I2C pins are now also configurable, allowing for remapping to other pins.
* Generate project, fill in the details
* Repair json
* Separate keymaps to numpad and all-1U
* Apply suggestions from code review
Co-Authored-By: Elliot Powell <32494740+e11i0t23@users.noreply.github.com>
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Begin work
* Make things a tad easier to read
* Fix spacing
* Get things compiling
* Build a variety of generic keymaps
* Correct RGB pin
* Add configurator json
* Apply suggestions from code review
Co-Authored-By: Elliot Powell <32494740+e11i0t23@users.noreply.github.com>
Co-Authored-By: MechMerlin <30334081+mechmerlin@users.noreply.github.com>
* Remove JJ50 data from YMD96
JJ50 was actually added as its own keyboard when this was added in #2546. It should have been taken out then, but wasn't.
* Update ymd96.h
- use #pragma once include guard
- remove redundant file includes
* Update LAYOUT_iso macro to K<row><col> notation
* Update LAYOUT_custom macro to K<row><col> notation
* Update LAYOUT_default macro to K<row><col> notation
* Refactor default keymap
* Rename readme file to lowercase
* Rename layers enum and default layer
- renamed layers enum to layer_names
- proposed by fauxpark in Issue 5977, and I like the idea
- https://github.com/qmk/qmk_firmware/issues/5977#issuecomment-495924338
- renamed the base layer to _DEFAULT
- I think it looks nicer.
* initial commit
* remove mentions of oe and replace with le
* add new layout macros with the spacebar change
* add rgb underglow support
* Update keyboards/exclusive/e6v2/le_bmc/rules.mk
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update keyboards/exclusive/e6v2/le_bmc/readme.md
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* belgian layout had no sendstring definition
* backtick was not defined for belgian sendstring
* slash definition was wrong for belgian sendstring
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* use BE_ keys whenever we can
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* ^ can be sent as a normal key (not a dead key) with altgr+para
* changed rgb positions and modifiers within RGB matrix thing for CTRL and DZ60RGB
* changed CTRL corner LEDs + centered horizontally
* whoops - changed CTRL's underglow LEDs back to the underglow flag
* whitespace
* I changed the right file this time
* Fixed DZ60RGB left shift out of position
* Expand info.json formatting to one line per key
This is a white-space-only change. Make it easier for me to read the file.
* Make sure every key object has a label
Going to be using them shortly.
* Insert key identifiers from v1.h into info.json labels
Shows where each key is located in the switch matrix.
* Move K5O to its correct location on the top row
* Adjust white space in v1.h
At this point, the macros for LAYOUT and LAYOUT_75_ansi are 100% identical, except for their names.
* Redefine LAYOUT_75_ansi as an alias of LAYOUT
No need for two code blocks with the same data.
* Correct visual positioning in info.json
- move Pause 1u to the right
- move K5O to the top row, between Print Screen and Pause
- move Enter key 1u to the left and 1u wider (1.25u to 2.25u)
* Delete key identifiers from info.json labels
Don't need them anymore now that we know where everything is.
I'm calling K5O as ScrLk so it has a label, even though that's not actually what it is.
Also gave the Spacebar a label because I prefer when all the keys have labels.
* Enable 75_ansi Community Layout support
* Reassign layout macro as LAYOUT_75_ansi and delete macro alias
Configure the codebase so LAYOUT_75_ansi is the only layout macro available.
* Add key_count key to info.json data
* added personal CTRL keymap
* added personal dz60rgb keymap
* enabled new rgb effect
* added space cadet shift
* media player track buttons now orange
* updated keymaps with rgb setting and visual HSV setting preview
* fixed source stuff?
* added support for underglow toggle (bugged to all hell)
* everything now behaves as expected when ti comes to RGB toggles, thank god
* removed ifdefs
* changed color of MAS_CRM
* uh, whitespace
* changed rgb positions and modifiers within RGB matrix thing for CTRL and DZ60RGB
* updated keymap to work kindof
* KEYMAP: changed list of rgb effects
* changed CTRL rgb defaults
* KEYMAP: new LED layout for ctrl
* adds spacetime keyboard
* removes custom tap and mod functions
this commit replaces tap_key, control_key and shift_key with built-in
tap_code16.
* changes thumb layer and makes left palm key ralt
* Add support for LSJ Ares
Thanks to the other ports which have made this port possible.
* Update Ares code per request
* More changes to Ares
* Update Ares rules.mk
Co-Authored-By: Maartenwut <maartenwut@gmail.com>
* Remove escaping backslashes from Ares default keymap
* mostly done with first version of Ellipse Rev1 software
* mostly done, error with backlight breathing
* more testing and changing default keymaps
* ready for first release attempt
* fix newline in readme
* fix copyright and extraneous declarations and symbols
* remove more excess backslashes
* fixed more formatting
* feat-user-kuatsure: abstract symbol row out
* feat-user-kuatsure: abstract grouped bracket, brace, paren out
* fix-preonic-kuatsure: remove eol as requested by @drashna
* feat-user-kuatsure: add KC_MAKE and KC_FLSH
thanks to @drashna for the help
* chore-preonic-kuatsure: remove auto shift
* chore-user-kuatsure: move leader seq's to macro syntax
* feat-user-kuatsure: add `KC_VRSN` key
plus use it preonic keymap
* chore-user-kuatsure: namespace keyboard macros `KB`
* chore-preonic-kuatsure: move some keyboardy keys around
* chore-preonic-kuatsure: remove parens, brackets, braces from lower
* chore-user-kuatsure: move tmux window shifts to dbl press leaders
* feat-user-kuatsure: add a computer lock leader seq
* fix-preonic-kuatsure: go back to lower brackets
* chore-preonic-kuatsure: clear out raise
* feat-various-kuatsure: add meh + tab mod tap
* chore-preonic-kuatsure: `raise` eats `game_mod` layer
* fix-preonic-kuatsure: reverse pg up and pg down
* chore-user-kuatsure: add double tap to turn off music
* chore-user-kuatsure: move like seqs together
* chore-preonic-kuatsure: add a few more items to the num pad on raise
* feat-user-kuatsure: re-enable td for <> keys
* chore-user-kuatsure: give a little more grace period for leader
* fix-user-kuatsure: give lock leader a gui buffer
no timer or anything, but alfred doesn't boot up as quickly as I would like sometimes
gui doesn't do anything but gives a little bit of a time bump
* fix-user-kuatsure: changes from @drashna review
* Switch Quefrency from flaky I2C back to serial
* Lower mouse wheel speed on Quefrency slightly
* Migrate common settings to userspace
* Enable Bootmagic Lite for consistent reset to bootloader.
* Turn off some undesired features across all keyboards.
* Remove EEPROM reset keybinding from all keyboards since Bootmagic Lite
also does an EEPROM reset.
* Set backlight and underglow increments consistently across all
keyboards since lots of them like to override the deafults.
* Set mouse keys consistently across all keyboards.
* Update function layer keymap images
* translate docs into Mandarin Chinese
translate
faq_debug.md
into Chinese
* translate faq_build.md into Chinese
translate faq_build.md into Chinese
* faq_keymap.md to zh-cn
faq_keymap.md to zh-cn
* Added customisations and README
* Tweak keymap: word traversal/deletion
* Add w and b word traversal/deletion keycodes.
* Add fine volume control key codes, but don't use them, because they
conflict with other key codes. `A` somehow got remapped to fine
volume up.
* Set mousekey delay to zero
* Use SAFE_RANGE for key codes.
* Update keymap and README
Add new mouse-specific layer 3, activated by pressing and holding space.
Add brightness controls to layer 4 (previously, layer 3).
Update README:
* New keyboard-layout mockup image.
* Add actual link to kbdfans.cn.
* Update layer descriptions.
* Fix indentation in keymap.c
* Use _______ over KC_TRNS to increase readability
* Custom keys: use #define over process_record_user
* Use enum for naming layers
* Rename README.md -> readme.md
* Keep ASCII art consistent with keymap
* Possible fix for xyverz ortho keymap: define RGBLED_NUM
* Update DZ60 keymap; TODO store old keymap under different directory?
* Change RGUI to RALT because 7u spacebar is too long
* Save old bottom row keymap
* Update Iris keymap: replace backslash with grv
* Add ortho_4x12 layout
* Added Delete key to Iris keymap
* Move delete key
* Oh look a new keyboard
* ortho4x12: get an adjust layer back
* Remove jj40 keymap, add custom power draw #define
* Set WhiteFox to advertise only 100mA of power draw
* Update WhiteFox keymap
* Update WF keymap (2)
* Remove lets_split keymap, update community krusli keymap
* Add #define for BACKLIGHT_LEVELS (unused)
* Update Whitefox keymap
* Add YD60 from auto-generated kbfirmware files
* Bring files up to speed with new standards
* Fix: KEYMAP -> LAYOUT
* Fix keymap differences (DZ60 -> YD60)
* Update keymap
* Update README
* Fix RShift position
* Specify that the port is for the YD60MQ variant
* Update keyboards/iris/keymaps/krusli/keymap.c
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Fix Iris and Let's Split keymaps
* Remove unused keymap file
* Use #include QMK_KEYBOARD_H
* Add atmel-dfu selection to yd60
* Rename dir to YD60MQ, update definitions
* Use new convenience macros/functions for led_set_user
* Use #pragma once
* Change all ?= to = in rules.mk
* Use pragma once for yd60mq.h
* Take out DZ60 and Iris changes
* Remove now-removed Iris folder
* Revert adding ortho_4x12
* Revert on xyverz ortho_4x12 keymap
* Undo deleting JJ40 keymap files
* Don't revert beyond upstream jj40 state
* Extra files from earlier commit is to be deleted
* Remove WhiteFox keymap not in upstream yet
* Re-add my Let's Split keymap
* Revert keymap changes
* Cleanup: indentation
* Update keyboards/yd60mq/rules.mk
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update keyboards/yd60mq/rules.mk
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Cleanup & move kb backlighting code to yd60mq.c
* Update README, rename to lowercase
* Update README: rename to lowercase
* Update README with links and picture of PCB
* Remove PREVENT_STUCK_MODIFIERS
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Set Quefrency bootloader correctly for Elite-C
* Update Quefrency layout to be more like HHKB
* Update KBD67 layout to be more like HHKB
* Add keymap for BDN9 macropad
* Keyboard: add treeadstone48
* rename layout defines
* Use of pragma once
* move common include code
* fixed info.json
* change keymap layout from kc to normal
* fix alpha revision keymap
* fixed info.json
* remove USE_Link_Time_Optimization
* Add center sprit keymap for nomu30
* Re-enable Audio
And there was much rejoicingmake keebio/iris/rev2:drashna AUDIO_ENABLE=yes!
* Re-add debounce to ergodox EZ
* Fix rgb matrix helper function
* Make sure that RGM Matrix is checked properly
* Fix merge commit?
* Disable more RGB matrix modes
* Increase Debounce for Ergodox EZ
The performance improvements have made it necessary, actually
* Consolidate RGB Matrix layer indication function
And changes to iris
* Fix lighting issue for gamepad
* Update Corne Keyboard configuration
* Update Corne Keyboard layout
* Update KC_MAKE macro to better handle crkbd split
* Tweaks to Corne Keyboard Layout
* Enable RGB Matrix Sleep
* Update my code to use layer_state_t typedef
* rename bmc due to confusion as the bmc from r2 is different
* update readme
* Update keyboards/exclusive/e6v2/readme.md
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* use pragma once
* remove custom matrix
* remove custom i2c code in favor of QMK's i2c_master
* rename to all lower case readme
* update readme
* turn off bootmagic as it doesn't work anyway
* Update keyboards/pearl/readme.md
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* Adding an AUDIO_CLICKY_DELAY_DURATION configurable value to the AUDIO_CLICKY feature.
* Tweaking my community keymap to work better with my rev 4 planck.
* Typedef'ed layer_state_t to uint32_t.
This enables future work with layer_state_t to uint8_t for optimization purposes.
* Removed accidental xeal60 commit
* Revert to egyptian brackets, added sizeof(layer_state_t) so when layer_state_t is redefined it will automagically work.
* Add additional typedefs
* Add checks for setting layer state
* Update tmk_core/common/action_layer.h
Co-Authored-By: alex-ong <the.onga@gmail.com>
* Revert commit.
* adding my keymap for the KUMO
* edited the readme file
* edited some more files
* edited some more files
* edited files from feedback
* edited one more files from feedback
* edited rules
* fix the things the stupid script broke
* create an appropriate LAYOUT macro using LAYOUT_tkl_ansi
* create an appropriate keymap stolen from the phantom default keymap
* add correct pins used and rgb led numbers
* change vendor and device name
* add QMK Configurator support
* fix up RGB underglow
* update readme
* introduce new layout macro tkl_iso
* add QMK Configurator support for new layout macro
* enable backlight and add community layout support
* Increase delay for Hold-Tap register for CAPSLOCK
Because it seems that the 80ms delay wasn't too much
* Screw it, make the caps delay a define and make it configurable
* initial commit
* copy paste with some fixes the code from fox lab leaf60 repo
* add 60_ansi and 60_hhkb and community layout support
* add QMK Configurator support
* turn bootmagic to lite and turn on rgb and backlights
* disable some features so firmware isn't too big
* initial commit for hotswap leaf60
* add hotswap support
* edits for consistency
* add a generic leaf60 readme
* turn off console and command to save firmware space
* not enabling sleep led enable
* not enabling sleep led enable
* had one extra key in 60_hhkb
* get rid of limit val define
* Update keyboards/foxlab/leaf60/hotswap/readme.md
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/foxlab/leaf60/hotswap/rules.mk
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update keyboards/foxlab/leaf60/universal/rules.mk
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* add rgblight_set_effect_range()
* implement effect range
* Arrange the order of function list in rgblight.h .
* update docs/feature_rgblight.md
* fix RGBLIGHT_RAINBOW_SWIRL_RANGE default value
* add example code about Utility Functions
* add example code about direct operation functions
* When RGBLIGHT_SPLIT is defined, the following function has no meaning and is invalidated.
* rgblight_setrgb_master(r, g, b)
* rgblight_setrgb_slave(r, g, b)
* rgblight_sethsv_master(h, s, v)
* rgblight_sethsv_slave(h, s, v)
* add temporary test code for rgblight_set_effect_range
* fix rgblight_effect_knight() bug
* Test End. Revert "add temporary test code for rgblight_set_effect_range"
This reverts commit 5680cddd01.
This is a Neo2 inspired layout that is meant to be fully usable on
MacOS when used with the default US QWERTY/ABC Extended keymap.
Neo2 layers 1-4 have been almost fully implemented in hardware.
Layers 5 and 6 (greek and mathematical symbols) have been left
out for now as most of them aren't available on the default
keymaps.
Layer toggling for layer 3 on the right hand side utilizes a
tap-toggle approach that is a combination of MO & LT macros.
This is required to allow sending Y when tapped, @ when tapped
while the SHIFT modifier is active and support momentarily
toggling the layer while the key is held.
* trying to make my global keymap
* refactoring the old keymap using userspace
* getting there
* move readme and remove community layout
* use pragma once instead of ifndefs
* just make iris work
* iris decent
* better naming
* add some modifiers on the home row
* use symbol and sysctl layers
* fix up
* a bit faster
* add < and > on symbol layer
* apparently im not using z all that much..
* okok
* fix up stuff
* led init is back
* bring back led indicators
* Update keyboards/ergotravel/keymaps/pvinis/config.h
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* not needed
* not needed
* delete these for now, until I use the userspace code
* remove katamari from here. made a new pr for it
* lower case
* drashna suggestion :)
* move files to correct place
* fix missing command
* First publish of roguepullreqest programmer dvorak planck layout
* Removed junk line
* Update keyboards/planck/keymaps/roguepullrequest/keymap.c
Co-Authored-By: roguepullrequest <roguepullrequest@users.noreply.github.com>
* Update keyboards/planck/keymaps/roguepullrequest/keymap.c
Co-Authored-By: roguepullrequest <roguepullrequest@users.noreply.github.com>
* Update keyboards/planck/keymaps/roguepullrequest/keymap.c
Co-Authored-By: roguepullrequest <roguepullrequest@users.noreply.github.com>
* Update keyboards/planck/keymaps/roguepullrequest/keymap.c
Co-Authored-By: roguepullrequest <roguepullrequest@users.noreply.github.com>
* Removed layer songs
Removed layer songs for cleanliness. Will use them later.
* Update keyboards/planck/keymaps/roguepullrequest/readme.md
Co-Authored-By: roguepullrequest <roguepullrequest@users.noreply.github.com>
* Made basic LSHIFT framework but is not working. Listed other tapdances.
* Got LSHIFT to work
* Added working RSHIFT
* Added working TD_S
* Cleaned up LEFT and RIGHT [ { ] } on the UPPER layer.
* Cleaned up layout.
* Reenabled audio space is not needed right now.
* Added tap dances and layout image
* Started dactylmanuform layout
* Revert "Started dactylmanuform layout"
This reverts commit 5ef48e4a23.
* Started mousepad version of BDN9...wont compile for some reason.
* Fixed BDN9 mousepad layout
* Added readme.md to mousepad bdn9 layout.
* Updated readme.md for mousepad bdn9 layout.
Fixed the tables to finally work.
* Unslashed the mousepad keymap for the BDN9
* remove not need file
* set RGBLIGHT_SPLIT
* set RGBLIGHT by layer
* exchange LED color on layer
* Update keyboards/hecomi/alpha/rules.mk
I misunderstand RGBLIGHT_SPLIT
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Fix LAYOUT_60_iso_split_space_bs_rshift to match comments and Configurator
* Fix LAYOUT_60_iso_split_space_bs_rshift to match comments and Configurator
* Initial Zygomorph 5x6 code
Split is not working yet
* layout changes
implement 4 row config option (not done yet), remove layout comments in layout.c
* Zygomorph layouts for 5x12, 5x6, 4x12, and 4x6
Also, info.json *should* be nearly usable
for the configurator
* temporary fix for pin D5 being broken
* show D5 issue comment
* add build notes
* Pin B7 broken in split why?
* remove fix
* Fix some pin assignments
* begin to fix keymap
* Create new 5x6 layout
* update key positions
* Initial Zygomorph 5x6 code
Split is not working yet
* layout changes
implement 4 row config option (not done yet), remove layout comments in layout.c
* Zygomorph layouts for 5x12, 5x6, 4x12, and 4x6
Also, info.json *should* be nearly usable
for the configurator
* temporary fix for pin D5 being broken
* show D5 issue comment
* add build notes
* Pin B7 broken in split why?
* remove fix
* Fix some pin assignments
* begin to fix keymap
* Create new 5x6 layout
* Rough first pass at split common conversion.
Keymap cleanup to cover just the basics.
Broke OLED code out into separate example.
* Fix readme
* Removal of old encoder / oled driver, fix for layout macros
* small update
* xulkal zygomorph keymaps
* Removed the LED_MIRRORED option as leds are always mirrored on Zygomorph
* Xulkal keymaps update
* split rgb light support
* fix line endings
* Apply suggestions from code review
Co-Authored-By: zvecr <git@zvecr.com>
* More layout and compile fixes from pr review
* Cleaning up rules.mk files
* Apply suggestions from code review
Co-Authored-By: zvecr <git@zvecr.com>
* Updating defaults
* Apply suggestions from code review
Co-Authored-By: noroadsleft <18669334+noroadsleft@users.noreply.github.com>
* Added check for pressed to clear space cadet
* Found some docs to update
* Update docs/quantum_keycodes.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Changes from PR
* Fix white space on z150_blackheart.h
* Update z150_blackheart.h to use #pragma once include guard
* Update z150_blackheart.h to use QMK-preferred K<row><col> notation
* Add QMK Configurator support
* Refactor the keymaps
- refactor the keymaps into separate files for each layout macro
- give credit where credit is due
- white space update (four-space indent)
* Make Hardware Availability link in readme a rich text link
* Convert LED indicators to GPIO commands
* Elevate Indicator LED set-up and toggling to keyboard level
* project creation and config.h import
* fix name
* cleanup
* layout for left
* working left with feather pins
* full keymap
* ?
* let's do this
* non working twimaster version
* it fucking works!
* bluetooth!
* cleanup
* use auto output for ADAFRUIT_BLE
* remove auto from custom matrix
* better ble auto
* fix f1
* revert
* fix ble
* update readme
* Update readme.md
* Update readme.md
* translate newbs.md into Madarin Chinese
translate newbs.md into Madarin Chinese
* translate docs into Mandarin Chinese
translate getting_started_github.md into Mandarin Chinese
* translate getting_started_getting_help.md into Mandarin Chinese
translate getting_started_getting_help.md into Mandarin Chinese
* contributing.md to Chinese
Personify QMK as a girl named Q酱 . It can make more developer read this document and contribute QMK.
* getting_started_introduction.md to Chinese
getting_started_introduction.md to Chinese
* faq.md to Chinese
faq.md to Chinese
* crlf2lf getting_started_introduction.md
ending line fix getting_started_introduction.md
* crlf2lf contributing.md
crlf2lf contributing.md
* clean up rgb matrix extern usage
Moved rgb matrix boiler plate into macros
Rebased onto typing heatmap pr
* Fixing the reversed frame buffer access in digital rain
* Fixing digital rain & typing heatmap if keyreactive effects are not enabled
* Apply suggestions from code review
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Adding parenthesizes to DRIVER_LED_TOTAL where necessary
* Updated docs
* added notes about parentheses
* Improve Animation docs with example
- example to reduce flash footprint of animations using RGBLIGHT_EFFECT_ defines
* Re-order the effects list
* Update docs/feature_rgblight.md
Co-Authored-By: yanfali <yanfali@gmail.com>
* Update docs/feature_rgblight.md
Co-Authored-By: yanfali <yanfali@gmail.com>
* Update docs/feature_rgblight.md
Co-Authored-By: yanfali <yanfali@gmail.com>
* Introduce line breaks
* Add title for animation speed section
* Organize Animation Defines Into Groups
* Use the RGB EFFECT recommended by mtei in docs
- has the most modes, and STATIC_LIGHT can't really be disabled.
* Use more accurate titles for effects and animation
- accidentally put a toggle in settings
* Norman layout with Lower and Raise layers working
* Add keymap_extra def for Norman layout
* Re-org'ed the modifiers as explained in the Readme
* Corrected colour legend for KLE that the Readme links to
* Use #pragma once in header file
* Use pragma once and move user config to config.h
* Move definitions to the right file and correct link in Readme
* Move def of NM_COLN to the logical place in header file
* Add sendstring_norman.h for when the laptop layout is not QWERTY
* Update quantum/keymap_extras/sendstring_norman.h
Co-Authored-By: lehoff <torben.lehoff@gmail.com>
* initial commit and script error fixes
* add matrix and pin definitions along with LAYOUT macro
* add an appropriate keymap
* add num lock led support
* turn on bootmagic lite along with backlight led support
* add QMK Configurator support
* initial commit
* fix script issues
* define pins used and electrical matrix size and an appropriate LAYOUT macro
* add an appropriate keymap
* turn on bootmagic lite and backlight support
* Add QMK Configurator support
* add caps lock led support
* update readme with group buy links
* initial commit
* fixup script issues
* define pins used and create an appropriate LAYOUT macro
* create an appropriate keymap
* turn on backlight and bootmagic lite
* add QMK Configurator support
* fixup readme
* remove doubly defined KC_TRNS from keymap
* add support for Caps lock and Scroll lock LEDs
* Initial conversion of the rgb_led struct
* Converting last keyboard & updating effects to take advantage of the new structure
* New struct should not be const
* Updated docs
* Changing define ___ for no led to NO_LED
* Missed converting some keymap usages of the old struct layout
slave backlight was always on - as get_backlight_level() doesn't
indicate if the backlight is enabled or not.
also updated the corosponding code for serial transport to stop peeking
directly at 'internal' backlight_config structure.
* Disable a bunch of reactive modes
* Enable rgb matrix for Corne Keyboard
* Convert CRKBD to rgb matrix
* Add Gergo keyboard layout
* Make Diablo 3 tap dance better
* Add basic support for Planck EZ
* Fix RGB Matrix stuff
* Fix keycodes for Planck EZ
* Update CRKBD OLED stuff
* Fix typo for sleep on ergodox glow
* Improve my gergo layout
* Scrolling OLED key logger!
* Change gergo layout
* Hnadle unicode keycodes if unicode is disabled
* Disable COMMAND/CONSOLE for gergo
* Fix right side control
* Re-enable LTO for all platforms
Since I got updated arm gcc binaries that no longer error out on lto
* Update formatting to match newer community standards
Poor 2 space
* Re-alight startup animation to use new HUE range
* Streamline gitlab ci scripts
* Disabled Space Cadet
* Add support for breathing table
* Enable new LTO Option
And clean up defines that will now be repeatitive
* Remove vscode settings
* Additional formatting cleanup of config.h files
* Add FnLk to Melody96 bottom row
* Update conditional in userspace makefile
Thanks @drashna
* Add F keys to Melody96 Fn layer
* Add FN_ESC alias to userspace
* Update KBD6X keymap
* Fix RGB_MATRIX_ENABLE constant name in #if
* Remove trailing \ from LAYOUT macro calls
* Set RGB mode on EEPROM reset in KBD6X
* Swap right and middle mouse buttons in KBD6X
* Rearrange RGB controls in KBD6X
* Update keycode aliases, replace CLEAR with DEL_NXT in KBD6X
Add Clear to KBD6X as RCtrl+`
* Convert code to 4 space indents
* Tweak RCTRL layer functionality
* Replace NUMPAD custom keycode with layer state logic
* Update RGB_MATRIX_ENABLE check
Co-Authored-By: vomindoraan <vomindoraan@gmail.com>
* Re-fix Mousekey Movements
After the new movement model was instroduced, it broke diagonal momement, again. Reapplying fix from #3147 to both old and new acceleration method.
* Make diagonal mouse report checks more readable
Co-Authored-By: drashna <drashna@live.com>
* added personal CTRL keymap
* added personal dz60rgb keymap
* enabled new rgb effect
* added space cadet shift
* media player track buttons now orange
* updated keymaps with rgb setting and visual HSV setting preview
* fixed source stuff?
* added support for underglow toggle (bugged to all hell)
* everything now behaves as expected when ti comes to RGB toggles, thank god
* removed ifdefs
* changed color of MAS_CRM
* uh, whitespace
* fixed issue with LED indicators
corrected error in info.json
* fixed issue with led indictors
* added fix for key_count to info.json for westfoxtrot/aanzee
* fix to support config.qmk.fm correctly and remove unused key from matrix for westfoxtrot/aanzee
The code as originally listed didn't work for me, but replacing `unregister_code16(LALT(KC_TAB));` with `unregister_code(KC_LALT);` fixes the problem and causes the macro to work as intended.
Thanks to folks on Discord for helping me figure this out.
* docker_build.sh: Docker requires access to hosts devices
This also runs the container interactively which allows the user to
interupt the build with Ctrl-C.
* docker_build.sh: Mount /dev via $usb_args instead
* remove files that contributed to default hex file creation
* fix up rgb pcb rules and config that previously depended on rules and config in a parent directory
* use #pragma once
* turn on backlight breathing and use #pragma once
* fix config.h and rules.mk to not depend on the parent directory
* use #pragma once
* removed keyboard info.jsons in favor of a shared one
* add in hhkb layout and shared info.json file
* fixup readme file
* remove cruft
* use bootmagic lite over yes
* fix config path and use pragma once
* commit PR fixes
* update manufacturer
* set bootloader correctly
* Expose unicode_saved_mods
* Add UNICODEMAP shift pair functionality and XS keycode
* Add XS to keycode reference documentation
* Pick pair index based on both Shift and Caps Lock state
* Add XS to Unicode feature docs
* Clean up process_unicode* headers
* Extract unicode_map index calculation into function
* Pick pair index as XOR rather than OR of Shift and Caps states
* unicode_input_start() has to be called before the unicode_map index is calculated
* Replace unicodemap_input_error() with more generic unicode_input_cancel()
* Replace register+tap+unregister with tap_code16(LCTL(LSFT(KC_U)))
* UNICODE_OSX_KEY → UNICODE_KEY_OSX, UNICODE_WINC_KEY → UNICODE_KEY_WINC
* Make keycode range checks more robust
* Fix keycode range checks for different input modes
* Add UNICODE_KEY_LNX, update docs
* QK_UNICODEMAP_SHIFT → QK_UNICODEMAP_PAIR
* XS → XP, update docs
* Tweak Unicode docs
* Use recently added MOD_MASK_SHIFT and IS_HOST_LED_ON helpers
* Update Unicode table in docs/keycodes.md
* Update Unicode docs per review comments
* Replace references to Mac OS X with macOS in Unicode docs
* As of v0.9.0, WinCompose supports all possible code points
* Expand descriptions in XP docs
* Update keycode table and cycling docs
* Further expand cycling docs
* Add DFU Suffix for ARM boards
* Blindly flash DFU SUFFIX ARGS for now
* Fix commented out check
* Fix DFU Suffix Argument check
Thank you jack!
* Update Travis CI Scripts to include dfu-util
So we can get dfu-suffix as well
* Manually add dfu-suffix package
* Use external repo for newer version of dfu-util
One that includes dfu-suffix
* Update .travis.yml
* Silence unnecessary output from dfu-suffix
The insertion point for `$(patsubst %.c,%.clib,$(LIB_SRC))` must be after all normal `SRC += ..` . I modified it to be so.
Because LIB_SRC and SRC are assumed to be used in pairs. Similarly, QUANTUM_LIB_SRC and QUANTUM_SRC are assumed to be used in pairs.
translate
newbs_getting_started.md
newbs_building_firmware.md
newbs_flashing.md
newbs_testing_debugging.md
newbs_best_practices.md
newbs_learn_more_resources.md
into Mandarin Chinese
Specifically, to fix some edge cases, and keep the handling consistent, the userspace folder should not actually be added at the end. Ideally, it should be added after the keymap paths, but before the keyboard's path.
This issue was discovered in #5484, and the fix created by mtei.
* If RGBLIGHT_EFFECT_BREATHE_CENTER is undefined, use fixed breathe table instead of exp() and sin()
* Change rgblight breathing table size to be easily selectable.
add RGBLIGHT_BREATHE_TABLE_SIZE macro for customize breathing effect.
* Add compatibility for LAYOUTS = planck_mit planck_grid
* Add compatibility for LAYOUTS = ortho_4x12
* Remove planck_grid community support from Plaid
* First publish of roguepullreqest programmer dvorak planck layout
* Removed junk line
* Update keyboards/planck/keymaps/roguepullrequest/keymap.c
Co-Authored-By: roguepullrequest <roguepullrequest@users.noreply.github.com>
* Update keyboards/planck/keymaps/roguepullrequest/keymap.c
Co-Authored-By: roguepullrequest <roguepullrequest@users.noreply.github.com>
* Update keyboards/planck/keymaps/roguepullrequest/keymap.c
Co-Authored-By: roguepullrequest <roguepullrequest@users.noreply.github.com>
* Update keyboards/planck/keymaps/roguepullrequest/keymap.c
Co-Authored-By: roguepullrequest <roguepullrequest@users.noreply.github.com>
* Removed layer songs
Removed layer songs for cleanliness. Will use them later.
* Update keyboards/planck/keymaps/roguepullrequest/readme.md
Co-Authored-By: roguepullrequest <roguepullrequest@users.noreply.github.com>
* Made basic LSHIFT framework but is not working. Listed other tapdances.
* Got LSHIFT to work
* Added working RSHIFT
* Added working TD_S
* Cleaned up LEFT and RIGHT [ { ] } on the UPPER layer.
* Cleaned up layout.
* Reenabled audio space is not needed right now.
* Added tap dances and layout image
* Started dactylmanuform layout
* Revert "Started dactylmanuform layout"
This reverts commit 5ef48e4a23.
* Adjusted the linear led table and hsv_to_rgb to better handle 255 hue
* small math adjustments to better handle specific uint8_t rounding and overflows
* Remove dependency on sortedcontainers
* Sort dictionary on output
* Externalize writing of keymap.c into function
- serialize layers into one flat list
* Add encoding
* Generate JSON keymap in addition to keymap.c
* Replace XXXXXX with KC_NO
* Added support for BM16S keyboard.
* Update keyboards/bm16s/bm16s.h
Co-Authored-By: bontakun <ben@bontakun.net>
* Update keyboards/bm16s/bm16s.h
Co-Authored-By: bontakun <ben@bontakun.net>
* Cleaned up a bunch of unneeded stuff.
* Made layout name match.
* Changed rules file to have correct bootloader and indention. Updated readme to reflect availability on krepublic. Updated keymap to have more obvious RGB controls.
* Removed unnecessary file.
* Fixed grammar in readme.
Co-Authored-By: bontakun <ben@bontakun.net>
* Migrated to autogenerated layout config, without issue.
* Renamed LAYOUT to match community standards.
* Move lib8tion header-defined constant into implementation file, add to build
* Move b_m16_interleave initializtion to lib8tion.c, change build to include lib8tion.c in QUANTUM_LIB_SRC
* Remove left-over whitespace
* Move lib8tion include by RGB_MATRIX_ENABLE code in makefile
* Revert build changes and change lib8tion b_m16_interleave constant to static
* Adding ortho_4x12 & planck_mit layouts for KBD4X.
* Adding LAYOUT_kc_ortho_4x12 macro to KBD4x.
* Turn off console for KBD4X so firmware size falls within limit.
* Revamped custom effects approach
See docs for example usage
* push-up RGB Matrix default mode
Override default effect using RGB_MATRIX_STARTUP_MODE.
Useful on boards without EEPROM support
(*cough* Massdrop ALT/CTRL *cough*)
* update docs
* Planck: Copy contents of Planck rules.mk to each revision
* Planck: Delete Planck rules.mk
* Planck: Concatenate duplicate rules
Concatenate rules that are set and then overridden into one setting.
* Preonic: Copy contents of Preonic rules.mk to each revision
* Preonic: Delete Preonic rules.mk
* Preonic: Concatenate duplicate rules
Concatenate rules that are set and then overridden into one setting.
* Planck: Delete non-specific Bootloader settings from revs. 1 and 2
Deleted BOOTLOADER setting code block, as the checks were only valid for revs. 3-5 and the Planck Light.
Neither Planck rev1 or rev2 set the bootloader via rules.mk, so there's no setting of BOOTLOADER in their rules.mk files.
* Preonic: Fix BOOTLOADER settings code blocks
* Preonic: delete extra blank lines from rules.mk files
* Preonic: delete AVR-type hardware config blocks from rev3
* Update Planck and Preonic readme files
- update Hardware Supported
- update/add Install Examples
- update Docs paragraph
* Enable Bootmagic Lite where it is disabled
Enabled Bootmagic Lite for:
- Planck Light
- Planck revs. 1-5
- Preonic revs. 1 and 2
* Remove `planck_grid` from LAYOUTS rule for all Planck revisions
Community has landed on `ortho_4x12`, which is already set; `planck_grid` is redundant.
* Update code for compatibility with latest QMK
* Added compatibility with Planck rev6
* use wait_ms instead of _delay_ms
* removed unnecessary rules
* disable audio on rev4 only
* A better new_project.sh
* Fix docstrings
* Use single quotes for anything not shown to user
* Missed this docstring
* Simplify get_git_username()
Thanks @vomindoraan
* chmod +x
* Add docstring for print_error()
* Break up git username call into multiple lines
* Use with statement here
* Conform to PEP 8 even more
* Turn it back into a shell script
* chmod +x again
* Update docs to reflect new keyboard generator usage
* Tweak wording slightly
* Trim trailing whitespace
* Don't actually need to escape the newlines here
* As I suspected, you can pass shift a number
* Prepend ./ to match the other code block
* Minor syntax tweaks
* The username token has changed
* Replace name in the readme too
* Make some reasonable assumptions about the presence of Git
* Add initial keyboard layout for Quefrency
* Add RGB config and keybindings for Quefrency
* Move Quefrency wheel keys to more convenient place
* Actually switch from serial to I2C
Commit 64708c6 updated the comment, not the #define. D'oh!
* [Keyboard] Update Gergo to use newer Ergodox Matrix code
And update layout macros to be correct
* Almost forgot the json file
* Remove board specific defines for i2c timeout
* Start to standardize macro timer
* Update Fractal layout
Specifically, limit the RGB Lighting, since it's too many for the power, and only have the KITT annimation on the front
* Update Iris keymap to use I2C for transport
* Remove TAP_CODE_DELAY from keyboard in favor of global setting
* Remove Woodpad
Since it\'s no longer in my possession
* Only enable LTO on AVR boards
* Run matrix_scans while doing startup light
* Run matrix_scan to get split keyboard code synced properly
* Fix rgb mode
* Remove custom debouncing settings
* Make RGB Light Startup Animation optional
* Fix opt def
* Remove extra tap code delay value
* Fix references to keebio boards
* Add support for LP Iris keyboard
* Add backlight code
* Make startup animation optional
* Update gitlab ci script
* Remove port declaration
* Revert avrgcc changes to gitlab ci file
* Don't re-set mods
* Remove MACRO_TIMER define
* Add custom name for crkbd
* Add name for Prime M pad
* Add names for ortho 4x12 boards
* Add some additional handling for rgb init
* Change thumb clusters on ergodox
* Switch Orthodox to I2C
* Fix Space in ergodox keymap
* Use OSL for ergodox layout
* Ugh, can't find a good layout
* Fix typo
* Fix up animation startup
* Cries in AVR
* Fix makefiles for ergodox ez boards
* Add support for "secret songs" in my userspace
* Reset debounce to 5ms for Ergodox EZ
* Fix gitlab CI yaml file
* More crying in AVR
* Cannot use rgb light and rgb matrix at the same time due to the WS2812 rgb matrix PR until the "Coexistance" PR is merged
* Update ODox for split common and i2c
* Add split config
* Impement Split code
* Add support for xscorpion OLED code
* Add OLED display config
* Fix OLED screen font
* Get OLED set up in vertical mode
* Remove old OLED code
* add per key support for crkbd
* Fix split changes
* RGB Tweeaks
* More OLED tweaks
* Fix rotation stuff
* Fix more OLED stuff
* Remove custom Debounce from Ergodox layout since it's no longer needed
With my XD60, I noticed that when typing the backlight was flickering.
The XD60 doesn't have the backlight wired to a hardware PWM pin.
I assumed it was a timing issue in the matrix scan that made the PWM
lit the LED a bit too longer. I verified it because the more keys that
were pressed, the more lighting I observed.
This patch makes the software PWM be called during CPU interruptions.
It works almost like the hardware PWM, except instead of using
the CPU waveform generation, the CPU will fire interruption
when the LEDs need be turned on or off.
Using the same timer system as for hardware PWM, when the counter
will reach OCRxx (the current backlight level), an Output Compare
match interrupt will be fired and we'll turn the LEDs off.
When the counter reaches its maximum value, an overflow interrupt
will be triggered in which we turn the LEDs on.
This way we replicate the hardware backlight PWM duty cycle.
This gives a better time stability of the PWM computation than pure
software PWM, leading to a flicker free backlight.
Since this is reusing the hardware PWM code, software PWM also supports
backlight breathing.
Note that if timer1 is used for audio, backlight will use timer3, and if
timer3 is used for audio backlight will use timer1.
If both timers are used for audio, then this feature is disabled and we
revert to the matrix scan based PWM computation.
Signed-off-by: Brice Figureau <brice@daysofwonder.com>
* added info.json for ymd96
* fix layout for keymap_custom macrom, correct info.json for default layout
* add info layout for iso
* add info layout for iso
* align layout name, added maintainer username
* layout case fix
* layout case fix
* fix overlapping keys
* match layouts to keymaps.
* Define RGB colors
Define RGB colors and pass them to the rgblight functions, instead of
defining multiple macros.
* Add new color definitions support for RGB Matrix
* Add/clarify info about new color definitions in Docs
* Add deprecation warning banner to rgblight_list.h
* initial commit
* get rid of some of the vanilla code
* set up matrix and pins
* Create LAYOUT macro and an appropriate keymap
* support for caps lock LED
* add some documentation to the doro67 parent readme
* align the language used in the several readme files
* initial commit
* get rid of some of the vanilla code
* set up matrix and pins
* Create LAYOUT macro and an appropriate keymap
* support for caps lock LED
* add some documentation to the doro67 parent readme
* align the language used in the several readme files
* Use RGB Matrix and fix enter key bug
* fix formatting
* remove merge conflict artifacts
* make a more useful default keymap
* add configurator support for the RGB pcb
* fix rgb matrix based on new info. Multipler should be reversed
* forgot to actually set the pin output for caps lock led
* fix offset keys in layer 1 keymap
* code cleanup
* use macros for the rgb_led calculations struct
* set RGB led num to 67 as I mistakenly counted the caps lock led
* cleanup config.h file
* add RGB note in readme
* get consistent naming in config file
* fix some inconsistencies
* readjust matrix and get rid of macros based on drashna's suggestions
* add keymap
* fix readme title
* renamed README.md to lowercase, fix typo
* renamed README.md to lowercase, for real
* add double spaces for github
* lowercase name in readme
* rename directory to lowercase
* Make Signum 3.0 compatible with default ortho_4x12 layout
* Disable unicode map by default
* Add missing backspace key
* Add missing delete key
* Fix broken gui right command
* Move MO5 to a different key an add Esc to L4
* Move MO5 to a different key
* Add Del and Bspace to layer 4
* add I2C_slave_buffer_t to quantum/split_common/transport.c
Improvements to ease the maintenance of the I2C slave buffer layout. And this commit does not change the compilation results.
* add temporary pdhelix(Patched Helix) code
* temporary cherry-pick from #5020
add new version(#5020) quantum/rgblight.[ch], quantum/rgblight_modes.h
* add post_config.h support to build_keyboard.mk
* add quantum/rgblight_post_config.h, quantum/split_common/post_config.h
Add quantum/rgblight_post_config.h and quantum/split_common/post_config.h using POST_CONFIG_H variable of build_keyboard.mk.
quantum/rgblight_post_config.h additionally defines RGBLIGHT_SPLIT if RGBLED_SPIT is defined.
quantum/split_common/post_config.h defines RGBLIGHT_SPLIT additionally when master-slave communication is I2C.
* Change split_common's transport.c I2C to use the synchronization feature of rgblight.c
* Change split_common's transport.c serial to use the synchronization feature of rgblight.c
* test RGBLIGHT_SPLIT on keyboards/handwired/pdhelix
* Test End Revert "test RGBLIGHT_SPLIT on keyboards/handwired/pdhelix"
This reverts commit 80118a6bbd.
[x] make RGBLIGHT_TEST=1 handwired/pdhelix/i2c:default
[x] make RGBLIGHT_TEST=2 handwired/pdhelix/i2c:default (same RGBLIGHT_TEST=3)
[x] make RGBLIGHT_TEST=3 handwired/pdhelix/i2c:default
[x] make RGBLIGHT_TEST=1 handwired/pdhelix/pd2:default
[x] make RGBLIGHT_TEST=2 handwired/pdhelix/pd2:default
[x] make RGBLIGHT_TEST=3 handwired/pdhelix/pd2:default
[x] make RGBLIGHT_TEST=1 handwired/pdhelix/pd2_2oled:default
[x] make RGBLIGHT_TEST=2 handwired/pdhelix/pd2_2oled:default
[x] make RGBLIGHT_TEST=3 handwired/pdhelix/pd2_2oled:default
* Test End, Revert "temporary cherry-pick from #5020"
This reverts commit d35069f68b.
* Test End, Revert "add temporary pdhelix(Patched Helix) code"
This reverts commit aebddfc1a8.
* temporarily cherry-pick from #5020 to see if it passes the travis-ci test.
add new version(#5020) quantum/rgblight.[ch], quantum/rgblight_modes.h
* Passed the travis-ci test. Revert "temporarily cherry-pick from #5020 to see if it passes the travis-ci test."
This reverts commit 647c0a9755.
* update docs/config_options.md
* update split_common/transport.c, improves maintainability of serial transaction IDs.
No change in build result.
* temporary cherry-pick from #5020
* fix build fail keebio/iris/rev3:default
* fix build fail lets_split_eh/eh:default
* Revert "temporary cherry-pick from #5020"
This reverts commit be48ca1b45.
* temporary cherry-pick from #5020 (0.6.336)
* Revert "temporary cherry-pick from #5020 (0.6.336)"
This reverts commit 978d26a8b3.
* temporary cherry-pick from #5020 (0.6.336)
* add temporary file that is rgblight.c call graph
* add rgblight_update_hook()
* update rgblight-call-graph.dot (temporary file)
* add more hook point
* add TODO comment
* temporary Revert "add TODO comment"
This reverts commit df6165aac9.
* temporary Revert "add more hook point"
This reverts commit 64592b06f3.
* temporary Revert "add rgblight_update_hook()"
This reverts commit 432b74c912.
* add rgblight_update_hook()
* add more hook point
* add TODO comment
* implement rgblight_update_hook()
* remove rgblight_update_hook(), add RGBLIGHT_SPLIT_SET_CHANGE_XXXX
rgblight_update_hook() is too large.
change to simple flag setting.
* shrink rgblight_config_t
* implement rgblight_update_sync()
Note: The animation synchronization process has not been implemented yet.
* update quantum/rgblight-call-graph.dot (temporary file)
* rmove quantum/rgblight-call-graph.dot (temporary file)
* update rgblight.c
* Add temporary code to Helix keyboard 'five_rows' keymap to test rgblight.c .
* fix build break rgblight_update_sync() when all animation off
* fix quantum/rgblight.c:rgblight_disable_XX() add RGBLIGHT_SPLIT_SET_CHANGE_MODE
* quantum/rgblight.c change code order: move rgblight_update_sync()
* add mode_base_table[] to quantum/rgblight.c
* quantum/rgblight.c use mode_base_table[] and rgblight_status.base_mode
* quantum/rgblkght.c animation timer integration
* quantum/rgblkght.c add animation sync for split keyboard
* fix mode_base_table[] and snake effect
* fix build break keyboards/mxss.
keyboards/mxss's local rgblight.c need old version rgblight.h
* rgblight.c: fix animation sync
* quantum/rgblight.c: fix snake effect sync
* quantum/rgblight.c: animation sync interverl 30 sec
* quantum/rgblight.c: fix rgblight_effect_rainbow_swirl() and rgblight_effect_knight()
* quantum/rgblight.c: add macro RGBLIGHT_SPLIT_ANIMATION
* cherry-pick from 'rgblight_modes.h sample implementation'
* fix RGBLIGHT_SPLIT_ANIMATION check position
* Update temporary code in Helix keyboard 'five_rows' keymap to test rgblight.c
* Reduce the firmware size by 1500 bytes when rgblight_effect_breathing() is enabled.
* Changed to rgblight_sethsv_eeprom_helper() for easier reading.
* add fail-safe code to quantum/rgblight.c:rgblight_task(),rgblight_timer_enable()
* remove temporary code in Helix keyboard 'five_rows' keymap
* quantum/rgblight.c: add split-keyboard master side sync functions
add functions:
uint8_t rgblight_get_change_flags(void);
void rgblight_clear_change_flags(void);
void rgblight_get_syncinfo(rgblight_syncinfo_t *syncinfo);
change function:
void rgblight_update_sync(rgblight_syncinfo_t *syncinfo, bool write_to_eeprom);
* Change rgblight_update_sync() to use write_to_eeprom.
* remove TODO comment from quantum/rgblight.h
* Revert "fix build break keyboards/mxss."
This reverts commit 90b9a1aa7d.
(Separated this change into the newly opened PR #5461.)
* Revert "Reduce the firmware size by 1500 bytes when rgblight_effect_breathing() is enabled."
This reverts commit b61004e63e.
* update quantum/rgblight.c: Code size reduction when not using RGBLIGHT_SPLIT.
* Add temporary code to Helix keyboard 'five_rows' keymap to test rgblight.c .
* add temporary pdhelix(Patched Helix) code
* Add temporary code to split_common/transport.c to test rgblight.c.
* Finish testing rgblight.c with helix keyboard.
Revert "Add temporary code to Helix keyboard 'five_rows' keymap to test rgblight.c ."
This reverts commit 0bf81a4723.
* Finish testing rgblight.c with quantum/split_common code.
Revert "Add temporary code to split_common/transport.c to test rgblight.c."
This reverts commit 71db3e24ee.
* remove temporary pdhelix(Patched Helix) code
This reverts commit 5287e51a39.
* Added description of RGBLIGHT_SPLIT macro to docs/feature_rgblight.md.
* add RGBLIGHT_SPLIT_SET_CHANGE_HSVS to rgblight_init()
* Changed to restart animation only when changing mode.
When changing hue, sat and val, the animation is not restarted and continues.
Patch from https://github.com/qmk/qmk_firmware/issues/3657#issuecomment-415147411
Long story short, in avr-gcc pre-8.2, reset_key was assigned to a memory area that was in a normal range, but when 8.2 came out, that memory got moved to an out of range area, causing errors like 0x800293 out of range. Apparently, this was fixed up in avr-gcc, but we haven't seen a release with the fix yet (we expected it in 8.3, but that didn't happen for some reason).
What this commit does is move the reset_key back to the original memory location it was in before.
* Reduce CRKBD firmware size by reducing layer numbers
* Update layer output code based on mtei's suggestion/code
* Fix spacing
* Revert "Update layer output code based on mtei's suggestion/code"
This reverts commit 036d347db3.
Unfortunately, because this is NOT in the keymap itself, the layer macros aren't accessible and will error on commit
* Add comment for future person
When waking from suspend, only enable the LED drivers if they were not previously set to disabled by the user. This functionality was removed by the recent updates to adapt Massdrop keyboards to QMK RGB Matrix. Affects Massdrop CTRL and ALT keyboards compiled using Massdrop Configurator mode.
* First publish of roguepullreqest programmer dvorak planck layout
* Removed junk line
* Update keyboards/planck/keymaps/roguepullrequest/keymap.c
Co-Authored-By: roguepullrequest <roguepullrequest@users.noreply.github.com>
* Update keyboards/planck/keymaps/roguepullrequest/keymap.c
Co-Authored-By: roguepullrequest <roguepullrequest@users.noreply.github.com>
* Update keyboards/planck/keymaps/roguepullrequest/keymap.c
Co-Authored-By: roguepullrequest <roguepullrequest@users.noreply.github.com>
* Update keyboards/planck/keymaps/roguepullrequest/keymap.c
Co-Authored-By: roguepullrequest <roguepullrequest@users.noreply.github.com>
* Removed layer songs
Removed layer songs for cleanliness. Will use them later.
* Update keyboards/planck/keymaps/roguepullrequest/readme.md
Co-Authored-By: roguepullrequest <roguepullrequest@users.noreply.github.com>
* Made basic LSHIFT framework but is not working. Listed other tapdances.
* Got LSHIFT to work
* Added working RSHIFT
* Added working TD_S
* Cleaned up LEFT and RIGHT [ { ] } on the UPPER layer.
* Cleaned up layout.
* Reenabled audio space is not needed right now.
* Add files via upload
* kingwangwong
* kingwangwong
* revisions and adding atom40
* revisions for 5626
* revisions for 5626
* revisions for 5626.
* revisions for 5626, re added safe range
* revisions for 5626, added qmkkeyboard
* revisions for 5626, quefrency
Most of our style is pretty easy to pick up on, but right now it's not entirely consistent. You should match the style of the code surrounding your change, but if that code is inconsistent or unclear use the following guidelines:
* We indent using four (4) spaces (soft tabs)
* We use a modified One True Brace Style
* Opening Brace: At the end of the same line as the statement that opens the block
* Closing Brace: Lined up with the first character of the statement that opens the block
* Else If: Place the closing brace at the beginning of the line and the next opening brace at the end of the same line.
* Optional Braces: Always include optional braces.
* Good: if (condition) { return false; }
* Bad: if (condition) return false;
* We encourage use of C style comments: `/* */`
* Think of them as a story describing the feature
* Use them liberally to explain why particular decisions were made.
* Do not write obvious comments
* If you not sure if a comment is obvious, go ahead and include it.
* In general we don't wrap lines, they can be as long as needed. If you do choose to wrap lines please do not wrap any wider than 76 columns.
* We use `#pragma once` at the start of header files rather than old-style include guards (`#ifndef THIS_FILE_H`, `#define THIS_FILE_H`, ..., `#endif`)
* We accept both forms of preprocessor if's: `#ifdef DEFINED` and `#if defined(DEFINED)`
* If you are not sure which to prefer use the `#if defined(DEFINED)` form.
* Do not change existing code from one style to the other, except when moving to a multiple condition `#if`.
* Do not put whitespace between `#` and `if`.
* When deciding how (or if) to indent directives keep these points in mind:
* Readability is more important than consistency.
* Follow the file's existing style. If the file is mixed follow the style that makes sense for the section you are modifying.
* When choosing to indent you can follow the indention level of the surrounding C code, or preprocessor directives can have their own indent level. Choose the style that best communicates the intent of your code.
Here is an example for easy reference:
```c
/* Enums for foo */
enumfoo_state{
FOO_BAR,
FOO_BAZ,
};
/* Returns a value */
intfoo(void){
if(some_condition){
returnFOO_BAR;
}else{
return-1;
}
}
```
# Auto-formatting with clang-format
[Clang-format](https://clang.llvm.org/docs/ClangFormat.html) is part of LLVM and can automatically format your code for you, because ain't nobody got time to do it manually. We supply a configuration file for it that applies most of the coding conventions listed above. It will only change whitespace and newlines, so you will still have to remember to include optional braces yourself.
Use the [full LLVM installer](http://llvm.org/builds/) to get clang-format on Windows, or use `sudo apt install clang-format` on Ubuntu.
If you run it from the command-line, pass `-style=file` as an option and it will automatically find the .clang-format configuration file in the QMK root directory.
If you use VSCode, the standard C/C++ plugin supports clang-format, alternatively there is a [separate extension](https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.ClangFormat) for it.
Some things (like LAYOUT macros) are destroyed by clang-format, so either don't run it on those files, or wrap the sensitive code in `// clang-format off` and `// clang-format on`.
Most of our style follows PEP8 with some local modifications to make things less nit-picky.
* We target Python 3.5 for compatability with all supported platforms.
* We indent using four (4) spaces (soft tabs)
* We encourage liberal use of comments
* Think of them as a story describing the feature
* Use them liberally to explain why particular decisions were made.
* Do not write obvious comments
* If you not sure if a comment is obvious, go ahead and include it.
* We require useful docstrings for all functions.
* In general we don't wrap lines, they can be as long as needed. If you do choose to wrap lines please do not wrap any wider than 76 columns.
* Some of our practices conflict with the wider python community to make our codebase more approachable to non-pythonistas.
# YAPF
You can use [yapf](https://github.com/google/yapf) to style your code. We provide a config in [setup.cfg](setup.cfg).
# Imports
We don't have a hard and fast rule for when to use `import ...` vs `from ... import ...`. Understandability and maintainability is our ultimate goal.
Generally we prefer to import specific function and class names from a module to keep code shorter and easier to understand. Sometimes this results in a name that is ambiguous, and in such cases we prefer to import the module instead. You should avoid using the "as" keyword when importing, unless you are importing a compatability module.
Imports should be one line per module. We group import statements together using the standard python rules- system, 3rd party, local.
Do not use `from foo import *`. Supply a list of objects you want to import instead, or import the whole module.
## Import Examples
Good:
```
from qmk import effects
effects.echo()
```
Bad:
```
from qmk.effects import echo
echo() # It's unclear where echo comes from
```
Good:
```
from qmk.keymap import compile_firmware
compile_firmware()
```
OK, but the above is better:
```
import qmk.keymap
qmk.keymap.compile_firmware()
```
# Statements
One statement per line.
Even when allowed (EG `if foo: bar`) we do not combine 2 statements onto a single line.
Function names, variable names, and filenames should be descriptive; eschew abbreviation. In particular, do not use abbreviations that are ambiguous or unfamiliar to readers outside your project, and do not abbreviate by deleting letters within a word.
Always use a .py filename extension. Never use dashes.
## Names to Avoid
* single character names except for counters or iterators. You may use "e" as an exception identifier in try/except statements.
* dashes (-) in any package/module name
* __double_leading_and_trailing_underscore__ names (reserved by Python)
# Docstrings
To maintain consistency with our docstrings we've set out the following guidelines.
* Use markdown formatting
* Always use triple-dquote docstrings with at least one linebreak: `"""\n"""`
* First line is a short (<70char)descriptionofwhatthefunctiondoes
* key combination that allows the use of magic commands (useful for debugging)
*`#define USB_MAX_POWER_CONSUMPTION`
* sets the maximum power (in mA) over USB for the device (default: 500)
*`#define SCL_CLOCK 100000L`
* sets the SCL_CLOCK speed for split keyboards. The default is `100000L` but some boards can be set to`400000L`.
*`#define F_SCL 100000L`
* sets the I2C clock rate speed for keyboards using I2C. The default is `400000L`, except for keyboards using `split_common`, where the default is`100000L`.
## Features That Can Be Disabled
@@ -171,6 +171,8 @@ If you define these options you will enable the associated feature, which may in
* how long for the Combo keys to be detected. Defaults to `TAPPING_TERM` if not defined.
*`#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.
## RGB Light Configuration
@@ -180,10 +182,12 @@ If you define these options you will enable the associated feature, which may in
* run RGB animations
*`#define RGBLED_NUM 12`
* number of LEDs
*`#define RGBLIGHT_SPLIT`
* Needed if both halves of the board have RGB LEDs wired directly to the RGB output pin on the controllers instead of passing the output of the left half to the input of the right half
*`#define RGBLED_SPLIT { 6, 6 }`
* number of LEDs connected that are directly wired to `RGB_DI_PIN` on each half of a split keyboard
* First value indicates number of LEDs for left half, second value is for the right half
*Needed if both halves of the board have RGBLEDs wired directly to the RGB output pin on the controllers instead of passing the output of the left half to the input of the right half
*When RGBLED_SPLIT is defined, RGBLIGHT_SPLIT is implicitly defined.
*`#define RGBLIGHT_HUE_STEP 12`
* units to step when in/decreasing hue
*`#define RGBLIGHT_SAT_STEP 25`
@@ -244,6 +248,9 @@ There are a few different ways to set handedness for split keyboards (listed in
*`#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.
* 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`.
*`#define RGBLED_SPLIT { 6, 6 }`
* See [RGB Light Configuration](#rgb-light-configuration)
@@ -285,6 +292,7 @@ This is a [make](https://www.gnu.org/software/make/manual/make.html) file that i
*`halfkay`
*`caterina`
*`bootloadHID`
*`USBasp`
## Feature Options
@@ -328,6 +336,8 @@ Use these to enable or disable building certain features. The more you have enab
* Forces the keyboard to wait for a USB connection to be established before it starts up
*`NO_USB_STARTUP_CHECK`
* Disables usb suspend check after keyboard startup. Usually the keyboard waits for the host to wake it up before any tasks are performed. This is useful for split keyboards as one half will not get a wakeup call but must send commands to the master.
*`LINK_TIME_OPTIMIZATION_ENABLE`
= Enables Link Time Optimization (`LTO`) when compiling the keyboard. This makes the process take longer, but can significantly reduce the compiled size (and since the firmware is small, the added time is not noticable). However, this will automatically disable the old Macros and Functions features automatically, as these break when `LTO` is enabled. It does this by automatically defining `NO_ACTION_MACRO` and `NO_ACTION_FUNCTION`
@@ -54,54 +54,10 @@ Never made an open source contribution before? Wondering how contributions work
# Coding Conventions
Most of our style is pretty easy to pick up on, but right now it's not entirely consistent. You should match the style of the code surrounding your change, but if that code is inconsistent or unclear use the following guidelines:
Most of our style is pretty easy to pick up on. If you are familiar with either C or Python you should not have too much trouble with our local styles.
*We indent using two spaces (soft tabs)
*We use a modified One True Brace Style
* Opening Brace: At the end of the same line as the statement that opens the block
* Closing Brace: Lined up with the first character of the statement that opens the block
* Else If: Place the closing brace at the beginning of the line and the next opening brace at the end of the same line.
* Optional Braces: Always include optional braces.
* Good: if (condition) { return false; }
* Bad: if (condition) return false;
* We encourage use of C style comments: `/* */`
* Think of them as a story describing the feature
* Use them liberally to explain why particular decisions were made.
* Do not write obvious comments
* If you not sure if a comment is obvious, go ahead and include it.
* In general we don't wrap lines, they can be as long as needed. If you do choose to wrap lines please do not wrap any wider than 76 columns.
* We use `#pragma once` at the start of header files rather than old-style include guards (`#ifndef THIS_FILE_H`, `#define THIS_FILE_H`, ..., `#endif`)
Here is an example for easy reference:
```c
/* Enums for foo */
enumfoo_state{
FOO_BAR,
FOO_BAZ,
};
/* Returns a value */
intfoo(void){
if(some_condition){
returnFOO_BAR;
}else{
return-1;
}
}
```
# Auto-formatting with clang-format
[Clang-format](https://clang.llvm.org/docs/ClangFormat.html) is part of LLVM and can automatically format your code for you, because ain't nobody got time to do it manually. We supply a configuration file for it that applies most of the coding conventions listed above. It will only change whitespace and newlines, so you will still have to remember to include optional braces yourself.
Use the [full LLVM installer](http://llvm.org/builds/) to get clang-format on Windows, or use `sudo apt install clang-format` on Ubuntu.
If you run it from the command-line, pass `-style=file` as an option and it will automatically find the .clang-format configuration file in the QMK root directory.
If you use VSCode, the standard C/C++ plugin supports clang-format, alternatively there is a [separate extension](https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.ClangFormat) for it.
Some things (like LAYOUT macros) are destroyed by clang-format, so either don't run it on those files, or wrap the sensitive code in `// clang-format off` and `// clang-format on`.
@@ -267,7 +267,7 @@ You should use this function if you need custom matrix scanning code. It can als
If the board supports it, it can be "idled", by stopping a number of functions. A good example of this is RGB lights or backlights. This can save on power consumption, or may be better behavior for your keyboard.
This is controlled by two functions: `suspend_power_down_*` and `suspend_wakeup_init_*`, which are called when the system is board is idled and when it wakes up, respectively.
This is controlled by two functions: `suspend_power_down_*` and `suspend_wakeup_init_*`, which are called when the system board is idled and when it wakes up, respectively.
### Example suspend_power_down_user() and suspend_wakeup_init_user() Implementation
@@ -297,8 +297,8 @@ This runs code every time that the layers get changed. This can be useful for l
This example shows how to set the [RGB Underglow](feature_rgblight.md) lights based on the layer, using the Planck as an example
The above function will use the EEPROM config immediately after reading it, to set the default layer's RGB color. The "raw" value of it is converted in a usable structure based on the "union" that you created above.
### Serial device is not detected in bootloader mode on Linux
Make sure your kernel has appropriate support for your device. If your device uses USB ACM, such as
Pro Micro (Atmega32u4), make sure to include `CONFIG_USB_ACM=y`. Other devices may require `USB_SERIAL` and any of its sub options.
## Unknown Device for DFU Bootloader
If you're using Windows to flash your keyboard, and you are running into issues, check the Device Manager. If you see an "Unknown Device" when the keyboard is in "bootloader mode", then you may have a driver issue.
Issues encountered when flashing keyboards on Windows are most often due to having the wrong drivers installed for the bootloader.
Re-running the installation script for MSYS2 may help (eg run `./util/qmk_install.sh` from MSYS2/WSL) or reinstalling the QMK Toolbox may fix the issue.
Re-running the installation script for MSYS2 may help (eg run `util/qmk_install.sh` from MSYS2/WSL) or reinstalling the QMK Toolbox may fix the issue. Alternatively, you can download and run the [`qmk_driver_installer`](https://github.com/qmk/qmk_driver_installer) package.
If that doesn't work, then you may need to grab the [Zadig Utility](https://zadig.akeo.ie/). Download this, find the device in question, and select the `WinUSB` option, and hit "Reinstall driver". Once you've done that, try flashing your board, again. If that doesn't work, try all of the options, until one works.
If that doesn't work, then you may need to grab the [Zadig Utility](https://zadig.akeo.ie/). Download this, and run it on the system. Then, you will need to reset your board into bootloader mode. After that, locate the device in question. If the device doesn't show up in the list (or nothing shows up in the list), you may need to enable the `List all devices` option in the `Options` menu.
?> There isn't a best option for which driver should be used here. Some options work better on some systems than others. libUSB and WinUSB seem to be the best options here.
If the bootloader doesn't show up in the list for devices, you may need to enable the "List all devices" option in the `Options` menu, and then find the bootloader in question.
From here, you will need to know what type of controller the board is using. You may see it listed in the Device Manager as `ATmega32U4` device (which is an AVR board), or an `STM32` device (Which is an ARM board). For AVR boards, use `libusb-win32` for the driver. For ARM boards, use the `WinUSB` driver. Once the correct driver type has been selected, click on the `Replace Driver` button, unplug your board, plug it back in, and reset it again.
## WINAVR is Obsolete
@@ -140,8 +164,8 @@ For now, you need to rollback avr-gcc to 7 in brew.
```
brew uninstall --force avr-gcc
brew install avr-gcc@7
brew link --force avr-gcc@7
brew install avr-gcc@8
brew link --force avr-gcc@8
```
### I just flashed my keyboard and it does nothing/keypresses don't register - it's also ARM (rev6 planck, clueboard 60, hs60v2, etc...) (Feb 2019)
- EEPROM has around a 100000 write cycle. You shouldn't rewrite the
firmware repeatedly and continually; that'll burn the EEPROM
eventually.
## NKRO Doesn't work
First you have to compile firmware with this build option `NKRO_ENABLE` in **Makefile**.
@@ -183,22 +184,15 @@ Pressing any key during sleep should wake host.
Arduino Leonardo and micro have **ATMega32U4** and can be used for TMK, though Arduino bootloader may be a problem.
## Enabling JTAG
## Using PF4-7 Pins of USB AVR?
You need to set JTD bit of MCUCR yourself to use PF4-7 as GPIO. Those pins are configured to serve JTAG function by default. MCUs like ATMega*U* or AT90USB* are affected with this.
By default, the JTAG debugging interface is disabled as soon as the keyboard starts up. JTAG-capable MCUs come from the factory with the `JTAGEN` fuse set, and it takes over certain pins of the MCU that the board may be using for the switch matrix, LEDs, etc.
If you are using Teensy this isn't needed. Teensy is shipped with JTAGEN fuse bit unprogrammed to disable the function.
If you would like to keep JTAG enabled, just add the following to your `config.h`:
See this code.
```c
#define NO_JTAG_DISABLE
```
// JTAG disable for PORT F. write JTD bit twice within four cycles.
@@ -256,10 +256,10 @@ If you press a Mod Tap key, tap another key (press and release) and then release
For Instance:
-`SHFT_T(KC_A)` Down
-`SFT_T(KC_A)` Down
-`KC_X` Down
-`KC_X` Up
-`SHFT_T(KC_A)` Up
-`SFT_T(KC_A)` Up
Normally, if you do all this within the `TAPPING_TERM` (default: 200ms) this will be registered as `ax` by the firmware and host system. With permissive hold enabled, this modifies how this is handled by considering the Mod Tap keys as a Mod if another key is tapped, and would registered as `X` (`SHIFT`+`x`).
@@ -279,9 +279,9 @@ Setting `Ignore Mod Tap Interrupt` requires holding both keys for the `TAPPING_
For Instance:
-`SHFT_T(KC_A)` Down
-`SFT_T(KC_A)` Down
-`KC_X` Down
-`SHFT_T(KC_A)` Up
-`SFT_T(KC_A)` Up
-`KC_X` Up
Normally, this would send `X` (`SHIFT`+`x`). With `Ignore Mod Tap Interrupt` enabled, holding both keys are required for the `TAPPING_TERM` to register the hold action. A quick tap will output `ax` in this case, while a hold on both will still output `X` (`SHIFT`+`x`).
@@ -303,11 +303,11 @@ When the user holds a key after tap, this repeats the tapped key rather to hold
Example:
- SHFT_T(KC_A) Down
- SHFT_T(KC_A) Up
- SHFT_T(KC_A) Down
- SFT_T(KC_A) Down
- SFT_T(KC_A) Up
- SFT_T(KC_A) Down
- wait more than tapping term...
- SHFT_T(KC_A) Up
- SFT_T(KC_A) Up
With default settings, `a` will be sent on the first release, then `a` will be sent on the second press allowing the computer to trigger its auto repeat function.
@@ -21,6 +21,8 @@ STARTUP_SONG // plays when the keyboard starts up (audio.c)
GOODBYE_SONG // plays when you press the RESET key (quantum.c)
AG_NORM_SONG // plays when you press AG_NORM (quantum.c)
AG_SWAP_SONG // plays when you press AG_SWAP (quantum.c)
CG_NORM_SONG // plays when you press CG_NORM (quantum.c)
CG_SWAP_SONG // plays when you press CG_SWAP (quantum.c)
MUSIC_ON_SONG // plays when music mode is activated (process_music.c)
MUSIC_OFF_SONG // plays when music mode is deactivated (process_music.c)
CHROMATIC_SONG // plays when the chromatic music mode is selected (process_music.c)
@@ -175,8 +177,9 @@ You can configure the default, min and max frequencies, the stepping and built i
| `AUDIO_CLICKY_FREQ_DEFAULT` | 440.0f | Sets the default/starting audio frequency for the clicky sounds. |
| `AUDIO_CLICKY_FREQ_MIN` | 65.0f | Sets the lowest frequency (under 60f are a bit buggy). |
| `AUDIO_CLICKY_FREQ_MAX` | 1500.0f | Sets the the highest frequency. Too high may result in coworkers attacking you. |
| `AUDIO_CLICKY_FREQ_FACTOR` | 1.18921f| Sets the stepping of UP/DOWN key codes. |
| `AUDIO_CLICKY_FREQ_FACTOR` | 1.18921f| Sets the stepping of UP/DOWN key codes. This is a multiplicative factor. The default steps the frequency up/down by a musical minor third. |
| `AUDIO_CLICKY_FREQ_RANDOMNESS` | 0.05f | Sets a factor of randomness for the clicks, Setting this to `0f` will make each click identical, and `1.0f` will make this sound much like the 90's computer screen scrolling/typing effect. |
| `AUDIO_CLICKY_DELAY_DURATION` | 1 | An integer note duration where 1 is 1/16th of the tempo, or a sixty-fourth note (see `quantum/audio/musical_notes.h` for implementation details). The main clicky effect will be delayed by this duration. Adjusting this to values around 6-12 will help compensate for loud switches. |
@@ -30,7 +30,31 @@ You should then be able to use the keycodes below to change the backlight level.
This feature is distinct from both the [RGB underglow](feature_rgblight.md) and [RGB matrix](feature_rgb_matrix.md) features as it usually allows for only a single colour per switch, though you can obviously use multiple different coloured LEDs on a keyboard.
Hardware PWM is only supported on certain pins of the MCU, so if the backlighting is not connected to one of them, a software implementation will be used, and backlight breathing will not be available. Currently the supported pins are `B5`, `B6`, `B7`, and `C6`.
Hardware PWM is supported according to the following table:
All other pins will use software PWM. If the [Audio](feature_audio.md) feature is disabled or only using one timer, the backlight PWM can be triggered by a hardware timer:
|Audio Pin|Audio Timer|Software PWM Timer|
|---------|-----------|------------------|
|`C4` |Timer 3 |Timer 1 |
|`C5` |Timer 3 |Timer 1 |
|`C6` |Timer 3 |Timer 1 |
|`B5` |Timer 1 |Timer 3 |
|`B6` |Timer 1 |Timer 3 |
|`B7` |Timer 1 |Timer 3 |
When both timers are in use for Audio, the backlight PWM will not use a hardware timer, but will instead be triggered during the matrix scan. In this case, breathing is not supported, and the backlight might flicker, because the PWM computation may not be called with enough timing precision.
## Configuration
@@ -39,10 +63,33 @@ To change the behaviour of the backlighting, `#define` these in your `config.h`:
|`BACKLIGHT_PIN` |`B7` |The pin that controls the LEDs. Unless you are designing your own keyboard, you shouldn't need to change this|
|`BACKLIGHT_LEVELS` |`3` |The number of brightness levels (maximum 15 excluding off) |
|`BACKLIGHT_PINS` |*Not defined*|experimental: see below for more information |
|`BACKLIGHT_LEVELS` |`3` |The number of brightness levels (maximum 31 excluding off) |
|`BACKLIGHT_CAPS_LOCK`|*Not defined*|Enable Caps Lock indicator using backlight (for keyboards without dedicated LED) |
|`BACKLIGHT_BREATHING`|*Not defined*|Enable backlight breathing, if hardware PWM is used |
|`BACKLIGHT_BREATHING`|*Not defined*|Enable backlight breathing, if supported |
|`BREATHING_PERIOD` |`6` |The length of one backlight "breath" in seconds |
|`BACKLIGHT_ON_STATE` |`0` |The state of the backlight pin when the backlight is "on" - `1` for high, `0` for low |
## Backlight On State
Most backlight circuits are driven by an N-channel MOSFET or NPN transistor. This means that to turn the transistor *on* and light the LEDs, you must drive the backlight pin, connected to the gate or base, *high*.
Sometimes, however, a P-channel MOSFET, or a PNP transistor is used. In this case, when the transistor is on, the pin is driven *low* instead.
This functionality is configured at the keyboard level with the `BACKLIGHT_ON_STATE` define.
## Multiple backlight pins
Most keyboards have only one backlight pin which control all backlight LEDs (especially if the backlight is connected to an hardware PWM pin).
In software PWM, it is possible to define multiple backlight pins. All those pins will be turned on and off at the same time during the PWM duty cycle.
This feature allows to set for instance the Caps Lock LED (or any other controllable LED) brightness at the same level as the other LEDs of the backlight. This is useful if you have mapped LCTRL in place of Caps Lock and you need the Caps Lock LED to be part of the backlight instead of being activated when Caps Lock is on.
To activate multiple backlight pins, you need to add something like this to your user `config.h`:
~~~c
#define BACKLIGHT_LED_COUNT 2
#undef BACKLIGHT_PIN
#define BACKLIGHT_PINS { F5, B2 }
~~~
## Hardware PWM Implementation
@@ -53,6 +100,15 @@ In this way `OCRxx` essentially controls the duty cycle of the LEDs, and thus th
The breathing effect is achieved by registering an interrupt handler for `TIMER1_OVF_vect` that is called whenever the counter resets, roughly 244 times per second.
In this handler, the value of an incrementing counter is mapped onto a precomputed brightness curve. To turn off breathing, the interrupt handler is simply disabled, and the brightness reset to the level stored in EEPROM.
## Software PWM Implementation
When `BACKLIGHT_PIN` is not set to a hardware backlight pin, QMK will use a hardware timer configured to trigger software interrupts. This time will count up to `ICRx` (by default `0xFFFF`) before resetting to 0.
When resetting to 0, the CPU will fire an OVF (overflow) interrupt that will turn the LEDs on, starting the duty cycle.
The desired brightness is calculated and stored in the `OCRxx` register. When the counter reaches this value, the CPU will fire a Compare Output match interrupt, which will turn the LEDs off.
In this way `OCRxx` essentially controls the duty cycle of the LEDs, and thus the brightness, where `0x0000` is completely off and `0xFFFF` is completely on.
The breathing effect is the same as in the hardware PWM implementation.
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.
To enable this feature, yu need to add `COMBO_ENABLE = yes` to your `rules.mk`.
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).
@@ -16,36 +16,36 @@ To use Command, hold down the key combination defined by the `IS_COMMAND()` macr
If you would like to change the key assignments for Command, `#define` these in your `config.h` at either the keyboard or keymap level. All keycode assignments here must omit the `KC_` prefix.
@@ -195,6 +195,49 @@ This will clear all mods currently pressed.
This will clear all keys besides the mods currently pressed.
## Advanced Example:
### Super ALT↯TAB
This macro will register `KC_LALT` and tap `KC_TAB`, then wait for 1000ms. If the key is tapped again, it will send another `KC_TAB`; if there is no tap, `KC_LALT` will be unregistered, thus allowing you to cycle through windows.
Mouse keys is a feature that allows you to emulate a mouse using your keyboard. You can move the pointer at different speeds, press 5 buttons and scroll in 8 directions.
Mousekeys is a feature that allows you to emulate a mouse using your keyboard. You can move the pointer around, click up to 5 buttons, and even scroll in all 4 directions.
## Adding mousekeys to your keyboard
There are 2 ways to define how the mousekeys behave, using "[auto-accelerating](#configuring-the-behavior-of-mousekeys-with-auto-accelerated-movement)" or "[3-speed constant](#configuring-the-behavior-of-mousekeys-with-3-speed-constant-movement)" behavior.
To use mousekeys, you must at least enable mousekeys support and map mouse actions to keys on your keyboard.
In either case, you will need to enable mousekeys in your makefile,
and add the relevant [keycodes](#mapping-mouse-actions-to-keyboard-keys) to your keymap.
### Enabling mousekeys
#### Enable Mousekeys
To enable mousekeys, add the following line to your keymap’s `rules.mk`:
To enable the mousekey functionality, add the following line to your keymap's `rules.mk`:
```
```c
MOUSEKEY_ENABLE=yes
```
#### Mapping Mouse Actions to Keyboard Keys
### Mapping mouse actions
You can use these keycodes within your keymap to map button presses to mouse actions:
In your keymap you can use the following keycodes to map key presses to mouse actions:
|`KC_MS_ACCEL0` |`KC_ACL0`|Set mouse acceleration to 0(slow) |
|`KC_MS_ACCEL1` |`KC_ACL1`|Set mouse acceleration to 1(medium)|
|`KC_MS_ACCEL2` |`KC_ACL2`|Set mouse acceleration to 2(fast) |
|Key |Aliases |Description |
|----------------|---------|-----------------|
|`KC_MS_UP` |`KC_MS_U`|Move cursor up |
|`KC_MS_DOWN` |`KC_MS_D`|Move cursor down |
|`KC_MS_LEFT` |`KC_MS_L`|Move cursor left |
|`KC_MS_RIGHT` |`KC_MS_R`|Move cursor right|
|`KC_MS_BTN1` |`KC_BTN1`|Press button 1 |
|`KC_MS_BTN2` |`KC_BTN2`|Press button 2 |
|`KC_MS_BTN3` |`KC_BTN3`|Press button 3 |
|`KC_MS_BTN4` |`KC_BTN4`|Press button 4 |
|`KC_MS_BTN5` |`KC_BTN5`|Press button 5 |
|`KC_MS_WH_UP` |`KC_WH_U`|Move wheel up |
|`KC_MS_WH_DOWN` |`KC_WH_D`|Move wheel down |
|`KC_MS_WH_LEFT` |`KC_WH_L`|Move wheel left |
|`KC_MS_WH_RIGHT`|`KC_WH_R`|Move wheel right |
|`KC_MS_ACCEL0` |`KC_ACL0`|Set speed to 0 |
|`KC_MS_ACCEL1` |`KC_ACL1`|Set speed to 1 |
|`KC_MS_ACCEL2` |`KC_ACL2`|Set speed to 2 |
## Configuring mouse keys
## Configuring the Behavior of Mousekeys with auto-accelerated movement
Mousekeys supports two different modes to move the cursor:
This behavior is intended to emulate the X Window System MouseKeysAccel feature. You can read more about it [on Wikipedia](https://en.wikipedia.org/wiki/Mouse_keys).
* **Accelerated (default):** Holding movement keys accelerates the cursor until it reaches its maximum speed.
* **Constant:** Holding movement keys moves the cursor at constant speeds.
The default speed for controlling the mouse with the keyboard is intentionally slow. You can adjust these parameters by adding these settings to your keymap's `config.h` file. All times are specified in milliseconds (ms).
The same principle applies to scrolling.
```
#define MOUSEKEY_DELAY 300
#define MOUSEKEY_INTERVAL 50
#define MOUSEKEY_MAX_SPEED 10
#define MOUSEKEY_TIME_TO_MAX 20
#define MOUSEKEY_WHEEL_MAX_SPEED 8
#define MOUSEKEY_WHEEL_TIME_TO_MAX 40
```
Configuration options that are times, intervals or delays are given in milliseconds. Scroll speed is given as multiples of the default scroll step. For example, a scroll speed of 8 means that each scroll action covers 8 times the length of the default scroll step as defined by your operating system or application.
#### `MOUSEKEY_DELAY`
### Accelerated mode
When one of the mouse movement buttons is pressed this setting is used to define the delay between that button press and the mouse cursor moving. Some people find that small movements are impossible if this setting is too low, while settings that are too high feel sluggish.
This is the default mode. You can adjust the cursor and scrolling acceleration using the following settings in your keymap’s `config.h` file:
|`MOUSEKEY_DELAY` |300 |Delay between pressing a movement key and cursor movement|
|`MOUSEKEY_INTERVAL` |50 |Time between cursor movements |
|`MOUSEKEY_MAX_SPEED` |10 |Maximum cursor speed at which acceleration stops |
|`MOUSEKEY_TIME_TO_MAX` |20 |Time until maximum cursor speed is reached |
|`MOUSEKEY_WHEEL_MAX_SPEED` |8 |Maximum number of scroll steps per scroll action |
|`MOUSEKEY_WHEEL_TIME_TO_MAX`|40 |Time until maximum scroll speed is reached |
When a movement key is held down this specifies how long to wait between each movement report. Lower settings will translate into an effectively higher mouse speed.
Tips:
#### `MOUSEKEY_MAX_SPEED`
* Setting `MOUSEKEY_DELAY` too low makes the cursor unresponsive. Setting it too high makes small movements difficult.
* For smoother cursor movements, lower the value of `MOUSEKEY_INTERVAL`. If the refresh rate of your display is 60Hz, you could set it to `16` (1/60). As this raises the cursor speed significantly, you may want to lower `MOUSEKEY_MAX_SPEED`.
* Setting `MOUSEKEY_TIME_TO_MAX` or `MOUSEKEY_WHEEL_TIME_TO_MAX` to `0` will disable acceleration for the cursor or scrolling respectively. This way you can make one of them constant while keeping the other accelerated, which is not possible in constant speed mode.
As a movement key is held down the speed of the mouse cursor will increase until it reaches `MOUSEKEY_MAX_SPEED`.
Cursor acceleration uses the same algorithm as the X Window System MouseKeysAccel feature. You can read more about it [on Wikipedia](https://en.wikipedia.org/wiki/Mouse_keys).
#### `MOUSEKEY_TIME_TO_MAX`
### Constant mode
How long you want to hold down a movement key for until `MOUSEKEY_MAX_SPEED` is reached. This controls how quickly your cursor will accelerate.
In this mode you can define multiple different speeds for both the cursor and the mouse wheel. There is no acceleration. `KC_ACL0`, `KC_ACL1` and `KC_ACL2` change the cursor and scroll speed to their respective setting.
#### `MOUSEKEY_WHEEL_MAX_SPEED`
You can choose whether speed selection is momentary or tap-to-select:
The top speed for scrolling movements.
* **Momentary:** The chosen speed is only active while you hold the respective key. When the key is raised, mouse keys returns to the unmodified speed.
* **Tap-to-select:** The chosen speed is activated when you press the respective key and remains active even after the key has been raised. The default speed is that of `KC_ACL1`. There is no unmodified speed.
#### `MOUSEKEY_WHEEL_TIME_TO_MAX`
The default speeds from slowest to fastest are as follows:
How long you want to hold down a scroll key for until `MOUSEKEY_WHEEL_MAX_SPEED` is reached. This controls how quickly your scrolling will accelerate.
## Configuring the Behavior of Mousekeys with 3-speed constant movement
In your keymap's `config.h`, you must add the line:
```
```c
#define MK_3_SPEED
```
Then you can precisely define 3 different speeds for both the cursor and the mouse wheel, and also whether speed selection is momentary or tap-to-select.
For each speed, you can specify how many milliseconds you want between reports(interval), and how far you want to it to move per report(offset).
#define MK_MOMENTARY_ACCEL // comment this out for tap-to-select acceleration
// cursor speeds:
#define MK_C_OFFSET_SLOW 1 // pixels
#define MK_C_INTERVAL_SLOW 100 // milliseconds
#define MK_C_OFFSET_MED 4
#define MK_C_INTERVAL_MED 16
#define MK_C_OFFSET_FAST 12
#define MK_C_INTERVAL_FAST 16
// scroll wheel speeds:
#define MK_W_OFFSET_SLOW 1 // wheel clicks
#define MK_W_INTERVAL_SLOW 400 // milliseconds
#define MK_W_OFFSET_MED 1
#define MK_W_INTERVAL_MED 200
#define MK_W_OFFSET_FAST 1
#define MK_W_INTERVAL_FAST 100
```c
#define MK_MOMENTARY_ACCEL
```
Medium values will be used as the default or unmodified speed.
The speed at which both the cursor and scrolling move can be selected with KC_ACL0, KC_ACL1, KC_ACL2 for slow, medium, and fast. However, if you leave MK_MOMENTARY_ACCEL defined then there is no need to ever send KC_ACL1, since that will be the unmodified speed.
| SH1106 | 128x64 | AVR | No rotation or scrolling |
Hardware configurations using ARM-based microcontrollers or different sizes of OLED modules may be compatible, but are untested.
!> Warning: This OLED Driver currently uses the new i2c_master driver from split common code. If your split keyboard uses I2C to communicate between sides, this driver could cause an address conflict (serial is fine). Please contact your keyboard vendor and ask them to migrate to the latest split common code to fix this. In addition, the display timeout system to reduce OLED burn-in also uses split common to detect keypresses, so you will need to implement custom timeout logic for non-split common keyboards.
## Usage
To enable the OLED feature, there are three steps. First, when compiling your keyboard, you'll need to set `OLED_DRIVER_ENABLE=yes` in `rules.mk`, e.g.:
```
OLED_DRIVER_ENABLE = yes
```
This enables the feature and the `OLED_DRIVER_ENABLE` define. Then in your `keymap.c` file, you will need to implement the user task call, e.g:
```C++
#ifdef OLED_DRIVER_ENABLE
void oled_task_user(void) {
// Host Keyboard Layer Status
oled_write_P(PSTR("Layer: "), false);
switch (get_highest_layer(layer_state)) {
case _QWERTY:
oled_write_P(PSTR("Default\n"), false);
break;
case _FN:
oled_write_P(PSTR("FN\n"), false);
break;
case _ADJ:
oled_write_P(PSTR("ADJ\n"), false);
break;
default:
// Or use the write_ln shortcut over adding '\n' to the end of your string
In split keyboards, it is very common to have two OLED displays that each render different content and oriented flipped differently. You can do this by switching which content to render by using the return from `is_keyboard_master()` or `is_keyboard_left()` found in `split_util.h`, e.g:
| `OLED_DISPLAY_ADDRESS` | `0x3C` | The i2c address of the OLED Display |
| `OLED_FONT_H` | `"glcdfont.c"` | The font code file to use for custom fonts |
| `OLED_FONT_START` | `0` | The starting characer index for custom fonts |
| `OLED_FONT_END` | `224` | The ending characer index for custom fonts |
| `OLED_FONT_WIDTH` | `6` | The font width |
| `OLED_FONT_HEIGHT` | `8` | The font height (untested) |
| `OLED_DISABLE_TIMEOUT` | *Not defined* | Disables the built in OLED timeout feature. Useful when implementing custom timeout rules. |
| `OLED_IC` | `OLED_IC_SSD1306` | Set to `OLED_IC_SH1106` if you're using the SH1106 OLED controller. |
| `OLED_COLUMN_OFFSET` | `0` | (SH1106 only.) Shift output to the right this many pixels.<br />Useful for 128x64 displays centered on a 132x64 SH1106 IC. |
## 128x64 & Custom sized OLED Displays
The default display size for this feature is 128x32 and all necessary defines are precalculated with that in mind. We have added a define, `OLED_DISPLAY_128X64`, to switch all the values to be used in a 128x64 display, as well as added a custom define, `OLED_DISPLAY_CUSTOM`, that allows you to provide the necessary values to the driver.
OLED displays driven by SSD1306 drivers only natively support in hard ware 0 degree and 180 degree rendering. This feature is done in software and not free. Using this feature will increase the time to calculate what data to send over i2c to the OLED. If you are strapped for cycles, this can cause keycodes to not register. In testing however, the rendering time on an `atmega32u4` board only went from 2ms to 5ms and keycodes not registering was only noticed once we hit 15ms.
90 Degree Rotated Rendering is achieved by using bitwise operations to rotate each 8 block of memory and uses two precalculated arrays to remap buffer memory to OLED memory. The memory map defines are precalculated for remap performance and are calculated based on the OLED Height, Width, and Block Size. For example, in the 128x32 implementation with a `uint8_t` block type, we have a 64 byte block size. This gives us eight 8 byte blocks that need to be rotated and rendered. The OLED renders horizontally two 8 byte blocks before moving down a page, e.g:
| | | | | | |
|---|---|---|---|---|---|
| 0 | 1 | | | | |
| 2 | 3 | | | | |
| 4 | 5 | | | | |
| 6 | 7 | | | | |
However the local buffer is stored as if it was Height x Width display instead of Width x Height, e.g:
| | | | | | |
|---|---|---|---|---|---|
| 3 | 7 | | | | |
| 2 | 6 | | | | |
| 1 | 5 | | | | |
| 0 | 4 | | | | |
So those precalculated arrays just index the memory offsets in the order in which each one iterates its data.
!> 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 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`:
@@ -40,11 +42,11 @@ Define these arrays listing all the LEDs in your `<keyboard>.c`:
Where `Cx_y` is the location of the LED in the matrix defined by [the datasheet](http://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` or `1` right now).
---
### IS31FL3733/IS31FL3737
!> For the IS31FL3737, replace all instances of `IS31FL3733` below with `IS31FL3737`.
@@ -90,11 +93,11 @@ 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](http://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` (Only `0` right now).
From this point forward the configuration is the same for all the drivers.
---
### WS2812 (AVR only)
There is basic support for addressable RGB matrix lighting with a WS2811/WS2812{a,b,c} addressable LED strand. To enable it, add this to your `rules.mk`:
```C
constrgb_ledg_rgb_leds[DRIVER_LED_TOTAL]={
/* {row | col << 4}
* | {x=0..224, y=0..64}
* | | modifier
* | | | */
{{0|(0<<4)},{20.36*0,21.33*0},1},
{{0|(1<<4)},{20.36*1,21.33*0},1},
....
}
RGB_MATRIX_ENABLE=WS2812
```
The format for the matrix position used in this array is `{row | (col << 4)}`. The `x` is between (inclusive) 0-224, and `y` is between (inclusive) 0-64. The easiest way to calculate these positions is:
Configure the hardware via your `config.h`:
```C
x=224/(NUMBER_OF_COLS-1)*ROW_POSITION
y=64/(NUMBER_OF_ROWS-1)*COL_POSITION
// The pin connected to the data pin of the LEDs
#define RGB_DI_PIN D7
// The number of LEDs connected
#define DRIVER_LED_TOTAL 70
```
Where all variables are decimels/floats.
---
`modifier` is a boolean, whether or not a certain key is considered a modifier (used in some effects).
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:
The first part, `// Key Matrix to LED Index`, tells the system what key this LED represents by using the key's electrical matrix row & col. The second part, `// LED Index to Physical Position` represents the LED's physical `{ x, y }` position on the keyboard. The default expected range of values for `{ x, y }` is the inclusive range `{ 0..224, 0..64 }`. This default expected range is due to effects that calculate the center of the keyboard for their animations. The easiest way to calculate these positions is imagine your keyboard is a grid, and the top left of the keyboard represents `{ x, y }` coordinate `{ 0, 0 }` and the bottom right of your keyboard represents `{ 224, 64 }`. Using this as a basis, you can use the following formula to calculate the physical position:
```C
x=224/(NUMBER_OF_COLS-1)*COL_POSITION
y=64/(NUMBER_OF_ROWS-1)*ROW_POSITION
```
Where NUMBER_OF_COLS, NUMBER_OF_ROWS, COL_POSITION, & ROW_POSITION are all based on the physical layout of your keyboard, not the electrical layout.
As mentioned earlier, the center of the keyboard by default is expected to be `{ 112, 32 }`, but this can be changed if you want to more accurately calculate the LED's physical `{ x, y }` positions. Keyboard designers can implement `#define RGB_MATRIX_CENTER { 112, 32 }` in their config.h file with the new center point of the keyboard, or where they want it to be allowing more possibilities for the `{ x, y }` values. Do note that the maximum value for x or y is 255, and the recommended maximum is 224 as this gives animations runoff room before they reset.
`// LED Index to Flag` is a bitmask, whether or not a certain LEDs is of a certain type. It is recommended that LEDs are set to only 1 type.
Custom layer effects can be done by defining this in your `<keyboard>.c`:
By setting `RGB_MATRIX_CUSTOM_USER` (and/or `RGB_MATRIX_CUSTOM_KB`) in `rule.mk`, new effects can be defined directly from userspace, without having to edit any QMK core files.
To declare new effects, create a new `rgb_matrix_user/kb.inc` that looks something like this:
`rgb_matrix_user.inc` should go in the root of the keymap directory.
`rgb_matrix_kb.inc` should go in the root of the keyboard directory.
```C
voidrgb_matrix_indicators_kb(void){
rgb_matrix_set_color(index,red,green,blue);
// !!! DO NOT ADD #pragma once !!! //
// Step 1.
// Declare custom effects using the RGB_MATRIX_EFFECT macro
// (note the lack of semicolon after the macro!)
RGB_MATRIX_EFFECT(my_cool_effect)
RGB_MATRIX_EFFECT(my_cool_effect2)
// Step 2.
// Define effects inside the `RGB_MATRIX_CUSTOM_EFFECT_IMPLS` ifdef block
#ifdef RGB_MATRIX_CUSTOM_EFFECT_IMPLS
// e.g: A simple effect, self-contained within a single method
staticboolmy_cool_effect(effect_params_t*params){
RGB_MATRIX_USE_LIMITS(led_min,led_max);
for(uint8_ti=led_min;i<led_max;i++){
rgb_matrix_set_color(i,0xff,0xff,0x00);
}
returnled_max<DRIVER_LED_TOTAL;
}
// e.g: A more complex effect, relying on external methods and state, with
A similar function works in the keymap as `rgb_matrix_indicators_user`.
For inspiration and examples, check out the built-in effects under `quantum/rgb_matrix_animation/`
## Colors
These are shorthands to popular colors. The `RGB` ones can be passed to the `setrgb` functions, while the `HSV` ones to the `sethsv` functions.
|RGB |HSV |
|-------------------|-------------------|
|`RGB_WHITE` |`HSV_WHITE` |
|`RGB_RED` |`HSV_RED` |
|`RGB_CORAL` |`HSV_CORAL` |
|`RGB_ORANGE` |`HSV_ORANGE` |
|`RGB_GOLDENROD` |`HSV_GOLDENROD` |
|`RGB_GOLD` |`HSV_GOLD` |
|`RGB_YELLOW` |`HSV_YELLOW` |
|`RGB_CHARTREUSE` |`HSV_CHARTREUSE` |
|`RGB_GREEN` |`HSV_GREEN` |
|`RGB_SPRINGGREEN` |`HSV_SPRINGGREEN` |
|`RGB_TURQUOISE` |`HSV_TURQUOISE` |
|`RGB_TEAL` |`HSV_TEAL` |
|`RGB_CYAN` |`HSV_CYAN` |
|`RGB_AZURE` |`HSV_AZURE` |
|`RGB_BLUE` |`HSV_BLUE` |
|`RGB_PURPLE` |`HSV_PURPLE` |
|`RGB_MAGENTA` |`HSV_MAGENTA` |
|`RGB_PINK` |`HSV_PINK` |
These are defined in [`rgblight_list.h`](https://github.com/qmk/qmk_firmware/blob/master/quantum/rgblight_list.h). Feel free to add to this list!
## Additional `config.h` Options
@@ -224,6 +374,7 @@ A similar function works in the keymap as `rgb_matrix_indicators_user`.
#define RGB_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 RGB_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 RGB_MATRIX_MAXIMUM_BRIGHTNESS 200 // limits maximum brightness of LEDs to 200 out of 255. If not defined maximum brightness is set to 255
#define RGB_MATRIX_STARTUP_MODE RGB_MATRIX_CYCLE_LEFT_RIGHT // Sets the default mode, if none has been set
```
## EEPROM storage
@@ -231,10 +382,10 @@ A similar function works in the keymap as `rgb_matrix_indicators_user`.
The EEPROM for it is currently shared with the RGBLIGHT system (it's generally assumed only one RGB would be used at a time), but could be configured to use its own 32bit address with:
@@ -37,9 +37,9 @@ QMK uses [Hue, Saturation, and Value](https://en.wikipedia.org/wiki/HSL_and_HSV)
<imgsrc="gitbook/images/color-wheel.svg"alt="HSV Color Wheel"width="250"/>
Changing the **Hue** cycles around the circle.
Changing the **Saturation** moves between the inner and outer sections of the wheel, affecting the intensity of the color.
Changing the **Value** sets the overall brightness.
Changing the **Hue** cycles around the circle.<br>
Changing the **Saturation** moves between the inner and outer sections of the wheel, affecting the intensity of the color.<br>
Changing the **Value** sets the overall brightness.<br>
## Keycodes
@@ -75,9 +75,9 @@ Your RGB lighting can be configured by placing these `#define`s in your `config.
|`RGBLIGHT_VAL_STEP` |`17` |The number of steps to increment the brightness by |
|`RGBLIGHT_LIMIT_VAL` |`255` |The maximum brightness level |
|`RGBLIGHT_SLEEP` |*Not defined*|If defined, the RGB lighting will be switched off when the host goes to sleep|
|`RGBLIGHT_SPLIT` |*Not defined*|If defined, synchronization functionality for split keyboards is added|
## Animations
## Effects and Animations
Not only can this lighting be whatever color you want,
if `RGBLIGHT_EFFECT_xxxx` or `RGBLIGHT_ANIMATIONS` is defined, you also have a number of animation modes at your disposal:
@@ -99,29 +99,54 @@ Check out [this video](https://youtube.com/watch?v=VKrpPAHlisY) for a demonstrat
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.
The following options can be used to tweak the various animations:
### Effect and Animation Toggles
Use these defines to add or remove animations from the firmware. When you are running low on flash space, it can be helpful to disable animations you are not using.
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:
|`rgblight_enable()` |Turn LEDs on, based on their previous state |
|`rgblight_enable_noeeprom()` |Turn LEDs on, based on their previous state (not written to EEPROM) |
|`rgblight_disable()` |Turn LEDs off |
|`rgblight_disable_noeeprom()` |Turn LEDs off (not written to EEPROM) |
|`rgblight_mode(x)` |Set the mode, if RGB animations are enabled |
|`rgblight_mode_noeeprom(x)` |Set the mode, if RGB animations are enabled (not written to EEPROM) |
|`rgblight_setrgb(r, g, b)` |Set all LEDs to the given RGB value where `r`/`g`/`b` are between 0 and 255 (not written to EEPROM) |
|`rgblight_setrgb_at(r, g, b, led)` |Set a single LED to the given RGB value, where `r`/`g`/`b` are between 0 and 255 and `led` is between 0 and `RGBLED_NUM` (not written to EEPROM) |
|`rgblight_setrgb_range(r, g, b, start, end)`|Set a continuous range of LEDs to the given RGB value, where `r`/`g`/`b` are between 0 and 255 and `start`(included) and `stop`(excluded) are between 0 and `RGBLED_NUM` (not written to EEPROM)|
|`rgblight_setrgb_master(r, g, b)` |Set the LEDs on the master side to the given RGB value, where `r`/`g`/`b` are between 0 and 255 (not written to EEPROM) |
|`rgblight_setrgb_slave(r, g, b)` |Set the LEDs on the slave side to the given RGB value, where `r`/`g`/`b` are between 0 and 255 (not written to EEPROM) |
|`rgblight_sethsv(h, s, v)` |Set all LEDs to the given HSV value where `h` is between 0 and 360 and `s`/`v` are between 0 and 255 |
|`rgblight_sethsv_noeeprom(h, s, v)` |Set all LEDs to the given HSV value where `h` is between 0 and 360 and `s`/`v` are between 0 and 255 (not written to EEPROM) |
|`rgblight_sethsv_at(h, s, v, led)` |Set a single LED to the given HSV value, where `h` is between 0 and 360, `s`/`v` are between 0 and 255, and `led` is between 0 and `RGBLED_NUM` (not written to EEPROM)|
|`rgblight_sethsv_range(h, s, v, start, end)`|Set a continuous range of LEDs to the given HSV value, where `h` is between 0 and 360, `s`/`v` are between 0 and 255, and `start`(included) and `stop`(excluded) are between 0 and `RGBLED_NUM` (not written to EEPROM)|
|`rgblight_sethsv_master(h, s, v)` |Set the LEDs on the master side to the given HSV value, where `h` is between 0 and 360, `s`/`v` are between 0 and 255 (not written to EEPROM) |
|`rgblight_sethsv_slave(h, s, v)` |Set the LEDs on the slave side to the given HSV value, where `h` is between 0 and 360, `s`/`v` are between 0 and 255 (not written to EEPROM) |
|`rgblight_toggle()` |Toggle all LEDs between on and off |
|`rgblight_toggle_noeeprom()` |Toggle all LEDs between on and off (not written to EEPROM) |
|`rgblight_step()` |Change the mode to the next RGB animation in the list of enabled RGB animations |
|`rgblight_step_noeeprom()` |Change the mode to the next RGB animation in the list of enabled RGB animations (not written to EEPROM) |
|`rgblight_step_reverse()` |Change the mode to the previous RGB animation in the list of enabled RGB animations |
|`rgblight_step_reverse_noeeprom()` |Change the mode to the previous RGB animation in the list of enabled RGB animations (not written to EEPROM) |
|`rgblight_increase_hue()` |Increase the hue for all LEDs. This wraps around at maximum hue |
|`rgblight_increase_hue_noeeprom()` |Increase the hue for all LEDs. This wraps around at maximum hue (not written to EEPROM) |
|`rgblight_decrease_hue()` |Decrease the hue for all LEDs. This wraps around at minimum hue |
|`rgblight_decrease_hue_noeeprom()` |Decrease the hue for all LEDs. This wraps around at minimum hue (not written to EEPROM) |
|`rgblight_increase_sat()` |Increase the saturation for all LEDs. This wraps around at maximum saturation |
|`rgblight_increase_sat_noeeprom()` |Increase the saturation for all LEDs. This wraps around at maximum saturation (not written to EEPROM) |
|`rgblight_decrease_sat()` |Decrease the saturation for all LEDs. This wraps around at minimum saturation |
|`rgblight_decrease_sat_noeeprom()` |Decrease the saturation for all LEDs. This wraps around at minimum saturation (not written to EEPROM) |
|`rgblight_increase_val()` |Increase the value for all LEDs. This wraps around at maximum value |
|`rgblight_increase_val_noeeprom()` |Increase the value for all LEDs. This wraps around at maximum value (not written to EEPROM) |
|`rgblight_decrease_val()` |Decrease the value for all LEDs. This wraps around at minimum value |
|`rgblight_decrease_val_noeeprom()` |Decrease the value for all LEDs. This wraps around at minimum value (not written to EEPROM) |
|`rgblight_set_clipping_range(pos, num)` |Set clipping Range |
|`rgblight_setrgb_at(r, g, b, index)` |Set a single LED to the given RGB value, where `r`/`g`/`b` are between 0 and 255 and `index` is between 0 and `RGBLED_NUM` (not written to EEPROM) |
|`rgblight_sethsv_at(h, s, v, index)` |Set a single LED to the given HSV value, where `h`/`s`/`v` are between 0 and 255, and `index` is between 0 and `RGBLED_NUM` (not written to EEPROM) |
|`rgblight_setrgb_range(r, g, b, start, end)`|Set a continuous range of LEDs to the given RGB value, where `r`/`g`/`b` are between 0 and 255 and `start`(included) and `stop`(excluded) are between 0 and `RGBLED_NUM` (not written to EEPROM)|
|`rgblight_sethsv_range(h, s, v, start, end)`|Set a continuous range of LEDs to the given HSV value, where `h`/`s`/`v` are between 0 and 255, and `start`(included) and `stop`(excluded) are between 0 and `RGBLED_NUM` (not written to EEPROM)|
|`rgblight_setrgb(r, g, b)` |Set effect range LEDs to the given RGB value where `r`/`g`/`b` are between 0 and 255 (not written to EEPROM) |
|`rgblight_setrgb_master(r, g, b)` |Set the LEDs on the master side to the given RGB value, where `r`/`g`/`b` are between 0 and 255 (not written to EEPROM) |
|`rgblight_setrgb_slave(r, g, b)` |Set the LEDs on the slave side to the given RGB value, where `r`/`g`/`b` are between 0 and 255 (not written to EEPROM) |
|`rgblight_sethsv_master(h, s, v)` |Set the LEDs on the master side to the given HSV value, where `h`/`s`/`v` are between 0 and 255 (not written to EEPROM) |
|`rgblight_sethsv_slave(h, s, v)` |Set the LEDs on the slave side to the given HSV value, where `h`/`s`/`v` are between 0 and 255 (not written to EEPROM) |
Example:
```c
rgblight_sethsv(HSV_WHITE,0);// led 0
rgblight_sethsv(HSV_RED,1);// led 1
rgblight_sethsv(HSV_GREEN,2);// led 2
// The above functions automatically calls rgblight_set(), so there is no need to call it explicitly.
// Note that it is inefficient to call repeatedly.
|`rgblight_increase_hue()` |Increase the hue for effect range LEDs. This wraps around at maximum hue |
|`rgblight_increase_hue_noeeprom()` |Increase the hue for effect range LEDs. This wraps around at maximum hue (not written to EEPROM) |
|`rgblight_decrease_hue()` |Decrease the hue for effect range LEDs. This wraps around at minimum hue |
|`rgblight_decrease_hue_noeeprom()` |Decrease the hue for effect range LEDs. This wraps around at minimum hue (not written to EEPROM) |
|`rgblight_increase_sat()` |Increase the saturation for effect range LEDs. This wraps around at maximum saturation |
|`rgblight_increase_sat_noeeprom()` |Increase the saturation for effect range LEDs. This wraps around at maximum saturation (not written to EEPROM) |
|`rgblight_decrease_sat()` |Decrease the saturation for effect range LEDs. This wraps around at minimum saturation |
|`rgblight_decrease_sat_noeeprom()` |Decrease the saturation for effect range LEDs. This wraps around at minimum saturation (not written to EEPROM) |
|`rgblight_increase_val()` |Increase the value for effect range LEDs. This wraps around at maximum value |
|`rgblight_increase_val_noeeprom()` |Increase the value for effect range LEDs. This wraps around at maximum value (not written to EEPROM) |
|`rgblight_decrease_val()` |Decrease the value for effect range LEDs. This wraps around at minimum value |
|`rgblight_decrease_val_noeeprom()` |Decrease the value for effect range LEDs. This wraps around at minimum value (not written to EEPROM) |
|`rgblight_sethsv(h, s, v)` |Set effect range LEDs to the given HSV value where `h`/`s`/`v` are between 0 and 255 |
|`rgblight_sethsv_noeeprom(h, s, v)` |Set effect range LEDs to the given HSV value where `h`/`s`/`v` are between 0 and 255 (not written to EEPROM) |
#### query
|Function |Description |
|-----------------------|-----------------|
|`rgblight_get_mode()` |Get current mode |
|`rgblight_get_hue()` |Get current hue |
|`rgblight_get_sat()` |Get current sat |
|`rgblight_get_val()` |Get current val |
## Colors
These are shorthands to popular colors. The `RGB` ones can be passed to the `setrgb` functions, while the `HSV` ones to the `sethsv` functions.
|RGB |HSV |
|-------------------|-------------------|
|`RGB_WHITE` |`HSV_WHITE` |
|`RGB_RED` |`HSV_RED` |
|`RGB_CORAL` |`HSV_CORAL` |
|`RGB_ORANGE` |`HSV_ORANGE` |
|`RGB_GOLDENROD` |`HSV_GOLDENROD` |
|`RGB_GOLD` |`HSV_GOLD` |
|`RGB_YELLOW` |`HSV_YELLOW` |
|`RGB_CHARTREUSE` |`HSV_CHARTREUSE` |
|`RGB_GREEN` |`HSV_GREEN` |
|`RGB_SPRINGGREEN` |`HSV_SPRINGGREEN` |
|`RGB_TURQUOISE` |`HSV_TURQUOISE` |
|`RGB_TEAL` |`HSV_TEAL` |
|`RGB_CYAN` |`HSV_CYAN` |
|`RGB_AZURE` |`HSV_AZURE` |
|`RGB_BLUE` |`HSV_BLUE` |
|`RGB_PURPLE` |`HSV_PURPLE` |
|`RGB_MAGENTA` |`HSV_MAGENTA` |
|`RGB_PINK` |`HSV_PINK` |
```c
rgblight_setrgb(RGB_ORANGE);
rgblight_sethsv_noeeprom(HSV_GREEN);
rgblight_setrgb_at(RGB_GOLD,3);
rgblight_sethsv_range(HSV_WHITE,0,6);
```
These are defined in [`rgblight_list.h`](https://github.com/qmk/qmk_firmware/blob/master/quantum/rgblight_list.h). Feel free to add to this list!
Additionally, [`rgblight_list.h`](https://github.com/qmk/qmk_firmware/blob/master/quantum/rgblight_list.h) defines several predefined shortcuts for various colors. Feel free to add to this list!
## Changing the order of the LEDs
@@ -266,4 +380,6 @@ In addition to setting the Clipping Range, you can use `RGBLIGHT_LED_MAP` togeth
If your keyboard lacks onboard underglow LEDs, you may often be able to solder on an RGB LED strip yourself. You will need to find an unused pin to wire to the data pin of your LED strip. Some keyboards may break out unused pins from the MCU to make soldering easier. The other two pins, VCC and GND, must also be connected to the appropriate power pins.
Steve Losh described the [Space Cadet Shift](http://stevelosh.com/blog/2012/10/a-modern-space-cadet/) quite well. Essentially, when you tap Left Shift on its own, you get an opening parenthesis; tap Right Shift on its own and you get the closing one. When held, the Shift keys function as normal. Yes, it's as cool as it sounds, and now even cooler supporting Control and Alt as well!
## Usage
Firstly, in your keymap, do one of the following:
- Replace the Left Shift key with `KC_LSPO` (Left Shift, Parenthesis Open), and Right Shift with `KC_RSPC` (Right Shift, Parenthesis Close).
- Replace the Left Control key with `KC_LCPO` (Left Control, Parenthesis Open), and Right Control with `KC_RCPC` (Right Control, Parenthesis Close).
- Replace the Left Alt key with `KC_LAPO` (Left Alt, Parenthesis Open), and Right Alt with `KC_RAPC` (Right Alt, Parenthesis Close).
- Replace any Shift key in your keymap with `KC_SFTENT` (Right Shift, Enter).
|`KC_LSPO` |Left Shift when held, `(` when tapped |
|`KC_RSPC` |Right Shift when held, `)` when tapped |
|`KC_LCPO` |Left Control when held, `(` when tapped |
|`KC_RCPC` |Right Control when held, `)` when tapped |
|`KC_LAPO` |Left Alt when held, `(` when tapped |
|`KC_RAPC` |Right Alt when held, `)` when tapped |
|`KC_SFTENT`|Right Shift when held, Enter when tapped |
## Caveats
Space Cadet's functionality can conflict with the default Command functionality when both Shift keys are held at the same time. See the [Command feature](feature_command.md) for info on how to change it, or make sure that Command is disabled in your `rules.mk` with:
```make
COMMAND_ENABLE= no
```
## Configuration
By default Space Cadet assumes a US ANSI layout, but if your layout uses different keys for parentheses, you can redefine them in your `config.h`. In addition, you can redefine the modifier to send on tap, or even send no modifier at all. The new configuration defines bundle all options up into a single define of 3 key codes in this order: the `Modifier` when held or when used with other keys, the `Tap Modifer` sent when tapped (no modifier if `KC_TRNS`), finally the `Keycode` sent when tapped. Now keep in mind, mods from other keys will still apply to the `Keycode` if say `KC_RSFT` is held while tapping `KC_LSPO` key with `KC_TRNS` as the `Tap Modifer`.
|`LSPO_KEYS` |`KC_LSFT, LSPO_MOD, LSPO_KEY` |Send `KC_LSFT` when held, the mod and key defined by `LSPO_MOD` and `LSPO_KEY`. |
|`RSPC_KEYS` |`KC_RSFT, RSPC_MOD, RSPC_KEY` |Send `KC_RSFT` when held, the mod and key defined by `RSPC_MOD` and `RSPC_KEY`. |
|`LCPO_KEYS` |`KC_LCTL, KC_LSFT, KC_9` |Send `KC_LCTL` when held, the mod `KC_LSFT` with the key `KC_9` when tapped. |
|`RCPC_KEYS` |`KC_RCTL, KC_RSFT, KC_0` |Send `KC_RCTL` when held, the mod `KC_RSFT` with the key `KC_0` when tapped. |
|`LAPO_KEYS` |`KC_LALT, KC_LSFT, KC_9` |Send `KC_LALT` when held, the mod `KC_LSFT` with the key `KC_9` when tapped. |
|`RAPC_KEYS` |`KC_RALT, KC_RSFT, KC_0` |Send `KC_RALT` when held, the mod `KC_RSFT` with the key `KC_0` when tapped. |
|`SFTENT_KEYS` |`KC_RSFT, KC_TRNS, SFTENT_KEY` |Send `KC_RSFT` when held, no mod with the key `SFTENT_KEY` when tapped. |
|`SPACE_CADET_MODIFIER_CARRYOVER` |*Not defined* |Store current modifiers before the hold mod is pressed and use them with the tap mod and keycode. Useful for when you frequently release a modifier before triggering Space Cadet. |
## Obsolete Configuration
These defines are used in the above defines internally to support backwards compatibility, so you may continue to use them, however the above defines open up a larger range of flexibility than before. As an example, say you want to not send any modifier when you tap just `KC_LSPO`, with the old defines you had an all or nothing choice of using the `DISABLE_SPACE_CADET_MODIFIER` define. Now you can define that key as: `#define LSPO_KEYS KC_LSFT, KC_TRNS, KC_9`. This tells the system to set Left Shift if held or used with other keys, then on tap send no modifier (transparent) with the `KC_9`.
Steve Losh described the [Space Cadet Shift](http://stevelosh.com/blog/2012/10/a-modern-space-cadet/) quite well. Essentially, when you tap Left Shift on its own, you get an opening parenthesis; tap Right Shift on its own and you get the closing one. When held, the Shift keys function as normal. Yes, it's as cool as it sounds.
## Usage
Replace the Left Shift key in your keymap with `KC_LSPO` (Left Shift, Parenthesis Open), and Right Shift with `KC_RSPC` (Right Shift, Parenthesis Close).
|`KC_LSPO`|Left Shift when held, `(` when tapped |
|`KC_RSPC`|Right Shift when held, `)` when tapped|
## Caveats
Space Cadet's functionality can conflict with the default Command functionality when both Shift keys are held at the same time. Make sure that Command is disabled in your `rules.mk` with:
```make
COMMAND_ENABLE= no
```
## Configuration
By default Space Cadet assumes a US ANSI layout, but if your layout uses different keys for parentheses, you can redefine them in your `config.h`.
You can also disable the rollover, allowing you to use the opposite Shift key to cancel the Space Cadet state in the event of an erroneous press, instead of emitting a pair of parentheses when the keys are released.
Also, by default, the Space Cadet applies modifiers LSPO_MOD and RSPC_MOD to keys defined by LSPO_KEY and RSPC_KEY. You can override this behavior by redefining those variables in your `config.h`. You can also prevent the Space Cadet to apply a modifier by defining DISABLE_SPACE_CADET_MODIFIER in your `config.h`.
Based on the [Space Cadet Shift](feature_space_cadet_shift.md) feature. Tap the Shift key on its own, and it behaves like Enter. When held, the Shift functions as normal.
## Usage
Replace any Shift key in your keymap with `KC_SFTENT` (Shift, Enter), and you're done.
Many keyboards in the QMK Firmware repo are "split" keyboards. They use two controllers—one plugging into USB, and the second connected by a serial or an I<sup>2</sup>C connection over a TRRS or similar cable.
Split keyboards can have a lot of benefits, but there is some additional work needed to get them enabled.
QMK Firmware has a generic implementation that is usable by any board, as well as numerous board specific implementations.
For this, we will mostly be talking about the generic implementation used by the Let's Split and other keyboards.
!> ARM is not yet supported for Split Keyboards. Progress is being made, but we are not quite there, yet.
## Hardware Configuration
This assumes that you're using two Pro Micro-compatible controllers, and are using TRRS jacks to connect to two halves.
### Required Hardware
Apart from diodes and key switches for the keyboard matrix in each half, you will need 2x TRRS sockets and 1x TRRS cable.
Alternatively, you can use any sort of cable and socket that has at least 3 wires.
If you want to use I<sup>2</sup>C to communicate between halves, you will need a cable with at least 4 wires and 2x 4.7kΩ pull-up resistors.
#### Considerations
The most commonly used connection is a TRRS cable and jacks. These provide 4 wires, making them very useful for split keyboards, and are easy to find.
However, since one of the wires carries VCC, this means that the boards are not hot pluggable. You should always disconnect the board from USB before unplugging and plugging in TRRS cables, or you can short the controller, or worse.
Another option is to use phone cables (as in, old school RJ-11/RJ-14 cables). Make sure that you use one that actually supports 4 wires/lanes.
However, USB cables, SATA cables, and even just 4 wires have been known to be used for communication between the controllers.
!> Using USB cables for communication between the controllers works just fine, but the connector could be mistaken for a normal USB connection and potentially short out the keyboard, depending on how it's wired. For this reason, they are not recommended for connecting split keyboards.
### Serial Wiring
The 3 wires of the TRS/TRRS cable need to connect GND, VCC, and D0 (aka PDO or pin 3) between the two Pro Micros.
?> Note that the pin used here is actually set by `SOFT_SERIAL_PIN` below.

### I<sup>2</sup>C Wiring
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. It is also possible to use 4 resistors and have the pull-ups in both halves, but this is unnecessary in simple use cases.

## Firmware Configuration
To enable the split keyboard feature, add the following to your `rules.mk`:
```make
SPLIT_KEYBOARD= yes
```
If you're using a custom transport (communication method), then you will also need to add:
```make
SPLIT_TRANSPORT= custom
```
### Setting Handedness
By default, the firmware does not know which side is which; it needs some help to determine that. There are several ways to do this, listed in order of precedence.
#### Handedness by Pin
You can configure the firmware to read a pin on the controller to determine handedness. To do this, add the following to your `config.h` file:
```c
#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.
#### Handedness by EEPROM
This method sets the keyboard's handedness by setting a flag in the persistent storage (`EEPROM`). This is checked when the controller first starts up, and determines what half the keyboard is, and how to orient the keyboard layout.
To enable this method, add the following to your `config.h` file:
```c
#define EE_HANDS
```
However, you'll have to flash the EEPROM files for the correct hand to each controller. You can do this manually, or there are targets for avrdude and dfu to do this, while flashing the firmware:
*`:avrdude-split-left`
*`:avrdude-split-right`
*`:dfu-split-left`
*`:dfu-split-right`
This setting is not changed when re-initializing the EEPROM using the `EEP_RST` key, or using the `eeconfig_init()` function. However, if you reset the EEPROM outside of the firmware's built in options (such as flashing a file that overwrites the `EEPROM`, like how the [QMK Toolbox]()'s "Reset EEPROM" button works), you'll need to re-flash the controller with the `EEPROM` files.
You can find the `EEPROM` files in the QMK firmware repo, [here](https://github.com/qmk/qmk_firmware/tree/master/quantum/split_common).
#### Handedness by `#define`
You can set the handedness at compile time. This is done by adding the following to your `config.h` file:
```c
#define MASTER_RIGHT
```
or
```c
#define MASTER_LEFT
```
If neither are defined, the handedness defaults to `MASTER_LEFT`.
### Communication Options
Because not every split keyboard is identical, there are a number of additional options that can be configured in your `config.h` file.
```c
#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.
```c
#define SOFT_SERIAL_PIN D0
```
This sets the pin to be used for serial communication. If you're not using serial, you shouldn't need to define this.
However, if you are using serial and I<sup>2</sup>C on the board, you will need to set this, and to something other than D0 and D1 (as these are used for I<sup>2</sup>C communication).
```c
#define SELECT_SOFT_SERIAL_SPEED {#}`
```
If you're having issues with serial communication, you can change this value, as it controls the communication speed for serial. The default is 1, and the possible values are:
* **`0`**: about 189kbps (Experimental only)
* **`1`**: about 137kbps (default)
* **`2`**: about 75kbps
* **`3`**: about 39kbps
* **`4`**: about 26kbps
* **`5`**: about 20kbps
### Hardware Configuration Options
There are some settings that you may need to configure, based on how the hardware is set up.
```c
#define MATRIX_ROW_PINS_RIGHT { <row pins> }
#define MATRIX_COL_PINS_RIGHT { <col pins> }
```
This allows you to specify a different set of pins for the matrix on the right side. This is useful if you have a board with differently-shaped halves that requires a different configuration (such as Keebio's Quefrency).
This allows you to specify a different set of encoder pins for the right side.
```c
#define RGBLIGHT_SPLIT
```
This option enables synchronization of the RGB Light modes between the controllers of the split keyboard. This is for keyboards that have RGB LEDs that are directly wired to the controller (that is, they are not using the "extra data" option on the TRRS cable).
```c
#define RGBLED_SPLIT { 6, 6 }
```
This sets how many LEDs are directly connected to each controller. The first number is the left side, and the second number is the right side.
?> This setting implies that `RGBLIGHT_SPLIT` is enabled, and will forcibly enable it, if it's not.
## Additional Resources
Nicinabox has a [very nice and detailed guide](https://github.com/nicinabox/lets-split-guide) for the Let's Split keyboard, that covers most everything you need to know, including troubleshooting information.
However, the RGB Light section is out of date, as it was written long before the RGB Split code was added to QMK Firmware. Instead, wire each strip up directly to the controller.
<!-- I may port this information later, but for now ... it's very nice, and covers everything -->
# Tap Dance: A Single Key Can Do 3, 5, or 100 Different Things
<!-- FIXME: Break this up into multiple sections -->
## Introduction
Hit the semicolon key once, send a semicolon. Hit it twice, rapidly -- send a colon. Hit it three times, and your keyboard's LEDs do a wild dance. That's just one example of what Tap Dance can do. It's one of the nicest community-contributed features in the firmware, conceived and created by [algernon](https://github.com/algernon) in [#451](https://github.com/qmk/qmk_firmware/pull/451). Here's how algernon describes the feature:
With this feature one can specify keys that behave differently, based on the amount of times they have been tapped, and when interrupted, they get handled before the interrupter.
To make it clear how this is different from `ACTION_FUNCTION_TAP`, let's explore a certain setup! We want one key to send `Space` on single tap, but `Enter` on double-tap.
## Explanatory Comparison with `ACTION_FUNCTION_TAP`
`ACTION_FUNCTION_TAP` can offer similar functionality to Tap Dance, but it's worth noting some important differences. To do this, let's explore a certain setup! We want one key to send `Space` on single-tap, but `Enter` on double-tap.
With `ACTION_FUNCTION_TAP`, it is quite a rain-dance to set this up, and has the problem that when the sequence is interrupted, the interrupting key will be sent first. Thus, `SPC a` will result in `a SPC` being sent, if they are typed within `TAPPING_TERM`. With the tap dance feature, that'll come out as `SPC a`, correctly.
With `ACTION_FUNCTION_TAP`, it is quite a rain-dance to set this up, and has the problem that when the sequence is interrupted, the interrupting key will be sent first. Thus, `SPC a` will result in `a SPC` being sent, if `SPC` and `a` are both typed within `TAPPING_TERM`. With the Tap Dance feature, that'll come out correctly as `SPC a` (even if both `SPC` and `a` are typed within the `TAPPING_TERM`.
The implementation hooks into two parts of the system, to achieve this: into`process_record_quantum()`, and the matrix scan. We need the latter to be able to time out a tap sequence even when a key is not being pressed, so`SPC` alone will time out and register after `TAPPING_TERM` time.
To achieve this correct handling of interrupts, the implementation of Tap Dance hooks into two parts of the system:`process_record_quantum()`, and the matrix scan. These two parts are explained below, but for now the point to note is that we need the latter to be able to time out a tap sequence even when a key is not being pressed. That way,`SPC` alone will time out and register after `TAPPING_TERM` time.
But lets start with how to use it, first!
## How to Use Tap Dance
But enough of the generalities; lets look at how to actually use Tap Dance!
First, you will need `TAP_DANCE_ENABLE=yes` in your `rules.mk`, because the feature is disabled by default. This adds a little less than 1k to the firmware size. Next, you will want to define some tap-dance keys, which is easiest to do with the `TD()` macro, that - similar to `F()`, takes a number, which will later be used as an index into the `tap_dance_actions` array.
First, you will need `TAP_DANCE_ENABLE=yes` in your `rules.mk`, because the feature is disabled by default. This adds a little less than 1k to the firmware size.
This array specifies what actions shall be taken when a tap-dance key is in action. Currently, there are five possible options:
Optionally, you might want to set a custom `TAPPING_TERM` time by adding something like this in you `config.h`:
```
#define TAPPING_TERM 175
```
The `TAPPING_TERM` time is the maximum time allowed between taps of your Tap Dance key, and is measured in milliseconds. For example, if you used the above `#define` statement and set up a Tap Dance key that sends `Space` on single-tap and `Enter` on double-tap, then this key will send `ENT` only if you tap this key twice in less than 175ms. If you tap the key, wait more than 175ms, and tap the key again you'll end up sending `SPC SPC` instead.
Next, you will want to define some tap-dance keys, which is easiest to do with the `TD()` macro, that - similar to `F()` - takes a number, which will later be used as an index into the `tap_dance_actions` array.
After this, you'll want to use the `tap_dance_actions` array to specify what actions shall be taken when a tap-dance key is in action. Currently, there are five possible options:
*`ACTION_TAP_DANCE_DOUBLE(kc1, kc2)`: Sends the `kc1` keycode when tapped once, `kc2` otherwise. When the key is held, the appropriate keycode is registered: `kc1` when pressed and held, `kc2` when tapped once, then pressed and held.
*`ACTION_TAP_DANCE_DUAL_ROLE(kc, layer)`: Sends the `kc` keycode when tapped once, or moves to `layer`. (this functions like the `TO` layer keycode).
@@ -24,17 +35,22 @@ This array specifies what actions shall be taken when a tap-dance key is in acti
*`ACTION_TAP_DANCE_FN_ADVANCED(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn)`: Calls the first specified function - defined in the user keymap - on every tap, the second function when the dance action finishes (like the previous option), and the last function when the tap dance action resets.
*`ACTION_TAP_DANCE_FN_ADVANCED_TIME(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn, tap_specific_tapping_term)`: This functions identically to the `ACTION_TAP_DANCE_FN_ADVANCED` function, but uses a custom tapping term for it, instead of the predefined `TAPPING_TERM`.
The first option is enough for a lot of cases, that just want dual roles. For example, `ACTION_TAP_DANCE_DOUBLE(KC_SPC, KC_ENT)` will result in `Space` being sent on single-tap, `Enter` otherwise.
The first option is enough for a lot of cases, that just want dual roles. For example, `ACTION_TAP_DANCE_DOUBLE(KC_SPC, KC_ENT)` will result in `Space` being sent on single-tap, `Enter` otherwise.
!> Keep in mind that only [basic keycodes](keycodes_basic.md) are supported here. Custom keycodes are not supported.
And that's the bulk of it!
Similar to the first option, the second option is good for simple layer-switching cases.
And now, on to the explanation of how it works!
For more complicated cases, use the third or fourth options (examples of each are listed below).
The main entry point is `process_tap_dance()`, called from `process_record_quantum()`, which is run for every keypress, and our handler gets to run early. This function checks whether the key pressed is a tap-dance key. If it is not, and a tap-dance was in action, we handle that first, and enqueue the newly pressed key. If it is a tap-dance key, then we check if it is the same as the already active one (if there's one active, that is). If it is not, we fire off the old one first, then register the new one. If it was the same, we increment the counter and the timer.
Finally, the fifth option is particularly useful if your non-Tap-Dance keys start behaving weirdly after adding the code for your Tap Dance keys. The likely problem is that you changed the `TAPPING_TERM`time to make your Tap Dance keys easier for you to use, and that this has changed the way your other keys handle interrupts.
This means that you have `TAPPING_TERM` time to tap the key again, you do not have to input all the taps within that timeframe. This allows for longer tap counts, with minimal impact on responsiveness.
## Implementation Details
Well, that's the bulk of it! You should now be able to work through the examples below, and to develop your own Tap Dance functionality. But if you want a deeper understanding of what's going on behind the scenes, then read on for the explanation of how it all works!
The main entry point is `process_tap_dance()`, called from `process_record_quantum()`, which is run for every keypress, and our handler gets to run early. This function checks whether the key pressed is a tap-dance key. If it is not, and a tap-dance was in action, we handle that first, and enqueue the newly pressed key. If it is a tap-dance key, then we check if it is the same as the already active one (if there's one active, that is). If it is not, we fire off the old one first, then register the new one. If it was the same, we increment the counter and reset the timer.
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.
Wrap each tapdance keycode in `TD()` when including it in your keymap, e.g. `TD(ALT_LP)`.
### Example 6: Using tap dance for momentary-layer-switch and layer-toggle keys
Tap Dance can be used to mimic MO(layer) and TG(layer) functionality. For this example, we will set up a key to function as `KC_QUOT` on single-tap, as `MO(_MY_LAYER)` on single-hold, and `TG(_MY_LAYER)` on double-tap.
The first step is to include the following code towards the beginning of your `keymap.c`:
```
typedef struct {
bool is_press_action;
int state;
} tap;
//Define a type for as many tap dance states as you need
enum {
SINGLE_TAP = 1,
SINGLE_HOLD = 2,
DOUBLE_TAP = 3
};
enum {
QUOT_LAYR = 0 //Our custom tap dance key; add any other tap dance keys to this enum
};
//Declare the functions to be used with your tap dance key(s)
The above code is similar to that used in previous examples. The one point to note is that you need to declare a variable to keep track of what layer is currently the active layer. We'll see why shortly.
Towards the bottom of your `keymap.c`, include the following code:
```
//Update active_layer
uint32_t layer_state_set_user(uint32_t state) {
switch (biton32(state)) {
case 1:
active_layer = 1;
break;
case 2:
active_layer = 2;
break;
case 3:
active_layer = 3;
break;
default:
active_layer = 0;
break;
}
return state;
}
//Determine the current tap dance state
int cur_dance (qk_tap_dance_state_t *state) {
if (state->count == 1) {
if (!state->pressed) {return SINGLE_TAP;}
else return SINGLE_HOLD;
} else if (state->count == 2) {return DOUBLE_TAP;}
else return 8;
}
//Initialize tap structure associated with example tap dance key
static tap ql_tap_state = {
.is_press_action = true,
.state = 0
};
//Functions that control what our tap dance key does
The is where the real logic of our tap dance key gets worked out. Since `layer_state_set_user()` is called on any layer switch, we use it to update `active_layer`. Our example is assuming that your `keymap.c` includes 4 layers, so adjust the switch statement here to fit your actual number of layers.
The use of `cur_dance()` and `ql_tap_state` mirrors the above examples.
The `case:SINGLE_TAP` in `ql_finished` is similar to the above examples. The `case:SINGLE_HOLD` works in conjunction with `ql_reset()` to switch to `_MY_LAYER` while the tap dance key is held, and to switch away from `_MY_LAYER` when the key is released. This mirrors the use of `MO(_MY_LAYER)`. The `case:DOUBLE_TAP` works by checking whether `_MY_LAYER` is the active layer, and toggling it on or off accordingly. This mirrors the use of `TG(_MY_LAYER)`.
`tap_dance_actions[]` works similar to the above examples. Note that I used `ACTION_TAP_DANCE_FN_ADVANCED_TIME()` instead of `ACTION_TAP_DANCE_FN_ADVANCED()`. This is because I like my `TAPPING_TERM` to be short (~175ms) for my non-tap-dance keys but find that this is too quick for me to reliably complete tap dance actions - thus the increased time of 275ms here.
Finally, to get this tap dance key working, be sure to include `TD(QUOT_LAYR)` in your `keymaps[]`.
There are three Unicode keymap definition methods available in QMK:
Unicode characters can be input straight from your keyboard! There are some limitations, however.
## `UNICODE_ENABLE`
QMK has three different methods for enabling Unicode input and defining keycodes:
Supports Unicode up to `0x7FFF`. This covers characters for most modern languages, as well as symbols, but it doesn't cover emoji. The keycode function is `UC(c)` in the keymap file, where _c_ is the code point's number (preferably hexadecimal, up to 4 digits long). For example: `UC(0x45B)`, `UC(0x30C4)`.
## Basic Unicode
## `UNICODEMAP_ENABLE`
This method supports Unicode code points up to `0x7FFF`. This covers characters for most modern languages, as well as symbols, but it doesn't cover emoji.
Supports Unicode up to `0x10FFFF` (all possible code points). You need to maintain a separate mapping table `const uint32_t PROGMEM unicode_map[] = {...}` in your keymap file. The keycode function is `X(i)`, where _i_ is an array index into the mapping table. The table may contain at most 1024 entries.
Add the following to your `rules.mk`:
You may want to have an enum to make referencing easier. So, you could add something like this to your keymap file:
```make
UNICODE_ENABLE= yes
```
Then add `UC(c)` keycodes to your keymap, where _c_ is the code point (preferably in hexadecimal, up to 4 digits long). For example: `UC(0x45B)`, `UC(0x30C4)`.
## Unicode Map
This method supports all possible code points (up to `0x10FFFF`); however, you need to maintain a separate mapping table in your keymap file, which may contain at most 16384 entries.
Add the following to your `rules.mk`:
```make
UNICODEMAP_ENABLE= yes
```
Then add `X(i)` keycodes to your keymap, where _i_ is an array index into the mapping table:
```c
enumunicode_names{
BANG,
IRONY,
SNEK,
BANG,
IRONY,
SNEK
};
constuint32_tPROGMEMunicode_map[]={
[BANG]=0x203D,// ‽
[IRONY]=0x2E2E,// ⸮
[SNEK]=0x1F40D,// 🐍
[BANG]=0x203D,// ‽
[IRONY]=0x2E2E,// ⸮
[SNEK]=0x1F40D,// 🐍
};
```
Then you can use `X(BANG)` etc. in your keymap.
Then you can use `X(BANG)`, `X(SNEK)` etc. in your keymap.
## `UCIS_ENABLE`
### Lower and Upper Case
Supports Unicode up to `0x10FFFF` (all possible code points). As with `UNICODEMAP`, you need to maintain a mapping table in your keymap file. However, there are no built-in keycodes for this feature — you will have to add a keycode or function that calls `qk_ucis_start()`. Once this function's been called, you can type the corresponding mnemonic for your character, then hit Space or Enter to complete it, or Esc to cancel. If the mnemonic matches an entry in your table, the typed text will automatically be erased and the corresponding Unicode character inserted.
Characters often come in lower and upper case pairs, such as å and Å. To make inputting these characters easier, you can use `XP(i, j)` in your keymap, where _i_ and _j_ are the mapping table indices of the lower and upper case character, respectively. If you're holding down Shift or have Caps Lock turned on when you press the key, the second (upper case) character will be inserted; otherwise, the first (lower case) version will appear.
For instance, you would define a table like this in your keymap file:
This is most useful when creating a keymap for an international layout with special characters. Instead of having to put the lower and upper case versions of a character on separate keys, you can have them both on the same key by using `XP()`. This helps blend Unicode keys in with regular alphas.
Due to keycode size constraints, _i_ and _j_ can each only refer to one of the first 128 characters in your `unicode_map`. In other words, 0 ≤ _i_ ≤ 127 and 0 ≤ _j_ ≤ 127. This is enough for most use cases, but if you'd like to customize the index calculation, you can override the [`unicodemap_index()`](https://github.com/qmk/qmk_firmware/blob/71f640d47ee12c862c798e1f56392853c7b1c1a8/quantum/process_keycode/process_unicodemap.c#L40) function. This also allows you to, say, check Ctrl instead of Shift/Caps.
## UCIS
This method also supports all possible code points. As with the Unicode Map method, you need to maintain a mapping table in your keymap file. However, there are no built-in keycodes for this feature — you have to create a custom keycode or function that invokes this functionality.
Add the following to your `rules.mk`:
```make
UCIS_ENABLE= yes
```
Then define a table like this in your keymap file:
You call `qk_ucis_start()`, then type "rofl" and hit Enter. QMK should erase the "rofl" text and input the laughing emoji.
To use it, call `qk_ucis_start()`. Then, type the mnemonic for the character (such as "rofl"), and hit Space or Enter. QMK should erase the "rofl" text and insert the laughing emoji.
### Customization
@@ -60,28 +90,29 @@ Unicode input in QMK works by inputting a sequence of characters to the OS, sort
The following input modes are available:
* **`UC_OSX`**: MacOS X built-in Unicode hex input. Supports code points up to `0xFFFF` (`0x10FFFF` with `UNICODEMAP`).
* **`UC_OSX`**: macOS built-in Unicode hex input. Supports code points up to `0xFFFF` (`0x10FFFF` with Unicode Map).
To enable, go to _System Preferences > Keyboard > Input Sources_, add _Unicode Hex Input_ to the list (it's under _Other_), then activate it from the input dropdown in the Menu Bar.
By default, this mode uses the left Option key (`KC_LALT`), but this can be changed by defining [`UNICODE_OSX_KEY`](#input-key-configuration) with another keycode.
By default, this mode uses the left Option key (`KC_LALT`) for Unicode input, but this can be changed by defining [`UNICODE_KEY_OSX`](#input-key-configuration) with another keycode.
**Note:** Using the _Unicode Hex Input_ input source may disable some Option based shortcuts, such as: Option + Left Arrow (`moveWordLeftAndModifySelection`) and Option + Right Arrow (`moveWordRightAndModifySelection`).
!> Using the _Unicode Hex Input_ input source may disable some Option based shortcuts, such as Option + Left Arrow and Option + Right Arrow.
* **`UC_LNX`**: Linux built-in IBus Unicode input. Supports code points up to `0x10FFFF` (all possible code points).
Enabled by default and works almost anywhere on IBus-enabled distros. Without IBus, this mode works under GTK apps, but rarely anywhere else.
By default, this mode uses Ctrl+Shift+U (`LCTL(LSFT(KC_U))`) to start Unicode input, but this can be changed by defining [`UNICODE_KEY_LNX`](#input-key-configuration) with another keycode. This might be required for IBus versions ≥1.5.15, where Ctrl+Shift+U behavior is consolidated into Ctrl+Shift+E.
* **`UC_WIN`**: _(not recommended)_ Windows built-in hex numpad Unicode input. Supports code points up to `0xFFFF`.
To enable, create a registry key under `HKEY_CURRENT_USER\Control Panel\Input Method\EnableHexNumpad` of type `REG_SZ` called `EnableHexNumpad` and set its value to `1`. This can be done from the Command Prompt by running `reg add "HKCU\Control Panel\Input Method" -v EnableHexNumpad -t REG_SZ -d 1` with administrator privileges. Afterwards, reboot.
To enable, create a registry key under `HKEY_CURRENT_USER\Control Panel\Input Method\EnableHexNumpad` of type `REG_SZ` called `EnableHexNumpad` and set its value to `1`. This can be done from the Command Prompt by running `reg add "HKCU\Control Panel\Input Method" -v EnableHexNumpad -t REG_SZ -d 1` with administrator privileges. Reboot afterwards.
This mode is not recommended because of reliability and compatibility issues; use the `UC_WINC` mode instead.
* **`UC_BSD`**: _(non implemented)_ Unicode input under BSD. Not implemented at this time. If you're a BSD user and want to help add support for it, please [open an issue on GitHub](https://github.com/qmk/qmk_firmware/issues).
* **`UC_WINC`**: Windows Unicode input using [WinCompose](https://github.com/samhocevar/wincompose). As of v0.8.2, supports code points up to `0xFFFFF` (all currently assigned code points).
* **`UC_WINC`**: Windows Unicode input using [WinCompose](https://github.com/samhocevar/wincompose). As of v0.9.0, supports code points up to `0x10FFFF` (all possible code points).
To enable, install the [latest release](https://github.com/samhocevar/wincompose/releases/latest). Once installed, WinCompose will automatically run on startup. Works reliably under all version of Windows supported by the app.
By default, this mode uses the right Alt key (`KC_RALT`), but this can be changed in the WinCompose settings and by defining [`UNICODE_WINC_KEY`](#input-key-configuration) with another keycode.
By default, this mode uses right Alt (`KC_RALT`) as the Compose key, but this can be changed in the WinCompose settings and by defining [`UNICODE_KEY_WINC`](#input-key-configuration) with another keycode.
### Switching Input Modes
@@ -89,21 +120,21 @@ There are two ways to set the input mode for Unicode: by keycode or by function.
You can switch the input mode at any time by using one of the following keycodes. The easiest way is to add the ones you use to your keymap.
|`UNICODE_MODE_FORWARD`|`UC_MOD` |Next in list|[Cycle](#input-mode-cycling) through selected modes |
|`UNICODE_MODE_REVERSE`|`UC_RMOD`|Prev in list|[Cycle](#input-mode-cycling) through selected modes in reverse|
|`UNICODE_MODE_OSX` |`UC_M_OS`|`UC_OSX` |Switch to macOS input |
|`UNICODE_MODE_LNX` |`UC_M_LN`|`UC_LNX` |Switch to Linux input |
|`UNICODE_MODE_WIN` |`UC_M_WI`|`UC_WIN` |Switch to Windows input |
|`UNICODE_MODE_BSD` |`UC_M_BS`|`UC_BSD` |Switch to BSD input (not implemented) |
|`UNICODE_MODE_WINC` |`UC_M_WC`|`UC_WINC` |Switch to Windows input using WinCompose|
You can also switch the input mode by calling `set_unicode_input_mode(x)` in your code, where _x_ is one of the above input mode constants (e.g. `UC_LNX`). Since the function only needs to be called once, it's recommended that you do it in `eeconfig_init_user` (or a similar function). For example:
You can also switch the input mode by calling `set_unicode_input_mode(x)` in your code, where _x_ is one of the above input mode constants (e.g. `UC_LNX`). Since the function only needs to be called once, it's recommended that you do it in `eeconfig_init_user()` (or a similar function). For example:
```c
voideeconfig_init_user(void){
set_unicode_input_mode(UC_LNX);
set_unicode_input_mode(UC_LNX);
}
```
@@ -123,35 +154,45 @@ For instance, you can add these definitions to your `config.h` file:
### Additional Customization
Because Unicode is such a large and variable feature, there are a number of options that you can customize to work better on your system.
Because Unicode is a large and versatile feature, there are a number of options you can customize to make it work better on your system.
#### Start and Finish input functions
#### Start and Finish Input Functions
The functions for starting and finishing Unicode input on your platform can be overridden locally. Possible uses include customizing input mode behavior if you don't use the default keys, or adding extra visual/audio feedback to Unicode input.
*`void unicode_input_start(void)`– This sends the initial sequence that tells your platform to enter Unicode input mode. For example, it presses Ctrl+Shift+U on Linux and holds the Option key on Mac.
*`void unicode_input_start(void)`– This sends the initial sequence that tells your platform to enter Unicode input mode. For example, it presses Ctrl+Shift+U on Linux and holds the Option key on macOS.
*`void unicode_input_finish(void)`– This is called to exit Unicode input mode, for example by pressing Space or releasing the Option key.
You can find the default implementations of these functions in [`process_unicode_common.c`](https://github.com/qmk/qmk_firmware/blob/master/quantum/process_keycode/process_unicode_common.c).
#### Input Key Configuration
Additionally, you can customize the keys used to trigger the unicode input for macOS and WinCompose by adding defines to your `config.h`
You can customize the keys used to trigger Unicode input for macOS, Linux and WinCompose by adding corresponding defines to your `config.h`. The default values match the platforms' default settings, so you shouldn't need to change this unless Unicode input isn't working, or you want to use a different key (e.g. in order to free up left or right Alt).
You can choose which input modes are available for cycling through. By default, this is disabled. If you want to enable it, limiting it to just the modes you use makes sense. Note that the values in the list are comma-delimited.
You can cycle through the selected modes by using the `UC_MOD`/`UC_RMOD` keycodes, or by calling `cycle_unicode_input_mode(offset)` in your code (`offset` is how many modes to move forward by, so +1 corresponds to `UC_MOD`).
Also, you can choose which input methods are availble for cycling through. By default, this is disabled. But if you want to enabled it, then limiting it to just those modes makes sense. Note that `UNICODE_SELECTED_MODES` define is comma delimited.
By default, when the keyboard boots, it will initialize the input mode to the last one you used. You can disable this and make it start with the first mode in the list every time by adding the following to your `config.h`:
!> Using `UNICODE_SELECTED_MODES` means you don't have to initially set the input mode in `matrix_init_user()` (or a similar function); the Unicode system will do that for you on startup. This has the added benefit of avoiding unnecessary writes to EEPROM.
## `send_unicode_hex_string`
To type multiple characters for things like (ノಠ痊ಠ)ノ彡┻━┻, you can use `send_unicode_hex_string()` much like `SEND_STRING()` except you would use hex values separate by spaces.
@@ -110,16 +110,16 @@ QMK has a bunch of [functions](custom_quantum_functions.md) that have [`_quantum
However, you can actually add support for keymap version, so that you can use it in both your userspace and your keymap!
For instance, lets looks at the `layer_state_set_user` function. Lets enable the [Tri Layer State](ref_functions.md#olkb-tri-layers) functionalitly to all of our boards, and then still have your `keymap.c` still able to use this functionality.
For instance, let's look at the `layer_state_set_user()` function. You can enable the [Tri Layer State](ref_functions.md#olkb-tri-layers) functionality on all of your boards, while also retaining the Tri Layer functionality in your `keymap.c` files.
* [Grave Escape](feature_grave_esc.md) - Lets you use a single key for Esc and Grave.
* [Haptic Feedback](feature_haptic_feedback.md) - Add haptic feedback drivers to your board.
* [HD44780 LCD Display](feature_hd44780.md) - Support for LCD character displays using the HD44780 standard.
* [Key Lock](feature_key_lock.md) - Lock a key in the "down" state.
* [Layouts](feature_layouts.md) - Use one keymap with any keyboard that supports your layout.
@@ -20,12 +23,14 @@ QMK has a staggering number of features for building your keyboard. It can take
* [LED Matrix](feature_led_matrix.md) - LED Matrix single color lights for per key lighting (Single Color, not RGB).
* [Macros](feature_macros.md) - Send multiple key presses when pressing only one physical key.
* [Mouse keys](feature_mouse_keys.md) - Control your mouse pointer from your keyboard.
* [One Shot Keys](feature_advanced_keycodes.md#one-shot-keys) - Sticky Keys, lets hit a key rather than holding it.
* [OLED Driver](feature_oled_driver.md) - Add OLED screens to your keyboard.
* [One Shot Keys](feature_advanced_keycodes.md#one-shot-keys) - Sticky Keys, lets you hit a key rather than holding it.
* [Pointing Device](feature_pointing_device.md) - Framework for connecting your custom pointing device to your keyboard.
* [PS2 Mouse](feature_ps2_mouse.md) - Driver for connecting a PS/2 mouse directly to your keyboard.
* [RGB Light](feature_rgblight.md) - RGB lighting for your keyboard.
* [RGB Matrix](feature_rgb_matrix.md) - RGB Matrix lights for per key lighting.
* [Space Cadet](feature_space_cadet_shift.md) - Use your left/right shift keys to type parenthesis and brackets.
* [Space Cadet](feature_space_cadet.md) - Use your left/right shift keys to type parenthesis and brackets.
* [Split Keyboard](feature_split_keyboard.md)
* [Stenography](feature_stenography.md) - Put your keyboard into Plover mode for stenography use.
* [Swap Hands](feature_swap_hands.md) - Mirror your keyboard for one handed usage.
* [Tap Dance](feature_tap_dance.md) - Make a single key do as many things as you want.
@@ -33,3 +38,4 @@ QMK has a staggering number of features for building your keyboard. It can take
* [Thermal Printer](feature_thermal_printer.md) - Connect a thermal printer to your keyboard to be able to toggle on a printed log of everything you type.
1. Press the `RESET` keycode, or keep the boot pin shorted to GND while quickly shorting RST to GND
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)
## STM32
All STM32 chips come preloaded with a factory bootloader that cannot be modified nor deleted. Some STM32 chips have bootloaders that do not come with USB programming (e.g. STM32F103) but the process is still the same.
@@ -146,7 +171,5 @@ Flashing sequence:
There are a number of DFU commands that you can use to flash firmware to a STM32 device:
*`:dfu-util` - The default command for flashing to STM32 devices.
*`:dfu-util-wait` - This works like the default command, but it gives you a (configurable) 10 second timeout before it attempts to flash the firmware. You can use `TIME_DELAY=20` from the command line to change the timeout.
@@ -62,14 +62,14 @@ If you're using [homebrew,](http://brew.sh/) you can use the following commands:
brew tap osx-cross/avr
brew tap PX4/homebrew-px4
brew update
brew install avr-gcc@7
brew link --force avr-gcc@7
brew install avr-gcc@8
brew link --force avr-gcc@8
brew install dfu-programmer
brew install dfu-util
brew install gcc-arm-none-eabi
brew install avrdude
This is the recommended method. If you don't have homebrew, [install it!](http://brew.sh/) It's very much worth it for anyone who works in the command line. Note that the `make` and `make install` portion during the homebrew installation of `avr-gcc@7` can take over 20 minutes and exhibit high CPU usage.
This is the recommended method. If you don't have homebrew, [install it!](http://brew.sh/) It's very much worth it for anyone who works in the command line. Note that the `make` and `make install` portion during the homebrew installation of `avr-gcc@8` can take over 20 minutes and exhibit high CPU usage.
@@ -12,11 +12,17 @@ Within the folder `users` is a directory for each user. This is a place for user
### Keyboard Project Structure
Within the folder `keyboards` and its subfolder `handwired` is a directory for each keyboard project, for example `qmk_firmware/keyboards/clueboard`. Within it you'll find the following structure:
Within the folder `keyboards`, its subfolder `handwired` and its vendor and manufacture subdirectories e.g. `clueboard` is a directory for each keyboard project, for example `qmk_firmware/keyboards/clueboard/2x1800`. Within it, you'll find the following structure:
*`keymaps/`: Different keymaps that can be built
*`rules.mk`: The file that sets the default "make" options. Do not edit this file directly, instead use a keymap specific `rules.mk`.
*`config.h`: The file that sets the default compile time options. Do not edit this file directly, instead use a keymap specific `config.h`.
*`info.json`: The file used for setting layout for QMK Configurator. See [Configurator Support](reference_configurator_support.md) for more information.
*`readme.md`: A brief overview of the keyboard.
*`<keyboardName>.h`: This file is where the keyboard layout is defined against the keyboard's switch matrix.
*`<keyboardName>.c`: This file is where you can find custom code for the keyboard.
For more information on project structure, see [QMK Keyboard Guidelines](hardware_keyboard_guidelines.md).
This project includes a Vagrantfile that will allow you to build a new firmware for your keyboard very easily without major changes to your primary operating system. This also ensures that when you clone the project and perform a build, you have the exact same environment as anyone else using the Vagrantfile to build. This makes it much easier for people to help you troubleshoot any issues you encounter.
This project includes a `Vagrantfile` that will allow you to build a new firmware for your keyboard very easily without major changes to your primary operating system. This also ensures that when you clone the project and perform a build, you have the exact same environment as anyone else using the Vagrantfile to build. This makes it much easier for people to help you troubleshoot any issues you encounter.
## Requirements
Using the `/Vagrantfile` in this repository requires you have [Vagrant](http://www.vagrantup.com/) as well as [VirtualBox](https://www.virtualbox.org/) (or [VMware Workstation](https://www.vmware.com/products/workstation) and [Vagrant VMware plugin](http://www.vagrantup.com/vmware) but the (paid) VMware plugin requires a licensed copy of VMware Workstation/Fusion).
Using the `Vagrantfile` in this repository requires you have [Vagrant](http://www.vagrantup.com/) as well as a supported provider installed:
*COMPATIBILITY NOTICE* Certain versions of Virtualbox 5 appear to have an incompatibility with the Virtualbox extensions installed in the boxes in this Vagrantfile. If you encounter any issues with the /vagrant mount not succeeding, please upgrade your version of Virtualbox to at least 5.0.12. **Alternately, you can try running the following command:**`vagrant plugin install vagrant-vbguest`
* [VirtualBox](https://www.virtualbox.org/) (Version at least 5.0.12)
* Sold as 'the most accessible platform to use Vagrant'
* [VMware Workstation](https://www.vmware.com/products/workstation) and [Vagrant VMware plugin](http://www.vagrantup.com/vmware)
* The (paid) VMware plugin requires a licensed copy of VMware Workstation/Fusion
* [Docker](https://www.docker.com/)
Other than having Vagrant and Virtualbox installed and possibly a restart of your computer afterwards, you can simple run a 'vagrant up' anywhere inside the folder where you checked out this project and it will start a Linux virtual machine that contains all the tools required to build this project. There is a post Vagrant startup hint that will get you off on the right foot, otherwise you can also reference the build documentation below.
Other than having Vagrant, a suitable provider installed and possibly a restart of your computer afterwards, you can simple run a 'vagrant up' anywhere inside the folder where you checked out this project and it will start an environment (either a virtual machine or container) that contains all the tools required to build this project. There is a post Vagrant startup hint that will get you off on the right foot, otherwise you can also reference the build documentation below.
# Flashing the Firmware
## Flashing the Firmware
The "easy" way to flash the firmware is using a tool from your host OS:
@@ -19,3 +23,35 @@ 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.
## FAQ
### Why am I seeing issues under Virtualbox?
Certain versions of Virtualbox 5 appear to have an incompatibility with the Virtualbox extensions installed in the boxes in this Vagrantfile. If you encounter any issues with the /vagrant mount not succeeding, please upgrade your version of Virtualbox to at least 5.0.12. **Alternately, you can try running the following command:**
```console
vagrant plugin install vagrant-vbguest
```
### How do I remove an existing environment?
Finished with your environment? From anywhere inside the folder where you checked out this project, Execute:
```console
vagrant destory
```
### What if I want to use Docker directly?
Want to benefit from the Vagrant workflow without a virtual machine? The Vagrantfile is configured to bypass running a virtual machine, and run the container directly. Execute the following when bringing up the environment to force the use of Docker:
```console
vagrant up --provider=docker
```
### How do I access the virtual machine instead of the Docker container?
Execute the following to bypass the `vagrant` user booting directly to the official qmk builder image:
@@ -198,15 +198,17 @@ From here, you should have a working keyboard once you program a firmware. Befor
To start out, download [the firmware](https://github.com/qmk/qmk_firmware/) - we'll be using my (Jack's) fork of TMK called QMK/Quantum. We'll be doing a lot from the Terminal/command prompt, so get that open, along with a decent text editor like [Sublime Text](http://www.sublimetext.com/) (paid) or [Visual Studio Code](https://code.visualstudio.com) (free).
The first thing we're going to do is create a new project using the script in the root directory of the firmware. In your terminal, run this command with `<project_name>` replaced by the name of your project - it'll need to be different from any other project in the `keyboards/` folder:
The first thing we're going to do is create a new keyboard. In your terminal, run this command, which will ask you some questions and generate a basic keyboard project:
```
util/new_project.sh <project_name>
./util/new_keyboard.sh
```
You'll want to navigate to the `keyboards/<project_name>/` folder by typing, like the print-out from the script specifies:
cd keyboards/<project_name>
```
cd keyboards/<project_name>
```
### `config.h`
@@ -326,7 +328,7 @@ Carefully flip your keyboard over, open up a new text document, and try typing -
2. Check the solder joints on the diode - if the diode is loose, part of your row may register, while the other may not.
3. Check the solder joints on the columns - if your column wiring is loose, part or all of the column may not work.
4. Check the solder joints on both sides of the wires going to/from the Teensy - the wires need to be fully soldered and connect to both sides.
5. Check the <project_name>.h file for errors and incorrectly placed `KC_NO`s - if you're unsure where they should be, instead duplicate a k*xy* variable.
5. Check the `<project_name>.h` file for errors and incorrectly placed `KC_NO`s - if you're unsure where they should be, instead duplicate a k*xy* variable.
6. Check to make sure you actually compiled the firmware and flashed the Teensy correctly. Unless you got error messages in the terminal, or a pop-up during flashing, you probably did everything correctly.
If you've done all of these things, keep in mind that sometimes you might have had multiple things affecting the keyswitch, so it doesn't hurt to test the keyswitch by shorting it out at the end.
@@ -335,4 +337,4 @@ If you've done all of these things, keep in mind that sometimes you might have h
Now that you have a working board, it's time to get things in their permanent positions. I've often used liberal amounts of hot glue to secure and insulate things, so if that's your style, start spreading that stuff like butter. Otherwise, double-sided tape is always an elegant solution, and electrical tape is a distant second. Due to the nature of these builds, a lot of this part is up to you and how you planned (or didn't plan) things out.
There are a lot of possibilities inside the firmware - explore [docs.qmk.fm](http://docs.qmk.fm) for a full feature list, and dive into the different project (Planck, Clueboard, Ergodox EZ, etc) to see how people use all of them. You can always stop by [the OLKB subreddit for help!](http://reddit.com/r/olkb)
There are a lot of possibilities inside the firmware - explore [docs.qmk.fm](http://docs.qmk.fm) for a full feature list, and dive into the different keyboards (Planck, Clueboard, Ergodox EZ, etc) to see how people use all of them. You can always stop by [the OLKB subreddit for help!](http://reddit.com/r/olkb)
@@ -6,14 +6,26 @@ 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_project.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 the `util/new_keyboard.sh` script:
To start working on things, cd into keyboards/mycoolkb,
or open the directory in your favourite 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.
@@ -66,7 +78,7 @@ Do change the `MANUFACTURER`, `PRODUCT`, and `DESCRIPTION` lines to accurately r
#define DESCRIPTION A custom keyboard
```
?> Note: On Windows and macOS the `MANUFACTURER`,`PRODUCT`, and `DESCRIPTION` fields will be displayed in the list of USB devices. ?> On Linux these values will not be visible in lsusb by default, since Linux takes the information from the list maintained by [USB ID Repository](http://www.linux-usb.org/usb-ids.html) by default. lsusb will show the information reported by the device when executed with -v option. It is also present in kernel logs after plugging in the device.
?> Windows and macOS will display the `MANUFACTURER` and`PRODUCT` in the list of USB devices. `lsusb` on Linux instead takes these from the list maintained by the [USB ID Repository](http://www.linux-usb.org/usb-ids.html) by default. `lsusb -v` will show the values reported by the device, and they are also present in kernel logs after plugging it in.
### Keyboard Matrix Configuration
@@ -113,7 +125,7 @@ To configure a keyboard where each switch is connected to a separate pin and gro
### Backlight Configuration
By default QMK supports backlighting on pins `B5`, `B6`, and `B7`. If you are using one of those you can simply enable it here. For more details see the [Backlight Documentation](feature_backlight.md).
QMK supports backlighting on most GPIO pins. A select few of these can be driven by the MCU in hardware. For more details see the [Backlight Documentation](feature_backlight.md).
```c
#define BACKLIGHT_PIN B7
@@ -122,8 +134,6 @@ By default QMK supports backlighting on pins `B5`, `B6`, and `B7`. If you are us
#define BREATHING_PERIOD 6
```
?> You can use backlighting on any pin you like, but you will have to do more work to support that. See the [Backlight Documentation](feature_backlight.md) for more details.
### Other Configuration Options
There are a lot of features that can be configured or tuned in `config.h`. You should see the [Config Options](config_options.md) page for more details.
@@ -14,9 +14,9 @@ QMK is used on a lot of different hardware. While support for the most common MC
Support for addressing pins on the ProMicro by their Arduino name rather than their AVR name. This needs to be better documented, if you are trying to do this and reading the code doesn't help please [open an issue](https://github.com/qmk/qmk_firmware/issues/new) and we can help you through the process.
## SSD1306 (AVR Only)
## SSD1306 OLED Driver
Support for SSD1306 based OLED displays. This needs to be better documented, if you are trying to do this and reading the code doesn't help please [open an issue](https://github.com/qmk/qmk_firmware/issues/new) and we can help you through the process.
Support for SSD1306 based OLED displays. For more information see the [OLED Driver Feature](feature_oled_driver.md) page.
## uGFX
@@ -32,4 +32,4 @@ Support for up to 2 drivers. Each driver impliments 2 charlieplex matrices to in
## IS31FL3733
Support for up to a single driver with room for expansion. Each driver can control 192 individual LEDs or 64 RGB LEDs. For more information on how to setup the driver see the [RGB Matrix](feature_rgb_matrix.md) page.
Support for up to a single driver with room for expansion. Each driver can control 192 individual LEDs or 64 RGB LEDs. For more information on how to setup the driver see the [RGB Matrix](feature_rgb_matrix.md) page.
@@ -33,7 +33,11 @@ The firmware does not send actual letters or characters, but only scancodes.
Thus, by modifying the firmware, you can only modify what scancode is sent over
USB for a given key.
## 3. What the Operating System Does
## 3. What the Event Input/Kernel Does
The *scancode* is mapped to a *keycode* dependent on the keyboard [60-keyboard.hwdb at Master](https://github.com/systemd/systemd/blob/master/hwdb/60-keyboard.hwdb). Without this mapping, the operating system will not receive a valid keycode and will be unable to do anything useful with that key press.
## 4. What the Operating System Does
Once the keycode reaches the operating system, a piece of software has to have
it match an actual character thanks to a keyboard layout. For example, if your
@@ -63,10 +67,10 @@ You may wonder why a keyboard layout containing all of Unicode is not devised th
## How to (Maybe) Enter Unicode Characters
You can have the firmware send *sequences of keys* to use the [software Unicode Input Method](https://en.wikipedia.org/wiki/Unicode_input#Hexadecimal_code_input) of the target operating system, thus effectively entering characters independently of the layout defined in the OS.
You can have the firmware send *sequences of keys* to use the [software Unicode Input Method](https://en.wikipedia.org/wiki/Unicode_input#Hexadecimal_input) of the target operating system, thus effectively entering characters independently of the layout defined in the OS.
Yet, it does come with multiple disadvantages:
- Tied to a specific OS a a time (need recompilation when changing OS);
- Tied to a specific OS at a time (need recompilation when changing OS);
- Within a given OS, does not work in all software;
@@ -65,12 +65,47 @@ By default the I2C1 hardware driver is assumed to be used. If another hardware d
STM32 MCUs allows a variety of pins to be configured as I2C pins depending on the hardware driver used. By default B6 and B7 are set to I2C. You can use these defines to set your i2c pins:
| `I2C1_SCL_BANK` | The bank of pins (`GPIOA`, `GPIOB`, `GPIOC`) to use for SCL | `GPIOB` |
| `I2C1_SDA_BANK` | The bank of pins (`GPIOA`, `GPIOB`, `GPIOC`) to use for SDA | `GPIOB` |
| `I2C1_SCL` | The pin number for the SCL pin (0-9) | `6` |
| `I2C1_SDA` | The pin number for the SDA pin (0-9) | `7` |
| `I2C1_BANK` (deprecated) | The bank of pins (`GPIOA`, `GPIOB`, `GPIOC`), superceded by `I2C1_SCL_BANK`, `I2C1_SDA_BANK` | `GPIOB` |
The ChibiOS I2C driver configuration depends on STM32 MCU:
STM32F1xx, STM32F2xx, STM32F4xx, STM32L0xx and STM32L1xx use I2Cv1;
STM32F0xx, STM32F3xx, STM32F7xx and STM32L4xx use I2Cv2;
#### I2Cv1
STM32 MCUs allow for different clock and duty parameters when configuring I2Cv1. These can be modified using the following parameters, using <https://www.playembedded.org/blog/stm32-i2c-chibios/#I2Cv1_configuration_structure> as a reference:
| Variable | Default |
|--------------------|------------------|
| `I2C1_OPMODE` | `OPMODE_I2C` |
| `I2C1_CLOCK_SPEED` | `100000` |
| `I2C1_DUTY_CYCLE` | `STD_DUTY_CYCLE` |
#### I2Cv2
STM32 MCUs allow for different timing parameters when configuring I2Cv2. These can be modified using the following parameters, using <https://www.st.com/en/embedded-software/stsw-stm32126.html> as a reference:
| Variable | Default |
|-----------------------|---------|
| `I2C1_TIMINGR_PRESC` | `15U` |
| `I2C1_TIMINGR_SCLDEL` | `4U` |
| `I2C1_TIMINGR_SDADEL` | `2U` |
| `I2C1_TIMINGR_SCLH` | `15U` |
| `I2C1_TIMINGR_SCLL` | `21U` |
STM32 MCUs allow for different "alternate function" modes when configuring GPIO pins. These are required to switch the pins used to I2Cv2 mode. See the respective datasheet for the appropriate values for your MCU.
| Variable | Default |
|---------------------|---------|
| `I2C1_SCL_PAL_MODE` | `4` |
| `I2C1_SDA_PAL_MODE` | `4` |
#### Other
You can also overload the `void i2c_init(void)` function, which has a weak attribute. If you do this the configuration variables above will not be used. Please consult the datasheet of your MCU for the available GPIO configurations. The following is an example initialization function:
|`MAGIC_SWAP_CONTROL_CAPSLOCK` | |Swap Caps Lock and Left Control |
|`MAGIC_CAPSLOCK_TO_CONTROL` | |Treat Caps Lock as Control |
|`MAGIC_SWAP_LCTL_LGUI` | |Swap Left Control and GUI |
|`MAGIC_SWAP_RCTL_RGUI` | |Swap Right Control and GUI |
|`MAGIC_SWAP_LALT_LGUI` | |Swap Left Alt and GUI |
|`MAGIC_SWAP_RALT_RGUI` | |Swap Right Alt and GUI |
|`MAGIC_NO_GUI` | |Disable the GUI key |
@@ -263,8 +270,11 @@ This is a reference only. Each group of keys links to the page documenting their
|`MAGIC_SWAP_BACKSLASH_BACKSPACE` | |Swap `\` and Backspace |
|`MAGIC_HOST_NKRO` | |Force NKRO on |
|`MAGIC_SWAP_ALT_GUI` |`AG_SWAP`|Swap Alt and GUI on both sides |
|`MAGIC_SWAP_CTL_GUI` |`CG_SWAP`|Swap Ctrl and GUI on both sides (for macOS)|
|`MAGIC_UNSWAP_CONTROL_CAPSLOCK` | |Unswap Caps Lock and Left Control |
|`MAGIC_UNCAPSLOCK_TO_CONTROL` | |Stop treating Caps Lock as Control |
|`MAGIC_UNSWAP_LCTL_LGUI` | |Unswap Left Control and GUI |
|`MAGIC_UNSWAP_RCTL_RGUI` | |Unswap Right Control and GUI |
|`MAGIC_UNSWAP_LALT_LGUI` | |Unswap Left Alt and GUI |
|`MAGIC_UNSWAP_RALT_RGUI` | |Unswap Right Alt and GUI |
|`MAGIC_UNNO_GUI` | |Enable the GUI key |
@@ -272,8 +282,10 @@ This is a reference only. Each group of keys links to the page documenting their
|`MAGIC_UNSWAP_BACKSLASH_BACKSPACE`| |Unswap `\` and Backspace |
|`MAGIC_UNHOST_NKRO` | |Force NKRO off |
|`MAGIC_UNSWAP_ALT_GUI` |`AG_NORM`|Unswap Alt and GUI on both sides |
|`MAGIC_TOGGLE_ALT_GUI` |`AG_TOGG`|Toggle Alt and GUI swap on both sides|
|`MAGIC_TOGGLE_NKRO` | |Turn NKRO on or off |
|`MAGIC_UNSWAP_CTL_GUI` |`CG_NORM`|Unswap Ctrl and GUI on both sides|
|`MAGIC_TOGGLE_ALT_GUI`|`AG_TOGG`|Toggle Alt and GUI swap on both sides |
|`MAGIC_TOGGLE_CTL_GUI` |`CG_TOGG`|Toggle Ctrl and GUI swap on both sides |
|`MAGIC_TOGGLE_NKRO` | |Turn NKRO on or off |
## [Bluetooth](feature_bluetooth.md)
@@ -293,7 +305,7 @@ This is a reference only. Each group of keys links to the page documenting their
|`LM(layer, mod)`|Momentarily turn on `layer` (like MO) with `mod` active as well. Where `mod` is a mods_bit. Mods can be viewed [here](https://docs.qmk.fm/#/feature_advanced_keycodes?id=mod-tap). Example Implementation: `LM(LAYER_1, MOD_LALT)`|
|`LT(layer, kc)` |Turn on `layer` when held, `kc` when tapped |
|`TG(layer)` |Toggle `layer` on or off |
|`TO(layer)` |Turn on `layer`when pressed |
|`TO(layer)` |Turns on `layer`and turns off all other layers, except the default layer |
|`TT(layer)` |Normally acts like MO unless it's tapped multiple times, which toggles `layer` on |
## [Mouse Keys](feature_mouse_keys.md)
@@ -339,23 +351,24 @@ This is a reference only. Each group of keys links to the page documenting their
|`LCTL_T(kc)`|`CTL_T(kc)` |Left Control when held, `kc` when tapped |
|`LSFT_T(kc)`|`SFT_T(kc)` |Left Shift when held, `kc` when tapped |
|`LALT_T(kc)`|`ALT_T(kc)` |Left Alt when held, `kc` when tapped |
|`LGUI_T(kc)`|`LCMD_T(kc)`, `LWIN_T(kc)`, `GUI_T(kc)`, `CMD_T(kc)`, `WIN_T(kc)`|Left GUI when held, `kc` when tapped |
|`RCTL_T(kc)`| |Right Control when held, `kc` when tapped |
|`RSFT_T(kc)`| |Right Shift when held, `kc` when tapped |
|`RALT_T(kc)`|`ALGR_T(kc)` |Right Alt when held, `kc` when tapped |
|`RGUI_T(kc)`|`RCMD_T(kc)`, `RWIN_T(kc)` |Right GUI when held, `kc` when tapped |
|`SGUI_T(kc)`|`SCMD_T(kc)`, `SWIN_T(kc)` |Left Shift and GUI when held, `kc` when tapped |
|`LCA_T(kc)` | |Left Control and Alt when held, `kc` when tapped |
|`LCAG_T(kc)`| |Left Control, Alt and GUI when held, `kc` when tapped |
|`RCAG_T(kc)`| |Right Control, Alt and GUI when held, `kc` when tapped |
|`C_S_T(kc)` | |Left Control and Shift when held, `kc` when tapped |
|`MEH_T(kc)` | |Left Control, Shift and Alt when held, `kc` when tapped|
|`HYPR_T(kc)`|`ALL_T(kc)` |Left Control, Shift, Alt and GUI when held, `kc` when tapped - more info [here](http://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/)|
|`MT(mod, kc)`| |`mod` when held, `kc` when tapped |
|`LCTL_T(kc)`|`CTL_T(kc)` |Left Control when held, `kc` when tapped |
|`LSFT_T(kc)`|`SFT_T(kc)` |Left Shift when held, `kc` when tapped |
|`LALT_T(kc)`|`ALT_T(kc)`|Left Alt when held, `kc` when tapped |
|`LGUI_T(kc)` |`LCMD_T(kc)`, `LWIN_T(kc)`, `GUI_T(kc)`, `CMD_T(kc)`, `WIN_T(kc)`|Left GUI when held, `kc` when tapped |
|`RCTL_T(kc)`| |Right Control when held, `kc` when tapped |
|`RSFT_T(kc)` | |Right Shift when held, `kc` when tapped |
|`RALT_T(kc)` |`ALGR_T(kc)`|Right Alt when held, `kc` when tapped |
|`RGUI_T(kc)`|`RCMD_T(kc)`, `RWIN_T(kc)` |Right GUI when held, `kc` when tapped |
|`SGUI_T(kc)` |`SCMD_T(kc)`, `SWIN_T(kc)`|Left Shift and GUI when held, `kc` when tapped |
|`LCA_T(kc)`| |Left Control and Alt when held, `kc` when tapped |
|`LCAG_T(kc)`| |Left Control, Alt and GUI when held, `kc` when tapped |
|`RCAG_T(kc)` | |Right Control, Alt and GUI when held, `kc` when tapped |
|`C_S_T(kc)` | |Left Control and Shift when held, `kc` when tapped|
|`MEH_T(kc)` | |Left Control, Shift and Alt when held, `kc` when tapped|
|`HYPR_T(kc)` |`ALL_T(kc)` |Left Control, Shift, Alt and GUI when held, `kc` when tapped - more info [here](http://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/)|
## [RGB Lighting](feature_rgblight.md)
@@ -450,7 +463,15 @@ This is a reference only. Each group of keys links to the page documenting their
[QMK Toolbox](https://github.com/qmk/qmk_toolbox) will show messages from your keyboard if you have `CONSOLE_ENABLE = yes` in your `rules.mk`. By default the output is very limited, but you can turn on debug mode to increase the amount of debug output. Use the `DEBUG` keycode in your keymap, use the [Command](feature_command.md) feature to enable debug mode, or add the following code to your keymap.
Your keyboard will output debug information if you have `CONSOLE_ENABLE = yes` in your `rules.mk`. By default the output is very limited, but you can turn on debug mode to increase the amount of debug output. Use the `DEBUG` keycode in your keymap, use the [Command](feature_command.md) feature to enable debug mode, or add the following code to your keymap.
For compatible platforms, [QMK Toolbox](https://github.com/qmk/qmk_toolbox) can be used to display debug messages from your keyboard.
### Debugging With hid_listen
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.
<!-- FIXME: Describe the debugging messages here. -->
## Sending Your Own Debug Messages
@@ -41,3 +49,51 @@ After that you can use a few different print functions:
*`uprintf("%s string", var)`: Print a formatted string
*`dprint("string")` Print a simple string, but only when debug mode is enabled
*`dprintf("%s string", var)`: Print a formatted string, but only when debug mode is enabled
## Debug Examples
Below is a collection of real world debugging examples. For additional information, refer to [Debugging/Troubleshooting QMK](faq_debug.md).
### Which matrix position is this keypress?
When porting, or when attempting to diagnose pcb issues, it can be useful to know if a keypress is scanned correctly. To enable logging for this scenario, add the following code to your keymaps `keymap.c`
When testing performance issues, it can be useful to know the frequency at which the switch matrix is being scanned. To enable logging for this scenario, add the following code to your keymaps `config.h`
Setting up your ARM based PCB is a little more involved than an Atmel MCU, but is easy enough. Start by using `util/new_project.sh <keyboard>` to create a new project:
Setting up your ARM based PCB is a little more involved than an Atmel MCU, but is easy enough. Start by running `util/new_keyboard.sh`:
To start working on things, cd into keyboards/mycoolkb,
or open the directory in your favourite text editor.
```
# END OF NEW ARM DOC, OLD ATMEL DOC FOLLOWS
## `/keyboards/<keyboard>/config.h`
@@ -24,7 +34,7 @@ For the `DIODE_DIRECTION`, most hand-wiring guides will instruct you to wire the
To configure a keyboard where each switch is connected to a separate pin and ground instead of sharing row and column pins, use `DIRECT_PINS`. The mapping defines the pins of each switch in rows and columns, from left to right. Must conform to the sizes within `MATRIX_ROWS` and `MATRIX_COLS`, use `NO_PIN` to fill in blank spaces. Overrides the behaviour of `DIODE_DIRECTION`, `MATRIX_ROW_PINS` and `MATRIX_COL_PINS`.
`BACKLIGHT_PIN` is the pin that your PWM-controlled backlight (if one exists) is hooked-up to. Currently only B5, B6, and B7 are supported.
`BACKLIGHT_PIN` is the pin that your PWM-controlled backlight (if one exists) is hooked-up to.
`BACKLIGHT_BREATHING` is a fancier backlight feature that adds breathing/pulsing/fading effects to the backlight. It uses the same timer as the normal backlight. These breathing effects must be called by code in your keymap.
This document gives an overview of how QMK has structured its python code. You should read this before working on any of the python code.
## Script directories
There are two places scripts live in QMK: `qmk_firmware/bin` and `qmk_firmware/util`. You should use `bin` for any python scripts that utilize the `qmk` wrapper. Scripts that are standalone and not run very often live in `util`.
We discourage putting anything into `bin` that does not utilize the `qmk` wrapper. If you think you have a good reason for doing so please talk to us about your use case.
## Python Modules
Most of the QMK python modules can be found in `qmk_firmware/lib/python`. This is the path that we append to `sys.path`.
We have a module hierarchy under that path:
*`qmk_firmware/lib/python`
*`milc.py` - The CLI library we use. Will be pulled out into its own module in the future.
*`qmk` - Code associated with QMK
*`cli` - Modules that will be imported for CLI commands.
*`errors.py` - Errors that can be raised within QMK apps
*`keymap.py` - Functions for working with keymaps
## CLI Scripts
We have a CLI wrapper that you should utilize for any user facing scripts. We think it's pretty easy to use and it gives you a lot of nice things for free.
To use the wrapper simply place a module into `qmk_firmware/lib/python/qmk/cli`, and create a symlink to `bin/qmk` named after your module. Dashes in command names will be converted into dots so you can use hierarchy to manage commands.
When `qmk` is run it checks to see how it was invoked. If it was invoked as `qmk` the module name is take from `sys.argv[1]`. If it was invoked as `qmk-<module-name>` then everything after the first dash is taken as the module name. Dashes and underscores are converted to dots, and then `qmk.cli` is prepended before the module is imported.
The module uses `@cli.entrypoint()` and `@cli.argument()` decorators to define an entrypoint, which is where execution starts.
## Example CLI Script
We have provided a QMK Hello World script you can use as an example. To run it simply run `qmk hello` or `qmk-hello`. The source code is listed below.
```
from milc import cli
@cli.argument('-n', '--name', default='World', help='Name to greet.')
Quantum keycodes allow for easier customisation of your keymap than the basic ones provide, without having to define custom actions.
Quantum keycodes allow for easier customization of your keymap than the basic ones provide, without having to define custom actions.
All keycodes within quantum are numbers between `0x0000` and `0xFFFF`. Within your `keymap.c` it may look like you have functions and other special cases, but ultimately the C preprocessor will translate those into a single 4 byte integer. QMK has reserved `0x0000` through `0x00FF` for standard keycodes. These are keycodes such as `KC_A`, `KC_1`, and `KC_LCTL`, which are basic keys defined in the USB HID specification.
@@ -16,6 +16,11 @@ On this page we have documented keycodes between `0x00FF` and `0xFFFF` which are
|`KC_GESC` |`GRAVE_ESC`|Escape when tapped, <code>`</code> when pressed with Shift or GUI|
|`KC_LSPO` | |Left Shift when held, `(` when tapped |
|`KC_RSPC` | |Right Shift when held, `)` when tapped |
|`KC_LCPO` | |Left Control when held, `(` when tapped |
|`KC_RCPC` | |Right Control when held, `)` when tapped |
|`KC_LAPO` | |Left Alt when held, `(` when tapped |
|`KC_RAPC` | |Right Alt when held, `)` when tapped |
|`KC_SFTENT` | |Right Shift when held, Enter when tapped |
Alternatively, you don't have to immediately "return" the value. This is useful if you want to add multiple tri layers, or if you want to add additional effects.
@@ -89,7 +89,7 @@ Once the layout is as desired, move to the Raw Data tab in KLE, and copy the con
To convert this data into our JSON, go to the [QMK KLE-JSON Converter](https://qmk.fm/converter/), paste the Raw Data into the Input field, and click the Convert button. After a moment, our JSON data will appear in the Output field. Copy the contents to a new text document, and name the document `info.json`, saving it in the same folder that contains `numpad.h`.
Use the `keyboard_name` object to set the name of the keyboard. The `bootloader` object is deprecated, so it can be deleted. For instruction purposes, we will put each key's object on its own line. This is only to make the file more human-readable, and does not affect the Configurator's functionality.
Use the `keyboard_name` object to set the name of the keyboard. For instruction purposes, we will put each key's object on its own line. This is only to make the file more human-readable, and does not affect the Configurator's functionality.
The kerpleplork was intermittently failing with error code 23. The root cause was the fronzlebop setting, which causes the kerpleplork to activate every N iterations.
Limited experimentation on the devices I have available shows that 7 is high enough to avoid confusing the kerpleplork, but I'd like to get some feedback from people with ARM devices to be sure.
case RGB_LYR: // <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD>underglow<6F><77>Ϊ<EFBFBD><CEAA>ָʾ<D6B8><CABE><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ʹ<EFBFBD>á<EFBFBD>
case RGB_MODE_FORWARD ... RGB_MODE_GRADIENT: // <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>е<EFBFBD>RGB<47><42><EFBFBD><EFBFBD> (see quantum_keycodes.h, L400 <20><><EFBFBD>Բο<D4B2>)
if (record->event.pressed) { //<2F><><EFBFBD><EFBFBD>ʧ<EFBFBD>ܲ<EFBFBD>ָʾ<D6B8><CABE><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ı<EFBFBD><C4B1><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ҫ<EFBFBD><D2AA><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
if (user_config.rgb_layer_change) { // <20><><EFBFBD><EFBFBD>ʹ<EFBFBD><CAB9>ʱ
Github can be a little tricky to those that aren't familiar with it - this guide will walk through each step of forking, cloning, and submitting a pull request with QMK.
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.