* Port DIRECT_PINS from split_common/matrix.c to matrix.c
* Reorder matrix.c to remove foward declaration and match split_common/matrix.c
* Refactor nano to use DIRECT_PINS
* Reorder matrix.c to remove foward declaration and match split_common/matrix.c
* Add DIRECT_PINS documentation
* Reorder matrix.c to remove foward declaration and match split_common/matrix.c - fix logic from inherited from split_common
* Add DIRECT_PINS documentation - review comments
* Revert "Update build instructions and Dockerfile to download submodules"
This reverts commit 93210547bd.
* Update build tools docs based on feedback
* Fix bad link in build tools docs
* RGB Matrix overhaul
Breakout of animations to separate files
Integration of optimized int based math lib
Overhaul of rgb_matrix.c and animations for performance
* Updating effect function api for future extensions
* Combined the keypresses || keyreleases define checks into a single define so I stop forgetting it where necessary
* Moving define RGB_MATRIX_KEYREACTIVE_ENABLED earlier in the include chain
* Adds the Planck EZ, 3737 RGB, fixes out-of-tune notes
* fix bug in quantum/rgb_matrix_drivers.c
Co-Authored-By: jackhumbert <jack.humb@gmail.com>
* update command setting to the correct default
* correct rgb config
* remove commented-out lines
* update docs for the 3737
* Update docs/feature_rgb_matrix.md
Co-Authored-By: jackhumbert <jack.humb@gmail.com>
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
* Refactor 4x4 in line with current ps2avrgb template
* Add backlight pwm bodge till #4324 lands
* Disable bootmagic lite as it seems to not work on atmega32a/bootloadHID
* remove unneeded uart setting
* use pragma once everywhere
* remove custom matrix support
* fixup readme
* set bootmagic to lite
* remove dependency on custom i2c code
* use the right header files and function calls
* remove bootmagic support as it doesn't work on bmc boards
* readme merge artifacts removal
* pragma once it all
* put amnesia's name everywhere
* fixup readme
* remove custom matrix
* remove unneccessary configs
* disable bootmagic
* remove custom i2c in favor of i2c_master
* fix rgb led num
* add in rgb underglow support
* Refactor jj40 in line with current ps2avrgb template
* Disable bootmagic lite as it seems to not work on atmega32a/bootloadHID
* Add backlight pwm bodge till #4324 lands
* Increase planck keymap compatibility
* use pragma once
* modified readme with maintainer info
* remove rev1 for the time being
* QMK Configurator support for 60_ansi and 60_ansi_split_bs_rshift
* add hhkb layout and QMK Configurator support
* fix compile issue due to missing DEVICE_VER
* use a saner and less complicated default layout
* remove unused file
* fix up LAYOUT_all and formatting along with QKM Configurator support
* turn on bootmagic lite as the hardware reset switch isn't in a standard position
* remove default folder
* Added Waldo keyboard base files and default keymap
* Updated Waldo files and added keymap for split shift and split backspace
* Updated meta-data for the Waldo board
* Apply suggestions from code review
Committing suggestions for real this time.
Co-Authored-By: That-Canadian <Poole.Chris.11@gmail.com>
* Made suggested changes that were not explicitly made.
* Add keyboard Signum 3.0 for the elite-c
* Update readme.md
* Remove unused macros
* Use bootmagic lite instead of full
* Add warning to keymap.c that it's auto-generate
* Add description for customizing keyboard layouts
* Make generate_km.py executable
* Make right shift available in numpad layer
* Update keyboards/signum/3_0/elitec/readme.md
Co-Authored-By: jceb <jceb@e-jc.de>
* Update keyboards/signum/3_0/elitec/readme.md
Co-Authored-By: jceb <jceb@e-jc.de>
* Fix typo in symbol name
* remove dependency on custom i2c code
* missed a pragma once
* fix readme install instructions
* config.h cleanup
* make the bootmagic key not the same bmc reset key
* disable bootmagic functionality as it doesn't seem to work on atmega32a bmc boards
* remove custom i2c code in favor of QMK i2c_master
* clean up config file
* fix pyusb install instructions
* fix naming in usbconfig.h
* disable bootmagic as it does not work for bmc boards
* Update macros and keycode handling
- Update NUBS_Z macro so it repeats when held down
- Number row now uses numpad keycodes if Right Alt is being held
- coding conventions and formatting update
- switched to four-space indent
- reformatted a block comment
* Update readme files
* remove unneeded uart setting
* use pragma once everywhere
* remove custom matrix support
* fixup readme
* set bootmagic to lite
* remove dependency on custom i2c code
* use the right header files and function calls
* On i2c_init, enable two wire interface, twi interrupt, and slave
address ACK along with pull up resistors.
* thanks to some testing by drashna, we know that setting TWI doesn't work for all boards. Putting the new code into an ifdef block
* Add new keyboard: NQG
* Delete .gitignore
.gitignore removed
Originally used to ignore .DS_Store files from being committed.
* Changed Maintainer information
Maintainer link now points to a github account.
* Add customizable tapping terms
* Add Documentation
* Fix function
* Fixes
* It's not a pointer
* Add debugging output
* Update documentation to be at least vaguely accurate
* Use `get_tapping_term(tapping_key.event)` instead
`e` doesn't include column and row information, properly. It registers as 255, regardless of the actual keypress.
However `tapping_key.event` actually gives the correct column and row information. It appears be the correct structure to use.
In fact, it looks like the issue is that `e` is actually the "TICK" structure, as defined in keyboard.h
* Use variable tapping term value rather than define
* Silly drashna - tapping_key.event, not event
* add get_event_keycode() function
* Fix typo
Co-Authored-By: drashna <drashna@live.com>
* Remove post_process_record_quantum since it's the wrong PR
* Update quantum/quantum.c
Co-Authored-By: drashna <drashna@live.com>
* Better handle ifdef statement for permissive hold
Since we can't be sure that tapping term is actually 500
* Update quantum.c comments based on feedback
* Clean up get_tapping_term function
Clean up function so that users don't need to call the event function, and instead only check the keycode
* Add ability to run functionality on and off
* Make ifdef's more compact
* initial commit of budget96
* non logic changes
* add my name to readme
* update matrix.c
* make the matrix representation of the layout macro
* fix up LAYOUT macro
* add missing character
* initial keymap commit
* put KC_NO where they belong
* basic keymap
* fix matrix row and col definition
* The diagram I was sent and the pins used I was sent were in opposite order from each other. This should fix the issues
* update the readme
* change up manufacturer for budget96
* update copyright date
* fix up the switch matrix and provide a keymap
* forgot the keymap
* other matrix fixes
* missing a few keys in the switch matrix
* messed up the row tracing
* tweak keymap a bit
* use a lower case k
* fix spacing for markdown rendering
* put in the reset key documentation
* clean up the file a little
* use LAYOUT_96_ansi
* add a second layer for lighting controls
* add in lighting support
* add QMK Configurator support
* use pragma once
* remove un needed matrix.c
* convert to GPIO methods
* turn on rgblight_enable and get rid of custom matrix
* set bootloadhid_bootloader to 1
* set bootmagic to lite and set it to k50
* add reset information to readme
* use i2c_master instead of custom i2c
* restore the custom i2c code
* introduce reset key and eep_rst in function layer 1
* fix up pip3 install commands
* fix up device and manufacturer names
* remove un needed comments
* add an ALL layout macro along with QMK Configurator support
* move budget96 into donutcables directory since he actually has different boards
* add a short donut cables blurb taken from his website
* update readme for make instructions to point to the new path
* Update keyboards/donutcables/budget96/config.h
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update keyboards/donutcables/budget96/readme.md
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update keyboards/donutcables/budget96/info.json
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* turn on backlight
* Update keyboards/donutcables/budget96/readme.md
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* remove extra UART and BOOTLOADER settings that are not needed
* Added first configuration for handwired hacked motosped keyboard
* Added first keymap
* Fixed h file key layout
* Swapped Y and Z in default keymap
* Added name, email and description
* Moved hacked motospeed keyboard to handwired
* Changed make command in readme
* Formatted readme to be displayed properly with markdown
* Formatted keymap and layout to better reflect the physical keyboard
* Fixed info.json
* Update keyboards/handwired/hacked_motospeed/info.json
Co-Authored-By: Deckweiss <Deckweiss75@gmail.com>
* Removed .directory from .gitignore
Co-Authored-By: Deckweiss <Deckweiss75@gmail.com>
* Minor changes and cleanup
* Update keyboards/handwired/hacked_motospeed/hacked_motospeed.h
Added back newline needed for properly parsing
Co-Authored-By: Deckweiss <Deckweiss75@gmail.com>
* Adding new keymap folder for goadmaster
* add switch break
* zeal60 rgb backlight files
* modified for red caps lock key
* Remove return statement
* Files removed
* Add new RGB options
* Back to original file
* Keyboard: add treeadstone48
* rename layout defines
* Use of pragma once
* move common include code
* fixed info.json
* change keymap layout from kc to normal
* fix alpha revision keymap
* fixed info.json
* remove USE_Link_Time_Optimization
* Initial portover of the doro68.json with corrected column pins.
* Initial setup of LAYOUT_ansi and it's use in the default keymap.
* Added F keys to default kemap on layer 1.
* Added split space (and everything else) layout and a base keymap to be updated.
* Renamed split_space to multi.
* Changed product_id for doro.
* Created a basic doro LAYOUT_iso and default keymap.
* Copied over basic layout and keymap.
* Added readme.md for doro67 multi.
* Removed basic keyboad layout and keymap because it's a separate PCB.
* Added backlight controls to the various keymaps.
* Added explicit backlight pin define.
* Increased number of backlight levels for flexibility.
* Removed unnecessary line slashes and unified keymcaps.
* Corrected ISO layout and switched position with multi.
* Added keymap readme.md files.
* Corrected ISO keymap.
* Added Layouts to info.json for toolbox.
* Re-added slashes as they were necessary here...
* Corrected info.json/keymap discreptancies.
* Updated copyright messages (and fixed small readme error).
* Added missing line break spaces in readme.md
Co-Authored-By: ShadeDream <nick@shadedream.com>
* Keymap alignments on default_multi readme.md
Co-Authored-By: ShadeDream <nick@shadedream.com>
* Keymap alignments on default_multi readme.md
Co-Authored-By: ShadeDream <nick@shadedream.com>
* Keymap alignments on default_multi readme.md
Co-Authored-By: ShadeDream <nick@shadedream.com>
* Small alignment adjustment on the default keymap readme.md
Co-Authored-By: ShadeDream <nick@shadedream.com>
* use pragma once where applicable
* remove ?
* update default keymap readme
* remove un need include
* update readme with newbs guide
* set underglow and backlight to be on by default, and explicitly set them to no for the default keymap to handle the non Polestar case.
* put mine and benlyall's name in the code
* update readme
* port Massdrop CTRL/ALT to use RGB Matrix
Co-authored-by: Matt Schneeberger <helluvamatt@gmail.com>
* Massdrop lighting support working
This commit is to get the Massdrop lighting code working again through use of the compilation define USE_MASSDROP_CONFIGURATOR added to a keymap's rules.mk.
Added keymaps for both CTRL and ALT named default_md and mac_md. These should be used if the Massdrop style lighting is desired.
* Updating config based on testing results with patrickmt & compile errors
* Updates for PR5328
For CTRL and ALT:
Moved location of new RGB Matrix macros from config_led.h to config.h.
Added RGB_MATRIX_LED_FLUSH_LIMIT (time between flushes) to config.h for correct LED driver update timing.
Re-added missing breathing code for when Massdrop configurator mode is defined.
* remove prilik keymap form PR
* Implemented Eager Per Row debouncing algorithm.
Good for when fingers can only press one row at a time (e.g. when keyboard is wired so that "rows" are vertical)
* Added documentation for eager_pr
* Ported ergodox_ez to eager_pr debouncing.
* Removed check for changes in matrix_scan.
* Added further clarification in docs.
* Accidental merge with ergodox_ez
* Small cleanup in eager_pr
* Forgot to debounce_init - this would probably cause seg-faults.
* first [ass at pulling out common duck library functions
* use new library in jetfire
* use new library in duck lightsaver
* use new library in octagon v2
* put Device into the library
* refactor send_value
* refactor send_value and send_color
* use pragma once
* use pragma once
* use pragma once
* use pragma once
* rename backlight_led to indicator_leds to match with other duck boards
* rename enum
* make #define names consistent
* rename ducklib to duck_led
* update rules.mk ?= to =
* put rgb in the correct order
* add debounce debugging printouts
* turn on bootmagic lite and set it to the top left most key commonly programmed as Escape
* add reset key documentation
* fix that typo
* Update keyboards/duck/duck_led/duck_led.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* include the correct library
* initial commit
* get rid of some of the vanilla cookie cutter code
* Put in the matrix size and the pins
* add LAYOUT macro and a suitable keymap
* Add QMK Configurator support
* set bootmagic to lite
* put a RESET key into the default keymap
* edit kyuu readme file for description and quantrik.com link
* Update keyboards/quantrik/kyuu/config.h
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* fix captilization of keyboard name
* fix keymap wrapping issue and add MO key
* preserve RESET key location
* use one of the macros
* RGB Matrix overhaul
Breakout of animations to separate files
Integration of optimized int based math lib
Overhaul of rgb_matrix.c and animations for performance
* Updating effect function api for future extensions
* Combined the keypresses || keyreleases define checks into a single define so I stop forgetting it where necessary
* Moving define RGB_MATRIX_KEYREACTIVE_ENABLED earlier in the include chain
* Add tennie
* Jacobs Functions
* Switch back to normal layout
* Remove define from old template
* Fix broken keymaps
* Correct style errors, add bootlite
* Update readmes. Rename test keymap
* Missed comma
* Switch rgb from init to post init
Added Fantasie Impromptu and Nocturne Op. 9 No. 1 in B flat minor by Chopin
Added Isabella's Lullaby from The Promised Neverland
Added Renai Circulation and Platinum Disco from Monogatari
Added Terra's theme from Final Fantasy 6
* Updated iris, planck, and xd75 keymaps
* Added brightness down and up to commented layout of Symbol layer.
* updated config files for planck and iris
* removed unnecessary include lines from iris and planck config files
* updated XD75's PC layer and its NAVPC toggle layer
* fixed typo in alias declaration for C_BSPS
* changed alias names for BSPC toggle keys
The other bépo layouts were a bit too complex/weird or without LED code
and hard to transition to for new users. This config is a good base for
bépo users.
* Updated iris, planck, and xd75 keymaps
* Added brightness down and up to commented layout of Symbol layer.
* updated config files for planck and iris
* removed unnecessary include lines from iris and planck config files
* Fixed typo of 'confid.h' to 'config.h'
* Fixed broken links in docs
* Fixed a lot of dead links
* Removed all dead links that I could not find a replacement for
* Placed knops links back in
* Fixed plank keymaps so that they will compile for planck light
* Https doesn't work on knops.io
* tv44:budi now compiles
* s60_x:amnesia0287 now compiles
* Fixed allocation of key_combos so that narze keymap for planck can compile correctly
* Disabled rgb on ergodone and infinity
* Enabled tap dance so it compiles
* Added return statement so it compiles
* If compiling on light disable extra functionality
* Properly redefined variable so it compiles
* Remove remaining dead links
* Create custom Planck Light keycap
See README for details
* Link to WhatPulse in README
* More remapping, and add RGB LED effects
* Remove dead code, address PR feedback from @drashna
* Add macro for “screenshot region to clipboard” hotkey for macOS
Also remove unused layer / key logic
* Remove extraneous comment
* Incorporate PR feedback from @drashna.
Update README with new mapping.
* Add keycodes for new macros to keymaps
* add macros for commonly used shortcuts
* FIx macro code and add comments
* Replaced with build in QMK keycodes
* Removed macros that duplicated QMK keycodes
* The code in this directory supports the KBD65
* Update readme.md
* Update readme.md
* Clear up the confusion between the kbd67/kbd65 naming.
* Update keyboards/kbdfans/kbd67/readme.md
Co-Authored-By: Hackerpilot <briancschott@gmail.com>
* initial commit of e6v2 bmc files
* update readme with bmc template and reset key location
* fix up the switch matrix
* add usbconfig.h file
* add i2c files
* cleanup config.h
* cleanup rules.mk and remove non atmega32a architecture code
* add an appropriate keymap for testing
* update readme with warning not to flash this hex file onto atmega32u4 e6v2
* get rgb lights working
* add QMK Configurator support for 60_ansi layout
* add hhkb support layout
* add additional layouts such as tsangan and all and included QMK Configurator support for them
* add bootmagic lite, and have it be set to Esc or the key located at k50
* update readme
* fixup spacing for LAYOUT_all electrical matrix
* add some pragma once magic
* use i2c_master instead of custom i2c.c
* remove the custom i2c.c
* restore a more valid default keymap
* add eep_rst to keymap
* Add kwer keymap and RGB mod description to cypher
* Add custom led_set_user to keymap
* Remove unneccessary include path from keyboards/westfoxtrot/cypher/keymaps/kwer/keymap.c
Co-Authored-By: kwerdenker <sebastian.spindler@gmail.com>
* build size-check enhancement
Changed to display a warning when the free size of compilation result is less than 512 bytes.
* update message.mk
* add SIZE_MARGIN variable, change default margin 512 to 1024
for Example.
```
$ make SIZE_MARGIN=2048 crkbd:all
$ make crkbd:all ## mergin is 1024
```
* Update message.mk
change message to ‘approaching the maximum’
Co-Authored-By: mtei <2170248+mtei@users.noreply.github.com>
Added song of the ancients and kaine salvation fron Nier
Added Amusement park, Copied city, Vague Hope cold rain and weight of the world from Nier Automata
This PR is cherry-pick from 90b9a1aa7d in PR #5020.
@MxBlu copied quantum/rgblight.c to keyboards/mxss/rgblight.c on July 8, 2018. At that time, I think it would be better to copy quantum/rgblight.h at the same time.
Because if someone makes a change to `quantum/rgblight.[ch]` that is incompatible with the past, it may cause problems with the compilation of keyboards/mxss.
(Like when I changed the prototype of the `rgblight_effect_XXX()` functions of rgblight.c in PR #5020.)
* copy default over as starting point
* Getting rid of dvorak and colemak for now, added a couple changes to the
keymap
* removed refs to bad layers, formatting comments
* First version of my ergodox ported layout!
* Symbols layer, media layer, updated comments
* Hyper as a single key
* Fix stuck hyper key when switching layers
* Tweak some annoying things about the layout.
- move raise left and promote alt
- remove swap keys on the last layer
- reorganize media keys so they're easier to reach and more intuitive
- fix some comment template things
* Add readme for rjhilgefort planck layout
* readme tweak
* PR feedback changes
* Add support for wiring RGB LEDs for both halves directly to their respective controllers
RGB LEDs for each half don't need to be chained together across the TRRS cable with this
* Add split RGB LED support for serial
* Update config/rules for bakingpy layout
* Un-nest ifdefs for hand detection
* Read RGB config state from memory instead of EEPROM for serial updates
* Reuse existing LED pointer instead of creating new one
* Create custom Planck Light keycap
See README for details
* Link to WhatPulse in README
* More remapping, and add RGB LED effects
* Remove dead code, address PR feedback from drashna
* Adding new tap dance key
* Adding new tap dance code
* add code for copy/paste to tap dance
* testing tap dance enums
* New tap dance keycodes
* Fix enums
* handwired/magicforce61: refactor
Renamed layout macro KEYMAP to LAYOUT.
Keymap now uses #include QMK_KEYBOARD_H.
Refactored the default keymap to use non-auto-prepended keycodes per QMK standard.
Deleted deprecated action_get_macro block (was unused).
* handwired/magicforce61: Configurator support
* handwired/magicforce61: readme cleanup
Restructured the readme to be more similar to current QMK template.
* handwired/magicforce61: replace missing image in readme
Replaced the missing wiring image (error 404) with a table.
* handwired/magicforce61: rename readme to lowercase
* Convert config.h to #pragma once include guard
* rgblight.c: add RGBLIGHT_LED_MAP support
* add code to keyboards/helix/rev2/keymaps/five_rows/config.h to test rgblight.c:RGBLIGHT_LED_MAP
* Test end. Revert "add code to keyboards/helix/rev2/keymaps/five_rows/config.h to test rgblight.c:RGBLIGHT_LED_MAP"
This reverts commit e7488d6f73.
* update docs/feature_rgblight.md
* led_map[] move to PROGMEM
* introduce stt layout with K(row)(col)
* set bootmagic to lite
* Rename the original LAYOUT to LAYOUT_all
Introduce the STT layout
In additional the whole matrix was changed to support the K(row)(col) notation.
* rename LAYOUT to LAYOUT_all
* add QMK Configurator support
* stt keymap based on mrpetrov's default configuration on the hb85 he lent me
* update readme
* introduce basic and aop layouts along with QMK Configurator support for them
* add a new line
* add EEP_RST to layer 1 as it is needed to get rgb underglow to work
* add documentation on how to reset the eeprom on the board
* put contributors names where appropriate
* added Boy_.314's layout for halfnhalf keyboard
* reset rules.mk to default
* update keymap with qwerty layout, and enable tap dancing
* fixed formatting in layout visualization
* added rules.mk to custom layout
* added mod tap for ctrl/capslock
* fixed typo in config.h, remove excess in rules.mk, revert half_n_half rules.mk
* added Boy_.314's layout for halfnhalf keyboard
* reset rules.mk to default
* update keymap with qwerty layout, and enable tap dancing
* fixed typo in config.h, remove excess in rules.mk, revert half_n_half rules.mk
* added macros to raise layer
* fixed mismatched layout/comments
* fixed layout switching
* Remove unnecessary IS_COMMAND definition from clueboard/66_hotswap/gen1
* Remove old-style IS_COMMAND definition comment from dozen0
* Use get_mods() instead of keyboard_report->mods in georgi
* Recursively clone qmk_firmware repo
Specifically, so that it grabs the submodules, since ARM keyboards are becoming more common, and we are seeing more issues about chibiOS not being downloaded (in the error log, rather than by question)
* Wrap in shell
* keymap + alpha
* some fixes
* keymap + alpha
* some fixes
* drashna changes
* linked main Alpha repo in keyboards/alpha readme
* missed a spot
* there's another function called FUNC lol
* keymap + alpha
* some fixes
* keymap + alpha
* drashna changes
* Fixed include
* Revert "Fixed include"
This reverts commit ea92f261f8.
* messed up my git, fixed include
* starting work on TMO50 layout
* Update keyboards/tmo50/keymaps/default/keymap.c
Co-Authored-By: PyrooL <lm11887@gmail.com>
* Updated PyroL's TMO50 keymap
* Added task manager/Ctrl Alt Del that i stole from the eco keymap
* Clean up task manager and ctrl alt del macros
Co-Authored-By: PyrooL <lm11887@gmail.com>
* initial commit
* initial commit
* fixed indents
* spelling, capitalization, and order.
* added dota mode keymap, removed old comments
* fixed default keymap always having tilde, instead of grave accent and tilde. Improved dota keymap.
* lower does not change backspace to delete anymore
* corrected pgup/pgdown
* changed period on lower from numpad dot to regular dot
* added colemak and dvorak
* made colemak/dvorak border keys consistent with querty
* updated to match current practices, added custom metakeys for dvorak and colemak
* added disclaimer about audio
* renamed to lowercase
* replaced include guards with #pragma once
Co-Authored-By: rileyweber13 <rileyw13@protonmail.com>
* removed unncessary include
Co-Authored-By: rileyweber13 <rileyw13@protonmail.com>
* removed defines included in core
Co-Authored-By: rileyweber13 <rileyw13@protonmail.com>
* replace defines with an enum, switched from custom function to set_single_persistent_default_layer
* removed ifndef/include/endif left over from previous build system
* removed unnecessary ifdef block
* updated soungs to work with set_single_persistent_default_layer
* Instant 60
* Instant60 changes again
* turn off LSE and features
* Working RGB underglow 🎉
* Add missing files
* Update keymap to have reset
* Backlighting on
* Backlight code for instant60
* Move 072 files to common folder and use it in Instant60
* Updates
* Update keyboards/cannonkeys/instant60/rules.mk
Co-Authored-By: awkannan <andrew.kannan@klaviyo.com>
* add SCREEN_NAV layer for copy/pasting within screen
* working readreg/paste macros
* working read reg / paste macros
* write log and tran patterns, and expand
* add ls -la shortcut, add tab on combined layer
* put delete word on the right pinky key on shell_nav layer
* add TAB on the right side, add reset key
* added Cloud9 macros
* add cloud9 shortcuts to atreus layout
* added BROWSER_CONTROL layer
* finalized browser control layer
* adding comment
* add browser control layer to atreus
* add flashing command line
* remove the tab on combined layer
* remove the tomouse
* remove mouse layer, change log/tran expand patterns, cleanups
* add dumptlog macro
* add "delete to home" shortcut
* fix conflict
* remove unneeded mouse layer
* add meh shortcuts on the browser_control layer
* add/modify some macros
* explain the various layers
* putty paste is right mouse button
* add android studio shortcuts
* allow switching between base and alternate base layouts
* replace cloud9 shortcuts with android studio
* more android studio shortcuts
* add two meh shortcuts on keynav layer
* additional android studio shortcut
* added defines for android studio
* Updated layout after some months of testing.
The current setup looks quite better than the initial one. It's not
perfect but it allows me to work quite well.
The only big problem is the Alt modifiers on the home row which
sometimes break the typing if keys are pressed too fast. I'm also not
satisfied by the TAB key position on the thumb cluster.
Main improvements since previous push:
- Shift layouts on both halves
- Moved around symbols
- Improved number/fn keys
- Reorganized thumbs
* Used enum as suggested by @drashna :-)
* Corrected column count and adjusted layouts to include missing key
The original version reflected 14 columns and omitted KC_GRV, the 15th key on the top row. This revision adds support for the 15h key, and also updates the default (Tsangan) layout to include the HHKB layer keys.
* Reverted config.h to version in master branch
* Moved K413 to the correct location
* Added info.json
* Update keyboards/1upkeyboards/1up60hte/1up60hte.h
Co-Authored-By: newbold <adam@neatnik.net>
* Update keyboards/1upkeyboards/1up60hte/info.json
Co-Authored-By: newbold <adam@neatnik.net>
* Update keyboards/1upkeyboards/1up60hte/keymaps/default/keymap.c
Co-Authored-By: newbold <adam@neatnik.net>
* Update keyboards/1upkeyboards/1up60hte/keymaps/hhkb/keymap.c
Co-Authored-By: newbold <adam@neatnik.net>
* Update keyboards/1upkeyboards/1up60hte/keymaps/hhkb/keymap.c
Co-Authored-By: newbold <adam@neatnik.net>
* Update keyboards/1upkeyboards/1up60hte/keymaps/default/keymap.c
Co-Authored-By: newbold <adam@neatnik.net>
* fresh commit for a new fork for PR to upstream/master
* gaming mode added, lighting changes for other modes
* rules.mk fixed...
* fixed collision issue with aesthetic and shifty modes
* fixed collision issue with aesthetic and shifty modes
* troubleshooting game mode failing
* moved game tapdance key to default layer, fixed issue
* Align docker and vagrant base images - update box to debian 9.6
* Align docker and vagrant base images - lock docker image to debian 9
* Align docker and vagrant base images - update vagrant docker to debian 9
* added my own keymap
* changed thing
* updated keymap Samuel
* updated laypout for better one handed use
* updated stuff I want
* happy with my lagout
* formatting
* Added new literate config
* made everything nice
* cleaned
* fixed spelling and two small bugs in macros
* Made press and lift function for modifiers
* made taps occur on press instead of release
* added oneshot keys and chars cant be negative!
* removed debug message
* Added command and qwerty layers
* fixed bug with oneshot layer
* same bug, different key
Added Liebesleid by Kriesler (or Rachmaninoff), Michishirube from Violet Evergarden, Melodies of Life from Final Fantasy 9 and Eyes on Me from Final Fantasy 8
* Add nrichers keymap
* Additional keymap tweaks, add readme info
* Improve descriptions for changes from default keymap
* Add image of keymap, update .gitignore to
* Add image link
Adds an image of the modified keymap.
* Improve legibility of keymap changes with colour coding
* Tinker with color codes in Markdown
* Experiment with colour codes
* Tinker more with colour codes
* Figured out the easiest way to include colour coding
* Undo earlier .gitignore change
* Refactor layout macro names
Update the names of the layout macros to reflect QMK's desired usage.
- KEYMAP renamed to LAYOUT
- colinta keymap updated accordingly
- KC_KEYMAP renamed to LAYOUT_kc
- mtdjr keymap updated accordingly
* Update xd75.h to use #pragma once include guard
* Update keymaps to use QMK_KEYBOARD_H
* Refactor default keymap
- updated to use layout macro
- remove deprecated action_get_macro function
- add functions from QMK keymap.c template
- process_record_user
- matrix_init_user
- matrix_scan_user
- led_set_user
* Update supporting files
- updated config.h files to use #pragma once include guard
- remove errant QUANTUM_DIR code block
* Rename readme files to fully lowercase filenames
* Restructure keyboard readme
Updated the readme to better align with the current QMK template.
* Bugfixes to supporting files
* Make rgblight_update_dword not update eeprom (we already have
eeconfig_update_rgblight for that).
Make split i2c keyboards transfer active rgblight config rather than
eeprom saved version of rgblight config, enabling runtime changes
that aren't persisted to eeprom.
* prev_level and prev_rgb only store successfully transmitted values
* greenshadowmaker keymap for idobo xd75 massdrop
* remove uneeded config.h
* corrected format to match convention instead of xd75 where I accidentally started from
* Use correct functions for dip switch code
* Some planck cleanup
* Hopefully fix RGB Sleeping with RGB Matrix
* Add rgbmatrix extern
* Add numpad 5x6 layout
* RGB Tweaks
* Add RGB startup animation
* Minor RGB Fixes
* Turn off RBG on planck
* Enable separate storage of EEPROM
* Update Macro pad
* Add BJohnson Keymap and minor darshna tweaks
* Clean up rgb and other code for new numpad
* Remove clicky hachy thing
* Update my code to use built in MOD_MASK defines
* Fix up modifier calls
* Tweak to KC_MAKE
* Tweak to KC_MAKE
* Add Semi-colon to numpad
* Preprocess out rgb matrix stuff if not enabled
* Formatting of KC_MAKE
* Add stuff for matrix and light rgb coexistance
* Fix bad spelling
* Change where layer indication shows based on rgblight status
* Force set mods in KC_MAKE
* Optimize CRKBD
* added Boy_.314's layout for halfnhalf keyboard
* reset rules.mk to default
* update keymap with qwerty layout, and enable tap dancing
* fixed formatting in layout visualization
* added rules.mk to custom layout
* added mod tap for ctrl/capslock
* fixed typo in config.h, remove excess in rules.mk, revert half_n_half rules.mk
Added keymap for 60% board 1up60rgb. The map provides VIM-style navigation on a
second layer (L1) with HOME, PGDN, PGUP, and END keys on that same layer one
row below the home row. The layout is used by https://github.com/michaeldye.
* sleep until usb port becomes writable before running avrdude
* only wait for a writable USB port when not on MSYS
using MINGW or MSYS: sleep for one second, as before.
otherwise: wait for the port to become writable.
* typo
* typo
* Add satisfaction75 revision 1
* Update manufacturer
* Add tester layout and update rev1 comments
* Add ifdef guards for OLED for tester
* Add oled disabling rules
* Update to save backlight settings and setup for VIA custom config
* Add new VIA values to satisfaction75
* Safety guard in clock set mode
* Fix mistaken doc edit
* Address PR comments
* bring the default back to pass travis CI
* Address further PR comments
* Added 3 new songs and added new note type to musical_notes.h
Added Megalovania from Undertale, Kataware Doki from Kimi no Na Wa and La Campanella by Lizst to song_list.h
Added the breve (double whole note) and dotted breve note types to musical_notes.h. I included this because the default tempo is quite high, so I thought a note with higher
duration was needed
* Fixed indentation for new notes in musical_notes.h
Changed tabs to spaces in indentation
* 412_64 move to handwired
412_64 and its second printing, Mark Zero Stand Aside, are now obsolesced by new hardware. As only two units exist in the wild not owned by me, I'm moving the definition to handwired.
* Mark 3 Stand Aside ready for production.
Uploading firmware, compiled and tested, for Mark 3 Stand Aside. The hardware's ready, now the software is too.
* Whoops.
Should've branched before pushing Stand Aside. Sorry 'bout that.
* Revert "Whoops."
This reverts commit d222046cfe.
* Revert "Mark 3 Stand Aside ready for production."
This reverts commit c790899af7.
* Mark 3 Stand Aside ready.
Initial commit for Mark 3 Stand Aside, ready for production.
* Update keyboards/standaside/rules.mk
noroadsleft suggested removal of a line, 'LAYOUTS = ortho_4x16'. I agree.
Co-Authored-By: FateEverywhere <41215461+FateEverywhere@users.noreply.github.com>
* Cleanup for pull request.
Making changes requested by Drashna, as they're all good, and I know way less about the standards than they do.
* Initial cleanup completion.
Missed a few lines in standaside.c, they're cleaned up now.
* Update info.json
Adding layout for the macro version.
* Update info.json
Changed the macro layout to match exactly like the non-macro version (split backspace and bottow row match)
* added my launchpad
* updated keymap with legends and fixed layout errors
* Added default keymap with added layer for RGB controls and included the necessary config code
* fixed layer orders
* removed my personal keymap to clean PR
* missed an underscore
* updated readme
* removed more unnecessary code
* moved RGB code to its own config phone
* moved underglow info to its own readme
* removed redundant code from default_rgb config.h file, included QMK KEYBOARD H in place of initial defines in keymap.c
* reverted launchpad config
* removing the = because I can't figure out why its there
* Revert "removing the = because I can't figure out why its there"
This reverts commit e3b5e6d568.
* reverted rev1/config.h
* reverted all files I should not have touched
* removing redundant code in rules.mk
* readibility improvements to keymap
* Add ISO backslash key position to matrix and keymap files
* Use KC_NO instead of KC_BSLS for unused position in custom keymap
* Add new key position to json layout file used by online configurator
* Get things working except indicators
* Attempt to get things working
* hmm
* Compiles but doesn't run
* Make data transfer work
* Get all indicators working
* Remove old transport
* Prepare for pullreq
* Revert keymap from testing to production
* Final error checking for pull request
* Remove autogenerated is_command from config.h
* Rewrite pin toggles using qmk functions
* 412_64 move to handwired
412_64 and its second printing, Mark Zero Stand Aside, are now obsolesced by new hardware. As only two units exist in the wild not owned by me, I'm moving the definition to handwired.
* Mark 3 Stand Aside ready for production.
Uploading firmware, compiled and tested, for Mark 3 Stand Aside. The hardware's ready, now the software is too.
* Whoops.
Should've branched before pushing Stand Aside. Sorry 'bout that.
* Revert "Whoops."
This reverts commit d222046cfe.
* Revert "Mark 3 Stand Aside ready for production."
This reverts commit c790899af7.
* Update userspace with common config.h
* Add my dz60, satan and xd75 keyboard keymaps
* Fixing executable bits changed during last upstream merge
* Cleanup unnecessary files and defines
* Remove unnecessary defines from userspace config
* Add underglow controls to dz60 function layer
* Fixing merge conflicts
* Fixing exectable bits changed during merge
* Userspace update
* intial commit
* fix up some of the cookie cutter code
* define pins used and size of switch matrix
* enable lighting settings and bootmagic lite
* create the appropriate LAYOUT macro
* remove a comma for compilation errors
* provide a suitable keymap
* disable console and command due to firmware being too large
* add Caps Lock LED support
* Add QMK Configurator support
* fix markdown rendering
* fix mechmerlin to mechkeys
* use `register_code16` and relatives for tapdance code
* rename tapdance keys to more closely mirror the `KC` names in QMK
* additional naming change to match QMK style
* add a tapdance example for creating advanced mod-tap and layer-tap keys
* add optional curly braces to match QMK conventions
* change example to use `register_code16()` and tapdance keycodes more closely matching QMK variants
* Gray Studio HB85 Initial Support
* Fixed README image
* Updated README
* Disabled Bootmagic and Console for HB85
* Fixed Numpad 4 matrix place
* Fixes board crashing with RGB enabled
* Moved HB85 files to gray_studio folder
* Uses old i2c library since this version makes RGB underglow work
* Improved default keymap with underglow control layer
* Removes obsolete program and uses generic script instead
As per zvecr feedback
* Uses GPIO Functions to initialise and set RGB underglow PINS
* Add keycode for KC_MAKE
* Add KC_MAKE keycode
* Add stanrc85.c file with KC_MAKE
* Remove unused include
* Improved KC_MAKE stolen from Drashna
* Define mod mask for new KC_MAKE code
* RESET board to flash after compiling
* Remove send_string
* RESET fixed in KC_MAKE
* add dusty keymap
* change keymap folder to match my github username
* initial keymap completed in comments only
* layout without NAV completed in comments only
* disable Command to prevent interference with Space Cadet keys
* switch _ and \ in the symbol layer
* Layers complete through _NAV
* add thumb keys to _NAV
* complete _NUM
* all layouts complete; still needs `process_user_record()`
* completed first draft of keymap; still needs config.h to match
* corrected keycodes for Mac macro-volume keys
* fix Mac mute keycode
* add missing Mac keycodes for previous and next track
* placeholder for qwerty layout, not yet completed;
remove unnecessary breaks;
add todos
* eliminate Preonic branch before switching to Minidox branch:
• delete dustypomerleau Preonic keymap folder
• complete keymap.c (QWERTY layer, vanilla numbers layer)
TODO:
• add preferences to config.h
• complete the README
* edit commented keymap diagrams for clarity in dual function keys
* define initial config.h and add rules.mk for mouse key support
* fix redundant line after implementation of tap_code()
* fixed key_timer declaration, added README and rules
* formatting of keymap
* add CTPC to config
* cycle thumb keys to favor center position
* modify config.h for temporary Pro Micro compatibility
* remove superfluous call to use serial; homebrewed mod tap keys are still broken with OSL
* merge _SYS and _MEDIA on new Z_SYS key
* ALT_OP example of new MT macro complete
* initial narze-inspired MT fixes in PRU
* add (currently superfluous) custom keycode for the _SYS layer
* rudimentary `OSL` symbol macros that immediately register the mod and fail to reset the oneshot layer, but do output the proper keys—fix both of these things
* remove permissive hold to improve tapping performance
* remove calls to `clear_oneshot_layer_state()`, as they have no effect inside `process_record_user()`. Tapdance appears to be the way forward.
* final commit before tapdance code; correct layout in comments
* initial tapdance code for shifted mod taps
* add numeric and ergo NUM layers and pinky shifts for keycuts
* add TD() wrappers to tapdance codes and clean up commented layout guides
* add faux return to cur_dance to allow compilation - TODO: research what the default clause should be in cur_dance
* update commented schematics for better readability
* add backspace and delete to lockable layers, Z_SYS -> SYS_Z for consistency, fix schematic errors
* add `DOUBLE_SINGLE_TAP` to tapdance cases to allow doubling of the single tap character without waiting tapping term
* remove reduced oneshot tapping toggles
* update README
* newline tweak :)
* Update keyboards/minidox/keymaps/dustypomerleau/keymap.c
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* remove `PREVENT_STUCK_MODIFIERS`, as this is default behavior
* enable extrakey in rules to enable media keys
* enable extrakeys for media key compatibility on macOS
* add dash and slash to _NUM layers
* change to universal volume keycodes
* revert micro volume adjustments to macOS-specific codes due to lack of functionality (macro volume adjustments are still universal)
* fix image of _SYS layer in comments
* more diagram fixes in comments
* fix typo
* simplify tapdance code
* match _NUM_N to _NUM_E
* move slash to allow better use of comma in number layers
* match layer and keycode enums to the docs
* correct qwerty numlock to match numeric numlock layer
* Change how desktop commands work
* Add DST_MOD_MASK as a config option
* DST_RMV → DST_REM
* Add melody96:konstantin keymap
* Update custom SEND_STRING
* Move feature flags from userspace into keyboard rules
* Use "Vo-", "Vo+" instead of "VoD", "VoU" in keymap comments
* Add RGB controls and numpad Unicode to Melody96 keymap
* Add RGB_SET keycode to Melody96 and RGB files to userspace
* Generate UNICODE and UNICODEMAP constants using macros
* Avoid collisions with X_* send string constants
* Use two spaces before inline comments
* Add _keymap versions of other custom Quantum functions
Not added: eeconfig_update_keymap, eeconfig_read_keymap
* Switch to UNICODEMAP in keyboard rules
* Make toggle_numpad a nested function in process_record_user
* Set Melody96 underglow color to Godspeed blue on EEPROM reset
* Remove most _keymap and _user definitions in userspace
Some keyboards misuse _user functions by defining them in the base files
instead of the corresponding _kb functions (especially led_set_user and
matrix_init_user). Until this is fixed (#5148), I've removed definitions
in my userspace that could cause linking collisions.
* Update GODSPEED_BLUE values and RGB mode keys
* Add GODSPEED_YELLOW color
* Set preferred intervals for rgblight effects
* Update tap dance function names
* Replace td_lshift_fn with generic td_mod_layer, add TD_RCTL_FN
Move TD_FN_RCTL after TD_RCTL_FN
* Replace td_fn_rctrl with generic td_layer_mod
* Add blank lines, prefer explicit initialization
* ACTION_TAP_DANCE_DOUBLE_MODS → ACTION_TAP_DANCE_DOUBLE_MOD
* Update Godspeed colors
* Add media controls to Melody96 keymap
* Add SysRq, Break combos and other keys to Melody96 keymap
* Add HOME/END keys as upper/lower on arrow-up/down
* Reduce .hex file size by turning off unneeded options
* Put digit keypad onto left hand upon RAISE; this will sometimes be preferable to double-hits of right hand
* Latest super latest version merge
* cbbrowne keymap for XD75re
* starting notes on XD75re keymap plans
* First draft of bottom row of QWERTY
* Switch my special bottom line over to QCENT
* Dunno
* Filling in wanted keys, bit by bit...
* Add copyright, extra macro
* Clean up comments, remove some experimental code I didn't like
* TODO plans for xd75re
* clean up keyboard layout
* QCENT2 is my new experiment for the main keyboard...
* Add a few more main layer keys, and modify LOWER to shift things outwards to conform with main layer
* Clean up RAISE layer to conform with main layer, remove QCENT layer as QCENT2 is the new thing
* More xd75 changes, now that I actually have it in hand
* shift keymap around, as original attempt was a bit too aggressive in keeping to the edges
* more revs to XD75
* Dropping parts of the centre keypad in favor of Keys I Really Need
* Improve documentation to conform with how builds are done now
* Improve documentation to conform with how builds are done now
* Add cbbrowne rules file as alternative to having the rules in Makefile
* Makefile not needed anymore for individual keymap
* Some revs to my keymapping
* Add {}
* Add PGUP/PGDN
* Shifted some middle-range keys around
* Needed Tilde, Backquote, and to shift RESET onto FUNCTION layer
* Wanted ~
* cbbrowne hasn't anything to do with hadron keymaps
* trim unneeded bits
* I prefer OrgMode for my notes
* Have a right-alt
* Layer keys make LED colors change
* Add sample user rules for cbbrowne
* Add source of xd75 rules
* Individualized xd75 rules
* Adopt LAYOUT to genericize the layout as an ortholinear 5x15 keyboard
I'm a web designer and know there are several "decent" code editors out there, but I would figure not everyone into keyboards is, so I found Sublime text a bit of a hard sell for someone who just need to manipulate some text files. VS Code or Atom would b a much better suit for them instead of dropping $80 on a "decent" text editor.
* Tidy up 5x6.h
- replaced tabs with spaces (QMK convention)
- aligned layout macro visually
* Fix Configurator support for Dactyl Manuform 5x6
- layout macro had the wrong name in info.json
* Tidy up 5x7.h
- replaced tabs with spaces (QMK convention)
- aligned layout macro visually
* Fix Configurator support for Dactyl Manuform 5x7
- corrected keyboard height
- layout macro had the wrong name in info.json
* Tidy up 6x6.h
- replaced tabs with spaces (QMK convention)
- aligned layout macro visually
* Fix Configurator support for Dactyl Manuform 6x6
- layout macro had the wrong name in info.json
* Separate keymaps to VIA enabled/dissabled.
- Default rules.mk has been changed to disable via.
- VIA keymaps have been added for default keymaps.
* Update naming
* Add INSERT and EEP_RST to HS60 keymap
* Add INSERT to keymap
* Layer based RGB colors
* Move RGB code to layer_rgb.c
* New file with layer based RGB colors
* Use RGB code if RGBLIGHT is enabled
* Set RGB options in config.h
* Remove rgb enable from init user
Some keyboards misuse _user functions by defining them in the base files
instead of the corresponding _kb functions (especially led_set_user and
matrix_init_user). Until this is fixed (#5148), I've removed definitions
in my userspace that could cause linking collisions.
* Initial refactor of handwired bluetooth mod to keymap
* Initial refactor of handwired bluetooth mod to keymap - strip out unnecessary duplicate config, update readme
* Initial refactor of handwired bluetooth mod to keymap - reduce firmware size
* Initial refactor of handwired bluetooth mod to keymap - update readme image
* add dusty keymap
* change keymap folder to match my github username
* initial keymap completed in comments only
* layout without NAV completed in comments only
* disable Command to prevent interference with Space Cadet keys
* switch _ and \ in the symbol layer
* Layers complete through _NAV
* add thumb keys to _NAV
* complete _NUM
* all layouts complete; still needs `process_user_record()`
* completed first draft of keymap; still needs config.h to match
* corrected keycodes for Mac macro-volume keys
* fix Mac mute keycode
* add missing Mac keycodes for previous and next track
* placeholder for qwerty layout, not yet completed;
remove unnecessary breaks;
add todos
* eliminate Preonic branch before switching to Minidox branch:
• delete dustypomerleau Preonic keymap folder
• complete keymap.c (QWERTY layer, vanilla numbers layer)
TODO:
• add preferences to config.h
• complete the README
* edit commented keymap diagrams for clarity in dual function keys
* define initial config.h and add rules.mk for mouse key support
* fix redundant line after implementation of tap_code()
* fixed key_timer declaration, added README and rules
* formatting of keymap
* add CTPC to config
* cycle thumb keys to favor center position
* modify config.h for temporary Pro Micro compatibility
* remove superfluous call to use serial; homebrewed mod tap keys are still broken with OSL
* merge _SYS and _MEDIA on new Z_SYS key
* ALT_OP example of new MT macro complete
* initial narze-inspired MT fixes in PRU
* add (currently superfluous) custom keycode for the _SYS layer
* rudimentary `OSL` symbol macros that immediately register the mod and fail to reset the oneshot layer, but do output the proper keys—fix both of these things
* remove permissive hold to improve tapping performance
* remove calls to `clear_oneshot_layer_state()`, as they have no effect inside `process_record_user()`. Tapdance appears to be the way forward.
* final commit before tapdance code; correct layout in comments
* initial tapdance code for shifted mod taps
* add numeric and ergo NUM layers and pinky shifts for keycuts
* add TD() wrappers to tapdance codes and clean up commented layout guides
* add faux return to cur_dance to allow compilation - TODO: research what the default clause should be in cur_dance
* update commented schematics for better readability
* add backspace and delete to lockable layers, Z_SYS -> SYS_Z for consistency, fix schematic errors
* add `DOUBLE_SINGLE_TAP` to tapdance cases to allow doubling of the single tap character without waiting tapping term
* remove reduced oneshot tapping toggles
* update README
* newline tweak :)
* Update keyboards/minidox/keymaps/dustypomerleau/keymap.c
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* remove `PREVENT_STUCK_MODIFIERS`, as this is default behavior
* enable extrakey in rules to enable media keys
* enable extrakeys for media key compatibility on macOS
* add dash and slash to _NUM layers
* change to universal volume keycodes
* revert micro volume adjustments to macOS-specific codes due to lack of functionality (macro volume adjustments are still universal)
* keymap + alpha
* some fixes
* keymap + alpha
* some fixes
* drashna changes
* linked main Alpha repo in keyboards/alpha readme
* missed a spot
* there's another function called FUNC lol
* keymap + alpha
* some fixes
* keymap + alpha
* drashna changes
* Fixed include
* Revert "Fixed include"
This reverts commit ea92f261f8.
* messed up my git, fixed include
* starting work on TMO50 layout
* Update keyboards/tmo50/keymaps/default/keymap.c
Co-Authored-By: PyrooL <lm11887@gmail.com>
* Removed since options are in userspace
* Removed RGB option that was breaking one of my builds
* Remove unused options
* Removed options present in userspace, add board specific options here
* Removed code also present in userspace
* Turns out those lines were needed, added them back
* Testing changes
* Added code to ensure board read as ANSI instead of default ISO for HS60
* Setting \ key to "MOD" instead of "ALPHA" for lighting
* enable velocikey for my userspace and explicitly for my 75% layout
* add guards to only turn on RGB stuff if the RGB pin is actually defined
* update 60_ansi keymap
* update the 60_ansi_split_bs_rshift keymap
* update 66_ansi keymap
* update docs
* Update layouts/community/60_ansi/mechmerlin-ansi/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update layouts/community/60_ansi_split_bs_rshift/mechmerlin-split/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update layouts/community/60_ansi_split_bs_rshift/mechmerlin-split/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update layouts/community/66_ansi/mechmerlin/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update layouts/community/60_ansi_split_bs_rshift/mechmerlin-split/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update layouts/community/60_ansi/mechmerlin-ansi/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update layouts/community/60_ansi/mechmerlin-ansi/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* remove my attempt to find a good way to detect this
* move audio clicky into user space and do feature setting per keyboard
* fixup 66_ansi keymap
* update changelog
* update readme
* Added personal keymaps for Planck, Preonic, Vitamins Included by Juno
* Removing redundancies as suggested
* More removals that were missed out in the previous commits
* Updated Preonic to use new layout
* More redundancies missed out
* Updated more optimal code for FN layer LED indicator.
* Further codes clean up.
* Added a dual windows/osx layout
Default layer is normal ISO for windows. Second layout is Windows ISO layout but for OSX, but with the keys corrected so you will get the correct shifted and alt'd keys on OSX (keyboard keys match OSX keys without having to change your keyboard type in system preferences). Layer three is configuration and other functions, and layer four is where the shifting magic happens. Also tab and caps lock have been swapped around.
* made sure bootmagic is in a seperate rules.mk
made sure bootmagic is in a seperate rules.mk
* commiting the keymap rules.mk
commiting the keymap rules.mk
* Convert community layout to userspace for future use
* Big readme update
* Move layer toggle to CAPS
* Readme updates
* Deleted since unused
* Removed call to unused .c file
* [keymap] adding my Levinson keymap
pretty self explanatory, added the readme, just in case
tested it just now, seems to work fine for my needs
* Update keymap.c
removing the deprecated persistent layer function as Drashna kindly reminded me
* Apply suggestions from code review
incorporated the suggestions, and thanks again for taking care of me with my silly changes :)
Co-Authored-By: OMGVee <mateescu.victor@gmail.com>
* Fix up audio calls
* Add backlight controls
* Add backlight controls and remove RGB underglow
* Make HS60 board specific changes to readme
* Remove BL_TOGG as it isn't use on this board
* use #pragma once
* get rid of code for unused indicators
* pragma once and other small fixes for consistency
* use #pragma once
* pragma once and other small fixes for consistency
* add a short blurb to the readme
* turn on compiler optimization flags
* remove the compiler optimization
* remove compiler optimization for super16
* pragma once and turn on bootmagic lite
* pragma once changes and turning on bootmagic lite
* switch to using pragma once
* switch to using #pragma once
* switch to using #pramga once
* convert tabs to spaces
* fix#4578: don't call gemini protocol code when in bolt mode
Add missing break; statements in switch. The missing break resulted in
a fall through and an additional processing of the gemini code.
* Initial Clueboard 66% arm support
* Fix LAYOUT_66_ansi
* wip
* Bring this branch up to date with led_matrix
* Get Clueboard 66% hotswap working with led_matrix
* stm32 cleanup
* Fix compiling for clueboard 66% hotswap prototype
* Reduce the size of the prototype firmware
Many instances in the QMK Docs referenced KEYMAP macros, which is outdated terminology.
Replaced most instances of KEYMAP with LAYOUT, to reflect the desired usage.
* Draft commit of typing speed RGB control
* More information in the readme
* Support all RGB animation modes (Fixes#1)
* Added support for all RGB light modes to use typing speed
Except christmas lights because that is seizure-inducing at high speeds!
* Introduced a value range specific to each RGB mode
Because some modes are a little too much when running at full speed!
* Update readme.md
* Update readme.md
* Re-arrange typing_speed definitions (Fixes#5) (#6)
* Re-arrange variable definitions to avoid including quantum.h from rgblight.c
* Fix a compilation error when trying to run make test:all
* Tweaks to the typing speed decay rate
* Renamed to momentum; moved implementation into dedicated files
* Groundwork for toggling momentum on/off (currently always on)
* Add EEPROM toggle for momentum-matching
* Moved momentum out of RGBLIGHT_ENABLE toggles so it's more generic
* Move momentum decay task out of rgblight_task()
* Fix missing momentum.h in lufa.c
* Experimental LED support (untested)
* Draft commit of typing speed RGB control
* More information in the readme
* Support all RGB animation modes (Fixes#1)
* Added support for all RGB light modes to use typing speed
Except christmas lights because that is seizure-inducing at high speeds!
* Introduced a value range specific to each RGB mode
Because some modes are a little too much when running at full speed!
* Update readme.md
* Update readme.md
* Re-arrange typing_speed definitions (Fixes#5) (#6)
* Re-arrange variable definitions to avoid including quantum.h from rgblight.c
* Fix a compilation error when trying to run make test:all
* Tweaks to the typing speed decay rate
* Renamed to momentum; moved implementation into dedicated files
* Groundwork for toggling momentum on/off (currently always on)
* Add EEPROM toggle for momentum-matching
* Moved momentum out of RGBLIGHT_ENABLE toggles so it's more generic
* Move momentum decay task out of rgblight_task()
* Fix missing momentum.h in lufa.c
* Added documentation
* Renamed feature to velocikey
* Reverted readme to original state
* Correct the readme title
* Updated feature name in the docs
* Update EECONFIG name
* Add compile-time toggles for velocikey
* Update feature documentation
* Revert "Merge branch 'led-support' into master"
This reverts commit e123ff5feb, reversing
changes made to df111a55b9.
* Move velocikey EECONFIG definition to depend on VELOCIKEY_ENABLE
* Rename decay_task function to decelerate
* Apply suggestions from code review
Co-Authored-By: chrislewisdev <chris@chrislewisdev.com>
* Re-order eeconfig definitions
* Apply coding conventions
* Apply #ifdef check in lufa.c
* Refactored interval time checks into one functionc
* Small rename
* Fix unused function error for layouts not using all rgb effects
* Only update EEPROM if Velocikey is enabled
* Incorporate code review feedback
* Small adjustment to top-end decay rate
* Add Velocikey documentation to table of contents
* Bring tetris:default keymap size down by disabling audio
Descriptions for B5_AUDIO, B6_AUDIO, and B7_AUDIO under Hardware Options were partially italicized when parsed by Docsify, though rendered as intended by GitHub.
* initial commit
* get rid of vanilla cookie cutter code and replace with more correct info
* edit config file for pins and switch matrix size
* turn on bootmagic lite, and backlight/rgb settings
* copy pasta switch matrix from noroads tool
* create an appropriate keymap (copy pasta)
* disable some features to decrease firmware file size
* add qmk configurator support
* add in support for caps lock, scroll lock, and num lock leds
* add temporary pdhelix(Patched Helix) code
* add test code into quantum/split_common/matrix.c
* add test code into keyboards/handwired/pdhelix/
* Revert "add test code into keyboards/handwired/pdhelix/"
This reverts commit 9ed98f0797ddd962c99756689fc4ecb4cd067d3d.
* Revert "add test code into quantum/split_common/matrix.c"
This reverts commit 1876d3ed69f6c213153a9f6476192be839f16c1f.
* Revert "add temporary pdhelix(Patched Helix) code"
This reverts commit 41ac92b814e3f894eaf85bc3e5bb945895342fa8.
* fix quantum/split_common/matrix.c: select_col()/select_row()
* Changed use of '\s' in grep to '[ \t]' for portability
* Pushed DFU Keyboard.h into a shell script
* Fixed execution permissions on make_dfu_header,sh
* introduce wkl directory and readme
* move bface into winkeyless directory and edit readme for new make instructions
* move bmini into the winkeyless directory and edit readme
* move bmini ex into winkeyless directory
* edit readme some more
* add newbs guide to readmes
* fix path to bface
* temporarily turn off community layout support until we refactor this taking out all the custom ps2avrgb stuff
* Change Command keycode defaults to match corresponding Bootmagic codes
* Make alternate magic key keycodes consistent
* Reflect changes from previous commit in tmk_core/common/command.c
* Remove unnecessary MAGIC_KEY_* definitions from keymaps compatible with these changes
* Swap E and BSPACE for MAGIC_KEY_EEPROM
* Add MAGIC_KEY_EEPROM_CLEAR instead of MAGIC_KEY_EEPROM_ALT
* Remove BOOTMAGIC_ENABLE checks around EECONFIG stuff
* Update Command descriptions
* initial work to add eeprom to haptic feedback and decouple the feedback process from keyboards
* Haptic feedback enhancements: on/off toggle working, feedback order working
todo:
-work on modes switching
-get modes switching to save to eeprom
* haptic enhancement - eeprom and modes added
* Added set and get functions for haptic feedback
* initial implementation of solenoids under haptic feedback
* changed eeprom to 32 bits to reserve blocks for future features
* start documentation of haptic feedback
* change keycode per comment from reviewers
* typo fixes
* added eeprom for solenoid configs
* added solenoid and docs
* Add/fix default parameters configs, improve docs
* more doc cleanup
* add in solenoid buzz toggle, clean up doc
* some fixes for error in compiling solenoid
* fix a chibios specific i2c read function and added one for AVR controllers in DRV2605L.c
* fixes for avr side issues
* update keymap
* fix keymap compile error
* fix bugs found during solenoid testing
* set pin that is not powered during bootloader
* added warning about certain pins on the MCU may trip solenoid during DFU/bootloader
- flags for the linker
- added INSERT key as I kinda use it for work fairly often
- turned on more things in rules.mk since I recovered space via linker
flags and whatnot
Based on conversation with Drashna on Discord, we know that if ONE_SHOT_TAP_TOGGLE is 5, then tapping a one shot mod key 5 times holds the one shot key permanently, but to come out of this, you need to press the same key only once.
* Add support for using ranges for RGB
This patch adds support for controlling continuous ranges of RGB LEDs.
Helper functions for split boards are also available.
* RGB Range: Use hardware-platform agnostic wait
* Update KC_GESC documentation
- document caveats on OSX and expected behavior with KC_GESC and GUI
- clarify documentation slightly
- give examples of expected output in actual use
* Update OSX -> macOS
* Captilization
* remove simply
* added my own keymap
* changed thing
* updated keymap Samuel
* updated laypout for better one handed use
* updated stuff I want
* happy with my lagout
* formatting
* Added new literate config
* made everything nice
* cleaned
* fixed spelling and two small bugs in macros
* Made press and lift function for modifiers
* Remove problematic unicode_map stub definition in process_unicodemap.c
* Add unicode_map declaration to process_unicodemap.h
* Disable UNICODEMAP on converter boards that don't use it
* Added xeal60 via clone of lets split
* Delete removed other keymaps
* Basic keymap (no FN). Compiles.
* Removed NP_STAR and NP_SLSH.
* Removed "debounce_algo = manual" in all keyboards with CUSTOM_MATRIX = yes.
* Changed order of rules in TMK. Documented feature.
* Fixed missing whitespace in debounce documentation
Table wasn't working due to missing newline.
* Added bold in a few areas.
* DO NOT USE - Removed debounce from TMK.
* Remove accidental xeal60 commit
* DO NOT USE - debounce successfully compiled.
* DO NOT USE Revert back to original API to support split_keyboards.
* Working eager_pk
* Whitespace cleanup.
* Restored debounce.h since there wasnt any real change.
* Moved debouncing_time variable to inside #if debounce
* Removed check for custom_matrix. We can safely include the debounce file for compilation when custom_matrix is used.
* Removed #include "matrix.h" from debounce.h
* Bug fix - was using MATRIX_ROWS instead of num_rows
* Fixed compilation error with debounce_sym_g
* Renamed DEBOUNCE_ALGO to DEBOUNCE_TYPE
* Malloc array in debounce_eager_pk, since split keyboards only use MATRIX_ROWS/2.
* Fix compile error in debounce_eager_pk
* Stricter, leaner DEBOUNCE_TYPE section in common_features.mk. Cleanup debounce_type.mk
* Add suspend functions
* Disable RGB code if it's disabled
* Add keyboard_init functions
* Change where references so it will compile
* Wrong command chained in wake up kb function
* Fix non-feature file changes
* Add documentation
* Re-add matrix init docs
* add rgblight code to example
* Remove suspend code
* Clean up docs
* Fix docs
* Fix suspend code
* more doc fixes
* change function to startup_* rather than keyboard_init_
* fix spelling error
* fix up docs to finish removing keyboard_init
* Use Pre and Post init functions
* Update Documenation
* Remove changes to my keymap and userspace code
* Cleanup
* Revert changes to extra files
* Forgot a semicolon
* Make sure all protocols call keyboard_setup
* Cleanup functions
* Unset startup_user
* Remove changes from division keyboard
* Readd startup_user function
* Remove all to startup_user
* Update docs/custom_quantum_functions.md
Co-Authored-By: drashna <drashna@live.com>
* Update docs/custom_quantum_functions.md
Co-Authored-By: drashna <drashna@live.com>
* Add suggestion line
* Rebase fixes
* Update documentation to be more useful/accurate
* Cleanup of documentation
* Fix spacing inconsistency
* Revert unexpected change to keymap
* Add a mechanism for force building a particular community layout
* Add docs for FORCE_LAYOUT argument
* Update output name when FORCE_LAYOUT is enabled
* Don't click if turning audio off
On ARM, playing the click when turning off audio causes the audio get stuck and continually play the tone
* Fix Audio EEPROM support for ARM
* Update touched files to conform to QMK Coding Conventions
* Add better check for ARM EEPROM support
* Migrate fn_actions for default keymaps
* Rename the Grave/Escape Shift masks
* No need for shift_esc_shift_mask
* Change breaks to return false
* Right align pointers
* Add default case
* Separate cases with empty lines
* NUBS_Z: initial version
Create a keycode that is normally Z, but KC_NUBS when tapped while Alt is being held.
This removes the possibility of using an Alt+Z shortcut.
* NUBS_Z: modification
Modify NUBS_Z macro to only use alternate operation if Right Alt is being held, rather than responding to either Alt key.
Also add QMK version keycode to System layer, Equals key.
* Remove unneeded breaks from process_record_user
* Macro refactoring
- removed G_RST and G_C10R macros
- updated G_BRCH macro
- outputs `master` if used while Shift is held down; or my git alias for the current branch otherwise
- updated G_FTCH macro
- outputs `git pull upstream ` if used with Shift; `git fetch upstream ` otherwise
- swapped `modifiers` variable for `get_mods()` function directly for checking modifier state
- swapped keymap-level modifier mask macros for QMK-core mod mask macros (thanks vomindoraan #4337)
- renamed MODS_RALT_MASK to MOD_MASK_RALT (more consistent with the above change)
* Update readme files
* set bootmagic from no to lite and put in a note in the readme
* use pragma once
* discovered a compile error when testing with default keymap. The inlined led functions need to be externed in the .c file
* might as well turn on mouse keys as well
* [Keymap] Adding buhearns keymap
* Removing deprecated function
with fauxpark's help
* Update readme.md
* Switching to UNICODE_ENABLE
with drashna's help
* Update rules.mk
* Update config.h
* Update config.h
Tidying up
* Update keymap.c
Tidying up
* Update readme.md
Tidying up
* Update rules.mk
Tidying up
* Removing GESC and adding TILD
* initial commit with edits to vanilla code
* Add QMK Configurator support
* add an appropriately generated keymap
* pins, matrices, and features added in
* moved it all to a regular directory. It's called regular as that's what it's called in the group buy. In the future we will have other directories for the other PCBs that are delivered to customers.
* forgot caps lock led support
* Update keyboards/doro67/regular/keymaps/default/config.h
Use the NAME
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update keyboards/doro67/regular/readme.md
Be more explicit
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Add stm32f072 base ck4x4 to handwired
* add prints
* Save these tries
* Save changes again
* Working hadron oled
* OLEd working but ws2812b still iffy:
* save another try
* Encoder feature + OLED
* RTC code
* Implement clock setting mode
* Whitespace
* Encoder hooked up to working LED PWM code
* Add missing files
* eeprom changes
* Save changes
* Move i2c master
* Move satisfaction75 under cannonkeys
* Set proper default folder
* Revert some core changes
* Undo paved iris changes
* Reorganize code for maintainability and prep for new features
* Add starting code for clock OLED mode
* Clock set mode finished
* Add custom encoder modes
* Actually add VIA keymap
* Gate to only 072
* fix gate for only 072
* Update header guards and includes
* Update i2c selection strategy
* Update board.c to handle software reset to DFU
* add dusty keymap
* change keymap folder to match my github username
* initial keymap completed in comments only
* layout without NAV completed in comments only
* disable Command to prevent interference with Space Cadet keys
* switch _ and \ in the symbol layer
* Layers complete through _NAV
* add thumb keys to _NAV
* complete _NUM
* all layouts complete; still needs `process_user_record()`
* completed first draft of keymap; still needs config.h to match
* corrected keycodes for Mac macro-volume keys
* fix Mac mute keycode
* add missing Mac keycodes for previous and next track
* placeholder for qwerty layout, not yet completed;
remove unnecessary breaks;
add todos
* eliminate Preonic branch before switching to Minidox branch:
• delete dustypomerleau Preonic keymap folder
• complete keymap.c (QWERTY layer, vanilla numbers layer)
TODO:
• add preferences to config.h
• complete the README
* edit commented keymap diagrams for clarity in dual function keys
* define initial config.h and add rules.mk for mouse key support
* fix redundant line after implementation of tap_code()
* fixed key_timer declaration, added README and rules
* formatting of keymap
* add CTPC to config
* cycle thumb keys to favor center position
* modify config.h for temporary Pro Micro compatibility
* remove superfluous call to use serial; homebrewed mod tap keys are still broken with OSL
* merge _SYS and _MEDIA on new Z_SYS key
* ALT_OP example of new MT macro complete
* initial narze-inspired MT fixes in PRU
* add (currently superfluous) custom keycode for the _SYS layer
* rudimentary `OSL` symbol macros that immediately register the mod and fail to reset the oneshot layer, but do output the proper keys—fix both of these things
* remove permissive hold to improve tapping performance
* remove calls to `clear_oneshot_layer_state()`, as they have no effect inside `process_record_user()`. Tapdance appears to be the way forward.
* final commit before tapdance code; correct layout in comments
* initial tapdance code for shifted mod taps
* add numeric and ergo NUM layers and pinky shifts for keycuts
* add TD() wrappers to tapdance codes and clean up commented layout guides
* add faux return to cur_dance to allow compilation - TODO: research what the default clause should be in cur_dance
* update commented schematics for better readability
* add backspace and delete to lockable layers, Z_SYS -> SYS_Z for consistency, fix schematic errors
* add `DOUBLE_SINGLE_TAP` to tapdance cases to allow doubling of the single tap character without waiting tapping term
* remove reduced oneshot tapping toggles
* update README
* newline tweak :)
* Update keyboards/minidox/keymaps/dustypomerleau/keymap.c
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* Update keyboards/minidox/keymaps/dustypomerleau/config.h
Co-Authored-By: dustypomerleau <dustypomerleau@users.noreply.github.com>
* remove `PREVENT_STUCK_MODIFIERS`, as this is default behavior
* Grab HEX and BIN files from autogen
And push them to qmk.fm/compiled
* Make autogen copy extension agnostic
This way, when travis cl scrpit looks for hex files, it will actually grab bin files, and not hex files for ARM boards
* Handle the AUTOGEN in :bin target to properly handle edge cases
Both the TADA68 and ATSAM boards generate the hex file and then convert it to a bin file. The changes I made does not handle this well, at all. This removes the hex and replaces it with a bin, if a bin is normally generated.
* Revert hex target to original copy command
* Check hex and bin separately in compile push script
Since I don't know how to script this, well
* Simplify push to compiled folder
* Further simplify compiled push script
* Move AUTOGEN parsing to a more sane location to prevent tech debt
Thanks to skully!
* Remove AUTOGEN completely, as it's not needed
This has the benefit of making everything super simple, since we can pull every hex and bin from the root of the qmk_firmware folder, and move that to th compiled folder. This also removes old and unneeded code, and removes some tech debt that has been accrued, without adding more, in theory.
* Tweaks to default 1up60hte layout + support for HHKB style layout
* Added changes to layouts
* Fix config.h
* Fixed errant KC_NO in layout
* Added readme to keyboard... Will update with images/store link when avail.
* Update to use LAYOUT_60_hhkb default layout
* md formatting fix
* Update keyboards/1upkeyboards/1up60hte/readme.md
Co-Authored-By: bubnick <bubnick@users.noreply.github.com>
* Update keyboards/1upkeyboards/1up60hte/readme.md
Co-Authored-By: bubnick <bubnick@users.noreply.github.com>
* Added layout to rules.mk, fixed layout to be compatble with community HHKB keymaps
* Added image, updated store page to readme
* Add userspace files for vosechu
* Code review corrections
* Few more code review corrections
* Initial add of Laptreus code
* Initial add of Laptreus code
* Adding last punctuation to default
* Add some debug suggestions to the debug readme
* Fixes for PR feedback
* Fixing capitalization of readme files
* update auto detect connection logic
* remove unneeded file
* make an appropriate readme
* amend the LAYOUT macro to adhere to new QMK standards and create an appropriate keymap
* add QMK Configurator support
* a bunch of changes lol
* delete unneeded routines
* update date to modern times
* remove a useless prototype
* add in drashna's suggestions on PR
* Improvement of Space Cadet Shift by preventing to automatically apply a modifier on the key and allow to override the default modifier. Closesqmk/qmk_firmware#3815
* Improve the use of the DISABLE_SPACE_CADET_MODIFIER flag to avoid unregistering KC_LSFT when equals to LSPO_MOD
* change #if to if statement
* Added callbacks to one shot modifier changes
* Altered signature of callback functions
* Reordered the callback methods, shortened brief documentation
* Added One Shot Modifier callback documentation
* First attempt at unit tests
* Revert "First attempt at unit tests"
This reverts commit 5ec21a7822.
* Simplified oneshot function implementations
* Made clear_oneshot_locked_mods to be conform action_util.h, adhering to the (void) signature
* Made used datatypes for oneshot mods consistently unsigned integers
* Corrected callback to call clear callback when clear_oneshot_locked_mods is invoked
* Simplified oneshot equals statements
* Corrected return type and signature of get and set oneshot locked mods
* Consolidated one shot callbacks, added initial layer callback version
* Fixed non-updating one shot layer variable after timeout or other clear, added code comments
* Added better one shot key docs
* added keyboard jj4x4, a shorter version of the jj40
* removed useless file
* edited jj4x4 readme.md
* optimized array size in jj4x4 config.h, removed reference to jj40 layouts from rules.mk
* removed custom matrix for this ps2avrgb board, refactored column and row pins
* fix a bug in which the physical matrix did not match the physical layout. Top row was missing 1 key and bottom row had 1 extra key
* amend keymap to account for the new physical matrix
* 6.25u space bar is actually supported, so add a new layout that supports this
* fix keymap readme to no longer need the cautionary warning
* Moving sentraq keyboards to sentraq subdirectory.
* Updating readme markdown to correct make commands.
* Updating s60_x references to point to the new vendor subdirectory.
* Fixed stripped spaces in markdown.
* Updated help information in s60_x readme and linked to additional documentation.
* Make QMK Configurator work with e7-v1
This adds the missing info.json file for the e7-v1 keyboard which I
forgot to add to the original PR.
This allows to see the correct layout in QMK Configurator.
* Fix the ISO layout
The ISO layout has one extra key (hash/tilde) on row 3 right before
the enter key.
The e7-v1 PCB has this key wired at the same switch as the ANSI
backslash (since this switch is not used in ISO).
The tkl_ansi layout had an incorrect value for the grave/tilde key, and
number row keys were misnumbered. This fix removes the typo and adds the
missing K1C key.
* Fix mixed tabs and spaces in adb_usb and m0110_usb makefiles
* Fix typos in converter build options
* Tweak ordering and spacing in converter makefiles
* initial commit
* Do a nice write up for readme
* establish switch matrix and physical layout
* Put in the pins that are used
* QMK configurator support and keymap
* set bootloader to caterina because pro micro boohoo
* add ortho_4x4 support for user spaces
* got the columns reversed lol
* Tweaks to default 1up60hte layout + support for HHKB style layout
* Added changes to layouts
* Fix config.h
* Fixed errant KC_NO in layout
* Added readme to keyboard... Will update with images/store link when avail.
* Update to use LAYOUT_60_hhkb default layout
* md formatting fix
* Update keyboards/1upkeyboards/1up60hte/readme.md
Co-Authored-By: bubnick <bubnick@users.noreply.github.com>
* Update keyboards/1upkeyboards/1up60hte/readme.md
Co-Authored-By: bubnick <bubnick@users.noreply.github.com>
* Added layout to rules.mk, fixed layout to be compatble with community HHKB keymaps
* Create ISO HHKB keymapping for GH60
* Add media controls to Fn layer
* Use M(x) instead of F(x), add Copyright text
* Add README for additional information about TMO50 features/quirks
* Add indicator LED code
* Move indicator code to tmo50.c
* move over kbd19x into the kbdfans directory
* move over kbd4x into the kbdfans directory
* move kbd66 into the kbdfans directory
* move the kbd6x into the kbdfans directory
* move kbd8x into the kbdfans directory
* move kbd75 into the kbdfans directory
* move kbd67 into kbdfans directory
* add a fairly sparse readme for kbdfans directory
* update make instructions for keyboards and add the Complete Newbs Guide to readmes that was missing it
* get kbd75 compiling again
* remove repetitive #defines of KC_NO and KC_TRNS when QMK_KEYBOARD_H is already included in KBD75
* add links to kbdfans readme
* fix some readme formatting
* there is no reason to have two different keymaps with such a small difference, condensing to one
* turning on backlights by default
* enable backlight by default for kbd66
* noticed that the kbd75 had caps lock led code in every keymap. Moved it out to the keyboard.c so everyone can partake.
* Update keyboards/kbdfans/kbd66/readme.md
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* update readme link ordering
* Added QMK Config for Sentraq Number Pad keyboard.
* Sentraq Number Pad documentation cleanup.
* mend
* Added json for configurator.
* Small documentation tweaks.
* Updated the layouts to use the default layouts that match.
* Uncommended user level functions in keymap, left custom keycode/macro code commented but documented why.
* Switched to #pragma once from #ifndef structure in header file.
* Moved Sentraq number pad to sentraq creator directory.
* Renamed sentraq_number_pad to number_pad now that it's nested in the sentraq directory.
* Updated references inside the files for the keyboard rename and nesting.
* Adds keymaps for muzfuz
* Remove unused keys from adjust layer
* Bring in line with current QMK standards.
* Adds Preonic and adjusted Planck keymaps
* Make changes per review request
* update reset sequence info
* fix my rgb underglow led number flub
* add a more sensible keymap
* add caps lock led support
* remove unused #define
* swap the spacebar sizes around to match the space65
* use vomindoraan's suggestion in PR to use IS_LED_ON
* fixed arrow keys and left control
* added right shift
* latest version
* reverted arrow keys
* edited readme
* added osu layer
* updated osu layout
* updated osu layout
* added full arrow keys to osu layout
* in case i mess up creating macros
* added the best meme key in the world
* added plover steno layer
* updated boy314 layout
* removed unused layers
* added boy314 xd75 layout, inspired by preonic layout
* added boy314 xd75 layout, inspired by preonic layout
* version 2 of boy314's xd75 layout
* added readme notes
* updated readme for boy314 xd75 layout
* qwerty support, brackets on bottom row, caps lock underglow
* fixed readme/
* small changes to allow merging
* minor changes to format
* fixed up default readme
* added numpad and tweaked bottom row
* updated xd75 and preonic rev3 keymaps
* added initial half n half files
* fixed .h file
* updated names
* fixed layout in halfnhalf.h
* fixed manu name, changed bootloader in rules.mk
* removed redundancies in preonic and xd75 layouts
* readme updated
* initial commit
* get rid of vanilla code, and fix formatting
* write up a nice looking readme
* add in pins and enable features
* define keymap and switch/physical matrix
* add QMK Configurator support
* switch to bootmagic lite to decrease file size
* Move boards to cannonkeys and share resources
* Share common files between cannonkey boards
* Fix ortho60 keymap
* update LED numbers
* Add RGB keys to Ortho60 and Ortho48
* Add Backlight control to default layout Ortho60 and 48
* Remove unnecessary ws2812.c SRC from rules.mk
* Make Default standard layout
Move Mac OS layout to a separate layout. Basically Mac has the Alt and GUI keys swapped
* Fix typos
* Use Bootmagic keys instead of separate MacOS keymap
* Create ISO HHKB keymapping for GH60
* Add media controls to Fn layer
* Use M(x) instead of F(x), add Copyright text
* Add README for additional information about TMO50 features/quirks
* handwired/space_oddity: refactor
- config.h: updated to use #pragma once include guard
- rules.mk: replace `?=` with `=`
- space_oddity.h:
- updated to use #pragma once include guard
- layout macro KEYMAP renamed to LAYOUT
- default keymap:
- updated to use #include QMK_KEYBOARD_H
- replace references to Planck keycodes
- replace fn_actions-powered layer switch keycode
- rebuild keymap block comments
- keymap layers now use short-form keycodes
- refactor action_get_macro keycodes into process_record_user
* handwired/space_oddity: Configurator support
* handwired/space_oddity: readme cleanup
- update readme to better conform with QMK template
- fixed the make command.
* Add the e7-v1 keyboard
The e7-v1 is a 75% keyboard made by Exclusive based on an Atmega32u4
pub with RGB lights on top and backlighting.
This PR add supports for the regular ANSI layout and ANSI split
backspace layout. No ISO yet :(
* My e7-v1 keymap
Difference from base layout:
* split backspace
* Home & End on last keys of row 0 instead of Insert/Del
* Fn is on the End key when hold
* supports both a windows/linux keymap and osx keymap
* layer change is reflected in the rgb leds of the logo
* [BACKLIGHT_CAPS_LOCK_INDICATOR] Use backlight toggling as Caps Lock LED
I've implemented this feature because S65-X doesn't have LED indicators
and the existing led_set_kb(usb_led) function try to use backlight as
indicator but that creates an inconsistency with backlight_config state.
- define `BACKLIGHT_CAPS_LOCK_INDICATOR` to enable Caps Lock indicator
using backlight (for keyboards without dedicated LED)
- Don't turn off LED indicators when suspend because backlight is
already turned off. Else led_set(0) will turn back on backlight.
- Documentation has been updated
* [BACKLIGHT_CAPS_LOCK_INDICATOR] Turn off all LED indicators except Caps Lock if BACKLIGHT_CAPS_LOCK_INDICATOR
* [BACKLIGHT_CAPS_LOCK] Rename BACKLIGHT_CAPS_LOCK_INDICATOR
* [BACKLIGHT_CAPS_LOCK] Use new IS_LED_ON method
The following layouts were being rendered with 6.75u Spacebars instead of 7u:
- LAYOUT_ansi_blocker_7u
- LAYOUT_ansi_blocker_7u_small_lshift
- LAYOUT_ansi_blocker_7u_small_bspc
- LAYOUT_ansi_blocker_7u_small_lshift_small_bspc
- LAYOUT_iso_blocker_7u
This commit corrects this issue.
Flagged by yanfali on QMK Discord.
- layout macro and keymap layers refactored to more closely resemble physical keyboard layout
- added layout mockup to alice.h
- correct info.json data (was missing a key)
* Added southpole keyboard
added southpole keyboard folder and files including keymaps folder. Keymaps have errors and will not compile yet
* Add files via upload
added manufacturer and product name and description
* Update config.h
* Add files via upload
changed formating added layer
* cleaned up files, fixed foobeard keymap, and added maker info
* fixed keymap files
* Update keyboards/southpole/keymaps/foobeard/keymap.c
Co-Authored-By: ericduns <ericduns@gmail.com>
* Update keyboards/southpole/keymaps/default/keymap.c
Co-Authored-By: ericduns <ericduns@gmail.com>
* made changes fixing outdated lines and added readme.md
* made requested changes for pr to all files
* removed vs code and added new line to southpole.h
* moved some stuff around on my iris layout, but don't expect a lot of changes in the future
* good working setup
* [keymap] some mods to my (omgvee) Helidox keymap
* updated zlant keymap with diagram
* made edites to last post
* noticed slight error in default keymap due to my own mistake. fixed to be the same as default
* fixed spacing in second base layer second row from left
* Added xealousbrown keyboard.
* Changed to pragma once in config.h
* Update keyboards/handwired/xealousbrown/rules.mk
Added bootloader.
Co-Authored-By: alex-ong <the.onga@gmail.com>
* Update keyboards/handwired/xealousbrown/config.h
Commented out IS_COMMAND() since it is already default value.
Co-Authored-By: alex-ong <the.onga@gmail.com>
* Remove duplicated or unnecessary definitions in config.h and rules.mk
* Use IS_HOST_LED_ON() macro
* Add mouse acceleration to kbd6x:konstantin keymap
* Clear and restore mods when sending macros
* Make SEND_STRING_CLEAN a config option
* Add NO_ACTION_ONESHOT to userspace config
* Add files via upload
* Changed _____ to _______ as requested to meet QMK standards.
* Added readme.md
* Removed "PERMISSIVE_HOLD" as it is no longer used.
* Additional code changes made per request
* Added # to first line and removed redundant line.
* Modified Copyright information
* Added space after # for proper formatting
* Formatting changes and additional details
* Remove unnecessary IS_COMMAND definition in clueboard/66/rev4
* Replace keyboard_report->mods with get_mods() in IS_COMMAND definitions
* Update docs to use get_mods() instead of keyboard_report->mods
* Replace keyboard_report->mods with get_mods() in tmk_core/protocol/usb_hid/test
For some reason, this occurrence used KB_LSHIFT and KB_RSHIFT, which don't exist
* Replace keyboard_report->mods with get_mods() in Massdrop keyboards (as per @patrickmt)
* Move Iris via support to Via keymap
And move it out of the main keyboard files
* Actually add via keymap folder
Because using git when you're tired is apparently a very bad idea, and you do stupid things like not running git add
* Clean up config.h file for iris via keymap
* Add default value for IS_COMMAND for COMMAND feature
* Cleanup and consistency
* Update Templates to reflect change
* Fix IS_COMMAND in template
* Fix IS_COMMAND define
* Use consistent IS_COMMAND block in templates
* Remove unnecessary `#undef IS_COMMAND` directives
* Fix compile issue on orthodox
* Reomve IS_COMMAND option for newer boards
* Remove all existing definitions of IS_COMMAND if they use default LSHIFT and RSHIFT setting
* Remove a couple of additional IS_COMMAND defines
* Remove remaining redundant IS_COMMAND definitions
* Remove #undef IS_COMMAND from orthodox:drashna and whitefox:konstantin
* Remove multiple empty lines in modified config.h files
* Update additional boards
* Reomve IS_COMMAND from newer boards
* Update Alice keyboard
* Remove IS_COMMAND from additional boards
Jan 24th edition
* Only re-enable RGBLIGHT if it was on when going to sleep
* Reformat file to follow QMK Standards
* Fix check, since this is a loop, whoops
Much thanks to @Rockman18 for catching this and posting the additional code!
* Add ability to animate arm_atsam led matrix from the center of a circle
* Make arm_atsam led matrix circular animation circular rather than obloid
* Fix indentation in tmk_core led_matrix.c
* Basic Fanoe support (no LED yet)
* Enable RGB lights
* Backlighting support
* Change to reflect Wheat Field brand of Fanoe PCB
* Hot swap variant
* Fix review comment issues
* Fix review issues
* Corrected rules.mk
* Change naming to avoid using possibly copyrighted names
* Added info.json
* Corrected manufacturer name in info.json
* Keymap updates
* Add layout for use with ws2812b and such
* Fixes based on code review
I think `quantum.h` should contain only API declarations that `quantum.c` provides externally. `rgb.h` contains function weak definitions. This should not be in `quantum.h`.
I worked on those keymap to simplify the use of 60% keyboards for
coders. Instead of trying to mimic planck, this keymap remove
raise/lower layer complexity and keep some important sign keys for coder
in the upper right side pretty much the same way as they are on a full
keyboard.
A karabiner configuration is also provided to mimic most of the keymap
features on the macbook internal keyboard for when you are forced to use
it.
* Adding documentation for the LM layer modifier.
This will hopefully clear up some of the confusion around adding this layer modifier. I struggled with this a bit as well at first.
* Removing duplicate table.
* Changed section title to `Changing Layers`
* Retain name
* Custom keymap.
* Fix magic layer, enable Unicode.
* Update README.
* Make Unicode config change keymap-local.
* Move magic to AltGr, simplifying layout.
* Changes per Drashna.
* Fix magic+esc = backtick!
* Change reset implementation per Drashna's suggestion.
* Add a few more symbols so long as the commit is open - √ℜℂℤ⊙ℚℕ and the like.
* Typo fix.
* Slight simplification, drop an extra variable.
* Added busby222 config
* Fixed bug with leftover colemak and dvorak layouts
* Fixing dumb mistake
* Minor tweaks to layout. Need to use at work tomorrow to make more adjustments
* Added mouse controls for raised layer
* Update keymap.c
* Update keymap.c
* Update keymap.c
* Update keymap.c
* Update keymap.c
* Update config.h
Added mouse specific settings for smoother mouse movement (default is sort of hard to use)
* config.h cleanup
* Lowering max mouse speed (personal preference)
* Update keymap.c
* Update keymap.c
* Update keymap.c
* Update keymap.c
* Update keymap.c
* Update config.h
* Update rules.mk
* Added MIDI layer
* Switched the Adjust layer to an MO call
* Update keymap.c
* Fixing bugs related to midi layer
* Changed "Caps Lock" ctrl to RCTRL for use in VirtualBox
* Added shovelpaw keyamp
* Removed deprecated QUANTUM_DIR code block
* Switched midi layer to be only active when held
* Addressing requested changes
* Removed unnecessary include statement
* initial commit
* move the original kbd67 stuff into its own directory, rev1
* get rid of vanilla cookie cutter code
* put in the switch matrix pins, backlight pin, and rgb underglow pin. Number of underglow LEDs is questionable.
* switch matrix created for hotswap
* create a basic keymap for testing
* make info.json for QMK Configurator support
* rename kbd67 due to compile error
* kbd67 generic readme file
* fix make instructions for the new rev1
* comment out unneeded rgb light #defines
* Update keyboards/kbd67/readme.md
Add an extra space for proper markdown rendering
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update keyboards/kbd67/hotswap/hotswap.h
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* Update keyboards/kbd67/hotswap/keymaps/default/keymap.c
Co-Authored-By: mechmerlin <30334081+mechmerlin@users.noreply.github.com>
* use pragma once
* proper format of MechMerlin
* Cluecard: refactor
- renamed layout macro KEYMAP to LAYOUT
- reformatted layout macro to more closely resemble physical device layout
- keymaps now use #include QMK_KEYBOARD_H
- config.h files updated to use #pragma once method
- deleted outdated QUANTUM_DIR code blocks from rules.mk files
- white space changes on rules.mk files (alignment/readability)
* Cluecard: Configurator support
* Cluecard: readme update
- added image
- updated Docs links
* Clueboard 66% HotSwap: corrected matrix and Configurator data
- removed k31 and k84 from LAYOUT
- both appear to be unsupported for this PCB according to images on clueboard.co
- updated block comment mock-ups to match changes
- rebuilt info.json file
- delete removed keys from default keymap.c
* Clueboard 66% HotSwap: readme update
- fix make example
- updated Docs links
* Clueboard 66% HotSwap: 66_ansi keymap update
Updated to use #include QMK_KEYBOARD_H
* Clueboard 60% refactor
- renamed layout macro KEYMAP to LAYOUT_all
- renamed layout macro KEYMAP_AEK to LAYOUT_aek
- removed redundant KC_TRNS definitions from keymaps
- all keymaps now use #include QMK_KEYBOARD_H
* Clueboard 17%: refactor
* Clueboard 17%: Configurator support
* Clueboard 17%: update Docs links in readme
* Cleanup the 2x1800 files
* Update Clueboard 60% to standard matrix
* Update the clueboard default keymaps
* Refresh and update clueboard 17
* Add the 66% hotswap to Clueboard's readme
* Clarify the 66% hotswap's readme
* change the image to imgur
* Update the clueboard 66 to follow modern standards
* update clueboard 66_hotswap to follow modern practices
* Move the logo to imgur
* update clueboard/card to follow modern practices
* remove clueboard/66 as a valid make target
* Address comments in #4902
* fix user keymaps after the changes
When this if statement is false, it will cause the report ID to be read as the LED state.
We already know there are two bytes in the endpoint, which is a reasonably good indicator that it contains a report ID, so we should always read both.
* Added TGR Alice keyboard support
This keyboard uses ps2avrGB firmware, so I used the same matrix
Bootmapper Client was using and was able to flash it appropriately.
* Refactor alice to use QMK core
* Fixed markdown line breaks on TGR Alice readme
* handwired/retro_refit: refactor
- retro_refit.h
- updated to use #pragma once include guard
- refactored layout macro to not auto-prepend KC_ to keycodes
- renamed to LAYOUT (from KEYMAP)
- aligned for readability
- default keymap.c
- now uses #include QMK_KEYBOARD_H
- removed unused fn_actions and action_get_macro blocks
* handwired/retro_refit: Configurator support
* handwired/retro_refit: readme update
Updated readme to format of current QMK template.
* Create ISO HHKB keymapping for GH60
* Add media controls to Fn layer
* Use M(x) instead of F(x), add Copyright text
* Create initial firmware for TMO50
* Correct year and author
* Fix repos README
* Remove unnecessary code
* Change include guard in tmo50.h
* Plain60: remove redundant include guard from plain60.h
Superseded by #pragma once.
* Plain60: add Docs links to readme file
* Plain60: Configurator support
* new hhkb keymap implementing movement layer + comfort features
* Apply suggestions from code review
Co-Authored-By: schaefer-dev <schaefer.dev@gmail.com>
* removed deprecated function action_get_macro and mousewheel configs that are no longer used
* handwired/reddot: refactor
- reddot.h
- updated to use #pragma once include guard
- renamed layout macro KEYMAP to LAYOUT
- refactored arguments to more closely resemble physical layout
- aligned for readability
- keymaps/default/keymap.c
- now uses #include QMK_KEYBOARD_H
- updated include path for keymap_french.h
- refactored to use short keycodes
- aligned for readability
* handwired/reddot: Configurator support
* handwired/reddot: readme update
- update readme to current QMK template
- add KLE permalink to my best guess at the layout
* Initial support for TKC Candybar
* Correct FN layer issue
Both shift keys were overloaded. Moved Caps Lock to FN + C.
* Update keyboard description in config.h.
* Info.json
* Update project information
* Update keyboards/candybar/readme.md
Co-Authored-By: TerryMathews <terry@terrymathews.net>
* handwired/qc60: refactor and Configurator update
- correct layout macro name (LAYOUT_ANSI_DEFAULT to LAYOUT_ansi_default)
- add layout data for remaining layout macros
- correct ISO layout macros (neither had a split left Shift)
- refactor LAYOUT_iso_alt (place KC_NUHS key on home row; consistent with LAYOUT_iso_default)
- proto.h refactored to use #pragma once include guard
* handwired/qc60: keymap refactor
- delete redundant KC_TRNS and KC_NO aliases
* handwired/qc60: readme update
- update header (made consistent with QMK template)
- update Docs links (Newbs Guide; grammar)
* handwired/ortho60: Configurator update
- correct labels for Up and Right keys
- add layout data for LAYOUT_1x2uC
* handwired/ortho60: readme update
- update readme file to use QMK template
* handwired/ortho60: deleted DEFAULT_FOLDER rule
Not needed as the keyboard currently has no revisions.
* TKC1800: refactor
- tkc1800.h
- updated to use #pragma once
- visual alignment
- update config.h files to use #pragma once
- update all keymaps to use #include QMK_KEYBOARD_H
- delete redundant mod mask, KC_TRNS, and KC_NO definitions
- reformat keymap layers for readability
- add block comment for Function layer in default keymap
- delete commented action_get_macro code blocks (deprecated function)
- update files to better conform with QMK coding conventions
- update smt keymap to use set_single_persistent_default_layer (instead of persistent_default_layer_set)
- replace instances of `?=` with `=` in rules.mk
* TKC1800: Configurator visual fixes
- correct key sizes and positioning
- reformat file so each physical key object has its own line for readability
- update and add `label` keys for readability
* TKC1800: readme update
- fix image gallery link
- update Hardware Supported and Hardware Availability lines
- update make example (add :default suffix)
- update QMK Docs links (Newbs Guide; grammar)
* Add missing semicolons to smt keymap
* Grammatical fixes for GPIO Control doc
I found the Advanced Settings section to be poorly written.
* Commit suggestions from fauxpark
* Change first instance of "microcontroller" to match suggestion
Discovered the LAYOUT_compact macro didn't compile in QMK Configurator. Realized the reason for that was that it automatically prepends `KC_` to every keycode received.
Renamed the macro to LAYOUT_kc so Configurator will ignore it.
Also changed the file to use the #pragma once include guard because I was in here anyway.
* change VENDOR_ID, PRODUCT_ID, and DEVICE_VER as step one in getting VIA support
* fix v1 product id
* VIA doesn't use the version, so we need to encode it into PRODUCT_ID
* Defined IS_(HOST_)LED_ON/OFF() and improved LED documentation
* Update docs/custom_quantum_functions.md
Co-Authored-By: DidierLoiseau <didierloiseau+github@gmail.com>
* Update docs/custom_quantum_functions.md
Co-Authored-By: DidierLoiseau <didierloiseau+github@gmail.com>
* Integrated @drashna and @fauxpark's PR comments
- changed all plurals of "LED" to "LEDs" in the file
- rewording of the note about host_keyboard_leds() vs. led_set_user()
* Update docs/custom_quantum_functions.md
Co-Authored-By: DidierLoiseau <didierloiseau+github@gmail.com>
* Eliminate separate slave loop
Both master and slave run the standard keyboard_task main loop now.
* Refactor i2c/serial specific code
Simplify some of the preprocessor mess by using common function names.
* Fix missing #endif
* Move direct pin mapping support from miniaxe to split_common
For boards with more pins than sense--sorry, switches.
* Reordering and reformatting only
* Don't run matrix_scan_quantum on slave side
* Clean up the offset/slaveOffset calculations
* Cut undebounced matrix size in half
* Refactor debouncing
* Minor fixups
* Split split_common transport and debounce code into their own files
Can now be replaced with custom versions per keyboard using
CUSTOM_TRANSPORT = yes and CUSTOM_DEBOUNCE = yes
* Refactor debounce for non-split keyboards too
* Update handwired/xealous to build using new split_common
* Fix debounce breaking basic test
* Dodgy method to allow a split kb to only include one of i2c/serial
SPLIT_TRANSPORT = serial or SPLIT_TRANSPORT = i2c will include only
that driver code in the binary.
SPLIT_TRANSPORT = custom (or anything else) will include neither, the
keyboard must supply it's own code
if SPLIT_TRANSPORT is not defined then the original behaviour (include
both avr i2c and serial code) is maintained.
This could be better but it would require explicitly updating all the
existing split keyboards.
* Enable LTO to get lets_split/sockets under the line
* Add docs for SPLIT_TRANSPORT, CUSTOM_MATRIX, CUSTOM_DEBOUNCE
* Remove avr-specific sei() from split matrix_setup
Not needed now that slave doesn't have a separate main loop.
Both sides (on avr) call sei() in lufa's main() after exiting
keyboard_setup().
* Fix QUANTUM_LIB_SRC references and simplify SPLIT_TRANSPORT.
* Add comments and fix formatting.
* Crawlpad: delete kbfirmware JSON file
* Crawlpad: refactor
- config.h and crawlpad.h updated to use #pragma once method
- layout macro renamed from KEYMAP to LAYOUT_ortho_4x4
- default keymap now uses #include QMK_KEYBOARD_H
- deleted deprecated action_get_macro function
- cleanup rules.mk file
- add LAYOUTS = ortho_4x4 to rules.mk
* Crawlpad: Configurator support
* Crawlpad: readme update
- update image link to direct link
- fully update Docs link line
- delete reference to deleted kbfirmware JSON file
* Add encoder support
* Add VIA support to Iris Rev. 3
* Update pinout and disable mouse keys to free up space
* Rollout VIA support to all Iris revisions
* Update default keymap
* Update vendor ID
* Add kbd6x:konstantin keymap
* Prevent tap dance from sending LShift as a weak mod in KBD6X
* Move config.h and rules.mk definitions into userspace
* Add UC_WIN to UNICODE_SELECTED_MODES
* Temporarily use Bootmagic until Command is fixed
* Move common behavior from keyboards into userspace
* Update kbd6x:konstantin keymap and userspace
* Make a RCTRL layer in kbd6x:konstantin
* Make KC_ESC turn off layers
* KC_ESC turns L_FN off only if it was locked on
* Add missing record->event.pressed checks
* Move numpad toggling logic into function
* Disable Bootmagic, enable KEYBOARD_SHARED_EP with Command
* Add support for THE50
A 50% custom keyboard designed and produced by LazyDesigners
* THE50 code-improvement
Implement the changes suggested by noroadsleft.
* changed ortho keymaps and userspace
* changed prime_o keymap
* changed userspace
* optimized keymaps and userspace
* removed permissive hold as it doesn't seem to do anything
* defined TAPPING_TERM in userspace config.h
* Commited into clean repo
* Gergo initial release
* Cleaning up
* Cleaning up
* Update readme.md
* Updated image, fixed MD formatting, added clairity
* Moved keymap to keyboard subdir, modified rules.mk
* Cleaned header guards
* Cleaned header guards. Read the rest of the PR comments
* Update keyboards/gergo/keymaps/default/keymap.c
Co-Authored-By: germ <jeremythegeek@gmail.com>
* Update keyboards/gergo/readme.md
Co-Authored-By: germ <jeremythegeek@gmail.com>
* Moved makefiles to keymap mod-area-thingy-with-overrides
* Update rules.mk
Slow the roll on the defaults while I wait for merge
* Update rules.mk
* Cleaning cleaning cleaning
* More housekeeping. Keeping optdefs
* moved keyboard specfic conf to config.h. Can we merge yet?
* added info.json
* Check the size of the SET_REPORT packet
If we have two bytes, that probably means the first is a report ID. The 6KRO interface may or may not have one, but the NKRO interface always does, so we need to check this regardless of whether KEYBOARD_SHARED_EP is defined.
* Fix indentation
* adds proton c base
* fixes custom matrix include
* adds readme.md
* initial proton coversion, no pin mapping
* start of mcu selection
* add pin mapping and sweet16 test
* add at90 to list
* disable backlight, fix d7
* update flag names
* doc updates
* proton c update for mcu selection
* initial prime_o commit
* Cleaned up comments, other things.
* Update bakingpy 4x12 keymap and add test mode for debugging/development (#4810)
* Keymap: ave-63's iris layout (#4812)
* Updated keymap to use standard seven-underscore KC_TRNS notation
* initial prime_o commit
* Cleaned up comments, other things.
* Updated keymap to use standard seven-underscore KC_TRNS notation
* Downbubble: Configurator fix
Fix the visual key alignment and some typos.
* Downbubble: refactor
Rename layout macros:
- LAYOUT_downbubble_standard to LAYOUT_standard
- LAYOUT_downbubble_splitbackspace to LAYOUT_split_bs
- LAYOUT_downbubble_splitrightshift to LAYOUT_split_rshift
- LAYOUT_downbubble_splitnumpad to LAYOUT_split_numpad
- LAYOUT_downbubble_spliteverything to LAYOUT_all
* Remove unused UNICODE(n) macro, update docs
* Add note about max length of unicode_map to docs
* QK_UNICODE_MAP → QK_UNICODEMAP
* Refactor process_unicode_map
* process_unicode_map → process_unicodemap
This is done for consistency: UNICODEMAP is the method (hence UNICODEMAP_ENABLE, process_unicodemap), whereas unicode_map is the mapping table itself.
* Update references and ordering in docs/understanding_qmk
* Add additional note to docs/understanding_qmk
* &unicode_map[index] → unicode_map + index
This avoids the issue of the compiler sometimes complaining about the array index being out of range
* Update docs/getting_started_make_guide
* Update method sections in docs/feature_unicode
Microsecond (us) delays are now handled by a busy wait loop according to MCU frequency. This replaces the system counter method which had an overhead of around 12us.
TC5 device and supporting routines removed as it was the old us delay counter.
wait_ms is now properly a macro to CLK_delay_ms.
wait_us is now properly a macro to CLK_delay_us.
Removed CLK_get_us as it has no use.
All calls to CLK_get_ms() have been replaced by timer_read64() with corrected typing.
All calls to CLK_delay_ms() have been replaced by wait_ms().
All calls to CLK_delay_us() have been replaced by wait_us() and timings verified or updated as needed after review on scope.
Corrected typing of variables using 64bit ms timer readings if needed.
* initial commit, this now mostly works
- RGB controls work
- Dynamic keymap still broken due to eeprom
- Via works
* STM32 eeprom update
- Update EEPROM emulation library to handle 8bit data like AVR.
- This library also allows for multiple page pairs resulting in greater EEPROM size flexibility
* hs60 changes
* HS60 hhkb added
* Update keyboards/hs60/v2/config.h
Co-Authored-By: yiancar <yiangosyiangou@cytanet.com.cy>
* Fractal: layout macro cleanup
Removed KEYMAP alias for LAYOUT_preonic_mit. Alias was unused, and the terminology usage is deprecated.
* Fractal: readme cleanup
Updated the line containing the documentation links in the readme.
* Fractal: disable preonic_mit community layout
QMK doesn't have a preonic_mit community layout at this time.
Disables preonic_mit as an option for community layout. Can be re-enabled when the layout is added.
* Numbrero: fix Configurator mismatch
Key object order in info.json didn't match the layout macro, leading to keys being assigned out-of-sequence.
* Numbrero: tidy
- white space changes in numbrero.h (alignment/readability/QMK conventions)
- minor changes to readme.md (grammar, mostly)
* Tradestation: tidy code
- correct JSON syntax on info.json
- visual key alignment on info.json
- white space changes on rules.mk and tradestation.h (readability/QMK conventions)
* Tradestation: readme refactor
Modify readme.md to more closely match QMK template.
* Tradestation: readme update
Update The Board podcast link for libsyn.
* S65-X: remove S65-Plus support
The original QMK codebase for the Sentraq S65-X actually supported both the S65-X and the S65-Plus. In the interim, the S65-Plus has been broken off into its own directory.
This commit removes support for the S65-Plus from the `keyboards/s65_x/` directory, as that code has been superseded by the code in the S65-Plus directory (`keyboards/s65_plus/`).
- deleted S65-Plus layout macros from s65_x.h and info.json
- deleted s65plus keymap directory
- removed references to the unused column pins
- removed the two unused columns for the switch matrices
- renamed switch K300 in LAYOUT_ansi to K301 (reflects matrix position)
- renamed switch K214 in LAYOUT_iso to K114 (reflects matrix position)
* S65-X: keymap refactor
- all keymaps now use #include QMK_KEYBOARD_H
- default and iso keymaps refactored for readability
- deleted redundant KC_TRNS and KC_NO keycode definitions from smt keymap
* S65-X: readme update
- updated Hardware Availability link
- updated Docs links
* S65-Plus: add LAYOUT_iso data
Adds LAYOUT_iso macro to s65_plus.h and info.json, and an ISO layout version of the default keymap.
* S65-Plus: refactor default keymap
- refactor for alignment/readability
- removed fn_actions code block
- add empty process_record_user block
* S65-Plus: readme update
- Hardware Availability link is now a hyperlink
- updated Docs links
* S65-X: enable 65_ansi and 65_iso community layouts
Thi commit allows the Sentraq S65-X to use the 65_ansi and 65_iso community layouts.
- LAYOUT_ansi renamed to LAYOUT_65_ansi
- LAYOUT_iso renamed to LAYOUT_65_iso
- added LAYOUTS rule to rules.mk
* Remove QUANTUM_DIR code blocks from keyboard rules
This commit removes the deprecated "QUANTUM_DIR" code block from
rules.mk files that affect entire keyboards.
* remove QUANTUM_DIR code blocks from rules for default keymaps
This commit removes the deprecated "QUANTUM_DIR" code block from
rules.mk files that affect default keymaps.
* remove QUANTUM_DIR code blocks from rules for user keymaps
This commit removes the deprecated "QUANTUM_DIR" code block from
rules.mk files that affect "user" keymaps. (It's actually any keymap
that isn't named `default`.)
* remove QUANTUM_DIR code blocks from rules for community layouts
This commit removes the deprecated "QUANTUM_DIR" code block from
rules.mk files for community layouts.
* remove QUANTUM_DIR code blocks from rules for userspaces
This commit removes the deprecated "QUANTUM_DIR" code block from
rules.mk files for userspaces.
* Use standard KC_ALGR, remove language-specific redefinitions
* Use ALGR instead of ALTGR in BÉPO and Canadian multilingual keymaps
* Remove BE_LALT, BE_LGUI aliases
* adding default settings to support 3v ERM vibration motors
* set default settings of haptic motor for LV061228B-L64-A 2v LRA
* update ishtob keymap and fix config settings
* Bocaj Layout Revamp
* Pull in Upstream (#1)
* Various tweaks for some Input:Club build processes
* change KEYMAP to LAYOUT for all new keyboards made using this script
* Add support for rev3 of the Atom47 (#2672)
* Added support for rev3 of the Atom47
* Updated Atom47 readme's
* Fix redefine error on rev2 and add maartenwut's keymap
* Fix redefine error on LEdiodes keymap
* Add Nyquist keymap (#2692)
* nyquist
* danielhklein nyquist setup
* shift left controls
* remove readme
* cleanup before pr
* ready for pr
* Adds Phantom TKL support (#2696)
* Add an info.json to phantom keyboard
* Add layouts
- KEYMAP_WINKEYLESS
- KEYMAP_7BIT
- KEYMAP_ISO
- KEYMAP_ISO_WINKEYLESS
* Add key_counts
* Add 2 missing F-Row keys
* Add TKC1800 info.json
Created an info.json for the tkc1800.
* Clueboard 60 info.json
- adds
- LAYOUT_60_ansi
- LAYOUT_60_iso
- KEYMAP_AEK
- KEYMAP
- LAYOUT_60_ansi_split_bs_rshift
* Add the Speedo keyboard
* Fix KC60 info.json file (#2707)
* change KEYMAP to LAYOUT in all the KC60 files
* Redo the info.json file
* Small fixes to TKC1800
- adjust F-row to use 0.25 spacing
- split left shift
- add key_count
* Fix some Configurator Warnings regarding LAYOUT vs KEYMAP (#2708)
* change diverge 3 KC_KEYMAP to LAYOUT
* Change KEYMAP to LAYOUT for handwired arrow pad
* change M10A to LAYOUT for m10-a
* Change KC_KEYMAP to LAYOUT_kc and KEYMAP to LAYOUT for mf68
* change KC_KEYMAP to LAYOUT for nano
* Refactor to LAYOUT
* refactor to LAYOUT-ansi and LAYOUT_iso for s65
* LAYOUT conversions for lfkkeyboards
* missed a few renames
* mini1800 for lfkeyobards support of LAYOUT
* Improve state/chord handling and clean up namespace
Some values that can never, ever, change were held in local
variables, rather than in PROGMEM. Fixed.
Change "pressed" to a signed int so the test for < 0 makes
sense, and to avoid possible weird failure modes in the
case where a key release comes in when pressed is already
zero. (Shouldn't happen, sure, but computers are weird.)
A lot of things in process_steno had external linkage for no
particular reason. They've been marked static. Stuff still
builds.
Distinguish between currently-held keys and keys that have
been held, and expose these values through a nicely-named API
so other code could, say, check on the current set of steno
chording in order to make displays. Also in passing fix up the
"state" value having external linkage so it could clash with
other people's variable declarations.
The API also provides hooks for key processing and steno chord
events, so you can monitor those events without having to
run in matrix_scan_user and recheck the values directly. Also
document these.
There is no path through processing a key that doesn't
end with a return false, so the nested return foo() are
gone and we just return false.
* Pull information from config.h and rules.mk (#2711)
* Pull information from config.h and rules.mk
* Readd the kbd75 maintainer
* Remove obsolete info.json entries (#2712)
* Clean up some long-standing errors when populating the API (#2715)
* More Configurator Warning Fixes (#2716)
* mf68_ble did not have the correct .c and .h files
* Fix JC65 KEYMAP to LAYOUT
* Change KEYMAP to LAYOUT for s60_x
* Convert KEYMAP to LAYOUT for lets_split boards
* Convert KEYMAP to LAYOUT
* more fixes to keymap for iris
* convert KEYMAP to LAYOUT for levinson keyboard
* change losinggeneration's KEYMAP to LAYOUT
* convert KEYMAP to LAYOUT
* convert KEYMAP to LAYOUT for nyquist
* convert KEYMAP to LAYOUT
* convert KEYMAP to LAYOUT for viterbi
* convert KEYMAP to LAYOUT
* convert KEYMAP and its subsidiries to the LAYOUT standard
* convert KEYMAP and its subsidiries to the new LAYOUT standard
* Normacos keymap for let's split keyboard (#2691)
* Cheers let's split keymap
* fixed typo on norman layer of cheers keymap for let's split
* fixed right handed mappings for home row
* cheers keymap for let's split redefinition
* updated Cheers keymap for let's split
* cheers keymap for let's split updated with some terminal macros
* renamed cheers let's split keymap to a more appropriate normacos
* updated normacos keymap doc / removed non functional keys
* reset let's split rules to default values
* added more spotlight search macros
* normalized keymap comments
* Moved numpad on lower layer
* hhkb jp personal keymap (#2698)
* Add JJ40 Cockpit personal keymap (#2713)
* Add JJ40 Cockpit keymap
* Fix lower layer symbols
* Add readme for "major" keyboards to eliminate more QMK Configurator errors (#2718)
* add readme to ktype keyboard
* add readme to m10a
* add readme to mini1800
* add readme to parent directory
* Revert "Pull in Upstream (#1)"
This reverts commit eeba0cec17.
* Updates to Bocaj Files
- Gave up on Tap Dance for ' -> '
+ Added another 'Secret'
+ Add ' -> ' to the Swap Hands key
+ Add Swap Hands to the ' -> ' key
+ Made Hand Swapping a momentary toggle
- Removed Auto Shift
+ Added Layer Toggle to KC_QUOTE for the _TOOLS layer
- Disabled Tap Dance
* Merge remote-tracking branch 'upstream/master'
* Updates to Bocaj
Added Game Layers, Removed Unused Macros
* Removed 'secrets.h'
* Updates to Bocaj
Remove 'secrets'.
Remove 'sendstring_workman.h' and set related layer back to qwerty due to macro compatibility issues
* Total revisioning of keymap and layout structure
* Missed readme.md file
* Bocaj - Permissive Hold setting enabled
* Switching from ErgoDox EZ centric configuration to the layout/user approach
* Bocaj - Create Userspace and Ergodox layout
* Update settings.json
* Pushing local updates
* Reverting .vscode/settings.json
* Adds pretty_osx and _win wrappers
* Utilize Windows and Mac Wrappers
* Update layouts/community/ergodox/bocaj/keymap.c
* Updates to Bocaj keymap.c
- Extended pretty_osx and pretty_win wrappers to allow modification of the bottom rows and thumb clusters.
- Fixed already wrapped layouts to align with the change
- Wrapped _NUMS and _CLICKY layers with the _osx wrapper because I main with a Mac
* Updates to Bocaj
Small documentation updates, added KC_MAKE from Drashna's layout, added KC_LOCK back to the diablo layer.
* Add LShift to _Adjust layer
* Minor changes to bocaj
Put wrappers in userspace and added RESET keycode to the Adjust layer
* Updates to Bocaj config & keymap; Fixed problem with process_leader.c
- Made lots of changes to the bocaj layout and userspace
- Pulled in latest upstream/master
- Attempted to compile with latest and found an unneccessary `break` in process_leader.c
* Bocaj - Updates to Layout and Userspace
* Adjust LEADER_TIMEOUT to 350
* Put KC_GRAVE on _ADJUST layer
* Eliminate _LOWER layer and associated definitions
* Adjusted layer indicating LEDs to match changes
* Fixed Diablo leader sequence
* Added build info leader sequence
* Got rid of obsoleted IGNORE_MOD_TAP_INTERRUPT/PERMISSIVE_HOLD/PREVENT_STUCK_MODIFIERS (may add STRICT_LAYER_RELEASE in the future)
* Remove type_traits
Not sure what in my VSCode config always brings this one in
* refactor stage 1
* Bocaj Refactor Phase II
* Made LED_2 brighter if both CTRL & GUI are being held
* Enabled unicode because I got it to work in Mac OS
* Finalized Build Info leader combination after testing in Mac OS
* Not sure why KC_D3_1 was set to ASDF if !TAP_DANCE_ENABLE. So I changed that back
* Experienced issues with `EXTRAFLAGS += -flto` using Docker in MacOS. Not sure what it does, but I don't seem to be missing anything
* Wrote obligatory readme.md files and mentioned Drashna too many times... I don't think I can actually take credit for much of anything here.
* Updates to Bocaj
Made LED changes, added LM_DFLT which is similar to the grave macro, enabled retro tapping, working on a unicode idea -- currently fails to build.
* Bocaj Refactor Phase 3 Part 2
- Continuation of implementing unicode switching based on default layer
- Slight adjustments to _DIABLO and base wrapper because LM_DFLT macro didn't function as I'd hoped
* Slight adjustment to KC_MAKE
* Added my Mechmini2 layout to qmk.
* Added more info to the readme.
* Made changes.
* Update keyboards/mechmini/v2/keymaps/lbibass_625_space/keymap.c
Co-Authored-By: lbibass <ewdries02@gmail.com>
* Update keyboards/mechmini/v2/keymaps/lbibass_split_space/keymap.c
Co-Authored-By: lbibass <ewdries02@gmail.com>
* Added brightness and volume controls to MechMini 625 layout.
* Make CRKBD keylogger output actually show tap keys
* check MT/LT for twinkling
* Add ortho 5x12 support for fractal keyboard
* Use newer interface for setting pins/ports
* Remove custom unicode methods
* Reomve unicode input info
* Odd rules issue
* Redefine REST note to be more pleasing
* Properly disable PM LEDs with GPIO commands
* Update gitlab CI yaml file
* Remove extra mod tap check
* Remove initial state on ergodox glow
* Rev6 Cleanup
* Fix KC_MAKE macro
* Update GitLab CI yaml file
* More GitLab CI changes
* One final GitLab CI change
* Remove unneeded unicode support
* Optimize KC_MAKE
* Change rgblight_get_mode's return type to uint8_t.
Since rgblight_get_mode() is just returning rgblight_config_t.mode,
it should match rgblight_config_t.mode's type: uint8_t.
* Update rgb_matrix_get_mode to return uint8_t.
It seems the led_mask is set incorrectly on the WhiteFox meaning that
the LED at C9-1 (the space bar) doesn't get lit. I can't see any reason
for this to be intentional so I am pretty sure it's a typo. At the very
least it fixes the space bar LED for me.
* Add my zeal60 keymap
* Temporarily remove failing community layout from zeal60 make rules
* Revert "Temporarily remove failing community layout from zeal60 make rules"
This reverts commit ffd0018fb1.
* refactored cyclops keyboard project
Moved the files into a subfolder to allow consistency in preparation for additional commits to come in the future.
made some small adjustments to the configuration and keymap
* Update keyboards/westfoxtrot/cyclops/keymaps/default/keymap.c
Co-Authored-By: westfoxtrot <17062872+westfoxtrot@users.noreply.github.com>
* Update keyboards/westfoxtrot/cyclops/readme.md
Co-Authored-By: westfoxtrot <17062872+westfoxtrot@users.noreply.github.com>
* Update keyboards/westfoxtrot/cyclops/readme.md
Co-Authored-By: westfoxtrot <17062872+westfoxtrot@users.noreply.github.com>
* Update keyboards/westfoxtrot/cyclops/readme.md
Co-Authored-By: westfoxtrot <17062872+westfoxtrot@users.noreply.github.com>
* Keep pressed keys on layer state change
* Add doc comment for clear_keyboard_but_mods_and_keys
* Keep pressed keys only if PREVENT_STUCK_MODIFIERS is on
* Check STRICT_LAYER_RELEASE instead of PREVENT_STUCK_MODIFIERS
* Update feature_advanced_keycodes.md
Probably a better way to word it, but I've solved this issue on reddit several times, had to solve this for friends, ect. It's something worth being in the docs as it's a common issue, and not always intuitive. I have offered this change as I was told by several people "It was never mentioned in the docs".
* Update feature_advanced_keycodes.md
Clear up what was meant to be said.
* Change spaces to tabs on two lines
The rest of the file uses tabs
* Read user input in a non-terrible, non-hacky way
* Remove unnecessary tee call
* read -p is not POSIX
* Add missing $ to echo GENTOO_WARNING
* Replace non-POSIX echo -n with printf
* Use cd ... || exit 1 in case git clone fails
* Add missing sudo
Thanks @snortwolf
* Undo replacing tee with >>
* XMMX: matrix and keymap refactor
- xmmx.h updated to use #pragma once
- renamed LAYOUT_ansi_wk macro to LAYOUT_tkl_ansi
- renamed LAYOUT_ansi_wkl macro to LAYOUT_tkl_ansi_wkl
- renamed LAYOUT_iso_wk macro to LAYOUT_tkl_iso
- renamed LAYOUT_iso_wkl macro to LAYOUT_tkl_iso_wkl
* XMMX: Configurator support
* XMMX: readme update
* Add support for reset to bootloader
Chibios_test/STM32_F072_ONEKEY wouldn't reset to bootloader on a
compatible Discovery board because the Chibios library board file was
lacking the __early_init(void) function necessary to read the magic key.
Borrowed code from Clueboard 60, tested working.
* Remove board.chcfg
* Add provisional Helix implementation to test the quantum/split_common.
* copy keyboards/helix/serial.[ch] to quantum/split_common/
* Make serial.c a pure driver.
Remove buffer name and buffer size from serial.c. They should be placed in the caller(matrix.c, split_utils.c).
* remove quantum/split_common/serial_backward_compatibility.h
* Changed array serial_master_buffer to structure serial_m2s_buffer.
* Changed array serial_slave_buffer to structure serial_s2m_buffer.
* Change keyboards/miniaxe/matrix.c
I also made changes to quantum/split_comon/matrix.c to keyboards/miniaxe/matrix.c.
Note: I contacted @ka2hiro, creator of miniaxe, and I got permission to change keyboards/miniaxe/matrix.c.
* update history comment in quantum/split_common/serial.c
* Revert "Add provisional Helix implementation to test the quantum/split_common."
This reverts commit 168c82ef82.
* fix keyboards/miniaxe/matrix.c, quantum/split_common/matrix.c
avr-gcc 4.9.[23] report error.
avr-gcc 5.4.0, avr-gcc 7.3.0 pass.
It is funny.
* update comment quantum/split_common/serial.c
* Reserve RGBLIGHT_SPLIT macro in quantum/split_common
* initial commit for Othi's HHKB layout keymap,
covering multiple modifiers hold and vim-like support and german characters. If there's
any suggestion i can be reached via mnpqraven on github or Othi#6661 on
discord
* added readme.md. TODO: update readme.md
* changed to default quantum keycode for `KC_TRNS`,
removed `PREVENT_STUCK_MODIFIERS`,
fixed tap dance using one shots
TODO: unicode implementation at https://docs.qmk.fm/#/feature_unicode
* keymap documentaion(readme) added
* unicode init
TODO: figure out what made the compose sequence not running
* update unicode and readme
* JD40: default keymap refactor
- Removed redundant action_layer.h include
- Refactored to use LAYOUT macro (from LAYOUT_kc)
- Refactored to use QMK-native keycodes
- Removed superseded TMK code blocks
* JD40: readme cleanup
Fixed and updated the links in the readme file
* Infinity60: refactor
- infinity60.h / keymap.c
- renamed layout macro to LAYOUT_60_ansi_split_bs_rshift; removed layout macro alias
- updated to #pragma once
- keymaps now use #include QMK_KEYBOARD_H
- keymaps/jpetermans/config.h updated to #pragma once
- keymaps/jpetermans/rules.mk deleted (complete contents were deprecated make instructions)
* Infinity 60%: Configurator support
* Infinity60: readme update
Updated the Docs links.
* Infinity60: bugfix depariel keymap
Had a typo.
* Infinity60: edit matrix.c
per @drashna
- https://github.com/qmk/qmk_firmware/pull/4707#issuecomment-449540676
* Fix up process_leader to be a bit more optimized
* Process dual function keys better
* Make leader start a callable function
* Fix per key timer call location
* Add escape if already leading
* Return false for KC_LEAD
* Add documentation
* add some comment about Helix customize and auto-setup RGBLIGHT_LIMIT_VAL
* add define USB_MAX_POWER_CONSUMPTION
* Helix keyboard OLED, RGBLIGHT enable/disable control integrate into rules.mk
rules.mk: add 4 Variables for compile control.
# Helix keyboard customize
# you can edit follows 4 Variables
# jp: 以下の4つの変数を必要に応じて編集します。
OLED_ENABLE = no # OLED_ENABLE
LED_BACK_ENABLE = no # LED backlight (Enable WS2812 RGB underlight.)
LED_UNDERGLOW_ENABLE = no # LED underglow (Enable WS2812 RGB underlight.)
LED_ANIMATIONS = yes # LED animations
config.h: auto set RGBLED_NUM by HELIX_ROWS and rules.mk's define
* HELIX_ROWS define move from config.h to rules.mk
* add readme.md
* rename readme.md to readme_jp.md
* add readme.md and modify readme_jp.md
* change helix/ssd1306.c for select glcdfont.c position
* add variable LOCAL_GLCDFONT into each keymaps rules.mk
* Add iPhone/iPad LED support to Helix default keymap
* renumber _ADJUST for shrink program size
* Fix Helix i2c wrong bit rate
* add helix serial debug code
* serial debug macro move from config.h to serial.h
* helix serial.c debugging...
* refine debug macros
* add some comments
* add SELECT_SERIAL_SPEED
* add comments
* debugging sync_send/sync_recv
* add very high speed
* fix sync_send/sync_recv
* fix com. start and switch send/recv
* debug mode off
* remove debug codes
* temporary change, compiling C, C++ and ASM without -g
* helix config.h refine
* Revert "temporary change, compiling C, C++ and ASM without -g"
This reverts commit e9730cbbfd.
* add change_reciver2sender()/change_sender2reciver()
This is a change to improve readability.
* txled, rxled off in matrix_init()
* add serial_send_packet() / serial_recive_packet()
This is a change to reduce object size.
* add serial_low() at ISR() top
* add __attribute__((always_inline)) to some functions
* modify serial_send_packet()/serial_recive_packet()
A little, object size reduction.
A little, speedup.
* add debug code to helix/serial.c
* Adjust sampling timing of serial signal being received
* add split_scomm.c/split_scomm.h and change serial.c/serial.h
serial.c was divided into 2 layers, split_scom.c and serial.c.
The upper layer split_scomm.c is called from matrix.c.
The lower layer serial.c accesses the hardware.
* add split_scomm.c/split_scomm.h into helix/rev1
* reduce object size helix/rev2/matrix.c
* remove checksum check, add parity check
* force occur parity error for test
* parity test ok. remove test code
* change some comment & add skip code when buffer_size == 0
* serial.c: multiple types of transaction support
Add 4 bits transaction-type field at packet top.
Select Transaction Descriptor Table entry by transaction-type.
* helix serial master-slave transaction optimize
Using multi-type transaction feature of serial.c, communication contents between master slaves were optimized.
* add debug code for retry
* add comment into each config.h
* fix ISR status drop
* add a debug macro 'debug_retry_chg()'
* reduce led_test size
* remove debug code from helix/serial.c and etc.
* helix:five_rows change TAPPING_TERM value 140
* Improved compatibility with let's split of serial.c. Finish helix/serial.c improvement.
- The difference with the original let's split's serial.c
- It's high-speed about 4 times.
- Stable bi-directional data transfer. (Helix need master to slave transfer)
- serial.h was divided 2 files, serial_config.h and sereial.h
- With multiple types of transaction support, communication contents can be optimized. (NEW flexible API)
- USE OLD Simple APIs (compatible with let's split serial.c)
- files :
- serial_config.h -- hardware configuration (need include by config.h)
- serial.c/serial.h -- serial communication
- USE NEW flexible APIs. (Support multi-type transaction function.)
serial.c was divided into 2 layers, split_scom.c and serial.c.
The upper layer split_scomm.c is called from matrix.c.
The lower layer serial.c accesses the hardware.
- files
- split_scomm.c -- communication buffer is defined in here. call by matrix.c.
- split_scomm.h -- buffer size is defined in here. include by matrix.c, split_util.c
- serial_config.h -- hardware configuration (need include by config.h)
To use the NEW API, specify #define SERIAL_USE_MULTI_TRANSACTION
- serial.c/serial.h -- serial communication lower layer
- NEW APIs for serial.c / serial.h (The lower layer)
// Soft Serial Transaction Descriptor
typedef struct _SSTD_t {
uint8_t *status;
uint8_t initiator2target_buffer_size;
uint8_t *initiator2target_buffer;
uint8_t target2initiator_buffer_size;
uint8_t *target2initiator_buffer;
} SSTD_t;
// initiator is transaction start side
void soft_serial_initiator_init(SSTD_t *sstd_table);
// target is interrupt accept side
void soft_serial_target_init(SSTD_t *sstd_table);
int soft_serial_transaction(int sstd_index);
int soft_serial_get_and_clean_target_status(int sstd_index);
- NEW APIs for split_scomm.c / split_scomm.h (The upper layer)
move from old serial.c the following buffer and functions
serial_slave_buffer[]
serial_master_buffer[]
void serial_master_init(void)
void serial_slave_init(void)
int serial_update_buffers(void)
define SERIAL_xxxxx_BUFFER_LENGTH move from serial_config.h to split_scomm.h
* fix comment typo
* Fix the value of helix:five_rows variable HELIX_ROWS to 5.
* led_test rules.mk some change
* Separate common parts of helix/rev2/keymaps/*/rules.mk into helix/rev2/keymaps_common.mk
* helix/rev2/keymaps/edvorakjp/rules.mk use helix/rev2/keymaps_common.mk
* Separate common parts of helix/pico/keymaps/*/rules.mk into helix/pico/keymaps_common.mk
* Helix each keymap's using rgblight mode symbol instead magic number
No change in build result.
* Helix pico keymaps: make rgblight modes selectable.
No change in build result.
* Helix rev2 keymaps: make rgblight modes selectable.
No change in build result.
* fixed Helix froggy/keymap.c: invalid rgblight mode value 0 to 1 (=RGBLIGHT_MODE_STATIC_LIGHT)
* Deselect RGB_TEST and ALTERNATING in Helix rev2,pico keymaps config.h.
* Merge branch 'master' of https://github.com/qmk/qmk_firmware
* revert 955dcbc
* delete keymaps_common.mk
* add LAYOUT_kc() to keyboards/helix/pico/pico.h
* Standardize the Unicode EEPROM code
* Remove unicode init from process_record_* functions
* Add unicode init to where it belongs: matrix_init_quantum
* Move Unicode proccessing to unicode common
* Add audio feedback to input mode keys to drive konstantin up a wall
* Tap_code cleanup
* Update keycodes
* Update unicode documentation
* Update unicode keycodes for consistency/easier merge
* Add Audio Feedback section
* Remove Functions from feature page
And link to the file instead. Link to specific lines later on.
* Fix spacing
Co-Authored-By: drashna <drashna@live.com>
* Because I missed it!
Co-Authored-By: drashna <drashna@live.com>
* Fix spacing
Co-Authored-By: drashna <drashna@live.com>
* SPAAAAAAAAAACing
Co-Authored-By: drashna <drashna@live.com>
* Add BSD for future compatibility
* Thought I fixed that!
Co-Authored-By: drashna <drashna@live.com>
* non-breaking
Co-Authored-By: drashna <drashna@live.com>
* Considered that
Co-Authored-By: drashna <drashna@live.com>
* Yuuup
Co-Authored-By: drashna <drashna@live.com>
* consistency
Co-Authored-By: drashna <drashna@live.com>
* white spaces .... copied from elsewhere
Co-Authored-By: drashna <drashna@live.com>
* white spaces
Co-Authored-By: drashna <drashna@live.com>
* white spaces
Co-Authored-By: drashna <drashna@live.com>
* Update keycode defines
* Fix Linux Song
* Update all of the songs
* Cleanup
* Move and update check to ensure only one unicode method is enabled
* Update quantum/quantum_keycodes.h
* Update documentation
* Wordsmithing and cleanup
* Format unicode_common (#13)
* case alignment
* process_record_unicode_common → process_unicode_common
* Move song arrays into function where they're used, align preprocessor directives
* Swap the order of UC_WIN and UC_BSD
* Update Unicode docs
* Reorder Unicode mode stuff to match the order of input mode constants
* Fix capitalization in doc subtitle
* Readd BSD and OSX_RALT songs
* Reword BSD note in docs
* Readd BSD keycode description
* Reword explanation of input on different platforms
* Steal vomindoraan's input mode documentation
Co-Authored-By: vomindoraan (vomindoraan@gmail.com)
* Willingly give Drashna the rest of my Unicode doc improvements
* Wordsmithing
Co-Authored-By: drashna <drashna@live.com>
* remove merge artifacts
* Unicode common cleanup (#17)
* Standardize the Unicode EEPROM code
* Remove unicode init from process_record_* functions
* Add unicode init to where it belongs: matrix_init_quantum
* Move Unicode proccessing to unicode common
* Add audio feedback to input mode keys to drive konstantin up a wall
* Tap_code cleanup
* Update keycodes
* Update unicode documentation
* Update unicode keycodes for consistency/easier merge
* Add Audio Feedback section
* Remove Functions from feature page
And link to the file instead. Link to specific lines later on.
* Fix white spaces
Co-Authored-By: drashna <drashna@live.com>
* Fix spacing
Co-Authored-By: drashna <drashna@live.com>
* Because I missed it!
Co-Authored-By: drashna <drashna@live.com>
* Fix spacing
Co-Authored-By: drashna <drashna@live.com>
* SPAAAAAAAAAACing
Co-Authored-By: drashna <drashna@live.com>
* white spaces
Co-Authored-By: drashna <drashna@live.com>
* Add BSD for future compatibility
* Thought I fixed that!
Co-Authored-By: drashna <drashna@live.com>
* non-breaking
Co-Authored-By: drashna <drashna@live.com>
* Considered that
Co-Authored-By: drashna <drashna@live.com>
* Yuuup
Co-Authored-By: drashna <drashna@live.com>
* consistency
Co-Authored-By: drashna <drashna@live.com>
* white spaces .... copied from elsewhere
Co-Authored-By: drashna <drashna@live.com>
* white spaces
Co-Authored-By: drashna <drashna@live.com>
* white spaces
Co-Authored-By: drashna <drashna@live.com>
* Update keycode defines
* Fix Linux Song
* Update all of the songs
* Cleanup
* Move and update check to ensure only one unicode method is enabled
* Update quantum/quantum_keycodes.h
* Update documentation
* Wordsmithing and cleanup
* Format unicode_common (#13)
* case alignment
* process_record_unicode_common → process_unicode_common
* Move song arrays into function where they're used, align preprocessor directives
* Swap the order of UC_WIN and UC_BSD
* Update Unicode docs
* Reorder Unicode mode stuff to match the order of input mode constants
* Fix capitalization in doc subtitle
* Readd BSD and OSX_RALT songs
* Reword BSD note in docs
* Readd BSD keycode description
* Reword explanation of input on different platforms
* Steal vomindoraan's input mode documentation
Co-Authored-By: vomindoraan (vomindoraan@gmail.com)
* Willingly give Drashna the rest of my Unicode doc improvements
* Wordsmithing
Co-Authored-By: drashna <drashna@live.com>
* Rearrange process_unicode_common functions
* Make Unicode input mode constants (UC_*) an enum
* Simplify unicode_input_start/finish code
* Make the key used for WinCompose configurable
* Remove UC_OSX_RALT in favor of setting the key with UNICODE_OSX_KEY
* Update Unicode input mode doc
* Add descriptions and rearrange definitions in process_unicode_common.h
* Add registry command to Unicode docs + misc updates
* Reword an explanation in Unicode docs
* Add TODO comment
* Remove trailing whitespace
* Improve Cycling documentation
* Add Unicode Input method Cycling support (#19)
* Standardize the Unicode EEPROM code
* Remove unicode init from process_record_* functions
* Add unicode init to where it belongs: matrix_init_quantum
* Move Unicode proccessing to unicode common
* Add audio feedback to input mode keys to drive konstantin up a wall
* Tap_code cleanup
* Update keycodes
* Update unicode documentation
* Update unicode keycodes for consistency/easier merge
* Add Audio Feedback section
* Remove Functions from feature page
And link to the file instead. Link to specific lines later on.
* Fix white spaces
Co-Authored-By: drashna <drashna@live.com>
* Fix spacing
Co-Authored-By: drashna <drashna@live.com>
* Because I missed it!
Co-Authored-By: drashna <drashna@live.com>
* Fix spacing
Co-Authored-By: drashna <drashna@live.com>
* SPAAAAAAAAAACing
Co-Authored-By: drashna <drashna@live.com>
* white spaces
Co-Authored-By: drashna <drashna@live.com>
* Add BSD for future compatibility
* Thought I fixed that!
Co-Authored-By: drashna <drashna@live.com>
* non-breaking
Co-Authored-By: drashna <drashna@live.com>
* Considered that
Co-Authored-By: drashna <drashna@live.com>
* Yuuup
Co-Authored-By: drashna <drashna@live.com>
* consistency
Co-Authored-By: drashna <drashna@live.com>
* white spaces .... copied from elsewhere
Co-Authored-By: drashna <drashna@live.com>
* white spaces
Co-Authored-By: drashna <drashna@live.com>
* white spaces
Co-Authored-By: drashna <drashna@live.com>
* Update keycode defines
* Fix Linux Song
* Update all of the songs
* Cleanup
* Move and update check to ensure only one unicode method is enabled
* Update quantum/quantum_keycodes.h
* Update documentation
* Wordsmithing and cleanup
* Format unicode_common (#13)
* case alignment
* process_record_unicode_common → process_unicode_common
* Move song arrays into function where they're used, align preprocessor directives
* Swap the order of UC_WIN and UC_BSD
* Update Unicode docs
* Reorder Unicode mode stuff to match the order of input mode constants
* Fix capitalization in doc subtitle
* Readd BSD and OSX_RALT songs
* Reword BSD note in docs
* Readd BSD keycode description
* Reword explanation of input on different platforms
* Steal vomindoraan's input mode documentation
Co-Authored-By: vomindoraan (vomindoraan@gmail.com)
* Willingly give Drashna the rest of my Unicode doc improvements
* Wordsmithing
Co-Authored-By: drashna <drashna@live.com>
* Rearrange process_unicode_common functions
* Make Unicode input mode constants (UC_*) an enum
* Simplify unicode_input_start/finish code
* Make the key used for WinCompose configurable
* Remove UC_OSX_RALT in favor of setting the key with UNICODE_OSX_KEY
* Update Unicode input mode doc
* Add descriptions and rearrange definitions in process_unicode_common.h
* Add registry command to Unicode docs + misc updates
* Reword an explanation in Unicode docs
* Add TODO comment
* Add cycle_unicode_input_mode and UNICODE_SELECTED_MODES macro
* Add an option for making cycle changes persistent
* Add debug prints to functions that change input_mode
* Use cycle_unicode_input_mode in whitefox/konstantin
* Add persist_unicode_input_mode function
* Add offset to cycle to allow stepping in reverse
* Add keycodes: UNICODE_MODE_FORWARD, UNICODE_MODE_REVERSE
Aliases: UC_MOD, UC_RMOD (respectively)
* REVERT ME: Undo changes to whitefox/konstantin to avoid conflicts
* Fix wrong constant name
* Revert "REVERT ME: Undo changes to whitefox/konstantin to avoid conflicts"
This reverts commit 42676bf251.
* Change dprintf text
* Give selected modes priority over EEPROM when !UNICODE_CYCLE_PERSIST
* Remove trailing whitespace
* Cleanup of RALT code and unicode compilation stuff
* Remove else for unicode handling
* Espectro: layout macro refactor
- updated to #pragma once method
- restructure LAYOUT_all data as block comment
- Configurator was reading the LAYOUT_all macro even though it was commented out.
- updated all keyswitch arguments to use K<ROW><COLUMN> notation
- add LAYOUT_iso macro
- add info.json file for Configurator support
* Espectro: keymap refactor
- deleted unused MODS_CTRL_MASK definitions
- iso keymap refactored to use LAYOUT_iso macro
- default and iso keymaps refactored for readability
* A Planck style keymap with iris flair
- Re-arrange layers to be more planck like.
- move backspace to right thumb
- replace backspace with minus, more useful for coding
- replace center keys with brackets
- MT(MOD_LCTRL and ESCAPE)
- Use QMK-DFU for bootloader
- add a soft reset to keymap
* Feedback from reviewers
- remove redundant define (noroadsleft)
- remove unused layer switch case (drashna)
* Adding ortho60 to handwired
* update to use LAYOUT_ortho_5x12
* Address PR comments about layout macros
* Add default layout to info.json for configurator
* Hack to xyverz layout until RGB branch is merged
* Fix undef RGBDIPIN in xyverz 12x5 layout
* Revert change to xvyerz's layout
* Fix typo
* Fix order
* Revert xyverz rules.mk
* ErgoInu: Configurator update, part 1
Give each key its own line to make the file easier to debug.
* ErgoInu: Configurator update, part 2
- converted all JSON variables to lowercase (this was the bugfix)
- converted Tabs to Spaces
* ErgoInu: Configurator update, part 3
- break key data into chunks
* ErgoInu: Configurator update, part 4
Rebuilt the layout tree into a new file, taking the Y values from the original data. Copied relevant data from original file into the new file, and then overwrote the original file.
* Cospad: Configurator update
- added LAYOUT_gamepad_6x4 data
- renders as 4 rows by 6 columns visually
- fixed LAYOUT_numpad_6x4 data
- JSON objects were in the wrong order
* Cospad: readme update
- markdown formatting fixes
- made Hardware Availability address a hyperlink
- updated Docs links
* converter/ibm_5291: Configurator support
- added layout data to info.json file
- corrected keyboard_folder value
* converter/ibm_5291: readme cleanup
- Fixed "image" url (target of link was a web page; changed markdown formatting to text link)
- Sentence capitalization fixes
- markdown formatting fixes for readability
* Layout macro refactor
- Renamed KC_KEYMAP to LAYOUT_kc
- Renamed KEYMAP to LAYOUT
- moved LAYOUT above LAYOUT_kc (Hoping this encourages users to use LAYOUT.)
- updated layout macro name in info.json
- white space changes for readability
* Keymap refactor: default
Default keymap now uses `#include QMK_KEYBOARD_H` and LAYOUT macro (from KC_KEYMAP/LAYOUT_kc). Keymap was also refactored to use process_record_user function instead of deprecated action_get_macro from TMK.
Also moved LONGPRESS_DELAY and LAYER_TOGGLE_DELAY definitions to config.h.
* Keymap refactor: dcompact
- Changed chimera_ortho.h include for QMK_KEYBOARD_H
- Updated layout name on keymap layers
* Coding conventions fix in default keymap
* Keymap refactor: gordon
- Changed chimera_ortho.h include for QMK_KEYBOARD_H
- Removed redundant includes of action_layer.h and process_tap_dance.h (superseded by QMK_KEYBOARD_H)
- Removed redundant definitions for KC_NO and KC_TRNS
- Updated layout name on keymap layers
* add temporary compile test shell script
* Extended support of SKIP_VERSION to make invariant compile results during testing.
* build_keyboard.mk, tmk_core/rules.mk: add LIB_SRC, QUANTUM_LIB_SRC support
Support compiled object enclosed in library.
e.g.
```
LIB_SRC += xxxx.c
xxxx.c --> xxxx.o ---> xxxx.a
```
* remove 'ifdef/ifndef USE_I2C' from quantum/split_common/{i2c|serial}.c
* add SKIP_DEBUG_INFO into tmk_core/rules.mk
When SKIP_DEBUG_INFO=yes is specified, do not use the -g option at compile time.
* tmk_core/rules.mk: Library object need -fno-lto
* add SKIP_DEBUG_INFO=yes
* remove temporary compile test shell script
* add '#define SOFT_SERIAL_PIN D0' to keyboards/lets_split/rev?/config.h
* quantum/split_common/serial.c: Changed not to use USE_I2C.
* Refactor fourier to use split common code
* Refactor fourier to use split common code - fix handedness when not using EE_HANDS or MASTER_LEFT
* add SOFT_SERIAL_PIN config
* Add delay in Tap Code to avoid issues
I think a few people have reporting issues with it working properly, and it may be a timing issue. The 'register_code' uses this sort of delay in some of the functions, and
this is probably why.
Adding the 100ms delay should hopefully fix any issues with it.
* Make tap_code delay configurable
* Update documentation
* Bring tap_code16 inline with changes
* Fix type for tap_code16
Bad copy-paste job
* Just use the value check for the define
* Clarify timing in docs
Co-Authored-By: drashna <drashna@live.com>
* Wordsmithing
Co-Authored-By: drashna <drashna@live.com>
* handwired/CMD60: refactor
- renamed layout macro KEYMAP to LAYOUT
- removed K2C, K3B and K3C locations (indications are these locations were unused in hardware)
- keymap
- now uses #include QMK_KEYBOARD_H
- converted keycodes to short format
- deleted TMK fn_actions and action_get_macro blocks
- white space changes (readability/alignment)
* handwired/CMD60: Configurator support
* handwired/CMD60: readme update
- updated to conform to current QMK template
- added image and build gallery links
* handwired/cmd60: rename all files and folders to lowercase
* handwired/maartenwut: readme cleanup
- Fixed typo (Maarten's last name was misspelled)
- Updated Docs links
* handwired/maartenwut: Configurator support
* S7 Elephant: Configurator bugfix, part 1
Reformatted the JSON so each key is on its own line:
This makes the keys easier to rearrange.
* S7 Elephant: Configurator bugfix, part 2
Deleted the extra key from LAYOUT_iso_1u:
JSON contents stated this layout used a split Backspace, but the matrix is configured and intended to have a 2u Backspace.
Extended the Backspace to 2u width and deleted the extra key. (This fixes the error that broke LAYOUT_iso_1u's rendering in the Configurator.)
* S7 Elephant: Configurator bugfix, part 3
Fix ISO layouts:
Noticed JSON object for Enter on ISO layouts was immediately after Right Bracket. Inspection of s7_elephant.h revealed the expected and appropriate location to be after ISO Hash.
Moved Enter key to the proper location on all ISO layouts.
* Add standard ALGR defition, remove (re)definitions from language files
* Use ALGR(kc) consistently in ALTGR(kc) aliases
* Non-Nordic keymaps should not use NO_ALGR
* Add standard KC_ALGR definition
* Update docs with ALGR and KC_ALGR
* Update SS_ALGR and ALGR_T aliases
* handwired/numpad20: refactor
- layout macro no longer auto-prepends keycodes with KC_
- keymaps for this keyboard will now compile in QMK Configurator
- keymap now uses #include QMK_KEYBOARD_H
- deleted unused fn_actions code block
* handwired/numpad20: Configurator support
* Preonic: refactor layout macros
Unify layout macro names across AVR and ARM.
- all layouts and matrices have moved/duplicated to their appropriate revisions
- preonic.h now includes the appropriate header file from the selected revision
- revision header files only contain layouts appropriate for that revision
- Previously, all layouts were available in source for all revisions.
- removed KEYMAP layout macro alias (was unused)
- macros LAYOUT_preonic_1x2uC and LAYOUT_preonic_grid for AVR and ARM revisions
- LAYOUT_preonic_grid has alias LAYOUT_ortho_5x12 for all revisions
- deleted LAYOUT_ortho_4x12 alias (not appropriate for this keyboard)
- ARM-based revisions have 1x2uR, 1x2uL and 2x2u matrices
* Preonic: updated revision headers to #pragma once
* Preonic: update Configurator files
Updated the Configurator files to reflect the previous changes in this branch.
- Preonic revs. 1 and 2 will use keyboards/preonic/info.json
- Preonic rev. 3 will use keyboards/preonic/rev3/info.json
- This file will override keyboards/preonic/info.json when preonic/rev3 is selected in the Configurator.
* handwired/practice60: Configurator Support
* handwired/practice60: refactor
- layout macro rows did not have an equal number of arguments in all rows of the matrix
- white space changes for readability/alignment
* handwired/pilcrow: refactor
- layout macro renamed from KEYMAP to LAYOUT
- keymap now uses #include QMK_KEYBOARD_H
- layers reformatted for readability
- removed unused and deprecated fn_actions and action_get_macro blocks
- keymap config.h
- updated to use #pragma once
- removed redundant config.h include
* handwired/pilcrow: Configurator support
* handwired/pilcrow: readme update
Updated readme.md file to use modern template formatting.
On a laptop with god knows what mandatory security software (Cylance?), running up-to-date Windows 10 with msys2 mingw-64, attempting to install the AVR toolkit results in the following error:
```
1 [main] 7z (13316) C:\msys32\usr\lib\p7zip\7z.exe: *** fatal error - cygheap base mismatch detected - 0x612A5410/0x2375410.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version. The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution. Rebooting is also suggested if you
are unable to find another cygwin DLL.
```
This appears to be related in some way, based on my research, to ASLR functionality in security software. Since I'm unable to override whatever is enforcing ASLR on my system, after trying several other approaches (removing other copies of msys-2.0.dll, which is what this is apparently actually referencing, rebasing that file in Windows to address 0x61000000, a few other things) I simply edited the installation shell script to use `unzip` instead of 7zip; `unzip`'s binary does not provoke a mismatch error and the installation proceeds as it should.
I'm not aware of the reason why some parts of the install script use `unzip` (e.g. `install_arm`) and others use 7zip, but it seems that for broader compatibility and sparing users on locked down machines the 120 minutes or so of futzing this took me to fix, it might be better to just use `unzip` in all cases.
Note: There is another function that uses 7zip, `extract_flip`. The line is `7z -oflip x FlipInstaller.exe`. I'm not sure what this is doing, or whether it's possible to do it with `unzip`, but it produces the same error. I haven't attempted to fix that in this PR, but it might be good to fix it for the same reason.
MCU Pins for debugging, LED, boot tracing, and shift registers are now configurable at keyboard level.
Macros led_* replaced by DBG_LED_*
Macros m15_* replaced by DBG_1_*
Macros m27_* replaced by DBG_2_*
Macros m28_* replaced by DBG_3_*
For CTRL and ALT keyboards, debug boot tracing pin default now set to pad M27 instead of M28 since although M28 is not being used, it is technically a signal for USB port detection.
m15_print(...) renamed to dbg_print(...) to get away from hard coded port names.
dbg_print function now follows similar pattern to debug led output.
* Added RGB toggle and cycle to default mapping. This is present on layouts on 'http://qmkeyboard.cn/' but not here.
* Added addition keycodes for hue/sat/val.
* Add a Docker build script
* Add usage and error messages
* Add -r to reads
Thanks mechmerlin
* Add keyboard:keymap form, improve script
* Add target argument, change usage forms in script
* Add check for more than 3 args in keyboard:keymap:target form
* Change Docker base image to debian, use community repo
This matches what qmk_compiler uses (https://github.com/qmk/qmk_compiler/blob/master/Dockerfile#L1).
I've removed the maintainer as we now have a community build on Docker Hub (https://hub.docker.com/r/qmkfm/qmk_firmware). This Dockerfile will also be maintained by the community.
* Change build command format to keyboard:keymap
* Call make directly in container run command
* Simplify script, remove 3-arg form
* Add COPY to Dockerfile so images are usable in and of themselves
Also change WORKDIR from /qmk to /qmk_firmware
* Add USB pass-through for Linux and docker-machine hosts
* Read directly into variables instead of array
* Alphabetically sort dependencies in Dockerfile
* Set executable bit on util/docker_build.sh
* Update Docker docs
* Add warning about Docker on Windows
* Expand comment in docs
* Check docker-machine exit code instead of string
* Only match --help with whole arguments
* Make script POSIX-compliant
* Convert script indentation to tabs
* handwired/minorca: refactor
- Refactored keymaps to use a layout macro, which was added to minorca.h.
- keymaps now use QMK_KEYBOARD_H include
- removed redundant KC_TRNS and KC_NO definitions
- rgb keymap refactor to use QMK core layer switching and Mod-Tap keycodes
* handwired/minorca: Configurator support
* handwired/minorca: readme cleanup
Restructure readme file to current QMK template.
* Update alps64 aek layout to work
I tried using the layout provided with my alp64 board in AEK
configuration, but keys weren't mapping correctly until I made this fix.
* Update crd's alps64 aek keymp to match other boards
(inspired by mechmerlin)
* Fix minor whitespace issue
* Initial palm_usb support
* removing left over sun .c file
* fixing licenses
* actually adding updated files
* fixing build error
* more include cleanup
* handwired/gamenum: refactor
- layout macro KEYMAP renamed to LAYOUT
- white space changes for alignment
- default keymap
- now uses #include QMK_KEYBOARD_H
- updated layout macro names
- white space changes (for readability)
* handwired/gamenum: Configurator support
* handwired/gamenum: readme cleanup
- renamed file to lowercase
- updated to match current QMK template more closely
- edits to reflect the other changes in this PR
* Add initial support for vertically-oriented animations
* DRY up vertical animation support
* Fix animation code for arm_atsam led_matrix to work in all directions
* Adjust py calculation to base off bottom rather than top
Adds Configurator support for the Sol rev. 1 by RGBKB.
Notes:
The Sol keyboard supports split thumb keys like the Ergodox - any of the 2u thumb keys can be split into two 1u keys. The matrix here is configured for fully 1u keys on the thumbs.
The Sol also supports installing a rotary encoder on each half. The key matrix given includes the encoders' functions, which are shown in the Configurator as two 1u keys side by side below each half's main key block. The left key of the two (for each side) represents that half's rotary encoder's counter-clockwise function, and the right key is that encoder's clockwise function.
* handwired/fivethirteen: refactor
- Layout macro KEYMAP renamed to LAYOUT
- Default keymap
- now uses #include QMK_KEYBOARD_H
- Removed redundant KC_TRNS definition
- Removed deprecated fn_actions and action_get_macro functions.
* handwired/fivethirteen: Configurator support
* handwired/fivethirteen: readme cleanup
Restructured readme file to be closer to current QMK template.
Couldn't find a photo of an assembled fivethirteen, so deleted the
reference to the photograph.
Renamed to readme.md
* handwired/dactyl_manuform/4x5: Configurator support
* handwired/dactyl_manuform/4x6: Configurator support
* handwired/dactyl_manuform/5x6: Configurator support
* handwired/dactyl_manuform/5x7: Configurator support
* handwired/dactyl_manuform/6x6: Configurator support
* Update to work with Planck Rev. 6
Still something that needs to be worked with under keymap.c
Qwerty layer tap-toggle function seems to be a little laggy? Not instantaneous
* Changes
Deleted some unneeded lines
* deleting unneeded lines
* my XD75 builds for idobo and XD75
these are my xd75 layouts for the 2 versions of the board
* clearing of free space
spring cleaning
* additional cleaning
more spring cleaning
* removed lighting commands
don't need lighting on the idobo board so removal of such commands to keep the sizing down
* update for readme.md
* Update config.h
* commiting with keymap erros on idobo for review
* syntax fix for idobo and xd75 revok75, addition of del key switch on fn layer
* config edit to config user and keymap QMK_KEYBOARD_H
* update to vol controls for both idobo and xd75 for revok75 keymap
* filename changes
Specifically, moved the shifted keycodes to the top of the 'Feature' list, so it's more visible. This way, all of the keycodes are at the top of the list, rather than having the shifted keys at the bottom, so they should be easier to find since they're all in one place.
* Refactor lets split to use split common code
* Refactor lets split to use split common code
* Build fixes for OLED_sample keymap
* Build fixes for OLED_sample keymap - attempt to reduce firmware size
* preonic-kuatsure: ctrl / esc in one key + hello ` again
* preonic-kuatsure: remove esc on lower
* preonic-kuatsure: programmy macros
* user-kuatsure: turn off console all the time
* preonic-kuatsure: auto shift, but only for numbers
* preonic-kuatsure: remove programmery macros
* preonic-kuatsure: move braces, parens, etc over to raise
backwards compat
move &*() on lower
* preonic-kuatsure: stop with the full rep of game layer
* Add tsangan bottom row hhkb layout for dz60
* Add crd's tsangan hhkb layout for dz60
* Resort to native key aliases when they exist
* Update crd's dz60 ansi keymap to match updates for hhkb fn layer
* Add tsangan hhkb layout to dz60 info.json for KLE
* Fix JSON nesting in dz60 layouts block
* Minor adjustments to crd layouts to make them more consistent
* Update layout naming to 60_tsangan_hhkb
* Hacker Dvorak
Programmer Dvorak based layout for the Ergodox EZ.
* Address drashna comments.
* Fix RGB and drop OSL for MO.
* Add gulp file to automate development.
* Fix gulpfile.
* Caps, num and scroll lock indicators.
* Fix scroll lock.
* Add final RGBKB Sol firmware
* Apply suggestions from code review
Apply most of the changes noroadsleft has suggested
Co-Authored-By: Legonut <legonut3@gmail.com>
* Cleanup readme
* Cleanup keymaps per @noroadslefts suggestions
* Remove eeproms, use set_single_persistent_default_layer
* Suggestions from @noroadsleft and @drashna
some small cleanup
* Change RGB_SMOD to RGB_RMOD
* fix RGB_SMOD
* Apply suggestions from code review
Remove redundant lines
Co-Authored-By: Legonut <legonut3@gmail.com>
* Break up files to make more readable
* Add comments to ortho 4x12 layout rules.mk
* Small tweaks
* Update GitLab CI scripts
* Make ortho boards smaller
- [ ] Alteration (enhancement/optimization) of existing feature(s)
- [ ] New behavior
## Description
<!-- 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. -->
<!--- 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, choose the bug report template instead, as that may be more appropriate. -->
@@ -59,6 +59,8 @@ This is a C header file that is one of the first things included, and will persi
* define is matrix has ghost (unlikely)
*`#define DIODE_DIRECTION COL2ROW`
* COL2ROW or ROW2COL - how your matrix is configured. COL2ROW means the black mark on your diode is facing to the rows, and between the switch and the rows.
* key combination that allows the use of magic commands (useful for debugging)
*`#define USB_MAX_POWER_CONSUMPTION`
* sets the maximum power (in mA) over USB for the device (default: 500)
@@ -109,9 +111,9 @@ If you define these options you will disable the associated feature, which can s
*`#define NO_ACTION_ONESHOT`
* disable one-shot modifiers
*`#define NO_ACTION_MACRO`
* disable all macro handling
* disable old style macro handling: MACRO() & action_get_macro
*`#define NO_ACTION_FUNCTION`
* disable the action function (deprecated)
* disable calling of action_function() from the fn_actions array (deprecated)
## Features That Can Be Enabled
@@ -126,6 +128,8 @@ If you define these options you will enable the associated feature, which may in
*`#define TAPPING_TERM 200`
* how long before a tap becomes a hold, if set above 500, a key tapped during the tapping term will turn it into a hold too
*`#define TAPPING_TERM_PER_KEY`
* enables handling for per key `TAPPING_TERM` settings
*`#define RETRO_TAPPING`
* tap anyway, even after TAPPING_TERM, if there was no other key interruption between press and release
* See [Retro Tapping](feature_advanced_keycodes.md#retro-tapping) for details
@@ -143,6 +147,11 @@ If you define these options you will enable the associated feature, which may in
* Breaks any Tap Toggle functionality (`TT` or the One Shot Tap Toggle)
*`#define LEADER_TIMEOUT 300`
* how long before the leader key times out
* If you're having issues finishing the sequence before it times out, you may need to increase the timeout setting. Or you may want to enable the `LEADER_PER_KEY_TIMING` option, which resets the timeout after each key is tapped.
*`#define LEADER_PER_KEY_TIMING`
* sets the timer for leader key chords to run on each key press rather than overall
*`#define LEADER_KEY_STRICT_KEY_PROCESSING`
* Disables keycode filtering for Mod-Tap and Layer-Tap keycodes. Eg, if you enable this, you would need to specify `MT(MOD_CTL, KC_A)` if you want to use `KC_A`.
*`#define ONESHOT_TIMEOUT 300`
* how long before oneshot times out
*`#define ONESHOT_TAP_TOGGLE 2`
@@ -160,15 +169,21 @@ If you define these options you will enable the associated feature, which may in
* Set this to the number of combos that you're using in the [Combo](feature_combo.md) feature.
*`#define COMBO_TERM 200`
* how long for the Combo keys to be detected. Defaults to `TAPPING_TERM` if not defined.
*`#define TAP_CODE_DELAY 100`
* Sets the delay between `register_code` and `unregister_code`, if you're having issues with it registering properly (common on VUSB boards). The value is in milliseconds.
## 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`
@@ -190,12 +205,58 @@ If you define these options you will enable the associated feature, which may in
Split Keyboard specific options, make sure you have 'SPLIT_KEYBOARD = yes' in your rules.mk
*`SPLIT_TRANSPORT = custom`
* Allows replacing the standard split communication routines with a custom one. ARM based split keyboards must use this at present.
### Setting Handedness
One thing to remember, the side that the USB port is plugged into is always the master half. The side not plugged into USB is the slave.
There are a few different ways to set handedness for split keyboards (listed in order of precedence):
1. Set `SPLIT_HAND_PIN`: Reads a pin to determine handedness. If pin is high, it's the left side, if low, the half is determined to be the right side
2. Set `EE_HANDS` and flash `eeprom-lefthand.eep`/`eeprom-righthand.eep` to each half
* For boards with DFU bootloader you can use `:dfu-split-left`/`:dfu-split-right` to flash these EEPROM files
* For boards with Caterina bootloader (like stock Pro Micros), use `:avrdude-split-left`/`:avrdude-split-right`
3. Set `MASTER_RIGHT`: Half that is plugged into the USB port is determined to be the master and right half (inverse of the default)
4. Default: The side that is plugged into the USB port is the master half and is assumed to be the left half. The slave side is the right half
#### Defines for handedness
*`#define SPLIT_HAND_PIN B7`
* For using high/low pin to determine handedness, low = right hand, high = left hand. Replace 'B7' with the pin you are using. This is optional and you can still use the EEHANDS method or MASTER_LEFT / MASTER_RIGHT defines like the stock Let's Split uses.
* For using high/low pin to determine handedness, low = right hand, high = left hand. Replace `B7` with the pin you are using. This is optional, and if you leave `SPLIT_HAND_PIN` undefined, then you can still use the EE_HANDS method or MASTER_LEFT / MASTER_RIGHT defines like the stock Let's Split uses.
*`#define EE_HANDS` (only works if `SPLIT_HAND_PIN` is not defined)
* Reads the handedness value stored in the EEPROM after `eeprom-lefthand.eep`/`eeprom-righthand.eep` has been flashed to their respective halves.
*`#define MASTER_RIGHT`
* Master half is defined to be the right half.
### Other Options
*`#define USE_I2C`
* For using I2C instead of Serial (defaults to serial)
*`#define SOFT_SERIAL_PIN D0`
* When using serial, define this. `D0` or `D1`,`D2`,`D3`,`E6`.
*`#define MATRIX_ROW_PINS_RIGHT { <row pins> }`
*`#define MATRIX_COL_PINS_RIGHT { <col pins> }`
* If you want to specify a different pinout for the right half than the left half, you can define `MATRIX_ROW_PINS_RIGHT`/`MATRIX_COL_PINS_RIGHT`. Currently, the size of `MATRIX_ROW_PINS` must be the same as `MATRIX_ROW_PINS_RIGHT` and likewise for the definition of columns.
*`#define RGBLED_SPLIT { 6, 6 }`
* See [RGB Light Configuration](#rgb-light-configuration)
*`#define SELECT_SOFT_SERIAL_SPEED <speed>` (default speed is 1)
* Sets the protocol speed when using serial communication
* Speeds:
* 0: about 189kbps (Experimental only)
* 1: about 137kbps (default)
* 2: about 75kbps
* 3: about 39kbps
* 4: about 26kbps
* 5: about 20kbps
# The `rules.mk` File
This is a [make](https://www.gnu.org/software/make/manual/make.html) file that is included by the top-level `Makefile`. It is used to set some information about the MCU that we will be compiling for as well as enabling and disabling certain features.
@@ -247,6 +308,8 @@ Use these to enable or disable building certain features. The more you have enab
* Enable the audio subsystem.
*`RGBLIGHT_ENABLE`
* Enable keyboard underlight functionality
*`LEADER_ENABLE`
* Enable leader key chording
*`MIDI_ENABLE`
* MIDI controls
*`UNICODE_ENABLE`
@@ -257,6 +320,10 @@ Use these to enable or disable building certain features. The more you have enab
* Current options are AdafruitEzKey, AdafruitBLE, RN42
*`SPLIT_KEYBOARD`
* Enables split keyboard support (dual MCU like the let's split and bakingpy's boards) and includes all necessary files located at quantum/split_common
*`CUSTOM_MATRIX`
* Allows replacing the standard matrix scanning routine with a custom one.
*`DEBOUNCE_TYPE`
* Allows replacing the standard key debouncing routine with an alternative or custom one.
*`WAIT_FOR_USB`
* Forces the keyboard to wait for a USB connection to be established before it starts up
[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%`)
Call this function to get the last received LED state. This is useful for reading the LED state outside `led_set_*`, e.g. in [`matrix_scan_user()`](#matrix-scanning-code).
For convenience, you can use the `IS_HOST_LED_ON(led_name)` and `IS_HOST_LED_OFF(led_name)` macros instead of calling and checking `host_keyboard_leds()` directly.
Before a keyboard can be used the hardware must be initialized. QMK handles initialization of the keyboard matrix itself, but if you have other hardware like LED's or i²c controllers you will need to set up that hardware before it can be used.
## Setting Physical LED State
Some keyboard implementations provide convenience methods for setting the state of the physical LEDs.
### Example `matrix_init_user()` Implementation
### Ergodox Boards
This example, at the keyboard level, sets up B1, B2, and B3 as LED pins.
The Ergodox implementations provide `ergodox_right_led_1`/`2`/`3_on`/`off()` to turn individual LEDs on or off, as well as `ergodox_right_led_on`/`off(uint8_t led)` to turn them on or off by their index.
In addition, it is possible to specify the brightness level of all LEDs with `ergodox_led_all_set(uint8_t n)`; of individual LEDs with `ergodox_right_led_1`/`2`/`3_set(uint8_t n)`; or by index with `ergodox_right_led_set(uint8_t led, uint8_t n)`.
Ergodox boards also define `LED_BRIGHTNESS_LO` for the lowest brightness and `LED_BRIGHTNESS_HI` for the highest brightness (which is the default).
# Keyboard Initialization Code
There are several steps in the keyboard initialization process. Depending on what you want to do, it will influence which function you should use.
These are the three main initialization functions, listed in the order that they're called.
*`keyboard_pre_init_*` - Happens before most anything is started. Good for hardware setup that you want running very early.
*`matrix_init_*` - Happens midway through the firmware's startup process. Hardware is initialized, but features may not be yet.
*`keyboard_post_init_*` - Happens at the end of the firmware's startup process. This is where you'd want to put "customization" code, for the most part.
!> For most people, the `keyboard_post_init_user` function is what you want to call. For instance, this is where you want to set up things for RGB Underglow.
## Keyboard Pre Initialization code
This runs very early during startup, even before the USB has been started.
Shortly after this, the matrix is initialized.
For most users, this shouldn't be used, as it's primarily for hardware oriented initialization.
However, if you have hardware stuff that you need initialized, this is the best place for it (such as initializing LED pins).
### Example `keyboard_pre_init_user()` Implementation
This example, at the keyboard level, sets up B0, B1, B2, B3, and B4 as LED pins.
This is called when the matrix is initialized, and after some of the hardware has been set up, but before many of the features have been initialized.
This is useful for setting up stuff that you may need elsewhere, but isn't hardware related nor is dependant on where it's started.
### `matrix_init_*` Function Documentation
* Keyboard/Revision: `void matrix_init_kb(void)`
* Keymap: `void matrix_init_user(void)`
## Keyboard Post Initialization code
This is ran as the very last task in the keyboard initialization process. This is useful if you want to make changes to certain features, as they should be initialized by this point.
### Example `keyboard_post_init_user()` Implementation
This example, running after everything else has initialized, sets up the rgb underglow configuration.
```c
voidkeyboard_post_init_user(void){
// Call the post init code.
rgblight_enable_noeeprom();// enables Rgb, without saving settings
rgblight_sethsv_noeeprom(180,255,255);// sets the color to teal/cyan without saving
rgblight_mode_noeeprom(RGBLIGHT_MODE_BREATHING+3);// sets mode to Fast breathing without saving
Whenever possible you should customize your keyboard by using `process_record_*()` and hooking into events that way, to ensure that your code does not have a negative performance impact on your keyboard. However, in rare cases it is necessary to hook into the matrix scanning. Be extremely careful with the performance of code in these functions, as it will be called at least 10 times per second.
@@ -176,7 +260,7 @@ This example has been deliberately omitted. You should understand enough about Q
This function gets called at every matrix scan, which is basically as often as the MCU can handle. Be careful what you put here, as it will get run a lot.
You should use this function if you need custom matrix scanning code. It can also be used for custom status output (such as LED's or a display) or other functionality that you want to trigger regularly even when the user isn't typing.
You should use this function if you need custom matrix scanning code. It can also be used for custom status output (such as LEDs or a display) or other functionality that you want to trigger regularly even when the user isn't typing.
# Keyboard Idling/Wake Code
@@ -188,22 +272,18 @@ This is controlled by two functions: `suspend_power_down_*` and `suspend_wakeup_
### Example suspend_power_down_user() and suspend_wakeup_init_user() Implementation
This example, at the keyboard level, sets up B1, B2, and B3 as LED pins.
```c
voidsuspend_power_down_user(void)
{
voidsuspend_power_down_user(void){
rgb_matrix_set_suspend_state(true);
}
voidsuspend_wakeup_init_user(void)
{
voidsuspend_wakeup_init_user(void){
rgb_matrix_set_suspend_state(false);
}
```
### `keyboard_init_*` Function Documentation
### Keyboard suspend/wake Function Documentation
* Keyboard/Revision: `void suspend_power_down_kb(void)` and `void suspend_wakeup_init_user(void)`
* Keymap: `void suspend_power_down_kb(void)` and `void suspend_wakeup_init_user(void)`
The `state` is the bitmask of the active layers, as explained in the [Keymap Overview](keymap.md#keymap-layer-status)
@@ -256,13 +337,13 @@ Keep in mind that EEPROM has a limited number of writes. While this is very high
* If you don't understand the example, then you may want to avoid using this feature, as it is rather complicated.
### Example Implementation
### Example Implementation
This is an example of how to add settings, and read and write it. We're using the user keymap for the example here. This is a complex function, and has a lot going on. In fact, it uses a lot of the above functions to work!
In your keymap.c file, add this to the top:
```
```c
typedefunion{
uint32_traw;
struct{
@@ -275,11 +356,11 @@ user_config_t user_config;
This sets up a 32 bit structure that we can store settings with in memory, and write to the EEPROM. Using this removes the need to define variables, since they're defined in this structure. Remember that `bool` (boolean) values use 1 bit, `uint8_t` uses 8 bits, `uint16_t` uses up 16 bits. You can mix and match, but changing the order can cause issues, as it will change the values that are read and written.
We're using `rgb_layer_change`, for the `layer_state_set_*` function, and use `matrix_init_user` and `process_record_user` to configure everything.
We're using `rgb_layer_change`, for the `layer_state_set_*` function, and use `keyboard_post_init_user` and `process_record_user` to configure everything.
Now, using the `matrix_init_user` code above, you want to add `eeconfig_read_user()` to it, to populate the structure you've just created. And you can then immediately use this structure to control functionality in your keymap. And It should look like:
```
void matrix_init_user(void) {
Now, using the `keyboard_post_init_user` code above, you want to add `eeconfig_read_user()` to it, to populate the structure you've just created. And you can then immediately use this structure to control functionality in your keymap. And It should look like:
```c
void keyboard_post_init_user(void){
// Call the keymap level matrix init.
// Read the user config from EEPROM
@@ -295,7 +376,7 @@ void matrix_init_user(void) {
```
The above function will use the EEPROM config immediately after reading it, to set the default layer's RGB color. The "raw" value of it is converted in a usable structure based on the "union" that you created above.
This will cause the RGB underglow to be changed ONLY if the value was enabled. Now to configure this value, create a new keycode for `process_record_user` called `RGB_LYR` and `EPRM`. Additionally, we want to make sure that if you use the normal RGB codes, that it turns off Using the example above, make it look this:
```
This will cause the RGB underglow to be changed ONLY if the value was enabled. Now to configure this value, create a new keycode for `process_record_user` called `RGB_LYR`. Additionally, we want to make sure that if you use the normal RGB codes, that it turns off Using the example above, make it look this:
And lastly, you want to add the `eeconfig_init_user` function, so that when the EEPROM is reset, you can specify default values, and even custom actions. For example, if you want to set rgb layer indication by default, and save the default valued.
And lastly, you want to add the `eeconfig_init_user` function, so that when the EEPROM is reset, you can specify default values, and even custom actions. To force an EEPROM reset, use the `EEP_RST` keycode or [Bootmagic](feature_bootmagic.md) functionallity. For example, if you want to set rgb layer indication by default, and save the default valued.
```
```c
voideeconfig_init_user(void){// EEPROM is getting reset!
user_config.raw=0;
user_config.rgb_layer_change=true;// We want this enabled by default
eeconfig_update_user(user_config.raw);// Write default value to EEPROM now
@@ -384,3 +461,31 @@ And you're done. The RGB layer indication will only work if you want it to. And
* Keymap: `void eeconfig_init_user(void)`, `uint32_t eeconfig_read_user(void)` and `void eeconfig_update_user(uint32_t val)`
The `val` is the value of the data that you want to write to EEPROM. And the `eeconfig_read_*` function return a 32 bit (DWORD) value from the EEPROM.
# Custom Tapping Term
By default, the tapping term is defined globally, and is not configurable by key. For most users, this is perfectly fine. But in come cases, dual function keys would be greatly improved by different timeouts than `LT` keys, or because some keys may be easier to hold than others. Instead of using custom key codes for each, this allows for per key configurable `TAPPING_TERM`.
To enable this functionality, you need to add `#define TAPPING_TERM_PER_KEY` to your `config.h`, first.
## Example `get_tapping_term` Implementation
To change the `TAPPING TERM` based on the keycode, you'd want to add something like the following to your `keymap.c` file:
```c
uint16_tget_tapping_term(uint16_tkeycode){
switch(keycode){
caseSFT_T(KC_SPC):
returnTAPPING_TERM+1250;
caseLT(1,KC_GRV):
return130;
default:
returnTAPPING_TERM;
}
}
```
### `get_tapping_term` Function Documentation
Unlike many of the other functions here, there isn't a need (or even reason) to have a quantum or keyboard level function. Only a user level function is useful here, so no need to mark it as such.
### Serial device is not detected in bootloader mode on Linux
Make sure your kernel has appropriate support for your device. If your device uses USB ACM, such as
Pro Micro (Atmega32u4), make sure to include `CONFIG_USB_ACM=y`. Other devices may require `USB_SERIAL` and any of its sub options.
## Unknown Device for DFU Bootloader
If you're using Windows to flash your keyboard, and you are running into issues, check the Device Manager. If you see an "Unknown Device" when the keyboard is in "bootloader mode", then you may have a driver issue.
If you're using Windows to flash your keyboard, and you are running into issues, check the Device Manager. If you see an "Unknown Device" when the keyboard is in "bootloader mode", then you may have a driver issue.
Re-running the installation script for MSYS2 may help (eg run `./util/qmk_install.sh` from MSYS2/WSL) or reinstalling the QMK Toolbox may fix the issue.
Re-running the installation script for MSYS2 may help (eg run `./util/qmk_install.sh` from MSYS2/WSL) or reinstalling the QMK Toolbox may fix the issue.
If that doesn't work, then you may need to grab the [Zadig Utility](https://zadig.akeo.ie/). Download this, find the device in question, and select the `WinUSB` option, and hit "Reinstall driver". Once you've done that, try flashing your board, again. If that doesn't work, try all of the options, until one works.
?> There isn't a best option for which driver should be used here. Some options work better on some systems than others. libUSB and WinUSB seem to be the best options here.
If the bootloader doesn't show up in the list for devices, you may need to enable the "List all devices" option in the `Options` menu, and then find the bootloader in question.
If that doesn't work, then you may need to grab the [Zadig Utility](https://zadig.akeo.ie/). Download this, find the device in question, and select the `WinUS(libusb-1.0)` option, and hit "Reinstall driver". Once you've done that, try flashing your board, again.
## WINAVR is Obsolete
It is no longer recommended and may cause some problem.
### I just flashed my keyboard and it does nothing/keypresses don't register - it's also ARM (rev6 planck, clueboard 60, hs60v2, etc...) (Feb 2019)
Due to how EEPROM works on ARM based chips, saved settings may no longer be valid. This affects the default layers, and *may*, under certain circumstances we are still figuring out, make the keyboard unusable. Resetting the EEPROM will correct this.
[Planck rev6 reset EEPROM](https://cdn.discordapp.com/attachments/473506116718952450/539284620861243409/planck_rev6_default.bin) can be used to force an eeprom reset. After flashing this image, flash your normal firmware again which should restore your keyboard to _normal_ working order.
If bootmagic is enabled in any form, you should be able to do this too (see [Bootmagic docs](feature_bootmagic.md) and keyboard info for specifics on how to do this).
@@ -11,21 +11,21 @@ People often define custom names using `#define`. For example:
#define ALT_TAB LALT(KC_TAB)
```
This will allow you to use `FN_CAPS` and `ALT_TAB` in your `KEYMAP()`, keeping it more readable.
This will allow you to use `FN_CAPS` and `ALT_TAB` in your keymap, keeping it more readable.
## Caveats
Currently, `LT()` and `MT()` are limited to the [Basic Keycode set](keycodes_basic.md), meaning you can't use keycodes like `LCTL()`, `KC_TILD`, or anything greater than `0xFF`. Modifiers specified as part of a Layer Tap or Mod Tap's keycode will be ignored.
Currently, `LT()` and `MT()` are limited to the [Basic Keycode set](keycodes_basic.md), meaning you can't use keycodes like `LCTL()`, `KC_TILD`, or anything greater than `0xFF`. Modifiers specified as part of a Layer Tap or Mod Tap's keycode will be ignored. If you need to apply modifiers to your tapped keycode, [Tap Dance](https://github.com/qmk/qmk_firmware/blob/master/docs/feature_tap_dance.md#example-5-using-tap-dance-for-advanced-mod-tap-and-layer-tap-keys) can be used to accomplish this.
Additionally, if at least one right-handed modifier is specified in a Mod Tap or Layer Tap, it will cause all modifiers specified to become right-handed, so it is not possible to mix and match the two.
# Switching and Toggling Layers
These functions allow you to activate layers in various ways. Note that layers are not generally independent layouts -- multiple layers can be activated at once, and it's typical for layers to use `KC_TRNS` to allow keypresses to pass through to lower layers. For a detailed explanation of layers, see [Keymap Overview](keymap.md#keymap-and-layers)
These functions allow you to activate layers in various ways. Note that layers are not generally independent layouts -- multiple layers can be activated at once, and it's typical for layers to use `KC_TRNS` to allow keypresses to pass through to lower layers. For a detailed explanation of layers, see [Keymap Overview](keymap.md#keymap-and-layers). When using momentary layer switching with MO(), LM(), TT(), or LT(), make sure to leave the key on the above layers transparent or it may not work as intended.
*`DF(layer)` - switches the default layer. The default layer is the always-active base layer that other layers stack on top of. See below for more about the default layer. This might be used to switch from QWERTY to Dvorak layout. (Note that this is a temporary switch that only persists until the keyboard loses power. To modify the default layer in a persistent way requires deeper customization, such as calling the `set_single_persistent_default_layer` function inside of [process_record_user](custom_quantum_functions.md#programming-the-behavior-of-any-keycode).)
*`MO(layer)` - momentarily activates *layer*. As soon as you let go of the key, the layer is deactivated.
*`LM(layer, mod)` - Momentarily activates *layer* (like `MO`), but with modifier(s) *mod* active. Only supports layers 0-15 and the left modifiers.
*`LM(layer, mod)` - Momentarily activates *layer* (like `MO`), but with modifier(s) *mod* active. Only supports layers 0-15 and the left modifiers: `MOD_LCTL`, `MOD_LSFT`, `MOD_LALT`, `MOD_LGUI` (note the use of `MOD_` constants instead of `KC_`). These modifiers can be combined using bitwise OR, e.g. `LM(_RAISE, MOD_LCTL | MOD_LALT)`.
*`LT(layer, kc)` - momentarily activates *layer* when held, and sends *kc* when tapped. Only supports layers 0-15.
*`OSL(layer)` - momentarily activates *layer* until the next key is pressed. See [One Shot Keys](#one-shot-keys) for details and additional functionality.
*`TG(layer)` - toggles *layer*, activating it if it's inactive and vice versa
@@ -60,21 +60,21 @@ Sometimes, you might want to switch between layers in a macro or as part of a ta
These allow you to combine a modifier with a keycode. When pressed, the keydown event for the modifier, then `kc` will be sent. On release, the keyup event for `kc`, then the modifier will be sent.
|`LCTL_T(kc)`|`CTL_T(kc)` |Left Control when held, `kc` when tapped |
|`RCTL_T(kc)`| |Right Control when held, `kc` when tapped |
|`LSFT_T(kc)`|`SFT_T(kc)` |Left Shift when held, `kc` when tapped |
|`RSFT_T(kc)`| |Right Shift when held, `kc` when tapped |
|`LALT_T(kc)`|`ALT_T(kc)`|Left Alt when held, `kc` when tapped |
|`RALT_T(kc)`|`ALGR_T(kc)` |Right Alt when held, `kc` when tapped |
|`LGUI_T(kc)`|`LCMD_T(kc)`, `RWIN_T(kc)`, `GUI_T(kc)`|Left GUI when held, `kc` when tapped |
|`RGUI_T(kc)`|`RCMD_T(kc)`, `RWIN_T(kc)` |Right GUI when held, `kc` when tapped |
|`C_S_T(kc)` | |Left Control and Shift when held, `kc` when tapped |
|`MEH_T(kc)` | |Left Control, Shift and Alt when held, `kc` when tapped|
|`LCAG_T(kc)`| |Left Control, Alt and GUI when held, `kc` when tapped |
|`RCAG_T(kc)`| |Right Control, Alt and GUI when held, `kc` when tapped |
|`ALL_T(kc)` | |Left Control, Shift, Alt and GUI when held, `kc` when tapped - more info [here](http://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/)|
|`SGUI_T(kc)`|`SCMD_T(kc)`, `SWIN_T(kc)` |Left Shift and GUI when held, `kc` when tapped|
|`LCA_T(kc)` | |Left Control and Alt when held, `kc` when tapped |
|`LCTL_T(kc)`|`CTL_T(kc)`|Left Control when held, `kc` when tapped |
|`LSFT_T(kc)`|`SFT_T(kc)` |Left Shift when held, `kc` when tapped |
|`LALT_T(kc)`|`ALT_T(kc)`|Left Alt when held, `kc` when tapped |
|`LGUI_T(kc)`|`LCMD_T(kc)`, `LWIN_T(kc)`, `GUI_T(kc)`, `CMD_T(kc)`, `WIN_T(kc)`|Left GUI when held, `kc` when tapped |
|`RCTL_T(kc)`| |Right Control when held, `kc` when tapped |
|`RSFT_T(kc)`||Right Shift when held, `kc` when tapped |
|`RALT_T(kc)`|`ALGR_T(kc)` |Right Alt when held, `kc` when tapped |
|`RGUI_T(kc)`|`RCMD_T(kc)`, `RWIN_T(kc)` |Right GUI when held, `kc` when tapped |
|`SGUI_T(kc)`|`SCMD_T(kc)`, `SWIN_T(kc)` |Left Shift and GUI when held, `kc` when tapped |
|`LCA_T(kc)` | |Left Control and Alt when held, `kc` when tapped|
|`LCAG_T(kc)`| |Left Control, Alt and GUI when held, `kc` when tapped |
|`RCAG_T(kc)`| |Right Control, Alt and GUI when held, `kc` when tapped |
|`C_S_T(kc)` | |Left Control and Shift when held, `kc` when tapped |
|`MEH_T(kc)` | |Left Control, Shift and Alt when held, `kc` when tapped|
|`HYPR_T(kc)`|`ALL_T(kc)` |Left Control, Shift, Alt and GUI when held, `kc` when tapped - more info [here](http://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/)|
## Caveats
@@ -146,7 +146,7 @@ Additionally, hitting keys five times in a short period will lock that key. This
You can control the behavior of one shot keys by defining these in `config.h`:
```c
#define ONESHOT_TAP_TOGGLE 5 /* Tapping this number of times holds the key until tapped this number of times again. */
#define ONESHOT_TAP_TOGGLE 5 /* Tapping this number of times holds the key until tapped once again. */
#define ONESHOT_TIMEOUT 5000 /* Time (in ms) before the one shot key is released */
```
@@ -161,8 +161,88 @@ 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
# Permissive Hold
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.
These options let you modify the behavior of the Tap-Hold keys.
## Permissive Hold
As of [PR#1359](https://github.com/qmk/qmk_firmware/pull/1359/), there is a new `config.h` option:
@@ -185,7 +265,7 @@ Normally, if you do all this within the `TAPPING_TERM` (default: 200ms) this wil
?> If you have `Ignore Mod Tap Interrupt` enabled, as well, this will modify how both work. The regular key has the modifier added if the first key is released first or if both keys are held longer than the `TAPPING_TERM`.
# Ignore Mod Tap Interrupt
## Ignore Mod Tap Interrupt
To enable this setting, add this to your `config.h`:
@@ -211,7 +291,7 @@ Normally, this would send `X` (`SHIFT`+`x`). With `Ignore Mod Tap Interrupt` ena
?> If you have `Permissive Hold` enabled, as well, this will modify how both work. The regular key has the modifier added if the first key is released first or if both keys are held longer than the `TAPPING_TERM`.
# Tapping Force Hold
## Tapping Force Hold
To enable `tapping force hold`, add the following to your `config.h`:
@@ -235,7 +315,7 @@ With `TAPPING_FORCE_HOLD`, the second press will be interpreted as a Shift, allo
!> `TAPPING_FORCE_HOLD` will break anything that uses tapping toggles (Such as the `TT` layer keycode, and the One Shot Tapping Toggle).
# Retro Tapping
## Retro Tapping
To enable `retro tapping`, add the following to your `config.h`:
@@ -61,9 +61,11 @@ It's advised that you wrap all audio features in `#ifdef AUDIO_ENABLE` / `#endif
The available keycodes for audio are:
*`AU_ON` - Turn audio mode on
*`AU_OFF` - Turn audio mode off
*`AU_TOG` - Toggle audio mode
*`AU_ON` - Turn Audio Feature on
*`AU_OFF` - Turn Audio Feature off
*`AU_TOG` - Toggle Audio Feature state
!> These keycodes turn all of the audio functionality on and off. Turning it off means that audio feedback, audio clicky, music mode, etc. are disabled, completely.
## ARM Audio Volume
@@ -98,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
@@ -118,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.
## Audio Click
@@ -158,7 +183,7 @@ You can configure the default, min and max frequencies, the stepping and built i
## MIDI Functionality
This is still a WIP, but check out `quantum/keymap_midi.c` to see what's happening. Enable from the Makefile.
This is still a WIP, but check out `quantum/process_keycode/process_midi.c` to see what's happening. Enable from the Makefile.
@@ -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 |
@@ -5,10 +5,11 @@ If you've ever used Vim, you know what a Leader key is. If not, you're about to
That's what `KC_LEAD` does. Here's an example:
1. Pick a key on your keyboard you want to use as the Leader key. Assign it the keycode `KC_LEAD`. This key would be dedicated just for this -- it's a single action key, can't be used for anything else.
2. Include the line `#define LEADER_TIMEOUT 300` in your config.h. The 300 there is 300ms -- that's how long you have for the sequence of keys following the leader. You can tweak this value for comfort, of course.
3. Within your `matrix_scan_user` function, do something like this:
2. Include the line `#define LEADER_TIMEOUT 300` in your `config.h`. This sets the timeout for the `KC_LEAD` key. Specifically, when you press the `KC_LEAD` key, you only have a certain amount of time to complete the Leader Key sequence. The `300` here sets that to 300ms, and you can increase this value to give you more time to hit the sequence. But any keys pressed during this timeout are intercepted and not sent, so you may want to keep this value low. .
* By default, this timeout is how long after pressing `KC_LEAD` to complete your entire sequence. This may be very low for some people. So you may want to increase this timeout. Optionally, you may want to enable the `LEADER_PER_KEY_TIMING` option, which resets the timeout after each key is tapped. This allows you to maintain a low value here, but still be able to use the longer sequences. To enable this option, add `#define LEADER_PER_KEY_TIMING` to your `config.h`.
3. Within your `matrix_scan_user` function, add something like this:
```
```c
LEADER_EXTERNS();
voidmatrix_scan_user(void){
@@ -44,6 +45,102 @@ Each of these accepts one or more keycodes as arguments. This is an important po
To add support for Leader Key you simply need to add a single line to your keymap's `rules.mk`:
```
```make
LEADER_ENABLE= yes
```
## Per Key Timing on Leader keys
Rather than relying on an incredibly high timeout for long leader key strings or those of us without 200wpm typing skills, we can enable per key timing to ensure that each key pressed provides us with more time to finish our stroke. This is incredibly helpful with leader key emulation of tap dance (read: multiple taps of the same key like C, C, C).
In order to enable this, place this in your `config.h`:
```c
#define LEADER_PER_KEY_TIMING
```
After this, it's recommended that you lower your `LEADER_TIMEOUT` to something less that 300ms.
```c
#define LEADER_TIMEOUT 250
```
Now, something like this won't seem impossible to do without a 1000MS leader key timeout:
```c
SEQ_THREE_KEYS(KC_C,KC_C,KC_C){
SEND_STRING("Per key timing is great!!!");
}
```
## Strict Key Processing
By default, the Leader Key feature will filter the keycode out of [`Mod-Tap`](feature_advanced_keycodes.md#mod-tap) and [`Layer Tap`](feature_advanced_keycodes.md#switching-and-toggling-layers) functions when checking for the Leader sequences. That means if you're using `LT(3, KC_A)`, it will pick this up as `KC_A` for the sequence, rather than `LT(3, KC_A)`, giving a more expected behavior for newer users.
While, this may be fine for most, if you want to specify the whole keycode (eg, `LT(3, KC_A)` from the example above) in the sequence, you can enable this by added `#define LEADER_KEY_STRICT_KEY_PROCESSING` to your `config.h` file. This well then disable the filtering, and you'll need to specify the whole keycode.
## Customization
The Leader Key feature has some additional customization to how the Leader Key feature works. It has two functions that can be called at certain parts of the process. Namely `leader_start()` and `leader_end()`.
The `leader_start()` function is called when you tap the `KC_LEAD` key, and the `leader_end()` function is called when either the leader sequence is completed, or the leader timeout is hit.
You can add these functions to your code (`keymap.c` usually) to add feedback to the Leader sequences (such as beeping or playing music).
```c
voidleader_start(void){
// sequence started
}
voidleader_end(void){
// sequence ended (no success/failuer detection)
}
```
### Example
This example will play the Mario "One Up" sound when you hit `KC_LEAD` to start the Leader Sequence, and will play "All Star" if it completes successfully or "Rick Roll" you if it fails.
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`:
We first define a new custom keycode in the range not occupied by any other keycodes.
Then we use the `process_record_user` function, which is called whenever a key is pressed or released, to check if our custom keycode has been activated.
If yes, we send the string `"QMK is the best thing ever!"` to the computer via the `SEND_STRING` macro (this is a C preprocessor macro, not to be confused with QMK macros).
We return `false` to indicate to the caller that the key press we just processed need not be processed any further.
We return `true` to indicate to the caller that the key press we just processed should continue to be processed as normal (as we didn't replace or alter the functionality).
Finally, we define the keymap so that the first button activates our macro and the second button is just an escape button.
You might want to add more than one macro.
@@ -45,28 +49,42 @@ You can do that by adding another keycode and adding another case to the switch
This defines two macros which will be run when the key they are assigned to is pressed. If instead you'd like them to run when the key is released you can change the if statement:
if (!record->event.pressed) {
### Macro Commands
A macro can include the following commands:
* I() change interval of stroke in milliseconds.
* D() press key.
* U() release key.
* T() type key(press and release).
* W() wait (milliseconds).
* END end mark.
### 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:
When you press the key on the left it will type "Hi!" and when you press the key on the right it will type "Bye!".
### Naming Your Macros
If you have a bunch of macros you want to refer to from your keymap while keeping the keymap easily readable you can name them using `#define` at the top of your file.
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.
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
}
if(record->event.pressed){
// on keydown
}else{
// on keyup
}
```
### `register_code(<kc>);`
@@ -232,6 +175,14 @@ Parallel to `register_code` function, this sends the `<kc>` keyup event to the c
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.
@@ -244,22 +195,100 @@ This will clear all mods currently pressed.
This will clear all keys besides the mods currently pressed.
## Advanced Example: Single-Key Copy/Paste
## **(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:
This defines two macros which will be run when the key they are assigned to is pressed. If instead you'd like them to run when the key is released you can change the if statement:
if (!record->event.pressed) {
### Macro Commands
A macro can include the following commands:
* I() change interval of stroke in milliseconds.
* D() press key.
* U() release key.
* T() type key(press and release).
* W() wait (milliseconds).
* END end mark.
### 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:
When you press the key on the left it will type "Hi!" and when you press the key on the right it will type "Bye!".
### Naming Your Macros
If you have a bunch of macros you want to refer to from your keymap while keeping the keymap easily readable you can name them using `#define` at the top of your file.
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_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`.
@@ -185,29 +185,11 @@ Below is a specific example:
## Setup
You will need a few things that can be used for 'Quad Function Tap-Dance'. The suggested setup is to create a user directory for yourself. This directory will contain rules.mk `<your_name>.c` and `<your_name>.h`. This directory should be called `<your_name>`, and located in the top level `users` directory. There should already be a few examples to look at there.
You will need a few things that can be used for 'Quad Function Tap-Dance'.
### In `/qmk_firmware/users/<your_name>/rules.mk`
Put the following:
```c
TAP_DANCE_ENABLE=yes
SRC+=your_name.c
```
Pretty simple. It is a nice way to keep some rules common on all your keymaps.
### In `/qmk_firmware/users/<your_name>/<your_name>.h`
You will need a few things in this file:
You'll need to add these to the top of your `keymap.c` file, before your keymap.
```c
#pragma once
#include"quantum.h"
#include"process_keycode/process_tap_dance.h"
typedefstruct{
boolis_press_action;
intstate;
@@ -234,18 +216,12 @@ int cur_dance (qk_tap_dance_state_t *state);
//for the x tap dance. Put it here so it can be used in any keymap
And then simply use `TD(X_CTL)` anywhere in your keymap after including `<your_name>.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
There are three Unicode keymap definition method available in QMK:
There are three Unicode keymap definition methods available in QMK:
## UNICODE_ENABLE
## `UNICODE_ENABLE`
Supports Unicode input up to 0xFFFF. The keycode function is `UC(n)` in keymap file, where *n* is a 4 digit hexadecimal.
Supports Unicode up to `0x7FFF`. This covers characters for most modern languages, as well as symbols, but it doesn't cover emoji. The keycode function is `UC(c)` in the keymap file, where _c_ is the code point's number (preferably hexadecimal, up to 4 digits long). For example: `UC(0x45B)`, `UC(0x30C4)`.
## UNICODEMAP_ENABLE
## `UNICODEMAP_ENABLE`
Supports Unicode up to 0xFFFFFFFF. You need to maintain a separate mapping table `const uint32_t PROGMEM unicode_map[] = {...}` in your keymap file. The keycode function is `X(n)` where *n* is the array index of the mapping table.
Supports Unicode up to `0x10FFFF` (all possible code points). You need to maintain a separate mapping table `const uint32_t PROGMEM unicode_map[] = {...}` in your keymap file. The keycode function is `X(i)`, where _i_ is an array index into the mapping table. The table may contain at most 1024 entries.
And you may want to have an enum to make reference easier. So you'd want to add something like this to your keymap:
You may want to have an enum to make referencing easier. So, you could add something like this to your keymap file:
```c
enumunicode_name{
BANG,// ‽
IRONY,// ⸮
SNEK// snke 🐍
enumunicode_names{
BANG,
IRONY,
SNEK,
};
constuint32_tPROGMEMunicode_map[]={
[BANG]=0x0203D,// ‽
[IRONY]=0x02E2E,// ⸮
[SNEK]=0x1F40D// snke 🐍
}:
[BANG]=0x203D,// ‽
[IRONY]=0x2E2E,// ⸮
[SNEK]=0x1F40D,// 🐍
};
```
Make sure that the order for both matches.
Then you can use `X(BANG)` etc. in your keymap.
## UCIS_ENABLE
## `UCIS_ENABLE`
Supports Unicode up to 0xFFFFFFFF. As with `UNICODE_MAP`, you may want to maintain a mapping table in your keymap file. However, there is no keycodes for this feature, you will have to add a keycode or function to call `qk_ucis_start()`. Once you've run that, you can just type the text for your unicode, and then hit space or enter to complete it, or ESC to cancel it. And if it matches an entry in your table, it will automatically "backspace" the trigger word (from your table) and then will input the unicode sequence.
Supports Unicode up to `0x10FFFF` (all possible code points). As with `UNICODEMAP`, you need to maintain a mapping table in your keymap file. However, there are no built-in keycodes for this feature — you will have to add a keycode or function that calls`qk_ucis_start()`. Once this function's been called, you can type the corresponding mnemonic for your character, then hit Space or Enter to complete it, or Esc to cancel. If the mnemonic matches an entry in your table, the typed text will automatically be erased and the corresponding Unicode character inserted.
For instance, you would need to have a table like this in your keymap:
For instance, you would define a table like this in your keymap file:
You run the function, and then type "rofl" and hit enter, it should backspace remove "rofl" and input the `0x1f923` unicode.
You call `qk_ucis_start()`, then type "rofl" and hit Enter. QMK should erase the "rofl" text and input the laughing emoji.
### Customization
There are several functions that you can add to your keymap to customize the functionality of this feature.
There are several functions that you can define in your keymap to customize the functionality of this feature.
*`void qk_ucis_start_user(void)`- This runs when you run the "start" function, and can be used to provide feedback. By default, it types out a keyboard emoji.
*`void qk_ucis_success(uint8_t symbol_index)`- This runs when the unicode input has matched something, and has completed. Default doesn't do anything.
*`void qk_ucis_symbol_fallback (void)`- This runs if the input text doesn't match anything. The default function falls back to trying that input as a unicode code.
*`void qk_ucis_start_user(void)`– This runs when you call the "start" function, and can be used to provide feedback. By default, it types out a keyboard emoji.
*`void qk_ucis_success(uint8_t symbol_index)`– This runs when the input has matched something and has completed. By default, it doesn't do anything.
*`void qk_ucis_symbol_fallback (void)`– This runs when the input doesn't match anything. By default, it falls back to trying that input as a Unicode code.
The default code for these are:
You can find the default implementations of these functions in [`process_ucis.c`](https://github.com/qmk/qmk_firmware/blob/master/quantum/process_keycode/process_ucis.c).
## Input Modes
Unicode input in QMK works by inputting a sequence of characters to the OS, sort of like a macro. Unfortunately, the way this is done differs for each platform. Specifically, each platform requires a different combination of keys to trigger Unicode input. Therefore, a corresponding input mode has to be set in QMK.
The following input modes are available:
* **`UC_OSX`**: Mac OS X built-in Unicode hex input. Supports code points up to `0xFFFF` (`0x10FFFF` with `UNICODEMAP`).
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.
* **`UC_WIN`**: _(not recommended)_ Windows built-in hex numpad Unicode input. Supports code points up to `0xFFFF`.
To enable, create a registry key under `HKEY_CURRENT_USER\Control Panel\Input Method\EnableHexNumpad` of type `REG_SZ` called `EnableHexNumpad` and set its value to `1`. This can be done from the Command Prompt by running `reg add "HKCU\Control Panel\Input Method" -v EnableHexNumpad -t REG_SZ -d 1` with administrator privileges. Afterwards, reboot.
This mode is not recommended because of reliability and compatibility issues; use the `UC_WINC` mode instead.
* **`UC_BSD`**: _(non implemented)_ Unicode input under BSD. Not implemented at this time. If you're a BSD user and want to help add support for it, please [open an issue on GitHub](https://github.com/qmk/qmk_firmware/issues).
* **`UC_WINC`**: Windows Unicode input using [WinCompose](https://github.com/samhocevar/wincompose). As of v0.8.2, supports code points up to `0xFFFFF` (all currently assigned code points).
To enable, install the [latest release](https://github.com/samhocevar/wincompose/releases/latest). Once installed, WinCompose will automatically run on startup. Works reliably under all version of Windows supported by the app.
By default, this mode uses the right Alt key (`KC_RALT`), but this can be changed in the WinCompose settings and by defining [`UNICODE_WINC_KEY`](#input-key-configuration) with another keycode.
### Switching Input Modes
There are two ways to set the input mode for Unicode: by keycode or by function. Keep in mind that both methods write to persistent storage (EEPROM), and are loaded each time the keyboard starts. So once you've set it the first time, you don't need to set it again unless you want to change it, or you've reset the EEPROM settings.
You can switch the input mode at any time by using one of the following keycodes. The easiest way is to add the ones you use to your keymap.
|`UNICODE_MODE_FORWARD` |`UC_MOD` | |Cycles forwards through the available modes. [(Disabled by default)](#input-method-cycling)|
|`UNICODE_MODE_REVERSE` |`UC_RMOD`| |Cycles forwards through the available modes. [(Disabled by default)](#input-method-cycling)|
|`UNICODE_MODE_OSX` |`UC_M_OS`|`UC_OSX` |Switch to Mac OS X input. |
|`UNICODE_MODE_LNX` |`UC_M_LN`|`UC_LNX` |Switch to Linux input. |
|`UNICODE_MODE_WIN` |`UC_M_WI`|`UC_WIN` |Switch to Windows input. |
|`UNICODE_MODE_BSD` |`UC_M_BS`|`UC_BSD` |Switch to BSD input (not implemented). |
|`UNICODE_MODE_WINC` |`UC_M_WC`|`UC_WINC` |Switch to Windows input using WinCompose.|
You can also switch the input mode by calling `set_unicode_input_mode(x)` in your code, where _x_ is one of the above input mode constants (e.g. `UC_LNX`). Since the function only needs to be called once, it's recommended that you do it in `eeconfig_init_user` (or a similar function). For example:
voidqk_ucis_symbol_fallback(void){// falls back to manual unicode entry
for(uint8_ti=0;i<qk_ucis_state.count-1;i++){
uint8_tcode=qk_ucis_state.codes[i];
register_code(code);
unregister_code(code);
wait_ms(UNICODE_TYPE_DELAY);
}
voideeconfig_init_user(void){
set_unicode_input_mode(UC_LNX);
}
```
## Unicode Input methods
### Audio Feedback
Unicode input in QMK works by inputting a sequence of characters to the OS,
sort of like macro. Unfortunately, each OS has different ideas on how Unicode is input.
If you have the [Audio feature](feature_audio.md) enabled on the board, you can set melodies to be played when you press the above keys. That way you can have some audio feedback when switching input modes.
This is the current list of Unicode input method in QMK:
For instance, you can add these definitions to your `config.h` file:
* __UC_OSX__: MacOS Unicode Hex Input support. Works only up to 0xFFFF. Disabled by default. To enable: go to System Preferences -> Keyboard -> Input Sources, and enable Unicode Hex.
* __UC_OSX_RALT__: Same as UC_OSX, but sends the Right Alt key for unicode input
* __UC_LNX__: Unicode input method under Linux. Works up to 0xFFFFF. Should work almost anywhere on ibus enabled distros. Without ibus, this works under GTK apps, but rarely anywhere else.
* __UC_WIN__: (not recommended) Windows built-in Unicodeinput. To enable: create registry key under `HKEY_CURRENT_USER\Control Panel\Input Method\EnableHexNumpad` of type `REG_SZ` called `EnableHexNumpad`, set its value to 1, and reboot. This method is not recommended because of reliability and compatibility issue, use WinCompose method below instead.
* __UC_WINC__: Windows Unicode input using WinCompose. Requires [WinCompose](https://github.com/samhocevar/wincompose). Works reliably under many (all?) variations of Windows.
```c
#define UNICODE_SONG_OSX COIN_SOUND
#define UNICODE_SONG_LNX UNICODE_LINUX
#define UNICODE_SONG_BSD MARIO_GAMEOVER
#define UNICODE_SONG_WIN UNICODE_WINDOWS
#define UNICODE_SONG_WINC UNICODE_WINDOWS
```
At some point, you need to call `set_unicode_input_mode(x)` to set the correct unicode method. This sets the method that is used to send the unicode, and stores it in EEPROM, so you only need to call this once.
### 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.
#### Start and Finish input functions
The functions for starting and finishing Unicode input on your platform can be overridden locally. Possible uses include customizing input mode behavior if you don't use the default keys, or adding extra visual/audio feedback to Unicode input.
*`void unicode_input_start(void)`– This sends the initial sequence that tells your platform to enter Unicode input mode. For example, it presses Ctrl+Shift+U on Linux and holds the Option key on Mac.
*`void unicode_input_finish(void)`– This is called to exit Unicode input mode, for example by pressing Space or releasing the Option key.
You can find the default implementations of these functions in [`process_unicode_common.c`](https://github.com/qmk/qmk_firmware/blob/master/quantum/process_keycode/process_unicode_common.c).
#### Input Key Configuration
Additionally, you can customize the keys used to trigger the unicode input for macOS and WinCompose by adding defines to your `config.h`
```c
#define UNICODE_OSX_KEY KC_LALT
#define UNICODE_WINC_KEY KC_RALT
```
#### Input Method Cycling
Also, you can choose which input methods are availble for cycling through. By default, this is disabled. But if you want to enabled it, then limiting it to just those modes makes sense. Note that `UNICODE_SELECTED_MODES` define is comma delimited.
caseKC_MAKE:// Compiles the firmware, and adds the flash command based on keyboard bootloader
if(!record->event.pressed){
uint8_ttemp_mod=get_mods();
uint8_ttemp_osm=get_oneshot_mods();
clear_mods();clear_oneshot_mods();
SEND_STRING("make "QMK_KEYBOARD":"QMK_KEYMAP);
#ifndef FLASH_BOOTLOADER
if((temp_mod|temp_osm)&MOD_MASK_SHIFT)
#endif
{//
#if defined(__arm__) // only run for ARM boards
SEND_STRING(":dfu-util");
#elif defined(BOOTLOADER_DFU) // only run for DFU boards
SEND_STRING(":dfu");
#elif defined(BOOTLOADER_HALFKAY) // only run for teensy boards
SEND_STRING(":teensy");
#elif defined(BOOTLOADER_CATERINA) // only run for Pro Micros
SEND_STRING(":avrdude");
#endif // bootloader options
}
if((temp_mod|temp_osm)&MOD_MASK_CTRL){
SEND_STRING(" -j8 --output-sync");
}
SEND_STRING(SS_TAP(X_ENTER));
set_mods(temp_mod);
}
break;
}
returnprocess_record_keymap(keycode,record);
}
```
For boards that may not have a shift button (such as on a macro pad), we need a way to always include the bootloader option. To do that, add the following to the `rules.mk` in your userspace folder:
```make
ifeq ($(strip $(FLASH_BOOTLOADER)), yes)
OPT_DEFS += -DFLASH_BOOTLOADER
endif
```
This will add a new `KC_MAKE` keycode that can be used in any of your keymaps. And this keycode will output `make <keyboard>:<keymap>`, making frequent compiling easier. And this will work with any keyboard and any keymap as it will output the current boards info, so that you don't have to type this out every time.
Additionally, this should flash the newly compiled firmware automatically, using the correct utility, based on the bootloader settings (or default to just generating the HEX file). However, it should be noted that this may not work on all systems. AVRDUDE doesn't work on WSL, namely (and will dump the HEX in the ".build" folder instead).
Also, holding `shift` will add the appropriate flashing command (`:dfu`, `:teensy`, `:avrdude`, `:dfu-util`) for a majority of keyboards. Holding `control` will add some commands that will speed up compiling time by processing multiple files at once.
And for the boards that lack a shift key, or that you want to always attempt the flashing part, you can add `FLASH_BOOTLOADER = yes` to the `rules.mk` of that keymap.
?> This should flash the newly compiled firmware automatically, using the correct utility, based on the bootloader settings (or default to just generating the HEX file). However, it should be noted that this may not work on all systems. AVRDUDE doesn't work on WSL, namely. And this doesn't support BootloadHID or mdloader.
Velocikey is a feature that lets you control the speed of lighting effects (like the Rainbow Swirl effect) with the speed of your typing. The faster you type, the faster the lights will go!
## Usage
For Velocikey to take effect, there are two steps. First, when compiling your keyboard, you'll need to set `VELOCIKEY_ENABLE=yes` in `rules.mk`, e.g.:
```
BOOTMAGIC_ENABLE = no
MOUSEKEY_ENABLE = no
STENO_ENABLE = no
EXTRAKEY_ENABLE = yes
VELOCIKEY_ENABLE = yes
```
Then, while using your keyboard, you need to also turn it on with the VLK_TOG keycode, which toggles the feature on and off.
The following light effects will all be controlled by Velocikey when it is enabled:
- RGB Breathing
- RGB Rainbow Mood
- RGB Rainbow Swirl
- RGB Snake
- RGB Knight
Support for LED breathing effects is planned but not available yet.
As long as Velocikey is enabled, it will control the speed regardless of any other speed setting that your RGB lights are currently on.
## Configuration
Velocikey doesn't currently support any configuration via keyboard settings. If you want to adjust something like the speed increase or decay rate, you would need to edit `velocikey.c` and adjust the values there to achieve the kinds of speeds that you like.
@@ -49,9 +49,18 @@ To generate this bootloader, use the `bootloader` target, eg `make planck/rev4:d
To generate a production-ready .hex file (containing the application and the bootloader), use the `production` target, eg `make planck/rev4:default:production`.
### DFU commands
There are a number of DFU commands that you can use to flash firmware to a DFU device:
*`:dfu` - This is the normal option and waits until a DFU device is available, and then flashes the firmware. This will check every 5 seconds, to see if a DFU device has appeared.
*`:dfu-ee` - This flashes an `eep` file instead of the normal hex. This is uncommon.
*`:dfu-split-left` - This flashes the normal firmware, just like the default option (`:dfu`). However, this also flashes the "Left Side" EEPROM file for split keyboards. _This is ideal for Elite C based split keyboards._
*`:dfu-split-right` - This flashes the normal firmware, just like the default option (`:dfu`). However, this also flashes the "Right Side" EEPROM file for split keyboards. _This is ideal for Elite C based split keyboards._
## Caterina
Arduino boards and their clones use the [Caterina bootloader](https://github.com/arduino/Arduino/tree/master/hardware/arduino/avr/bootloaders/caterina) (any keyboard built with a Pro Micro, or clone), and uses the avr109 protocol to communicate through virtual serial. Bootloaders like [A-Star](https://www.pololu.com/docs/0J61/9) are based on Caterina.
Arduino boards and their clones use the [Caterina bootloader](https://github.com/arduino/ArduinoCore-avr/tree/master/bootloaders/caterina) (any keyboard built with a Pro Micro, or clone), and uses the avr109 protocol to communicate through virtual serial. Bootloaders like [A-Star](https://www.pololu.com/docs/0J61/9) are based on Caterina.
To ensure compatibility with the Caterina bootloader, make sure this block is present your `rules.mk`:
@@ -84,6 +93,7 @@ or if you want to flash multiple boards, use the following command
When you're done flashing boards, you'll need to hit Ctrl + C or whatever the correct keystroke is for your operating system to break the loop.
## Halfkay
Halfkay is a super-slim protocol developed by PJRC that uses HID, and come on all Teensys (namely the 2.0).
@@ -131,3 +141,12 @@ Flashing sequence:
* You will receive a warning about the DFU signature; Just ignore it
4. Reset the device into application mode (may be done automatically)
* If you are building from command line (e.g. `make planck/rev6:default:dfu-util`), make sure that `:leave` is passed to the `DFU_ARGS` variable inside your `rules.mk` (e.g. `DFU_ARGS = -d 0483:df11 -a 0 -s 0x08000000:leave`) so that your device resets after flashing
### STM32 Commands
There are a number of DFU commands that you can use to flash firmware to a STM32 device:
*`:dfu-util` - The default command for flashing to STM32 devices.
*`:dfu-util-wait` - This works like the default command, but it gives you a (configurable) 10 second timeout before it attempts to flash the firmware. You can use `TIME_DELAY=20` from the command line to change the timeout.
@@ -123,24 +129,27 @@ 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](https://www.docker.com/products/docker), run the following command at the root of the QMK folder 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
# You'll run this every time you want to build a keymap
# modify the keymap and keyboard assignment to compile what you want
# defaults are ergodox/default
util/docker_build.sh keyboard:keymap
# For example: util/docker_build.sh ergodox_ez:steno
```
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`.
docker run -e keymap=gwen -e keyboard=ergodox_ez --rm -v $('pwd'):/qmk:rw edasque/qmk_firmware
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
util/docker_build.sh
# Reads parameters as input (leave blank for defaults)
```
On Windows Docker seems to have issues with the VOLUME tag in Dockerfile, and `$('pwd')` won't print a Windows compliant path; use full path instead, like this:
There is also support for building _and_ flashing the keyboard straight from Docker by specifying the `target` as well:
```bash
docker run -e keymap=default -e keyboard=ergodox_ez --rm -v D:/Users/Sacapuces/Documents/Repositories/qmk:/qmk:rw edasque/qmk_firmware
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](https://github.com/qmk/qmk_toolbox) instead.
This will compile the targeted keyboard/keymap and leave it in your QMK directory for you to flash.
!> 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**.
## Vagrant
If you have any problems building the firmware, you can try using a tool called Vagrant. It will set up a virtual computer with a known configuration that's ready-to-go for firmware building. OLKB does NOT host the files for this virtual computer. Details on how to set up Vagrant are in the [vagrant guide](getting_started_vagrant.md).
@@ -93,19 +93,17 @@ This enables MIDI sending and receiving with your keyboard. To enter MIDI send m
`UNICODE_ENABLE`
This allows you to send unicode symbols via`UC(<unicode>)` in your keymap. Only codes up to 0x7FFF are currently supported.
This allows you to send Unicode characters using`UC(<code point>)` in your keymap. Code points up to `0x7FFF` are supported. This covers characters for most modern languages, as well as symbols, but it doesn't cover emoji.
`UNICODEMAP_ENABLE`
This allows sending unicode symbols using `X(<unicode>)` in your keymap. Codes
up to 0xFFFFFFFF are supported, including emojis. You will need to maintain
a separate mapping table in your keymap file.
This allows you to send Unicode characters using `X(<map index>)` in your keymap. You will need to maintain a mapping table in your keymap file. All possible code points (up to `0x10FFFF`) are supported.
Known limitations:
- Under Mac OS, only codes up to 0xFFFF are supported.
- Under Linux ibus, only codes up to 0xFFFFF are supported (but anything important is still under this limit for now).
`UCIS_ENABLE`
Characters out of range supported by the OS will be ignored.
This allows you to send Unicode characters by inputting a mnemonic corresponding to the character you want to send. You will need to maintain a mapping table in your keymap file. All possible code points (up to `0x10FFFF`) are supported.
For further details, as well as limitations, see the [Unicode page](feature_unicode.md).
`BLUETOOTH_ENABLE`
@@ -117,7 +115,7 @@ This allows you output audio on the C6 pin (needs abstracting). See the [audio p
`FAUXCLICKY_ENABLE`
Uses buzzer to emulate clicky switches. A cheap imitation of the Cherry blue switches. By default, uses the C6 pin, same as AUDIO_ENABLE.
Uses buzzer to emulate clicky switches. A cheap imitation of the Cherry blue switches. By default, uses the C6 pin, same as `AUDIO_ENABLE`.
`VARIABLE_TRACE`
@@ -137,6 +135,18 @@ This enables [key lock](feature_key_lock.md). This consumes an additional 260 by
This enables split keyboard support (dual MCU like the let's split and bakingpy's boards) and includes all necessary files located at quantum/split_common
`SPLIT_TRANSPORT`
As there is no standard split communication driver for ARM-based split keyboards yet, `SPLIT_TRANSPORT = custom` must be used for these. It will prevent the standard split keyboard communication code (which is AVR-specific) from being included, allowing a custom implementation to be used.
`CUSTOM_MATRIX`
Lets you replace the default matrix scanning routine with your own code. You will need to provide your own implementations of matrix_init() and matrix_scan().
`DEBOUNCE_TYPE`
Lets you replace the default key debouncing routine with an alternative one. If `custom` you will need to provide your own implementation.
## Customizing Makefile Options on a Per-Keymap Basis
If your keymap directory has a file called `rules.mk` any options you set in that file will take precedence over other `rules.mk` options for your particular keyboard.
@@ -185,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
QMK has a GPIO control abstraction layer which is micro-controller agnostic. This is done to allow easy access to pin control across different platforms.
QMK has a GPIO control abstraction layer which is microcontroller agnostic. This is done to allow easy access to pin control across different platforms.
## Functions
@@ -17,7 +17,7 @@ The following functions can provide basic control of GPIOs and are found in `qua
|`writePin(pin, level)`|Set pin level, assuming it is an output |
|`readPin(pin)` |Returns the level of the pin |
## Advance settings
## Advanced Settings
Each micro-controller can have multiple advance settings regarding its GPIO. This abstraction layer does not limit the use of architecturespecific functions. Advance users should consult the datasheet of there desired device and include any needed libraries. For AVR the standard avr/io.h library is used and for STM32 the Chibios [PAL library](http://chibios.sourceforge.net/docs3/hal/group___p_a_l.html) is used.
Each microcontroller can have multiple advanced settings regarding its GPIO. This abstraction layer does not limit the use of architecture-specific functions. Advanced users should consult the datasheet of their desired device and include any needed libraries. For AVR, the standard avr/io.h library is used; for STM32, the ChibiOS [PAL library](http://chibios.sourceforge.net/docs3/hal/group___p_a_l.html) is used.
@@ -53,7 +53,7 @@ This is pretty straight-forward - we'll be connecting like-things to like-things
The only difference between the .hex files below is which pin is connected to RESET. You can use them on other boards as well, as long as you're aware of the pins being used. If for some reason neither of these pins are available, [create an issue](https://github.com/qmk/qmk_firmware/issues/new), and we can generate one for you!
If you're not sure what your board uses, look in the `rules.mk` file for the keyboard in QMK. The `MCU =` line will have the value you need. It may differ between different versions of the board.
@@ -113,6 +114,10 @@ Since our keyboard uses an `atmega32u4` (common), that is the chip we'll specify
|`MO(layer)` |Momentarily turn on `layer` when pressed (requires `KC_TRNS` on destination layer)|
|`OSL(layer)` |Momentarily activates `layer`until a key is pressed. See [One Shot Keys](https://docs.qmk.fm/#/feature_advanced_keycodes?id=one-shot-keys) for details. |
|`LM(layer, mod)`|Momentarily turn on `layer` (like MO) with `mod` active as well. Where `mod` is a mods_bit. Mods can be viewed [here](https://docs.qmk.fm/#/feature_advanced_keycodes?id=mod-tap). Example Implementation: `LM(LAYER_1, MOD_LALT)`|
|`LT(layer, kc)` |Turn on `layer` when held, `kc` when tapped |
|`TG(layer)`|Toggle `layer` on or off |
|`TO(layer)`|Turn on `layer` when pressed |
|`TT(layer)` |Normally acts like MO unless it's tapped multiple times, which toggles `layer` on |
## [Mouse Keys](feature_mouse_keys.md)
@@ -321,43 +319,43 @@ This is a reference only. Each group of keys links to the page documenting their
|`LCTL_T(kc)`|`CTL_T(kc)` |Left Control when held, `kc` when tapped |
|`RCTL_T(kc)`| |Right Control when held, `kc` when tapped |
|`LSFT_T(kc)`|`SFT_T(kc)` |Left Shift when held, `kc` when tapped |
|`RSFT_T(kc)`| |Right Shift when held, `kc` when tapped |
|`LALT_T(kc)`|`ALT_T(kc)`|Left Alt when held, `kc` when tapped |
|`RALT_T(kc)`|`ALGR_T(kc)` |Right Alt when held, `kc` when tapped |
|`LGUI_T(kc)`|`LCMD_T(kc)`, `RWIN_T(kc)`, `GUI_T(kc)`|Left GUI when held, `kc` when tapped |
|`RGUI_T(kc)`|`RCMD_T(kc)`, `RWIN_T(kc)` |Right GUI when held, `kc` when tapped |
|`C_S_T(kc)` | |Left Control and Shift when held, `kc` when tapped |
|`MEH_T(kc)` | |Left Control, Shift and Alt when held, `kc` when tapped|
|`LCAG_T(kc)`| |Left Control, Alt and GUI when held, `kc` when tapped |
|`RCAG_T(kc)`| |Right Control, Alt and GUI when held, `kc` when tapped |
|`ALL_T(kc)` | |Left Control, Shift, Alt and GUI when held, `kc` when tapped - more info [here](http://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/)|
|`SGUI_T(kc)`|`SCMD_T(kc)`, `SWIN_T(kc)` |Left Shift and GUI when held, `kc` when tapped|
|`LCA_T(kc)` | |Left Control and Alt when held, `kc` when tapped |
|`LCTL_T(kc)`|`CTL_T(kc)`|Left Control when held, `kc` when tapped |
|`LSFT_T(kc)`|`SFT_T(kc)` |Left Shift when held, `kc` when tapped |
|`LALT_T(kc)`|`ALT_T(kc)`|Left Alt when held, `kc` when tapped |
|`LGUI_T(kc)`|`LCMD_T(kc)`, `LWIN_T(kc)`, `GUI_T(kc)`, `CMD_T(kc)`, `WIN_T(kc)`|Left GUI when held, `kc` when tapped |
|`RCTL_T(kc)`| |Right Control when held, `kc` when tapped |
|`RSFT_T(kc)`||Right Shift when held, `kc` when tapped |
|`RALT_T(kc)`|`ALGR_T(kc)` |Right Alt when held, `kc` when tapped |
|`RGUI_T(kc)`|`RCMD_T(kc)`, `RWIN_T(kc)` |Right GUI when held, `kc` when tapped |
|`SGUI_T(kc)`|`SCMD_T(kc)`, `SWIN_T(kc)` |Left Shift and GUI when held, `kc` when tapped |
|`LCA_T(kc)` | |Left Control and Alt when held, `kc` when tapped|
|`LCAG_T(kc)`| |Left Control, Alt and GUI when held, `kc` when tapped |
|`RCAG_T(kc)`| |Right Control, Alt and GUI when held, `kc` when tapped |
|`C_S_T(kc)` | |Left Control and Shift when held, `kc` when tapped |
|`MEH_T(kc)` | |Left Control, Shift and Alt when held, `kc` when tapped|
|`HYPR_T(kc)`|`ALL_T(kc)` |Left Control, Shift, Alt and GUI when held, `kc` when tapped - more info [here](http://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/)|
## [RGB Lighting](feature_rgblight.md)
@@ -431,18 +429,6 @@ This is a reference only. Each group of keys links to the page documenting their
QMK keymaps are defined inside a C source file. The data structure is an array of arrays. The outer array is a list of layer arrays while the inner layer array is a list of keys. Most keyboards define a `KEYMAP()` macro to help you create this array of arrays.
QMK keymaps are defined inside a C source file. The data structure is an array of arrays. The outer array is a list of layer arrays while the inner layer array is a list of keys. Most keyboards define a `LAYOUT()` macro to help you create this array of arrays.
## Keymap and Layers
@@ -119,7 +119,7 @@ The main part of this file is the `keymaps[]` definition. This is where you list
> This `fn_actions[]` interface is mostly for backward compatibility. In QMK, you don't need to use `fn_actions[]`. You can directly use `ACTION_FUNCTION(N)` or any other action code value itself normally generated by the macro in `keymaps[][MATRIX_ROWS][MATRIX_COLS]`. N in `F(N)` can only be 0 to 31. Use of the action code directly in `keymaps` unlocks this limitation.
@@ -6,13 +6,18 @@ Not sure if your keyboard can run QMK? If it's a mechanical keyboard you built y
## Overview
There are 5 main sections to this guide:
There are 7 main sections to this guide:
* [Getting Started](newbs_getting_started.md)
* [Building Your First Firmware](newbs_building_firmware.md)
* [Building Your First Firmware using the command line](newbs_building_firmware.md)
* [Building Your First Firmware using the online GUI](newbs_building_firmware_configurator.md)
* [Flashing Firmware](newbs_flashing.md)
* [Testing and Debugging](newbs_testing_debugging.md)
* [Best Practices](newbs_best_practices.md)
* [Git Best Practices](newbs_best_practices.md)
* [Learn More with these Resources](newbs_learn_more_resources.md)
This guide is focused on helping someone who has never compiled software before. It makes choices and recommendations based on that viewpoint. There are alternative methods for many of these procedures, and we support most of those alternatives. If you have any doubt about how to accomplish a task you can [ask us for guidance](getting_started_getting_help.md).
## Additional Resources
* [Thomas Baart's QMK Basics Blog](https://thomasbaart.nl/category/mechanical-keyboards/firmware/qmk/qmk-basics/) – A user-created blog covering the basics of how to use QMK Firmware, as seen from a new user's perspective.
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:
If a board currently supported in QMK uses a Pro Micro (or compatible board) and you want to use the Proton C, you can generate the firmware by appending `CONVERT_TO_PROTON_C=yes` (or `CTPC=yes`) to your make argument, like this:
make 40percentclub/mf68:default CTPC=yes
You can add the same argument to your keymap's `rules.mk`, which will accomplish the same thing.
This exposes the `CONVERT_TO_PROTON_C` flag that you can use in your code with `#ifdef`s, like this:
#ifdef CONVERT_TO_PROTON_C
// Proton C code
#else
// Pro Micro code
#endif
Before being able to compile, you may get some errors about `PORTB/DDRB`, etc not being defined, so you'll need to convert the keyboard's code to use the [GPIO Controls](internals_gpio_control.md) that will work for both ARM and AVR. This shouldn't affect the AVR builds at all.
The Proton C only has one on-board LED (C13), and by default, the TXLED (D5) is mapped to it. If you want the RXLED (B0) mapped to it instead, add this like to your `config.h`:
This file is used by the [QMK API](https://github.com/qmk/qmk_api). It contains the information [QMK Configurator](https://config.qmk.fm/) needs to display a representation of your keyboard. You can also set metadata here.
You can create `info.json` files at every level under `qmk_firmware/keyboards/<name>` to specify this metadata. These files are combined, with more specific files overriding keys in less specific files. This means you do not need to duplicate your metadata information. For example, `qmk_firmware/keyboards/clueboard/info.json` specifies `manufacturer` and `maintainer`, while `qmk_firmware/keyboards/clueboard/66/info.json` specifies more specific information about Clueboard 66%.
## `info.json` Format
The `info.json` file is a JSON formatted dictionary with the following keys available to be set. You do not have to set all of them, merely the keys that apply to your keyboard.
*`keyboard_name`
* A free-form text string describing the keyboard.
* Example: `Clueboard 66%`
*`url`
* A URL to the keyboard's product page, [QMK.fm/keyboards](https://qmk.fm/keyboards) page, or other page describing information about the keyboard.
*`maintainer`
* GitHub username of the maintainer, or `qmk` for community maintained boards
*`width`
* Width of the board in Key Units
*`height`
* Height of the board in Key Units
*`layouts`
* Physical Layout representations. See the next section for more detail.
### Layout Format
Within our `info.json` file the `layouts` portion of the dictionary contains several nested dictionaries. The outer layer consists of QMK layout macros, for example `LAYOUT_ansi` or `LAYOUT_iso`. Within each layout macro are keys for `width`, `height`, and `key_count`, each of which should be self-explanatory.
*`width`
* Optional: The width of the layout in Key Units
*`height`
* Optional: The height of the layout in Key Units
*`key_count`
* **Required**: The number of keys in this layout
*`layout`
* A list of Key Dictionaries describing the physical layout. See the next section for more details.
### Key Dictionary Format
Each Key Dictionary in a layout describes the physical properties of a key. If you are familiar with the Raw Code for <http://keyboard-layout-editor.com> you will find many of the concepts the same. We re-use the same key names and layout choices wherever possible, but unlike keyboard-layout-editor each key is stateless, inheriting no properties from the keys that came before it.
All key positions and rotations are specified in relation to the top-left corner of the keyboard, and the top-left corner of each key.
*`x`
* **Required**: The absolute position of the key in the horizontal axis, in Key Units.
*`y`
* **Required**: The absolute position of the key in the vertical axis, in Key Units.
*`w`
* The width of the key, in Key Units. Ignored if `ks` is provided. Default: `1`
*`h`
* The height of the key, in Key Units. Ignored if `ks` is provided. Default: `1`
*`r`
* How many degrees clockwise to rotate the key.
*`rx`
* The absolute position of the point to rotate the key around in the horizontal axis. Default: `x`
*`ry`
* The absolute position of the point to rotate the key around in the vertical axis. Default: `y`
*`ks`
* Key Shape: define a polygon by providing a list of points, in Key Units.
* **Important**: These are relative to the top-left of the key, not absolute.
* Example ISO Enter: `[ [0,0], [1.5,0], [1.5,2], [0.25,2], [0.25,1], [0,1], [0,0] ]`
*`label`
* What to name this position in the matrix.
* This should usually be the same name as what is silkscreened on the PCB at this location.
## How is the Metadata Exposed?
This metadata is primarily used in two ways:
* To allow web-based configurators to dynamically generate UI
* To support the new `make keyboard:keymap:qmk` target, which bundles this metadata up with the firmware to allow QMK Toolbox to be smarter.
Configurator authors can see the [QMK Compiler](https://docs.api.qmk.fm/using-the-api) docs for more information on using the JSON API.
If you need help with something, the best place to get quick support is going to be on our [Discord Server](https://discord.gg/Uq7gcHh). There is usually somebody online, and there are a bunch of very helpful people there.
Don't forget to read our [Code of Conduct](https://qmk.fm/coc/).
## Help! I don't know where to start!
If this is the case, then you should start with our [Newbs Guide](https://docs.qmk.fm/#/newbs). There is a lot of great info there, and that should cover everything you need to get started.
If that's an issue, hop onto the [QMK Configurator](https://config.qmk.fm), as that will handle a majority of what you need there.
## Help! I'm having issues flashing!
First, head to the [Compiling/Flashing FAQ Page](https://docs.qmk.fm/#/faq_build). There is a good deal of info there, and you'll find a bunch of solutions to common issues there.
## Help, I have an issue that isn't covered by the links above
Okay, that's fine. Then please check the [open issues in our GitHub](https://github.com/qmk/qmk_firmware/issues) to see if somebody is experiencing the same thing (make sure it's not just similar, but actually the same).
If you can't find anything, then please open a [new issue](https://github.com/qmk/qmk_firmware/issues/new)!
## What if I found a bug?
Then please open an [issue](https://github.com/qmk/qmk_firmware/issues/new), and if you know how to fix it, open up a Pull Request on GitHub with the fix.
## But `git` and `GitHub` are intimidating!
Don't worry, we have some pretty nice [Guidelines](https://docs.qmk.fm/#/newbs_best_practices) on how to start using `git` and GitHub to make things easier to develop.
Additionally, you can find additional `git` and GitHub related links [here](https://docs.qmk.fm/#/newbs_learn_more_resources).
## I have a Keyboard that I want to add support for
Awesome! Open up a Pull Request for it. We'll review the code, and merge it!
### What if I want to do brand it with `QMK`?
That's amazing! We would love to assist you with that!
In fact, we have a [whole page](https://qmk.fm/powered/) dedicated to adding QMK Branding to your page and keyboard. This covers pretty much everything you need (knowledge and images) to officially support QMK.
If you have any questions about this, open an issue or head to [Discord](https://discord.gg/Uq7gcHh).
@@ -12,7 +12,7 @@ You can think of QMK as no different from any other computer program. It is star
The reason for this is the different platforms that QMK supports. The most common platform is `lufa`, which runs on AVR processors such at the atmega32u4. We also support `chibios` and `vusb`.
We'll focus on AVR processors for the moment, which use the `lufa` platform. You can find the `main()` function in [tmk_core/protocol/lufa/lufa.c](https://github.com/qmk/qmk_firmware/blob/661ca4440cc42f3b60697e98985c44b0571ccfc1/tmk_core/protocol/lufa/lufa.c#L1019). If you browse through that function you'll find that it initializes any hardware that has been configured (including USB to the host) and then it starts the core part of the program with a [`while(1)`](https://github.com/qmk/qmk_firmware/blob/661ca4440cc42f3b60697e98985c44b0571ccfc1/tmk_core/protocol/lufa/lufa.c#L1060). This is [The Main Loop](#the-main-loop).
We'll focus on AVR processors for the moment, which use the `lufa` platform. You can find the `main()` function in [tmk_core/protocol/lufa/lufa.c](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/tmk_core/protocol/lufa/lufa.c#L1028). If you browse through that function you'll find that it initializes any hardware that has been configured (including USB to the host) and then it starts the core part of the program with a [`while(1)`](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/tmk_core/protocol/lufa/lufa.c#L1069). This is [The Main Loop](#the-main-loop).
## The Main Loop
@@ -22,7 +22,7 @@ This section of code is called "The Main Loop" because it's responsible for loop
keyboard_task();
```
This is where all the keyboard specific functionality is dispatched. The source code for `keyboard_task()` can be found in [tmk_core/common/keyboard.c](https://github.com/qmk/qmk_firmware/blob/661ca4440cc42f3b60697e98985c44b0571ccfc1/tmk_core/common/keyboard.c#L206), and it is responsible for detecting changes in the matrix and turning status LED's on and off.
This is where all the keyboard specific functionality is dispatched. The source code for `keyboard_task()` can be found in [tmk_core/common/keyboard.c](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/tmk_core/common/keyboard.c#L216), and it is responsible for detecting changes in the matrix and turning status LED's on and off.
Within `keyboard_task()` you'll find code to handle:
@@ -57,10 +57,10 @@ Matrix Scanning runs many times per second. The exact rate varies but typically
Once we know the state of every switch on our keyboard we have to map that to a keycode. In QMK this is done by making use of C macros to allow us to separate the definition of the physical layout from the definition of keycodes.
At the keyboard level we define a C macro (typically named `KEYMAP()`) which maps our keyboard's matrix to physical keys. Sometimes the matrix does not have a switch in every location, and we can use this macro to pre-populate those with KC_NO, making the keymap definition easier to work with. Here's an example `KEYMAP()` macro for a numpad:
At the keyboard level we define a C macro (typically named `LAYOUT()`) which maps our keyboard's matrix to physical keys. Sometimes the matrix does not have a switch in every location, and we can use this macro to pre-populate those with KC_NO, making the keymap definition easier to work with. Here's an example `LAYOUT()` macro for a numpad:
```c
#define KEYMAP( \
#define LAYOUT( \
k00, k01, k02, k03, \
k10, k11, k12, k13, \
k20, k21, k22, \
@@ -75,17 +75,17 @@ At the keyboard level we define a C macro (typically named `KEYMAP()`) which map
}
```
Notice how the second block of our `KEYMAP()` macro matches the Matrix Scanning array above? This macro is what will map the matrix scanning array to keycodes. However, if you look at a 17 key numpad you'll notice that it has 3 places where the matrix could have a switch but doesn't, due to larger keys. We have populated those spaces with `KC_NO` so that our keymap definition doesn't have to.
Notice how the second block of our `LAYOUT()` macro matches the Matrix Scanning array above? This macro is what will map the matrix scanning array to keycodes. However, if you look at a 17 key numpad you'll notice that it has 3 places where the matrix could have a switch but doesn't, due to larger keys. We have populated those spaces with `KC_NO` so that our keymap definition doesn't have to.
You can also use this macro to handle unusual matrix layouts, for example the [Clueboard rev 2](https://github.com/qmk/qmk_firmware/blob/661ca4440cc42f3b60697e98985c44b0571ccfc1/keyboards/clueboard/66/rev2/rev2.h). Explaining that is outside the scope of this document.
You can also use this macro to handle unusual matrix layouts, for example the [Clueboard rev 2](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/keyboards/clueboard/66/rev2/rev2.h). Explaining that is outside the scope of this document.
##### Keycode Assignment
At the keymap level we make use of our `KEYMAP()` macro above to map keycodes to physical locations to matrix locations. It looks like this:
At the keymap level we make use of our `LAYOUT()` macro above to map keycodes to physical locations to matrix locations. It looks like this:
Notice how all of these arguments match up with the first half of the `KEYMAP()` macro from the last section? This is how we take a keycode and map it to our Matrix Scan from earlier.
Notice how all of these arguments match up with the first half of the `LAYOUT()` macro from the last section? This is how we take a keycode and map it to our Matrix Scan from earlier.
##### State Change Detection
@@ -130,31 +130,35 @@ Comparing against our keymap we can see that the pressed key is KC_NLCK. From he
##### Process Record
The `process_record()` function itself is deceptively simple, but hidden within is a gateway to overriding functionality at various levels of QMK. The chain of events is listed below, using cluecard whenever we need to look at the keyboard/keymap level functions. Depending on options set in rule.mk or elsewhere, only a subset of the functions below will be included in final firmware.
The `process_record()` function itself is deceptively simple, but hidden within is a gateway to overriding functionality at various levels of QMK. The chain of events is listed below, using cluecard whenever we need to look at the keyboard/keymap level functions. Depending on options set in `rules.mk` or elsewhere, only a subset of the functions below will be included in final firmware.
* [Identify and process quantum specific keycodes](https://github.com/qmk/qmk_firmware/blob/661ca4440cc42f3b60697e98985c44b0571ccfc1/quantum/quantum.c#L287)
* [Identify and process Quantum-specific keycodes](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/quantum/quantum.c#L291)
At any step during this chain of events a function (such as `process_record_kb()`) can `return false` to halt all further processing.
@@ -221,4 +216,3 @@ along with this program. If not, see <http://www.gnu.org/licenses/>.
#define LCD_E_PIN 1 //< pin for Enable line
#endif
*/
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.