* Port DIRECT_PINS from split_common/matrix.c to matrix.c
* Reorder matrix.c to remove foward declaration and match split_common/matrix.c
* Refactor nano to use DIRECT_PINS
* Reorder matrix.c to remove foward declaration and match split_common/matrix.c
* Add DIRECT_PINS documentation
* Reorder matrix.c to remove foward declaration and match split_common/matrix.c - fix logic from inherited from split_common
* Add DIRECT_PINS documentation - review comments
* Revert "Update build instructions and Dockerfile to download submodules"
This reverts commit 93210547bd.
* Update build tools docs based on feedback
* Fix bad link in build tools docs
* RGB Matrix overhaul
Breakout of animations to separate files
Integration of optimized int based math lib
Overhaul of rgb_matrix.c and animations for performance
* Updating effect function api for future extensions
* Combined the keypresses || keyreleases define checks into a single define so I stop forgetting it where necessary
* Moving define RGB_MATRIX_KEYREACTIVE_ENABLED earlier in the include chain
* Adds the Planck EZ, 3737 RGB, fixes out-of-tune notes
* fix bug in quantum/rgb_matrix_drivers.c
Co-Authored-By: jackhumbert <jack.humb@gmail.com>
* update command setting to the correct default
* correct rgb config
* remove commented-out lines
* update docs for the 3737
* Update docs/feature_rgb_matrix.md
Co-Authored-By: jackhumbert <jack.humb@gmail.com>
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
* Refactor 4x4 in line with current ps2avrgb template
* Add backlight pwm bodge till #4324 lands
* Disable bootmagic lite as it seems to not work on atmega32a/bootloadHID
* remove unneeded uart setting
* use pragma once everywhere
* remove custom matrix support
* fixup readme
* set bootmagic to lite
* remove dependency on custom i2c code
* use the right header files and function calls
* remove bootmagic support as it doesn't work on bmc boards
* readme merge artifacts removal
* pragma once it all
* put amnesia's name everywhere
* fixup readme
* remove custom matrix
* remove unneccessary configs
* disable bootmagic
* remove custom i2c in favor of i2c_master
* fix rgb led num
* add in rgb underglow support
* Refactor jj40 in line with current ps2avrgb template
* Disable bootmagic lite as it seems to not work on atmega32a/bootloadHID
* Add backlight pwm bodge till #4324 lands
* Increase planck keymap compatibility
* use pragma once
* modified readme with maintainer info
* remove rev1 for the time being
* QMK Configurator support for 60_ansi and 60_ansi_split_bs_rshift
* add hhkb layout and QMK Configurator support
* fix compile issue due to missing DEVICE_VER
* use a saner and less complicated default layout
* remove unused file
* fix up LAYOUT_all and formatting along with QKM Configurator support
* turn on bootmagic lite as the hardware reset switch isn't in a standard position
* remove default folder
* Added Waldo keyboard base files and default keymap
* Updated Waldo files and added keymap for split shift and split backspace
* Updated meta-data for the Waldo board
* Apply suggestions from code review
Committing suggestions for real this time.
Co-Authored-By: That-Canadian <Poole.Chris.11@gmail.com>
* Made suggested changes that were not explicitly made.
* Add keyboard Signum 3.0 for the elite-c
* Update readme.md
* Remove unused macros
* Use bootmagic lite instead of full
* Add warning to keymap.c that it's auto-generate
* Add description for customizing keyboard layouts
* Make generate_km.py executable
* Make right shift available in numpad layer
* Update keyboards/signum/3_0/elitec/readme.md
Co-Authored-By: jceb <jceb@e-jc.de>
* Update keyboards/signum/3_0/elitec/readme.md
Co-Authored-By: jceb <jceb@e-jc.de>
* Fix typo in symbol name
* remove dependency on custom i2c code
* missed a pragma once
* fix readme install instructions
* config.h cleanup
* make the bootmagic key not the same bmc reset key
* disable bootmagic functionality as it doesn't seem to work on atmega32a bmc boards
* remove custom i2c code in favor of QMK i2c_master
* clean up config file
* fix pyusb install instructions
* fix naming in usbconfig.h
* disable bootmagic as it does not work for bmc boards
* Update macros and keycode handling
- Update NUBS_Z macro so it repeats when held down
- Number row now uses numpad keycodes if Right Alt is being held
- coding conventions and formatting update
- switched to four-space indent
- reformatted a block comment
* Update readme files
* remove unneeded uart setting
* use pragma once everywhere
* remove custom matrix support
* fixup readme
* set bootmagic to lite
* remove dependency on custom i2c code
* use the right header files and function calls
* On i2c_init, enable two wire interface, twi interrupt, and slave
address ACK along with pull up resistors.
* thanks to some testing by drashna, we know that setting TWI doesn't work for all boards. Putting the new code into an ifdef block
* Add new keyboard: NQG
* Delete .gitignore
.gitignore removed
Originally used to ignore .DS_Store files from being committed.
* Changed Maintainer information
Maintainer link now points to a github account.
* Add customizable tapping terms
* Add Documentation
* Fix function
* Fixes
* It's not a pointer
* Add debugging output
* Update documentation to be at least vaguely accurate
* Use `get_tapping_term(tapping_key.event)` instead
`e` doesn't include column and row information, properly. It registers as 255, regardless of the actual keypress.
However `tapping_key.event` actually gives the correct column and row information. It appears be the correct structure to use.
In fact, it looks like the issue is that `e` is actually the "TICK" structure, as defined in keyboard.h
* Use variable tapping term value rather than define
* Silly drashna - tapping_key.event, not event
* add get_event_keycode() function
* Fix typo
Co-Authored-By: drashna <drashna@live.com>
* Remove post_process_record_quantum since it's the wrong PR
* Update quantum/quantum.c
Co-Authored-By: drashna <drashna@live.com>
* Better handle ifdef statement for permissive hold
Since we can't be sure that tapping term is actually 500
* Update quantum.c comments based on feedback
* Clean up get_tapping_term function
Clean up function so that users don't need to call the event function, and instead only check the keycode
* Add ability to run functionality on and off
* Make ifdef's more compact
* initial commit of budget96
* non logic changes
* add my name to readme
* update matrix.c
* make the matrix representation of the layout macro
* fix up LAYOUT macro
* add missing character
* initial keymap commit
* put KC_NO where they belong
* basic keymap
* fix matrix row and col definition
* The diagram I was sent and the pins used I was sent were in opposite order from each other. This should fix the issues
* update the readme
* change up manufacturer for budget96
* update copyright date
* fix up the switch matrix and provide a keymap
* forgot the keymap
* other matrix fixes
* missing a few keys in the switch matrix
* messed up the row tracing
* tweak keymap a bit
* use a lower case k
* fix spacing for markdown rendering
* put in the reset key documentation
* clean up the file a little
* use LAYOUT_96_ansi
* add a second layer for lighting controls
* add in lighting support
* add QMK Configurator support
* use pragma once
* remove un needed matrix.c
* convert to GPIO methods
* turn on rgblight_enable and get rid of custom matrix
* set bootloadhid_bootloader to 1
* set bootmagic to lite and set it to k50
* add reset information to readme
* use i2c_master instead of custom i2c
* restore the custom i2c code
* introduce reset key and eep_rst in function layer 1
* fix up pip3 install commands
* fix up device and manufacturer names
* remove un needed comments
* add an ALL layout macro along with QMK Configurator support
* move budget96 into donutcables directory since he actually has different boards
* add a short donut cables blurb taken from his website
* update readme for make instructions to point to the new path
* Update keyboards/donutcables/budget96/config.h
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update keyboards/donutcables/budget96/readme.md
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update keyboards/donutcables/budget96/info.json
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* turn on backlight
* Update keyboards/donutcables/budget96/readme.md
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* remove extra UART and BOOTLOADER settings that are not needed
* Added first configuration for handwired hacked motosped keyboard
* Added first keymap
* Fixed h file key layout
* Swapped Y and Z in default keymap
* Added name, email and description
* Moved hacked motospeed keyboard to handwired
* Changed make command in readme
* Formatted readme to be displayed properly with markdown
* Formatted keymap and layout to better reflect the physical keyboard
* Fixed info.json
* Update keyboards/handwired/hacked_motospeed/info.json
Co-Authored-By: Deckweiss <Deckweiss75@gmail.com>
* Removed .directory from .gitignore
Co-Authored-By: Deckweiss <Deckweiss75@gmail.com>
* Minor changes and cleanup
* Update keyboards/handwired/hacked_motospeed/hacked_motospeed.h
Added back newline needed for properly parsing
Co-Authored-By: Deckweiss <Deckweiss75@gmail.com>
* Adding new keymap folder for goadmaster
* add switch break
* zeal60 rgb backlight files
* modified for red caps lock key
* Remove return statement
* Files removed
* Add new RGB options
* Back to original file
* Keyboard: add treeadstone48
* rename layout defines
* Use of pragma once
* move common include code
* fixed info.json
* change keymap layout from kc to normal
* fix alpha revision keymap
* fixed info.json
* remove USE_Link_Time_Optimization
* Initial portover of the doro68.json with corrected column pins.
* Initial setup of LAYOUT_ansi and it's use in the default keymap.
* Added F keys to default kemap on layer 1.
* Added split space (and everything else) layout and a base keymap to be updated.
* Renamed split_space to multi.
* Changed product_id for doro.
* Created a basic doro LAYOUT_iso and default keymap.
* Copied over basic layout and keymap.
* Added readme.md for doro67 multi.
* Removed basic keyboad layout and keymap because it's a separate PCB.
* Added backlight controls to the various keymaps.
* Added explicit backlight pin define.
* Increased number of backlight levels for flexibility.
* Removed unnecessary line slashes and unified keymcaps.
* Corrected ISO layout and switched position with multi.
* Added keymap readme.md files.
* Corrected ISO keymap.
* Added Layouts to info.json for toolbox.
* Re-added slashes as they were necessary here...
* Corrected info.json/keymap discreptancies.
* Updated copyright messages (and fixed small readme error).
* Added missing line break spaces in readme.md
Co-Authored-By: ShadeDream <nick@shadedream.com>
* Keymap alignments on default_multi readme.md
Co-Authored-By: ShadeDream <nick@shadedream.com>
* Keymap alignments on default_multi readme.md
Co-Authored-By: ShadeDream <nick@shadedream.com>
* Keymap alignments on default_multi readme.md
Co-Authored-By: ShadeDream <nick@shadedream.com>
* Small alignment adjustment on the default keymap readme.md
Co-Authored-By: ShadeDream <nick@shadedream.com>
* use pragma once where applicable
* remove ?
* update default keymap readme
* remove un need include
* update readme with newbs guide
* set underglow and backlight to be on by default, and explicitly set them to no for the default keymap to handle the non Polestar case.
* put mine and benlyall's name in the code
* update readme
* port Massdrop CTRL/ALT to use RGB Matrix
Co-authored-by: Matt Schneeberger <helluvamatt@gmail.com>
* Massdrop lighting support working
This commit is to get the Massdrop lighting code working again through use of the compilation define USE_MASSDROP_CONFIGURATOR added to a keymap's rules.mk.
Added keymaps for both CTRL and ALT named default_md and mac_md. These should be used if the Massdrop style lighting is desired.
* Updating config based on testing results with patrickmt & compile errors
* Updates for PR5328
For CTRL and ALT:
Moved location of new RGB Matrix macros from config_led.h to config.h.
Added RGB_MATRIX_LED_FLUSH_LIMIT (time between flushes) to config.h for correct LED driver update timing.
Re-added missing breathing code for when Massdrop configurator mode is defined.
* remove prilik keymap form PR
* Implemented Eager Per Row debouncing algorithm.
Good for when fingers can only press one row at a time (e.g. when keyboard is wired so that "rows" are vertical)
* Added documentation for eager_pr
* Ported ergodox_ez to eager_pr debouncing.
* Removed check for changes in matrix_scan.
* Added further clarification in docs.
* Accidental merge with ergodox_ez
* Small cleanup in eager_pr
* Forgot to debounce_init - this would probably cause seg-faults.
* first [ass at pulling out common duck library functions
* use new library in jetfire
* use new library in duck lightsaver
* use new library in octagon v2
* put Device into the library
* refactor send_value
* refactor send_value and send_color
* use pragma once
* use pragma once
* use pragma once
* use pragma once
* rename backlight_led to indicator_leds to match with other duck boards
* rename enum
* make #define names consistent
* rename ducklib to duck_led
* update rules.mk ?= to =
* put rgb in the correct order
* add debounce debugging printouts
* turn on bootmagic lite and set it to the top left most key commonly programmed as Escape
* add reset key documentation
* fix that typo
* Update keyboards/duck/duck_led/duck_led.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* include the correct library
* initial commit
* get rid of some of the vanilla cookie cutter code
* Put in the matrix size and the pins
* add LAYOUT macro and a suitable keymap
* Add QMK Configurator support
* set bootmagic to lite
* put a RESET key into the default keymap
* edit kyuu readme file for description and quantrik.com link
* Update keyboards/quantrik/kyuu/config.h
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* fix captilization of keyboard name
* fix keymap wrapping issue and add MO key
* preserve RESET key location
* use one of the macros
* RGB Matrix overhaul
Breakout of animations to separate files
Integration of optimized int based math lib
Overhaul of rgb_matrix.c and animations for performance
* Updating effect function api for future extensions
* Combined the keypresses || keyreleases define checks into a single define so I stop forgetting it where necessary
* Moving define RGB_MATRIX_KEYREACTIVE_ENABLED earlier in the include chain
* Add tennie
* Jacobs Functions
* Switch back to normal layout
* Remove define from old template
* Fix broken keymaps
* Correct style errors, add bootlite
* Update readmes. Rename test keymap
* Missed comma
* Switch rgb from init to post init
Added Fantasie Impromptu and Nocturne Op. 9 No. 1 in B flat minor by Chopin
Added Isabella's Lullaby from The Promised Neverland
Added Renai Circulation and Platinum Disco from Monogatari
Added Terra's theme from Final Fantasy 6
* Updated iris, planck, and xd75 keymaps
* Added brightness down and up to commented layout of Symbol layer.
* updated config files for planck and iris
* removed unnecessary include lines from iris and planck config files
* updated XD75's PC layer and its NAVPC toggle layer
* fixed typo in alias declaration for C_BSPS
* changed alias names for BSPC toggle keys
The other bépo layouts were a bit too complex/weird or without LED code
and hard to transition to for new users. This config is a good base for
bépo users.
* Updated iris, planck, and xd75 keymaps
* Added brightness down and up to commented layout of Symbol layer.
* updated config files for planck and iris
* removed unnecessary include lines from iris and planck config files
* Fixed typo of 'confid.h' to 'config.h'
* Fixed broken links in docs
* Fixed a lot of dead links
* Removed all dead links that I could not find a replacement for
* Placed knops links back in
* Fixed plank keymaps so that they will compile for planck light
* Https doesn't work on knops.io
* tv44:budi now compiles
* s60_x:amnesia0287 now compiles
* Fixed allocation of key_combos so that narze keymap for planck can compile correctly
* Disabled rgb on ergodone and infinity
* Enabled tap dance so it compiles
* Added return statement so it compiles
* If compiling on light disable extra functionality
* Properly redefined variable so it compiles
* Remove remaining dead links
* Create custom Planck Light keycap
See README for details
* Link to WhatPulse in README
* More remapping, and add RGB LED effects
* Remove dead code, address PR feedback from @drashna
* Add macro for “screenshot region to clipboard” hotkey for macOS
Also remove unused layer / key logic
* Remove extraneous comment
* Incorporate PR feedback from @drashna.
Update README with new mapping.
* Add keycodes for new macros to keymaps
* add macros for commonly used shortcuts
* FIx macro code and add comments
* Replaced with build in QMK keycodes
* Removed macros that duplicated QMK keycodes
* The code in this directory supports the KBD65
* Update readme.md
* Update readme.md
* Clear up the confusion between the kbd67/kbd65 naming.
* Update keyboards/kbdfans/kbd67/readme.md
Co-Authored-By: Hackerpilot <briancschott@gmail.com>
* initial commit of e6v2 bmc files
* update readme with bmc template and reset key location
* fix up the switch matrix
* add usbconfig.h file
* add i2c files
* cleanup config.h
* cleanup rules.mk and remove non atmega32a architecture code
* add an appropriate keymap for testing
* update readme with warning not to flash this hex file onto atmega32u4 e6v2
* get rgb lights working
* add QMK Configurator support for 60_ansi layout
* add hhkb support layout
* add additional layouts such as tsangan and all and included QMK Configurator support for them
* add bootmagic lite, and have it be set to Esc or the key located at k50
* update readme
* fixup spacing for LAYOUT_all electrical matrix
* add some pragma once magic
* use i2c_master instead of custom i2c.c
* remove the custom i2c.c
* restore a more valid default keymap
* add eep_rst to keymap
* Add kwer keymap and RGB mod description to cypher
* Add custom led_set_user to keymap
* Remove unneccessary include path from keyboards/westfoxtrot/cypher/keymaps/kwer/keymap.c
Co-Authored-By: kwerdenker <sebastian.spindler@gmail.com>
* build size-check enhancement
Changed to display a warning when the free size of compilation result is less than 512 bytes.
* update message.mk
* add SIZE_MARGIN variable, change default margin 512 to 1024
for Example.
```
$ make SIZE_MARGIN=2048 crkbd:all
$ make crkbd:all ## mergin is 1024
```
* Update message.mk
change message to ‘approaching the maximum’
Co-Authored-By: mtei <2170248+mtei@users.noreply.github.com>
Added song of the ancients and kaine salvation fron Nier
Added Amusement park, Copied city, Vague Hope cold rain and weight of the world from Nier Automata
This PR is cherry-pick from 90b9a1aa7d in PR #5020.
@MxBlu copied quantum/rgblight.c to keyboards/mxss/rgblight.c on July 8, 2018. At that time, I think it would be better to copy quantum/rgblight.h at the same time.
Because if someone makes a change to `quantum/rgblight.[ch]` that is incompatible with the past, it may cause problems with the compilation of keyboards/mxss.
(Like when I changed the prototype of the `rgblight_effect_XXX()` functions of rgblight.c in PR #5020.)
* copy default over as starting point
* Getting rid of dvorak and colemak for now, added a couple changes to the
keymap
* removed refs to bad layers, formatting comments
* First version of my ergodox ported layout!
* Symbols layer, media layer, updated comments
* Hyper as a single key
* Fix stuck hyper key when switching layers
* Tweak some annoying things about the layout.
- move raise left and promote alt
- remove swap keys on the last layer
- reorganize media keys so they're easier to reach and more intuitive
- fix some comment template things
* Add readme for rjhilgefort planck layout
* readme tweak
* PR feedback changes
* Add support for wiring RGB LEDs for both halves directly to their respective controllers
RGB LEDs for each half don't need to be chained together across the TRRS cable with this
* Add split RGB LED support for serial
* Update config/rules for bakingpy layout
* Un-nest ifdefs for hand detection
* Read RGB config state from memory instead of EEPROM for serial updates
* Reuse existing LED pointer instead of creating new one
* Create custom Planck Light keycap
See README for details
* Link to WhatPulse in README
* More remapping, and add RGB LED effects
* Remove dead code, address PR feedback from drashna
* Adding new tap dance key
* Adding new tap dance code
* add code for copy/paste to tap dance
* testing tap dance enums
* New tap dance keycodes
* Fix enums
* handwired/magicforce61: refactor
Renamed layout macro KEYMAP to LAYOUT.
Keymap now uses #include QMK_KEYBOARD_H.
Refactored the default keymap to use non-auto-prepended keycodes per QMK standard.
Deleted deprecated action_get_macro block (was unused).
* handwired/magicforce61: Configurator support
* handwired/magicforce61: readme cleanup
Restructured the readme to be more similar to current QMK template.
* handwired/magicforce61: replace missing image in readme
Replaced the missing wiring image (error 404) with a table.
* handwired/magicforce61: rename readme to lowercase
* Convert config.h to #pragma once include guard
* rgblight.c: add RGBLIGHT_LED_MAP support
* add code to keyboards/helix/rev2/keymaps/five_rows/config.h to test rgblight.c:RGBLIGHT_LED_MAP
* Test end. Revert "add code to keyboards/helix/rev2/keymaps/five_rows/config.h to test rgblight.c:RGBLIGHT_LED_MAP"
This reverts commit e7488d6f73.
* update docs/feature_rgblight.md
* led_map[] move to PROGMEM
* introduce stt layout with K(row)(col)
* set bootmagic to lite
* Rename the original LAYOUT to LAYOUT_all
Introduce the STT layout
In additional the whole matrix was changed to support the K(row)(col) notation.
* rename LAYOUT to LAYOUT_all
* add QMK Configurator support
* stt keymap based on mrpetrov's default configuration on the hb85 he lent me
* update readme
* introduce basic and aop layouts along with QMK Configurator support for them
* add a new line
* add EEP_RST to layer 1 as it is needed to get rgb underglow to work
* add documentation on how to reset the eeprom on the board
* put contributors names where appropriate
* added Boy_.314's layout for halfnhalf keyboard
* reset rules.mk to default
* update keymap with qwerty layout, and enable tap dancing
* fixed formatting in layout visualization
* added rules.mk to custom layout
* added mod tap for ctrl/capslock
* fixed typo in config.h, remove excess in rules.mk, revert half_n_half rules.mk
* added Boy_.314's layout for halfnhalf keyboard
* reset rules.mk to default
* update keymap with qwerty layout, and enable tap dancing
* fixed typo in config.h, remove excess in rules.mk, revert half_n_half rules.mk
* added macros to raise layer
* fixed mismatched layout/comments
* fixed layout switching
* Remove unnecessary IS_COMMAND definition from clueboard/66_hotswap/gen1
* Remove old-style IS_COMMAND definition comment from dozen0
* Use get_mods() instead of keyboard_report->mods in georgi
* Recursively clone qmk_firmware repo
Specifically, so that it grabs the submodules, since ARM keyboards are becoming more common, and we are seeing more issues about chibiOS not being downloaded (in the error log, rather than by question)
* Wrap in shell
* keymap + alpha
* some fixes
* keymap + alpha
* some fixes
* drashna changes
* linked main Alpha repo in keyboards/alpha readme
* missed a spot
* there's another function called FUNC lol
* keymap + alpha
* some fixes
* keymap + alpha
* drashna changes
* Fixed include
* Revert "Fixed include"
This reverts commit ea92f261f8.
* messed up my git, fixed include
* starting work on TMO50 layout
* Update keyboards/tmo50/keymaps/default/keymap.c
Co-Authored-By: PyrooL <lm11887@gmail.com>
* Updated PyroL's TMO50 keymap
* Added task manager/Ctrl Alt Del that i stole from the eco keymap
* Clean up task manager and ctrl alt del macros
Co-Authored-By: PyrooL <lm11887@gmail.com>
* initial commit
* initial commit
* fixed indents
* spelling, capitalization, and order.
* added dota mode keymap, removed old comments
* fixed default keymap always having tilde, instead of grave accent and tilde. Improved dota keymap.
* lower does not change backspace to delete anymore
* corrected pgup/pgdown
* changed period on lower from numpad dot to regular dot
* added colemak and dvorak
* made colemak/dvorak border keys consistent with querty
* updated to match current practices, added custom metakeys for dvorak and colemak
* added disclaimer about audio
* renamed to lowercase
* replaced include guards with #pragma once
Co-Authored-By: rileyweber13 <rileyw13@protonmail.com>
* removed unncessary include
Co-Authored-By: rileyweber13 <rileyw13@protonmail.com>
* removed defines included in core
Co-Authored-By: rileyweber13 <rileyw13@protonmail.com>
* replace defines with an enum, switched from custom function to set_single_persistent_default_layer
* removed ifndef/include/endif left over from previous build system
* removed unnecessary ifdef block
* updated soungs to work with set_single_persistent_default_layer
* Instant 60
* Instant60 changes again
* turn off LSE and features
* Working RGB underglow 🎉
* Add missing files
* Update keymap to have reset
* Backlighting on
* Backlight code for instant60
* Move 072 files to common folder and use it in Instant60
* Updates
* Update keyboards/cannonkeys/instant60/rules.mk
Co-Authored-By: awkannan <andrew.kannan@klaviyo.com>
* add SCREEN_NAV layer for copy/pasting within screen
* working readreg/paste macros
* working read reg / paste macros
* write log and tran patterns, and expand
* add ls -la shortcut, add tab on combined layer
* put delete word on the right pinky key on shell_nav layer
* add TAB on the right side, add reset key
* added Cloud9 macros
* add cloud9 shortcuts to atreus layout
* added BROWSER_CONTROL layer
* finalized browser control layer
* adding comment
* add browser control layer to atreus
* add flashing command line
* remove the tab on combined layer
* remove the tomouse
* remove mouse layer, change log/tran expand patterns, cleanups
* add dumptlog macro
* add "delete to home" shortcut
* fix conflict
* remove unneeded mouse layer
* add meh shortcuts on the browser_control layer
* add/modify some macros
* explain the various layers
* putty paste is right mouse button
* add android studio shortcuts
* allow switching between base and alternate base layouts
* replace cloud9 shortcuts with android studio
* more android studio shortcuts
* add two meh shortcuts on keynav layer
* additional android studio shortcut
* added defines for android studio
* Updated layout after some months of testing.
The current setup looks quite better than the initial one. It's not
perfect but it allows me to work quite well.
The only big problem is the Alt modifiers on the home row which
sometimes break the typing if keys are pressed too fast. I'm also not
satisfied by the TAB key position on the thumb cluster.
Main improvements since previous push:
- Shift layouts on both halves
- Moved around symbols
- Improved number/fn keys
- Reorganized thumbs
* Used enum as suggested by @drashna :-)
* Corrected column count and adjusted layouts to include missing key
The original version reflected 14 columns and omitted KC_GRV, the 15th key on the top row. This revision adds support for the 15h key, and also updates the default (Tsangan) layout to include the HHKB layer keys.
* Reverted config.h to version in master branch
* Moved K413 to the correct location
* Added info.json
* Update keyboards/1upkeyboards/1up60hte/1up60hte.h
Co-Authored-By: newbold <adam@neatnik.net>
* Update keyboards/1upkeyboards/1up60hte/info.json
Co-Authored-By: newbold <adam@neatnik.net>
* Update keyboards/1upkeyboards/1up60hte/keymaps/default/keymap.c
Co-Authored-By: newbold <adam@neatnik.net>
* Update keyboards/1upkeyboards/1up60hte/keymaps/hhkb/keymap.c
Co-Authored-By: newbold <adam@neatnik.net>
* Update keyboards/1upkeyboards/1up60hte/keymaps/hhkb/keymap.c
Co-Authored-By: newbold <adam@neatnik.net>
* Update keyboards/1upkeyboards/1up60hte/keymaps/default/keymap.c
Co-Authored-By: newbold <adam@neatnik.net>
* fresh commit for a new fork for PR to upstream/master
* gaming mode added, lighting changes for other modes
* rules.mk fixed...
* fixed collision issue with aesthetic and shifty modes
* fixed collision issue with aesthetic and shifty modes
* troubleshooting game mode failing
* moved game tapdance key to default layer, fixed issue
* Align docker and vagrant base images - update box to debian 9.6
* Align docker and vagrant base images - lock docker image to debian 9
* Align docker and vagrant base images - update vagrant docker to debian 9
* added my own keymap
* changed thing
* updated keymap Samuel
* updated laypout for better one handed use
* updated stuff I want
* happy with my lagout
* formatting
* Added new literate config
* made everything nice
* cleaned
* fixed spelling and two small bugs in macros
* Made press and lift function for modifiers
* made taps occur on press instead of release
* added oneshot keys and chars cant be negative!
* removed debug message
* Added command and qwerty layers
* fixed bug with oneshot layer
* same bug, different key
Added Liebesleid by Kriesler (or Rachmaninoff), Michishirube from Violet Evergarden, Melodies of Life from Final Fantasy 9 and Eyes on Me from Final Fantasy 8
* Add nrichers keymap
* Additional keymap tweaks, add readme info
* Improve descriptions for changes from default keymap
* Add image of keymap, update .gitignore to
* Add image link
Adds an image of the modified keymap.
* Improve legibility of keymap changes with colour coding
* Tinker with color codes in Markdown
* Experiment with colour codes
* Tinker more with colour codes
* Figured out the easiest way to include colour coding
* Undo earlier .gitignore change
* Refactor layout macro names
Update the names of the layout macros to reflect QMK's desired usage.
- KEYMAP renamed to LAYOUT
- colinta keymap updated accordingly
- KC_KEYMAP renamed to LAYOUT_kc
- mtdjr keymap updated accordingly
* Update xd75.h to use #pragma once include guard
* Update keymaps to use QMK_KEYBOARD_H
* Refactor default keymap
- updated to use layout macro
- remove deprecated action_get_macro function
- add functions from QMK keymap.c template
- process_record_user
- matrix_init_user
- matrix_scan_user
- led_set_user
* Update supporting files
- updated config.h files to use #pragma once include guard
- remove errant QUANTUM_DIR code block
* Rename readme files to fully lowercase filenames
* Restructure keyboard readme
Updated the readme to better align with the current QMK template.
* Bugfixes to supporting files
* Make rgblight_update_dword not update eeprom (we already have
eeconfig_update_rgblight for that).
Make split i2c keyboards transfer active rgblight config rather than
eeprom saved version of rgblight config, enabling runtime changes
that aren't persisted to eeprom.
* prev_level and prev_rgb only store successfully transmitted values
* greenshadowmaker keymap for idobo xd75 massdrop
* remove uneeded config.h
* corrected format to match convention instead of xd75 where I accidentally started from
* Use correct functions for dip switch code
* Some planck cleanup
* Hopefully fix RGB Sleeping with RGB Matrix
* Add rgbmatrix extern
* Add numpad 5x6 layout
* RGB Tweaks
* Add RGB startup animation
* Minor RGB Fixes
* Turn off RBG on planck
* Enable separate storage of EEPROM
* Update Macro pad
* Add BJohnson Keymap and minor darshna tweaks
* Clean up rgb and other code for new numpad
* Remove clicky hachy thing
* Update my code to use built in MOD_MASK defines
* Fix up modifier calls
* Tweak to KC_MAKE
* Tweak to KC_MAKE
* Add Semi-colon to numpad
* Preprocess out rgb matrix stuff if not enabled
* Formatting of KC_MAKE
* Add stuff for matrix and light rgb coexistance
* Fix bad spelling
* Change where layer indication shows based on rgblight status
* Force set mods in KC_MAKE
* Optimize CRKBD
* added Boy_.314's layout for halfnhalf keyboard
* reset rules.mk to default
* update keymap with qwerty layout, and enable tap dancing
* fixed formatting in layout visualization
* added rules.mk to custom layout
* added mod tap for ctrl/capslock
* fixed typo in config.h, remove excess in rules.mk, revert half_n_half rules.mk
Added keymap for 60% board 1up60rgb. The map provides VIM-style navigation on a
second layer (L1) with HOME, PGDN, PGUP, and END keys on that same layer one
row below the home row. The layout is used by https://github.com/michaeldye.
* sleep until usb port becomes writable before running avrdude
* only wait for a writable USB port when not on MSYS
using MINGW or MSYS: sleep for one second, as before.
otherwise: wait for the port to become writable.
* typo
* typo
* Add satisfaction75 revision 1
* Update manufacturer
* Add tester layout and update rev1 comments
* Add ifdef guards for OLED for tester
* Add oled disabling rules
* Update to save backlight settings and setup for VIA custom config
* Add new VIA values to satisfaction75
* Safety guard in clock set mode
* Fix mistaken doc edit
* Address PR comments
* bring the default back to pass travis CI
* Address further PR comments
* Added 3 new songs and added new note type to musical_notes.h
Added Megalovania from Undertale, Kataware Doki from Kimi no Na Wa and La Campanella by Lizst to song_list.h
Added the breve (double whole note) and dotted breve note types to musical_notes.h. I included this because the default tempo is quite high, so I thought a note with higher
duration was needed
* Fixed indentation for new notes in musical_notes.h
Changed tabs to spaces in indentation
* 412_64 move to handwired
412_64 and its second printing, Mark Zero Stand Aside, are now obsolesced by new hardware. As only two units exist in the wild not owned by me, I'm moving the definition to handwired.
* Mark 3 Stand Aside ready for production.
Uploading firmware, compiled and tested, for Mark 3 Stand Aside. The hardware's ready, now the software is too.
* Whoops.
Should've branched before pushing Stand Aside. Sorry 'bout that.
* Revert "Whoops."
This reverts commit d222046cfe.
* Revert "Mark 3 Stand Aside ready for production."
This reverts commit c790899af7.
* Mark 3 Stand Aside ready.
Initial commit for Mark 3 Stand Aside, ready for production.
* Update keyboards/standaside/rules.mk
noroadsleft suggested removal of a line, 'LAYOUTS = ortho_4x16'. I agree.
Co-Authored-By: FateEverywhere <41215461+FateEverywhere@users.noreply.github.com>
* Cleanup for pull request.
Making changes requested by Drashna, as they're all good, and I know way less about the standards than they do.
* Initial cleanup completion.
Missed a few lines in standaside.c, they're cleaned up now.
* Update info.json
Adding layout for the macro version.
* Update info.json
Changed the macro layout to match exactly like the non-macro version (split backspace and bottow row match)
* added my launchpad
* updated keymap with legends and fixed layout errors
* Added default keymap with added layer for RGB controls and included the necessary config code
* fixed layer orders
* removed my personal keymap to clean PR
* missed an underscore
* updated readme
* removed more unnecessary code
* moved RGB code to its own config phone
* moved underglow info to its own readme
* removed redundant code from default_rgb config.h file, included QMK KEYBOARD H in place of initial defines in keymap.c
* reverted launchpad config
* removing the = because I can't figure out why its there
* Revert "removing the = because I can't figure out why its there"
This reverts commit e3b5e6d568.
* reverted rev1/config.h
* reverted all files I should not have touched
* removing redundant code in rules.mk
* readibility improvements to keymap
* Add ISO backslash key position to matrix and keymap files
* Use KC_NO instead of KC_BSLS for unused position in custom keymap
* Add new key position to json layout file used by online configurator
* Get things working except indicators
* Attempt to get things working
* hmm
* Compiles but doesn't run
* Make data transfer work
* Get all indicators working
* Remove old transport
* Prepare for pullreq
* Revert keymap from testing to production
* Final error checking for pull request
* Remove autogenerated is_command from config.h
* Rewrite pin toggles using qmk functions
* 412_64 move to handwired
412_64 and its second printing, Mark Zero Stand Aside, are now obsolesced by new hardware. As only two units exist in the wild not owned by me, I'm moving the definition to handwired.
* Mark 3 Stand Aside ready for production.
Uploading firmware, compiled and tested, for Mark 3 Stand Aside. The hardware's ready, now the software is too.
* Whoops.
Should've branched before pushing Stand Aside. Sorry 'bout that.
* Revert "Whoops."
This reverts commit d222046cfe.
* Revert "Mark 3 Stand Aside ready for production."
This reverts commit c790899af7.
* Update userspace with common config.h
* Add my dz60, satan and xd75 keyboard keymaps
* Fixing executable bits changed during last upstream merge
* Cleanup unnecessary files and defines
* Remove unnecessary defines from userspace config
* Add underglow controls to dz60 function layer
* Fixing merge conflicts
* Fixing exectable bits changed during merge
* Userspace update
* intial commit
* fix up some of the cookie cutter code
* define pins used and size of switch matrix
* enable lighting settings and bootmagic lite
* create the appropriate LAYOUT macro
* remove a comma for compilation errors
* provide a suitable keymap
* disable console and command due to firmware being too large
* add Caps Lock LED support
* Add QMK Configurator support
* fix markdown rendering
* fix mechmerlin to mechkeys
* use `register_code16` and relatives for tapdance code
* rename tapdance keys to more closely mirror the `KC` names in QMK
* additional naming change to match QMK style
* add a tapdance example for creating advanced mod-tap and layer-tap keys
* add optional curly braces to match QMK conventions
* change example to use `register_code16()` and tapdance keycodes more closely matching QMK variants
* Gray Studio HB85 Initial Support
* Fixed README image
* Updated README
* Disabled Bootmagic and Console for HB85
* Fixed Numpad 4 matrix place
* Fixes board crashing with RGB enabled
* Moved HB85 files to gray_studio folder
* Uses old i2c library since this version makes RGB underglow work
* Improved default keymap with underglow control layer
* Removes obsolete program and uses generic script instead
As per zvecr feedback
* Uses GPIO Functions to initialise and set RGB underglow PINS
* Add keycode for KC_MAKE
* Add KC_MAKE keycode
* Add stanrc85.c file with KC_MAKE
* Remove unused include
* Improved KC_MAKE stolen from Drashna
* Define mod mask for new KC_MAKE code
* RESET board to flash after compiling
* Remove send_string
* RESET fixed in KC_MAKE
* add dusty keymap
* change keymap folder to match my github username
* initial keymap completed in comments only
* layout without NAV completed in comments only
* disable Command to prevent interference with Space Cadet keys
* switch _ and \ in the symbol layer
* Layers complete through _NAV
* add thumb keys to _NAV
* complete _NUM
* all layouts complete; still needs `process_user_record()`
* completed first draft of keymap; still needs config.h to match
* corrected keycodes for Mac macro-volume keys
* fix Mac mute keycode
* add missing Mac keycodes for previous and next track
* placeholder for qwerty layout, not yet completed;
remove unnecessary breaks;
add todos
* eliminate Preonic branch before switching to Minidox branch:
• delete dustypomerleau Preonic keymap folder
• complete keymap.c (QWERTY layer, vanilla numbers layer)
TODO:
• add preferences to config.h
• complete the README
* edit commented keymap diagrams for clarity in dual function keys
* define initial config.h and add rules.mk for mouse key support
* fix redundant line after implementation of tap_code()
* fixed key_timer declaration, added README and rules
* formatting of keymap
* add CTPC to config
* cycle thumb keys to favor center position
* modify config.h for temporary Pro Micro compatibility
* remove superfluous call to use serial; homebrewed mod tap keys are still broken with OSL
* merge _SYS and _MEDIA on new Z_SYS key
* ALT_OP example of new MT macro complete
* initial narze-inspired MT fixes in PRU
* add (currently superfluous) custom keycode for the _SYS layer
* rudimentary `OSL` symbol macros that immediately register the mod and fail to reset the oneshot layer, but do output the proper keys—fix both of these things
* remove permissive hold to improve tapping performance
* remove calls to `clear_oneshot_layer_state()`, as they have no effect inside `process_record_user()`. Tapdance appears to be the way forward.
* final commit before tapdance code; correct layout in comments
* initial tapdance code for shifted mod taps
* add numeric and ergo NUM layers and pinky shifts for keycuts
* add TD() wrappers to tapdance codes and clean up commented layout guides
* add faux return to cur_dance to allow compilation - TODO: research what the default clause should be in cur_dance
* update commented schematics for better readability
* add backspace and delete to lockable layers, Z_SYS -> SYS_Z for consistency, fix schematic errors
* add `DOUBLE_SINGLE_TAP` to tapdance cases to allow doubling of the single tap character without waiting tapping term
* remove reduced oneshot tapping toggles
* update README
* newline tweak :)
* Update keyboards/minidox/keymaps/dustypomerleau/keymap.c
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* remove `PREVENT_STUCK_MODIFIERS`, as this is default behavior
* enable extrakey in rules to enable media keys
* enable extrakeys for media key compatibility on macOS
* add dash and slash to _NUM layers
* change to universal volume keycodes
* revert micro volume adjustments to macOS-specific codes due to lack of functionality (macro volume adjustments are still universal)
* fix image of _SYS layer in comments
* more diagram fixes in comments
* fix typo
* simplify tapdance code
* match _NUM_N to _NUM_E
* move slash to allow better use of comma in number layers
* match layer and keycode enums to the docs
* correct qwerty numlock to match numeric numlock layer
* Change how desktop commands work
* Add DST_MOD_MASK as a config option
* DST_RMV → DST_REM
* Add melody96:konstantin keymap
* Update custom SEND_STRING
* Move feature flags from userspace into keyboard rules
* Use "Vo-", "Vo+" instead of "VoD", "VoU" in keymap comments
* Add RGB controls and numpad Unicode to Melody96 keymap
* Add RGB_SET keycode to Melody96 and RGB files to userspace
* Generate UNICODE and UNICODEMAP constants using macros
* Avoid collisions with X_* send string constants
* Use two spaces before inline comments
* Add _keymap versions of other custom Quantum functions
Not added: eeconfig_update_keymap, eeconfig_read_keymap
* Switch to UNICODEMAP in keyboard rules
* Make toggle_numpad a nested function in process_record_user
* Set Melody96 underglow color to Godspeed blue on EEPROM reset
* Remove most _keymap and _user definitions in userspace
Some keyboards misuse _user functions by defining them in the base files
instead of the corresponding _kb functions (especially led_set_user and
matrix_init_user). Until this is fixed (#5148), I've removed definitions
in my userspace that could cause linking collisions.
* Update GODSPEED_BLUE values and RGB mode keys
* Add GODSPEED_YELLOW color
* Set preferred intervals for rgblight effects
* Update tap dance function names
* Replace td_lshift_fn with generic td_mod_layer, add TD_RCTL_FN
Move TD_FN_RCTL after TD_RCTL_FN
* Replace td_fn_rctrl with generic td_layer_mod
* Add blank lines, prefer explicit initialization
* ACTION_TAP_DANCE_DOUBLE_MODS → ACTION_TAP_DANCE_DOUBLE_MOD
* Update Godspeed colors
* Add media controls to Melody96 keymap
* Add SysRq, Break combos and other keys to Melody96 keymap
* Add HOME/END keys as upper/lower on arrow-up/down
* Reduce .hex file size by turning off unneeded options
* Put digit keypad onto left hand upon RAISE; this will sometimes be preferable to double-hits of right hand
* Latest super latest version merge
* cbbrowne keymap for XD75re
* starting notes on XD75re keymap plans
* First draft of bottom row of QWERTY
* Switch my special bottom line over to QCENT
* Dunno
* Filling in wanted keys, bit by bit...
* Add copyright, extra macro
* Clean up comments, remove some experimental code I didn't like
* TODO plans for xd75re
* clean up keyboard layout
* QCENT2 is my new experiment for the main keyboard...
* Add a few more main layer keys, and modify LOWER to shift things outwards to conform with main layer
* Clean up RAISE layer to conform with main layer, remove QCENT layer as QCENT2 is the new thing
* More xd75 changes, now that I actually have it in hand
* shift keymap around, as original attempt was a bit too aggressive in keeping to the edges
* more revs to XD75
* Dropping parts of the centre keypad in favor of Keys I Really Need
* Improve documentation to conform with how builds are done now
* Improve documentation to conform with how builds are done now
* Add cbbrowne rules file as alternative to having the rules in Makefile
* Makefile not needed anymore for individual keymap
* Some revs to my keymapping
* Add {}
* Add PGUP/PGDN
* Shifted some middle-range keys around
* Needed Tilde, Backquote, and to shift RESET onto FUNCTION layer
* Wanted ~
* cbbrowne hasn't anything to do with hadron keymaps
* trim unneeded bits
* I prefer OrgMode for my notes
* Have a right-alt
* Layer keys make LED colors change
* Add sample user rules for cbbrowne
* Add source of xd75 rules
* Individualized xd75 rules
* Adopt LAYOUT to genericize the layout as an ortholinear 5x15 keyboard
I'm a web designer and know there are several "decent" code editors out there, but I would figure not everyone into keyboards is, so I found Sublime text a bit of a hard sell for someone who just need to manipulate some text files. VS Code or Atom would b a much better suit for them instead of dropping $80 on a "decent" text editor.
* Tidy up 5x6.h
- replaced tabs with spaces (QMK convention)
- aligned layout macro visually
* Fix Configurator support for Dactyl Manuform 5x6
- layout macro had the wrong name in info.json
* Tidy up 5x7.h
- replaced tabs with spaces (QMK convention)
- aligned layout macro visually
* Fix Configurator support for Dactyl Manuform 5x7
- corrected keyboard height
- layout macro had the wrong name in info.json
* Tidy up 6x6.h
- replaced tabs with spaces (QMK convention)
- aligned layout macro visually
* Fix Configurator support for Dactyl Manuform 6x6
- layout macro had the wrong name in info.json
* Separate keymaps to VIA enabled/dissabled.
- Default rules.mk has been changed to disable via.
- VIA keymaps have been added for default keymaps.
* Update naming
* Add INSERT and EEP_RST to HS60 keymap
* Add INSERT to keymap
* Layer based RGB colors
* Move RGB code to layer_rgb.c
* New file with layer based RGB colors
* Use RGB code if RGBLIGHT is enabled
* Set RGB options in config.h
* Remove rgb enable from init user
Some keyboards misuse _user functions by defining them in the base files
instead of the corresponding _kb functions (especially led_set_user and
matrix_init_user). Until this is fixed (#5148), I've removed definitions
in my userspace that could cause linking collisions.
* Initial refactor of handwired bluetooth mod to keymap
* Initial refactor of handwired bluetooth mod to keymap - strip out unnecessary duplicate config, update readme
* Initial refactor of handwired bluetooth mod to keymap - reduce firmware size
* Initial refactor of handwired bluetooth mod to keymap - update readme image
* add dusty keymap
* change keymap folder to match my github username
* initial keymap completed in comments only
* layout without NAV completed in comments only
* disable Command to prevent interference with Space Cadet keys
* switch _ and \ in the symbol layer
* Layers complete through _NAV
* add thumb keys to _NAV
* complete _NUM
* all layouts complete; still needs `process_user_record()`
* completed first draft of keymap; still needs config.h to match
* corrected keycodes for Mac macro-volume keys
* fix Mac mute keycode
* add missing Mac keycodes for previous and next track
* placeholder for qwerty layout, not yet completed;
remove unnecessary breaks;
add todos
* eliminate Preonic branch before switching to Minidox branch:
• delete dustypomerleau Preonic keymap folder
• complete keymap.c (QWERTY layer, vanilla numbers layer)
TODO:
• add preferences to config.h
• complete the README
* edit commented keymap diagrams for clarity in dual function keys
* define initial config.h and add rules.mk for mouse key support
* fix redundant line after implementation of tap_code()
* fixed key_timer declaration, added README and rules
* formatting of keymap
* add CTPC to config
* cycle thumb keys to favor center position
* modify config.h for temporary Pro Micro compatibility
* remove superfluous call to use serial; homebrewed mod tap keys are still broken with OSL
* merge _SYS and _MEDIA on new Z_SYS key
* ALT_OP example of new MT macro complete
* initial narze-inspired MT fixes in PRU
* add (currently superfluous) custom keycode for the _SYS layer
* rudimentary `OSL` symbol macros that immediately register the mod and fail to reset the oneshot layer, but do output the proper keys—fix both of these things
* remove permissive hold to improve tapping performance
* remove calls to `clear_oneshot_layer_state()`, as they have no effect inside `process_record_user()`. Tapdance appears to be the way forward.
* final commit before tapdance code; correct layout in comments
* initial tapdance code for shifted mod taps
* add numeric and ergo NUM layers and pinky shifts for keycuts
* add TD() wrappers to tapdance codes and clean up commented layout guides
* add faux return to cur_dance to allow compilation - TODO: research what the default clause should be in cur_dance
* update commented schematics for better readability
* add backspace and delete to lockable layers, Z_SYS -> SYS_Z for consistency, fix schematic errors
* add `DOUBLE_SINGLE_TAP` to tapdance cases to allow doubling of the single tap character without waiting tapping term
* remove reduced oneshot tapping toggles
* update README
* newline tweak :)
* Update keyboards/minidox/keymaps/dustypomerleau/keymap.c
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* remove `PREVENT_STUCK_MODIFIERS`, as this is default behavior
* enable extrakey in rules to enable media keys
* enable extrakeys for media key compatibility on macOS
* add dash and slash to _NUM layers
* change to universal volume keycodes
* revert micro volume adjustments to macOS-specific codes due to lack of functionality (macro volume adjustments are still universal)
* keymap + alpha
* some fixes
* keymap + alpha
* some fixes
* drashna changes
* linked main Alpha repo in keyboards/alpha readme
* missed a spot
* there's another function called FUNC lol
* keymap + alpha
* some fixes
* keymap + alpha
* drashna changes
* Fixed include
* Revert "Fixed include"
This reverts commit ea92f261f8.
* messed up my git, fixed include
* starting work on TMO50 layout
* Update keyboards/tmo50/keymaps/default/keymap.c
Co-Authored-By: PyrooL <lm11887@gmail.com>
* Removed since options are in userspace
* Removed RGB option that was breaking one of my builds
* Remove unused options
* Removed options present in userspace, add board specific options here
* Removed code also present in userspace
* Turns out those lines were needed, added them back
* Testing changes
* Added code to ensure board read as ANSI instead of default ISO for HS60
* Setting \ key to "MOD" instead of "ALPHA" for lighting
* enable velocikey for my userspace and explicitly for my 75% layout
* add guards to only turn on RGB stuff if the RGB pin is actually defined
* update 60_ansi keymap
* update the 60_ansi_split_bs_rshift keymap
* update 66_ansi keymap
* update docs
* Update layouts/community/60_ansi/mechmerlin-ansi/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update layouts/community/60_ansi_split_bs_rshift/mechmerlin-split/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update layouts/community/60_ansi_split_bs_rshift/mechmerlin-split/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update layouts/community/66_ansi/mechmerlin/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update layouts/community/60_ansi_split_bs_rshift/mechmerlin-split/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update layouts/community/60_ansi/mechmerlin-ansi/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update layouts/community/60_ansi/mechmerlin-ansi/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* remove my attempt to find a good way to detect this
* move audio clicky into user space and do feature setting per keyboard
* fixup 66_ansi keymap
* update changelog
* update readme
* Added personal keymaps for Planck, Preonic, Vitamins Included by Juno
* Removing redundancies as suggested
* More removals that were missed out in the previous commits
* Updated Preonic to use new layout
* More redundancies missed out
* Updated more optimal code for FN layer LED indicator.
* Further codes clean up.
* Added a dual windows/osx layout
Default layer is normal ISO for windows. Second layout is Windows ISO layout but for OSX, but with the keys corrected so you will get the correct shifted and alt'd keys on OSX (keyboard keys match OSX keys without having to change your keyboard type in system preferences). Layer three is configuration and other functions, and layer four is where the shifting magic happens. Also tab and caps lock have been swapped around.
* made sure bootmagic is in a seperate rules.mk
made sure bootmagic is in a seperate rules.mk
* commiting the keymap rules.mk
commiting the keymap rules.mk
* Convert community layout to userspace for future use
* Big readme update
* Move layer toggle to CAPS
* Readme updates
* Deleted since unused
* Removed call to unused .c file
* [keymap] adding my Levinson keymap
pretty self explanatory, added the readme, just in case
tested it just now, seems to work fine for my needs
* Update keymap.c
removing the deprecated persistent layer function as Drashna kindly reminded me
* Apply suggestions from code review
incorporated the suggestions, and thanks again for taking care of me with my silly changes :)
Co-Authored-By: OMGVee <mateescu.victor@gmail.com>
* Fix up audio calls
* Add backlight controls
* Add backlight controls and remove RGB underglow
* Make HS60 board specific changes to readme
* Remove BL_TOGG as it isn't use on this board
* use #pragma once
* get rid of code for unused indicators
* pragma once and other small fixes for consistency
* use #pragma once
* pragma once and other small fixes for consistency
* add a short blurb to the readme
* turn on compiler optimization flags
* remove the compiler optimization
* remove compiler optimization for super16
* pragma once and turn on bootmagic lite
* pragma once changes and turning on bootmagic lite
* switch to using pragma once
* switch to using #pragma once
* switch to using #pramga once
* convert tabs to spaces
* fix#4578: don't call gemini protocol code when in bolt mode
Add missing break; statements in switch. The missing break resulted in
a fall through and an additional processing of the gemini code.
* Initial Clueboard 66% arm support
* Fix LAYOUT_66_ansi
* wip
* Bring this branch up to date with led_matrix
* Get Clueboard 66% hotswap working with led_matrix
* stm32 cleanup
* Fix compiling for clueboard 66% hotswap prototype
* Reduce the size of the prototype firmware
Many instances in the QMK Docs referenced KEYMAP macros, which is outdated terminology.
Replaced most instances of KEYMAP with LAYOUT, to reflect the desired usage.
* Draft commit of typing speed RGB control
* More information in the readme
* Support all RGB animation modes (Fixes#1)
* Added support for all RGB light modes to use typing speed
Except christmas lights because that is seizure-inducing at high speeds!
* Introduced a value range specific to each RGB mode
Because some modes are a little too much when running at full speed!
* Update readme.md
* Update readme.md
* Re-arrange typing_speed definitions (Fixes#5) (#6)
* Re-arrange variable definitions to avoid including quantum.h from rgblight.c
* Fix a compilation error when trying to run make test:all
* Tweaks to the typing speed decay rate
* Renamed to momentum; moved implementation into dedicated files
* Groundwork for toggling momentum on/off (currently always on)
* Add EEPROM toggle for momentum-matching
* Moved momentum out of RGBLIGHT_ENABLE toggles so it's more generic
* Move momentum decay task out of rgblight_task()
* Fix missing momentum.h in lufa.c
* Experimental LED support (untested)
* Draft commit of typing speed RGB control
* More information in the readme
* Support all RGB animation modes (Fixes#1)
* Added support for all RGB light modes to use typing speed
Except christmas lights because that is seizure-inducing at high speeds!
* Introduced a value range specific to each RGB mode
Because some modes are a little too much when running at full speed!
* Update readme.md
* Update readme.md
* Re-arrange typing_speed definitions (Fixes#5) (#6)
* Re-arrange variable definitions to avoid including quantum.h from rgblight.c
* Fix a compilation error when trying to run make test:all
* Tweaks to the typing speed decay rate
* Renamed to momentum; moved implementation into dedicated files
* Groundwork for toggling momentum on/off (currently always on)
* Add EEPROM toggle for momentum-matching
* Moved momentum out of RGBLIGHT_ENABLE toggles so it's more generic
* Move momentum decay task out of rgblight_task()
* Fix missing momentum.h in lufa.c
* Added documentation
* Renamed feature to velocikey
* Reverted readme to original state
* Correct the readme title
* Updated feature name in the docs
* Update EECONFIG name
* Add compile-time toggles for velocikey
* Update feature documentation
* Revert "Merge branch 'led-support' into master"
This reverts commit e123ff5feb, reversing
changes made to df111a55b9.
* Move velocikey EECONFIG definition to depend on VELOCIKEY_ENABLE
* Rename decay_task function to decelerate
* Apply suggestions from code review
Co-Authored-By: chrislewisdev <chris@chrislewisdev.com>
* Re-order eeconfig definitions
* Apply coding conventions
* Apply #ifdef check in lufa.c
* Refactored interval time checks into one functionc
* Small rename
* Fix unused function error for layouts not using all rgb effects
* Only update EEPROM if Velocikey is enabled
* Incorporate code review feedback
* Small adjustment to top-end decay rate
* Add Velocikey documentation to table of contents
* Bring tetris:default keymap size down by disabling audio
Descriptions for B5_AUDIO, B6_AUDIO, and B7_AUDIO under Hardware Options were partially italicized when parsed by Docsify, though rendered as intended by GitHub.
* initial commit
* get rid of vanilla cookie cutter code and replace with more correct info
* edit config file for pins and switch matrix size
* turn on bootmagic lite, and backlight/rgb settings
* copy pasta switch matrix from noroads tool
* create an appropriate keymap (copy pasta)
* disable some features to decrease firmware file size
* add qmk configurator support
* add in support for caps lock, scroll lock, and num lock leds
* add temporary pdhelix(Patched Helix) code
* add test code into quantum/split_common/matrix.c
* add test code into keyboards/handwired/pdhelix/
* Revert "add test code into keyboards/handwired/pdhelix/"
This reverts commit 9ed98f0797ddd962c99756689fc4ecb4cd067d3d.
* Revert "add test code into quantum/split_common/matrix.c"
This reverts commit 1876d3ed69f6c213153a9f6476192be839f16c1f.
* Revert "add temporary pdhelix(Patched Helix) code"
This reverts commit 41ac92b814e3f894eaf85bc3e5bb945895342fa8.
* fix quantum/split_common/matrix.c: select_col()/select_row()
* Changed use of '\s' in grep to '[ \t]' for portability
* Pushed DFU Keyboard.h into a shell script
* Fixed execution permissions on make_dfu_header,sh
* introduce wkl directory and readme
* move bface into winkeyless directory and edit readme for new make instructions
* move bmini into the winkeyless directory and edit readme
* move bmini ex into winkeyless directory
* edit readme some more
* add newbs guide to readmes
* fix path to bface
* temporarily turn off community layout support until we refactor this taking out all the custom ps2avrgb stuff
* Change Command keycode defaults to match corresponding Bootmagic codes
* Make alternate magic key keycodes consistent
* Reflect changes from previous commit in tmk_core/common/command.c
* Remove unnecessary MAGIC_KEY_* definitions from keymaps compatible with these changes
* Swap E and BSPACE for MAGIC_KEY_EEPROM
* Add MAGIC_KEY_EEPROM_CLEAR instead of MAGIC_KEY_EEPROM_ALT
* Remove BOOTMAGIC_ENABLE checks around EECONFIG stuff
* Update Command descriptions
* initial work to add eeprom to haptic feedback and decouple the feedback process from keyboards
* Haptic feedback enhancements: on/off toggle working, feedback order working
todo:
-work on modes switching
-get modes switching to save to eeprom
* haptic enhancement - eeprom and modes added
* Added set and get functions for haptic feedback
* initial implementation of solenoids under haptic feedback
* changed eeprom to 32 bits to reserve blocks for future features
* start documentation of haptic feedback
* change keycode per comment from reviewers
* typo fixes
* added eeprom for solenoid configs
* added solenoid and docs
* Add/fix default parameters configs, improve docs
* more doc cleanup
* add in solenoid buzz toggle, clean up doc
* some fixes for error in compiling solenoid
* fix a chibios specific i2c read function and added one for AVR controllers in DRV2605L.c
* fixes for avr side issues
* update keymap
* fix keymap compile error
* fix bugs found during solenoid testing
* set pin that is not powered during bootloader
* added warning about certain pins on the MCU may trip solenoid during DFU/bootloader
- flags for the linker
- added INSERT key as I kinda use it for work fairly often
- turned on more things in rules.mk since I recovered space via linker
flags and whatnot
Based on conversation with Drashna on Discord, we know that if ONE_SHOT_TAP_TOGGLE is 5, then tapping a one shot mod key 5 times holds the one shot key permanently, but to come out of this, you need to press the same key only once.
* Add support for using ranges for RGB
This patch adds support for controlling continuous ranges of RGB LEDs.
Helper functions for split boards are also available.
* RGB Range: Use hardware-platform agnostic wait
* Update KC_GESC documentation
- document caveats on OSX and expected behavior with KC_GESC and GUI
- clarify documentation slightly
- give examples of expected output in actual use
* Update OSX -> macOS
* Captilization
* remove simply
* added my own keymap
* changed thing
* updated keymap Samuel
* updated laypout for better one handed use
* updated stuff I want
* happy with my lagout
* formatting
* Added new literate config
* made everything nice
* cleaned
* fixed spelling and two small bugs in macros
* Made press and lift function for modifiers
* Remove problematic unicode_map stub definition in process_unicodemap.c
* Add unicode_map declaration to process_unicodemap.h
* Disable UNICODEMAP on converter boards that don't use it
* Added xeal60 via clone of lets split
* Delete removed other keymaps
* Basic keymap (no FN). Compiles.
* Removed NP_STAR and NP_SLSH.
* Removed "debounce_algo = manual" in all keyboards with CUSTOM_MATRIX = yes.
* Changed order of rules in TMK. Documented feature.
* Fixed missing whitespace in debounce documentation
Table wasn't working due to missing newline.
* Added bold in a few areas.
* DO NOT USE - Removed debounce from TMK.
* Remove accidental xeal60 commit
* DO NOT USE - debounce successfully compiled.
* DO NOT USE Revert back to original API to support split_keyboards.
* Working eager_pk
* Whitespace cleanup.
* Restored debounce.h since there wasnt any real change.
* Moved debouncing_time variable to inside #if debounce
* Removed check for custom_matrix. We can safely include the debounce file for compilation when custom_matrix is used.
* Removed #include "matrix.h" from debounce.h
* Bug fix - was using MATRIX_ROWS instead of num_rows
* Fixed compilation error with debounce_sym_g
* Renamed DEBOUNCE_ALGO to DEBOUNCE_TYPE
* Malloc array in debounce_eager_pk, since split keyboards only use MATRIX_ROWS/2.
* Fix compile error in debounce_eager_pk
* Stricter, leaner DEBOUNCE_TYPE section in common_features.mk. Cleanup debounce_type.mk
* Add suspend functions
* Disable RGB code if it's disabled
* Add keyboard_init functions
* Change where references so it will compile
* Wrong command chained in wake up kb function
* Fix non-feature file changes
* Add documentation
* Re-add matrix init docs
* add rgblight code to example
* Remove suspend code
* Clean up docs
* Fix docs
* Fix suspend code
* more doc fixes
* change function to startup_* rather than keyboard_init_
* fix spelling error
* fix up docs to finish removing keyboard_init
* Use Pre and Post init functions
* Update Documenation
* Remove changes to my keymap and userspace code
* Cleanup
* Revert changes to extra files
* Forgot a semicolon
* Make sure all protocols call keyboard_setup
* Cleanup functions
* Unset startup_user
* Remove changes from division keyboard
* Readd startup_user function
* Remove all to startup_user
* Update docs/custom_quantum_functions.md
Co-Authored-By: drashna <drashna@live.com>
* Update docs/custom_quantum_functions.md
Co-Authored-By: drashna <drashna@live.com>
* Add suggestion line
* Rebase fixes
* Update documentation to be more useful/accurate
* Cleanup of documentation
* Fix spacing inconsistency
* Revert unexpected change to keymap
* Add a mechanism for force building a particular community layout
* Add docs for FORCE_LAYOUT argument
* Update output name when FORCE_LAYOUT is enabled
* Don't click if turning audio off
On ARM, playing the click when turning off audio causes the audio get stuck and continually play the tone
* Fix Audio EEPROM support for ARM
* Update touched files to conform to QMK Coding Conventions
* Add better check for ARM EEPROM support
* Migrate fn_actions for default keymaps
* Rename the Grave/Escape Shift masks
* No need for shift_esc_shift_mask
* Change breaks to return false
* Right align pointers
* Add default case
* Separate cases with empty lines
* NUBS_Z: initial version
Create a keycode that is normally Z, but KC_NUBS when tapped while Alt is being held.
This removes the possibility of using an Alt+Z shortcut.
* NUBS_Z: modification
Modify NUBS_Z macro to only use alternate operation if Right Alt is being held, rather than responding to either Alt key.
Also add QMK version keycode to System layer, Equals key.
* Remove unneeded breaks from process_record_user
* Macro refactoring
- removed G_RST and G_C10R macros
- updated G_BRCH macro
- outputs `master` if used while Shift is held down; or my git alias for the current branch otherwise
- updated G_FTCH macro
- outputs `git pull upstream ` if used with Shift; `git fetch upstream ` otherwise
- swapped `modifiers` variable for `get_mods()` function directly for checking modifier state
- swapped keymap-level modifier mask macros for QMK-core mod mask macros (thanks vomindoraan #4337)
- renamed MODS_RALT_MASK to MOD_MASK_RALT (more consistent with the above change)
* Update readme files
* set bootmagic from no to lite and put in a note in the readme
* use pragma once
* discovered a compile error when testing with default keymap. The inlined led functions need to be externed in the .c file
* might as well turn on mouse keys as well
* [Keymap] Adding buhearns keymap
* Removing deprecated function
with fauxpark's help
* Update readme.md
* Switching to UNICODE_ENABLE
with drashna's help
* Update rules.mk
* Update config.h
* Update config.h
Tidying up
* Update keymap.c
Tidying up
* Update readme.md
Tidying up
* Update rules.mk
Tidying up
* Removing GESC and adding TILD
* initial commit with edits to vanilla code
* Add QMK Configurator support
* add an appropriately generated keymap
* pins, matrices, and features added in
* moved it all to a regular directory. It's called regular as that's what it's called in the group buy. In the future we will have other directories for the other PCBs that are delivered to customers.
* forgot caps lock led support
* Update keyboards/doro67/regular/keymaps/default/config.h
Use the NAME
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update keyboards/doro67/regular/readme.md
Be more explicit
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Add stm32f072 base ck4x4 to handwired
* add prints
* Save these tries
* Save changes again
* Working hadron oled
* OLEd working but ws2812b still iffy:
* save another try
* Encoder feature + OLED
* RTC code
* Implement clock setting mode
* Whitespace
* Encoder hooked up to working LED PWM code
* Add missing files
* eeprom changes
* Save changes
* Move i2c master
* Move satisfaction75 under cannonkeys
* Set proper default folder
* Revert some core changes
* Undo paved iris changes
* Reorganize code for maintainability and prep for new features
* Add starting code for clock OLED mode
* Clock set mode finished
* Add custom encoder modes
* Actually add VIA keymap
* Gate to only 072
* fix gate for only 072
* Update header guards and includes
* Update i2c selection strategy
* Update board.c to handle software reset to DFU
* add dusty keymap
* change keymap folder to match my github username
* initial keymap completed in comments only
* layout without NAV completed in comments only
* disable Command to prevent interference with Space Cadet keys
* switch _ and \ in the symbol layer
* Layers complete through _NAV
* add thumb keys to _NAV
* complete _NUM
* all layouts complete; still needs `process_user_record()`
* completed first draft of keymap; still needs config.h to match
* corrected keycodes for Mac macro-volume keys
* fix Mac mute keycode
* add missing Mac keycodes for previous and next track
* placeholder for qwerty layout, not yet completed;
remove unnecessary breaks;
add todos
* eliminate Preonic branch before switching to Minidox branch:
• delete dustypomerleau Preonic keymap folder
• complete keymap.c (QWERTY layer, vanilla numbers layer)
TODO:
• add preferences to config.h
• complete the README
* edit commented keymap diagrams for clarity in dual function keys
* define initial config.h and add rules.mk for mouse key support
* fix redundant line after implementation of tap_code()
* fixed key_timer declaration, added README and rules
* formatting of keymap
* add CTPC to config
* cycle thumb keys to favor center position
* modify config.h for temporary Pro Micro compatibility
* remove superfluous call to use serial; homebrewed mod tap keys are still broken with OSL
* merge _SYS and _MEDIA on new Z_SYS key
* ALT_OP example of new MT macro complete
* initial narze-inspired MT fixes in PRU
* add (currently superfluous) custom keycode for the _SYS layer
* rudimentary `OSL` symbol macros that immediately register the mod and fail to reset the oneshot layer, but do output the proper keys—fix both of these things
* remove permissive hold to improve tapping performance
* remove calls to `clear_oneshot_layer_state()`, as they have no effect inside `process_record_user()`. Tapdance appears to be the way forward.
* final commit before tapdance code; correct layout in comments
* initial tapdance code for shifted mod taps
* add numeric and ergo NUM layers and pinky shifts for keycuts
* add TD() wrappers to tapdance codes and clean up commented layout guides
* add faux return to cur_dance to allow compilation - TODO: research what the default clause should be in cur_dance
* update commented schematics for better readability
* add backspace and delete to lockable layers, Z_SYS -> SYS_Z for consistency, fix schematic errors
* add `DOUBLE_SINGLE_TAP` to tapdance cases to allow doubling of the single tap character without waiting tapping term
* remove reduced oneshot tapping toggles
* update README
* newline tweak :)
* Update keyboards/minidox/keymaps/dustypomerleau/keymap.c
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* remove `PREVENT_STUCK_MODIFIERS`, as this is default behavior
* Grab HEX and BIN files from autogen
And push them to qmk.fm/compiled
* Make autogen copy extension agnostic
This way, when travis cl scrpit looks for hex files, it will actually grab bin files, and not hex files for ARM boards
* Handle the AUTOGEN in :bin target to properly handle edge cases
Both the TADA68 and ATSAM boards generate the hex file and then convert it to a bin file. The changes I made does not handle this well, at all. This removes the hex and replaces it with a bin, if a bin is normally generated.
* Revert hex target to original copy command
* Check hex and bin separately in compile push script
Since I don't know how to script this, well
* Simplify push to compiled folder
* Further simplify compiled push script
* Move AUTOGEN parsing to a more sane location to prevent tech debt
Thanks to skully!
* Remove AUTOGEN completely, as it's not needed
This has the benefit of making everything super simple, since we can pull every hex and bin from the root of the qmk_firmware folder, and move that to th compiled folder. This also removes old and unneeded code, and removes some tech debt that has been accrued, without adding more, in theory.
* Tweaks to default 1up60hte layout + support for HHKB style layout
* Added changes to layouts
* Fix config.h
* Fixed errant KC_NO in layout
* Added readme to keyboard... Will update with images/store link when avail.
* Update to use LAYOUT_60_hhkb default layout
* md formatting fix
* Update keyboards/1upkeyboards/1up60hte/readme.md
Co-Authored-By: bubnick <bubnick@users.noreply.github.com>
* Update keyboards/1upkeyboards/1up60hte/readme.md
Co-Authored-By: bubnick <bubnick@users.noreply.github.com>
* Added layout to rules.mk, fixed layout to be compatble with community HHKB keymaps
* Added image, updated store page to readme
* Add userspace files for vosechu
* Code review corrections
* Few more code review corrections
* Initial add of Laptreus code
* Initial add of Laptreus code
* Adding last punctuation to default
* Add some debug suggestions to the debug readme
* Fixes for PR feedback
* Fixing capitalization of readme files
* update auto detect connection logic
* remove unneeded file
* make an appropriate readme
* amend the LAYOUT macro to adhere to new QMK standards and create an appropriate keymap
* add QMK Configurator support
* a bunch of changes lol
* delete unneeded routines
* update date to modern times
* remove a useless prototype
* add in drashna's suggestions on PR
* Improvement of Space Cadet Shift by preventing to automatically apply a modifier on the key and allow to override the default modifier. Closesqmk/qmk_firmware#3815
* Improve the use of the DISABLE_SPACE_CADET_MODIFIER flag to avoid unregistering KC_LSFT when equals to LSPO_MOD
* change #if to if statement
* Added callbacks to one shot modifier changes
* Altered signature of callback functions
* Reordered the callback methods, shortened brief documentation
* Added One Shot Modifier callback documentation
* First attempt at unit tests
* Revert "First attempt at unit tests"
This reverts commit 5ec21a7822.
* Simplified oneshot function implementations
* Made clear_oneshot_locked_mods to be conform action_util.h, adhering to the (void) signature
* Made used datatypes for oneshot mods consistently unsigned integers
* Corrected callback to call clear callback when clear_oneshot_locked_mods is invoked
* Simplified oneshot equals statements
* Corrected return type and signature of get and set oneshot locked mods
* Consolidated one shot callbacks, added initial layer callback version
* Fixed non-updating one shot layer variable after timeout or other clear, added code comments
* Added better one shot key docs
* added keyboard jj4x4, a shorter version of the jj40
* removed useless file
* edited jj4x4 readme.md
* optimized array size in jj4x4 config.h, removed reference to jj40 layouts from rules.mk
* removed custom matrix for this ps2avrgb board, refactored column and row pins
* fix a bug in which the physical matrix did not match the physical layout. Top row was missing 1 key and bottom row had 1 extra key
* amend keymap to account for the new physical matrix
* 6.25u space bar is actually supported, so add a new layout that supports this
* fix keymap readme to no longer need the cautionary warning
* Moving sentraq keyboards to sentraq subdirectory.
* Updating readme markdown to correct make commands.
* Updating s60_x references to point to the new vendor subdirectory.
* Fixed stripped spaces in markdown.
* Updated help information in s60_x readme and linked to additional documentation.
* Make QMK Configurator work with e7-v1
This adds the missing info.json file for the e7-v1 keyboard which I
forgot to add to the original PR.
This allows to see the correct layout in QMK Configurator.
* Fix the ISO layout
The ISO layout has one extra key (hash/tilde) on row 3 right before
the enter key.
The e7-v1 PCB has this key wired at the same switch as the ANSI
backslash (since this switch is not used in ISO).
The tkl_ansi layout had an incorrect value for the grave/tilde key, and
number row keys were misnumbered. This fix removes the typo and adds the
missing K1C key.
* Fix mixed tabs and spaces in adb_usb and m0110_usb makefiles
* Fix typos in converter build options
* Tweak ordering and spacing in converter makefiles
* initial commit
* Do a nice write up for readme
* establish switch matrix and physical layout
* Put in the pins that are used
* QMK configurator support and keymap
* set bootloader to caterina because pro micro boohoo
* add ortho_4x4 support for user spaces
* got the columns reversed lol
* Tweaks to default 1up60hte layout + support for HHKB style layout
* Added changes to layouts
* Fix config.h
* Fixed errant KC_NO in layout
* Added readme to keyboard... Will update with images/store link when avail.
* Update to use LAYOUT_60_hhkb default layout
* md formatting fix
* Update keyboards/1upkeyboards/1up60hte/readme.md
Co-Authored-By: bubnick <bubnick@users.noreply.github.com>
* Update keyboards/1upkeyboards/1up60hte/readme.md
Co-Authored-By: bubnick <bubnick@users.noreply.github.com>
* Added layout to rules.mk, fixed layout to be compatble with community HHKB keymaps
* Create ISO HHKB keymapping for GH60
* Add media controls to Fn layer
* Use M(x) instead of F(x), add Copyright text
* Add README for additional information about TMO50 features/quirks
* Add indicator LED code
* Move indicator code to tmo50.c
* move over kbd19x into the kbdfans directory
* move over kbd4x into the kbdfans directory
* move kbd66 into the kbdfans directory
* move the kbd6x into the kbdfans directory
* move kbd8x into the kbdfans directory
* move kbd75 into the kbdfans directory
* move kbd67 into kbdfans directory
* add a fairly sparse readme for kbdfans directory
* update make instructions for keyboards and add the Complete Newbs Guide to readmes that was missing it
* get kbd75 compiling again
* remove repetitive #defines of KC_NO and KC_TRNS when QMK_KEYBOARD_H is already included in KBD75
* add links to kbdfans readme
* fix some readme formatting
* there is no reason to have two different keymaps with such a small difference, condensing to one
* turning on backlights by default
* enable backlight by default for kbd66
* noticed that the kbd75 had caps lock led code in every keymap. Moved it out to the keyboard.c so everyone can partake.
* Update keyboards/kbdfans/kbd66/readme.md
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* update readme link ordering
* Added QMK Config for Sentraq Number Pad keyboard.
* Sentraq Number Pad documentation cleanup.
* mend
* Added json for configurator.
* Small documentation tweaks.
* Updated the layouts to use the default layouts that match.
* Uncommended user level functions in keymap, left custom keycode/macro code commented but documented why.
* Switched to #pragma once from #ifndef structure in header file.
* Moved Sentraq number pad to sentraq creator directory.
* Renamed sentraq_number_pad to number_pad now that it's nested in the sentraq directory.
* Updated references inside the files for the keyboard rename and nesting.
* Adds keymaps for muzfuz
* Remove unused keys from adjust layer
* Bring in line with current QMK standards.
* Adds Preonic and adjusted Planck keymaps
* Make changes per review request
* update reset sequence info
* fix my rgb underglow led number flub
* add a more sensible keymap
* add caps lock led support
* remove unused #define
* swap the spacebar sizes around to match the space65
* use vomindoraan's suggestion in PR to use IS_LED_ON
* fixed arrow keys and left control
* added right shift
* latest version
* reverted arrow keys
* edited readme
* added osu layer
* updated osu layout
* updated osu layout
* added full arrow keys to osu layout
* in case i mess up creating macros
* added the best meme key in the world
* added plover steno layer
* updated boy314 layout
* removed unused layers
* added boy314 xd75 layout, inspired by preonic layout
* added boy314 xd75 layout, inspired by preonic layout
* version 2 of boy314's xd75 layout
* added readme notes
* updated readme for boy314 xd75 layout
* qwerty support, brackets on bottom row, caps lock underglow
* fixed readme/
* small changes to allow merging
* minor changes to format
* fixed up default readme
* added numpad and tweaked bottom row
* updated xd75 and preonic rev3 keymaps
* added initial half n half files
* fixed .h file
* updated names
* fixed layout in halfnhalf.h
* fixed manu name, changed bootloader in rules.mk
* removed redundancies in preonic and xd75 layouts
* readme updated
* initial commit
* get rid of vanilla code, and fix formatting
* write up a nice looking readme
* add in pins and enable features
* define keymap and switch/physical matrix
* add QMK Configurator support
* switch to bootmagic lite to decrease file size
* Move boards to cannonkeys and share resources
* Share common files between cannonkey boards
* Fix ortho60 keymap
* update LED numbers
* Add RGB keys to Ortho60 and Ortho48
* Add Backlight control to default layout Ortho60 and 48
* Remove unnecessary ws2812.c SRC from rules.mk
* Make Default standard layout
Move Mac OS layout to a separate layout. Basically Mac has the Alt and GUI keys swapped
* Fix typos
* Use Bootmagic keys instead of separate MacOS keymap
* Create ISO HHKB keymapping for GH60
* Add media controls to Fn layer
* Use M(x) instead of F(x), add Copyright text
* Add README for additional information about TMO50 features/quirks
* handwired/space_oddity: refactor
- config.h: updated to use #pragma once include guard
- rules.mk: replace `?=` with `=`
- space_oddity.h:
- updated to use #pragma once include guard
- layout macro KEYMAP renamed to LAYOUT
- default keymap:
- updated to use #include QMK_KEYBOARD_H
- replace references to Planck keycodes
- replace fn_actions-powered layer switch keycode
- rebuild keymap block comments
- keymap layers now use short-form keycodes
- refactor action_get_macro keycodes into process_record_user
* handwired/space_oddity: Configurator support
* handwired/space_oddity: readme cleanup
- update readme to better conform with QMK template
- fixed the make command.
* Add the e7-v1 keyboard
The e7-v1 is a 75% keyboard made by Exclusive based on an Atmega32u4
pub with RGB lights on top and backlighting.
This PR add supports for the regular ANSI layout and ANSI split
backspace layout. No ISO yet :(
* My e7-v1 keymap
Difference from base layout:
* split backspace
* Home & End on last keys of row 0 instead of Insert/Del
* Fn is on the End key when hold
* supports both a windows/linux keymap and osx keymap
* layer change is reflected in the rgb leds of the logo
* [BACKLIGHT_CAPS_LOCK_INDICATOR] Use backlight toggling as Caps Lock LED
I've implemented this feature because S65-X doesn't have LED indicators
and the existing led_set_kb(usb_led) function try to use backlight as
indicator but that creates an inconsistency with backlight_config state.
- define `BACKLIGHT_CAPS_LOCK_INDICATOR` to enable Caps Lock indicator
using backlight (for keyboards without dedicated LED)
- Don't turn off LED indicators when suspend because backlight is
already turned off. Else led_set(0) will turn back on backlight.
- Documentation has been updated
* [BACKLIGHT_CAPS_LOCK_INDICATOR] Turn off all LED indicators except Caps Lock if BACKLIGHT_CAPS_LOCK_INDICATOR
* [BACKLIGHT_CAPS_LOCK] Rename BACKLIGHT_CAPS_LOCK_INDICATOR
* [BACKLIGHT_CAPS_LOCK] Use new IS_LED_ON method
The following layouts were being rendered with 6.75u Spacebars instead of 7u:
- LAYOUT_ansi_blocker_7u
- LAYOUT_ansi_blocker_7u_small_lshift
- LAYOUT_ansi_blocker_7u_small_bspc
- LAYOUT_ansi_blocker_7u_small_lshift_small_bspc
- LAYOUT_iso_blocker_7u
This commit corrects this issue.
Flagged by yanfali on QMK Discord.
- layout macro and keymap layers refactored to more closely resemble physical keyboard layout
- added layout mockup to alice.h
- correct info.json data (was missing a key)
* Added southpole keyboard
added southpole keyboard folder and files including keymaps folder. Keymaps have errors and will not compile yet
* Add files via upload
added manufacturer and product name and description
* Update config.h
* Add files via upload
changed formating added layer
* cleaned up files, fixed foobeard keymap, and added maker info
* fixed keymap files
* Update keyboards/southpole/keymaps/foobeard/keymap.c
Co-Authored-By: ericduns <ericduns@gmail.com>
* Update keyboards/southpole/keymaps/default/keymap.c
Co-Authored-By: ericduns <ericduns@gmail.com>
* made changes fixing outdated lines and added readme.md
* made requested changes for pr to all files
* removed vs code and added new line to southpole.h
* moved some stuff around on my iris layout, but don't expect a lot of changes in the future
* good working setup
* [keymap] some mods to my (omgvee) Helidox keymap
* updated zlant keymap with diagram
* made edites to last post
* noticed slight error in default keymap due to my own mistake. fixed to be the same as default
* fixed spacing in second base layer second row from left
* Added xealousbrown keyboard.
* Changed to pragma once in config.h
* Update keyboards/handwired/xealousbrown/rules.mk
Added bootloader.
Co-Authored-By: alex-ong <the.onga@gmail.com>
* Update keyboards/handwired/xealousbrown/config.h
Commented out IS_COMMAND() since it is already default value.
Co-Authored-By: alex-ong <the.onga@gmail.com>
* Remove duplicated or unnecessary definitions in config.h and rules.mk
* Use IS_HOST_LED_ON() macro
* Add mouse acceleration to kbd6x:konstantin keymap
* Clear and restore mods when sending macros
* Make SEND_STRING_CLEAN a config option
* Add NO_ACTION_ONESHOT to userspace config
* Add files via upload
* Changed _____ to _______ as requested to meet QMK standards.
* Added readme.md
* Removed "PERMISSIVE_HOLD" as it is no longer used.
* Additional code changes made per request
* Added # to first line and removed redundant line.
* Modified Copyright information
* Added space after # for proper formatting
* Formatting changes and additional details
* Remove unnecessary IS_COMMAND definition in clueboard/66/rev4
* Replace keyboard_report->mods with get_mods() in IS_COMMAND definitions
* Update docs to use get_mods() instead of keyboard_report->mods
* Replace keyboard_report->mods with get_mods() in tmk_core/protocol/usb_hid/test
For some reason, this occurrence used KB_LSHIFT and KB_RSHIFT, which don't exist
* Replace keyboard_report->mods with get_mods() in Massdrop keyboards (as per @patrickmt)
* Move Iris via support to Via keymap
And move it out of the main keyboard files
* Actually add via keymap folder
Because using git when you're tired is apparently a very bad idea, and you do stupid things like not running git add
* Clean up config.h file for iris via keymap
* Add default value for IS_COMMAND for COMMAND feature
* Cleanup and consistency
* Update Templates to reflect change
* Fix IS_COMMAND in template
* Fix IS_COMMAND define
* Use consistent IS_COMMAND block in templates
* Remove unnecessary `#undef IS_COMMAND` directives
* Fix compile issue on orthodox
* Reomve IS_COMMAND option for newer boards
* Remove all existing definitions of IS_COMMAND if they use default LSHIFT and RSHIFT setting
* Remove a couple of additional IS_COMMAND defines
* Remove remaining redundant IS_COMMAND definitions
* Remove #undef IS_COMMAND from orthodox:drashna and whitefox:konstantin
* Remove multiple empty lines in modified config.h files
* Update additional boards
* Reomve IS_COMMAND from newer boards
* Update Alice keyboard
* Remove IS_COMMAND from additional boards
Jan 24th edition
* Only re-enable RGBLIGHT if it was on when going to sleep
* Reformat file to follow QMK Standards
* Fix check, since this is a loop, whoops
Much thanks to @Rockman18 for catching this and posting the additional code!
* Add ability to animate arm_atsam led matrix from the center of a circle
* Make arm_atsam led matrix circular animation circular rather than obloid
* Fix indentation in tmk_core led_matrix.c
* Basic Fanoe support (no LED yet)
* Enable RGB lights
* Backlighting support
* Change to reflect Wheat Field brand of Fanoe PCB
* Hot swap variant
* Fix review comment issues
* Fix review issues
* Corrected rules.mk
* Change naming to avoid using possibly copyrighted names
* Added info.json
* Corrected manufacturer name in info.json
* Keymap updates
* Add layout for use with ws2812b and such
* Fixes based on code review
I think `quantum.h` should contain only API declarations that `quantum.c` provides externally. `rgb.h` contains function weak definitions. This should not be in `quantum.h`.
I worked on those keymap to simplify the use of 60% keyboards for
coders. Instead of trying to mimic planck, this keymap remove
raise/lower layer complexity and keep some important sign keys for coder
in the upper right side pretty much the same way as they are on a full
keyboard.
A karabiner configuration is also provided to mimic most of the keymap
features on the macbook internal keyboard for when you are forced to use
it.
- [ ] Alteration (enhancement/optimization) of existing feature(s)
- [ ] New behavior
## Description
## Description
<!-- A few sentences describing what it is that you'd like to see. Additional information (such as links to spec sheets, licensing info, other related issues or PR's, etc) would be helpful. -->
<!-- A few sentences describing what it is that you'd like to see in QMK. Additional information (such as links to spec sheets, licensing info, other related issues or PRs, etc) would be helpful. -->
about: Anything else that doesn't fall into the above categories.
---
<!--- Provide a general summary of the changes you want in the Title above -->
<!--- Provide a general summary of the changes you want in the title above. -->
<!-- This text and anything on lines wrapped like this one will not show up in the final text. This text is to help us and you. -->
<!--- Anything on lines wrapped in comments like these will not show up in the final text. -->
<!-- Please check https://docs.qmk.fm/#/support for additional resources first. If that doesn't answer your question, check the bug report option, as that may be more appropriate. -->
<!-- Please check https://docs.qmk.fm/#/support for additional resources first. If that doesn't answer your question, choose the bug report template instead, as that may be more appropriate. -->
@@ -59,6 +59,8 @@ This is a C header file that is one of the first things included, and will persi
* define is matrix has ghost (unlikely)
*`#define DIODE_DIRECTION COL2ROW`
* COL2ROW or ROW2COL - how your matrix is configured. COL2ROW means the black mark on your diode is facing to the rows, and between the switch and the rows.
* key combination that allows the use of magic commands (useful for debugging)
*`#define USB_MAX_POWER_CONSUMPTION`
* sets the maximum power (in mA) over USB for the device (default: 500)
@@ -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
[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 +129,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 +151,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 +164,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
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,17 +11,17 @@ People often define custom names using `#define`. For example:
#define ALT_TAB LALT(KC_TAB)
```
This will allow you to use `FN_CAPS` and `ALT_TAB` in your `KEYMAP()`, keeping it more readable.
This will allow you to use `FN_CAPS` and `ALT_TAB` in your keymap, keeping it more readable.
## Caveats
Currently, `LT()` and `MT()` are limited to the [Basic Keycode set](keycodes_basic.md), meaning you can't use keycodes like `LCTL()`, `KC_TILD`, or anything greater than `0xFF`. Modifiers specified as part of a Layer Tap or Mod Tap's keycode will be ignored.
Currently, `LT()` and `MT()` are limited to the [Basic Keycode set](keycodes_basic.md), meaning you can't use keycodes like `LCTL()`, `KC_TILD`, or anything greater than `0xFF`. Modifiers specified as part of a Layer Tap or Mod Tap's keycode will be ignored. If you need to apply modifiers to your tapped keycode, [Tap Dance](https://github.com/qmk/qmk_firmware/blob/master/docs/feature_tap_dance.md#example-5-using-tap-dance-for-advanced-mod-tap-and-layer-tap-keys) can be used to accomplish this.
Additionally, if at least one right-handed modifier is specified in a Mod Tap or Layer Tap, it will cause all modifiers specified to become right-handed, so it is not possible to mix and match the two.
# Switching and Toggling Layers
These functions allow you to activate layers in various ways. Note that layers are not generally independent layouts -- multiple layers can be activated at once, and it's typical for layers to use `KC_TRNS` to allow keypresses to pass through to lower layers. For a detailed explanation of layers, see [Keymap Overview](keymap.md#keymap-and-layers) When using momentary layer switching with MO(), LM(), TT(), or LT(), make sure to leave the key on the above layers transparent or it may not work as intended.
These functions allow you to activate layers in various ways. Note that layers are not generally independent layouts -- multiple layers can be activated at once, and it's typical for layers to use `KC_TRNS` to allow keypresses to pass through to lower layers. For a detailed explanation of layers, see [Keymap Overview](keymap.md#keymap-and-layers). When using momentary layer switching with MO(), LM(), TT(), or LT(), make sure to leave the key on the above layers transparent or it may not work as intended.
*`DF(layer)` - switches the default layer. The default layer is the always-active base layer that other layers stack on top of. See below for more about the default layer. This might be used to switch from QWERTY to Dvorak layout. (Note that this is a temporary switch that only persists until the keyboard loses power. To modify the default layer in a persistent way requires deeper customization, such as calling the `set_single_persistent_default_layer` function inside of [process_record_user](custom_quantum_functions.md#programming-the-behavior-of-any-keycode).)
*`MO(layer)` - momentarily activates *layer*. As soon as you let go of the key, the layer is deactivated.
@@ -60,21 +60,21 @@ Sometimes, you might want to switch between layers in a macro or as part of a ta
These allow you to combine a modifier with a keycode. When pressed, the keydown event for the modifier, then `kc` will be sent. On release, the keyup event for `kc`, then the modifier will be sent.
|`LCTL_T(kc)`|`CTL_T(kc)` |Left Control when held, `kc` when tapped |
|`RCTL_T(kc)`| |Right Control when held, `kc` when tapped |
|`LSFT_T(kc)`|`SFT_T(kc)` |Left Shift when held, `kc` when tapped |
|`RSFT_T(kc)`| |Right Shift when held, `kc` when tapped |
|`LALT_T(kc)`|`ALT_T(kc)` |Left Alt when held, `kc` when tapped |
|`RALT_T(kc)`|`ALGR_T(kc)` |Right Alt when held, `kc` when tapped |
|`LGUI_T(kc)`|`LCMD_T(kc)`, `LWIN_T(kc)`, `GUI_T(kc)`, `CMD_T(kc)`, `WIN_T(kc)`|Left GUI when held, `kc` when tapped |
|`RCTL_T(kc)`| |Right Control when held, `kc` when tapped |
|`RSFT_T(kc)`| |Right Shift when held, `kc` when tapped |
|`RALT_T(kc)`|`ALGR_T(kc)` |Right Alt when held, `kc` when tapped |
|`RGUI_T(kc)`|`RCMD_T(kc)`, `RWIN_T(kc)` |Right GUI when held, `kc` when tapped |
|`C_S_T(kc)` | |Left Control and Shift when held, `kc` when tapped |
|`MEH_T(kc)` | |Left Control, Shift and Alt when held, `kc` when tapped|
|`LCAG_T(kc)`| |Left Control, Alt and GUI when held, `kc` when tapped |
|`RCAG_T(kc)`| |Right Control, Alt and GUI when held, `kc` when tapped |
|`HYPR_T(kc)`|`ALL_T(kc)` |Left Control, Shift, Alt and GUI when held, `kc` when tapped - more info [here](http://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/)|
|`SGUI_T(kc)`|`SCMD_T(kc)`, `SWIN_T(kc)` |Left Shift and GUI when held, `kc` when tapped |
|`LCA_T(kc)` | |Left Control and Alt when held, `kc` when tapped |
|`LCAG_T(kc)`| |Left Control, Alt and GUI when held, `kc` when tapped |
|`RCAG_T(kc)`| |Right Control, Alt and GUI when held, `kc` when tapped |
|`C_S_T(kc)` | |Left Control and Shift when held, `kc` when tapped |
|`MEH_T(kc)` | |Left Control, Shift and Alt when held, `kc` when tapped|
|`HYPR_T(kc)`|`ALL_T(kc)` |Left Control, Shift, Alt and GUI when held, `kc` when tapped - more info [here](http://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/)|
## Caveats
@@ -146,7 +146,7 @@ Additionally, hitting keys five times in a short period will lock that key. This
You can control the behavior of one shot keys by defining these in `config.h`:
```c
#define ONESHOT_TAP_TOGGLE 5 /* Tapping this number of times holds the key until tapped this number of times again. */
#define ONESHOT_TAP_TOGGLE 5 /* Tapping this number of times holds the key until tapped once again. */
#define ONESHOT_TIMEOUT 5000 /* Time (in ms) before the one shot key is released */
```
@@ -161,6 +161,81 @@ For one shot mods, you need to call `set_oneshot_mods(MOD)` to set it, or `clear
!> If you're having issues with OSM translating over Remote Desktop Connection, this can be fixed by opening the settings, going to the "Local Resources" tap, and in the keyboard section, change the drop down to "On this Computer". This will fix the issue and allow OSM to function properly over Remote Desktop.
## Callbacks
When you'd like to perform custom logic when pressing a one shot key, there are several callbacks you can choose to implement. You could indicate changes in one shot keys by flashing an LED or making a sound, for example.
There is a callback for `OSM(mod)`. It is called whenever the state of any one shot modifier key is changed: when it toggles on, but also when it is toggled off. You can use it like this:
```c
voidoneshot_mods_changed_user(uint8_tmods){
if(mods&MOD_MASK_SHIFT){
println("Oneshot mods SHIFT");
}
if(mods&MOD_MASK_CTRL){
println("Oneshot mods CTRL");
}
if(mods&MOD_MASK_ALT){
println("Oneshot mods ALT");
}
if(mods&MOD_MASK_GUI){
println("Oneshot mods GUI");
}
if(!mods){
println("Oneshot mods off");
}
}
```
The `mods` argument contains the active mods after the change, so it reflects the current state.
When you use One Shot Tap Toggle (by adding `#define ONESHOT_TAP_TOGGLE 2` in your `config.h` file), you may lock a modifier key by pressing it the specified amount of times. There's a callback for that, too:
Last, there is also a callback for the `OSL(layer)` one shot key:
```c
voidoneshot_layer_changed_user(uint8_tlayer){
if(layer==1){
println("Oneshot layer 1 on");
}
if(!layer){
println("Oneshot layer off");
}
}
```
If any one shot layer is switched off, `layer` will be zero. When you're looking to do something on any layer change instead of one shot layer changes, `layer_state_set_user` is a better callback to use.
If you are making your own keyboard, there are also `_kb` equivalent functions:
```c
voidoneshot_locked_mods_changed_kb(uint8_tmods);
voidoneshot_mods_changed_kb(uint8_tmods);
voidoneshot_layer_changed_kb(uint8_tlayer);
```
As with any callback, be sure to call the `_user` variant to allow for further customizability.
# Tap-Hold Configuration Options
While Tap-Hold options are fantastic, they are not without their issues. We have tried to configure them with reasonal defaults, but that may still cause issues for some people.
@@ -100,6 +100,16 @@ In music mode, the following keycodes work differently, and don't pass through:
*`KC_UP` - speed-up playback
*`KC_DOWN` - slow-down playback
The pitch standard (`PITCH_STANDARD_A`) is 440.0f by default - to change this, add something like this to your `config.h`:
#define PITCH_STANDARD_A 432.0f
You can completely disable Music Mode as well. This is useful, if you're pressed for space on your controller. To disable it, add this to your `config.h`:
#define NO_MUSIC_MODE
### Music Mask
By default, `MUSIC_MASK` is set to `keycode < 0xFF` which means keycodes less than `0xFF` are turned into notes, and don't output anything. You can change this by defining this in your `config.h` like this:
#define MUSIC_MASK keycode != KC_NO
@@ -120,13 +130,26 @@ For a more advanced way to control which keycodes should still be processed, you
Things that return false are not part of the mask, and are always processed.
The pitch standard (`PITCH_STANDARD_A`) is 440.0f by default - to change this, add something like this to your `config.h`:
### Music Map
#define PITCH_STANDARD_A 432.0f
By default, the Music Mode uses the columns and row to determine the scale for the keys. For a board that uses a rectangular matrix that matches the keyboard layout, this is just fine. However, for boards that use a more complicated matrix (such as the Planck Rev6, or many split keyboards) this would result in a very skewed experience.
You can completely disable Music Mode as well. This is useful, if you're pressed for space on your controller. To disable it, add this to your `config.h`:
However, the Music Map option allows you to remap the scaling for the music mode, so it fits the layout, and is more natural.
#define NO_MUSIC_MODE
To enable this feature, add `#defineMUSIC_MAP` to your `config.h` file, and then you will want to add a `uint8_t music_map` to your keyboard's `c` file, or your `keymap.c`.
You will want to use whichever `LAYOUT` macro that your keyboard uses here. This maps it to the correct key location. Start in the bottom left of the keyboard layout, and move to the right, and then upwards. Fill in all the entries until you have a complete matrix.
You can look at the [Planck Keyboard](https://github.com/qmk/qmk_firmware/blob/e9ace1487887c1f8b4a7e8e6d87c322988bec9ce/keyboards/planck/planck.c#L24-L29) as an example of how to implement this.
@@ -16,35 +16,36 @@ To use Command, hold down the key combination defined by the `IS_COMMAND()` macr
If you would like to change the key assignments for Command, `#define` these in your `config.h` at either the keyboard or keymap level. All keycode assignments here must omit the `KC_` prefix.
| Not defined | Use the default algorithm, currently sym_g | Nothing |
| custom | Use your own debounce.c | ```SRC += debounce.c``` add your own debounce.c and implement necessary functions |
| anything_else | Use another algorithm from quantum/debounce/* | Nothing |
**Regarding split keyboards**:
The debounce code is compatible with split keyboards.
# Use your own debouncing code
* Set ```DEBOUNCE_TYPE = custom ```.
* Add ```SRC += debounce.c```
* Add your own ```debounce.c```. Look at current implementations in ```quantum/debounce``` for examples.
* Debouncing occurs after every raw matrix scan.
* Use num_rows rather than MATRIX_ROWS, so that split keyboards are supported correctly.
# Changing between included debouncing methods
You can either use your own code, by including your own debounce.c, or switch to another included one.
Included debounce methods are:
* eager_pr - debouncing per row. On any state change, response is immediate, followed by locking the row ```DEBOUNCE_DELAY``` milliseconds of no further input for that row.
For use in keyboards where refreshing ```NUM_KEYS``` 8-bit counters is computationally expensive / low scan rate, and fingers usually only hit one row at a time. This could be
appropriate for the ErgoDox models; the matrix is rotated 90°, and hence its "rows" are really columns, and each finger only hits a single "row" at a time in normal use.
* eager_pk - debouncing per key. On any state change, response is immediate, followed by ```DEBOUNCE_DELAY``` milliseconds of no further input for that key
* sym_g - debouncing per keyboard. On any state change, a global timer is set. When ```DEBOUNCE_DELAY``` milliseconds of no changes has occured, all input changes are pushed.
@@ -4,7 +4,11 @@ If you're using a 60% keyboard, or any other layout with no F-row, you will have
## Usage
Replace the `KC_GRAVE` key in your keymap (usually to the left of the `1` key) with `KC_GESC`. When pressed it will behave like `KC_ESC`, but with Shift or GUI held it will send`KC_GRAVE`.
Replace the `KC_GRAVE` key in your keymap (usually to the left of the `1` key) with `KC_GESC`. Most of the time this key will output `KC_ESC` when pressed. However, when Shift or GUI are held down it will output`KC_GRV` instead.
## What Your OS Sees
If Mary presses GESC on her keyboard, the OS will see an KC_ESC character. Now if Mary holds Shift down and presses GESC it will output `~`, or a shifted backtick. Now if she holds GUI/CMD/WIN, it will output a simple <code>`</code> character.
## Keycodes
@@ -12,6 +16,10 @@ Replace the `KC_GRAVE` key in your keymap (usually to the left of the `1` key) w
|`KC_GESC`|`GRAVE_ESC`|Escape when pressed, <code>`</code> when Shift or GUI are held|
### Caveats
On macOS, Command+<code>`</code> is by default mapped to "Move focus to next window" so it will not output a backtick. Additionally, Terminal always recognises this shortcut to cycle between windows, even if the shortcut is changed in the Keyboard preferences.
## Configuration
There are several possible key combinations this will break, among them Control+Shift+Escape on Windows and Command+Option+Escape on macOS. To work around this, you can `#define` these options in your `config.h`:
|`HPT_RST` | Reset haptic feedback config to default |
|`HPT_FBK` | Toggle feedback to occur on keypress, release or both |
|`HPT_BUZ` | Toggle solenoid buzz on/off |
|`HPT_MODI` | Go to next DRV2605L waveform |
|`HPT_MODD` | Go to previous DRV2605L waveform |
|`HPT_DWLI` | Increase Solenoid dwell time |
|`HPT_DWLD` | Decrease Solenoid dwell time |
### Solenoids
First you will need a build a circuit to drive the solenoid through a mosfet as most MCU will not be able to provide the current needed to drive the coil in the solenoid.
[Wiring diagram provided by Adafruit](https://playground.arduino.cc/uploads/Learning/solenoid_driver.pdf)
Select a pin that has PWM for the signal pin
```
#define SOLENOID_PIN *pin*
```
Beware that some pins may be powered during bootloader (ie. A13 on the STM32F303 chip) and will result in the solenoid kept in the on state through the whole flashing process. This may overheat and damage the solenoid. If you find that the pin the solenoid is connected to is triggering the solenoid during bootloader/DFU, select another pin.
### DRV2605L
DRV2605L is controlled over i2c protocol, and has to be connected to the SDA and SCL pins, these varies depending on the MCU in use.
#### Feedback motor setup
This driver supports 2 different feedback motors. Set the following in your `config.h` based on which motor you have selected.
##### ERM
Eccentric Rotating Mass vibration motors (ERM) is motor with a off-set weight attached so when drive signal is attached, the off-set weight spins and causes a sinusoidal wave that translate into vibrations.
#define FB_LOOPGAIN 1 /* For Low:0, Medium:1, High:2, Very High:3 */
/* Please refer to your datasheet for the optimal setting for your specific motor. */
#define RATED_VOLTAGE 3
#define V_PEAK 5
```
##### LRA
Linear resonant actuators (LRA, also know as a linear vibrator) works different from a ERM. A LRA has a weight and magnet suspended by springs and a voice coil. When the drive signal is applied, the weight would be vibrate on a single axis (side to side or up and down). Since the weight is attached to a spring, there is a resonance effect at a specific frequency. This frequency is where the LRA will operate the most efficiently. Refer to the motor's datasheet for the recommanded range for this frequency.
#define FB_LOOPGAIN 1 /* For Low:0, Medium:1, High:2, Very High:3 */
/* Please refer to your datasheet for the optimal setting for your specific motor. */
#define RATED_VOLTAGE 2
#define V_PEAK 2.8
#define V_RMS 2.0
#define V_PEAK 2.1
#define F_LRA 205 /* resonance freq */
```
#### DRV2605L waveform library
DRV2605L comes with preloaded library of various waveform sequences that can be called and played. If writing a macro, these waveforms can be played using `DRV_pulse(*sequence name or number*)`
List of waveform sequences from the datasheet:
|seq# | Sequence name |seq# | Sequence name |seq# |Sequence name |
This feature allows you to use LED matrices driven by external drivers. It hooks into the backlight system so you can use the same keycodes as backlighting to control it.
If you want to use RGB LED's you should use the [RGB Matrix Subsystem](feature_rgb_matrix.md) instead.
## Driver configuration
### IS31FL3731
There is basic support for addressable LED matrix lighting with the I2C IS31FL3731 RGB controller. To enable it, add this to your `rules.mk`:
LED_MATRIX_ENABLE = IS31FL3731
You can use between 1 and 4 IS31FL3731 IC's. Do not specify `LED_DRIVER_ADDR_<N>` defines for IC's that are not present on your keyboard. You can define the following items in `config.h`:
| Variable | Description | Default |
|----------|-------------|---------|
| `ISSI_TIMEOUT` | (Optional) How long to wait for i2c messages | 100 |
| `ISSI_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 |
| `LED_DRIVER_COUNT` | (Required) How many LED driver IC's are present | |
| `LED_DRIVER_LED_COUNT` | (Required) How many LED lights are present across all drivers | |
| `LED_DRIVER_ADDR_1` | (Required) Address for the first LED driver | |
| `LED_DRIVER_ADDR_2` | (Optional) Address for the second LED driver | |
| `LED_DRIVER_ADDR_3` | (Optional) Address for the third LED driver | |
| `LED_DRIVER_ADDR_4` | (Optional) Address for the fourth LED driver | |
Here is an example using 2 drivers.
// This is a 7-bit address, that gets left-shifted and bit 0
// set to 0 for write, 1 for read (as per I2C protocol)
// The address will vary depending on your wiring:
Currently only 2 drivers are supported, but it would be trivial to support all 4 combinations.
Define these arrays listing all the LEDs in your `<keyboard>.c`:
const is31_led g_is31_leds[DRIVER_LED_TOTAL] = {
/* Refer to IS31 manual for these locations
* driver
* | LED address
* | | */
{0, C3_3},
....
}
Where `Cx_y` is the location of the LED in the matrix defined by [the datasheet](http://www.issi.com/WW/pdf/31FL3731.pdf) and the header file `drivers/issi/is31fl3731-simple.h`. The `driver` is the index of the driver you defined in your `config.h` (`0`, `1`, `2`, or `3` ).
## Keycodes
All LED matrix keycodes are currently shared with the [backlight system](feature_backlight.md).
## LED Matrix Effects
Currently no LED matrix effects have been created.
## Custom layer effects
Custom layer effects can be done by defining this in your `<keyboard>.c`:
void led_matrix_indicators_kb(void) {
led_matrix_set_index_value(index, value);
}
A similar function works in the keymap as `led_matrix_indicators_user`.
## Suspended state
To use the suspend feature, add this to your `<keyboard>.c`:
?> This is inherited from TMK, and hasn't been updated - it's recommend that you use `SEND_STRING` and `process_record_user` instead.
## Advanced Macro Functions
There are some functions you may find useful in macro-writing. Keep in mind that while you can write some fairly advanced code within a macro, if your functionality gets too complex you may want to define a custom keycode instead. Macros are meant to be simple.
### `record->event.pressed`
This is a boolean value that can be tested to see if the switch is being pressed or released. An example of this is
```c
if(record->event.pressed){
// on keydown
}else{
// on keyup
}
```
### `register_code(<kc>);`
This sends the `<kc>` keydown event to the computer. Some examples would be `KC_ESC`, `KC_C`, `KC_4`, and even modifiers such as `KC_LSFT` and `KC_LGUI`.
### `unregister_code(<kc>);`
Parallel to `register_code` function, this sends the `<kc>` keyup event to the computer. If you don't use this, the key will be held down until it's sent.
### `tap_code(<kc>);`
This will send `register_code(<kc>)` and then `unregister_code(<kc>)`. This is useful if you want to send both the press and release events ("tap" the key, rather than hold it).
If you're having issues with taps (un)registering, you can add a delay between the register and unregister events by setting `#define TAP_CODE_DELAY 100` in your `config.h` file. The value is in milliseconds.
### `register_code16(<kc>);`, `unregister_code16(<kc>);` and `tap_code16(<kc>);`
These functions work similar to their regular counterparts, but allow you to use modded keycodes (with Shift, Alt, Control, and/or GUI applied to them).
Eg, you could use `register_code16(S(KC_5));` instead of registering the mod, then registering the keycode.
### `clear_keyboard();`
This will clear all mods and keys currently pressed.
### `clear_mods();`
This will clear all mods currently pressed.
### `clear_keyboard_but_mods();`
This will clear all keys besides the mods currently pressed.
## **(DEPRECATED)** The Old Way: `MACRO()` & `action_get_macro`
!> This is inherited from TMK, and hasn't been updated - it's recommended that you use `SEND_STRING` and `process_record_user` instead.
By default QMK assumes you don't have any macros. To define your macros you create an `action_get_macro()` function. For example:
@@ -183,11 +233,11 @@ A macro can include the following commands:
### Mapping a Macro to a Key
Use the `M()` function within your `KEYMAP()` to call a macro. For example, here is the keymap for a 2-key keyboard:
Use the `M()` function within your keymap to call a macro. For example, here is the keymap for a 2-key keyboard:
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.
### `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
### Advanced Example: Single-Key Copy/Paste
This example defines a macro which sends `Ctrl-C` when pressed down, and `Ctrl-V` when released.
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).
Mousekeys is a feature that allows you to emulate a mouse using your keyboard. You can move the pointer around, click up to 5 buttons, and even scroll in all 4 directions.
## Adding Mousekeys to a Keymap
There are 2 ways to define how the mousekeys behave, using "[auto-accelerating](#configuring-the-behavior-of-mousekeys-with-auto-accelerated-movement)" or "[3-speed constant](#configuring-the-behavior-of-mousekeys-with-3-speed-constant-movement)" behavior.
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.
In either case, you will need to enable mousekeys in your makefile,
and add the relevant [keycodes](#mapping-mouse-actions-to-keyboard-keys) to your keymap.
### Adding Mousekeys Support in the `rules.mk`
#### Enable Mousekeys
To add support for Mousekeys you simply need to add a single line to your keymap's `rules.mk`:
To enable the mousekey functionality, add the following line to your keymap's `rules.mk`:
```
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 to Keyboard Keys
#### Mapping Mouse Actions to Keyboard Keys
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(slow) |
|`KC_MS_ACCEL1` |`KC_ACL1`|Set mouse acceleration to 1(medium)|
|`KC_MS_ACCEL2` |`KC_ACL2`|Set mouse acceleration to 2(fast) |
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 the Behavior of Mousekeys
## Configuring the Behavior of Mousekeys with auto-accelerated movement
This behavior is intended to emulate the X Window System MouseKeysAccel feature. You can read more about it [on Wikipedia](https://en.wikipedia.org/wiki/Mouse_keys).
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).
@@ -55,27 +55,60 @@ The default speed for controlling the mouse with the keyboard is intentionally s
#define MOUSEKEY_WHEEL_TIME_TO_MAX 40
```
### `MOUSEKEY_DELAY`
#### `MOUSEKEY_DELAY`
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.
### `MOUSEKEY_INTERVAL`
#### `MOUSEKEY_INTERVAL`
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`
#### `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`
#### `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`
#### `MOUSEKEY_WHEEL_MAX_SPEED`
The top speed for scrolling movements.
### `MOUSEKEY_WHEEL_TIME_TO_MAX`
#### `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.
## Configuring the Behavior of Mousekeys with 3-speed constant movement
In your keymap's `config.h`, you must add the line:
```
#define MK_3_SPEED
```
Then you can precisely define 3 different speeds for both the cursor and the mouse wheel, and also whether speed selection is momentary or tap-to-select.
For each speed, you can specify how many milliseconds you want between reports(interval), and how far you want to it to move per report(offset).
For example:
```
#define MK_3_SPEED
#define MK_MOMENTARY_ACCEL // comment this out for tap-to-select acceleration
// cursor speeds:
#define MK_C_OFFSET_SLOW 1 // pixels
#define MK_C_INTERVAL_SLOW 100 // milliseconds
#define MK_C_OFFSET_MED 4
#define MK_C_INTERVAL_MED 16
#define MK_C_OFFSET_FAST 12
#define MK_C_INTERVAL_FAST 16
// scroll wheel speeds:
#define MK_W_OFFSET_SLOW 1 // wheel clicks
#define MK_W_INTERVAL_SLOW 400 // milliseconds
#define MK_W_OFFSET_MED 1
#define MK_W_INTERVAL_MED 200
#define MK_W_OFFSET_FAST 1
#define MK_W_INTERVAL_FAST 100
```
Medium values will be used as the default or unmodified speed.
The speed at which both the cursor and scrolling move can be selected with KC_ACL0, KC_ACL1, KC_ACL2 for slow, medium, and fast. However, if you leave MK_MOMENTARY_ACCEL defined then there is no need to ever send KC_ACL1, since that will be the unmodified speed.
This feature allows you to use RGB LED matrices driven by external drivers. It hooks into the RGBLIGHT system so you can use the same keycodes as RGBLIGHT to control it.
If you want to use single color LED's you should use the [LED Matrix Subsystem](feature_led_matrix.md) instead.
## Driver configuration
### IS31FL3731
There is basic support for addressable RGB matrix lighting with the I2C IS31FL3731 RGB controller. To enable it, add this to your `rules.mk`:
RGB_MATRIX_ENABLE = IS31FL3731
```C
RGB_MATRIX_ENABLE=IS31FL3731
```
Configure the hardware via your `config.h`:
// This is a 7-bit address, that gets left-shifted and bit 0
// set to 0 for write, 1 for read (as per I2C protocol)
// The address will vary depending on your wiring:
// 0b1110100 AD <-> GND
// 0b1110111 AD <-> VCC
// 0b1110101 AD <-> SCL
// 0b1110110 AD <-> SDA
#define DRIVER_ADDR_1 0b1110100
#define DRIVER_ADDR_2 0b1110110
```C
// This is a 7-bit address, that gets left-shifted and bit 0
// set to 0 for write, 1 for read (as per I2C protocol)
// The address will vary depending on your wiring:
Currently only 2 drivers are supported, but it would be trivial to support all 4 combinations.
Define these arrays listing all the LEDs in your `<keyboard>.c`:
const is31_led g_is31_leds[DRIVER_LED_TOTAL] = {
/* Refer to IS31 manual for these locations
* driver
*|R location
* | | G location
* | | | B location
* | | | | */
{0, C1_3, C2_3, C3_3},
....
}
```C
constis31_ledg_is31_leds[DRIVER_LED_TOTAL]={
/* Refer to IS31 manual for these locations
* driver
*|R location
* | | G location
* | | | B location
* | | | | */
{0,C1_3,C2_3,C3_3},
....
}
```
Where `Cx_y` is the location of the LED in the matrix defined by [the datasheet](http://www.issi.com/WW/pdf/31FL3731.pdf) and the header file `drivers/issi/is31fl3731.h`. The `driver` is the index of the driver you defined in your `config.h` (`0` or `1` right now).
### IS31FL3733
### IS31FL3733/IS31FL3737
!> For the IS31FL3737, replace all instances of `IS31FL3733` below with `IS31FL3737`.
There is basic support for addressable RGB matrix lighting with the I2C IS31FL3733 RGB controller. To enable it, add this to your `rules.mk`:
RGB_MATRIX_ENABLE = IS31FL3733
```C
RGB_MATRIX_ENABLE=IS31FL3733
```
Configure the hardware via your `config.h`:
// This is a 7-bit address, that gets left-shifted and bit 0
// set to 0 for write, 1 for read (as per I2C protocol)
// The address will vary depending on your wiring:
// 00 <-> GND
// 01 <-> SCL
// 10 <-> SDA
// 11 <-> VCC
// ADDR1 represents A1:A0 of the 7-bit address.
// ADDR2 represents A3:A2 of the 7-bit address.
// The result is: 0b101(ADDR2)(ADDR1)
#define DRIVER_ADDR_1 0b1010000
#define DRIVER_ADDR_2 0b1010000 // this is here for compliancy reasons.
```C
// This is a 7-bit address, that gets left-shifted and bit 0
// set to 0 for write, 1 for read (as per I2C protocol)
// The address will vary depending on your wiring:
// 00 <-> GND
// 01 <-> SCL
// 10 <-> SDA
// 11 <-> VCC
// ADDR1 represents A1:A0 of the 7-bit address.
// ADDR2 represents A3:A2 of the 7-bit address.
// The result is: 0b101(ADDR2)(ADDR1)
#define DRIVER_ADDR_1 0b1010000
#define DRIVER_ADDR_2 0b1010000 // this is here for compliancy reasons.
#define DRIVER_COUNT 1
#define DRIVER_1_LED_TOTAL 64
#define DRIVER_LED_TOTAL DRIVER_1_LED_TOTAL
#define DRIVER_COUNT 2
#define DRIVER_1_LED_TOTAL 64
#define DRIVER_LED_TOTAL DRIVER_1_LED_TOTAL
```
Currently only a single drivers is supported, but it would be trivial to support all 4 combinations. For now define `DRIVER_ADDR_2` as `DRIVER_ADDR_1`
Define these arrays listing all the LEDs in your `<keyboard>.c`:
const is31_led g_is31_leds[DRIVER_LED_TOTAL] = {
/* Refer to IS31 manual for these locations
* driver
*|R location
* ||G location
* | | | B location
* | | | | */
{0, B_1,A_1, C_1},
....
}
```C
constis31_ledg_is31_leds[DRIVER_LED_TOTAL]={
/* Refer to IS31 manual for these locations
* driver
*|R location
* | | G location
* | | | B location
* || | | */
{0,B_1,A_1,C_1},
....
}
```
Where `X_Y` is the location of the LED in the matrix defined by [the datasheet](http://www.issi.com/WW/pdf/31FL3733.pdf) and the header file `drivers/issi/is31fl3733.h`. The `driver` is the index of the driver you defined in your `config.h` (Only `0` right now).
From this point forward the configuration is the same for all the drivers.
const rgb_led g_rgb_leds[DRIVER_LED_TOTAL] = {
/* {row | col <<4}
*|{x=0..224,y=0..64}
*||modifier
*|||*/
{{0|(0<<4)},{20.36*0,21.33*0},1},
{{0|(1<<4)},{20.36*1,21.33*0},1},
....
}
```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.
@@ -109,47 +131,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`.
@@ -206,12 +240,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.
By default Space Cadet assumes a US ANSI layout, but if your layout uses different keys for parentheses, you can redefine them in your `config.h`.
You can also disable the rollover, allowing you to use the opposite Shift key to cancel the Space Cadet state in the event of an erroneous press, instead of emitting a pair of parentheses when the keys are released.
Also, by default, the Space Cadet applies modifiers LSPO_MOD and RSPC_MOD to keys defined by LSPO_KEY and RSPC_KEY. You can override this behavior by redefining those variables in your `config.h`. You can also prevent the Space Cadet to apply a modifier by defining DISABLE_SPACE_CADET_MODIFIER in your `config.h`.
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).
We welcome all keyboard projects into QMK, but ask that you try to stick to a couple guidelines that help us keep things organised and consistent.
Since starting, QMK has grown by leaps and bounds thanks to people like you who contribute to creating and maintaining our community keyboards. As we've grown we've discovered some patterns that work well, and ask that you conform to them to make it easier for other people to benefit from your hard work.
## Naming Your Keyboard/Project
All names should be lowercase alphanumeric, and separated by an underscore (`_`), but not begin with one. Your directory and your `.h` and `.c` files should have exactly the same name. All folders should follow the same format. `test`, `keyboard`, and `all` are reserved by make and are not a valid name for a keyboard.
All keyboard names are in lowercase, consisting only of letters, numbers, and underscore (`_`). Names may not begin with an underscore. Forward slash (`/`) is used as a sub-folder separation character.
## `readme.md`
The names `test`, `keyboard`, and `all` are reserved for make commands and may not be used as a keyboard or subfolder name.
All projects need to have a `readme.md` file that explains what the keyboard is, who made it, where it is available, and links to more information. Please follow the [published template](documentation_templates.md#keyboard-readmemd-template).
Valid Examples:
*`412_64`
*`chimera_ortho`
*`clueboard/66/rev3`
*`planck`
*`v60_type_r`
## Sub-folders
QMK uses sub-folders both for organization and to share code between revisions of the same keyboard. You can nest folders up to 4 levels deep:
If a sub-folder has a `rules.mk` file it will be considered a compilable keyboard. It will be available in QMK Configurator and tested with `make all`. If you are using a folder to organize several keyboards from the same maker you should not have a `rules.mk` file.
Example:
Clueboard uses sub-folders for both purposes, organization and keyboard revisions.
* [`clueboard`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard) ← This is the organization folder, there's no `rules.mk` file
* [`60`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/60) ← This is a compilable keyboard, it has a `rules.mk` file
* [`66`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/66) ← This is also compilable- it uses `DEFAULT_FOLDER` to specify `rev3` as the default revision
* [`rev3`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/66/rev3) ← compilable: `make clueboard/66/rev3` or `make clueboard/66`
## Keyboard Folder Structure
Your keyboard should be located in `qmk_firmware/keyboards/` and the folder name should be your keyboard's name as described in the previous section. Inside this folder should be several files:
*`readme.md`
*`info.json`
*`config.h`
*`rules.mk`
*`<keyboard_name>.c`
*`<keyboard_name>.h`
### `readme.md`
All projects need to have a `readme.md` file that explains what the keyboard is, who made it and where it's available. If applicable, it should also contain links to more information, such as the maker's website. Please follow the [published template](documentation_templates.md#keyboard-readmemd-template).
### `info.json`
This file is used by the [QMK API](https://github.com/qmk/qmk_api). It contains the information [QMK Configurator](https://config.qmk.fm/) needs to display a representation of your keyboard. You can also set metadata here. For more information see the [reference page](reference_info_json.md).
### `config.h`
All projects need to have a `config.h` file that sets things like the matrix size, product name, USB VID/PID, description and other settings. In general, use this file to set essential information and defaults for your keyboard that will always work.
### `rules.mk`
The presence of this file means that the folder is a keyboard target and can be used in `make` commands. This is where you setup the build environment for your keyboard and configure the default set of features.
### `<keyboard_name.c>`
This is where you will write custom code for your keyboard. Typically you will write code to initialize and interface with the hardware in your keyboard. If your keyboard consists of only a key matrix with no LEDs, speakers, or other auxillary hardware this file can be blank.
The following functions are typically defined in this file:
This file is used to define the matrix for your keyboard. You should define at least one C macro which translates an array into a matrix representing the physical switch matrix for your keyboard. If it's possible to build your keyboard with multiple layouts you should define additional macros.
If you have only a single layout you should call this macro `LAYOUT`.
When defining multiple layouts you should have a base layout, named `LAYOUT_all`, that supports all possible switch positions on your matrix, even if that layout is impossible to build physically. This is the macro you should use in your `default` keymap. You should then have additional keymaps named `default_<layout>` that use your other layout macros. This will make it easier for people to use the layouts you define.
Layout macro names are entirely lowercase, except for the word `LAYOUT` at the front.
As an example, if you have a 60% PCB that supports ANSI and ISO you might define the following layouts and keymaps:
| Layout Name | Keymap Name | Description |
|-------------|-------------|-------------|
| LAYOUT_all | default | A layout that supports both ISO and ANSI |
| LAYOUT_ansi | default_ansi | An ANSI layout |
| LAYOUT_iso | default_iso | An ISO layout |
## Image/Hardware Files
In an effort to keep the repo size down, we're no longer accepting images of any format in the repo, with few exceptions. Hosting them elsewhere (imgur) and linking them in the `readme.md` is the preferred method.
In an effort to keep the repo size down we're no longer accepting binary files of any format, with few exceptions. Hosting them elsewhere (such as <https://imgur.com>) and linking them in the `readme.md` is preferred.
Any sort of hardware file (plate, case, pcb) can't be stored in qmk_firmware, but we have the [qmk.fm repo](https://github.com/qmk/qmk.fm) where such files (as well as in-depth info) can be stored and viewed on [qmk.fm](http://qmk.fm). Downloadable files are stored in `/<keyboard>/` (name follows the same format as above) which are served at `http://qmk.fm/<keyboard>/`, and pages are generated from `/_pages/<keyboard>/` which are served at the same location (.md files are generated into .html files through Jekyll). Check out the `lets_split`directory for an example.
Hardware files (such as plates, cases, pcb) can be contributed to the [qmk.fm repo](https://github.com/qmk/qmk.fm) and they will be made available on [qmk.fm](http://qmk.fm). Downloadable files are stored in `/<keyboard>/` (name follows the same format as above) which are served at `http://qmk.fm/<keyboard>/`, and pages are generated from `/_pages/<keyboard>/` which are served at the same location (.md files are generated into .html files through Jekyll). Check out the `lets_split`folder for an example.
## Keyboard Defaults
@@ -32,77 +116,6 @@ If your keyboard does not have 2 shift keys you should provide a working default
As documented on [Customizing Functionality](custom_quantum_functions.md) you can define custom functions for your keyboard. Please keep in mind that your users may want to customize that behavior as well, and make it possible for them to do that. If you are providing a custom function, for example `process_record_kb()`, make sure that your function calls the `_user()` version of the call too. You should also take into account the return value of the `_user()` version, and only run your custom code if the user returns `true`.
## Keyboard Metadata
As QMK grows so does the ecosystem surrounding QMK. To make it easier for projects in that ecosystem to tie into QMK as we make changes we are developing a metadata system to expose information about keyboards in QMK.
You can create `info.json` files at every level under `qmk_firmware/keyboards/<name>` to specify this metadata. These files are combined, with more specific files overriding keys in less specific files. This means you do not need to duplicate your metadata information. For example, `qmk_firmware/keyboards/clueboard/info.json` specifies `manufacturer` and `maintainer`, while `qmk_firmware/keyboards/clueboard/66/info.json` specifies more specific information about Clueboard 66%.
### `info.json` Format
The `info.json` file is a JSON formatted dictionary with the following keys available to be set. You do not have to set all of them, merely the keys that apply to your keyboard.
*`keyboard_name`
* A free-form text string describing the keyboard.
* Example: `Clueboard 66%`
*`url`
* A URL to the keyboard's product page, [QMK.fm/keyboards](https://qmk.fm/keyboards) page, or other page describing information about the keyboard.
*`maintainer`
* GitHub username of the maintainer, or `qmk` for community maintained boards
*`width`
* Width of the board in Key Units
*`height`
* Height of the board in Key Units
*`layouts`
* Physical Layout representations. See the next section for more detail.
#### Layout Format
Within our `info.json` file the `layouts` portion of the dictionary contains several nested dictionaries. The outer layer consists of QMK layout macros, for example `LAYOUT_ansi` or `LAYOUT_iso`. Within each layout macro are keys for `width`, `height`, and `key_count`, each of which should be self-explanatory.
*`width`
* Optional: The width of the layout in Key Units
*`height`
* Optional: The height of the layout in Key Units
*`key_count`
* **Required**: The number of keys in this layout
*`layout`
* A list of Key Dictionaries describing the physical layout. See the next section for more details.
#### Key Dictionary Format
Each Key Dictionary in a layout describes the physical properties of a key. If you are familiar with the Raw Code for <http://keyboard-layout-editor.com> you will find many of the concepts the same. We re-use the same key names and layout choices wherever possible, but unlike keyboard-layout-editor each key is stateless, inheriting no properties from the keys that came before it.
All key positions and rotations are specified in relation to the top-left corner of the keyboard, and the top-left corner of each key.
*`X`
* **Required**: The absolute position of the key in the horizontal axis, in Key Units.
*`Y`
* **Required**: The absolute position of the key in the vertical axis, in Key Units.
*`W`
* The width of the key, in Key Units. Ignored if `ks` is provided. Default: `1`
*`H`
* The height of the key, in Key Units. Ignored if `ks` is provided. Default: `1`
*`R`
* How many degrees clockwise to rotate the key.
*`RX`
* The absolute position of the point to rotate the key around in the horizontal axis. Default: `x`
*`RY`
* The absolute position of the point to rotate the key around in the vertical axis. Default: `y`
*`KS`
* Key Shape: define a polygon by providing a list of points, in Key Units.
* **Important**: These are relative to the top-left of the key, not absolute.
* Example ISO Enter: `[ [0,0], [1.5,0], [1.5,2], [0.25,2], [0.25,1], [0,1], [0,0] ]`
### How is the Metadata Exposed?
This metadata is primarily used in two ways:
* To allow web-based configurators to dynamically generate UI
* To support the new `make keyboard:keymap:qmk` target, which bundles this metadata up with the firmware to allow QMK Toolbox to be smarter.
Configurator authors can see the [QMK Compiler](https://docs.compile.qmk.fm/api_docs.html) docs for more information on using the JSON API.
## Non-Production/Handwired Projects
We're happy to accept any project that uses QMK, including prototypes and handwired ones, but we have a separate `/keyboards/handwired/` folder for them, so the main `/keyboards/` folder doesn't get overcrowded. If a prototype project becomes a production project at some point in the future, we'd be happy to move it to the main `/keyboards/` folder!
@@ -12,7 +12,7 @@ The I2C Master drivers used in QMK have a set of common functions to allow porta
|`uint8_t i2c_receive(uint8_t address, uint8_t* data, uint16_t length, uint16_t timeout);` |Receive data over I2C. Address is the 7-bit slave address without the direction. Saves number of bytes specified by `length` in `data` array. Returns status of transaction. |
|`uint8_t i2c_writeReg(uint8_t devaddr, uint8_t regaddr, uint8_t* data, uint16_t length, uint16_t timeout);` |Same as the `i2c_transmit` function but `regaddr` sets where in the slave the data will be written. |
|`uint8_t i2c_readReg(uint8_t devaddr, uint8_t regaddr, uint8_t* data, uint16_t length, uint16_t timeout);` |Same as the `i2c_receive` function but `regaddr` sets from where in the slave the data will be read. |
|`uint8_t i2c_stop(uint16_t timeout);`|Stops the I2C driver. |
|`uint8_t i2c_stop(void);` |Ends an I2C transaction. |
### Function Return
@@ -33,8 +33,8 @@ The following defines can be used to configure the I2C master driver.
|`#Prescaler` |Divides master clock to aid in I2C clock selection |1 |
|`F_SCL` |Clock frequency in Hz |400KHz |
|`Prescaler` |Divides master clock to aid in I2C clock selection |1 |
AVRs usually have set GPIO which turn into I2C pins, therefore no further configuration is required.
@@ -63,20 +63,24 @@ Lastly, we need to assign the correct GPIO pins depending on the I2C hardware dr
By default the I2C1 hardware driver is assumed to be used. If another hardware driver is used, `#define I2C_DRIVER I2CDX` should be added to the `config.h` file with X being the number of hardware driver used. For example is I2C3 is enabled, the `config.h` file should contain `#define I2C_DRIVER I2CD3`. This aligns the QMK I2C driver with the Chibios I2C driver.
STM32 MCUs allows a variety of pins to be configured as I2C pins depending on the hardware driver used. By default B6 and B7 are set to I2C.
STM32 MCUs allows a variety of pins to be configured as I2C pins depending on the hardware driver used. By default B6 and B7 are set to I2C. You can use these defines to set your i2c pins:
This can be changed by declaring the `i2c_init` function which intentionally has a weak attribute. Please consult the datasheet of your MCU for the available GPIO configurations. The following is an example initialization function:
| `I2C1_BANK` | The bank of pins (`GPIOA`, `GPIOB`, `GPIOC`) | `GPIOB` |
| `I2C1_SCL` | The pin number for the SCL pin (0-9) | `6` |
| `I2C1_SDA` | The pin number for the SDA pin (0-9) | `7` |
You can also overload the `void i2c_init(void)` function, which has a weak attribute. If you do this the configuration variables above will not be used. Please consult the datasheet of your MCU for the available GPIO configurations. The following is an example initialization function:
```C
voidi2c_init(void)
{
setPinInput(B6);// Try releasing special pins for a short time
setPinInput(B7);
chThdSleepMilliseconds(10);// Wait for the release to happen
wait_ms(10);// Wait for the release to happen
palSetPadMode(GPIOB,6,PAL_MODE_ALTERNATE(4)|PAL_STM32_OTYPE_OPENDRAIN|PAL_STM32_PUPDR_PULLUP);// Set B6 to I2C function
palSetPadMode(GPIOB,7,PAL_MODE_ALTERNATE(4)|PAL_STM32_OTYPE_OPENDRAIN|PAL_STM32_PUPDR_PULLUP);// Set B7 to I2C function
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
|`LCTL_T(kc)`|`CTL_T(kc)` |Left Control when held, `kc` when tapped |
|`RCTL_T(kc)`| |Right Control when held, `kc` when tapped |
|`LSFT_T(kc)`|`SFT_T(kc)` |Left Shift when held, `kc` when tapped |
|`RSFT_T(kc)`| |Right Shift when held, `kc` when tapped |
|`LALT_T(kc)`|`ALT_T(kc)` |Left Alt when held, `kc` when tapped |
|`RALT_T(kc)`|`ALGR_T(kc)` |Right Alt when held, `kc` when tapped |
|`LGUI_T(kc)`|`LCMD_T(kc)`, `LWIN_T(kc)`, `GUI_T(kc)`, `CMD_T(kc)`, `WIN_T(kc)`|Left GUI when held, `kc` when tapped |
|`RCTL_T(kc)`| |Right Control when held, `kc` when tapped |
|`RSFT_T(kc)`| |Right Shift when held, `kc` when tapped |
|`RALT_T(kc)`|`ALGR_T(kc)` |Right Alt when held, `kc` when tapped |
|`RGUI_T(kc)`|`RCMD_T(kc)`, `RWIN_T(kc)` |Right GUI when held, `kc` when tapped |
|`C_S_T(kc)` | |Left Control and Shift when held, `kc` when tapped |
|`MEH_T(kc)` | |Left Control, Shift and Alt when held, `kc` when tapped|
|`LCAG_T(kc)`| |Left Control, Alt and GUI when held, `kc` when tapped |
|`RCAG_T(kc)`| |Right Control, Alt and GUI when held, `kc` when tapped |
|`HYPR_T(kc)`|`ALL_T(kc)` |Left Control, Shift, Alt and GUI when held, `kc` when tapped - more info [here](http://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/)|
|`SGUI_T(kc)`|`SCMD_T(kc)`, `SWIN_T(kc)` |Left Shift and GUI when held, `kc` when tapped |
|`LCA_T(kc)` | |Left Control and Alt when held, `kc` when tapped |
|`LCAG_T(kc)`| |Left Control, Alt and GUI when held, `kc` when tapped |
|`RCAG_T(kc)`| |Right Control, Alt and GUI when held, `kc` when tapped |
|`C_S_T(kc)` | |Left Control and Shift when held, `kc` when tapped |
|`MEH_T(kc)` | |Left Control, Shift and Alt when held, `kc` when tapped|
|`HYPR_T(kc)`|`ALL_T(kc)` |Left Control, Shift, Alt and GUI when held, `kc` when tapped - more info [here](http://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/)|
QMK keymaps are defined inside a C source file. The data structure is an array of arrays. The outer array is a list of layer arrays while the inner layer array is a list of keys. Most keyboards define a `KEYMAP()` macro to help you create this array of arrays.
QMK keymaps are defined inside a C source file. The data structure is an array of arrays. The outer array is a list of layer arrays while the inner layer array is a list of keys. Most keyboards define a `LAYOUT()` macro to help you create this array of arrays.
## Keymap and Layers
@@ -119,7 +119,7 @@ The main part of this file is the `keymaps[]` definition. This is where you list
> This `fn_actions[]` interface is mostly for backward compatibility. In QMK, you don't need to use `fn_actions[]`. You can directly use `ACTION_FUNCTION(N)` or any other action code value itself normally generated by the macro in `keymaps[][MATRIX_ROWS][MATRIX_COLS]`. N in `F(N)` can only be 0 to 31. Use of the action code directly in `keymaps` unlocks this limitation.
The [QMK Configurator](https://config.qmk.fm) is an online graphical user interface that generates QMK Firmware hex files.
?> **Please follow these steps in order.**
Watch the [Video Tutorial](https://youtu.be/7RH-1pAbjvw)
The QMK Configurator works best with Chrome/Firefox.
!> **Files from other tools such as KLE, or kbfirmware will not be compatible with QMK Configurator. Do not load them, do not import them. QMK Configurator is a DIFFERENT tool. **
## Selecting your keyboard
Click the drop down box and select the keyboard you want to create a keymap for.
?> If your keyboard has several versions, make sure you select the correct one.**
I'll say that again because it's important
!> **MAKE SURE YOU SELECT THE RIGHT VERSION!**
If your keyboard has been advertised to be powered by QMK but is not in the list, chances are a developer hasn't gotten to it yet or we haven't had a chance to merge it in yet. File an issue at [qmk_firmware](https://github.com/qmk/qmk_firmware/issues) requesting to support that particular keyboard, if there is no active [Pull Request](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+is%3Apr+label%3Akeyboard) for it. There are also QMK powered keyboards that are in their manufacturer's own github accounts. Double check for that as well.
## Selecting your keyboard layout
Choose the layout that best represents the keymap you want to create. Some keyboards do not have enough layouts or correct layouts defined yet. They will be supported in the future.
## Keymap Name
Call this keymap what you want.
?> If you are running into issues when compiling, it may be worth changing this name, as it may already exist in the QMK Firmware repo.
## Creating Your Keymap
Keycode Entry is accomplished in 3 ways.
1. Drag and dropping
2. Clicking on an empty spot on the layout and clicking the keycode you desire
3. Clicking on an empty spot on the layout, pressing the physical key on your keyboard.
Hover your mouse over a key and a short blurb will tell you what that keycode does. For a more verbose description please see
In the event that you can't find a layout that supports your keymap, for example three spots for spacebar, or two spots for backspace, or 2 spots for shift etc etc, Fill them ALL up.
### Example:
3 spots for spacebar: Fill them ALL with spacebar
2 spots for backspace: Fill them BOTH with backspace
2 spots for right shift: Fill them BOTH with right shift
1 spot for left shift and 1 spot for iso support: Fill them both with left shift
5 spots, but only 4 keys: Guess and check or ask someone who has done it before.
## Saving Your Keymap for Future Edits
When you're satisfied with your keymap or just want to work on it later, press the `Export Keymap` button. It will save your keymap as the name you chose above appended with .json.
You can then load this .json file in the future by pressing the `Import Keymap` button.
!> **CAUTION:** This is not the same type of .json file used for kbfirmware.com or any other tool. If you try to use this for those tools, or the .json from those tools with QMK Configurator, there is a chance your keyboard will **explode**.
## Generating your firmware file
Press the green `Compile` button.
When the compilation is done, you will be able to press the green `Download Firmware` button.
## Flashing Your Keyboard
Please refer to [Flashing Firmware](newbs_flashing.md)
## Troubleshooting
#### My .json file is not working
If the .json file was generated with QMK Configurator, congratulations you have stumbled upon a bug. File an issue at [qmk_configurator](https://github.com/qmk/qmk_configurator/issues)
If not....how did you miss my big bold message at the top saying not to use other .json files?
#### There are extra spaces in my layout? What do I do?
If you're referring to having three spots for space bar, the best course of action is to just fill them all with space bar. The same can be done for backspace and shifts
@@ -86,7 +86,7 @@ If you know what bootloader that you're using, then when compiling the firmware,
### DFU
For the DFU bootloader, when you're ready to compile and flash your firmware, open up your terminal window and run the built command:
For the DFU bootloader, when you're ready to compile and flash your firmware, open up your terminal window and run the build command:
make <my_keyboard>:<my_keymap>:dfu
@@ -131,9 +131,19 @@ If you have any issues with this, you may need to this:
sudo make <my_keyboard>:<my_keymap>:dfu
#### DFU commands
There are a number of DFU commands that you can use to flash firmware to a DFU device:
* `:dfu` - This is the normal option and waits until a DFU device is available, and then flashes the firmware. This will check every 5 seconds, to see if a DFU device has appeared.
* `:dfu-ee` - This flashes an `eep` file instead of the normal hex. This is uncommon.
* `:dfu-split-left` - This flashes the normal firmware, just like the default option (`:dfu`). However, this also flashes the "Left Side" EEPROM file for split keyboards. _This is ideal for Elite C based split keyboards._
* `:dfu-split-right` - This flashes the normal firmware, just like the default option (`:dfu`). However, this also flashes the "Right Side" EEPROM file for split keyboards. _This is ideal for Elite C based split keyboards._
### Caterina
For Arduino boards and their close (such as the SparkFun ProMicro), when you're ready to compile and flash your firmware, open up your terminal window and run the built command:
For Arduino boards and their clones (such as the SparkFun ProMicro), when you're ready to compile and flash your firmware, open up your terminal window and run the build command:
make <my_keyboard>:<my_keymap>:avrdude
@@ -199,9 +209,17 @@ If you have any issues with this, you may need to this:
sudo make <my_keyboard>:<my_keymap>:avrdude
Additionally, if you want to flash multiple boards, use the following command:
make <keyboard>:<keymap>:avrdude-loop
When you're done flashing boards, you'll need to hit Ctrl + C or whatever the correct keystroke is for your operating system to break the loop.
## HalfKay
For the PJRC devices (Teensy's), when you're ready to compile and flash your firmware, open up your terminal window and run the built command:
For the PJRC devices (Teensy's), when you're ready to compile and flash your firmware, open up your terminal window and run the build command:
make <my_keyboard>:<my_keymap>:teensy
@@ -226,12 +244,61 @@ Waiting for Teensy device...
For a majority of ARM boards (including the Proton C, Planck Rev 6, and Preonic Rev 3), when you're ready to compile and flash your firmware, open up your terminal window and run the build command:
make <my_keyboard>:<my_keymap>:dfu-util
For example, if your keymap is named "xyverz" and you're building a keymap for the Planck Revision 6 keyboard, you'll use this command and then reboot the keyboard to the bootloader (before it finishes compiling):
make planck/rev6:xyverz:dfu-util
Once the firmware finishes compiling, it will output something like this:
```
Linking: .build/planck_rev6_xyverz.elf [OK]
Creating binary load file for flashing: .build/planck_rev6_xyverz.bin [OK]
Creating load file for flashing: .build/planck_rev6_xyverz.hex [OK]
@@ -6,7 +6,10 @@ QMK tries to put a lot of power into your hands by making easy things easy, and
# Getting Started
Before you can build keymaps, you need to install some software and set up your build environment. This only has to be done once no matter how many keyboards you plan to compile firmware for.
Before you can build keymaps, you need to install some software and set up your build environment. This only has to be done once no matter how many keyboards you plan to compile firmware for.
If you would prefer a more graphical user interface approach, please consider using the online [QMK Configurator](https://config.qmk.fm). Please refer to [Building Your First Firmware using the online GUI](newbs_building_firmware_configurator.md).
## Download Software
@@ -63,8 +66,10 @@ You will need to install Git. It's very likely that you already have it, but if
Once you have set up your Linux/Unix environment, you are ready to download QMK. We will do this by using Git to "clone" the QMK repository. Open a Terminal or MSYS2 MinGW window and leave it open for the remainder of this guide. Inside that window run these two commands:
?> If you already know [how to use GitHub](getting_started_github.md), we recommend that you create and clone your own fork instead. If you don't know what that means, you can safely ignore this message.
@@ -15,7 +15,17 @@ Note: These programs are not provided by or endorsed by QMK.
## Debugging With QMK Toolbox
[QMK Toolbox](https://github.com/qmk/qmk_toolbox) will show messages from your keyboard if you have `CONSOLE_ENABLE = yes` in your `rules.mk`. By default the output is very limited, but you can turn on debug mode to increase the amount of debug output. Use the `DEBUG` keycode in your keymap, or use the [Command](feature_command.md) feature to enable debug mode.
[QMK Toolbox](https://github.com/qmk/qmk_toolbox) will show messages from your keyboard if you have `CONSOLE_ENABLE = yes` in your `rules.mk`. By default the output is very limited, but you can turn on debug mode to increase the amount of debug output. Use the `DEBUG` keycode in your keymap, use the [Command](feature_command.md) feature to enable debug mode, or add the following code to your keymap.
```c
voidkeyboard_post_init_user(void){
// Customise these values to desired behaviour
debug_enable=true;
debug_matrix=true;
//debug_keyboard=true;
//debug_mouse=true;
}
```
<!-- FIXME: Describe the debugging messages here. -->
# Setting up Visual Studio Code for QMK Development
[Visual Studio Code](https://code.visualstudio.com/) (VS Code) is an open-source code editor that supports many different programming languages.
Using a full-featured editor such as VS Code provides many advantages over a plain text editor, such as:
* intelligent code completion
* convenient navigation in the code
* refactoring tools
* build automation (no need for the command-line)
* a graphical front end for GIT
* many other tools such as debugging, code formatting, showing call hierarchies etc.
The purpose of this page is to document how to set up VS Code for developing QMK Firmware.
This guide covers how to configure everything needed on Windows and Ubuntu 18.04
# Set up VS Code
Before starting, you will want to make sure that you have all of the build tools set up, and QMK Firmware cloned. Head to the the [Newbs Getting Started Guide](newbs_getting_started.md) to get things set up, if you haven't already.
## Windows
### Prerequisites
* [Git for Windows](https://git-scm.com/download/win) (This link will prompt to save/run the installer)
1. Disable all of the options but `Git LFS (Large File Support)` and `Check daily for Git for Windows updates`.
2. Set the default editor to `Use Visual Studio Code as Git's default editor`
3. Select the `Use Git from Git Bash only` option, since that's the option that you should use here.
4. For the `Choosing HTTPS transport backend`, either option should be fine.
5. Select the `Checkout as-is, commit Unix-style line endings` option. QMK Firmware uses Unix style commits.
6. For the extra options, leave the default options as is.
This software is needed for Git support in VS Code. It may be possible to not include this, but it is much simpler to just use this.
* [Git Credential Manager for Windows](https://github.com/Microsoft/Git-Credential-Manager-for-Windows/releases) (Optional)
This software provides better support for Git by providing secure storage for git credentials, MFA and personal access token generation.
This isn't strictly needed, but we would recommend it.
### Installing VS Code
1. Head to [VS Code](https://code.visualstudio.com/) and download the installer
2. Run the installer
This part is super simple. However, there is some configuration that we need to do to ensure things are configured correctly.
### Configuring VS Code
First, we need to set up IntelliSense. This isn't strictly required, but it will make your life a LOT easier. To do this, we need to create the `.vscode/c_cpp_properies.json` file in the QMK Firmware folder, You can do this all manually, but I've done most of the work already.
Grab [this file](https://gist.github.com/drashna/48e2c49ce877be592a1650f91f8473e8) and save it. You may need to edit this file, if you didn't install MSYS2 to the default location, or are using WSL/LxSS.
Once you have saved this file, you will need to reload VS Code, if it was already running.
?> You should see an `extensions.json` and `settings.json` file in the `.vscode` folder, as well.
Now, we will set up the MSYS2 window to show up in VSCode as the integrated terminal. This has a number of advantages. Mostly, you can control+click on errors and jump to those files. This makes debugging much easier. It's also nice, in that you don't have to jump to another window.
If there are settings here already, then just add everything between the first and last curly brackets.
?> If you installed MSYS2 to a different folder, then you'll need to change the path for `terminal.integrated.shell.windows` to the correct path for your system.
4. Hit Ctrl-` (grave) to bring up the terminal.
This should start the terminal in the workspace's folder (so the `qmk_firmware` folder), and then you can compile your keyboard.
## Every other Operating System
1. Head to [VS Code](https://code.visualstudio.com/) and download the installer
2. Run the installer
3. That's it
No, really, that's it. The paths needed are already included when installing the packages, and it is much better about detecting the current workspace files and parsing them for IntelliSense.
## Plugins
There are a number of extensions that you may want to install:
This installs a bunch of Git related tools that may make using Git with QMK Firmware easier.
* [EditorConfig for VS Code](https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig) - _[Optional]_ - Helps to keep the code to the QMK Coding Conventions.
* [Bracket Pair Colorizer 2](https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer-2) - _[Optional]_ - This color codes the brackets in your code, to make it easier to reference nested code.
* [Github Markdown Preview](https://marketplace.visualstudio.com/items?itemName=bierner.github-markdown-preview) - _[Optional]_ - Makes the markdown preview in VS Code more like GitHub's.
* [VS Live Share Extension Pack](https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare-pack) - _[Optional]_ - This extension allows somebody else to access your workspace (or you to access somebody else's workspace) and help out. This is great if you're having issues and need some help from somebody.
* [VIM Keymap](https://marketplace.visualstudio.com/items?itemName=GiuseppeCesarano.vim-keymap) - _[Optional]_ - For those that prefer VIM style keybindings. There are other options for this, too.
* [Travis CI Status](https://marketplace.visualstudio.com/items?itemName=felixrieseberg.vsc-travis-ci-status) - _[Optional]_ - This shows the current Travis CI status, if you have it set up.
@@ -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:
This file is used by the [QMK API](https://github.com/qmk/qmk_api). It contains the information [QMK Configurator](https://config.qmk.fm/) needs to display a representation of your keyboard. You can also set metadata here.
You can create `info.json` files at every level under `qmk_firmware/keyboards/<name>` to specify this metadata. These files are combined, with more specific files overriding keys in less specific files. This means you do not need to duplicate your metadata information. For example, `qmk_firmware/keyboards/clueboard/info.json` specifies `manufacturer` and `maintainer`, while `qmk_firmware/keyboards/clueboard/66/info.json` specifies more specific information about Clueboard 66%.
## `info.json` Format
The `info.json` file is a JSON formatted dictionary with the following keys available to be set. You do not have to set all of them, merely the keys that apply to your keyboard.
*`keyboard_name`
* A free-form text string describing the keyboard.
* Example: `Clueboard 66%`
*`url`
* A URL to the keyboard's product page, [QMK.fm/keyboards](https://qmk.fm/keyboards) page, or other page describing information about the keyboard.
*`maintainer`
* GitHub username of the maintainer, or `qmk` for community maintained boards
*`width`
* Width of the board in Key Units
*`height`
* Height of the board in Key Units
*`layouts`
* Physical Layout representations. See the next section for more detail.
### Layout Format
Within our `info.json` file the `layouts` portion of the dictionary contains several nested dictionaries. The outer layer consists of QMK layout macros, for example `LAYOUT_ansi` or `LAYOUT_iso`. Within each layout macro are keys for `width`, `height`, and `key_count`, each of which should be self-explanatory.
*`width`
* Optional: The width of the layout in Key Units
*`height`
* Optional: The height of the layout in Key Units
*`key_count`
* **Required**: The number of keys in this layout
*`layout`
* A list of Key Dictionaries describing the physical layout. See the next section for more details.
### Key Dictionary Format
Each Key Dictionary in a layout describes the physical properties of a key. If you are familiar with the Raw Code for <http://keyboard-layout-editor.com> you will find many of the concepts the same. We re-use the same key names and layout choices wherever possible, but unlike keyboard-layout-editor each key is stateless, inheriting no properties from the keys that came before it.
All key positions and rotations are specified in relation to the top-left corner of the keyboard, and the top-left corner of each key.
*`x`
* **Required**: The absolute position of the key in the horizontal axis, in Key Units.
*`y`
* **Required**: The absolute position of the key in the vertical axis, in Key Units.
*`w`
* The width of the key, in Key Units. Ignored if `ks` is provided. Default: `1`
*`h`
* The height of the key, in Key Units. Ignored if `ks` is provided. Default: `1`
*`r`
* How many degrees clockwise to rotate the key.
*`rx`
* The absolute position of the point to rotate the key around in the horizontal axis. Default: `x`
*`ry`
* The absolute position of the point to rotate the key around in the vertical axis. Default: `y`
*`ks`
* Key Shape: define a polygon by providing a list of points, in Key Units.
* **Important**: These are relative to the top-left of the key, not absolute.
* Example ISO Enter: `[ [0,0], [1.5,0], [1.5,2], [0.25,2], [0.25,1], [0,1], [0,0] ]`
*`label`
* What to name this position in the matrix.
* This should usually be the same name as what is silkscreened on the PCB at this location.
## How is the Metadata Exposed?
This metadata is primarily used in two ways:
* To allow web-based configurators to dynamically generate UI
* To support the new `make keyboard:keymap:qmk` target, which bundles this metadata up with the firmware to allow QMK Toolbox to be smarter.
Configurator authors can see the [QMK Compiler](https://docs.api.qmk.fm/using-the-api) docs for more information on using the JSON API.
@@ -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
Make example for this keyboard (after setting up your build environment):
make 1upkeyboards/1up60hte:default
See the [build environment setup](https://docs.qmk.fm/#/getting_started_build_tools) and the [make instructions](https://docs.qmk.fm/#/getting_started_make_guide) for more information. Brand new to QMK? Start with our [Complete Newbs Guide](https://docs.qmk.fm/#/newbs).
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.