* 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
Assuming I understand this correctly, this should set the max scancode to E7 (RGUI), which is the last listed code in the main list (everything else use for internal QMK/TMK stuff).
* Port DIRECT_PINS from split_common/matrix.c to matrix.c
* Reorder matrix.c to remove foward declaration and match split_common/matrix.c
* Refactor nano to use DIRECT_PINS
* Reorder matrix.c to remove foward declaration and match split_common/matrix.c
* Add DIRECT_PINS documentation
* Reorder matrix.c to remove foward declaration and match split_common/matrix.c - fix logic from inherited from split_common
* Add DIRECT_PINS documentation - review comments
* Revert "Update build instructions and Dockerfile to download submodules"
This reverts commit 93210547bd.
* Update build tools docs based on feedback
* Fix bad link in build tools docs
* RGB Matrix overhaul
Breakout of animations to separate files
Integration of optimized int based math lib
Overhaul of rgb_matrix.c and animations for performance
* Updating effect function api for future extensions
* Combined the keypresses || keyreleases define checks into a single define so I stop forgetting it where necessary
* Moving define RGB_MATRIX_KEYREACTIVE_ENABLED earlier in the include chain
* Adds the Planck EZ, 3737 RGB, fixes out-of-tune notes
* fix bug in quantum/rgb_matrix_drivers.c
Co-Authored-By: jackhumbert <jack.humb@gmail.com>
* update command setting to the correct default
* correct rgb config
* remove commented-out lines
* update docs for the 3737
* Update docs/feature_rgb_matrix.md
Co-Authored-By: jackhumbert <jack.humb@gmail.com>
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
* Refactor 4x4 in line with current ps2avrgb template
* Add backlight pwm bodge till #4324 lands
* Disable bootmagic lite as it seems to not work on atmega32a/bootloadHID
* remove unneeded uart setting
* use pragma once everywhere
* remove custom matrix support
* fixup readme
* set bootmagic to lite
* remove dependency on custom i2c code
* use the right header files and function calls
* remove bootmagic support as it doesn't work on bmc boards
* readme merge artifacts removal
* pragma once it all
* put amnesia's name everywhere
* fixup readme
* remove custom matrix
* remove unneccessary configs
* disable bootmagic
* remove custom i2c in favor of i2c_master
* fix rgb led num
* add in rgb underglow support
* Refactor jj40 in line with current ps2avrgb template
* Disable bootmagic lite as it seems to not work on atmega32a/bootloadHID
* Add backlight pwm bodge till #4324 lands
* Increase planck keymap compatibility
* use pragma once
* modified readme with maintainer info
* remove rev1 for the time being
* QMK Configurator support for 60_ansi and 60_ansi_split_bs_rshift
* add hhkb layout and QMK Configurator support
* fix compile issue due to missing DEVICE_VER
* use a saner and less complicated default layout
* remove unused file
* fix up LAYOUT_all and formatting along with QKM Configurator support
* turn on bootmagic lite as the hardware reset switch isn't in a standard position
* remove default folder
* Added Waldo keyboard base files and default keymap
* Updated Waldo files and added keymap for split shift and split backspace
* Updated meta-data for the Waldo board
* Apply suggestions from code review
Committing suggestions for real this time.
Co-Authored-By: That-Canadian <Poole.Chris.11@gmail.com>
* Made suggested changes that were not explicitly made.
* Add keyboard Signum 3.0 for the elite-c
* Update readme.md
* Remove unused macros
* Use bootmagic lite instead of full
* Add warning to keymap.c that it's auto-generate
* Add description for customizing keyboard layouts
* Make generate_km.py executable
* Make right shift available in numpad layer
* Update keyboards/signum/3_0/elitec/readme.md
Co-Authored-By: jceb <jceb@e-jc.de>
* Update keyboards/signum/3_0/elitec/readme.md
Co-Authored-By: jceb <jceb@e-jc.de>
* Fix typo in symbol name
* remove dependency on custom i2c code
* missed a pragma once
* fix readme install instructions
* config.h cleanup
* make the bootmagic key not the same bmc reset key
* disable bootmagic functionality as it doesn't seem to work on atmega32a bmc boards
* remove custom i2c code in favor of QMK i2c_master
* clean up config file
* fix pyusb install instructions
* fix naming in usbconfig.h
* disable bootmagic as it does not work for bmc boards
* Update macros and keycode handling
- Update NUBS_Z macro so it repeats when held down
- Number row now uses numpad keycodes if Right Alt is being held
- coding conventions and formatting update
- switched to four-space indent
- reformatted a block comment
* Update readme files
* remove unneeded uart setting
* use pragma once everywhere
* remove custom matrix support
* fixup readme
* set bootmagic to lite
* remove dependency on custom i2c code
* use the right header files and function calls
* On i2c_init, enable two wire interface, twi interrupt, and slave
address ACK along with pull up resistors.
* thanks to some testing by drashna, we know that setting TWI doesn't work for all boards. Putting the new code into an ifdef block
* Add new keyboard: NQG
* Delete .gitignore
.gitignore removed
Originally used to ignore .DS_Store files from being committed.
* Changed Maintainer information
Maintainer link now points to a github account.
* Add customizable tapping terms
* Add Documentation
* Fix function
* Fixes
* It's not a pointer
* Add debugging output
* Update documentation to be at least vaguely accurate
* Use `get_tapping_term(tapping_key.event)` instead
`e` doesn't include column and row information, properly. It registers as 255, regardless of the actual keypress.
However `tapping_key.event` actually gives the correct column and row information. It appears be the correct structure to use.
In fact, it looks like the issue is that `e` is actually the "TICK" structure, as defined in keyboard.h
* Use variable tapping term value rather than define
* Silly drashna - tapping_key.event, not event
* add get_event_keycode() function
* Fix typo
Co-Authored-By: drashna <drashna@live.com>
* Remove post_process_record_quantum since it's the wrong PR
* Update quantum/quantum.c
Co-Authored-By: drashna <drashna@live.com>
* Better handle ifdef statement for permissive hold
Since we can't be sure that tapping term is actually 500
* Update quantum.c comments based on feedback
* Clean up get_tapping_term function
Clean up function so that users don't need to call the event function, and instead only check the keycode
* Add ability to run functionality on and off
* Make ifdef's more compact
* initial commit of budget96
* non logic changes
* add my name to readme
* update matrix.c
* make the matrix representation of the layout macro
* fix up LAYOUT macro
* add missing character
* initial keymap commit
* put KC_NO where they belong
* basic keymap
* fix matrix row and col definition
* The diagram I was sent and the pins used I was sent were in opposite order from each other. This should fix the issues
* update the readme
* change up manufacturer for budget96
* update copyright date
* fix up the switch matrix and provide a keymap
* forgot the keymap
* other matrix fixes
* missing a few keys in the switch matrix
* messed up the row tracing
* tweak keymap a bit
* use a lower case k
* fix spacing for markdown rendering
* put in the reset key documentation
* clean up the file a little
* use LAYOUT_96_ansi
* add a second layer for lighting controls
* add in lighting support
* add QMK Configurator support
* use pragma once
* remove un needed matrix.c
* convert to GPIO methods
* turn on rgblight_enable and get rid of custom matrix
* set bootloadhid_bootloader to 1
* set bootmagic to lite and set it to k50
* add reset information to readme
* use i2c_master instead of custom i2c
* restore the custom i2c code
* introduce reset key and eep_rst in function layer 1
* fix up pip3 install commands
* fix up device and manufacturer names
* remove un needed comments
* add an ALL layout macro along with QMK Configurator support
* move budget96 into donutcables directory since he actually has different boards
* add a short donut cables blurb taken from his website
* update readme for make instructions to point to the new path
* Update keyboards/donutcables/budget96/config.h
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update keyboards/donutcables/budget96/readme.md
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update keyboards/donutcables/budget96/info.json
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* turn on backlight
* Update keyboards/donutcables/budget96/readme.md
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* remove extra UART and BOOTLOADER settings that are not needed
* Added first configuration for handwired hacked motosped keyboard
* Added first keymap
* Fixed h file key layout
* Swapped Y and Z in default keymap
* Added name, email and description
* Moved hacked motospeed keyboard to handwired
* Changed make command in readme
* Formatted readme to be displayed properly with markdown
* Formatted keymap and layout to better reflect the physical keyboard
* Fixed info.json
* Update keyboards/handwired/hacked_motospeed/info.json
Co-Authored-By: Deckweiss <Deckweiss75@gmail.com>
* Removed .directory from .gitignore
Co-Authored-By: Deckweiss <Deckweiss75@gmail.com>
* Minor changes and cleanup
* Update keyboards/handwired/hacked_motospeed/hacked_motospeed.h
Added back newline needed for properly parsing
Co-Authored-By: Deckweiss <Deckweiss75@gmail.com>
* Adding new keymap folder for goadmaster
* add switch break
* zeal60 rgb backlight files
* modified for red caps lock key
* Remove return statement
* Files removed
* Add new RGB options
* Back to original file
* 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
* Initial portover of the doro68.json with corrected column pins.
* Initial setup of LAYOUT_ansi and it's use in the default keymap.
* Added F keys to default kemap on layer 1.
* Added split space (and everything else) layout and a base keymap to be updated.
* Renamed split_space to multi.
* Changed product_id for doro.
* Created a basic doro LAYOUT_iso and default keymap.
* Copied over basic layout and keymap.
* Added readme.md for doro67 multi.
* Removed basic keyboad layout and keymap because it's a separate PCB.
* Added backlight controls to the various keymaps.
* Added explicit backlight pin define.
* Increased number of backlight levels for flexibility.
* Removed unnecessary line slashes and unified keymcaps.
* Corrected ISO layout and switched position with multi.
* Added keymap readme.md files.
* Corrected ISO keymap.
* Added Layouts to info.json for toolbox.
* Re-added slashes as they were necessary here...
* Corrected info.json/keymap discreptancies.
* Updated copyright messages (and fixed small readme error).
* Added missing line break spaces in readme.md
Co-Authored-By: ShadeDream <nick@shadedream.com>
* Keymap alignments on default_multi readme.md
Co-Authored-By: ShadeDream <nick@shadedream.com>
* Keymap alignments on default_multi readme.md
Co-Authored-By: ShadeDream <nick@shadedream.com>
* Keymap alignments on default_multi readme.md
Co-Authored-By: ShadeDream <nick@shadedream.com>
* Small alignment adjustment on the default keymap readme.md
Co-Authored-By: ShadeDream <nick@shadedream.com>
* use pragma once where applicable
* remove ?
* update default keymap readme
* remove un need include
* update readme with newbs guide
* set underglow and backlight to be on by default, and explicitly set them to no for the default keymap to handle the non Polestar case.
* put mine and benlyall's name in the code
* update readme
* port Massdrop CTRL/ALT to use RGB Matrix
Co-authored-by: Matt Schneeberger <helluvamatt@gmail.com>
* Massdrop lighting support working
This commit is to get the Massdrop lighting code working again through use of the compilation define USE_MASSDROP_CONFIGURATOR added to a keymap's rules.mk.
Added keymaps for both CTRL and ALT named default_md and mac_md. These should be used if the Massdrop style lighting is desired.
* Updating config based on testing results with patrickmt & compile errors
* Updates for PR5328
For CTRL and ALT:
Moved location of new RGB Matrix macros from config_led.h to config.h.
Added RGB_MATRIX_LED_FLUSH_LIMIT (time between flushes) to config.h for correct LED driver update timing.
Re-added missing breathing code for when Massdrop configurator mode is defined.
* remove prilik keymap form PR
* Implemented Eager Per Row debouncing algorithm.
Good for when fingers can only press one row at a time (e.g. when keyboard is wired so that "rows" are vertical)
* Added documentation for eager_pr
* Ported ergodox_ez to eager_pr debouncing.
* Removed check for changes in matrix_scan.
* Added further clarification in docs.
* Accidental merge with ergodox_ez
* Small cleanup in eager_pr
* Forgot to debounce_init - this would probably cause seg-faults.
* first [ass at pulling out common duck library functions
* use new library in jetfire
* use new library in duck lightsaver
* use new library in octagon v2
* put Device into the library
* refactor send_value
* refactor send_value and send_color
* use pragma once
* use pragma once
* use pragma once
* use pragma once
* rename backlight_led to indicator_leds to match with other duck boards
* rename enum
* make #define names consistent
* rename ducklib to duck_led
* update rules.mk ?= to =
* put rgb in the correct order
* add debounce debugging printouts
* turn on bootmagic lite and set it to the top left most key commonly programmed as Escape
* add reset key documentation
* fix that typo
* Update keyboards/duck/duck_led/duck_led.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* include the correct library
* initial commit
* get rid of some of the vanilla cookie cutter code
* Put in the matrix size and the pins
* add LAYOUT macro and a suitable keymap
* Add QMK Configurator support
* set bootmagic to lite
* put a RESET key into the default keymap
* edit kyuu readme file for description and quantrik.com link
* Update keyboards/quantrik/kyuu/config.h
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* fix captilization of keyboard name
* fix keymap wrapping issue and add MO key
* preserve RESET key location
* use one of the macros
* RGB Matrix overhaul
Breakout of animations to separate files
Integration of optimized int based math lib
Overhaul of rgb_matrix.c and animations for performance
* Updating effect function api for future extensions
* Combined the keypresses || keyreleases define checks into a single define so I stop forgetting it where necessary
* Moving define RGB_MATRIX_KEYREACTIVE_ENABLED earlier in the include chain
* Add tennie
* Jacobs Functions
* Switch back to normal layout
* Remove define from old template
* Fix broken keymaps
* Correct style errors, add bootlite
* Update readmes. Rename test keymap
* Missed comma
* Switch rgb from init to post init
Added Fantasie Impromptu and Nocturne Op. 9 No. 1 in B flat minor by Chopin
Added Isabella's Lullaby from The Promised Neverland
Added Renai Circulation and Platinum Disco from Monogatari
Added Terra's theme from Final Fantasy 6
* Updated iris, planck, and xd75 keymaps
* Added brightness down and up to commented layout of Symbol layer.
* updated config files for planck and iris
* removed unnecessary include lines from iris and planck config files
* updated XD75's PC layer and its NAVPC toggle layer
* fixed typo in alias declaration for C_BSPS
* changed alias names for BSPC toggle keys
The other bépo layouts were a bit too complex/weird or without LED code
and hard to transition to for new users. This config is a good base for
bépo users.
* Updated iris, planck, and xd75 keymaps
* Added brightness down and up to commented layout of Symbol layer.
* updated config files for planck and iris
* removed unnecessary include lines from iris and planck config files
* Fixed typo of 'confid.h' to 'config.h'
* Fixed broken links in docs
* Fixed a lot of dead links
* Removed all dead links that I could not find a replacement for
* Placed knops links back in
* Fixed plank keymaps so that they will compile for planck light
* Https doesn't work on knops.io
* tv44:budi now compiles
* s60_x:amnesia0287 now compiles
* Fixed allocation of key_combos so that narze keymap for planck can compile correctly
* Disabled rgb on ergodone and infinity
* Enabled tap dance so it compiles
* Added return statement so it compiles
* If compiling on light disable extra functionality
* Properly redefined variable so it compiles
* Remove remaining dead links
* Create custom Planck Light keycap
See README for details
* Link to WhatPulse in README
* More remapping, and add RGB LED effects
* Remove dead code, address PR feedback from @drashna
* Add macro for “screenshot region to clipboard” hotkey for macOS
Also remove unused layer / key logic
* Remove extraneous comment
* Incorporate PR feedback from @drashna.
Update README with new mapping.
* Add keycodes for new macros to keymaps
* add macros for commonly used shortcuts
* FIx macro code and add comments
* Replaced with build in QMK keycodes
* Removed macros that duplicated QMK keycodes
* The code in this directory supports the KBD65
* Update readme.md
* Update readme.md
* Clear up the confusion between the kbd67/kbd65 naming.
* Update keyboards/kbdfans/kbd67/readme.md
Co-Authored-By: Hackerpilot <briancschott@gmail.com>
* initial commit of e6v2 bmc files
* update readme with bmc template and reset key location
* fix up the switch matrix
* add usbconfig.h file
* add i2c files
* cleanup config.h
* cleanup rules.mk and remove non atmega32a architecture code
* add an appropriate keymap for testing
* update readme with warning not to flash this hex file onto atmega32u4 e6v2
* get rgb lights working
* add QMK Configurator support for 60_ansi layout
* add hhkb support layout
* add additional layouts such as tsangan and all and included QMK Configurator support for them
* add bootmagic lite, and have it be set to Esc or the key located at k50
* update readme
* fixup spacing for LAYOUT_all electrical matrix
* add some pragma once magic
* use i2c_master instead of custom i2c.c
* remove the custom i2c.c
* restore a more valid default keymap
* add eep_rst to keymap
* Add kwer keymap and RGB mod description to cypher
* Add custom led_set_user to keymap
* Remove unneccessary include path from keyboards/westfoxtrot/cypher/keymaps/kwer/keymap.c
Co-Authored-By: kwerdenker <sebastian.spindler@gmail.com>
* build size-check enhancement
Changed to display a warning when the free size of compilation result is less than 512 bytes.
* update message.mk
* add SIZE_MARGIN variable, change default margin 512 to 1024
for Example.
```
$ make SIZE_MARGIN=2048 crkbd:all
$ make crkbd:all ## mergin is 1024
```
* Update message.mk
change message to ‘approaching the maximum’
Co-Authored-By: mtei <2170248+mtei@users.noreply.github.com>
Added song of the ancients and kaine salvation fron Nier
Added Amusement park, Copied city, Vague Hope cold rain and weight of the world from Nier Automata
This PR is cherry-pick from 90b9a1aa7d in PR #5020.
@MxBlu copied quantum/rgblight.c to keyboards/mxss/rgblight.c on July 8, 2018. At that time, I think it would be better to copy quantum/rgblight.h at the same time.
Because if someone makes a change to `quantum/rgblight.[ch]` that is incompatible with the past, it may cause problems with the compilation of keyboards/mxss.
(Like when I changed the prototype of the `rgblight_effect_XXX()` functions of rgblight.c in PR #5020.)
* copy default over as starting point
* Getting rid of dvorak and colemak for now, added a couple changes to the
keymap
* removed refs to bad layers, formatting comments
* First version of my ergodox ported layout!
* Symbols layer, media layer, updated comments
* Hyper as a single key
* Fix stuck hyper key when switching layers
* Tweak some annoying things about the layout.
- move raise left and promote alt
- remove swap keys on the last layer
- reorganize media keys so they're easier to reach and more intuitive
- fix some comment template things
* Add readme for rjhilgefort planck layout
* readme tweak
* PR feedback changes
* Add support for wiring RGB LEDs for both halves directly to their respective controllers
RGB LEDs for each half don't need to be chained together across the TRRS cable with this
* Add split RGB LED support for serial
* Update config/rules for bakingpy layout
* Un-nest ifdefs for hand detection
* Read RGB config state from memory instead of EEPROM for serial updates
* Reuse existing LED pointer instead of creating new one
* Create custom Planck Light keycap
See README for details
* Link to WhatPulse in README
* More remapping, and add RGB LED effects
* Remove dead code, address PR feedback from drashna
* Adding new tap dance key
* Adding new tap dance code
* add code for copy/paste to tap dance
* testing tap dance enums
* New tap dance keycodes
* Fix enums
* handwired/magicforce61: refactor
Renamed layout macro KEYMAP to LAYOUT.
Keymap now uses #include QMK_KEYBOARD_H.
Refactored the default keymap to use non-auto-prepended keycodes per QMK standard.
Deleted deprecated action_get_macro block (was unused).
* handwired/magicforce61: Configurator support
* handwired/magicforce61: readme cleanup
Restructured the readme to be more similar to current QMK template.
* handwired/magicforce61: replace missing image in readme
Replaced the missing wiring image (error 404) with a table.
* handwired/magicforce61: rename readme to lowercase
* Convert config.h to #pragma once include guard
* rgblight.c: add RGBLIGHT_LED_MAP support
* add code to keyboards/helix/rev2/keymaps/five_rows/config.h to test rgblight.c:RGBLIGHT_LED_MAP
* Test end. Revert "add code to keyboards/helix/rev2/keymaps/five_rows/config.h to test rgblight.c:RGBLIGHT_LED_MAP"
This reverts commit e7488d6f73.
* update docs/feature_rgblight.md
* led_map[] move to PROGMEM
* introduce stt layout with K(row)(col)
* set bootmagic to lite
* Rename the original LAYOUT to LAYOUT_all
Introduce the STT layout
In additional the whole matrix was changed to support the K(row)(col) notation.
* rename LAYOUT to LAYOUT_all
* add QMK Configurator support
* stt keymap based on mrpetrov's default configuration on the hb85 he lent me
* update readme
* introduce basic and aop layouts along with QMK Configurator support for them
* add a new line
* add EEP_RST to layer 1 as it is needed to get rgb underglow to work
* add documentation on how to reset the eeprom on the board
* put contributors names where appropriate
* added Boy_.314's layout for halfnhalf keyboard
* reset rules.mk to default
* update keymap with qwerty layout, and enable tap dancing
* fixed formatting in layout visualization
* added rules.mk to custom layout
* added mod tap for ctrl/capslock
* fixed typo in config.h, remove excess in rules.mk, revert half_n_half rules.mk
* added Boy_.314's layout for halfnhalf keyboard
* reset rules.mk to default
* update keymap with qwerty layout, and enable tap dancing
* fixed typo in config.h, remove excess in rules.mk, revert half_n_half rules.mk
* added macros to raise layer
* fixed mismatched layout/comments
* fixed layout switching
* Remove unnecessary IS_COMMAND definition from clueboard/66_hotswap/gen1
* Remove old-style IS_COMMAND definition comment from dozen0
* Use get_mods() instead of keyboard_report->mods in georgi
* Recursively clone qmk_firmware repo
Specifically, so that it grabs the submodules, since ARM keyboards are becoming more common, and we are seeing more issues about chibiOS not being downloaded (in the error log, rather than by question)
* Wrap in shell
* keymap + alpha
* some fixes
* keymap + alpha
* some fixes
* drashna changes
* linked main Alpha repo in keyboards/alpha readme
* missed a spot
* there's another function called FUNC lol
* keymap + alpha
* some fixes
* keymap + alpha
* drashna changes
* Fixed include
* Revert "Fixed include"
This reverts commit ea92f261f8.
* messed up my git, fixed include
* starting work on TMO50 layout
* Update keyboards/tmo50/keymaps/default/keymap.c
Co-Authored-By: PyrooL <lm11887@gmail.com>
* Updated PyroL's TMO50 keymap
* Added task manager/Ctrl Alt Del that i stole from the eco keymap
* Clean up task manager and ctrl alt del macros
Co-Authored-By: PyrooL <lm11887@gmail.com>
* initial commit
* initial commit
* fixed indents
* spelling, capitalization, and order.
* added dota mode keymap, removed old comments
* fixed default keymap always having tilde, instead of grave accent and tilde. Improved dota keymap.
* lower does not change backspace to delete anymore
* corrected pgup/pgdown
* changed period on lower from numpad dot to regular dot
* added colemak and dvorak
* made colemak/dvorak border keys consistent with querty
* updated to match current practices, added custom metakeys for dvorak and colemak
* added disclaimer about audio
* renamed to lowercase
* replaced include guards with #pragma once
Co-Authored-By: rileyweber13 <rileyw13@protonmail.com>
* removed unncessary include
Co-Authored-By: rileyweber13 <rileyw13@protonmail.com>
* removed defines included in core
Co-Authored-By: rileyweber13 <rileyw13@protonmail.com>
* replace defines with an enum, switched from custom function to set_single_persistent_default_layer
* removed ifndef/include/endif left over from previous build system
* removed unnecessary ifdef block
* updated soungs to work with set_single_persistent_default_layer
* Instant 60
* Instant60 changes again
* turn off LSE and features
* Working RGB underglow 🎉
* Add missing files
* Update keymap to have reset
* Backlighting on
* Backlight code for instant60
* Move 072 files to common folder and use it in Instant60
* Updates
* Update keyboards/cannonkeys/instant60/rules.mk
Co-Authored-By: awkannan <andrew.kannan@klaviyo.com>
* add SCREEN_NAV layer for copy/pasting within screen
* working readreg/paste macros
* working read reg / paste macros
* write log and tran patterns, and expand
* add ls -la shortcut, add tab on combined layer
* put delete word on the right pinky key on shell_nav layer
* add TAB on the right side, add reset key
* added Cloud9 macros
* add cloud9 shortcuts to atreus layout
* added BROWSER_CONTROL layer
* finalized browser control layer
* adding comment
* add browser control layer to atreus
* add flashing command line
* remove the tab on combined layer
* remove the tomouse
* remove mouse layer, change log/tran expand patterns, cleanups
* add dumptlog macro
* add "delete to home" shortcut
* fix conflict
* remove unneeded mouse layer
* add meh shortcuts on the browser_control layer
* add/modify some macros
* explain the various layers
* putty paste is right mouse button
* add android studio shortcuts
* allow switching between base and alternate base layouts
* replace cloud9 shortcuts with android studio
* more android studio shortcuts
* add two meh shortcuts on keynav layer
* additional android studio shortcut
* added defines for android studio
* Updated layout after some months of testing.
The current setup looks quite better than the initial one. It's not
perfect but it allows me to work quite well.
The only big problem is the Alt modifiers on the home row which
sometimes break the typing if keys are pressed too fast. I'm also not
satisfied by the TAB key position on the thumb cluster.
Main improvements since previous push:
- Shift layouts on both halves
- Moved around symbols
- Improved number/fn keys
- Reorganized thumbs
* Used enum as suggested by @drashna :-)
* Corrected column count and adjusted layouts to include missing key
The original version reflected 14 columns and omitted KC_GRV, the 15th key on the top row. This revision adds support for the 15h key, and also updates the default (Tsangan) layout to include the HHKB layer keys.
* Reverted config.h to version in master branch
* Moved K413 to the correct location
* Added info.json
* Update keyboards/1upkeyboards/1up60hte/1up60hte.h
Co-Authored-By: newbold <adam@neatnik.net>
* Update keyboards/1upkeyboards/1up60hte/info.json
Co-Authored-By: newbold <adam@neatnik.net>
* Update keyboards/1upkeyboards/1up60hte/keymaps/default/keymap.c
Co-Authored-By: newbold <adam@neatnik.net>
* Update keyboards/1upkeyboards/1up60hte/keymaps/hhkb/keymap.c
Co-Authored-By: newbold <adam@neatnik.net>
* Update keyboards/1upkeyboards/1up60hte/keymaps/hhkb/keymap.c
Co-Authored-By: newbold <adam@neatnik.net>
* Update keyboards/1upkeyboards/1up60hte/keymaps/default/keymap.c
Co-Authored-By: newbold <adam@neatnik.net>
* fresh commit for a new fork for PR to upstream/master
* gaming mode added, lighting changes for other modes
* rules.mk fixed...
* fixed collision issue with aesthetic and shifty modes
* fixed collision issue with aesthetic and shifty modes
* troubleshooting game mode failing
* moved game tapdance key to default layer, fixed issue
* Align docker and vagrant base images - update box to debian 9.6
* Align docker and vagrant base images - lock docker image to debian 9
* Align docker and vagrant base images - update vagrant docker to debian 9
* added my own keymap
* changed thing
* updated keymap Samuel
* updated laypout for better one handed use
* updated stuff I want
* happy with my lagout
* formatting
* Added new literate config
* made everything nice
* cleaned
* fixed spelling and two small bugs in macros
* Made press and lift function for modifiers
* made taps occur on press instead of release
* added oneshot keys and chars cant be negative!
* removed debug message
* Added command and qwerty layers
* fixed bug with oneshot layer
* same bug, different key
Added Liebesleid by Kriesler (or Rachmaninoff), Michishirube from Violet Evergarden, Melodies of Life from Final Fantasy 9 and Eyes on Me from Final Fantasy 8
* Add nrichers keymap
* Additional keymap tweaks, add readme info
* Improve descriptions for changes from default keymap
* Add image of keymap, update .gitignore to
* Add image link
Adds an image of the modified keymap.
* Improve legibility of keymap changes with colour coding
* Tinker with color codes in Markdown
* Experiment with colour codes
* Tinker more with colour codes
* Figured out the easiest way to include colour coding
* Undo earlier .gitignore change
* Refactor layout macro names
Update the names of the layout macros to reflect QMK's desired usage.
- KEYMAP renamed to LAYOUT
- colinta keymap updated accordingly
- KC_KEYMAP renamed to LAYOUT_kc
- mtdjr keymap updated accordingly
* Update xd75.h to use #pragma once include guard
* Update keymaps to use QMK_KEYBOARD_H
* Refactor default keymap
- updated to use layout macro
- remove deprecated action_get_macro function
- add functions from QMK keymap.c template
- process_record_user
- matrix_init_user
- matrix_scan_user
- led_set_user
* Update supporting files
- updated config.h files to use #pragma once include guard
- remove errant QUANTUM_DIR code block
* Rename readme files to fully lowercase filenames
* Restructure keyboard readme
Updated the readme to better align with the current QMK template.
* Bugfixes to supporting files
* Make rgblight_update_dword not update eeprom (we already have
eeconfig_update_rgblight for that).
Make split i2c keyboards transfer active rgblight config rather than
eeprom saved version of rgblight config, enabling runtime changes
that aren't persisted to eeprom.
* prev_level and prev_rgb only store successfully transmitted values
* greenshadowmaker keymap for idobo xd75 massdrop
* remove uneeded config.h
* corrected format to match convention instead of xd75 where I accidentally started from
* Use correct functions for dip switch code
* Some planck cleanup
* Hopefully fix RGB Sleeping with RGB Matrix
* Add rgbmatrix extern
* Add numpad 5x6 layout
* RGB Tweaks
* Add RGB startup animation
* Minor RGB Fixes
* Turn off RBG on planck
* Enable separate storage of EEPROM
* Update Macro pad
* Add BJohnson Keymap and minor darshna tweaks
* Clean up rgb and other code for new numpad
* Remove clicky hachy thing
* Update my code to use built in MOD_MASK defines
* Fix up modifier calls
* Tweak to KC_MAKE
* Tweak to KC_MAKE
* Add Semi-colon to numpad
* Preprocess out rgb matrix stuff if not enabled
* Formatting of KC_MAKE
* Add stuff for matrix and light rgb coexistance
* Fix bad spelling
* Change where layer indication shows based on rgblight status
* Force set mods in KC_MAKE
* Optimize CRKBD
* added Boy_.314's layout for halfnhalf keyboard
* reset rules.mk to default
* update keymap with qwerty layout, and enable tap dancing
* fixed formatting in layout visualization
* added rules.mk to custom layout
* added mod tap for ctrl/capslock
* fixed typo in config.h, remove excess in rules.mk, revert half_n_half rules.mk
Added keymap for 60% board 1up60rgb. The map provides VIM-style navigation on a
second layer (L1) with HOME, PGDN, PGUP, and END keys on that same layer one
row below the home row. The layout is used by https://github.com/michaeldye.
* sleep until usb port becomes writable before running avrdude
* only wait for a writable USB port when not on MSYS
using MINGW or MSYS: sleep for one second, as before.
otherwise: wait for the port to become writable.
* typo
* typo
* Add satisfaction75 revision 1
* Update manufacturer
* Add tester layout and update rev1 comments
* Add ifdef guards for OLED for tester
* Add oled disabling rules
* Update to save backlight settings and setup for VIA custom config
* Add new VIA values to satisfaction75
* Safety guard in clock set mode
* Fix mistaken doc edit
* Address PR comments
* bring the default back to pass travis CI
* Address further PR comments
* Added 3 new songs and added new note type to musical_notes.h
Added Megalovania from Undertale, Kataware Doki from Kimi no Na Wa and La Campanella by Lizst to song_list.h
Added the breve (double whole note) and dotted breve note types to musical_notes.h. I included this because the default tempo is quite high, so I thought a note with higher
duration was needed
* Fixed indentation for new notes in musical_notes.h
Changed tabs to spaces in indentation
* 412_64 move to handwired
412_64 and its second printing, Mark Zero Stand Aside, are now obsolesced by new hardware. As only two units exist in the wild not owned by me, I'm moving the definition to handwired.
* Mark 3 Stand Aside ready for production.
Uploading firmware, compiled and tested, for Mark 3 Stand Aside. The hardware's ready, now the software is too.
* Whoops.
Should've branched before pushing Stand Aside. Sorry 'bout that.
* Revert "Whoops."
This reverts commit d222046cfe.
* Revert "Mark 3 Stand Aside ready for production."
This reverts commit c790899af7.
* Mark 3 Stand Aside ready.
Initial commit for Mark 3 Stand Aside, ready for production.
* Update keyboards/standaside/rules.mk
noroadsleft suggested removal of a line, 'LAYOUTS = ortho_4x16'. I agree.
Co-Authored-By: FateEverywhere <41215461+FateEverywhere@users.noreply.github.com>
* Cleanup for pull request.
Making changes requested by Drashna, as they're all good, and I know way less about the standards than they do.
* Initial cleanup completion.
Missed a few lines in standaside.c, they're cleaned up now.
* Update info.json
Adding layout for the macro version.
* Update info.json
Changed the macro layout to match exactly like the non-macro version (split backspace and bottow row match)
* added my launchpad
* updated keymap with legends and fixed layout errors
* Added default keymap with added layer for RGB controls and included the necessary config code
* fixed layer orders
* removed my personal keymap to clean PR
* missed an underscore
* updated readme
* removed more unnecessary code
* moved RGB code to its own config phone
* moved underglow info to its own readme
* removed redundant code from default_rgb config.h file, included QMK KEYBOARD H in place of initial defines in keymap.c
* reverted launchpad config
* removing the = because I can't figure out why its there
* Revert "removing the = because I can't figure out why its there"
This reverts commit e3b5e6d568.
* reverted rev1/config.h
* reverted all files I should not have touched
* removing redundant code in rules.mk
* readibility improvements to keymap
* Add ISO backslash key position to matrix and keymap files
* Use KC_NO instead of KC_BSLS for unused position in custom keymap
* Add new key position to json layout file used by online configurator
* Get things working except indicators
* Attempt to get things working
* hmm
* Compiles but doesn't run
* Make data transfer work
* Get all indicators working
* Remove old transport
* Prepare for pullreq
* Revert keymap from testing to production
* Final error checking for pull request
* Remove autogenerated is_command from config.h
* Rewrite pin toggles using qmk functions
* 412_64 move to handwired
412_64 and its second printing, Mark Zero Stand Aside, are now obsolesced by new hardware. As only two units exist in the wild not owned by me, I'm moving the definition to handwired.
* Mark 3 Stand Aside ready for production.
Uploading firmware, compiled and tested, for Mark 3 Stand Aside. The hardware's ready, now the software is too.
* Whoops.
Should've branched before pushing Stand Aside. Sorry 'bout that.
* Revert "Whoops."
This reverts commit d222046cfe.
* Revert "Mark 3 Stand Aside ready for production."
This reverts commit c790899af7.
* Update userspace with common config.h
* Add my dz60, satan and xd75 keyboard keymaps
* Fixing executable bits changed during last upstream merge
* Cleanup unnecessary files and defines
* Remove unnecessary defines from userspace config
* Add underglow controls to dz60 function layer
* Fixing merge conflicts
* Fixing exectable bits changed during merge
* Userspace update
* intial commit
* fix up some of the cookie cutter code
* define pins used and size of switch matrix
* enable lighting settings and bootmagic lite
* create the appropriate LAYOUT macro
* remove a comma for compilation errors
* provide a suitable keymap
* disable console and command due to firmware being too large
* add Caps Lock LED support
* Add QMK Configurator support
* fix markdown rendering
* fix mechmerlin to mechkeys
* use `register_code16` and relatives for tapdance code
* rename tapdance keys to more closely mirror the `KC` names in QMK
* additional naming change to match QMK style
* add a tapdance example for creating advanced mod-tap and layer-tap keys
* add optional curly braces to match QMK conventions
* change example to use `register_code16()` and tapdance keycodes more closely matching QMK variants
* Gray Studio HB85 Initial Support
* Fixed README image
* Updated README
* Disabled Bootmagic and Console for HB85
* Fixed Numpad 4 matrix place
* Fixes board crashing with RGB enabled
* Moved HB85 files to gray_studio folder
* Uses old i2c library since this version makes RGB underglow work
* Improved default keymap with underglow control layer
* Removes obsolete program and uses generic script instead
As per zvecr feedback
* Uses GPIO Functions to initialise and set RGB underglow PINS
* Add keycode for KC_MAKE
* Add KC_MAKE keycode
* Add stanrc85.c file with KC_MAKE
* Remove unused include
* Improved KC_MAKE stolen from Drashna
* Define mod mask for new KC_MAKE code
* RESET board to flash after compiling
* Remove send_string
* RESET fixed in KC_MAKE
* add dusty keymap
* change keymap folder to match my github username
* initial keymap completed in comments only
* layout without NAV completed in comments only
* disable Command to prevent interference with Space Cadet keys
* switch _ and \ in the symbol layer
* Layers complete through _NAV
* add thumb keys to _NAV
* complete _NUM
* all layouts complete; still needs `process_user_record()`
* completed first draft of keymap; still needs config.h to match
* corrected keycodes for Mac macro-volume keys
* fix Mac mute keycode
* add missing Mac keycodes for previous and next track
* placeholder for qwerty layout, not yet completed;
remove unnecessary breaks;
add todos
* eliminate Preonic branch before switching to Minidox branch:
• delete dustypomerleau Preonic keymap folder
• complete keymap.c (QWERTY layer, vanilla numbers layer)
TODO:
• add preferences to config.h
• complete the README
* edit commented keymap diagrams for clarity in dual function keys
* define initial config.h and add rules.mk for mouse key support
* fix redundant line after implementation of tap_code()
* fixed key_timer declaration, added README and rules
* formatting of keymap
* add CTPC to config
* cycle thumb keys to favor center position
* modify config.h for temporary Pro Micro compatibility
* remove superfluous call to use serial; homebrewed mod tap keys are still broken with OSL
* merge _SYS and _MEDIA on new Z_SYS key
* ALT_OP example of new MT macro complete
* initial narze-inspired MT fixes in PRU
* add (currently superfluous) custom keycode for the _SYS layer
* rudimentary `OSL` symbol macros that immediately register the mod and fail to reset the oneshot layer, but do output the proper keys—fix both of these things
* remove permissive hold to improve tapping performance
* remove calls to `clear_oneshot_layer_state()`, as they have no effect inside `process_record_user()`. Tapdance appears to be the way forward.
* final commit before tapdance code; correct layout in comments
* initial tapdance code for shifted mod taps
* add numeric and ergo NUM layers and pinky shifts for keycuts
* add TD() wrappers to tapdance codes and clean up commented layout guides
* add faux return to cur_dance to allow compilation - TODO: research what the default clause should be in cur_dance
* update commented schematics for better readability
* add backspace and delete to lockable layers, Z_SYS -> SYS_Z for consistency, fix schematic errors
* add `DOUBLE_SINGLE_TAP` to tapdance cases to allow doubling of the single tap character without waiting tapping term
* remove reduced oneshot tapping toggles
* update README
* newline tweak :)
* Update keyboards/minidox/keymaps/dustypomerleau/keymap.c
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* remove `PREVENT_STUCK_MODIFIERS`, as this is default behavior
* enable extrakey in rules to enable media keys
* enable extrakeys for media key compatibility on macOS
* add dash and slash to _NUM layers
* change to universal volume keycodes
* revert micro volume adjustments to macOS-specific codes due to lack of functionality (macro volume adjustments are still universal)
* fix image of _SYS layer in comments
* more diagram fixes in comments
* fix typo
* simplify tapdance code
* match _NUM_N to _NUM_E
* move slash to allow better use of comma in number layers
* match layer and keycode enums to the docs
* correct qwerty numlock to match numeric numlock layer
* Change how desktop commands work
* Add DST_MOD_MASK as a config option
* DST_RMV → DST_REM
* Add melody96:konstantin keymap
* Update custom SEND_STRING
* Move feature flags from userspace into keyboard rules
* Use "Vo-", "Vo+" instead of "VoD", "VoU" in keymap comments
* Add RGB controls and numpad Unicode to Melody96 keymap
* Add RGB_SET keycode to Melody96 and RGB files to userspace
* Generate UNICODE and UNICODEMAP constants using macros
* Avoid collisions with X_* send string constants
* Use two spaces before inline comments
* Add _keymap versions of other custom Quantum functions
Not added: eeconfig_update_keymap, eeconfig_read_keymap
* Switch to UNICODEMAP in keyboard rules
* Make toggle_numpad a nested function in process_record_user
* Set Melody96 underglow color to Godspeed blue on EEPROM reset
* Remove most _keymap and _user definitions in userspace
Some keyboards misuse _user functions by defining them in the base files
instead of the corresponding _kb functions (especially led_set_user and
matrix_init_user). Until this is fixed (#5148), I've removed definitions
in my userspace that could cause linking collisions.
* Update GODSPEED_BLUE values and RGB mode keys
* Add GODSPEED_YELLOW color
* Set preferred intervals for rgblight effects
* Update tap dance function names
* Replace td_lshift_fn with generic td_mod_layer, add TD_RCTL_FN
Move TD_FN_RCTL after TD_RCTL_FN
* Replace td_fn_rctrl with generic td_layer_mod
* Add blank lines, prefer explicit initialization
* ACTION_TAP_DANCE_DOUBLE_MODS → ACTION_TAP_DANCE_DOUBLE_MOD
* Update Godspeed colors
* Add media controls to Melody96 keymap
* Add SysRq, Break combos and other keys to Melody96 keymap
* Add HOME/END keys as upper/lower on arrow-up/down
* Reduce .hex file size by turning off unneeded options
* Put digit keypad onto left hand upon RAISE; this will sometimes be preferable to double-hits of right hand
* Latest super latest version merge
* cbbrowne keymap for XD75re
* starting notes on XD75re keymap plans
* First draft of bottom row of QWERTY
* Switch my special bottom line over to QCENT
* Dunno
* Filling in wanted keys, bit by bit...
* Add copyright, extra macro
* Clean up comments, remove some experimental code I didn't like
* TODO plans for xd75re
* clean up keyboard layout
* QCENT2 is my new experiment for the main keyboard...
* Add a few more main layer keys, and modify LOWER to shift things outwards to conform with main layer
* Clean up RAISE layer to conform with main layer, remove QCENT layer as QCENT2 is the new thing
* More xd75 changes, now that I actually have it in hand
* shift keymap around, as original attempt was a bit too aggressive in keeping to the edges
* more revs to XD75
* Dropping parts of the centre keypad in favor of Keys I Really Need
* Improve documentation to conform with how builds are done now
* Improve documentation to conform with how builds are done now
* Add cbbrowne rules file as alternative to having the rules in Makefile
* Makefile not needed anymore for individual keymap
* Some revs to my keymapping
* Add {}
* Add PGUP/PGDN
* Shifted some middle-range keys around
* Needed Tilde, Backquote, and to shift RESET onto FUNCTION layer
* Wanted ~
* cbbrowne hasn't anything to do with hadron keymaps
* trim unneeded bits
* I prefer OrgMode for my notes
* Have a right-alt
* Layer keys make LED colors change
* Add sample user rules for cbbrowne
* Add source of xd75 rules
* Individualized xd75 rules
* Adopt LAYOUT to genericize the layout as an ortholinear 5x15 keyboard
I'm a web designer and know there are several "decent" code editors out there, but I would figure not everyone into keyboards is, so I found Sublime text a bit of a hard sell for someone who just need to manipulate some text files. VS Code or Atom would b a much better suit for them instead of dropping $80 on a "decent" text editor.
* Tidy up 5x6.h
- replaced tabs with spaces (QMK convention)
- aligned layout macro visually
* Fix Configurator support for Dactyl Manuform 5x6
- layout macro had the wrong name in info.json
* Tidy up 5x7.h
- replaced tabs with spaces (QMK convention)
- aligned layout macro visually
* Fix Configurator support for Dactyl Manuform 5x7
- corrected keyboard height
- layout macro had the wrong name in info.json
* Tidy up 6x6.h
- replaced tabs with spaces (QMK convention)
- aligned layout macro visually
* Fix Configurator support for Dactyl Manuform 6x6
- layout macro had the wrong name in info.json
* Separate keymaps to VIA enabled/dissabled.
- Default rules.mk has been changed to disable via.
- VIA keymaps have been added for default keymaps.
* Update naming
* Add INSERT and EEP_RST to HS60 keymap
* Add INSERT to keymap
* Layer based RGB colors
* Move RGB code to layer_rgb.c
* New file with layer based RGB colors
* Use RGB code if RGBLIGHT is enabled
* Set RGB options in config.h
* Remove rgb enable from init user
Some keyboards misuse _user functions by defining them in the base files
instead of the corresponding _kb functions (especially led_set_user and
matrix_init_user). Until this is fixed (#5148), I've removed definitions
in my userspace that could cause linking collisions.
* Initial refactor of handwired bluetooth mod to keymap
* Initial refactor of handwired bluetooth mod to keymap - strip out unnecessary duplicate config, update readme
* Initial refactor of handwired bluetooth mod to keymap - reduce firmware size
* Initial refactor of handwired bluetooth mod to keymap - update readme image
* add dusty keymap
* change keymap folder to match my github username
* initial keymap completed in comments only
* layout without NAV completed in comments only
* disable Command to prevent interference with Space Cadet keys
* switch _ and \ in the symbol layer
* Layers complete through _NAV
* add thumb keys to _NAV
* complete _NUM
* all layouts complete; still needs `process_user_record()`
* completed first draft of keymap; still needs config.h to match
* corrected keycodes for Mac macro-volume keys
* fix Mac mute keycode
* add missing Mac keycodes for previous and next track
* placeholder for qwerty layout, not yet completed;
remove unnecessary breaks;
add todos
* eliminate Preonic branch before switching to Minidox branch:
• delete dustypomerleau Preonic keymap folder
• complete keymap.c (QWERTY layer, vanilla numbers layer)
TODO:
• add preferences to config.h
• complete the README
* edit commented keymap diagrams for clarity in dual function keys
* define initial config.h and add rules.mk for mouse key support
* fix redundant line after implementation of tap_code()
* fixed key_timer declaration, added README and rules
* formatting of keymap
* add CTPC to config
* cycle thumb keys to favor center position
* modify config.h for temporary Pro Micro compatibility
* remove superfluous call to use serial; homebrewed mod tap keys are still broken with OSL
* merge _SYS and _MEDIA on new Z_SYS key
* ALT_OP example of new MT macro complete
* initial narze-inspired MT fixes in PRU
* add (currently superfluous) custom keycode for the _SYS layer
* rudimentary `OSL` symbol macros that immediately register the mod and fail to reset the oneshot layer, but do output the proper keys—fix both of these things
* remove permissive hold to improve tapping performance
* remove calls to `clear_oneshot_layer_state()`, as they have no effect inside `process_record_user()`. Tapdance appears to be the way forward.
* final commit before tapdance code; correct layout in comments
* initial tapdance code for shifted mod taps
* add numeric and ergo NUM layers and pinky shifts for keycuts
* add TD() wrappers to tapdance codes and clean up commented layout guides
* add faux return to cur_dance to allow compilation - TODO: research what the default clause should be in cur_dance
* update commented schematics for better readability
* add backspace and delete to lockable layers, Z_SYS -> SYS_Z for consistency, fix schematic errors
* add `DOUBLE_SINGLE_TAP` to tapdance cases to allow doubling of the single tap character without waiting tapping term
* remove reduced oneshot tapping toggles
* update README
* newline tweak :)
* Update keyboards/minidox/keymaps/dustypomerleau/keymap.c
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* remove `PREVENT_STUCK_MODIFIERS`, as this is default behavior
* enable extrakey in rules to enable media keys
* enable extrakeys for media key compatibility on macOS
* add dash and slash to _NUM layers
* change to universal volume keycodes
* revert micro volume adjustments to macOS-specific codes due to lack of functionality (macro volume adjustments are still universal)
* keymap + alpha
* some fixes
* keymap + alpha
* some fixes
* drashna changes
* linked main Alpha repo in keyboards/alpha readme
* missed a spot
* there's another function called FUNC lol
* keymap + alpha
* some fixes
* keymap + alpha
* drashna changes
* Fixed include
* Revert "Fixed include"
This reverts commit ea92f261f8.
* messed up my git, fixed include
* starting work on TMO50 layout
* Update keyboards/tmo50/keymaps/default/keymap.c
Co-Authored-By: PyrooL <lm11887@gmail.com>
* Removed since options are in userspace
* Removed RGB option that was breaking one of my builds
* Remove unused options
* Removed options present in userspace, add board specific options here
* Removed code also present in userspace
* Turns out those lines were needed, added them back
* Testing changes
* Added code to ensure board read as ANSI instead of default ISO for HS60
* Setting \ key to "MOD" instead of "ALPHA" for lighting
* enable velocikey for my userspace and explicitly for my 75% layout
* add guards to only turn on RGB stuff if the RGB pin is actually defined
* update 60_ansi keymap
* update the 60_ansi_split_bs_rshift keymap
* update 66_ansi keymap
* update docs
* Update layouts/community/60_ansi/mechmerlin-ansi/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update layouts/community/60_ansi_split_bs_rshift/mechmerlin-split/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update layouts/community/60_ansi_split_bs_rshift/mechmerlin-split/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update layouts/community/66_ansi/mechmerlin/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update layouts/community/60_ansi_split_bs_rshift/mechmerlin-split/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update layouts/community/60_ansi/mechmerlin-ansi/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update layouts/community/60_ansi/mechmerlin-ansi/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* remove my attempt to find a good way to detect this
* move audio clicky into user space and do feature setting per keyboard
* fixup 66_ansi keymap
* update changelog
* update readme
* Added personal keymaps for Planck, Preonic, Vitamins Included by Juno
* Removing redundancies as suggested
* More removals that were missed out in the previous commits
* Updated Preonic to use new layout
* More redundancies missed out
* Updated more optimal code for FN layer LED indicator.
* Further codes clean up.
* Added a dual windows/osx layout
Default layer is normal ISO for windows. Second layout is Windows ISO layout but for OSX, but with the keys corrected so you will get the correct shifted and alt'd keys on OSX (keyboard keys match OSX keys without having to change your keyboard type in system preferences). Layer three is configuration and other functions, and layer four is where the shifting magic happens. Also tab and caps lock have been swapped around.
* made sure bootmagic is in a seperate rules.mk
made sure bootmagic is in a seperate rules.mk
* commiting the keymap rules.mk
commiting the keymap rules.mk
* Convert community layout to userspace for future use
* Big readme update
* Move layer toggle to CAPS
* Readme updates
* Deleted since unused
* Removed call to unused .c file
* [keymap] adding my Levinson keymap
pretty self explanatory, added the readme, just in case
tested it just now, seems to work fine for my needs
* Update keymap.c
removing the deprecated persistent layer function as Drashna kindly reminded me
* Apply suggestions from code review
incorporated the suggestions, and thanks again for taking care of me with my silly changes :)
Co-Authored-By: OMGVee <mateescu.victor@gmail.com>
* Fix up audio calls
* Add backlight controls
* Add backlight controls and remove RGB underglow
* Make HS60 board specific changes to readme
* Remove BL_TOGG as it isn't use on this board
* use #pragma once
* get rid of code for unused indicators
* pragma once and other small fixes for consistency
* use #pragma once
* pragma once and other small fixes for consistency
* add a short blurb to the readme
* turn on compiler optimization flags
* remove the compiler optimization
* remove compiler optimization for super16
* pragma once and turn on bootmagic lite
* pragma once changes and turning on bootmagic lite
* switch to using pragma once
* switch to using #pragma once
* switch to using #pramga once
* convert tabs to spaces
* fix#4578: don't call gemini protocol code when in bolt mode
Add missing break; statements in switch. The missing break resulted in
a fall through and an additional processing of the gemini code.
* Initial Clueboard 66% arm support
* Fix LAYOUT_66_ansi
* wip
* Bring this branch up to date with led_matrix
* Get Clueboard 66% hotswap working with led_matrix
* stm32 cleanup
* Fix compiling for clueboard 66% hotswap prototype
* Reduce the size of the prototype firmware
Many instances in the QMK Docs referenced KEYMAP macros, which is outdated terminology.
Replaced most instances of KEYMAP with LAYOUT, to reflect the desired usage.
* Draft commit of typing speed RGB control
* More information in the readme
* Support all RGB animation modes (Fixes#1)
* Added support for all RGB light modes to use typing speed
Except christmas lights because that is seizure-inducing at high speeds!
* Introduced a value range specific to each RGB mode
Because some modes are a little too much when running at full speed!
* Update readme.md
* Update readme.md
* Re-arrange typing_speed definitions (Fixes#5) (#6)
* Re-arrange variable definitions to avoid including quantum.h from rgblight.c
* Fix a compilation error when trying to run make test:all
* Tweaks to the typing speed decay rate
* Renamed to momentum; moved implementation into dedicated files
* Groundwork for toggling momentum on/off (currently always on)
* Add EEPROM toggle for momentum-matching
* Moved momentum out of RGBLIGHT_ENABLE toggles so it's more generic
* Move momentum decay task out of rgblight_task()
* Fix missing momentum.h in lufa.c
* Experimental LED support (untested)
* Draft commit of typing speed RGB control
* More information in the readme
* Support all RGB animation modes (Fixes#1)
* Added support for all RGB light modes to use typing speed
Except christmas lights because that is seizure-inducing at high speeds!
* Introduced a value range specific to each RGB mode
Because some modes are a little too much when running at full speed!
* Update readme.md
* Update readme.md
* Re-arrange typing_speed definitions (Fixes#5) (#6)
* Re-arrange variable definitions to avoid including quantum.h from rgblight.c
* Fix a compilation error when trying to run make test:all
* Tweaks to the typing speed decay rate
* Renamed to momentum; moved implementation into dedicated files
* Groundwork for toggling momentum on/off (currently always on)
* Add EEPROM toggle for momentum-matching
* Moved momentum out of RGBLIGHT_ENABLE toggles so it's more generic
* Move momentum decay task out of rgblight_task()
* Fix missing momentum.h in lufa.c
* Added documentation
* Renamed feature to velocikey
* Reverted readme to original state
* Correct the readme title
* Updated feature name in the docs
* Update EECONFIG name
* Add compile-time toggles for velocikey
* Update feature documentation
* Revert "Merge branch 'led-support' into master"
This reverts commit e123ff5feb, reversing
changes made to df111a55b9.
* Move velocikey EECONFIG definition to depend on VELOCIKEY_ENABLE
* Rename decay_task function to decelerate
* Apply suggestions from code review
Co-Authored-By: chrislewisdev <chris@chrislewisdev.com>
* Re-order eeconfig definitions
* Apply coding conventions
* Apply #ifdef check in lufa.c
* Refactored interval time checks into one functionc
* Small rename
* Fix unused function error for layouts not using all rgb effects
* Only update EEPROM if Velocikey is enabled
* Incorporate code review feedback
* Small adjustment to top-end decay rate
* Add Velocikey documentation to table of contents
* Bring tetris:default keymap size down by disabling audio
Descriptions for B5_AUDIO, B6_AUDIO, and B7_AUDIO under Hardware Options were partially italicized when parsed by Docsify, though rendered as intended by GitHub.
* initial commit
* get rid of vanilla cookie cutter code and replace with more correct info
* edit config file for pins and switch matrix size
* turn on bootmagic lite, and backlight/rgb settings
* copy pasta switch matrix from noroads tool
* create an appropriate keymap (copy pasta)
* disable some features to decrease firmware file size
* add qmk configurator support
* add in support for caps lock, scroll lock, and num lock leds
* add temporary pdhelix(Patched Helix) code
* add test code into quantum/split_common/matrix.c
* add test code into keyboards/handwired/pdhelix/
* Revert "add test code into keyboards/handwired/pdhelix/"
This reverts commit 9ed98f0797ddd962c99756689fc4ecb4cd067d3d.
* Revert "add test code into quantum/split_common/matrix.c"
This reverts commit 1876d3ed69f6c213153a9f6476192be839f16c1f.
* Revert "add temporary pdhelix(Patched Helix) code"
This reverts commit 41ac92b814e3f894eaf85bc3e5bb945895342fa8.
* fix quantum/split_common/matrix.c: select_col()/select_row()
* Changed use of '\s' in grep to '[ \t]' for portability
* Pushed DFU Keyboard.h into a shell script
* Fixed execution permissions on make_dfu_header,sh
* introduce wkl directory and readme
* move bface into winkeyless directory and edit readme for new make instructions
* move bmini into the winkeyless directory and edit readme
* move bmini ex into winkeyless directory
* edit readme some more
* add newbs guide to readmes
* fix path to bface
* temporarily turn off community layout support until we refactor this taking out all the custom ps2avrgb stuff
* Change Command keycode defaults to match corresponding Bootmagic codes
* Make alternate magic key keycodes consistent
* Reflect changes from previous commit in tmk_core/common/command.c
* Remove unnecessary MAGIC_KEY_* definitions from keymaps compatible with these changes
* Swap E and BSPACE for MAGIC_KEY_EEPROM
* Add MAGIC_KEY_EEPROM_CLEAR instead of MAGIC_KEY_EEPROM_ALT
* Remove BOOTMAGIC_ENABLE checks around EECONFIG stuff
* Update Command descriptions
* initial work to add eeprom to haptic feedback and decouple the feedback process from keyboards
* Haptic feedback enhancements: on/off toggle working, feedback order working
todo:
-work on modes switching
-get modes switching to save to eeprom
* haptic enhancement - eeprom and modes added
* Added set and get functions for haptic feedback
* initial implementation of solenoids under haptic feedback
* changed eeprom to 32 bits to reserve blocks for future features
* start documentation of haptic feedback
* change keycode per comment from reviewers
* typo fixes
* added eeprom for solenoid configs
* added solenoid and docs
* Add/fix default parameters configs, improve docs
* more doc cleanup
* add in solenoid buzz toggle, clean up doc
* some fixes for error in compiling solenoid
* fix a chibios specific i2c read function and added one for AVR controllers in DRV2605L.c
* fixes for avr side issues
* update keymap
* fix keymap compile error
* fix bugs found during solenoid testing
* set pin that is not powered during bootloader
* added warning about certain pins on the MCU may trip solenoid during DFU/bootloader
- flags for the linker
- added INSERT key as I kinda use it for work fairly often
- turned on more things in rules.mk since I recovered space via linker
flags and whatnot
Based on conversation with Drashna on Discord, we know that if ONE_SHOT_TAP_TOGGLE is 5, then tapping a one shot mod key 5 times holds the one shot key permanently, but to come out of this, you need to press the same key only once.
* Add support for using ranges for RGB
This patch adds support for controlling continuous ranges of RGB LEDs.
Helper functions for split boards are also available.
* RGB Range: Use hardware-platform agnostic wait
* Update KC_GESC documentation
- document caveats on OSX and expected behavior with KC_GESC and GUI
- clarify documentation slightly
- give examples of expected output in actual use
* Update OSX -> macOS
* Captilization
* remove simply
* added my own keymap
* changed thing
* updated keymap Samuel
* updated laypout for better one handed use
* updated stuff I want
* happy with my lagout
* formatting
* Added new literate config
* made everything nice
* cleaned
* fixed spelling and two small bugs in macros
* Made press and lift function for modifiers
* Remove problematic unicode_map stub definition in process_unicodemap.c
* Add unicode_map declaration to process_unicodemap.h
* Disable UNICODEMAP on converter boards that don't use it
* Added xeal60 via clone of lets split
* Delete removed other keymaps
* Basic keymap (no FN). Compiles.
* Removed NP_STAR and NP_SLSH.
* Removed "debounce_algo = manual" in all keyboards with CUSTOM_MATRIX = yes.
* Changed order of rules in TMK. Documented feature.
* Fixed missing whitespace in debounce documentation
Table wasn't working due to missing newline.
* Added bold in a few areas.
* DO NOT USE - Removed debounce from TMK.
* Remove accidental xeal60 commit
* DO NOT USE - debounce successfully compiled.
* DO NOT USE Revert back to original API to support split_keyboards.
* Working eager_pk
* Whitespace cleanup.
* Restored debounce.h since there wasnt any real change.
* Moved debouncing_time variable to inside #if debounce
* Removed check for custom_matrix. We can safely include the debounce file for compilation when custom_matrix is used.
* Removed #include "matrix.h" from debounce.h
* Bug fix - was using MATRIX_ROWS instead of num_rows
* Fixed compilation error with debounce_sym_g
* Renamed DEBOUNCE_ALGO to DEBOUNCE_TYPE
* Malloc array in debounce_eager_pk, since split keyboards only use MATRIX_ROWS/2.
* Fix compile error in debounce_eager_pk
* Stricter, leaner DEBOUNCE_TYPE section in common_features.mk. Cleanup debounce_type.mk
* Add suspend functions
* Disable RGB code if it's disabled
* Add keyboard_init functions
* Change where references so it will compile
* Wrong command chained in wake up kb function
* Fix non-feature file changes
* Add documentation
* Re-add matrix init docs
* add rgblight code to example
* Remove suspend code
* Clean up docs
* Fix docs
* Fix suspend code
* more doc fixes
* change function to startup_* rather than keyboard_init_
* fix spelling error
* fix up docs to finish removing keyboard_init
* Use Pre and Post init functions
* Update Documenation
* Remove changes to my keymap and userspace code
* Cleanup
* Revert changes to extra files
* Forgot a semicolon
* Make sure all protocols call keyboard_setup
* Cleanup functions
* Unset startup_user
* Remove changes from division keyboard
* Readd startup_user function
* Remove all to startup_user
* Update docs/custom_quantum_functions.md
Co-Authored-By: drashna <drashna@live.com>
* Update docs/custom_quantum_functions.md
Co-Authored-By: drashna <drashna@live.com>
* Add suggestion line
* Rebase fixes
* Update documentation to be more useful/accurate
* Cleanup of documentation
* Fix spacing inconsistency
* Revert unexpected change to keymap
* Add a mechanism for force building a particular community layout
* Add docs for FORCE_LAYOUT argument
* Update output name when FORCE_LAYOUT is enabled
* Don't click if turning audio off
On ARM, playing the click when turning off audio causes the audio get stuck and continually play the tone
* Fix Audio EEPROM support for ARM
* Update touched files to conform to QMK Coding Conventions
* Add better check for ARM EEPROM support
* Migrate fn_actions for default keymaps
* Rename the Grave/Escape Shift masks
* No need for shift_esc_shift_mask
* Change breaks to return false
* Right align pointers
* Add default case
* Separate cases with empty lines
* NUBS_Z: initial version
Create a keycode that is normally Z, but KC_NUBS when tapped while Alt is being held.
This removes the possibility of using an Alt+Z shortcut.
* NUBS_Z: modification
Modify NUBS_Z macro to only use alternate operation if Right Alt is being held, rather than responding to either Alt key.
Also add QMK version keycode to System layer, Equals key.
* Remove unneeded breaks from process_record_user
* Macro refactoring
- removed G_RST and G_C10R macros
- updated G_BRCH macro
- outputs `master` if used while Shift is held down; or my git alias for the current branch otherwise
- updated G_FTCH macro
- outputs `git pull upstream ` if used with Shift; `git fetch upstream ` otherwise
- swapped `modifiers` variable for `get_mods()` function directly for checking modifier state
- swapped keymap-level modifier mask macros for QMK-core mod mask macros (thanks vomindoraan #4337)
- renamed MODS_RALT_MASK to MOD_MASK_RALT (more consistent with the above change)
* Update readme files
* set bootmagic from no to lite and put in a note in the readme
* use pragma once
* discovered a compile error when testing with default keymap. The inlined led functions need to be externed in the .c file
* might as well turn on mouse keys as well
* [Keymap] Adding buhearns keymap
* Removing deprecated function
with fauxpark's help
* Update readme.md
* Switching to UNICODE_ENABLE
with drashna's help
* Update rules.mk
* Update config.h
* Update config.h
Tidying up
* Update keymap.c
Tidying up
* Update readme.md
Tidying up
* Update rules.mk
Tidying up
* Removing GESC and adding TILD
* initial commit with edits to vanilla code
* Add QMK Configurator support
* add an appropriately generated keymap
* pins, matrices, and features added in
* moved it all to a regular directory. It's called regular as that's what it's called in the group buy. In the future we will have other directories for the other PCBs that are delivered to customers.
* forgot caps lock led support
* Update keyboards/doro67/regular/keymaps/default/config.h
Use the NAME
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update keyboards/doro67/regular/readme.md
Be more explicit
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Add stm32f072 base ck4x4 to handwired
* add prints
* Save these tries
* Save changes again
* Working hadron oled
* OLEd working but ws2812b still iffy:
* save another try
* Encoder feature + OLED
* RTC code
* Implement clock setting mode
* Whitespace
* Encoder hooked up to working LED PWM code
* Add missing files
* eeprom changes
* Save changes
* Move i2c master
* Move satisfaction75 under cannonkeys
* Set proper default folder
* Revert some core changes
* Undo paved iris changes
* Reorganize code for maintainability and prep for new features
* Add starting code for clock OLED mode
* Clock set mode finished
* Add custom encoder modes
* Actually add VIA keymap
* Gate to only 072
* fix gate for only 072
* Update header guards and includes
* Update i2c selection strategy
* Update board.c to handle software reset to DFU
* add dusty keymap
* change keymap folder to match my github username
* initial keymap completed in comments only
* layout without NAV completed in comments only
* disable Command to prevent interference with Space Cadet keys
* switch _ and \ in the symbol layer
* Layers complete through _NAV
* add thumb keys to _NAV
* complete _NUM
* all layouts complete; still needs `process_user_record()`
* completed first draft of keymap; still needs config.h to match
* corrected keycodes for Mac macro-volume keys
* fix Mac mute keycode
* add missing Mac keycodes for previous and next track
* placeholder for qwerty layout, not yet completed;
remove unnecessary breaks;
add todos
* eliminate Preonic branch before switching to Minidox branch:
• delete dustypomerleau Preonic keymap folder
• complete keymap.c (QWERTY layer, vanilla numbers layer)
TODO:
• add preferences to config.h
• complete the README
* edit commented keymap diagrams for clarity in dual function keys
* define initial config.h and add rules.mk for mouse key support
* fix redundant line after implementation of tap_code()
* fixed key_timer declaration, added README and rules
* formatting of keymap
* add CTPC to config
* cycle thumb keys to favor center position
* modify config.h for temporary Pro Micro compatibility
* remove superfluous call to use serial; homebrewed mod tap keys are still broken with OSL
* merge _SYS and _MEDIA on new Z_SYS key
* ALT_OP example of new MT macro complete
* initial narze-inspired MT fixes in PRU
* add (currently superfluous) custom keycode for the _SYS layer
* rudimentary `OSL` symbol macros that immediately register the mod and fail to reset the oneshot layer, but do output the proper keys—fix both of these things
* remove permissive hold to improve tapping performance
* remove calls to `clear_oneshot_layer_state()`, as they have no effect inside `process_record_user()`. Tapdance appears to be the way forward.
* final commit before tapdance code; correct layout in comments
* initial tapdance code for shifted mod taps
* add numeric and ergo NUM layers and pinky shifts for keycuts
* add TD() wrappers to tapdance codes and clean up commented layout guides
* add faux return to cur_dance to allow compilation - TODO: research what the default clause should be in cur_dance
* update commented schematics for better readability
* add backspace and delete to lockable layers, Z_SYS -> SYS_Z for consistency, fix schematic errors
* add `DOUBLE_SINGLE_TAP` to tapdance cases to allow doubling of the single tap character without waiting tapping term
* remove reduced oneshot tapping toggles
* update README
* newline tweak :)
* Update keyboards/minidox/keymaps/dustypomerleau/keymap.c
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* remove `PREVENT_STUCK_MODIFIERS`, as this is default behavior
* Grab HEX and BIN files from autogen
And push them to qmk.fm/compiled
* Make autogen copy extension agnostic
This way, when travis cl scrpit looks for hex files, it will actually grab bin files, and not hex files for ARM boards
* Handle the AUTOGEN in :bin target to properly handle edge cases
Both the TADA68 and ATSAM boards generate the hex file and then convert it to a bin file. The changes I made does not handle this well, at all. This removes the hex and replaces it with a bin, if a bin is normally generated.
* Revert hex target to original copy command
* Check hex and bin separately in compile push script
Since I don't know how to script this, well
* Simplify push to compiled folder
* Further simplify compiled push script
* Move AUTOGEN parsing to a more sane location to prevent tech debt
Thanks to skully!
* Remove AUTOGEN completely, as it's not needed
This has the benefit of making everything super simple, since we can pull every hex and bin from the root of the qmk_firmware folder, and move that to th compiled folder. This also removes old and unneeded code, and removes some tech debt that has been accrued, without adding more, in theory.
* Tweaks to default 1up60hte layout + support for HHKB style layout
* Added changes to layouts
* Fix config.h
* Fixed errant KC_NO in layout
* Added readme to keyboard... Will update with images/store link when avail.
* Update to use LAYOUT_60_hhkb default layout
* md formatting fix
* Update keyboards/1upkeyboards/1up60hte/readme.md
Co-Authored-By: bubnick <bubnick@users.noreply.github.com>
* Update keyboards/1upkeyboards/1up60hte/readme.md
Co-Authored-By: bubnick <bubnick@users.noreply.github.com>
* Added layout to rules.mk, fixed layout to be compatble with community HHKB keymaps
* Added image, updated store page to readme
* Add userspace files for vosechu
* Code review corrections
* Few more code review corrections
* Initial add of Laptreus code
* Initial add of Laptreus code
* Adding last punctuation to default
* Add some debug suggestions to the debug readme
* Fixes for PR feedback
* Fixing capitalization of readme files
* update auto detect connection logic
* remove unneeded file
* make an appropriate readme
* amend the LAYOUT macro to adhere to new QMK standards and create an appropriate keymap
* add QMK Configurator support
* a bunch of changes lol
* delete unneeded routines
* update date to modern times
* remove a useless prototype
* add in drashna's suggestions on PR
* Improvement of Space Cadet Shift by preventing to automatically apply a modifier on the key and allow to override the default modifier. Closesqmk/qmk_firmware#3815
* Improve the use of the DISABLE_SPACE_CADET_MODIFIER flag to avoid unregistering KC_LSFT when equals to LSPO_MOD
* change #if to if statement
* Added callbacks to one shot modifier changes
* Altered signature of callback functions
* Reordered the callback methods, shortened brief documentation
* Added One Shot Modifier callback documentation
* First attempt at unit tests
* Revert "First attempt at unit tests"
This reverts commit 5ec21a7822.
* Simplified oneshot function implementations
* Made clear_oneshot_locked_mods to be conform action_util.h, adhering to the (void) signature
* Made used datatypes for oneshot mods consistently unsigned integers
* Corrected callback to call clear callback when clear_oneshot_locked_mods is invoked
* Simplified oneshot equals statements
* Corrected return type and signature of get and set oneshot locked mods
* Consolidated one shot callbacks, added initial layer callback version
* Fixed non-updating one shot layer variable after timeout or other clear, added code comments
* Added better one shot key docs
* added keyboard jj4x4, a shorter version of the jj40
* removed useless file
* edited jj4x4 readme.md
* optimized array size in jj4x4 config.h, removed reference to jj40 layouts from rules.mk
* removed custom matrix for this ps2avrgb board, refactored column and row pins
* fix a bug in which the physical matrix did not match the physical layout. Top row was missing 1 key and bottom row had 1 extra key
* amend keymap to account for the new physical matrix
* 6.25u space bar is actually supported, so add a new layout that supports this
* fix keymap readme to no longer need the cautionary warning
* Moving sentraq keyboards to sentraq subdirectory.
* Updating readme markdown to correct make commands.
* Updating s60_x references to point to the new vendor subdirectory.
* Fixed stripped spaces in markdown.
* Updated help information in s60_x readme and linked to additional documentation.
* Make QMK Configurator work with e7-v1
This adds the missing info.json file for the e7-v1 keyboard which I
forgot to add to the original PR.
This allows to see the correct layout in QMK Configurator.
* Fix the ISO layout
The ISO layout has one extra key (hash/tilde) on row 3 right before
the enter key.
The e7-v1 PCB has this key wired at the same switch as the ANSI
backslash (since this switch is not used in ISO).
The tkl_ansi layout had an incorrect value for the grave/tilde key, and
number row keys were misnumbered. This fix removes the typo and adds the
missing K1C key.
* Fix mixed tabs and spaces in adb_usb and m0110_usb makefiles
* Fix typos in converter build options
* Tweak ordering and spacing in converter makefiles
* initial commit
* Do a nice write up for readme
* establish switch matrix and physical layout
* Put in the pins that are used
* QMK configurator support and keymap
* set bootloader to caterina because pro micro boohoo
* add ortho_4x4 support for user spaces
* got the columns reversed lol
* Tweaks to default 1up60hte layout + support for HHKB style layout
* Added changes to layouts
* Fix config.h
* Fixed errant KC_NO in layout
* Added readme to keyboard... Will update with images/store link when avail.
* Update to use LAYOUT_60_hhkb default layout
* md formatting fix
* Update keyboards/1upkeyboards/1up60hte/readme.md
Co-Authored-By: bubnick <bubnick@users.noreply.github.com>
* Update keyboards/1upkeyboards/1up60hte/readme.md
Co-Authored-By: bubnick <bubnick@users.noreply.github.com>
* Added layout to rules.mk, fixed layout to be compatble with community HHKB keymaps
* Create ISO HHKB keymapping for GH60
* Add media controls to Fn layer
* Use M(x) instead of F(x), add Copyright text
* Add README for additional information about TMO50 features/quirks
* Add indicator LED code
* Move indicator code to tmo50.c
* move over kbd19x into the kbdfans directory
* move over kbd4x into the kbdfans directory
* move kbd66 into the kbdfans directory
* move the kbd6x into the kbdfans directory
* move kbd8x into the kbdfans directory
* move kbd75 into the kbdfans directory
* move kbd67 into kbdfans directory
* add a fairly sparse readme for kbdfans directory
* update make instructions for keyboards and add the Complete Newbs Guide to readmes that was missing it
* get kbd75 compiling again
* remove repetitive #defines of KC_NO and KC_TRNS when QMK_KEYBOARD_H is already included in KBD75
* add links to kbdfans readme
* fix some readme formatting
* there is no reason to have two different keymaps with such a small difference, condensing to one
* turning on backlights by default
* enable backlight by default for kbd66
* noticed that the kbd75 had caps lock led code in every keymap. Moved it out to the keyboard.c so everyone can partake.
* Update keyboards/kbdfans/kbd66/readme.md
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* update readme link ordering
* Added QMK Config for Sentraq Number Pad keyboard.
* Sentraq Number Pad documentation cleanup.
* mend
* Added json for configurator.
* Small documentation tweaks.
* Updated the layouts to use the default layouts that match.
* Uncommended user level functions in keymap, left custom keycode/macro code commented but documented why.
* Switched to #pragma once from #ifndef structure in header file.
* Moved Sentraq number pad to sentraq creator directory.
* Renamed sentraq_number_pad to number_pad now that it's nested in the sentraq directory.
* Updated references inside the files for the keyboard rename and nesting.
* Adds keymaps for muzfuz
* Remove unused keys from adjust layer
* Bring in line with current QMK standards.
* Adds Preonic and adjusted Planck keymaps
* Make changes per review request
* update reset sequence info
* fix my rgb underglow led number flub
* add a more sensible keymap
* add caps lock led support
* remove unused #define
* swap the spacebar sizes around to match the space65
* use vomindoraan's suggestion in PR to use IS_LED_ON
* fixed arrow keys and left control
* added right shift
* latest version
* reverted arrow keys
* edited readme
* added osu layer
* updated osu layout
* updated osu layout
* added full arrow keys to osu layout
* in case i mess up creating macros
* added the best meme key in the world
* added plover steno layer
* updated boy314 layout
* removed unused layers
* added boy314 xd75 layout, inspired by preonic layout
* added boy314 xd75 layout, inspired by preonic layout
* version 2 of boy314's xd75 layout
* added readme notes
* updated readme for boy314 xd75 layout
* qwerty support, brackets on bottom row, caps lock underglow
* fixed readme/
* small changes to allow merging
* minor changes to format
* fixed up default readme
* added numpad and tweaked bottom row
* updated xd75 and preonic rev3 keymaps
* added initial half n half files
* fixed .h file
* updated names
* fixed layout in halfnhalf.h
* fixed manu name, changed bootloader in rules.mk
* removed redundancies in preonic and xd75 layouts
* readme updated
* initial commit
* get rid of vanilla code, and fix formatting
* write up a nice looking readme
* add in pins and enable features
* define keymap and switch/physical matrix
* add QMK Configurator support
* switch to bootmagic lite to decrease file size
* Move boards to cannonkeys and share resources
* Share common files between cannonkey boards
* Fix ortho60 keymap
* update LED numbers
* Add RGB keys to Ortho60 and Ortho48
* Add Backlight control to default layout Ortho60 and 48
* Remove unnecessary ws2812.c SRC from rules.mk
* Make Default standard layout
Move Mac OS layout to a separate layout. Basically Mac has the Alt and GUI keys swapped
* Fix typos
* Use Bootmagic keys instead of separate MacOS keymap
* Create ISO HHKB keymapping for GH60
* Add media controls to Fn layer
* Use M(x) instead of F(x), add Copyright text
* Add README for additional information about TMO50 features/quirks
* handwired/space_oddity: refactor
- config.h: updated to use #pragma once include guard
- rules.mk: replace `?=` with `=`
- space_oddity.h:
- updated to use #pragma once include guard
- layout macro KEYMAP renamed to LAYOUT
- default keymap:
- updated to use #include QMK_KEYBOARD_H
- replace references to Planck keycodes
- replace fn_actions-powered layer switch keycode
- rebuild keymap block comments
- keymap layers now use short-form keycodes
- refactor action_get_macro keycodes into process_record_user
* handwired/space_oddity: Configurator support
* handwired/space_oddity: readme cleanup
- update readme to better conform with QMK template
- fixed the make command.
* Add the e7-v1 keyboard
The e7-v1 is a 75% keyboard made by Exclusive based on an Atmega32u4
pub with RGB lights on top and backlighting.
This PR add supports for the regular ANSI layout and ANSI split
backspace layout. No ISO yet :(
* My e7-v1 keymap
Difference from base layout:
* split backspace
* Home & End on last keys of row 0 instead of Insert/Del
* Fn is on the End key when hold
* supports both a windows/linux keymap and osx keymap
* layer change is reflected in the rgb leds of the logo
* [BACKLIGHT_CAPS_LOCK_INDICATOR] Use backlight toggling as Caps Lock LED
I've implemented this feature because S65-X doesn't have LED indicators
and the existing led_set_kb(usb_led) function try to use backlight as
indicator but that creates an inconsistency with backlight_config state.
- define `BACKLIGHT_CAPS_LOCK_INDICATOR` to enable Caps Lock indicator
using backlight (for keyboards without dedicated LED)
- Don't turn off LED indicators when suspend because backlight is
already turned off. Else led_set(0) will turn back on backlight.
- Documentation has been updated
* [BACKLIGHT_CAPS_LOCK_INDICATOR] Turn off all LED indicators except Caps Lock if BACKLIGHT_CAPS_LOCK_INDICATOR
* [BACKLIGHT_CAPS_LOCK] Rename BACKLIGHT_CAPS_LOCK_INDICATOR
* [BACKLIGHT_CAPS_LOCK] Use new IS_LED_ON method
The following layouts were being rendered with 6.75u Spacebars instead of 7u:
- LAYOUT_ansi_blocker_7u
- LAYOUT_ansi_blocker_7u_small_lshift
- LAYOUT_ansi_blocker_7u_small_bspc
- LAYOUT_ansi_blocker_7u_small_lshift_small_bspc
- LAYOUT_iso_blocker_7u
This commit corrects this issue.
Flagged by yanfali on QMK Discord.
- layout macro and keymap layers refactored to more closely resemble physical keyboard layout
- added layout mockup to alice.h
- correct info.json data (was missing a key)
* Added southpole keyboard
added southpole keyboard folder and files including keymaps folder. Keymaps have errors and will not compile yet
* Add files via upload
added manufacturer and product name and description
* Update config.h
* Add files via upload
changed formating added layer
* cleaned up files, fixed foobeard keymap, and added maker info
* fixed keymap files
* Update keyboards/southpole/keymaps/foobeard/keymap.c
Co-Authored-By: ericduns <ericduns@gmail.com>
* Update keyboards/southpole/keymaps/default/keymap.c
Co-Authored-By: ericduns <ericduns@gmail.com>
* made changes fixing outdated lines and added readme.md
* made requested changes for pr to all files
* removed vs code and added new line to southpole.h
* moved some stuff around on my iris layout, but don't expect a lot of changes in the future
* good working setup
* [keymap] some mods to my (omgvee) Helidox keymap
* updated zlant keymap with diagram
* made edites to last post
* noticed slight error in default keymap due to my own mistake. fixed to be the same as default
* fixed spacing in second base layer second row from left
* Added xealousbrown keyboard.
* Changed to pragma once in config.h
* Update keyboards/handwired/xealousbrown/rules.mk
Added bootloader.
Co-Authored-By: alex-ong <the.onga@gmail.com>
* Update keyboards/handwired/xealousbrown/config.h
Commented out IS_COMMAND() since it is already default value.
Co-Authored-By: alex-ong <the.onga@gmail.com>
* Remove duplicated or unnecessary definitions in config.h and rules.mk
* Use IS_HOST_LED_ON() macro
* Add mouse acceleration to kbd6x:konstantin keymap
* Clear and restore mods when sending macros
* Make SEND_STRING_CLEAN a config option
* Add NO_ACTION_ONESHOT to userspace config
* Add files via upload
* Changed _____ to _______ as requested to meet QMK standards.
* Added readme.md
* Removed "PERMISSIVE_HOLD" as it is no longer used.
* Additional code changes made per request
* Added # to first line and removed redundant line.
* Modified Copyright information
* Added space after # for proper formatting
* Formatting changes and additional details
* Remove unnecessary IS_COMMAND definition in clueboard/66/rev4
* Replace keyboard_report->mods with get_mods() in IS_COMMAND definitions
* Update docs to use get_mods() instead of keyboard_report->mods
* Replace keyboard_report->mods with get_mods() in tmk_core/protocol/usb_hid/test
For some reason, this occurrence used KB_LSHIFT and KB_RSHIFT, which don't exist
* Replace keyboard_report->mods with get_mods() in Massdrop keyboards (as per @patrickmt)
* Move Iris via support to Via keymap
And move it out of the main keyboard files
* Actually add via keymap folder
Because using git when you're tired is apparently a very bad idea, and you do stupid things like not running git add
* Clean up config.h file for iris via keymap
* Add default value for IS_COMMAND for COMMAND feature
* Cleanup and consistency
* Update Templates to reflect change
* Fix IS_COMMAND in template
* Fix IS_COMMAND define
* Use consistent IS_COMMAND block in templates
* Remove unnecessary `#undef IS_COMMAND` directives
* Fix compile issue on orthodox
* Reomve IS_COMMAND option for newer boards
* Remove all existing definitions of IS_COMMAND if they use default LSHIFT and RSHIFT setting
* Remove a couple of additional IS_COMMAND defines
* Remove remaining redundant IS_COMMAND definitions
* Remove #undef IS_COMMAND from orthodox:drashna and whitefox:konstantin
* Remove multiple empty lines in modified config.h files
* Update additional boards
* Reomve IS_COMMAND from newer boards
* Update Alice keyboard
* Remove IS_COMMAND from additional boards
Jan 24th edition
* Only re-enable RGBLIGHT if it was on when going to sleep
* Reformat file to follow QMK Standards
* Fix check, since this is a loop, whoops
Much thanks to @Rockman18 for catching this and posting the additional code!
* Add ability to animate arm_atsam led matrix from the center of a circle
* Make arm_atsam led matrix circular animation circular rather than obloid
* Fix indentation in tmk_core led_matrix.c
* Basic Fanoe support (no LED yet)
* Enable RGB lights
* Backlighting support
* Change to reflect Wheat Field brand of Fanoe PCB
* Hot swap variant
* Fix review comment issues
* Fix review issues
* Corrected rules.mk
* Change naming to avoid using possibly copyrighted names
* Added info.json
* Corrected manufacturer name in info.json
* Keymap updates
* Add layout for use with ws2812b and such
* Fixes based on code review
I think `quantum.h` should contain only API declarations that `quantum.c` provides externally. `rgb.h` contains function weak definitions. This should not be in `quantum.h`.
I worked on those keymap to simplify the use of 60% keyboards for
coders. Instead of trying to mimic planck, this keymap remove
raise/lower layer complexity and keep some important sign keys for coder
in the upper right side pretty much the same way as they are on a full
keyboard.
A karabiner configuration is also provided to mimic most of the keymap
features on the macbook internal keyboard for when you are forced to use
it.
* Adding documentation for the LM layer modifier.
This will hopefully clear up some of the confusion around adding this layer modifier. I struggled with this a bit as well at first.
* Removing duplicate table.
* Changed section title to `Changing Layers`
* Retain name
* Custom keymap.
* Fix magic layer, enable Unicode.
* Update README.
* Make Unicode config change keymap-local.
* Move magic to AltGr, simplifying layout.
* Changes per Drashna.
* Fix magic+esc = backtick!
* Change reset implementation per Drashna's suggestion.
* Add a few more symbols so long as the commit is open - √ℜℂℤ⊙ℚℕ and the like.
* Typo fix.
* Slight simplification, drop an extra variable.
* Added busby222 config
* Fixed bug with leftover colemak and dvorak layouts
* Fixing dumb mistake
* Minor tweaks to layout. Need to use at work tomorrow to make more adjustments
* Added mouse controls for raised layer
* Update keymap.c
* Update keymap.c
* Update keymap.c
* Update keymap.c
* Update keymap.c
* Update config.h
Added mouse specific settings for smoother mouse movement (default is sort of hard to use)
* config.h cleanup
* Lowering max mouse speed (personal preference)
* Update keymap.c
* Update keymap.c
* Update keymap.c
* Update keymap.c
* Update keymap.c
* Update config.h
* Update rules.mk
* Added MIDI layer
* Switched the Adjust layer to an MO call
* Update keymap.c
* Fixing bugs related to midi layer
* Changed "Caps Lock" ctrl to RCTRL for use in VirtualBox
* Added shovelpaw keyamp
* Removed deprecated QUANTUM_DIR code block
* Switched midi layer to be only active when held
* Addressing requested changes
* Removed unnecessary include statement
* initial commit
* move the original kbd67 stuff into its own directory, rev1
* get rid of vanilla cookie cutter code
* put in the switch matrix pins, backlight pin, and rgb underglow pin. Number of underglow LEDs is questionable.
* switch matrix created for hotswap
* create a basic keymap for testing
* make info.json for QMK Configurator support
* rename kbd67 due to compile error
* kbd67 generic readme file
* fix make instructions for the new rev1
* comment out unneeded rgb light #defines
* Update keyboards/kbd67/readme.md
Add an extra space for proper markdown rendering
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update keyboards/kbd67/hotswap/hotswap.h
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update keyboards/kbd67/hotswap/keymaps/default/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* use pragma once
* proper format of MechMerlin
* Cluecard: refactor
- renamed layout macro KEYMAP to LAYOUT
- reformatted layout macro to more closely resemble physical device layout
- keymaps now use #include QMK_KEYBOARD_H
- config.h files updated to use #pragma once method
- deleted outdated QUANTUM_DIR code blocks from rules.mk files
- white space changes on rules.mk files (alignment/readability)
* Cluecard: Configurator support
* Cluecard: readme update
- added image
- updated Docs links
* Clueboard 66% HotSwap: corrected matrix and Configurator data
- removed k31 and k84 from LAYOUT
- both appear to be unsupported for this PCB according to images on clueboard.co
- updated block comment mock-ups to match changes
- rebuilt info.json file
- delete removed keys from default keymap.c
* Clueboard 66% HotSwap: readme update
- fix make example
- updated Docs links
* Clueboard 66% HotSwap: 66_ansi keymap update
Updated to use #include QMK_KEYBOARD_H
* Clueboard 60% refactor
- renamed layout macro KEYMAP to LAYOUT_all
- renamed layout macro KEYMAP_AEK to LAYOUT_aek
- removed redundant KC_TRNS definitions from keymaps
- all keymaps now use #include QMK_KEYBOARD_H
* Clueboard 17%: refactor
* Clueboard 17%: Configurator support
* Clueboard 17%: update Docs links in readme
* Cleanup the 2x1800 files
* Update Clueboard 60% to standard matrix
* Update the clueboard default keymaps
* Refresh and update clueboard 17
* Add the 66% hotswap to Clueboard's readme
* Clarify the 66% hotswap's readme
* change the image to imgur
* Update the clueboard 66 to follow modern standards
* update clueboard 66_hotswap to follow modern practices
* Move the logo to imgur
* update clueboard/card to follow modern practices
* remove clueboard/66 as a valid make target
* Address comments in #4902
* fix user keymaps after the changes
When this if statement is false, it will cause the report ID to be read as the LED state.
We already know there are two bytes in the endpoint, which is a reasonably good indicator that it contains a report ID, so we should always read both.
* Added TGR Alice keyboard support
This keyboard uses ps2avrGB firmware, so I used the same matrix
Bootmapper Client was using and was able to flash it appropriately.
* Refactor alice to use QMK core
* Fixed markdown line breaks on TGR Alice readme
* handwired/retro_refit: refactor
- retro_refit.h
- updated to use #pragma once include guard
- refactored layout macro to not auto-prepend KC_ to keycodes
- renamed to LAYOUT (from KEYMAP)
- aligned for readability
- default keymap.c
- now uses #include QMK_KEYBOARD_H
- removed unused fn_actions and action_get_macro blocks
* handwired/retro_refit: Configurator support
* handwired/retro_refit: readme update
Updated readme to format of current QMK template.
* Create ISO HHKB keymapping for GH60
* Add media controls to Fn layer
* Use M(x) instead of F(x), add Copyright text
* Create initial firmware for TMO50
* Correct year and author
* Fix repos README
* Remove unnecessary code
* Change include guard in tmo50.h
* Plain60: remove redundant include guard from plain60.h
Superseded by #pragma once.
* Plain60: add Docs links to readme file
* Plain60: Configurator support
* new hhkb keymap implementing movement layer + comfort features
* Apply suggestions from code review
Co-Authored-By: schaefer-dev <schaefer.dev@gmail.com>
* removed deprecated function action_get_macro and mousewheel configs that are no longer used
* handwired/reddot: refactor
- reddot.h
- updated to use #pragma once include guard
- renamed layout macro KEYMAP to LAYOUT
- refactored arguments to more closely resemble physical layout
- aligned for readability
- keymaps/default/keymap.c
- now uses #include QMK_KEYBOARD_H
- updated include path for keymap_french.h
- refactored to use short keycodes
- aligned for readability
* handwired/reddot: Configurator support
* handwired/reddot: readme update
- update readme to current QMK template
- add KLE permalink to my best guess at the layout
* Initial support for TKC Candybar
* Correct FN layer issue
Both shift keys were overloaded. Moved Caps Lock to FN + C.
* Update keyboard description in config.h.
* Info.json
* Update project information
* Update keyboards/candybar/readme.md
Co-Authored-By: TerryMathews <terry@terrymathews.net>
* handwired/qc60: refactor and Configurator update
- correct layout macro name (LAYOUT_ANSI_DEFAULT to LAYOUT_ansi_default)
- add layout data for remaining layout macros
- correct ISO layout macros (neither had a split left Shift)
- refactor LAYOUT_iso_alt (place KC_NUHS key on home row; consistent with LAYOUT_iso_default)
- proto.h refactored to use #pragma once include guard
* handwired/qc60: keymap refactor
- delete redundant KC_TRNS and KC_NO aliases
* handwired/qc60: readme update
- update header (made consistent with QMK template)
- update Docs links (Newbs Guide; grammar)
* handwired/ortho60: Configurator update
- correct labels for Up and Right keys
- add layout data for LAYOUT_1x2uC
* handwired/ortho60: readme update
- update readme file to use QMK template
* handwired/ortho60: deleted DEFAULT_FOLDER rule
Not needed as the keyboard currently has no revisions.
* TKC1800: refactor
- tkc1800.h
- updated to use #pragma once
- visual alignment
- update config.h files to use #pragma once
- update all keymaps to use #include QMK_KEYBOARD_H
- delete redundant mod mask, KC_TRNS, and KC_NO definitions
- reformat keymap layers for readability
- add block comment for Function layer in default keymap
- delete commented action_get_macro code blocks (deprecated function)
- update files to better conform with QMK coding conventions
- update smt keymap to use set_single_persistent_default_layer (instead of persistent_default_layer_set)
- replace instances of `?=` with `=` in rules.mk
* TKC1800: Configurator visual fixes
- correct key sizes and positioning
- reformat file so each physical key object has its own line for readability
- update and add `label` keys for readability
* TKC1800: readme update
- fix image gallery link
- update Hardware Supported and Hardware Availability lines
- update make example (add :default suffix)
- update QMK Docs links (Newbs Guide; grammar)
* Add missing semicolons to smt keymap
* Grammatical fixes for GPIO Control doc
I found the Advanced Settings section to be poorly written.
* Commit suggestions from fauxpark
* Change first instance of "microcontroller" to match suggestion
Discovered the LAYOUT_compact macro didn't compile in QMK Configurator. Realized the reason for that was that it automatically prepends `KC_` to every keycode received.
Renamed the macro to LAYOUT_kc so Configurator will ignore it.
Also changed the file to use the #pragma once include guard because I was in here anyway.
* change VENDOR_ID, PRODUCT_ID, and DEVICE_VER as step one in getting VIA support
* fix v1 product id
* VIA doesn't use the version, so we need to encode it into PRODUCT_ID
* Defined IS_(HOST_)LED_ON/OFF() and improved LED documentation
* Update docs/custom_quantum_functions.md
Co-Authored-By: DidierLoiseau <didierloiseau+github@gmail.com>
* Update docs/custom_quantum_functions.md
Co-Authored-By: DidierLoiseau <didierloiseau+github@gmail.com>
* Integrated @drashna and @fauxpark's PR comments
- changed all plurals of "LED" to "LEDs" in the file
- rewording of the note about host_keyboard_leds() vs. led_set_user()
* Update docs/custom_quantum_functions.md
Co-Authored-By: DidierLoiseau <didierloiseau+github@gmail.com>
* Eliminate separate slave loop
Both master and slave run the standard keyboard_task main loop now.
* Refactor i2c/serial specific code
Simplify some of the preprocessor mess by using common function names.
* Fix missing #endif
* Move direct pin mapping support from miniaxe to split_common
For boards with more pins than sense--sorry, switches.
* Reordering and reformatting only
* Don't run matrix_scan_quantum on slave side
* Clean up the offset/slaveOffset calculations
* Cut undebounced matrix size in half
* Refactor debouncing
* Minor fixups
* Split split_common transport and debounce code into their own files
Can now be replaced with custom versions per keyboard using
CUSTOM_TRANSPORT = yes and CUSTOM_DEBOUNCE = yes
* Refactor debounce for non-split keyboards too
* Update handwired/xealous to build using new split_common
* Fix debounce breaking basic test
* Dodgy method to allow a split kb to only include one of i2c/serial
SPLIT_TRANSPORT = serial or SPLIT_TRANSPORT = i2c will include only
that driver code in the binary.
SPLIT_TRANSPORT = custom (or anything else) will include neither, the
keyboard must supply it's own code
if SPLIT_TRANSPORT is not defined then the original behaviour (include
both avr i2c and serial code) is maintained.
This could be better but it would require explicitly updating all the
existing split keyboards.
* Enable LTO to get lets_split/sockets under the line
* Add docs for SPLIT_TRANSPORT, CUSTOM_MATRIX, CUSTOM_DEBOUNCE
* Remove avr-specific sei() from split matrix_setup
Not needed now that slave doesn't have a separate main loop.
Both sides (on avr) call sei() in lufa's main() after exiting
keyboard_setup().
* Fix QUANTUM_LIB_SRC references and simplify SPLIT_TRANSPORT.
* Add comments and fix formatting.
* Crawlpad: delete kbfirmware JSON file
* Crawlpad: refactor
- config.h and crawlpad.h updated to use #pragma once method
- layout macro renamed from KEYMAP to LAYOUT_ortho_4x4
- default keymap now uses #include QMK_KEYBOARD_H
- deleted deprecated action_get_macro function
- cleanup rules.mk file
- add LAYOUTS = ortho_4x4 to rules.mk
* Crawlpad: Configurator support
* Crawlpad: readme update
- update image link to direct link
- fully update Docs link line
- delete reference to deleted kbfirmware JSON file
* Add encoder support
* Add VIA support to Iris Rev. 3
* Update pinout and disable mouse keys to free up space
* Rollout VIA support to all Iris revisions
* Update default keymap
* Update vendor ID
* Add kbd6x:konstantin keymap
* Prevent tap dance from sending LShift as a weak mod in KBD6X
* Move config.h and rules.mk definitions into userspace
* Add UC_WIN to UNICODE_SELECTED_MODES
* Temporarily use Bootmagic until Command is fixed
* Move common behavior from keyboards into userspace
* Update kbd6x:konstantin keymap and userspace
* Make a RCTRL layer in kbd6x:konstantin
* Make KC_ESC turn off layers
* KC_ESC turns L_FN off only if it was locked on
* Add missing record->event.pressed checks
* Move numpad toggling logic into function
* Disable Bootmagic, enable KEYBOARD_SHARED_EP with Command
* Add support for THE50
A 50% custom keyboard designed and produced by LazyDesigners
* THE50 code-improvement
Implement the changes suggested by noroadsleft.
* changed ortho keymaps and userspace
* changed prime_o keymap
* changed userspace
* optimized keymaps and userspace
* removed permissive hold as it doesn't seem to do anything
* defined TAPPING_TERM in userspace config.h
* Commited into clean repo
* Gergo initial release
* Cleaning up
* Cleaning up
* Update readme.md
* Updated image, fixed MD formatting, added clairity
* Moved keymap to keyboard subdir, modified rules.mk
* Cleaned header guards
* Cleaned header guards. Read the rest of the PR comments
* Update keyboards/gergo/keymaps/default/keymap.c
Co-Authored-By: germ <jeremythegeek@gmail.com>
* Update keyboards/gergo/readme.md
Co-Authored-By: germ <jeremythegeek@gmail.com>
* Moved makefiles to keymap mod-area-thingy-with-overrides
* Update rules.mk
Slow the roll on the defaults while I wait for merge
* Update rules.mk
* Cleaning cleaning cleaning
* More housekeeping. Keeping optdefs
* moved keyboard specfic conf to config.h. Can we merge yet?
* added info.json
* Check the size of the SET_REPORT packet
If we have two bytes, that probably means the first is a report ID. The 6KRO interface may or may not have one, but the NKRO interface always does, so we need to check this regardless of whether KEYBOARD_SHARED_EP is defined.
* Fix indentation
* adds proton c base
* fixes custom matrix include
* adds readme.md
* initial proton coversion, no pin mapping
* start of mcu selection
* add pin mapping and sweet16 test
* add at90 to list
* disable backlight, fix d7
* update flag names
* doc updates
* proton c update for mcu selection
* initial prime_o commit
* Cleaned up comments, other things.
* Update bakingpy 4x12 keymap and add test mode for debugging/development (#4810)
* Keymap: ave-63's iris layout (#4812)
* Updated keymap to use standard seven-underscore KC_TRNS notation
* initial prime_o commit
* Cleaned up comments, other things.
* Updated keymap to use standard seven-underscore KC_TRNS notation
* Downbubble: Configurator fix
Fix the visual key alignment and some typos.
* Downbubble: refactor
Rename layout macros:
- LAYOUT_downbubble_standard to LAYOUT_standard
- LAYOUT_downbubble_splitbackspace to LAYOUT_split_bs
- LAYOUT_downbubble_splitrightshift to LAYOUT_split_rshift
- LAYOUT_downbubble_splitnumpad to LAYOUT_split_numpad
- LAYOUT_downbubble_spliteverything to LAYOUT_all
* Remove unused UNICODE(n) macro, update docs
* Add note about max length of unicode_map to docs
* QK_UNICODE_MAP → QK_UNICODEMAP
* Refactor process_unicode_map
* process_unicode_map → process_unicodemap
This is done for consistency: UNICODEMAP is the method (hence UNICODEMAP_ENABLE, process_unicodemap), whereas unicode_map is the mapping table itself.
* Update references and ordering in docs/understanding_qmk
* Add additional note to docs/understanding_qmk
* &unicode_map[index] → unicode_map + index
This avoids the issue of the compiler sometimes complaining about the array index being out of range
* Update docs/getting_started_make_guide
* Update method sections in docs/feature_unicode
Microsecond (us) delays are now handled by a busy wait loop according to MCU frequency. This replaces the system counter method which had an overhead of around 12us.
TC5 device and supporting routines removed as it was the old us delay counter.
wait_ms is now properly a macro to CLK_delay_ms.
wait_us is now properly a macro to CLK_delay_us.
Removed CLK_get_us as it has no use.
All calls to CLK_get_ms() have been replaced by timer_read64() with corrected typing.
All calls to CLK_delay_ms() have been replaced by wait_ms().
All calls to CLK_delay_us() have been replaced by wait_us() and timings verified or updated as needed after review on scope.
Corrected typing of variables using 64bit ms timer readings if needed.
* initial commit, this now mostly works
- RGB controls work
- Dynamic keymap still broken due to eeprom
- Via works
* STM32 eeprom update
- Update EEPROM emulation library to handle 8bit data like AVR.
- This library also allows for multiple page pairs resulting in greater EEPROM size flexibility
* hs60 changes
* HS60 hhkb added
* Update keyboards/hs60/v2/config.h
Co-Authored-By: yiancar <yiangosyiangou@cytanet.com.cy>
* Fractal: layout macro cleanup
Removed KEYMAP alias for LAYOUT_preonic_mit. Alias was unused, and the terminology usage is deprecated.
* Fractal: readme cleanup
Updated the line containing the documentation links in the readme.
* Fractal: disable preonic_mit community layout
QMK doesn't have a preonic_mit community layout at this time.
Disables preonic_mit as an option for community layout. Can be re-enabled when the layout is added.
* Numbrero: fix Configurator mismatch
Key object order in info.json didn't match the layout macro, leading to keys being assigned out-of-sequence.
* Numbrero: tidy
- white space changes in numbrero.h (alignment/readability/QMK conventions)
- minor changes to readme.md (grammar, mostly)
* Tradestation: tidy code
- correct JSON syntax on info.json
- visual key alignment on info.json
- white space changes on rules.mk and tradestation.h (readability/QMK conventions)
* Tradestation: readme refactor
Modify readme.md to more closely match QMK template.
* Tradestation: readme update
Update The Board podcast link for libsyn.
* S65-X: remove S65-Plus support
The original QMK codebase for the Sentraq S65-X actually supported both the S65-X and the S65-Plus. In the interim, the S65-Plus has been broken off into its own directory.
This commit removes support for the S65-Plus from the `keyboards/s65_x/` directory, as that code has been superseded by the code in the S65-Plus directory (`keyboards/s65_plus/`).
- deleted S65-Plus layout macros from s65_x.h and info.json
- deleted s65plus keymap directory
- removed references to the unused column pins
- removed the two unused columns for the switch matrices
- renamed switch K300 in LAYOUT_ansi to K301 (reflects matrix position)
- renamed switch K214 in LAYOUT_iso to K114 (reflects matrix position)
* S65-X: keymap refactor
- all keymaps now use #include QMK_KEYBOARD_H
- default and iso keymaps refactored for readability
- deleted redundant KC_TRNS and KC_NO keycode definitions from smt keymap
* S65-X: readme update
- updated Hardware Availability link
- updated Docs links
* S65-Plus: add LAYOUT_iso data
Adds LAYOUT_iso macro to s65_plus.h and info.json, and an ISO layout version of the default keymap.
* S65-Plus: refactor default keymap
- refactor for alignment/readability
- removed fn_actions code block
- add empty process_record_user block
* S65-Plus: readme update
- Hardware Availability link is now a hyperlink
- updated Docs links
* S65-X: enable 65_ansi and 65_iso community layouts
Thi commit allows the Sentraq S65-X to use the 65_ansi and 65_iso community layouts.
- LAYOUT_ansi renamed to LAYOUT_65_ansi
- LAYOUT_iso renamed to LAYOUT_65_iso
- added LAYOUTS rule to rules.mk
* Remove QUANTUM_DIR code blocks from keyboard rules
This commit removes the deprecated "QUANTUM_DIR" code block from
rules.mk files that affect entire keyboards.
* remove QUANTUM_DIR code blocks from rules for default keymaps
This commit removes the deprecated "QUANTUM_DIR" code block from
rules.mk files that affect default keymaps.
* remove QUANTUM_DIR code blocks from rules for user keymaps
This commit removes the deprecated "QUANTUM_DIR" code block from
rules.mk files that affect "user" keymaps. (It's actually any keymap
that isn't named `default`.)
* remove QUANTUM_DIR code blocks from rules for community layouts
This commit removes the deprecated "QUANTUM_DIR" code block from
rules.mk files for community layouts.
* remove QUANTUM_DIR code blocks from rules for userspaces
This commit removes the deprecated "QUANTUM_DIR" code block from
rules.mk files for userspaces.
* Use standard KC_ALGR, remove language-specific redefinitions
* Use ALGR instead of ALTGR in BÉPO and Canadian multilingual keymaps
* Remove BE_LALT, BE_LGUI aliases
* adding default settings to support 3v ERM vibration motors
* set default settings of haptic motor for LV061228B-L64-A 2v LRA
* update ishtob keymap and fix config settings
* Bocaj Layout Revamp
* Pull in Upstream (#1)
* Various tweaks for some Input:Club build processes
* change KEYMAP to LAYOUT for all new keyboards made using this script
* Add support for rev3 of the Atom47 (#2672)
* Added support for rev3 of the Atom47
* Updated Atom47 readme's
* Fix redefine error on rev2 and add maartenwut's keymap
* Fix redefine error on LEdiodes keymap
* Add Nyquist keymap (#2692)
* nyquist
* danielhklein nyquist setup
* shift left controls
* remove readme
* cleanup before pr
* ready for pr
* Adds Phantom TKL support (#2696)
* Add an info.json to phantom keyboard
* Add layouts
- KEYMAP_WINKEYLESS
- KEYMAP_7BIT
- KEYMAP_ISO
- KEYMAP_ISO_WINKEYLESS
* Add key_counts
* Add 2 missing F-Row keys
* Add TKC1800 info.json
Created an info.json for the tkc1800.
* Clueboard 60 info.json
- adds
- LAYOUT_60_ansi
- LAYOUT_60_iso
- KEYMAP_AEK
- KEYMAP
- LAYOUT_60_ansi_split_bs_rshift
* Add the Speedo keyboard
* Fix KC60 info.json file (#2707)
* change KEYMAP to LAYOUT in all the KC60 files
* Redo the info.json file
* Small fixes to TKC1800
- adjust F-row to use 0.25 spacing
- split left shift
- add key_count
* Fix some Configurator Warnings regarding LAYOUT vs KEYMAP (#2708)
* change diverge 3 KC_KEYMAP to LAYOUT
* Change KEYMAP to LAYOUT for handwired arrow pad
* change M10A to LAYOUT for m10-a
* Change KC_KEYMAP to LAYOUT_kc and KEYMAP to LAYOUT for mf68
* change KC_KEYMAP to LAYOUT for nano
* Refactor to LAYOUT
* refactor to LAYOUT-ansi and LAYOUT_iso for s65
* LAYOUT conversions for lfkkeyboards
* missed a few renames
* mini1800 for lfkeyobards support of LAYOUT
* Improve state/chord handling and clean up namespace
Some values that can never, ever, change were held in local
variables, rather than in PROGMEM. Fixed.
Change "pressed" to a signed int so the test for < 0 makes
sense, and to avoid possible weird failure modes in the
case where a key release comes in when pressed is already
zero. (Shouldn't happen, sure, but computers are weird.)
A lot of things in process_steno had external linkage for no
particular reason. They've been marked static. Stuff still
builds.
Distinguish between currently-held keys and keys that have
been held, and expose these values through a nicely-named API
so other code could, say, check on the current set of steno
chording in order to make displays. Also in passing fix up the
"state" value having external linkage so it could clash with
other people's variable declarations.
The API also provides hooks for key processing and steno chord
events, so you can monitor those events without having to
run in matrix_scan_user and recheck the values directly. Also
document these.
There is no path through processing a key that doesn't
end with a return false, so the nested return foo() are
gone and we just return false.
* Pull information from config.h and rules.mk (#2711)
* Pull information from config.h and rules.mk
* Readd the kbd75 maintainer
* Remove obsolete info.json entries (#2712)
* Clean up some long-standing errors when populating the API (#2715)
* More Configurator Warning Fixes (#2716)
* mf68_ble did not have the correct .c and .h files
* Fix JC65 KEYMAP to LAYOUT
* Change KEYMAP to LAYOUT for s60_x
* Convert KEYMAP to LAYOUT for lets_split boards
* Convert KEYMAP to LAYOUT
* more fixes to keymap for iris
* convert KEYMAP to LAYOUT for levinson keyboard
* change losinggeneration's KEYMAP to LAYOUT
* convert KEYMAP to LAYOUT
* convert KEYMAP to LAYOUT for nyquist
* convert KEYMAP to LAYOUT
* convert KEYMAP to LAYOUT for viterbi
* convert KEYMAP to LAYOUT
* convert KEYMAP and its subsidiries to the LAYOUT standard
* convert KEYMAP and its subsidiries to the new LAYOUT standard
* Normacos keymap for let's split keyboard (#2691)
* Cheers let's split keymap
* fixed typo on norman layer of cheers keymap for let's split
* fixed right handed mappings for home row
* cheers keymap for let's split redefinition
* updated Cheers keymap for let's split
* cheers keymap for let's split updated with some terminal macros
* renamed cheers let's split keymap to a more appropriate normacos
* updated normacos keymap doc / removed non functional keys
* reset let's split rules to default values
* added more spotlight search macros
* normalized keymap comments
* Moved numpad on lower layer
* hhkb jp personal keymap (#2698)
* Add JJ40 Cockpit personal keymap (#2713)
* Add JJ40 Cockpit keymap
* Fix lower layer symbols
* Add readme for "major" keyboards to eliminate more QMK Configurator errors (#2718)
* add readme to ktype keyboard
* add readme to m10a
* add readme to mini1800
* add readme to parent directory
* Revert "Pull in Upstream (#1)"
This reverts commit eeba0cec17.
* Updates to Bocaj Files
- Gave up on Tap Dance for ' -> '
+ Added another 'Secret'
+ Add ' -> ' to the Swap Hands key
+ Add Swap Hands to the ' -> ' key
+ Made Hand Swapping a momentary toggle
- Removed Auto Shift
+ Added Layer Toggle to KC_QUOTE for the _TOOLS layer
- Disabled Tap Dance
* Merge remote-tracking branch 'upstream/master'
* Updates to Bocaj
Added Game Layers, Removed Unused Macros
* Removed 'secrets.h'
* Updates to Bocaj
Remove 'secrets'.
Remove 'sendstring_workman.h' and set related layer back to qwerty due to macro compatibility issues
* Total revisioning of keymap and layout structure
* Missed readme.md file
* Bocaj - Permissive Hold setting enabled
* Switching from ErgoDox EZ centric configuration to the layout/user approach
* Bocaj - Create Userspace and Ergodox layout
* Update settings.json
* Pushing local updates
* Reverting .vscode/settings.json
* Adds pretty_osx and _win wrappers
* Utilize Windows and Mac Wrappers
* Update layouts/community/ergodox/bocaj/keymap.c
* Updates to Bocaj keymap.c
- Extended pretty_osx and pretty_win wrappers to allow modification of the bottom rows and thumb clusters.
- Fixed already wrapped layouts to align with the change
- Wrapped _NUMS and _CLICKY layers with the _osx wrapper because I main with a Mac
* Updates to Bocaj
Small documentation updates, added KC_MAKE from Drashna's layout, added KC_LOCK back to the diablo layer.
* Add LShift to _Adjust layer
* Minor changes to bocaj
Put wrappers in userspace and added RESET keycode to the Adjust layer
* Updates to Bocaj config & keymap; Fixed problem with process_leader.c
- Made lots of changes to the bocaj layout and userspace
- Pulled in latest upstream/master
- Attempted to compile with latest and found an unneccessary `break` in process_leader.c
* Bocaj - Updates to Layout and Userspace
* Adjust LEADER_TIMEOUT to 350
* Put KC_GRAVE on _ADJUST layer
* Eliminate _LOWER layer and associated definitions
* Adjusted layer indicating LEDs to match changes
* Fixed Diablo leader sequence
* Added build info leader sequence
* Got rid of obsoleted IGNORE_MOD_TAP_INTERRUPT/PERMISSIVE_HOLD/PREVENT_STUCK_MODIFIERS (may add STRICT_LAYER_RELEASE in the future)
* Remove type_traits
Not sure what in my VSCode config always brings this one in
* refactor stage 1
* Bocaj Refactor Phase II
* Made LED_2 brighter if both CTRL & GUI are being held
* Enabled unicode because I got it to work in Mac OS
* Finalized Build Info leader combination after testing in Mac OS
* Not sure why KC_D3_1 was set to ASDF if !TAP_DANCE_ENABLE. So I changed that back
* Experienced issues with `EXTRAFLAGS += -flto` using Docker in MacOS. Not sure what it does, but I don't seem to be missing anything
* Wrote obligatory readme.md files and mentioned Drashna too many times... I don't think I can actually take credit for much of anything here.
* Updates to Bocaj
Made LED changes, added LM_DFLT which is similar to the grave macro, enabled retro tapping, working on a unicode idea -- currently fails to build.
* Bocaj Refactor Phase 3 Part 2
- Continuation of implementing unicode switching based on default layer
- Slight adjustments to _DIABLO and base wrapper because LM_DFLT macro didn't function as I'd hoped
* Slight adjustment to KC_MAKE
* Added my Mechmini2 layout to qmk.
* Added more info to the readme.
* Made changes.
* Update keyboards/mechmini/v2/keymaps/lbibass_625_space/keymap.c
Co-Authored-By: lbibass <ewdries02@gmail.com>
* Update keyboards/mechmini/v2/keymaps/lbibass_split_space/keymap.c
Co-Authored-By: lbibass <ewdries02@gmail.com>
* Added brightness and volume controls to MechMini 625 layout.
* Make CRKBD keylogger output actually show tap keys
* check MT/LT for twinkling
* Add ortho 5x12 support for fractal keyboard
* Use newer interface for setting pins/ports
* Remove custom unicode methods
* Reomve unicode input info
* Odd rules issue
* Redefine REST note to be more pleasing
* Properly disable PM LEDs with GPIO commands
* Update gitlab CI yaml file
* Remove extra mod tap check
* Remove initial state on ergodox glow
* Rev6 Cleanup
* Fix KC_MAKE macro
* Update GitLab CI yaml file
* More GitLab CI changes
* One final GitLab CI change
* Remove unneeded unicode support
* Optimize KC_MAKE
* Change rgblight_get_mode's return type to uint8_t.
Since rgblight_get_mode() is just returning rgblight_config_t.mode,
it should match rgblight_config_t.mode's type: uint8_t.
* Update rgb_matrix_get_mode to return uint8_t.
It seems the led_mask is set incorrectly on the WhiteFox meaning that
the LED at C9-1 (the space bar) doesn't get lit. I can't see any reason
for this to be intentional so I am pretty sure it's a typo. At the very
least it fixes the space bar LED for me.
* Add my zeal60 keymap
* Temporarily remove failing community layout from zeal60 make rules
* Revert "Temporarily remove failing community layout from zeal60 make rules"
This reverts commit ffd0018fb1.
* refactored cyclops keyboard project
Moved the files into a subfolder to allow consistency in preparation for additional commits to come in the future.
made some small adjustments to the configuration and keymap
* Update keyboards/westfoxtrot/cyclops/keymaps/default/keymap.c
Co-Authored-By: westfoxtrot <17062872+westfoxtrot@users.noreply.github.com>
* Update keyboards/westfoxtrot/cyclops/readme.md
Co-Authored-By: westfoxtrot <17062872+westfoxtrot@users.noreply.github.com>
* Update keyboards/westfoxtrot/cyclops/readme.md
Co-Authored-By: westfoxtrot <17062872+westfoxtrot@users.noreply.github.com>
* Update keyboards/westfoxtrot/cyclops/readme.md
Co-Authored-By: westfoxtrot <17062872+westfoxtrot@users.noreply.github.com>
* Keep pressed keys on layer state change
* Add doc comment for clear_keyboard_but_mods_and_keys
* Keep pressed keys only if PREVENT_STUCK_MODIFIERS is on
* Check STRICT_LAYER_RELEASE instead of PREVENT_STUCK_MODIFIERS
* Update feature_advanced_keycodes.md
Probably a better way to word it, but I've solved this issue on reddit several times, had to solve this for friends, ect. It's something worth being in the docs as it's a common issue, and not always intuitive. I have offered this change as I was told by several people "It was never mentioned in the docs".
* Update feature_advanced_keycodes.md
Clear up what was meant to be said.
* Change spaces to tabs on two lines
The rest of the file uses tabs
* Read user input in a non-terrible, non-hacky way
* Remove unnecessary tee call
* read -p is not POSIX
* Add missing $ to echo GENTOO_WARNING
* Replace non-POSIX echo -n with printf
* Use cd ... || exit 1 in case git clone fails
* Add missing sudo
Thanks @snortwolf
* Undo replacing tee with >>
* XMMX: matrix and keymap refactor
- xmmx.h updated to use #pragma once
- renamed LAYOUT_ansi_wk macro to LAYOUT_tkl_ansi
- renamed LAYOUT_ansi_wkl macro to LAYOUT_tkl_ansi_wkl
- renamed LAYOUT_iso_wk macro to LAYOUT_tkl_iso
- renamed LAYOUT_iso_wkl macro to LAYOUT_tkl_iso_wkl
* XMMX: Configurator support
* XMMX: readme update
* Add support for reset to bootloader
Chibios_test/STM32_F072_ONEKEY wouldn't reset to bootloader on a
compatible Discovery board because the Chibios library board file was
lacking the __early_init(void) function necessary to read the magic key.
Borrowed code from Clueboard 60, tested working.
* Remove board.chcfg
* Add provisional Helix implementation to test the quantum/split_common.
* copy keyboards/helix/serial.[ch] to quantum/split_common/
* Make serial.c a pure driver.
Remove buffer name and buffer size from serial.c. They should be placed in the caller(matrix.c, split_utils.c).
* remove quantum/split_common/serial_backward_compatibility.h
* Changed array serial_master_buffer to structure serial_m2s_buffer.
* Changed array serial_slave_buffer to structure serial_s2m_buffer.
* Change keyboards/miniaxe/matrix.c
I also made changes to quantum/split_comon/matrix.c to keyboards/miniaxe/matrix.c.
Note: I contacted @ka2hiro, creator of miniaxe, and I got permission to change keyboards/miniaxe/matrix.c.
* update history comment in quantum/split_common/serial.c
* Revert "Add provisional Helix implementation to test the quantum/split_common."
This reverts commit 168c82ef82.
* fix keyboards/miniaxe/matrix.c, quantum/split_common/matrix.c
avr-gcc 4.9.[23] report error.
avr-gcc 5.4.0, avr-gcc 7.3.0 pass.
It is funny.
* update comment quantum/split_common/serial.c
* Reserve RGBLIGHT_SPLIT macro in quantum/split_common
* initial commit for Othi's HHKB layout keymap,
covering multiple modifiers hold and vim-like support and german characters. If there's
any suggestion i can be reached via mnpqraven on github or Othi#6661 on
discord
* added readme.md. TODO: update readme.md
* changed to default quantum keycode for `KC_TRNS`,
removed `PREVENT_STUCK_MODIFIERS`,
fixed tap dance using one shots
TODO: unicode implementation at https://docs.qmk.fm/#/feature_unicode
* keymap documentaion(readme) added
* unicode init
TODO: figure out what made the compose sequence not running
* update unicode and readme
- [ ] Alteration (enhancement/optimization) of existing feature(s)
- [ ] New behavior
## Description
## Description
<!-- A few sentences describing what it is that you'd like to see. Additional information (such as links to spec sheets, licensing info, other related issues or PR's, etc) would be helpful. -->
<!-- A few sentences describing what it is that you'd like to see in QMK. Additional information (such as links to spec sheets, licensing info, other related issues or PRs, etc) would be helpful. -->
about: Anything else that doesn't fall into the above categories.
---
<!--- Provide a general summary of the changes you want in the Title above -->
<!--- Provide a general summary of the changes you want in the title above. -->
<!-- This text and anything on lines wrapped like this one will not show up in the final text. This text is to help us and you. -->
<!--- Anything on lines wrapped in comments like these will not show up in the final text. -->
<!-- Please check https://docs.qmk.fm/#/support for additional resources first. If that doesn't answer your question, check the bug report option, as that may be more appropriate. -->
<!-- Please check https://docs.qmk.fm/#/support for additional resources first. If that doesn't answer your question, choose the bug report template instead, as that may be more appropriate. -->
@@ -59,6 +59,8 @@ This is a C header file that is one of the first things included, and will persi
* define is matrix has ghost (unlikely)
*`#define DIODE_DIRECTION COL2ROW`
* COL2ROW or ROW2COL - how your matrix is configured. COL2ROW means the black mark on your diode is facing to the rows, and between the switch and the rows.
* 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)
@@ -109,9 +111,9 @@ If you define these options you will disable the associated feature, which can s
*`#define NO_ACTION_ONESHOT`
* disable one-shot modifiers
*`#define NO_ACTION_MACRO`
* disable all macro handling
* disable old style macro handling: MACRO() & action_get_macro
*`#define NO_ACTION_FUNCTION`
* disable the action function (deprecated)
* disable calling of action_function() from the fn_actions array (deprecated)
## Features That Can Be Enabled
@@ -126,6 +128,8 @@ If you define these options you will enable the associated feature, which may in
*`#define TAPPING_TERM 200`
* how long before a tap becomes a hold, if set above 500, a key tapped during the tapping term will turn it into a hold too
*`#define TAPPING_TERM_PER_KEY`
* enables handling for per key `TAPPING_TERM` settings
*`#define RETRO_TAPPING`
* tap anyway, even after TAPPING_TERM, if there was no other key interruption between press and release
* See [Retro Tapping](feature_advanced_keycodes.md#retro-tapping) for details
@@ -143,7 +147,7 @@ If you define these options you will enable the associated feature, which may in
* Breaks any Tap Toggle functionality (`TT` or the One Shot Tap Toggle)
*`#define LEADER_TIMEOUT 300`
* how long before the leader key times out
* If you're having issues finishing the sequence before it times out, you may need to increase the timeout setting. Or you may want to enable the `LEADER_PER_KEY_TIMING` option, which resets the timeout after each key is tapped.
* If you're having issues finishing the sequence before it times out, you may need to increase the timeout setting. Or you may want to enable the `LEADER_PER_KEY_TIMING` option, which resets the timeout after each key is tapped.
*`#define LEADER_PER_KEY_TIMING`
* sets the timer for leader key chords to run on each key press rather than overall
*`#define LEADER_KEY_STRICT_KEY_PROCESSING`
@@ -171,11 +175,17 @@ If you define these options you will enable the associated feature, which may in
## RGB Light Configuration
*`#define RGB_DI_PIN D7`
* pin the DI on the ws2812 is hooked-up to
* pin the DI on the WS2812 is hooked-up to
*`#define RGBLIGHT_ANIMATIONS`
* run RGB animations
*`#define RGBLED_NUM 15`
*`#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
* 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`
@@ -197,8 +207,34 @@ If you define these options you will enable the associated feature, which may in
Split Keyboard specific options, make sure you have 'SPLIT_KEYBOARD = yes' in your rules.mk
*`SPLIT_TRANSPORT = custom`
* Allows replacing the standard split communication routines with a custom one. ARM based split keyboards must use this at present.
### Setting Handedness
One thing to remember, the side that the USB port is plugged into is always the master half. The side not plugged into USB is the slave.
There are a few different ways to set handedness for split keyboards (listed in order of precedence):
1. Set `SPLIT_HAND_PIN`: Reads a pin to determine handedness. If pin is high, it's the left side, if low, the half is determined to be the right side
2. Set `EE_HANDS` and flash `eeprom-lefthand.eep`/`eeprom-righthand.eep` to each half
* For boards with DFU bootloader you can use `:dfu-split-left`/`:dfu-split-right` to flash these EEPROM files
* For boards with Caterina bootloader (like stock Pro Micros), use `:avrdude-split-left`/`:avrdude-split-right`
3. Set `MASTER_RIGHT`: Half that is plugged into the USB port is determined to be the master and right half (inverse of the default)
4. Default: The side that is plugged into the USB port is the master half and is assumed to be the left half. The slave side is the right half
#### Defines for handedness
*`#define SPLIT_HAND_PIN B7`
* For using high/low pin to determine handedness, low = right hand, high = left hand. Replace 'B7' with the pin you are using. This is optional and you can still use the EEHANDS method or MASTER_LEFT / MASTER_RIGHT defines like the stock Let's Split uses.
* For using high/low pin to determine handedness, low = right hand, high = left hand. Replace `B7` with the pin you are using. This is optional, and if you leave `SPLIT_HAND_PIN` undefined, then you can still use the EE_HANDS method or MASTER_LEFT / MASTER_RIGHT defines like the stock Let's Split uses.
*`#define EE_HANDS` (only works if `SPLIT_HAND_PIN` is not defined)
* Reads the handedness value stored in the EEPROM after `eeprom-lefthand.eep`/`eeprom-righthand.eep` has been flashed to their respective halves.
*`#define MASTER_RIGHT`
* Master half is defined to be the right half.
### Other Options
*`#define USE_I2C`
* For using I2C instead of Serial (defaults to serial)
@@ -206,6 +242,23 @@ Split Keyboard specific options, make sure you have 'SPLIT_KEYBOARD = yes' in yo
*`#define SOFT_SERIAL_PIN D0`
* When using serial, define this. `D0` or `D1`,`D2`,`D3`,`E6`.
*`#define MATRIX_ROW_PINS_RIGHT { <row pins> }`
*`#define MATRIX_COL_PINS_RIGHT { <col pins> }`
* If you want to specify a different pinout for the right half than the left half, you can define `MATRIX_ROW_PINS_RIGHT`/`MATRIX_COL_PINS_RIGHT`. Currently, the size of `MATRIX_ROW_PINS` must be the same as `MATRIX_ROW_PINS_RIGHT` and likewise for the definition of columns.
*`#define RGBLED_SPLIT { 6, 6 }`
* See [RGB Light Configuration](#rgb-light-configuration)
*`#define SELECT_SOFT_SERIAL_SPEED <speed>` (default speed is 1)
* Sets the protocol speed when using serial communication
* Speeds:
* 0: about 189kbps (Experimental only)
* 1: about 137kbps (default)
* 2: about 75kbps
* 3: about 39kbps
* 4: about 26kbps
* 5: about 20kbps
# The `rules.mk` File
This is a [make](https://www.gnu.org/software/make/manual/make.html) file that is included by the top-level `Makefile`. It is used to set some information about the MCU that we will be compiling for as well as enabling and disabling certain features.
@@ -269,6 +322,10 @@ Use these to enable or disable building certain features. The more you have enab
* Current options are AdafruitEzKey, AdafruitBLE, RN42
*`SPLIT_KEYBOARD`
* Enables split keyboard support (dual MCU like the let's split and bakingpy's boards) and includes all necessary files located at quantum/split_common
*`CUSTOM_MATRIX`
* Allows replacing the standard matrix scanning routine with a custom one.
*`DEBOUNCE_TYPE`
* Allows replacing the standard key debouncing routine with an alternative or custom one.
*`WAIT_FOR_USB`
* Forces the keyboard to wait for a USB connection to be established before it starts up
@@ -56,7 +56,7 @@ Never made an open source contribution before? Wondering how contributions work
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 two spaces (soft tabs)
* 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
@@ -71,6 +71,14 @@ Most of our style is pretty easy to pick up on, but right now it's not entirely
* 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:
@@ -91,6 +99,18 @@ int foo(void) {
}
```
# 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`.
# General Guidelines
We have a few different types of changes in QMK, each requiring a different level of rigor. We'd like you to keep the following guidelines in mind no matter what type of change you're making.
@@ -117,6 +137,20 @@ Documentation is one of the easiest ways to get started contributing to QMK. Fin
You'll find all our documentation in the `qmk_firmware/docs` directory, or if you'd rather use a web based workflow you can click "Suggest An Edit" at the top of each page on http://docs.qmk.fm/.
When providing code examples in your documentation, try to observe naming conventions used elsewhere in the docs. For example, standardizing enums as `my_layers` or `my_keycodes` for consistency:
```c
enummy_layers{
_FIRST_LAYER,
_SECOND_LAYER
};
enummy_keycodes{
FIRST_LAYER=SAFE_RANGE,
SECOND_LAYER
};
```
## Keymaps
Most first-time QMK contributors start with their personal keymaps. We try to keep keymap standards pretty casual (keymaps, after all, reflect the personality of their creators) but we do ask that you follow these guidelines to make it easier for others to discover and learn from your keymap.
@@ -125,7 +159,7 @@ Most first-time QMK contributors start with their personal keymaps. We try to ke
* All Keymap PR's are squashed, so if you care about how your commits are squashed you should do it yourself
* Do not lump features in with keymap PR's. Submit the feature first and then a second PR for the keymap.
* Do not include `Makefile`s in your keymap folder (they're no longer used)
* Update copyrights in file headers (look for `REPLACE_WITH_YOUR_NAME`)
* Update copyrights in file headers (look for `%YOUR_NAME%`)
## Keyboards
@@ -138,7 +172,7 @@ We also ask that you follow these guidelines:
* Do not lump core features in with new keyboards. Submit the feature first and then submit a separate PR for the keyboard.
* Name `.c`/`.h` file after the immediate parent folder, eg `/keyboards/<kb1>/<kb2>/<kb2>.[ch]`
* Do not include `Makefile`s in your keyboard folder (they're no longer used)
* Update copyrights in file headers (look for `REPLACE_WITH_YOUR_NAME`)
* Update copyrights in file headers (look for `%YOUR_NAME%`)
Call this function to get the last received LED state. This is useful for reading the LED state outside `led_set_*`, e.g. in [`matrix_scan_user()`](#matrix-scanning-code).
For convenience, you can use the `IS_HOST_LED_ON(led_name)` and `IS_HOST_LED_OFF(led_name)` macros instead of calling and checking `host_keyboard_leds()` directly.
Before a keyboard can be used the hardware must be initialized. QMK handles initialization of the keyboard matrix itself, but if you have other hardware like LED's or i²c controllers you will need to set up that hardware before it can be used.
## Setting Physical LED State
Some keyboard implementations provide convenience methods for setting the state of the physical LEDs.
### Example `matrix_init_user()` Implementation
### Ergodox Boards
This example, at the keyboard level, sets up B1, B2, and B3 as LED pins.
The Ergodox implementations provide `ergodox_right_led_1`/`2`/`3_on`/`off()` to turn individual LEDs on or off, as well as `ergodox_right_led_on`/`off(uint8_t led)` to turn them on or off by their index.
In addition, it is possible to specify the brightness level of all LEDs with `ergodox_led_all_set(uint8_t n)`; of individual LEDs with `ergodox_right_led_1`/`2`/`3_set(uint8_t n)`; or by index with `ergodox_right_led_set(uint8_t led, uint8_t n)`.
Ergodox boards also define `LED_BRIGHTNESS_LO` for the lowest brightness and `LED_BRIGHTNESS_HI` for the highest brightness (which is the default).
# Keyboard Initialization Code
There are several steps in the keyboard initialization process. Depending on what you want to do, it will influence which function you should use.
These are the three main initialization functions, listed in the order that they're called.
*`keyboard_pre_init_*` - Happens before most anything is started. Good for hardware setup that you want running very early.
*`matrix_init_*` - Happens midway through the firmware's startup process. Hardware is initialized, but features may not be yet.
*`keyboard_post_init_*` - Happens at the end of the firmware's startup process. This is where you'd want to put "customization" code, for the most part.
!> For most people, the `keyboard_post_init_user` function is what you want to call. For instance, this is where you want to set up things for RGB Underglow.
## Keyboard Pre Initialization code
This runs very early during startup, even before the USB has been started.
Shortly after this, the matrix is initialized.
For most users, this shouldn't be used, as it's primarily for hardware oriented initialization.
However, if you have hardware stuff that you need initialized, this is the best place for it (such as initializing LED pins).
### Example `keyboard_pre_init_user()` Implementation
This example, at the keyboard level, sets up B0, B1, B2, B3, and B4 as LED pins.
This is called when the matrix is initialized, and after some of the hardware has been set up, but before many of the features have been initialized.
This is useful for setting up stuff that you may need elsewhere, but isn't hardware related nor is dependant on where it's started.
### `matrix_init_*` Function Documentation
* Keyboard/Revision: `void matrix_init_kb(void)`
* Keymap: `void matrix_init_user(void)`
## Keyboard Post Initialization code
This is ran as the very last task in the keyboard initialization process. This is useful if you want to make changes to certain features, as they should be initialized by this point.
### Example `keyboard_post_init_user()` Implementation
This example, running after everything else has initialized, sets up the rgb underglow configuration.
```c
voidkeyboard_post_init_user(void){
// Call the post init code.
rgblight_enable_noeeprom();// enables Rgb, without saving settings
rgblight_sethsv_noeeprom(180,255,255);// sets the color to teal/cyan without saving
rgblight_mode_noeeprom(RGBLIGHT_MODE_BREATHING+3);// sets mode to Fast breathing without saving
Whenever possible you should customize your keyboard by using `process_record_*()` and hooking into events that way, to ensure that your code does not have a negative performance impact on your keyboard. However, in rare cases it is necessary to hook into the matrix scanning. Be extremely careful with the performance of code in these functions, as it will be called at least 10 times per second.
@@ -176,7 +260,7 @@ This example has been deliberately omitted. You should understand enough about Q
This function gets called at every matrix scan, which is basically as often as the MCU can handle. Be careful what you put here, as it will get run a lot.
You should use this function if you need custom matrix scanning code. It can also be used for custom status output (such as LED's or a display) or other functionality that you want to trigger regularly even when the user isn't typing.
You should use this function if you need custom matrix scanning code. It can also be used for custom status output (such as LEDs or a display) or other functionality that you want to trigger regularly even when the user isn't typing.
# Keyboard Idling/Wake Code
@@ -188,22 +272,18 @@ This is controlled by two functions: `suspend_power_down_*` and `suspend_wakeup_
### Example suspend_power_down_user() and suspend_wakeup_init_user() Implementation
This example, at the keyboard level, sets up B1, B2, and B3 as LED pins.
```c
voidsuspend_power_down_user(void)
{
voidsuspend_power_down_user(void){
rgb_matrix_set_suspend_state(true);
}
voidsuspend_wakeup_init_user(void)
{
voidsuspend_wakeup_init_user(void){
rgb_matrix_set_suspend_state(false);
}
```
### `keyboard_init_*` Function Documentation
### Keyboard suspend/wake Function Documentation
* Keyboard/Revision: `void suspend_power_down_kb(void)` and `void suspend_wakeup_init_user(void)`
* Keymap: `void suspend_power_down_kb(void)` and `void suspend_wakeup_init_user(void)`
The `state` is the bitmask of the active layers, as explained in the [Keymap Overview](keymap.md#keymap-layer-status)
@@ -256,13 +337,13 @@ Keep in mind that EEPROM has a limited number of writes. While this is very high
* If you don't understand the example, then you may want to avoid using this feature, as it is rather complicated.
### Example Implementation
### Example Implementation
This is an example of how to add settings, and read and write it. We're using the user keymap for the example here. This is a complex function, and has a lot going on. In fact, it uses a lot of the above functions to work!
In your keymap.c file, add this to the top:
```
```c
typedefunion{
uint32_traw;
struct{
@@ -275,11 +356,11 @@ user_config_t user_config;
This sets up a 32 bit structure that we can store settings with in memory, and write to the EEPROM. Using this removes the need to define variables, since they're defined in this structure. Remember that `bool` (boolean) values use 1 bit, `uint8_t` uses 8 bits, `uint16_t` uses up 16 bits. You can mix and match, but changing the order can cause issues, as it will change the values that are read and written.
We're using `rgb_layer_change`, for the `layer_state_set_*` function, and use `matrix_init_user` and `process_record_user` to configure everything.
We're using `rgb_layer_change`, for the `layer_state_set_*` function, and use `keyboard_post_init_user` and `process_record_user` to configure everything.
Now, using the `matrix_init_user` code above, you want to add `eeconfig_read_user()` to it, to populate the structure you've just created. And you can then immediately use this structure to control functionality in your keymap. And It should look like:
```
void matrix_init_user(void) {
Now, using the `keyboard_post_init_user` code above, you want to add `eeconfig_read_user()` to it, to populate the structure you've just created. And you can then immediately use this structure to control functionality in your keymap. And It should look like:
```c
void keyboard_post_init_user(void){
// Call the keymap level matrix init.
// Read the user config from EEPROM
@@ -295,7 +376,7 @@ void matrix_init_user(void) {
```
The above function will use the EEPROM config immediately after reading it, to set the default layer's RGB color. The "raw" value of it is converted in a usable structure based on the "union" that you created above.
This will cause the RGB underglow to be changed ONLY if the value was enabled. Now to configure this value, create a new keycode for `process_record_user` called `RGB_LYR` and `EPRM`. Additionally, we want to make sure that if you use the normal RGB codes, that it turns off Using the example above, make it look this:
```
This will cause the RGB underglow to be changed ONLY if the value was enabled. Now to configure this value, create a new keycode for `process_record_user` called `RGB_LYR`. Additionally, we want to make sure that if you use the normal RGB codes, that it turns off Using the example above, make it look this:
And lastly, you want to add the `eeconfig_init_user` function, so that when the EEPROM is reset, you can specify default values, and even custom actions. For example, if you want to set rgb layer indication by default, and save the default valued.
And lastly, you want to add the `eeconfig_init_user` function, so that when the EEPROM is reset, you can specify default values, and even custom actions. To force an EEPROM reset, use the `EEP_RST` keycode or [Bootmagic](feature_bootmagic.md) functionallity. For example, if you want to set rgb layer indication by default, and save the default valued.
```
```c
voideeconfig_init_user(void){// EEPROM is getting reset!
user_config.raw=0;
user_config.rgb_layer_change=true;// We want this enabled by default
eeconfig_update_user(user_config.raw);// Write default value to EEPROM now
@@ -384,3 +461,31 @@ And you're done. The RGB layer indication will only work if you want it to. And
* Keymap: `void eeconfig_init_user(void)`, `uint32_t eeconfig_read_user(void)` and `void eeconfig_update_user(uint32_t val)`
The `val` is the value of the data that you want to write to EEPROM. And the `eeconfig_read_*` function return a 32 bit (DWORD) value from the EEPROM.
# Custom Tapping Term
By default, the tapping term is defined globally, and is not configurable by key. For most users, this is perfectly fine. But in come cases, dual function keys would be greatly improved by different timeouts than `LT` keys, or because some keys may be easier to hold than others. Instead of using custom key codes for each, this allows for per key configurable `TAPPING_TERM`.
To enable this functionality, you need to add `#define TAPPING_TERM_PER_KEY` to your `config.h`, first.
## Example `get_tapping_term` Implementation
To change the `TAPPING TERM` based on the keycode, you'd want to add something like the following to your `keymap.c` file:
```c
uint16_tget_tapping_term(uint16_tkeycode){
switch(keycode){
caseSFT_T(KC_SPC):
returnTAPPING_TERM+1250;
caseLT(1,KC_GRV):
return130;
default:
returnTAPPING_TERM;
}
}
```
### `get_tapping_term` Function Documentation
Unlike many of the other functions here, there isn't a need (or even reason) to have a quantum or keyboard level function. Only a user level function is useful here, so no need to mark it as such.
### 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.
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.
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.
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.
?> 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.
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 `WinUS(libusb-1.0)` option, and hit "Reinstall driver". Once you've done that, try flashing your board, again.
## WINAVR is Obsolete
It is no longer recommended and may cause some problem.
### 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)
Due to how EEPROM works on ARM based chips, saved settings may no longer be valid. This affects the default layers, and *may*, under certain circumstances we are still figuring out, make the keyboard unusable. Resetting the EEPROM will correct this.
[Planck rev6 reset EEPROM](https://cdn.discordapp.com/attachments/473506116718952450/539284620861243409/planck_rev6_default.bin) can be used to force an eeprom reset. After flashing this image, flash your normal firmware again which should restore your keyboard to _normal_ working order.
If bootmagic is enabled in any form, you should be able to do this too (see [Bootmagic docs](feature_bootmagic.md) and keyboard info for specifics on how to do this).
@@ -11,21 +11,21 @@ People often define custom names using `#define`. For example:
#define ALT_TAB LALT(KC_TAB)
```
This will allow you to use `FN_CAPS` and `ALT_TAB` in your `KEYMAP()`, keeping it more readable.
This will allow you to use `FN_CAPS` and `ALT_TAB` in your keymap, keeping it more readable.
## Caveats
Currently, `LT()` and `MT()` are limited to the [Basic Keycode set](keycodes_basic.md), meaning you can't use keycodes like `LCTL()`, `KC_TILD`, or anything greater than `0xFF`. Modifiers specified as part of a Layer Tap or Mod Tap's keycode will be ignored.
Currently, `LT()` and `MT()` are limited to the [Basic Keycode set](keycodes_basic.md), meaning you can't use keycodes like `LCTL()`, `KC_TILD`, or anything greater than `0xFF`. Modifiers specified as part of a Layer Tap or Mod Tap's keycode will be ignored. If you need to apply modifiers to your tapped keycode, [Tap Dance](https://github.com/qmk/qmk_firmware/blob/master/docs/feature_tap_dance.md#example-5-using-tap-dance-for-advanced-mod-tap-and-layer-tap-keys) can be used to accomplish this.
Additionally, if at least one right-handed modifier is specified in a Mod Tap or Layer Tap, it will cause all modifiers specified to become right-handed, so it is not possible to mix and match the two.
# Switching and Toggling Layers
These functions allow you to activate layers in various ways. Note that layers are not generally independent layouts -- multiple layers can be activated at once, and it's typical for layers to use `KC_TRNS` to allow keypresses to pass through to lower layers. For a detailed explanation of layers, see [Keymap Overview](keymap.md#keymap-and-layers)
These functions allow you to activate layers in various ways. Note that layers are not generally independent layouts -- multiple layers can be activated at once, and it's typical for layers to use `KC_TRNS` to allow keypresses to pass through to lower layers. For a detailed explanation of layers, see [Keymap Overview](keymap.md#keymap-and-layers). When using momentary layer switching with MO(), LM(), TT(), or LT(), make sure to leave the key on the above layers transparent or it may not work as intended.
*`DF(layer)` - switches the default layer. The default layer is the always-active base layer that other layers stack on top of. See below for more about the default layer. This might be used to switch from QWERTY to Dvorak layout. (Note that this is a temporary switch that only persists until the keyboard loses power. To modify the default layer in a persistent way requires deeper customization, such as calling the `set_single_persistent_default_layer` function inside of [process_record_user](custom_quantum_functions.md#programming-the-behavior-of-any-keycode).)
*`MO(layer)` - momentarily activates *layer*. As soon as you let go of the key, the layer is deactivated.
*`LM(layer, mod)` - Momentarily activates *layer* (like `MO`), but with modifier(s) *mod* active. Only supports layers 0-15 and the left modifiers.
*`LM(layer, mod)` - Momentarily activates *layer* (like `MO`), but with modifier(s) *mod* active. Only supports layers 0-15 and the left modifiers: `MOD_LCTL`, `MOD_LSFT`, `MOD_LALT`, `MOD_LGUI` (note the use of `MOD_` constants instead of `KC_`). These modifiers can be combined using bitwise OR, e.g. `LM(_RAISE, MOD_LCTL | MOD_LALT)`.
*`LT(layer, kc)` - momentarily activates *layer* when held, and sends *kc* when tapped. Only supports layers 0-15.
*`OSL(layer)` - momentarily activates *layer* until the next key is pressed. See [One Shot Keys](#one-shot-keys) for details and additional functionality.
*`TG(layer)` - toggles *layer*, activating it if it's inactive and vice versa
@@ -60,21 +60,21 @@ Sometimes, you might want to switch between layers in a macro or as part of a ta
These allow you to combine a modifier with a keycode. When pressed, the keydown event for the modifier, then `kc` will be sent. On release, the keyup event for `kc`, then the modifier will be sent.
|`LCTL_T(kc)`|`CTL_T(kc)` |Left Control when held, `kc` when tapped |
|`RCTL_T(kc)`| |Right Control when held, `kc` when tapped |
|`LSFT_T(kc)`|`SFT_T(kc)` |Left Shift when held, `kc` when tapped |
|`RSFT_T(kc)`| |Right Shift when held, `kc` when tapped |
|`LALT_T(kc)`|`ALT_T(kc)`|Left Alt when held, `kc` when tapped |
|`RALT_T(kc)`|`ALGR_T(kc)` |Right Alt when held, `kc` when tapped |
|`LGUI_T(kc)`|`LCMD_T(kc)`, `RWIN_T(kc)`, `GUI_T(kc)`|Left GUI when held, `kc` when tapped |
|`RGUI_T(kc)`|`RCMD_T(kc)`, `RWIN_T(kc)` |Right 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|
|`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 |
|`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/)|
|`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 |
|`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/)|
## Caveats
@@ -146,7 +146,7 @@ Additionally, hitting keys five times in a short period will lock that key. This
You can control the behavior of one shot keys by defining these in `config.h`:
```c
#define ONESHOT_TAP_TOGGLE 5 /* Tapping this number of times holds the key until tapped this number of times again. */
#define ONESHOT_TAP_TOGGLE 5 /* Tapping this number of times holds the key until tapped once again. */
#define ONESHOT_TIMEOUT 5000 /* Time (in ms) before the one shot key is released */
```
@@ -161,6 +161,81 @@ For one shot mods, you need to call `set_oneshot_mods(MOD)` to set it, or `clear
!> If you're having issues with OSM translating over Remote Desktop Connection, this can be fixed by opening the settings, going to the "Local Resources" tap, and in the keyboard section, change the drop down to "On this Computer". This will fix the issue and allow OSM to function properly over Remote Desktop.
## Callbacks
When you'd like to perform custom logic when pressing a one shot key, there are several callbacks you can choose to implement. You could indicate changes in one shot keys by flashing an LED or making a sound, for example.
There is a callback for `OSM(mod)`. It is called whenever the state of any one shot modifier key is changed: when it toggles on, but also when it is toggled off. You can use it like this:
```c
voidoneshot_mods_changed_user(uint8_tmods){
if(mods&MOD_MASK_SHIFT){
println("Oneshot mods SHIFT");
}
if(mods&MOD_MASK_CTRL){
println("Oneshot mods CTRL");
}
if(mods&MOD_MASK_ALT){
println("Oneshot mods ALT");
}
if(mods&MOD_MASK_GUI){
println("Oneshot mods GUI");
}
if(!mods){
println("Oneshot mods off");
}
}
```
The `mods` argument contains the active mods after the change, so it reflects the current state.
When you use One Shot Tap Toggle (by adding `#define ONESHOT_TAP_TOGGLE 2` in your `config.h` file), you may lock a modifier key by pressing it the specified amount of times. There's a callback for that, too:
Last, there is also a callback for the `OSL(layer)` one shot key:
```c
voidoneshot_layer_changed_user(uint8_tlayer){
if(layer==1){
println("Oneshot layer 1 on");
}
if(!layer){
println("Oneshot layer off");
}
}
```
If any one shot layer is switched off, `layer` will be zero. When you're looking to do something on any layer change instead of one shot layer changes, `layer_state_set_user` is a better callback to use.
If you are making your own keyboard, there are also `_kb` equivalent functions:
```c
voidoneshot_locked_mods_changed_kb(uint8_tmods);
voidoneshot_mods_changed_kb(uint8_tmods);
voidoneshot_layer_changed_kb(uint8_tlayer);
```
As with any callback, be sure to call the `_user` variant to allow for further customizability.
# Tap-Hold Configuration Options
While Tap-Hold options are fantastic, they are not without their issues. We have tried to configure them with reasonal defaults, but that may still cause issues for some people.
@@ -100,6 +100,16 @@ In music mode, the following keycodes work differently, and don't pass through:
*`KC_UP` - speed-up playback
*`KC_DOWN` - slow-down playback
The pitch standard (`PITCH_STANDARD_A`) is 440.0f by default - to change this, add something like this to your `config.h`:
#define PITCH_STANDARD_A 432.0f
You can completely disable Music Mode as well. This is useful, if you're pressed for space on your controller. To disable it, add this to your `config.h`:
#define NO_MUSIC_MODE
### Music Mask
By default, `MUSIC_MASK` is set to `keycode < 0xFF` which means keycodes less than `0xFF` are turned into notes, and don't output anything. You can change this by defining this in your `config.h` like this:
#define MUSIC_MASK keycode != KC_NO
@@ -120,13 +130,26 @@ For a more advanced way to control which keycodes should still be processed, you
Things that return false are not part of the mask, and are always processed.
The pitch standard (`PITCH_STANDARD_A`) is 440.0f by default - to change this, add something like this to your `config.h`:
### Music Map
#define PITCH_STANDARD_A 432.0f
By default, the Music Mode uses the columns and row to determine the scale for the keys. For a board that uses a rectangular matrix that matches the keyboard layout, this is just fine. However, for boards that use a more complicated matrix (such as the Planck Rev6, or many split keyboards) this would result in a very skewed experience.
You can completely disable Music Mode as well. This is useful, if you're pressed for space on your controller. To disable it, add this to your `config.h`:
However, the Music Map option allows you to remap the scaling for the music mode, so it fits the layout, and is more natural.
#define NO_MUSIC_MODE
To enable this feature, add `#defineMUSIC_MAP` to your `config.h` file, and then you will want to add a `uint8_t music_map` to your keyboard's `c` file, or your `keymap.c`.
You will want to use whichever `LAYOUT` macro that your keyboard uses here. This maps it to the correct key location. Start in the bottom left of the keyboard layout, and move to the right, and then upwards. Fill in all the entries until you have a complete matrix.
You can look at the [Planck Keyboard](https://github.com/qmk/qmk_firmware/blob/e9ace1487887c1f8b4a7e8e6d87c322988bec9ce/keyboards/planck/planck.c#L24-L29) as an example of how to implement this.
@@ -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 only supported on certain pins of the MCU, so if the backlighting is not connected to one of them, a software PWM implementation triggered by hardware timer interrupts will be used.
Hardware PWM is supported according to the following table:
| Backlight Pin | Hardware timer |
|---------------|----------------|
|`B5` | Timer 1 |
|`B6` | Timer 1 |
|`B7` | Timer 1 |
|`C6` | Timer 3 |
| other | Software PWM |
The [audio feature](feature_audio.md) also uses hardware timers. Please refer to the following table to know what hardware timer the software PWM will use depending on the audio configuration:
When all timers are in use for [audio](feature_audio.md), the backlight software PWM will not use a hardware timer, but instead will be triggered during the matrix scan. In this case the backlight doesn't support breathing and might show lighting artifacts (for instance flickering), because the PWM computation might not be called with enough timing precision.
## Configuration
@@ -39,10 +63,26 @@ 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_PINS` |*Not defined*|experimental: see below for more information|
|`BACKLIGHT_LEVELS` |`3` |The number of brightness levels (maximum 15 excluding off) |
|`BACKLIGHT_BREATHING`|*Not defined*|Enable backlight breathing, if hardware PWM is used |
|`BACKLIGHT_CAPS_LOCK`|*Not defined*|Enable Caps Lock indicator using backlight (for keyboards without dedicated LED) |
|`BACKLIGHT_BREATHING`|*Not defined*|Enable backlight breathing, if supported |
|`BREATHING_PERIOD` |`6` |The length of one backlight "breath" in seconds |
## 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
When using the supported pins for backlighting, QMK will use a hardware timer configured to output a PWM signal. This timer will count up to `ICRx` (by default `0xFFFF`) before resetting to 0.
@@ -52,6 +92,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.
@@ -16,35 +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.
| Not defined | Use the default algorithm, currently sym_g | Nothing |
| custom | Use your own debounce.c | ```SRC += debounce.c``` add your own debounce.c and implement necessary functions |
| anything_else | Use another algorithm from quantum/debounce/* | Nothing |
**Regarding split keyboards**:
The debounce code is compatible with split keyboards.
# Use your own debouncing code
* Set ```DEBOUNCE_TYPE = custom ```.
* Add ```SRC += debounce.c```
* Add your own ```debounce.c```. Look at current implementations in ```quantum/debounce``` for examples.
* Debouncing occurs after every raw matrix scan.
* Use num_rows rather than MATRIX_ROWS, so that split keyboards are supported correctly.
# Changing between included debouncing methods
You can either use your own code, by including your own debounce.c, or switch to another included one.
Included debounce methods are:
* eager_pr - debouncing per row. On any state change, response is immediate, followed by locking the row ```DEBOUNCE_DELAY``` milliseconds of no further input for that row.
For use in keyboards where refreshing ```NUM_KEYS``` 8-bit counters is computationally expensive / low scan rate, and fingers usually only hit one row at a time. This could be
appropriate for the ErgoDox models; the matrix is rotated 90°, and hence its "rows" are really columns, and each finger only hits a single "row" at a time in normal use.
* eager_pk - debouncing per key. On any state change, response is immediate, followed by ```DEBOUNCE_DELAY``` milliseconds of no further input for that key
* sym_g - debouncing per keyboard. On any state change, a global timer is set. When ```DEBOUNCE_DELAY``` milliseconds of no changes has occured, all input changes are pushed.
@@ -4,7 +4,11 @@ If you're using a 60% keyboard, or any other layout with no F-row, you will have
## Usage
Replace the `KC_GRAVE` key in your keymap (usually to the left of the `1` key) with `KC_GESC`. When pressed it will behave like `KC_ESC`, but with Shift or GUI held it will send`KC_GRAVE`.
Replace the `KC_GRAVE` key in your keymap (usually to the left of the `1` key) with `KC_GESC`. Most of the time this key will output `KC_ESC` when pressed. However, when Shift or GUI are held down it will output`KC_GRV` instead.
## What Your OS Sees
If Mary presses GESC on her keyboard, the OS will see an KC_ESC character. Now if Mary holds Shift down and presses GESC it will output `~`, or a shifted backtick. Now if she holds GUI/CMD/WIN, it will output a simple <code>`</code> character.
## Keycodes
@@ -12,6 +16,10 @@ Replace the `KC_GRAVE` key in your keymap (usually to the left of the `1` key) w
|`KC_GESC`|`GRAVE_ESC`|Escape when pressed, <code>`</code> when Shift or GUI are held|
### Caveats
On macOS, Command+<code>`</code> is by default mapped to "Move focus to next window" so it will not output a backtick. Additionally, Terminal always recognises this shortcut to cycle between windows, even if the shortcut is changed in the Keyboard preferences.
## Configuration
There are several possible key combinations this will break, among them Control+Shift+Escape on Windows and Command+Option+Escape on macOS. To work around this, you can `#define` these options in your `config.h`:
|`HPT_RST` | Reset haptic feedback config to default |
|`HPT_FBK` | Toggle feedback to occur on keypress, release or both |
|`HPT_BUZ` | Toggle solenoid buzz on/off |
|`HPT_MODI` | Go to next DRV2605L waveform |
|`HPT_MODD` | Go to previous DRV2605L waveform |
|`HPT_DWLI` | Increase Solenoid dwell time |
|`HPT_DWLD` | Decrease Solenoid dwell time |
### Solenoids
First you will need a build a circuit to drive the solenoid through a mosfet as most MCU will not be able to provide the current needed to drive the coil in the solenoid.
[Wiring diagram provided by Adafruit](https://playground.arduino.cc/uploads/Learning/solenoid_driver.pdf)
Select a pin that has PWM for the signal pin
```
#define SOLENOID_PIN *pin*
```
Beware that some pins may be powered during bootloader (ie. A13 on the STM32F303 chip) and will result in the solenoid kept in the on state through the whole flashing process. This may overheat and damage the solenoid. If you find that the pin the solenoid is connected to is triggering the solenoid during bootloader/DFU, select another pin.
### DRV2605L
DRV2605L is controlled over i2c protocol, and has to be connected to the SDA and SCL pins, these varies depending on the MCU in use.
#### Feedback motor setup
This driver supports 2 different feedback motors. Set the following in your `config.h` based on which motor you have selected.
##### ERM
Eccentric Rotating Mass vibration motors (ERM) is motor with a off-set weight attached so when drive signal is attached, the off-set weight spins and causes a sinusoidal wave that translate into vibrations.
#define FB_LOOPGAIN 1 /* For Low:0, Medium:1, High:2, Very High:3 */
/* Please refer to your datasheet for the optimal setting for your specific motor. */
#define RATED_VOLTAGE 3
#define V_PEAK 5
```
##### LRA
Linear resonant actuators (LRA, also know as a linear vibrator) works different from a ERM. A LRA has a weight and magnet suspended by springs and a voice coil. When the drive signal is applied, the weight would be vibrate on a single axis (side to side or up and down). Since the weight is attached to a spring, there is a resonance effect at a specific frequency. This frequency is where the LRA will operate the most efficiently. Refer to the motor's datasheet for the recommanded range for this frequency.
#define FB_LOOPGAIN 1 /* For Low:0, Medium:1, High:2, Very High:3 */
/* Please refer to your datasheet for the optimal setting for your specific motor. */
#define RATED_VOLTAGE 2
#define V_PEAK 2.8
#define V_RMS 2.0
#define V_PEAK 2.1
#define F_LRA 205 /* resonance freq */
```
#### DRV2605L waveform library
DRV2605L comes with preloaded library of various waveform sequences that can be called and played. If writing a macro, these waveforms can be played using `DRV_pulse(*sequence name or number*)`
List of waveform sequences from the datasheet:
|seq# | Sequence name |seq# | Sequence name |seq# |Sequence name |
This feature allows you to use LED matrices driven by external drivers. It hooks into the backlight system so you can use the same keycodes as backlighting to control it.
If you want to use RGB LED's you should use the [RGB Matrix Subsystem](feature_rgb_matrix.md) instead.
## Driver configuration
### IS31FL3731
There is basic support for addressable LED matrix lighting with the I2C IS31FL3731 RGB controller. To enable it, add this to your `rules.mk`:
LED_MATRIX_ENABLE = IS31FL3731
You can use between 1 and 4 IS31FL3731 IC's. Do not specify `LED_DRIVER_ADDR_<N>` defines for IC's that are not present on your keyboard. You can define the following items in `config.h`:
| Variable | Description | Default |
|----------|-------------|---------|
| `ISSI_TIMEOUT` | (Optional) How long to wait for i2c messages | 100 |
| `ISSI_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 |
| `LED_DRIVER_COUNT` | (Required) How many LED driver IC's are present | |
| `LED_DRIVER_LED_COUNT` | (Required) How many LED lights are present across all drivers | |
| `LED_DRIVER_ADDR_1` | (Required) Address for the first LED driver | |
| `LED_DRIVER_ADDR_2` | (Optional) Address for the second LED driver | |
| `LED_DRIVER_ADDR_3` | (Optional) Address for the third LED driver | |
| `LED_DRIVER_ADDR_4` | (Optional) Address for the fourth LED driver | |
Here is an example using 2 drivers.
// This is a 7-bit address, that gets left-shifted and bit 0
// set to 0 for write, 1 for read (as per I2C protocol)
// The address will vary depending on your wiring:
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`:
const is31_led g_is31_leds[DRIVER_LED_TOTAL] = {
/* Refer to IS31 manual for these locations
* driver
* | LED address
* | | */
{0, C3_3},
....
}
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-simple.h`. The `driver` is the index of the driver you defined in your `config.h` (`0`, `1`, `2`, or `3` ).
## Keycodes
All LED matrix keycodes are currently shared with the [backlight system](feature_backlight.md).
## LED Matrix Effects
Currently no LED matrix effects have been created.
## Custom layer effects
Custom layer effects can be done by defining this in your `<keyboard>.c`:
void led_matrix_indicators_kb(void) {
led_matrix_set_index_value(index, value);
}
A similar function works in the keymap as `led_matrix_indicators_user`.
## Suspended state
To use the suspend feature, add this to your `<keyboard>.c`:
?> This is inherited from TMK, and hasn't been updated - it's recommend that you use `SEND_STRING` and `process_record_user` instead.
## Advanced Macro Functions
There are some functions you may find useful in macro-writing. Keep in mind that while you can write some fairly advanced code within a macro, if your functionality gets too complex you may want to define a custom keycode instead. Macros are meant to be simple.
### `record->event.pressed`
This is a boolean value that can be tested to see if the switch is being pressed or released. An example of this is
```c
if(record->event.pressed){
// on keydown
}else{
// on keyup
}
```
### `register_code(<kc>);`
This sends the `<kc>` keydown event to the computer. Some examples would be `KC_ESC`, `KC_C`, `KC_4`, and even modifiers such as `KC_LSFT` and `KC_LGUI`.
### `unregister_code(<kc>);`
Parallel to `register_code` function, this sends the `<kc>` keyup event to the computer. If you don't use this, the key will be held down until it's sent.
### `tap_code(<kc>);`
This will send `register_code(<kc>)` and then `unregister_code(<kc>)`. This is useful if you want to send both the press and release events ("tap" the key, rather than hold it).
If you're having issues with taps (un)registering, you can add a delay between the register and unregister events by setting `#define TAP_CODE_DELAY 100` in your `config.h` file. The value is in milliseconds.
### `register_code16(<kc>);`, `unregister_code16(<kc>);` and `tap_code16(<kc>);`
These functions work similar to their regular counterparts, but allow you to use modded keycodes (with Shift, Alt, Control, and/or GUI applied to them).
Eg, you could use `register_code16(S(KC_5));` instead of registering the mod, then registering the keycode.
### `clear_keyboard();`
This will clear all mods and keys currently pressed.
### `clear_mods();`
This will clear all mods currently pressed.
### `clear_keyboard_but_mods();`
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.
There are some functions you may find useful in macro-writing. Keep in mind that while you can write some fairly advanced code within a macro if your functionality gets too complex you may want to define a custom keycode instead. Macros are meant to be simple.
## Advanced Example:
### `record->event.pressed`
This is a boolean value that can be tested to see if the switch is being pressed or released. An example of this is
```c
if(record->event.pressed){
// on keydown
}else{
// on keyup
}
```
### `register_code(<kc>);`
This sends the `<kc>` keydown event to the computer. Some examples would be `KC_ESC`, `KC_C`, `KC_4`, and even modifiers such as `KC_LSFT` and `KC_LGUI`.
### `unregister_code(<kc>);`
Parallel to `register_code` function, this sends the `<kc>` keyup event to the computer. If you don't use this, the key will be held down until it's sent.
### `tap_code(<kc>);`
This will send `register_code(<kc>)` and then `unregister_code(<kc>)`. This is useful if you want to send both the press and release events ("tap" the key, rather than hold it).
If you're having issues with taps (un)registering, you can add a delay between the register and unregister events by setting `#define TAP_CODE_DELAY 100` in your `config.h` file. The value is in milliseconds.
### `clear_keyboard();`
This will clear all mods and keys currently pressed.
### `clear_mods();`
This will clear all mods currently pressed.
### `clear_keyboard_but_mods();`
This will clear all keys besides the mods currently pressed.
## Advanced Example: Single-Key Copy/Paste
### Single-Key Copy/Paste
This example defines a macro which sends `Ctrl-C` when pressed down, and `Ctrl-V` when released.
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. QMK 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).
## Adding mouse keys to your keyboard
## Adding Mousekeys to a Keymap
To use mousekeys, you must at least enable mouse keys support and map mouse actions to keys on your keyboard.
There are two steps to adding Mousekeys support to your keyboard. You must enable support in the `rules.mk` file and you must map mouse actions to keys on your keyboard.
### Enabling mouse keys
### Adding Mousekeys Support in the `rules.mk`
To enable mousekeys, add the following line to your keymap’s `rules.mk`:
To add support for Mousekeys you simply need to add a single line to your keymap's `rules.mk`:
```
```c
MOUSEKEY_ENABLE=yes
```
You can see an example here: https://github.com/qmk/qmk_firmware/blob/master/keyboards/clueboard/66/keymaps/mouse_keys/rules.mk
### Mapping mouse actions
### Mapping Mouse Actions to Keyboard Keys
In your keymap you can use the following keycodes to map key presses to mouse actions:
You can use these keycodes within your keymap to map button presses to mouse actions:
|`KC_MS_ACCEL0` |`KC_ACL0`|Set mouse acceleration to 0|
|`KC_MS_ACCEL1` |`KC_ACL1`|Set mouse acceleration to 1|
|`KC_MS_ACCEL2` |`KC_ACL2`|Set mouse acceleration to 2|
## Configuring mouse keys
You can see an example in the `_ML` here: https://github.com/qmk/qmk_firmware/blob/master/keyboards/clueboard/66/keymaps/mouse_keys/keymap.c#L46
Mouse keys supports two different modes to move the cursor:
## Configuring the Behavior of Mousekeys
* **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.
### Accelerated mode
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 |
Tips:
* 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.
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).
### Constant mode
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.
You can choose whether speed selection is momentary or tap-to-select:
* **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.
The default speeds from slowest to fastest are as follows:
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.
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.
### `MOUSEKEY_MAX_SPEED`
As a movement key is held down the speed of the mouse cursor will increase until it reaches `MOUSEKEY_MAX_SPEED`.
### `MOUSEKEY_TIME_TO_MAX`
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.
### `MOUSEKEY_WHEEL_MAX_SPEED`
The top speed for scrolling movements.
### `MOUSEKEY_WHEEL_TIME_TO_MAX`
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.
128x32 OLED modules using SSD1306 driver IC over I2C. Supported on AVR based keyboards. Possible but untested hardware includes ARM based keyboards and other sized OLED modules using SSD1306 over I2C, such as 128x64.
!> Warning: This OLED Driver currently uses the new i2c_master driver from split common code. If your split keyboard uses i2c to communication 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.
## 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 (biton32(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.|
## 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.
This feature allows you to use RGB LED matrices driven by external drivers. It hooks into the RGBLIGHT system so you can use the same keycodes as RGBLIGHT to control it.
If you want to use single color LED's you should use the [LED Matrix Subsystem](feature_led_matrix.md) instead.
## Driver configuration
---
### IS31FL3731
There is basic support for addressable RGB matrix lighting with the I2C IS31FL3731 RGB controller. To enable it, add this to your `rules.mk`:
RGB_MATRIX_ENABLE = IS31FL3731
```C
RGB_MATRIX_ENABLE=IS31FL3731
```
Configure the hardware via your `config.h`:
// This is a 7-bit address, that gets left-shifted and bit 0
// set to 0 for write, 1 for read (as per I2C protocol)
// The address will vary depending on your wiring:
// 0b1110100 AD <-> GND
// 0b1110111 AD <-> VCC
// 0b1110101 AD <-> SCL
// 0b1110110 AD <-> SDA
#define DRIVER_ADDR_1 0b1110100
#define DRIVER_ADDR_2 0b1110110
```C
// This is a 7-bit address, that gets left-shifted and bit 0
// set to 0 for write, 1 for read (as per I2C protocol)
// The address will vary depending on your wiring:
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`:
const is31_led g_is31_leds[DRIVER_LED_TOTAL] = {
/* Refer to IS31 manual for these locations
* driver
*|R location
* | | G location
* | | | B location
* | | | | */
{0, C1_3, C2_3, C3_3},
....
}
```C
constis31_ledg_is31_leds[DRIVER_LED_TOTAL]={
/* Refer to IS31 manual for these locations
* driver
*|R location
* | | G location
* | | | B location
* | | | | */
{0,C1_3,C2_3,C3_3},
....
}
```
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
---
### IS31FL3733/IS31FL3737
!> For the IS31FL3737, replace all instances of `IS31FL3733` below with `IS31FL3737`.
There is basic support for addressable RGB matrix lighting with the I2C IS31FL3733 RGB controller. To enable it, add this to your `rules.mk`:
RGB_MATRIX_ENABLE = IS31FL3733
```C
RGB_MATRIX_ENABLE=IS31FL3733
```
Configure the hardware via your `config.h`:
// This is a 7-bit address, that gets left-shifted and bit 0
// set to 0 for write, 1 for read (as per I2C protocol)
// The address will vary depending on your wiring:
// 00 <-> GND
// 01 <-> SCL
// 10 <-> SDA
// 11 <-> VCC
// ADDR1 represents A1:A0 of the 7-bit address.
// ADDR2 represents A3:A2 of the 7-bit address.
// The result is: 0b101(ADDR2)(ADDR1)
#define DRIVER_ADDR_1 0b1010000
#define DRIVER_ADDR_2 0b1010000 // this is here for compliancy reasons.
```C
// This is a 7-bit address, that gets left-shifted and bit 0
// set to 0 for write, 1 for read (as per I2C protocol)
// The address will vary depending on your wiring:
// 00 <-> GND
// 01 <-> SCL
// 10 <-> SDA
// 11 <-> VCC
// ADDR1 represents A1:A0 of the 7-bit address.
// ADDR2 represents A3:A2 of the 7-bit address.
// The result is: 0b101(ADDR2)(ADDR1)
#define DRIVER_ADDR_1 0b1010000
#define DRIVER_ADDR_2 0b1010000 // this is here for compliancy reasons.
#define DRIVER_COUNT 1
#define DRIVER_1_LED_TOTAL 64
#define DRIVER_LED_TOTAL DRIVER_1_LED_TOTAL
#define DRIVER_COUNT 2
#define DRIVER_1_LED_TOTAL 64
#define DRIVER_LED_TOTAL DRIVER_1_LED_TOTAL
```
Currently only a single drivers is supported, but it would be trivial to support all 4 combinations. For now define `DRIVER_ADDR_2` as `DRIVER_ADDR_1`
Define these arrays listing all the LEDs in your `<keyboard>.c`:
const is31_led g_is31_leds[DRIVER_LED_TOTAL] = {
/* Refer to IS31 manual for these locations
* driver
*|R location
* ||G location
* | | | B location
* | | | | */
{0, B_1,A_1, C_1},
....
}
```C
constis31_ledg_is31_leds[DRIVER_LED_TOTAL]={
/* Refer to IS31 manual for these locations
* driver
*|R location
* | | G location
* | | | B location
* || | | */
{0,B_1,A_1,C_1},
....
}
```
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.
---
const rgb_led g_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},
....
}
### WS2812 (AVR only)
The formatforthematrixpositionusedinthisarrayis`{row | (col << 4)}`.The`x`isbetween(inclusive)0-224,and`y`isbetween(inclusive)0-64.Theeasiestwaytocalculatethesepositionsis:
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`:
From this point forward the configuration is the same for all the drivers. The struct rgb_led array tells the system for each led, what key electrical matrix it represents, what the physical position is on the board, and if the led is for a modifier key or not. Here is a brief example:
```C
rgb_ledg_rgb_leds[DRIVER_LED_TOTAL]={
/* {row | col << 4}
* | {x=0..224, y=0..64}
* | | flags
* | | | */
{{0|(0<<4)},{20.36*0,21.33*0},1},
{{0|(1<<4)},{20.36*1,21.33*0},4},
....
}
```
The first part, `{row | col << 4}`, tells the system what key this LED represents by using the key's electrical matrix row & col. The second part, `{x=0..224, y=0..64}` represents the LED's physical position on the keyboard. The `x` is between (inclusive) 0-224, and `y` is between (inclusive) 0-64 as the effects are based on this range. 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.
`flags` 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.
*`RGB_SPI`- increasespeedeffect (no EEPROMsupport)
*`RGB_SPD`- decreasespeedeffect (no EEPROMsupport)
*`RGB_MODE_*` keycodes will generally work, but are not currently mapped to the correct effects for the RGB Matrix system
## RGB Matrix Effects
Thesearethe effects that are currently available:
All effects have been configured to support current configuration values (Hue, Saturation, Value, & Speed) unless otherwise noted below. These are the effectsthat are currentlyavailable:
```C
enumrgb_matrix_effects{
RGB_MATRIX_NONE=0,
RGB_MATRIX_SOLID_COLOR=1,// Static single hue, no speed support
RGB_MATRIX_ALPHAS_MODS,// Static dual hue, speed is hue for secondary hue
RGB_MATRIX_GRADIENT_UP_DOWN,// Static gradient top to bottom, speed controls how much gradient changes
RGB_MATRIX_BREATHING,// Single hue brightness cycling animation
RGB_MATRIX_CYCLE_ALL,// Full keyboard solid hue cycling through full gradient
RGB_MATRIX_CYCLE_LEFT_RIGHT,// Full gradient scrolling left to right
RGB_MATRIX_CYCLE_UP_DOWN,// Full gradient scrolling top to bottom
RGB_MATRIX_RAINBOW_MOVING_CHEVRON,// Full gradent Chevron shapped scrolling left to right
RGB_MATRIX_DUAL_BEACON,// Full gradient spinning around center of keyboard
RGB_MATRIX_RAINBOW_BEACON,// Full tighter gradient spinning around center of keyboard
RGB_MATRIX_RAINBOW_PINWHEELS,// Full dual gradients spinning two halfs of keyboard
RGB_MATRIX_RAINDROPS,// Randomly changes a single key's hue
RGB_MATRIX_JELLYBEAN_RAINDROPS,// Randomly changes a single key's hue and saturation
RGB_MATRIX_DIGITAL_RAIN,// That famous computer simulation
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.
voidrgb_matrix_indicators_kb(void){
rgb_matrix_set_color(index,red,green,blue);
}
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
// !!! 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
#defineRGB_MATRIX_KEYPRESSES // reacts to keypresses
#defineRGB_MATRIX_KEYRELEASES // reacts to keyreleases (instead of keypresses)
#defineRGB_DISABLE_AFTER_TIMEOUT 0 // number of ticks to wait until disabling effects
#defineRGB_DISABLE_WHEN_USB_SUSPENDED false // turn off effects when suspended
#defineRGB_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
```
## EEPROM storage
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:
#defineEECONFIG_RGB_MATRIX(uint32_t*)16
```C
#define EECONFIG_RGB_MATRIX (uint32_t *)28
```
Where`16`is an unused index from`eeconfig.h`.
Where `28` is an unusedindexfrom `eeconfig.h`.
## Suspended state
To use the suspend feature, add this to your `<keyboard>.c`:
At minimum you must define the data pin your LED strip is connected to, and the number of LEDs in the strip, in your `config.h`. If your keyboard has onboard RGB LEDs, and you are simply creating a keymap, you usually won't need to modify these.
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_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_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_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 |
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!
## Colors
## Hardware Modification
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!
## Changing the order of the LEDs
If you want to make the logical order of LEDs different from the electrical connection order, you can do this by defining the `RGBLIGHT_LED_MAP` macro in your `config.h`.
Normally, the contents of the LED buffer are output to the LEDs in the same order.
For keyboards that use the RGB LEDs as a backlight for each key, you can also define it as in the example below.
```c
// config.h
#define RGBLED_NUM 30
/* RGB LED Conversion macro from physical array to electric array */
#define LED_LAYOUT( \
L00, L01, L02, L03, L04, L05, \
L10, L11, L12, L13, L14, L15, \
L20, L21, L22, L23, L24, L25, \
L30, L31, L32, L33, L34, L35, \
L40, L41, L42, L43, L44, L45 ) \
{ \
L05, L04, L03, L02, L01, L00, \
L10, L11, L12, L13, L14, L15, \
L25, L24, L23, L22, L21, L20, \
L30, L31, L32, L33, L34, L35, \
L46, L45, L44, L43, L42, L41 \
}
/* RGB LED logical order map */
/* Top->Bottom, Right->Left */
#define RGBLIGHT_LED_MAP LED_LAYOUT( \
25, 20, 15, 10, 5, 0, \
26, 21, 16, 11, 6, 1, \
27, 22, 17, 12, 7, 2, \
28, 23, 18, 13, 8, 3, \
29, 24, 19, 14, 9, 4 )
```
## Clipping Range
Using the `rgblight_set_clipping_range()` function, you can prepare more buffers than the actual number of LEDs, and output some of the buffers to the LEDs. This is useful if you want the split keyboard to treat left and right LEDs as logically contiguous.
You can set the Clipping Range by executing the following code.
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_LCTL, KC_9` |Send `KC_LCTL` when held, the mod `KC_LCTL` with the key `KC_9` when tapped. |
|`RCPO_KEYS` |`KC_RCTL, KC_RCTL, KC_0` |Send `KC_RCTL` when held, the mod `KC_RCTL` with the key `KC_0` when tapped. |
|`LAPO_KEYS` |`KC_LALT, KC_LALT, KC_9` |Send `KC_LALT` when held, the mod `KC_LALT` with the key `KC_9` when tapped. |
|`RAPO_KEYS` |`KC_RALT, KC_RALT, KC_0` |Send `KC_RALT` when held, the mod `KC_RALT` 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. |
## 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 KC_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.
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.
And then simply use `TD(X_CTL)` anywhere in your keymap.
If you want to implement this in your userspace, then you may want to check out how [DanielGGordon](https://github.com/qmk/qmk_firmware/tree/master/users/gordon) has implemented this in their userspace.
### Example 5: Using tap dance for advanced mod-tap and layer-tap keys
Tap dance can be used to emulate `MT()` and `LT()` behavior when the tapped code is not a basic keycode. This is useful to send tapped keycodes that normally require `Shift`, such as parentheses or curly braces—or other modified keycodes, such as `Control + X`.
Below your layers and custom keycodes, add the following:
```c
// tapdance keycodes
enumtd_keycodes{
ALT_LP// Our example key: `LALT` when held, `(` when tapped. Add additional keycodes for each tapdance.
};
// define a type containing as many tapdance states as you need
typedefenum{
SINGLE_TAP,
SINGLE_HOLD,
DOUBLE_SINGLE_TAP
}td_state_t;
// create a global instance of the tapdance state type
statictd_state_ttd_state;
// declare your tapdance functions:
// function to determine the current tapdance state
intcur_dance(qk_tap_dance_state_t*state);
// `finished` and `reset` functions for each tapdance keycode
There are three Unicode keymap definition methods available in QMK:
## UNICODE_ENABLE
## `UNICODE_ENABLE`
Supports Unicode up to `0xFFFF`. The keycode function is `UC(n)` in the keymap file, where _n_ is a 4 digit hexadecimal number.
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)`.
## UNICODEMAP_ENABLE
## `UNICODEMAP_ENABLE`
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(n)`, where _n_ is an array index into the mapping table.
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.
And you may want to have an enum to make reference easier. So you'd want to add something like this to your keymap:
You may want to have an enum to make referencing easier. So, you could add something like this to your keymap file:
```c
enumunicode_names{
@@ -20,38 +20,37 @@ enum unicode_names {
};
constuint32_tPROGMEMunicode_map[]={
[BANG]=0x203D,// ‽
[IRONY]=0x2E2E,// ⸮
[SNEK]=0x1F40D,// 🐍
[BANG]=0x203D,// ‽
[IRONY]=0x2E2E,// ⸮
[SNEK]=0x1F40D,// 🐍
};
```
Make sure that the order for both matches.
Then you can use `X(BANG)` etc. in your keymap.
## UCIS_ENABLE
## `UCIS_ENABLE`
Supports Unicode up to `0x10FFFF` (all possible code points). As with `UNICODEMAP`, you may want 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 it's been called, you can type the 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 sequence inserted.
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.
For instance, you would need to have a table like this in your keymap:
For instance, you would define a table like this in your keymap file:
You run the function, and then type "rofl" and hit enter, it should backspace remove "rofl" and input the `0x1f923` unicode.
You call `qk_ucis_start()`, then type "rofl" and hit Enter. QMK should erase the "rofl" text and input the laughing emoji.
### Customization
There are several functions that you can add to your keymap to customize the functionality of this feature.
There are several functions that you can define in your keymap to customize the functionality of this feature.
*`void qk_ucis_start_user(void)`- This runs when you run the "start" function, and can be used to provide feedback. By default, it types out a keyboard emoji.
*`void qk_ucis_success(uint8_t symbol_index)`- This runs when the unicode input has matched something, and has completed. Default doesn't do anything.
*`void qk_ucis_symbol_fallback (void)`- This runs if the input text doesn't match anything. The default function falls back to trying that input as a unicode code.
*`void qk_ucis_start_user(void)`– This runs when you call the "start" function, and can be used to provide feedback. By default, it types out a keyboard emoji.
*`void qk_ucis_success(uint8_t symbol_index)`– This runs when the input has matched something and has completed. By default, it doesn't do anything.
*`void qk_ucis_symbol_fallback (void)`– This runs when the input doesn't match anything. By default, it falls back to trying that input as a Unicode code.
You can find the default implementations of these functions in [`process_ucis.c`](https://github.com/qmk/qmk_firmware/blob/master/quantum/process_keycode/process_ucis.c).
@@ -66,7 +65,9 @@ The following input modes are available:
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.
* **`UC_LNX`**: Linux built-in IBus Unicode input. Supports all possible code points (`0x10FFFF`).
**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`).
* **`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.
@@ -77,7 +78,7 @@ The following input modes are available:
* **`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`.
* **`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).
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.
@@ -122,7 +123,7 @@ 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 such a large and variable feature, there are a number of options that you can customize to work better on your system.
#### Start and Finish input functions
@@ -184,7 +185,7 @@ AutoHotkey inserts the Text right of `Send, ` when this combination is pressed.
### US International
If you enable the US International layout on the system, it will use punctuation to accent the characters.
If you enable the US International layout on the system, it will use punctuation to accent the characters.
caseKC_MAKE:// Compiles the firmware, and adds the flash command based on keyboard bootloader
if(!record->event.pressed){
uint8_ttemp_mod=get_mods();
uint8_ttemp_osm=get_oneshot_mods();
clear_mods();clear_oneshot_mods();
SEND_STRING("make "QMK_KEYBOARD":"QMK_KEYMAP);
#ifndef FLASH_BOOTLOADER
if((temp_mod|temp_osm)&MOD_MASK_SHIFT)
#endif
{//
#if defined(__arm__) // only run for ARM boards
SEND_STRING(":dfu-util");
#elif defined(BOOTLOADER_DFU) // only run for DFU boards
SEND_STRING(":dfu");
#elif defined(BOOTLOADER_HALFKAY) // only run for teensy boards
SEND_STRING(":teensy");
#elif defined(BOOTLOADER_CATERINA) // only run for Pro Micros
SEND_STRING(":avrdude");
#endif // bootloader options
}
if((temp_mod|temp_osm)&MOD_MASK_CTRL){
SEND_STRING(" -j8 --output-sync");
}
SEND_STRING(SS_TAP(X_ENTER));
set_mods(temp_mod);
}
break;
}
returnprocess_record_keymap(keycode,record);
}
```
For boards that may not have a shift button (such as on a macro pad), we need a way to always include the bootloader option. To do that, add the following to the `rules.mk` in your userspace folder:
```make
ifeq ($(strip $(FLASH_BOOTLOADER)), yes)
OPT_DEFS += -DFLASH_BOOTLOADER
endif
```
This will add a new `KC_MAKE` keycode that can be used in any of your keymaps. And this keycode will output `make <keyboard>:<keymap>`, making frequent compiling easier. And this will work with any keyboard and any keymap as it will output the current boards info, so that you don't have to type this out every time.
Additionally, this should flash the newly compiled firmware automatically, using the correct utility, based on the bootloader settings (or default to just generating the HEX file). However, it should be noted that this may not work on all systems. AVRDUDE doesn't work on WSL, namely (and will dump the HEX in the ".build" folder instead).
Also, holding `shift` will add the appropriate flashing command (`:dfu`, `:teensy`, `:avrdude`, `:dfu-util`) for a majority of keyboards. Holding `control` will add some commands that will speed up compiling time by processing multiple files at once.
And for the boards that lack a shift key, or that you want to always attempt the flashing part, you can add `FLASH_BOOTLOADER = yes` to the `rules.mk` of that keymap.
?> This should flash the newly compiled firmware automatically, using the correct utility, based on the bootloader settings (or default to just generating the HEX file). However, it should be noted that this may not work on all systems. AVRDUDE doesn't work on WSL, namely. And this doesn't support BootloadHID or mdloader.
Velocikey is a feature that lets you control the speed of lighting effects (like the Rainbow Swirl effect) with the speed of your typing. The faster you type, the faster the lights will go!
## Usage
For Velocikey to take effect, there are two steps. First, when compiling your keyboard, you'll need to set `VELOCIKEY_ENABLE=yes` in `rules.mk`, e.g.:
```
BOOTMAGIC_ENABLE = no
MOUSEKEY_ENABLE = no
STENO_ENABLE = no
EXTRAKEY_ENABLE = yes
VELOCIKEY_ENABLE = yes
```
Then, while using your keyboard, you need to also turn it on with the VLK_TOG keycode, which toggles the feature on and off.
The following light effects will all be controlled by Velocikey when it is enabled:
- RGB Breathing
- RGB Rainbow Mood
- RGB Rainbow Swirl
- RGB Snake
- RGB Knight
Support for LED breathing effects is planned but not available yet.
As long as Velocikey is enabled, it will control the speed regardless of any other speed setting that your RGB lights are currently on.
## Configuration
Velocikey doesn't currently support any configuration via keyboard settings. If you want to adjust something like the speed increase or decay rate, you would need to edit `velocikey.c` and adjust the values there to achieve the kinds of speeds that you like.
@@ -49,9 +49,18 @@ To generate this bootloader, use the `bootloader` target, eg `make planck/rev4:d
To generate a production-ready .hex file (containing the application and the bootloader), use the `production` target, eg `make planck/rev4:default:production`.
### DFU commands
There are a number of DFU commands that you can use to flash firmware to a DFU device:
*`:dfu` - This is the normal option and waits until a DFU device is available, and then flashes the firmware. This will check every 5 seconds, to see if a DFU device has appeared.
*`:dfu-ee` - This flashes an `eep` file instead of the normal hex. This is uncommon.
*`:dfu-split-left` - This flashes the normal firmware, just like the default option (`:dfu`). However, this also flashes the "Left Side" EEPROM file for split keyboards. _This is ideal for Elite C based split keyboards._
*`:dfu-split-right` - This flashes the normal firmware, just like the default option (`:dfu`). However, this also flashes the "Right Side" EEPROM file for split keyboards. _This is ideal for Elite C based split keyboards._
## Caterina
Arduino boards and their clones use the [Caterina bootloader](https://github.com/arduino/Arduino/tree/master/hardware/arduino/avr/bootloaders/caterina) (any keyboard built with a Pro Micro, or clone), and uses the avr109 protocol to communicate through virtual serial. Bootloaders like [A-Star](https://www.pololu.com/docs/0J61/9) are based on Caterina.
Arduino boards and their clones use the [Caterina bootloader](https://github.com/arduino/ArduinoCore-avr/tree/master/bootloaders/caterina) (any keyboard built with a Pro Micro, or clone), and uses the avr109 protocol to communicate through virtual serial. Bootloaders like [A-Star](https://www.pololu.com/docs/0J61/9) are based on Caterina.
To ensure compatibility with the Caterina bootloader, make sure this block is present your `rules.mk`:
@@ -84,6 +93,7 @@ or if you want to flash multiple boards, use the following command
When you're done flashing boards, you'll need to hit Ctrl + C or whatever the correct keystroke is for your operating system to break the loop.
## Halfkay
Halfkay is a super-slim protocol developed by PJRC that uses HID, and come on all Teensys (namely the 2.0).
@@ -131,3 +141,12 @@ Flashing sequence:
* You will receive a warning about the DFU signature; Just ignore it
4. Reset the device into application mode (may be done automatically)
* If you are building from command line (e.g. `make planck/rev6:default:dfu-util`), make sure that `:leave` is passed to the `DFU_ARGS` variable inside your `rules.mk` (e.g. `DFU_ARGS = -d 0483:df11 -a 0 -s 0x08000000:leave`) so that your device resets after flashing
### STM32 Commands
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.
@@ -123,12 +129,12 @@ If you have trouble and want to ask for help, it is useful to generate a *Win_Ch
## Docker
If this is a bit complex for you, Docker might be the turn-key solution you need. After installing [Docker CE](https://docs.docker.com/install/#supported-platforms), run the following command from the `qmk_firmware` directory to build a keyboard/keymap:
If this is a bit complex for you, Docker might be the turnkey solution you need. After installing [Docker CE](https://docs.docker.com/install/#supported-platforms), run the following command from the `qmk_firmware` directory to build a keyboard/keymap:
```bash
util/docker_build.sh keyboard:keymap
util/docker_build.sh keyboard:keymap
# For example: util/docker_build.sh ergodox_ez:steno
```
This will compile the targeted keyboard/keymap and leave the resulting `.hex` or `.bin` file in the QMK directory for you to flash. If `:keymap` is omitted, the `default` keymap is used. Note that the parameter format is the same as when building with `make`.
This will compile the desired keyboard/keymap and leave the resulting `.hex` or `.bin` file in the QMK directory for you to flash. If `:keymap` is omitted, the `default` keymap is used. Note that the parameter format is the same as when building with `make`.
You can also start the script without any parameters, in which case it will ask you to input the build parameters one by one, which you may find easier to use:
```bash
@@ -141,7 +147,7 @@ There is also support for building _and_ flashing the keyboard straight from Doc
util/docker_build.sh keyboard:keymap:target
# For example: util/docker_build.sh planck/rev6:default:dfu-util
```
If you're on Linux, this should work out of the box. On Windows and macOS, it requires [Docker Machine](http://gw.tnode.com/docker/docker-machine-with-usb-support-on-windows-macos/) to be running. This is tedious to set up, so it's not recommended; use QMK Toolbox instead.
If you're on Linux, this should work out of the box. On Windows and macOS, it requires [Docker Machine](http://gw.tnode.com/docker/docker-machine-with-usb-support-on-windows-macos/) to be running. This is tedious to set up, so it's not recommended; use [QMK Toolbox](https://github.com/qmk/qmk_toolbox) instead.
!> Docker for Windows requires [Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v) to be enabled. This means that it cannot work on versions of Windows which don't have Hyper-V, such as Windows 7, Windows 8 and **Windows 10 Home**.
@@ -93,19 +93,17 @@ This enables MIDI sending and receiving with your keyboard. To enter MIDI send m
`UNICODE_ENABLE`
This allows you to send unicode symbols via`UC(<unicode>)` in your keymap. Only codes up to 0x7FFF are currently supported.
This allows you to send Unicode characters using`UC(<code point>)` in your keymap. Code points up to `0x7FFF` are supported. This covers characters for most modern languages, as well as symbols, but it doesn't cover emoji.
`UNICODEMAP_ENABLE`
This allows sending unicode symbols using `X(<unicode>)` in your keymap. Codes
up to 0xFFFFFFFF are supported, including emojis. You will need to maintain
a separate mapping table in your keymap file.
This allows you to send Unicode characters using `X(<map index>)` in your keymap. You will need to maintain a mapping table in your keymap file. All possible code points (up to `0x10FFFF`) are supported.
Known limitations:
- Under Mac OS, only codes up to 0xFFFF are supported.
- Under Linux ibus, only codes up to 0xFFFFF are supported (but anything important is still under this limit for now).
`UCIS_ENABLE`
Characters out of range supported by the OS will be ignored.
This allows you to send Unicode characters by inputting a mnemonic corresponding to the character you want to send. You will need to maintain a mapping table in your keymap file. All possible code points (up to `0x10FFFF`) are supported.
For further details, as well as limitations, see the [Unicode page](feature_unicode.md).
`BLUETOOTH_ENABLE`
@@ -117,7 +115,7 @@ This allows you output audio on the C6 pin (needs abstracting). See the [audio p
`FAUXCLICKY_ENABLE`
Uses buzzer to emulate clicky switches. A cheap imitation of the Cherry blue switches. By default, uses the C6 pin, same as AUDIO_ENABLE.
Uses buzzer to emulate clicky switches. A cheap imitation of the Cherry blue switches. By default, uses the C6 pin, same as `AUDIO_ENABLE`.
`VARIABLE_TRACE`
@@ -137,6 +135,18 @@ This enables [key lock](feature_key_lock.md). This consumes an additional 260 by
This enables split keyboard support (dual MCU like the let's split and bakingpy's boards) and includes all necessary files located at quantum/split_common
`SPLIT_TRANSPORT`
As there is no standard split communication driver for ARM-based split keyboards yet, `SPLIT_TRANSPORT = custom` must be used for these. It will prevent the standard split keyboard communication code (which is AVR-specific) from being included, allowing a custom implementation to be used.
`CUSTOM_MATRIX`
Lets you replace the default matrix scanning routine with your own code. You will need to provide your own implementations of matrix_init() and matrix_scan().
`DEBOUNCE_TYPE`
Lets you replace the default key debouncing routine with an alternative one. If `custom` you will need to provide your own implementation.
## Customizing Makefile Options on a Per-Keymap Basis
If your keymap directory has a file called `rules.mk` any options you set in that file will take precedence over other `rules.mk` options for your particular keyboard.
@@ -185,21 +185,30 @@ When you're done with the columns, start with the rows in the same process, from
As you move along, be sure that the Teensy is staying in place - recutting and soldering the wires is a pain!
## Additional guides
If you're more of a visual learner, or want some additional tips and something more to follow along, these two visual step by step guides may be helpful:
- [BrownFox's step by step guide](https://deskthority.net/viewtopic.php?f=7&t=6050)
- [Cribbit's modern hand wiring guide](https://geekhack.org/index.php?topic=87689.0)
# Getting Some Basic Firmware Set Up
From here, you should have a working keyboard once you program a firmware. Before we attach the Teensy permanently to the keyboard, let's quickly get some firmware loaded onto the Teensy so we can test each keyswitch.
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/).
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`
@@ -209,7 +218,7 @@ Farther down are `MATRIX_ROW_PINS` and `MATRIX_COL_PINS`. Change their definitio
### `<project_name>.h`
The next file you'll want to look at is `<project_name>.h`. You're going to want to rewrite the `KEYMAP` definition - the format and syntax here is extremely important, so pay attention to how things are setup. The first half of the definition are considered the arguments - this is the format that you'll be following in your keymap later on, so you'll want to have as many k*xy* variables here as you do keys. The second half is the part that the firmware actually looks at, and will contain gaps depending on how you wired your matrix.
The next file you'll want to look at is `<project_name>.h`. You're going to want to rewrite the `LAYOUT` definition - the format and syntax here is extremely important, so pay attention to how things are setup. The first half of the definition are considered the arguments - this is the format that you'll be following in your keymap later on, so you'll want to have as many k*xy* variables here as you do keys. The second half is the part that the firmware actually looks at, and will contain gaps depending on how you wired your matrix.
We'll dive into how this will work with the following example. Say we have a keyboard like this:
@@ -231,10 +240,10 @@ This can be described by saying the top row is 3 1u keys, and the bottom row is
└─────┴─────┘
```
The middle column is unused on the bottom row in this example. Our `KEYMAP` definition would look like this:
The middle column is unused on the bottom row in this example. Our `LAYOUT` definition would look like this:
```
#define KEYMAP( \
#define LAYOUT( \
k00, k01, k02, \
k10, k11, \
) \
@@ -256,10 +265,10 @@ Let's say that instead, we wired our keyboard like this (a fair thing to do):
└─────┴─────┘
```
This would require our `KEYMAP` definition to look like this:
This would require our `LAYOUT` definition to look like this:
```
#define KEYMAP( \
#define LAYOUT( \
k00, k01, k02, \
k10, k11, \
) \
@@ -269,7 +278,7 @@ This would require our `KEYMAP` definition to look like this:
}
```
Notice how the `k11` and `KC_NO` switched places to represent the wiring, and the unused final column on the bottom row. Sometimes it'll make more sense to put a keyswitch on a particular column, but in the end, it won't matter, as long as all of them are accounted for. You can use this process to write out the `KEYMAP` for your entire keyboard - be sure to remember that your keyboard is actually backwards when looking at the underside of it.
Notice how the `k11` and `KC_NO` switched places to represent the wiring, and the unused final column on the bottom row. Sometimes it'll make more sense to put a keyswitch on a particular column, but in the end, it won't matter, as long as all of them are accounted for. You can use this process to write out the `LAYOUT` for your entire keyboard - be sure to remember that your keyboard is actually backwards when looking at the underside of it.
### `keymaps/<variant>/default.c`
@@ -291,7 +300,7 @@ This can be accomplished by using the following `keymaps` definition:
Note that the layout of the keycodes is similar to the physical layout of our keyboard - this make it much easier to see what's going on. A lot of the keycodes should be fairly obvious, but for a full list of them, check out [Keycodes](keycodes.md) - there are also a lot of aliases to condense your keymap file.
It's also important to use the `KEYMAP` function we defined earlier - this is what allows the firmware to associate our intended readable keymap with the actual wiring.
It's also important to use the `LAYOUT` function we defined earlier - this is what allows the firmware to associate our intended readable keymap with the actual wiring.
## Compiling Your Firmware
@@ -319,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.
@@ -328,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.
@@ -87,12 +99,30 @@ Once you've defined the size of your matrix you need to define which pins on you
The number of `MATRIX_ROW_PINS` entries must be the same as the number you assigned to `MATRIX_ROWS`, and likewise for `MATRIX_COL_PINS` and `MATRIX_COLS`. You do not have to specify `UNUSED_PINS`, but you can if you want to document what pins are open.
Finally, you can specify the direction your diodes point. This can be `COL2ROW`,`ROW2COL`, or `CUSTOM_MATRIX`.
Finally, you can specify the direction your diodes point. This can be `COL2ROW` or`ROW2COL`.
```c
#define DIODE_DIRECTION COL2ROW
```
#### Direct Pin Matrix
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`.
```c
// #define MATRIX_ROW_PINS { D0, D5 }
// #define MATRIX_COL_PINS { F1, F0, B0 }
#define DIRECT_PINS { \
{ F1, E6, B0, B2, B3 }, \
{ F5, F0, B1, B7, D2 }, \
{ F6, F7, C7, D5, D3 }, \
{ B5, C6, B6, NO_PIN, NO_PIN } \
}
#define UNUSED_PINS
/* COL2ROW, ROW2COL */
//#define DIODE_DIRECTION
```
### 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).
@@ -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.
We welcome all keyboard projects into QMK, but ask that you try to stick to a couple guidelines that help us keep things organised and consistent.
Since starting, QMK has grown by leaps and bounds thanks to people like you who contribute to creating and maintaining our community keyboards. As we've grown we've discovered some patterns that work well, and ask that you conform to them to make it easier for other people to benefit from your hard work.
## Naming Your Keyboard/Project
All names should be lowercase alphanumeric, and separated by an underscore (`_`), but not begin with one. Your directory and your `.h` and `.c` files should have exactly the same name. All folders should follow the same format. `test`, `keyboard`, and `all` are reserved by make and are not a valid name for a keyboard.
All keyboard names are in lowercase, consisting only of letters, numbers, and underscore (`_`). Names may not begin with an underscore. Forward slash (`/`) is used as a sub-folder separation character.
## `readme.md`
The names `test`, `keyboard`, and `all` are reserved for make commands and may not be used as a keyboard or subfolder name.
All projects need to have a `readme.md` file that explains what the keyboard is, who made it, where it is available, and links to more information. Please follow the [published template](documentation_templates.md#keyboard-readmemd-template).
Valid Examples:
*`412_64`
*`chimera_ortho`
*`clueboard/66/rev3`
*`planck`
*`v60_type_r`
## Sub-folders
QMK uses sub-folders both for organization and to share code between revisions of the same keyboard. You can nest folders up to 4 levels deep:
If a sub-folder has a `rules.mk` file it will be considered a compilable keyboard. It will be available in QMK Configurator and tested with `make all`. If you are using a folder to organize several keyboards from the same maker you should not have a `rules.mk` file.
Example:
Clueboard uses sub-folders for both purposes, organization and keyboard revisions.
* [`clueboard`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard) ← This is the organization folder, there's no `rules.mk` file
* [`60`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/60) ← This is a compilable keyboard, it has a `rules.mk` file
* [`66`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/66) ← This is also compilable- it uses `DEFAULT_FOLDER` to specify `rev3` as the default revision
* [`rev3`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/66/rev3) ← compilable: `make clueboard/66/rev3` or `make clueboard/66`
## Keyboard Folder Structure
Your keyboard should be located in `qmk_firmware/keyboards/` and the folder name should be your keyboard's name as described in the previous section. Inside this folder should be several files:
*`readme.md`
*`info.json`
*`config.h`
*`rules.mk`
*`<keyboard_name>.c`
*`<keyboard_name>.h`
### `readme.md`
All projects need to have a `readme.md` file that explains what the keyboard is, who made it and where it's available. If applicable, it should also contain links to more information, such as the maker's website. Please follow the [published template](documentation_templates.md#keyboard-readmemd-template).
### `info.json`
This file is used by the [QMK API](https://github.com/qmk/qmk_api). It contains the information [QMK Configurator](https://config.qmk.fm/) needs to display a representation of your keyboard. You can also set metadata here. For more information see the [reference page](reference_info_json.md).
### `config.h`
All projects need to have a `config.h` file that sets things like the matrix size, product name, USB VID/PID, description and other settings. In general, use this file to set essential information and defaults for your keyboard that will always work.
### `rules.mk`
The presence of this file means that the folder is a keyboard target and can be used in `make` commands. This is where you setup the build environment for your keyboard and configure the default set of features.
### `<keyboard_name.c>`
This is where you will write custom code for your keyboard. Typically you will write code to initialize and interface with the hardware in your keyboard. If your keyboard consists of only a key matrix with no LEDs, speakers, or other auxillary hardware this file can be blank.
The following functions are typically defined in this file:
This file is used to define the matrix for your keyboard. You should define at least one C macro which translates an array into a matrix representing the physical switch matrix for your keyboard. If it's possible to build your keyboard with multiple layouts you should define additional macros.
If you have only a single layout you should call this macro `LAYOUT`.
When defining multiple layouts you should have a base layout, named `LAYOUT_all`, that supports all possible switch positions on your matrix, even if that layout is impossible to build physically. This is the macro you should use in your `default` keymap. You should then have additional keymaps named `default_<layout>` that use your other layout macros. This will make it easier for people to use the layouts you define.
Layout macro names are entirely lowercase, except for the word `LAYOUT` at the front.
As an example, if you have a 60% PCB that supports ANSI and ISO you might define the following layouts and keymaps:
| Layout Name | Keymap Name | Description |
|-------------|-------------|-------------|
| LAYOUT_all | default | A layout that supports both ISO and ANSI |
| LAYOUT_ansi | default_ansi | An ANSI layout |
| LAYOUT_iso | default_iso | An ISO layout |
## Image/Hardware Files
In an effort to keep the repo size down, we're no longer accepting images of any format in the repo, with few exceptions. Hosting them elsewhere (imgur) and linking them in the `readme.md` is the preferred method.
In an effort to keep the repo size down we're no longer accepting binary files of any format, with few exceptions. Hosting them elsewhere (such as <https://imgur.com>) and linking them in the `readme.md` is preferred.
Any sort of hardware file (plate, case, pcb) can't be stored in qmk_firmware, but we have the [qmk.fm repo](https://github.com/qmk/qmk.fm) where such files (as well as in-depth info) can be stored and viewed on [qmk.fm](http://qmk.fm). Downloadable files are stored in `/<keyboard>/` (name follows the same format as above) which are served at `http://qmk.fm/<keyboard>/`, and pages are generated from `/_pages/<keyboard>/` which are served at the same location (.md files are generated into .html files through Jekyll). Check out the `lets_split`directory for an example.
Hardware files (such as plates, cases, pcb) can be contributed to the [qmk.fm repo](https://github.com/qmk/qmk.fm) and they will be made available on [qmk.fm](http://qmk.fm). Downloadable files are stored in `/<keyboard>/` (name follows the same format as above) which are served at `http://qmk.fm/<keyboard>/`, and pages are generated from `/_pages/<keyboard>/` which are served at the same location (.md files are generated into .html files through Jekyll). Check out the `lets_split`folder for an example.
## Keyboard Defaults
@@ -32,77 +116,6 @@ If your keyboard does not have 2 shift keys you should provide a working default
As documented on [Customizing Functionality](custom_quantum_functions.md) you can define custom functions for your keyboard. Please keep in mind that your users may want to customize that behavior as well, and make it possible for them to do that. If you are providing a custom function, for example `process_record_kb()`, make sure that your function calls the `_user()` version of the call too. You should also take into account the return value of the `_user()` version, and only run your custom code if the user returns `true`.
## Keyboard Metadata
As QMK grows so does the ecosystem surrounding QMK. To make it easier for projects in that ecosystem to tie into QMK as we make changes we are developing a metadata system to expose information about keyboards in QMK.
You can create `info.json` files at every level under `qmk_firmware/keyboards/<name>` to specify this metadata. These files are combined, with more specific files overriding keys in less specific files. This means you do not need to duplicate your metadata information. For example, `qmk_firmware/keyboards/clueboard/info.json` specifies `manufacturer` and `maintainer`, while `qmk_firmware/keyboards/clueboard/66/info.json` specifies more specific information about Clueboard 66%.
### `info.json` Format
The `info.json` file is a JSON formatted dictionary with the following keys available to be set. You do not have to set all of them, merely the keys that apply to your keyboard.
*`keyboard_name`
* A free-form text string describing the keyboard.
* Example: `Clueboard 66%`
*`url`
* A URL to the keyboard's product page, [QMK.fm/keyboards](https://qmk.fm/keyboards) page, or other page describing information about the keyboard.
*`maintainer`
* GitHub username of the maintainer, or `qmk` for community maintained boards
*`width`
* Width of the board in Key Units
*`height`
* Height of the board in Key Units
*`layouts`
* Physical Layout representations. See the next section for more detail.
#### Layout Format
Within our `info.json` file the `layouts` portion of the dictionary contains several nested dictionaries. The outer layer consists of QMK layout macros, for example `LAYOUT_ansi` or `LAYOUT_iso`. Within each layout macro are keys for `width`, `height`, and `key_count`, each of which should be self-explanatory.
*`width`
* Optional: The width of the layout in Key Units
*`height`
* Optional: The height of the layout in Key Units
*`key_count`
* **Required**: The number of keys in this layout
*`layout`
* A list of Key Dictionaries describing the physical layout. See the next section for more details.
#### Key Dictionary Format
Each Key Dictionary in a layout describes the physical properties of a key. If you are familiar with the Raw Code for <http://keyboard-layout-editor.com> you will find many of the concepts the same. We re-use the same key names and layout choices wherever possible, but unlike keyboard-layout-editor each key is stateless, inheriting no properties from the keys that came before it.
All key positions and rotations are specified in relation to the top-left corner of the keyboard, and the top-left corner of each key.
*`X`
* **Required**: The absolute position of the key in the horizontal axis, in Key Units.
*`Y`
* **Required**: The absolute position of the key in the vertical axis, in Key Units.
*`W`
* The width of the key, in Key Units. Ignored if `ks` is provided. Default: `1`
*`H`
* The height of the key, in Key Units. Ignored if `ks` is provided. Default: `1`
*`R`
* How many degrees clockwise to rotate the key.
*`RX`
* The absolute position of the point to rotate the key around in the horizontal axis. Default: `x`
*`RY`
* The absolute position of the point to rotate the key around in the vertical axis. Default: `y`
*`KS`
* Key Shape: define a polygon by providing a list of points, in Key Units.
* **Important**: These are relative to the top-left of the key, not absolute.
* Example ISO Enter: `[ [0,0], [1.5,0], [1.5,2], [0.25,2], [0.25,1], [0,1], [0,0] ]`
### How is the Metadata Exposed?
This metadata is primarily used in two ways:
* To allow web-based configurators to dynamically generate UI
* To support the new `make keyboard:keymap:qmk` target, which bundles this metadata up with the firmware to allow QMK Toolbox to be smarter.
Configurator authors can see the [QMK Compiler](https://docs.compile.qmk.fm/api_docs.html) docs for more information on using the JSON API.
## Non-Production/Handwired Projects
We're happy to accept any project that uses QMK, including prototypes and handwired ones, but we have a separate `/keyboards/handwired/` folder for them, so the main `/keyboards/` folder doesn't get overcrowded. If a prototype project becomes a production project at some point in the future, we'd be happy to move it to the main `/keyboards/` folder!
@@ -12,7 +12,7 @@ The I2C Master drivers used in QMK have a set of common functions to allow porta
|`uint8_t i2c_receive(uint8_t address, uint8_t* data, uint16_t length, uint16_t timeout);` |Receive data over I2C. Address is the 7-bit slave address without the direction. Saves number of bytes specified by `length` in `data` array. Returns status of transaction. |
|`uint8_t i2c_writeReg(uint8_t devaddr, uint8_t regaddr, uint8_t* data, uint16_t length, uint16_t timeout);` |Same as the `i2c_transmit` function but `regaddr` sets where in the slave the data will be written. |
|`uint8_t i2c_readReg(uint8_t devaddr, uint8_t regaddr, uint8_t* data, uint16_t length, uint16_t timeout);` |Same as the `i2c_receive` function but `regaddr` sets from where in the slave the data will be read. |
|`uint8_t i2c_stop(uint16_t timeout);`|Stops the I2C driver. |
|`uint8_t i2c_stop(void);` |Ends an I2C transaction. |
### Function Return
@@ -33,8 +33,8 @@ The following defines can be used to configure the I2C master driver.
|`#Prescaler` |Divides master clock to aid in I2C clock selection |1 |
|`F_SCL` |Clock frequency in Hz |400KHz |
|`Prescaler` |Divides master clock to aid in I2C clock selection |1 |
AVRs usually have set GPIO which turn into I2C pins, therefore no further configuration is required.
@@ -63,20 +63,24 @@ Lastly, we need to assign the correct GPIO pins depending on the I2C hardware dr
By default the I2C1 hardware driver is assumed to be used. If another hardware driver is used, `#define I2C_DRIVER I2CDX` should be added to the `config.h` file with X being the number of hardware driver used. For example is I2C3 is enabled, the `config.h` file should contain `#define I2C_DRIVER I2CD3`. This aligns the QMK I2C driver with the Chibios I2C driver.
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.
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:
This can be changed by declaring the `i2c_init` function which intentionally has a weak attribute. Please consult the datasheet of your MCU for the available GPIO configurations. The following is an example initialization function:
| `I2C1_BANK` | The bank of pins (`GPIOA`, `GPIOB`, `GPIOC`) | `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` |
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:
```C
voidi2c_init(void)
{
setPinInput(B6);// Try releasing special pins for a short time
setPinInput(B7);
chThdSleepMilliseconds(10);// Wait for the release to happen
wait_ms(10);// Wait for the release to happen
palSetPadMode(GPIOB,6,PAL_MODE_ALTERNATE(4)|PAL_STM32_OTYPE_OPENDRAIN|PAL_STM32_PUPDR_PULLUP);// Set B6 to I2C function
palSetPadMode(GPIOB,7,PAL_MODE_ALTERNATE(4)|PAL_STM32_OTYPE_OPENDRAIN|PAL_STM32_PUPDR_PULLUP);// Set B7 to I2C function
QMK has a GPIO control abstraction layer which is micro-controller agnostic. This is done to allow easy access to pin control across different platforms.
QMK has a GPIO control abstraction layer which is microcontroller agnostic. This is done to allow easy access to pin control across different platforms.
## Functions
@@ -17,7 +17,7 @@ The following functions can provide basic control of GPIOs and are found in `qua
|`writePin(pin, level)`|Set pin level, assuming it is an output |
|`readPin(pin)` |Returns the level of the pin |
## Advance settings
## Advanced Settings
Each micro-controller can have multiple advance settings regarding its GPIO. This abstraction layer does not limit the use of architecturespecific functions. Advance users should consult the datasheet of there desired device and include any needed libraries. For AVR the standard avr/io.h library is used and for STM32 the Chibios [PAL library](http://chibios.sourceforge.net/docs3/hal/group___p_a_l.html) is used.
Each microcontroller can have multiple advanced settings regarding its GPIO. This abstraction layer does not limit the use of architecture-specific functions. Advanced users should consult the datasheet of their desired device and include any needed libraries. For AVR, the standard avr/io.h library is used; for STM32, the ChibiOS [PAL library](http://chibios.sourceforge.net/docs3/hal/group___p_a_l.html) is used.
@@ -53,7 +53,7 @@ This is pretty straight-forward - we'll be connecting like-things to like-things
The only difference between the .hex files below is which pin is connected to RESET. You can use them on other boards as well, as long as you're aware of the pins being used. If for some reason neither of these pins are available, [create an issue](https://github.com/qmk/qmk_firmware/issues/new), and we can generate one for you!
If you're not sure what your board uses, look in the `rules.mk` file for the keyboard in QMK. The `MCU =` line will have the value you need. It may differ between different versions of the board.
@@ -113,6 +114,10 @@ Since our keyboard uses an `atmega32u4` (common), that is the chip we'll specify
@@ -293,7 +290,7 @@ This is a reference only. Each group of keys links to the page documenting their
|`DF(layer)` |Set the base (default) layer |
|`MO(layer)` |Momentarily turn on `layer` when pressed (requires `KC_TRNS` on destination layer)|
|`OSL(layer)` |Momentarily activates `layer` until a key is pressed. See [One Shot Keys](https://docs.qmk.fm/#/feature_advanced_keycodes?id=one-shot-keys) for details. |
|`LM(layer, mod)`|Momentarily turn on `layer` (like MO) with `mod` active as well.
|`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 |
@@ -322,43 +319,43 @@ 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 |
|`RCTL_T(kc)`| |Right Control when held, `kc` when tapped |
|`LSFT_T(kc)`|`SFT_T(kc)` |Left Shift when held, `kc` when tapped |
|`RSFT_T(kc)`| |Right Shift when held, `kc` when tapped |
|`LALT_T(kc)`|`ALT_T(kc)`|Left Alt when held, `kc` when tapped |
|`RALT_T(kc)`|`ALGR_T(kc)` |Right Alt when held, `kc` when tapped |
|`LGUI_T(kc)`|`LCMD_T(kc)`, `RWIN_T(kc)`, `GUI_T(kc)`|Left GUI when held, `kc` when tapped |
|`RGUI_T(kc)`|`RCMD_T(kc)`, `RWIN_T(kc)` |Right 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|
|`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 |
|`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/)|
|`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 |
|`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)
@@ -439,7 +436,6 @@ This is a reference only. Each group of keys links to the page documenting their
|`OSM(mod)` |Hold `mod` for one keypress |
|`OSL(layer)`|Switch to `layer` for one keypress|
## [Swap Hands](feature_swap_hands.md)
|Key |Description |
@@ -454,7 +450,7 @@ This is a reference only. Each group of keys links to the page documenting their
QMK keymaps are defined inside a C source file. The data structure is an array of arrays. The outer array is a list of layer arrays while the inner layer array is a list of keys. Most keyboards define a `KEYMAP()` macro to help you create this array of arrays.
QMK keymaps are defined inside a C source file. The data structure is an array of arrays. The outer array is a list of layer arrays while the inner layer array is a list of keys. Most keyboards define a `LAYOUT()` macro to help you create this array of arrays.
## Keymap and Layers
@@ -119,7 +119,7 @@ The main part of this file is the `keymaps[]` definition. This is where you list
> This `fn_actions[]` interface is mostly for backward compatibility. In QMK, you don't need to use `fn_actions[]`. You can directly use `ACTION_FUNCTION(N)` or any other action code value itself normally generated by the macro in `keymaps[][MATRIX_ROWS][MATRIX_COLS]`. N in `F(N)` can only be 0 to 31. Use of the action code directly in `keymaps` unlocks this limitation.
The [QMK Configurator](https://config.qmk.fm) is an online graphical user interface that generates QMK Firmware hex files.
?> **Please follow these steps in order.**
Watch the [Video Tutorial](https://youtu.be/7RH-1pAbjvw)
The QMK Configurator works best with Chrome/Firefox.
!> **Files from other tools such as KLE, or kbfirmware will not be compatible with QMK Configurator. Do not load them, do not import them. QMK Configurator is a DIFFERENT tool. **
## Selecting your keyboard
Click the drop down box and select the keyboard you want to create a keymap for.
?> If your keyboard has several versions, make sure you select the correct one.**
I'll say that again because it's important
!> **MAKE SURE YOU SELECT THE RIGHT VERSION!**
If your keyboard has been advertised to be powered by QMK but is not in the list, chances are a developer hasn't gotten to it yet or we haven't had a chance to merge it in yet. File an issue at [qmk_firmware](https://github.com/qmk/qmk_firmware/issues) requesting to support that particular keyboard, if there is no active [Pull Request](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+is%3Apr+label%3Akeyboard) for it. There are also QMK powered keyboards that are in their manufacturer's own github accounts. Double check for that as well.
## Selecting your keyboard layout
Choose the layout that best represents the keymap you want to create. Some keyboards do not have enough layouts or correct layouts defined yet. They will be supported in the future.
## Keymap Name
Call this keymap what you want.
?> If you are running into issues when compiling, it may be worth changing this name, as it may already exist in the QMK Firmware repo.
## Creating Your Keymap
Keycode Entry is accomplished in 3 ways.
1. Drag and dropping
2. Clicking on an empty spot on the layout and clicking the keycode you desire
3. Clicking on an empty spot on the layout, pressing the physical key on your keyboard.
Hover your mouse over a key and a short blurb will tell you what that keycode does. For a more verbose description please see
In the event that you can't find a layout that supports your keymap, for example three spots for spacebar, or two spots for backspace, or 2 spots for shift etc etc, Fill them ALL up.
### Example:
3 spots for spacebar: Fill them ALL with spacebar
2 spots for backspace: Fill them BOTH with backspace
2 spots for right shift: Fill them BOTH with right shift
1 spot for left shift and 1 spot for iso support: Fill them both with left shift
5 spots, but only 4 keys: Guess and check or ask someone who has done it before.
## Saving Your Keymap for Future Edits
When you're satisfied with your keymap or just want to work on it later, press the `Export Keymap` button. It will save your keymap as the name you chose above appended with .json.
You can then load this .json file in the future by pressing the `Import Keymap` button.
!> **CAUTION:** This is not the same type of .json file used for kbfirmware.com or any other tool. If you try to use this for those tools, or the .json from those tools with QMK Configurator, there is a chance your keyboard will **explode**.
## Generating your firmware file
Press the green `Compile` button.
When the compilation is done, you will be able to press the green `Download Firmware` button.
## Flashing Your Keyboard
Please refer to [Flashing Firmware](newbs_flashing.md)
## Troubleshooting
#### My .json file is not working
If the .json file was generated with QMK Configurator, congratulations you have stumbled upon a bug. File an issue at [qmk_configurator](https://github.com/qmk/qmk_configurator/issues)
If not....how did you miss my big bold message at the top saying not to use other .json files?
#### There are extra spaces in my layout? What do I do?
If you're referring to having three spots for space bar, the best course of action is to just fill them all with space bar. The same can be done for backspace and shifts
@@ -86,7 +86,7 @@ If you know what bootloader that you're using, then when compiling the firmware,
### DFU
For the DFU bootloader, when you're ready to compile and flash your firmware, open up your terminal window and run the built command:
For the DFU bootloader, when you're ready to compile and flash your firmware, open up your terminal window and run the build command:
make <my_keyboard>:<my_keymap>:dfu
@@ -131,9 +131,19 @@ If you have any issues with this, you may need to this:
sudo make <my_keyboard>:<my_keymap>:dfu
#### DFU commands
There are a number of DFU commands that you can use to flash firmware to a DFU device:
* `:dfu` - This is the normal option and waits until a DFU device is available, and then flashes the firmware. This will check every 5 seconds, to see if a DFU device has appeared.
* `:dfu-ee` - This flashes an `eep` file instead of the normal hex. This is uncommon.
* `:dfu-split-left` - This flashes the normal firmware, just like the default option (`:dfu`). However, this also flashes the "Left Side" EEPROM file for split keyboards. _This is ideal for Elite C based split keyboards._
* `:dfu-split-right` - This flashes the normal firmware, just like the default option (`:dfu`). However, this also flashes the "Right Side" EEPROM file for split keyboards. _This is ideal for Elite C based split keyboards._
### Caterina
For Arduino boards and their close (such as the SparkFun ProMicro), when you're ready to compile and flash your firmware, open up your terminal window and run the built command:
For Arduino boards and their clones (such as the SparkFun ProMicro), when you're ready to compile and flash your firmware, open up your terminal window and run the build command:
make <my_keyboard>:<my_keymap>:avrdude
@@ -199,9 +209,17 @@ If you have any issues with this, you may need to this:
sudo make <my_keyboard>:<my_keymap>:avrdude
Additionally, if you want to flash multiple boards, use the following command:
make <keyboard>:<keymap>:avrdude-loop
When you're done flashing boards, you'll need to hit Ctrl + C or whatever the correct keystroke is for your operating system to break the loop.
## HalfKay
For the PJRC devices (Teensy's), when you're ready to compile and flash your firmware, open up your terminal window and run the built command:
For the PJRC devices (Teensy's), when you're ready to compile and flash your firmware, open up your terminal window and run the build command:
make <my_keyboard>:<my_keymap>:teensy
@@ -226,12 +244,61 @@ Waiting for Teensy device...
For a majority of ARM boards (including the Proton C, Planck Rev 6, and Preonic Rev 3), when you're ready to compile and flash your firmware, open up your terminal window and run the build command:
make <my_keyboard>:<my_keymap>:dfu-util
For example, if your keymap is named "xyverz" and you're building a keymap for the Planck Revision 6 keyboard, you'll use this command and then reboot the keyboard to the bootloader (before it finishes compiling):
make planck/rev6:xyverz:dfu-util
Once the firmware finishes compiling, it will output something like this:
```
Linking: .build/planck_rev6_xyverz.elf [OK]
Creating binary load file for flashing: .build/planck_rev6_xyverz.bin [OK]
Creating load file for flashing: .build/planck_rev6_xyverz.hex [OK]
@@ -6,7 +6,10 @@ QMK tries to put a lot of power into your hands by making easy things easy, and
# Getting Started
Before you can build keymaps, you need to install some software and set up your build environment. This only has to be done once no matter how many keyboards you plan to compile firmware for.
Before you can build keymaps, you need to install some software and set up your build environment. This only has to be done once no matter how many keyboards you plan to compile firmware for.
If you would prefer a more graphical user interface approach, please consider using the online [QMK Configurator](https://config.qmk.fm). Please refer to [Building Your First Firmware using the online GUI](newbs_building_firmware_configurator.md).
## Download Software
@@ -63,8 +66,10 @@ You will need to install Git. It's very likely that you already have it, but if
Once you have set up your Linux/Unix environment, you are ready to download QMK. We will do this by using Git to "clone" the QMK repository. Open a Terminal or MSYS2 MinGW window and leave it open for the remainder of this guide. Inside that window run these two commands:
?> If you already know [how to use GitHub](getting_started_github.md), we recommend that you create and clone your own fork instead. If you don't know what that means, you can safely ignore this message.
@@ -15,7 +15,17 @@ Note: These programs are not provided by or endorsed by QMK.
## Debugging With QMK Toolbox
[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, or use the [Command](feature_command.md) feature to enable debug mode.
[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.
```c
voidkeyboard_post_init_user(void){
// Customise these values to desired behaviour
debug_enable=true;
debug_matrix=true;
//debug_keyboard=true;
//debug_mouse=true;
}
```
<!-- FIXME: Describe the debugging messages here. -->
# Setting up Visual Studio Code for QMK Development
[Visual Studio Code](https://code.visualstudio.com/) (VS Code) is an open-source code editor that supports many different programming languages.
Using a full-featured editor such as VS Code provides many advantages over a plain text editor, such as:
* intelligent code completion
* convenient navigation in the code
* refactoring tools
* build automation (no need for the command-line)
* a graphical front end for GIT
* many other tools such as debugging, code formatting, showing call hierarchies etc.
The purpose of this page is to document how to set up VS Code for developing QMK Firmware.
This guide covers how to configure everything needed on Windows and Ubuntu 18.04
# Set up VS Code
Before starting, you will want to make sure that you have all of the build tools set up, and QMK Firmware cloned. Head to the the [Newbs Getting Started Guide](newbs_getting_started.md) to get things set up, if you haven't already.
## Windows
### Prerequisites
* [Git for Windows](https://git-scm.com/download/win) (This link will prompt to save/run the installer)
1. Disable all of the options but `Git LFS (Large File Support)` and `Check daily for Git for Windows updates`.
2. Set the default editor to `Use Visual Studio Code as Git's default editor`
3. Select the `Use Git from Git Bash only` option, since that's the option that you should use here.
4. For the `Choosing HTTPS transport backend`, either option should be fine.
5. Select the `Checkout as-is, commit Unix-style line endings` option. QMK Firmware uses Unix style commits.
6. For the extra options, leave the default options as is.
This software is needed for Git support in VS Code. It may be possible to not include this, but it is much simpler to just use this.
* [Git Credential Manager for Windows](https://github.com/Microsoft/Git-Credential-Manager-for-Windows/releases) (Optional)
This software provides better support for Git by providing secure storage for git credentials, MFA and personal access token generation.
This isn't strictly needed, but we would recommend it.
### Installing VS Code
1. Head to [VS Code](https://code.visualstudio.com/) and download the installer
2. Run the installer
This part is super simple. However, there is some configuration that we need to do to ensure things are configured correctly.
### Configuring VS Code
First, we need to set up IntelliSense. This isn't strictly required, but it will make your life a LOT easier. To do this, we need to create the `.vscode/c_cpp_properies.json` file in the QMK Firmware folder, You can do this all manually, but I've done most of the work already.
Grab [this file](https://gist.github.com/drashna/48e2c49ce877be592a1650f91f8473e8) and save it. You may need to edit this file, if you didn't install MSYS2 to the default location, or are using WSL/LxSS.
Once you have saved this file, you will need to reload VS Code, if it was already running.
?> You should see an `extensions.json` and `settings.json` file in the `.vscode` folder, as well.
Now, we will set up the MSYS2 window to show up in VSCode as the integrated terminal. This has a number of advantages. Mostly, you can control+click on errors and jump to those files. This makes debugging much easier. It's also nice, in that you don't have to jump to another window.
If there are settings here already, then just add everything between the first and last curly brackets.
?> If you installed MSYS2 to a different folder, then you'll need to change the path for `terminal.integrated.shell.windows` to the correct path for your system.
4. Hit Ctrl-` (grave) to bring up the terminal.
This should start the terminal in the workspace's folder (so the `qmk_firmware` folder), and then you can compile your keyboard.
## Every other Operating System
1. Head to [VS Code](https://code.visualstudio.com/) and download the installer
2. Run the installer
3. That's it
No, really, that's it. The paths needed are already included when installing the packages, and it is much better about detecting the current workspace files and parsing them for IntelliSense.
## Plugins
There are a number of extensions that you may want to install:
This installs a bunch of Git related tools that may make using Git with QMK Firmware easier.
* [EditorConfig for VS Code](https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig) - _[Optional]_ - Helps to keep the code to the QMK Coding Conventions.
* [Bracket Pair Colorizer 2](https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer-2) - _[Optional]_ - This color codes the brackets in your code, to make it easier to reference nested code.
* [Github Markdown Preview](https://marketplace.visualstudio.com/items?itemName=bierner.github-markdown-preview) - _[Optional]_ - Makes the markdown preview in VS Code more like GitHub's.
* [VS Live Share Extension Pack](https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare-pack) - _[Optional]_ - This extension allows somebody else to access your workspace (or you to access somebody else's workspace) and help out. This is great if you're having issues and need some help from somebody.
* [VIM Keymap](https://marketplace.visualstudio.com/items?itemName=GiuseppeCesarano.vim-keymap) - _[Optional]_ - For those that prefer VIM style keybindings. There are other options for this, too.
* [Travis CI Status](https://marketplace.visualstudio.com/items?itemName=felixrieseberg.vsc-travis-ci-status) - _[Optional]_ - This shows the current Travis CI status, if you have it set up.
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`
@@ -22,6 +32,8 @@ The `MATRIX_ROW_PINS` and `MATRIX_COL_PINS` are the pins your MCU uses on each r
For the `DIODE_DIRECTION`, most hand-wiring guides will instruct you to wire the diodes in the `COL2ROW` position, but it's possible that they are in the other - people coming from EasyAVR often use `ROW2COL`. Nothing will function if this is incorrect.
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_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.
@@ -54,10 +66,10 @@ This is where all of the custom logic for your keyboard goes - you may not need
## `/keyboards/<keyboard>/<keyboard>.h`
Here is where you can (optionally) define your `KEYMAP` function to remap your matrix into a more readable format. With ortholinear boards, this isn't always necessary, but it can help to accommodate the dead spots on your matrix, where there are keys that take up more than one space (2u, staggering, 6.25u, etc). The example shows the difference between the physical keys, and the matrix design:
Here is where you can (optionally) define your `LAYOUT` function to remap your matrix into a more readable format. With ortholinear boards, this isn't always necessary, but it can help to accommodate the dead spots on your matrix, where there are keys that take up more than one space (2u, staggering, 6.25u, etc). The example shows the difference between the physical keys, and the matrix design:
If a board currently supported in QMK uses a Pro Micro (or compatible board) and you want to use the Proton C, you can generate the firmware by appending `CONVERT_TO_PROTON_C=yes` (or `CTPC=yes`) to your make argument, like this:
make 40percentclub/mf68:default CTPC=yes
You can add the same argument to your keymap's `rules.mk`, which will accomplish the same thing.
This exposes the `CONVERT_TO_PROTON_C` flag that you can use in your code with `#ifdef`s, like this:
#ifdef CONVERT_TO_PROTON_C
// Proton C code
#else
// Pro Micro code
#endif
Before being able to compile, you may get some errors about `PORTB/DDRB`, etc not being defined, so you'll need to convert the keyboard's code to use the [GPIO Controls](internals_gpio_control.md) that will work for both ARM and AVR. This shouldn't affect the AVR builds at all.
The Proton C only has one on-board LED (C13), and by default, the TXLED (D5) is mapped to it. If you want the RXLED (B0) mapped to it instead, add this like to your `config.h`:
This file is used by the [QMK API](https://github.com/qmk/qmk_api). It contains the information [QMK Configurator](https://config.qmk.fm/) needs to display a representation of your keyboard. You can also set metadata here.
You can create `info.json` files at every level under `qmk_firmware/keyboards/<name>` to specify this metadata. These files are combined, with more specific files overriding keys in less specific files. This means you do not need to duplicate your metadata information. For example, `qmk_firmware/keyboards/clueboard/info.json` specifies `manufacturer` and `maintainer`, while `qmk_firmware/keyboards/clueboard/66/info.json` specifies more specific information about Clueboard 66%.
## `info.json` Format
The `info.json` file is a JSON formatted dictionary with the following keys available to be set. You do not have to set all of them, merely the keys that apply to your keyboard.
*`keyboard_name`
* A free-form text string describing the keyboard.
* Example: `Clueboard 66%`
*`url`
* A URL to the keyboard's product page, [QMK.fm/keyboards](https://qmk.fm/keyboards) page, or other page describing information about the keyboard.
*`maintainer`
* GitHub username of the maintainer, or `qmk` for community maintained boards
*`width`
* Width of the board in Key Units
*`height`
* Height of the board in Key Units
*`layouts`
* Physical Layout representations. See the next section for more detail.
### Layout Format
Within our `info.json` file the `layouts` portion of the dictionary contains several nested dictionaries. The outer layer consists of QMK layout macros, for example `LAYOUT_ansi` or `LAYOUT_iso`. Within each layout macro are keys for `width`, `height`, and `key_count`, each of which should be self-explanatory.
*`width`
* Optional: The width of the layout in Key Units
*`height`
* Optional: The height of the layout in Key Units
*`key_count`
* **Required**: The number of keys in this layout
*`layout`
* A list of Key Dictionaries describing the physical layout. See the next section for more details.
### Key Dictionary Format
Each Key Dictionary in a layout describes the physical properties of a key. If you are familiar with the Raw Code for <http://keyboard-layout-editor.com> you will find many of the concepts the same. We re-use the same key names and layout choices wherever possible, but unlike keyboard-layout-editor each key is stateless, inheriting no properties from the keys that came before it.
All key positions and rotations are specified in relation to the top-left corner of the keyboard, and the top-left corner of each key.
*`x`
* **Required**: The absolute position of the key in the horizontal axis, in Key Units.
*`y`
* **Required**: The absolute position of the key in the vertical axis, in Key Units.
*`w`
* The width of the key, in Key Units. Ignored if `ks` is provided. Default: `1`
*`h`
* The height of the key, in Key Units. Ignored if `ks` is provided. Default: `1`
*`r`
* How many degrees clockwise to rotate the key.
*`rx`
* The absolute position of the point to rotate the key around in the horizontal axis. Default: `x`
*`ry`
* The absolute position of the point to rotate the key around in the vertical axis. Default: `y`
*`ks`
* Key Shape: define a polygon by providing a list of points, in Key Units.
* **Important**: These are relative to the top-left of the key, not absolute.
* Example ISO Enter: `[ [0,0], [1.5,0], [1.5,2], [0.25,2], [0.25,1], [0,1], [0,0] ]`
*`label`
* What to name this position in the matrix.
* This should usually be the same name as what is silkscreened on the PCB at this location.
## How is the Metadata Exposed?
This metadata is primarily used in two ways:
* To allow web-based configurators to dynamically generate UI
* To support the new `make keyboard:keymap:qmk` target, which bundles this metadata up with the firmware to allow QMK Toolbox to be smarter.
Configurator authors can see the [QMK Compiler](https://docs.api.qmk.fm/using-the-api) docs for more information on using the JSON API.
@@ -12,7 +12,7 @@ You can think of QMK as no different from any other computer program. It is star
The reason for this is the different platforms that QMK supports. The most common platform is `lufa`, which runs on AVR processors such at the atmega32u4. We also support `chibios` and `vusb`.
We'll focus on AVR processors for the moment, which use the `lufa` platform. You can find the `main()` function in [tmk_core/protocol/lufa/lufa.c](https://github.com/qmk/qmk_firmware/blob/661ca4440cc42f3b60697e98985c44b0571ccfc1/tmk_core/protocol/lufa/lufa.c#L1019). If you browse through that function you'll find that it initializes any hardware that has been configured (including USB to the host) and then it starts the core part of the program with a [`while(1)`](https://github.com/qmk/qmk_firmware/blob/661ca4440cc42f3b60697e98985c44b0571ccfc1/tmk_core/protocol/lufa/lufa.c#L1060). This is [The Main Loop](#the-main-loop).
We'll focus on AVR processors for the moment, which use the `lufa` platform. You can find the `main()` function in [tmk_core/protocol/lufa/lufa.c](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/tmk_core/protocol/lufa/lufa.c#L1028). If you browse through that function you'll find that it initializes any hardware that has been configured (including USB to the host) and then it starts the core part of the program with a [`while(1)`](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/tmk_core/protocol/lufa/lufa.c#L1069). This is [The Main Loop](#the-main-loop).
## The Main Loop
@@ -22,7 +22,7 @@ This section of code is called "The Main Loop" because it's responsible for loop
keyboard_task();
```
This is where all the keyboard specific functionality is dispatched. The source code for `keyboard_task()` can be found in [tmk_core/common/keyboard.c](https://github.com/qmk/qmk_firmware/blob/661ca4440cc42f3b60697e98985c44b0571ccfc1/tmk_core/common/keyboard.c#L206), and it is responsible for detecting changes in the matrix and turning status LED's on and off.
This is where all the keyboard specific functionality is dispatched. The source code for `keyboard_task()` can be found in [tmk_core/common/keyboard.c](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/tmk_core/common/keyboard.c#L216), and it is responsible for detecting changes in the matrix and turning status LED's on and off.
Within `keyboard_task()` you'll find code to handle:
@@ -57,10 +57,10 @@ Matrix Scanning runs many times per second. The exact rate varies but typically
Once we know the state of every switch on our keyboard we have to map that to a keycode. In QMK this is done by making use of C macros to allow us to separate the definition of the physical layout from the definition of keycodes.
At the keyboard level we define a C macro (typically named `KEYMAP()`) which maps our keyboard's matrix to physical keys. Sometimes the matrix does not have a switch in every location, and we can use this macro to pre-populate those with KC_NO, making the keymap definition easier to work with. Here's an example `KEYMAP()` macro for a numpad:
At the keyboard level we define a C macro (typically named `LAYOUT()`) which maps our keyboard's matrix to physical keys. Sometimes the matrix does not have a switch in every location, and we can use this macro to pre-populate those with KC_NO, making the keymap definition easier to work with. Here's an example `LAYOUT()` macro for a numpad:
```c
#define KEYMAP( \
#define LAYOUT( \
k00, k01, k02, k03, \
k10, k11, k12, k13, \
k20, k21, k22, \
@@ -75,17 +75,17 @@ At the keyboard level we define a C macro (typically named `KEYMAP()`) which map
}
```
Notice how the second block of our `KEYMAP()` macro matches the Matrix Scanning array above? This macro is what will map the matrix scanning array to keycodes. However, if you look at a 17 key numpad you'll notice that it has 3 places where the matrix could have a switch but doesn't, due to larger keys. We have populated those spaces with `KC_NO` so that our keymap definition doesn't have to.
Notice how the second block of our `LAYOUT()` macro matches the Matrix Scanning array above? This macro is what will map the matrix scanning array to keycodes. However, if you look at a 17 key numpad you'll notice that it has 3 places where the matrix could have a switch but doesn't, due to larger keys. We have populated those spaces with `KC_NO` so that our keymap definition doesn't have to.
You can also use this macro to handle unusual matrix layouts, for example the [Clueboard rev 2](https://github.com/qmk/qmk_firmware/blob/661ca4440cc42f3b60697e98985c44b0571ccfc1/keyboards/clueboard/66/rev2/rev2.h). Explaining that is outside the scope of this document.
You can also use this macro to handle unusual matrix layouts, for example the [Clueboard rev 2](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/keyboards/clueboard/66/rev2/rev2.h). Explaining that is outside the scope of this document.
##### Keycode Assignment
At the keymap level we make use of our `KEYMAP()` macro above to map keycodes to physical locations to matrix locations. It looks like this:
At the keymap level we make use of our `LAYOUT()` macro above to map keycodes to physical locations to matrix locations. It looks like this:
Notice how all of these arguments match up with the first half of the `KEYMAP()` macro from the last section? This is how we take a keycode and map it to our Matrix Scan from earlier.
Notice how all of these arguments match up with the first half of the `LAYOUT()` macro from the last section? This is how we take a keycode and map it to our Matrix Scan from earlier.
##### State Change Detection
@@ -130,31 +130,35 @@ Comparing against our keymap we can see that the pressed key is KC_NLCK. From he
##### Process Record
The `process_record()` function itself is deceptively simple, but hidden within is a gateway to overriding functionality at various levels of QMK. The chain of events is listed below, using cluecard whenever we need to look at the keyboard/keymap level functions. Depending on options set in rule.mk or elsewhere, only a subset of the functions below will be included in final firmware.
The `process_record()` function itself is deceptively simple, but hidden within is a gateway to overriding functionality at various levels of QMK. The chain of events is listed below, using cluecard whenever we need to look at the keyboard/keymap level functions. Depending on options set in `rules.mk` or elsewhere, only a subset of the functions below will be included in final firmware.
* [Identify and process quantum specific keycodes](https://github.com/qmk/qmk_firmware/blob/661ca4440cc42f3b60697e98985c44b0571ccfc1/quantum/quantum.c#L287)
* [Identify and process Quantum-specific keycodes](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/quantum/quantum.c#L291)
At any step during this chain of events a function (such as `process_record_kb()`) can `return false` to halt all further processing.
//IS31FL3737_write_register(addr2, i, g_led_control_registers[1][i] );
}
}
}
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.