* 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.
- [ ] 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.
* pins mapped to rows and columns, from left to right. Defines a matrix where each switch is connected to a separate pin and ground.
*`#define AUDIO_VOICES`
* turns on the alternate audio voices (to cycle through)
*`#define C4_AUDIO`
@@ -68,11 +70,11 @@ This is a C header file that is one of the first things included, and will persi
*`#define C6_AUDIO`
* enables audio on pin C6
*`#define B5_AUDIO`
* enables audio on pin B5 (duophony is enables if one of B[5-7]_AUDIO is enabled along with one of C[4-6]_AUDIO)
* enables audio on pin B5 (duophony is enables if one of B[5-7]\_AUDIO is enabled along with one of C[4-6]\_AUDIO)
*`#define B6_AUDIO`
* enables audio on pin B6 (duophony is enables if one of B[5-7]_AUDIO is enabled along with one of C[4-6]_AUDIO)
* enables audio on pin B6 (duophony is enables if one of B[5-7]\_AUDIO is enabled along with one of C[4-6]\_AUDIO)
*`#define B7_AUDIO`
* enables audio on pin B7 (duophony is enables if one of B[5-7]_AUDIO is enabled along with one of C[4-6]_AUDIO)
* enables audio on pin B7 (duophony is enables if one of B[5-7]\_AUDIO is enabled along with one of C[4-6]\_AUDIO)
*`#define BACKLIGHT_PIN B7`
* pin of the backlight - B5, B6, B7 use PWM, others use softPWM
*`#define BACKLIGHT_LEVELS 3`
@@ -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
@@ -171,11 +175,15 @@ 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 RGBLED_SPLIT { 6, 6 }`
* number of LEDs connected that are directly wired to `RGB_DI_PIN` on each half of a split keyboard
* First value indicates number of LEDs for left half, second value is for the right half
* Needed if both halves of the board have 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 RGBLIGHT_HUE_STEP 12`
* units to step when in/decreasing hue
*`#define RGBLIGHT_SAT_STEP 25`
@@ -208,9 +216,13 @@ There are a few different ways to set handedness for split keyboards (listed in
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 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.
@@ -232,6 +244,9 @@ There are a few different ways to set handedness for split keyboards (listed in
*`#define MATRIX_COL_PINS_RIGHT { <col pins> }`
* If you want to specify a different pinout for the right half than the left half, you can define `MATRIX_ROW_PINS_RIGHT`/`MATRIX_COL_PINS_RIGHT`. Currently, the size of `MATRIX_ROW_PINS` must be the same as `MATRIX_ROW_PINS_RIGHT` and likewise for the definition of columns.
*`#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:
@@ -307,8 +322,8 @@ Use these to enable or disable building certain features. The more you have enab
* 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.
*`CUSTOM_DEBOUNCE`
* Allows replacing the standard key debouncing 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%`)
@@ -116,29 +116,29 @@ Use the `IS_LED_ON(usb_led, led_name)` and `IS_LED_OFF(usb_led, led_name)` macro
```c
voidled_set_user(uint8_tusb_led){
if(IS_LED_ON(usb_led,USB_LED_NUM_LOCK)){
PORTB|=(1<<0);
writePinLow(B0);
}else{
PORTB&=~(1<<0);
writePinHigh(B0);
}
if(IS_LED_ON(usb_led,USB_LED_CAPS_LOCK)){
PORTB|=(1<<1);
writePinLow(B1);
}else{
PORTB&=~(1<<1);
writePinHigh(B1);
}
if(IS_LED_ON(usb_led,USB_LED_SCROLL_LOCK)){
PORTB|=(1<<2);
writePinLow(B2);
}else{
PORTB&=~(1<<2);
writePinHigh(B2);
}
if(IS_LED_ON(usb_led,USB_LED_COMPOSE)){
PORTB|=(1<<3);
writePinLow(B3);
}else{
PORTB&=~(1<<3);
writePinHigh(B3);
}
if(IS_LED_ON(usb_led,USB_LED_KANA)){
PORTB|=(1<<4);
writePinLow(B4);
}else{
PORTB&=~(1<<4);
writePinHigh(B4);
}
}
```
@@ -165,31 +165,86 @@ In addition, it is possible to specify the brightness level of all LEDs with `er
Ergodox boards also define `LED_BRIGHTNESS_LO` for the lowest brightness and `LED_BRIGHTNESS_HI` for the highest brightness (which is the default).
# Matrix Initialization Code
# Keyboard Initialization Code
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 LEDs or i²c controllers you will need to set up that hardware before it can be used.
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.
### Example `matrix_init_user()` Implementation
*`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.
This example, at the keyboard level, sets up B1, B2, and B3 as LED pins.
!> 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.
@@ -217,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)
@@ -285,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{
@@ -304,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
@@ -324,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
@@ -413,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
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,11 +11,11 @@ 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.
@@ -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 */
@@ -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.
| 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 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 all 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|
For an example, see [the mouse layer in this keymap](https://github.com/qmk/qmk_firmware/blob/1df10ae3bfc146805c75b06dc0c126cd1ef3a60a/keyboards/clueboard/66/keymaps/mouse_keys/keymap.c#L40).
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
## Configuring mousekeys
## Configuring the Behavior of Mousekeys
Mouse keys supports two different modes to move the cursor:
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).
* **Accelerated (default):** Holding movement keys accelerates the cursor until it reaches its maximum speed.
* **Constant:** Holding movement keys moves the cursor at constant speeds.
```
#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
The same principle applies to scrolling.
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.
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).
---
### WS2812 (AVR only)
There is basic support for addressable RGB matrix lighting with a WS2811/WS2812{a,b,c} addressable LED strand. To enable it, add this to your `rules.mk`:
```C
RGB_MATRIX_ENABLE=WS2812
```
Configure the hardware via your `config.h`:
```C
// The pin connected to the data pin of the LEDs
#define RGB_DI_PIN D7
// The number of LEDs connected
#define DRIVER_LED_TOTAL 70
```
---
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},
....
}
```C
constrgb_ledg_rgb_leds[DRIVER_LED_TOTAL]={
/* {row | col << 4}
*|{x=0..224, y=0..64}
* ||modifier
* | | | */
{{0|(0<<4)},{20.36*0,21.33*0},1},
{{0|(1<<4)},{20.36*1,21.33*0},1},
....
}
```
The format for the matrix position used in this array is `{row | (col << 4)}`. The `x` is between (inclusive) 0-224, and `y` is between (inclusive) 0-64. The easiest way to calculate these positions is:
x =224/(NUMBER_OF_ROWS-1)*ROW_POSITION
y =64/(NUMBER_OF_COLS-1)*COL_POSITION
```C
x=224/( NUMBER_OF_COLS-1)*ROW_POSITION
y=64/(NUMBER_OF_ROWS-1)*COL_POSITION
```
Where all variables are decimels/floats.
@@ -113,47 +153,50 @@ Where all variables are decimels/floats.
All RGB keycodes are currently shared with the RGBLIGHT system:
*`RGB_TOG`- toggle
*`RGB_MOD`- cycle through modes
*`RGB_HUI`- increase hue
*`RGB_HUD`- decrease hue
*`RGB_SAI`- increase saturation
*`RGB_SAD`- decrease saturation
*`RGB_VAI`- increase value
*`RGB_VAD`- decrease value
*`RGB_SPI`- increase speed effect (no EEPROM support)
*`RGB_SPD`- decrease speed effect (no EEPROM support)
*`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:
enumrgb_matrix_effects{
RGB_MATRIX_SOLID_COLOR =1,
RGB_MATRIX_ALPHAS_MODS,
RGB_MATRIX_DUAL_BEACON,
RGB_MATRIX_GRADIENT_UP_DOWN,
RGB_MATRIX_RAINDROPS,
RGB_MATRIX_CYCLE_ALL,
RGB_MATRIX_CYCLE_LEFT_RIGHT,
RGB_MATRIX_CYCLE_UP_DOWN,
RGB_MATRIX_RAINBOW_BEACON,
RGB_MATRIX_RAINBOW_PINWHEELS,
RGB_MATRIX_RAINBOW_MOVING_CHEVRON,
RGB_MATRIX_JELLYBEAN_RAINDROPS,
RGB_MATRIX_DIGITAL_RAIN,
#ifdefRGB_MATRIX_KEYPRESSES
RGB_MATRIX_SOLID_REACTIVE,
RGB_MATRIX_SPLASH,
RGB_MATRIX_MULTISPLASH,
RGB_MATRIX_SOLID_SPLASH,
RGB_MATRIX_SOLID_MULTISPLASH,
#endif
RGB_MATRIX_EFFECT_MAX
};
```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
#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 *)16
```
Where `16` is an unused index from `eeconfig.h`.
@@ -210,12 +262,14 @@ Where `16` is an unused index from `eeconfig.h`.
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!
## Hardware Modification
## 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.
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
@@ -65,6 +65,8 @@ 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.
**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.
@@ -121,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
@@ -183,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.
@@ -129,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
@@ -147,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**.
@@ -143,9 +143,9 @@ As there is no standard split communication driver for ARM-based split keyboards
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().
`CUSTOM_DEBOUNCE`
`DEBOUNCE_TYPE`
Lets you replace the default key debouncing routine with your own code. You will need to provide your own implementation of debounce().
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
@@ -185,11 +185,18 @@ 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:
@@ -209,7 +216,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 +238,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 +263,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 +276,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 +298,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.
@@ -87,12 +87,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).
@@ -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. |
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
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.
@@ -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]
@@ -66,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.
@@ -22,6 +22,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 +56,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:
@@ -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/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
@@ -135,9 +135,11 @@ The `process_record()` function itself is deceptively simple, but hidden within
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.