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
* add initial support for hadron ver3
* add initial support for hadron ver3
* pull qwiic support for micro_led to be modified for use in hadron's 64x24 ssd1306 oled display
* initial work on OLED using qwiic driver
* early work to get 128x32 oled working by redefining qwiic micro oled parameters. Currently working, but would affect qwiic's micro oled functionality
* moved oled defines to config.h and added ifndef to micro_oled driver
* WORKING :D - note, still work in progress to get the start location correct on the 128x32 display.
* added equation to automatically calculate display offset based on screen width
* adding time-out timer to oled display
* changed read lock staus via read_led_state
* lock indications fixes
* Added scroll lock indication to oled
* add support for DRV2605 haptic driver
* Improve readabiity of DRV2605 driver.
-added typedef for waveform library
-added unions for registers
* Update keyboards/hadron/ver2/keymaps/default/config.h
Co-Authored-By: ishtob <ishtob@gmail.com>
* Update keyboards/hadron/ver2/keymaps/default/config.h
Co-Authored-By: ishtob <ishtob@gmail.com>
* Update keyboards/hadron/ver2/keymaps/default/config.h
Co-Authored-By: ishtob <ishtob@gmail.com>
* Update keyboards/hadron/ver2/keymaps/default/config.h
Co-Authored-By: ishtob <ishtob@gmail.com>
* Fixes for PR
* PR fixes
* fix old persistent layer function to use new set_single_persistent_default_layer
* fix issues with changing makefile defines that broken per-key haptic pulse
* Comment fixes
* Add definable parameter and auto-calibration based on motor choice
* 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
* add zh-cn readme
* edit readme
* Round 1 of edits
- Mandarin translation of QMK products is off, best to use the English name.
- Fix some terminology and grammar.
* trying re-translating the first paragraph
* add fallback langurages
* Create LANGS.md
* Rename docs/zh-cn/README.md to docs/zh/README.md
* Update LANGS.md
* Update index.html
* Delete README.md
* add sidebar for zh
* add zh-cn readme
* edit readme
* Round 1 of edits
- Mandarin translation of QMK products is off, best to use the English name.
- Fix some terminology and grammar.
* trying re-translating the first paragraph
* add fallback langurages
* Create LANGS.md
* Rename docs/zh-cn/README.md to docs/zh/README.md
* Update LANGS.md
* Update index.html
* handwired/atreus50: refactor
- layout macro renames:
- KEYMAP is now LAYOUT
- COMPACT_KEYMAP is now LAYOUT_kc
- keymap updates:
- both keymaps now use #include QMK_KEYBOARD_H
- removed redundant KC_TRNS and KC_NO definitions
- default keymap now uses LAYOUT macro instead of LAYOUT_kc
* handwired/atreus50: readme cleanup
Reformatted the readme to be more closely aligned to current QMK
template, and fixed some typos/grammar.
* handwired/atreus50: Configurator support
* add 60_hhkb support
* add qmk configurator support for the new 60_hhkb layout
* allow community layout support for the 60_hhkb
* fixup readme to adhere to new QMK standards
* handwired/promethium: refactor
- config.h files
- updated to use #pragma once
- removed redundant config.h includes
- layout macro moved from config.h to promethium.h
- layout macro renamed from KEYMAP_CUSTOM to LAYOUT
* handwired/promethium: Configurator support
* Add support for S7 Elephant
A high-end 70% custom keyboard designed and produced by jacky from Geekhack.
* Polish S7 Elephant code
Implement drashna's suggestions:
- specify bootloader
- remove unnecessary defines
- use led_set_user() for LED logic
* Correct info.json and s7_elephant.h
Correct info.json and s7_elepant.h to follow QMK convention and fix a
missing curly bracket.
* Add a layout to support tsangan bottom row with split bs and rshift
* Move the new layout to defaults
* Rename layout to be more accurately representative
* Rename files to match renamed layout def
* Refactored M6-B to use Zeal60 RGB backlight code
* Fixed M6-B LED co-ordinates
* Minor changes to RGB config for Zeal65
* Added dynamic keymaps to WT80-A, WT60-A, WT-80A, U80-A
* Macro implementation
* Implemented macros, API protocol version 8, RGB backlight fixes
* Improved radial effects for M6-B
* Fixed undefined references when building an RGB keyboard after M6-A
* add zh-cn readme
* edit readme
* Round 1 of edits
- Mandarin translation of QMK products is off, best to use the English name.
- Fix some terminology and grammar.
* trying re-translating the first paragraph
* handwired/arrow_pad: layout macro and keymap refactor
- Layout macros moved from the keymaps to arrow_pad.h.
- LAYOUT_pad21 refactored to only accept keys that are physical present (no KC_NO entries required in keymap)
- Keymaps now use #include QMK_KEYBOARD_H
- Keymaps refactored to use process_record_user function (from action_get_macro)
* handwired/arrow_pad: Readme cleanup
Fixed the make commands and updated the layout macro.
* handwired/arrow_pad: Configurator support
* Fix reversed bool check in layer_state_set
* Add Quefrency 65 for a friend
* Add Ergodox EZ Glow keymap
* Add RGB Matrix Code
* Further changes to rgb matrix ErgoDox EZ
* Update bjohnson keymaps
* Fix CRKBD display
* Overhaul to corne keyboard
* Narrow scope for keylogger
* Minor layout tweaks to Corne Keyboard
* additional CRKBD tweaks
* Minor tweaks to CRKBD
* Add all characters for keylogger
* Ergodox EZ Glow overhaul
* Fix Ergodox EZ Glow layer colors
* Increase Tapping Term for Corne Keyboard
* Fix unicode-ish
* Revert some changes
* Add layer specific lighting effects
* Some minor tweaks to ergodox glow config
* revert changes to ergodox files
* Update Glow readme
* Add more tapping term defines
* Fix changes
* Fix ergodox keymap
* Hopefully fix sleeping
* Disable layer indications if rgb matrix is disabled
* Add support for sleeping and rgb layer change toggle to ergodox ez glow
* Make RGB Layer Indication Great Again
* Make Unicode Great Again
* Remove placeholder define
Co-Authored-By: drashna <drashna@live.com>
* Remove placeholder define
Co-Authored-By: drashna <drashna@live.com>
* Remove old EEPROM Reset keycode
* Enable ortho_4x12 community layouts for lets_split_eh
* Keymap build fixes now that ortho_4x12 is enabled
* Keymap build fixes now that ortho_4x12 is enabled
* compiles but is not working
* still testing 5291
* compiles but is not working
* still testing 5291
* fixed a but in the layout (reversed key order in row)
* compiles but is not working
* still testing 5291
* fixed a but in the layout (reversed key order in row)
* fixed some issues
* doumentation needed
* doumentation needed
* documentation needed
* documentation needed
* Update readme.md
documentation
* Update readme.md
i dislike markdown <_>
* merge preperation
* Enable 4x4 and 5x5 community keymap support
* Pull 4x4 community keymap fixes from @noroadsleft
* Build fixes for guidoism keymap - move keymap to layouts/community/planck_mit as it uses the LAYOUT_planck_mit macro
* remove clmk and dvrk and backlight; switch esc and enter to be modtap; add meh key
* change songs
* space cadet; move enter; move '"; move pgup pgdn
* remove extra songs
* update from noahfredrick keymap
* make it easier to type ../../thing/*/*
* move pipe
* requested changes
* add interrobang support
* add shift-insert to raise-v and lower-v, move pipe to raise-/lower-n
* Adding my new keymap, based of xd75, with leds enabled via the rules.mk file
* cleaned up the rules file
* Per Change Requests: removed deprecated functions along with updated the map to use the layout macro instead of raw matrix
This is the final version of my layout.
Overall changes
===============
* Updated to work with QMK master.
Miscellaneous
=============
* The `😂` symbol can be entered with UCIS.
* `LEAD r` now inputs `Right Alt`.
Signed-off-by: Gergely Nagy <me@gergo.csillger.hu>
* Fix firmware to work with latest Wilba changes (i.e. dynamic keymap) and M60a.
* Get back RGB Backlight codes.
* More tweaks.
* Update users/talljoe/rules.mk
Co-Authored-By: Talljoe <jwasson+github@gmail.com>
* Include both base keyboards
* Merge the keymap
* Merge the configs
* Add wiring diagram for clarity of documentation
* Merge rules
* Merge keyboard sources
* Change names to compile
* Update documentation to suit
* Add qwerty layout to 108keyTrackpoint
* Separate the dvorak standard layout from a media focused one
* Update documentation to reflect new keymaps
* [style] Add empty lines at ends of files
* [style] Meet current QMK style guide
* Bring READEME closer to the QMK template
* [style] Change all "108keyTrackpoint" to "108key_trackpoint"
* [style] Use "LAYOUT" instead of "KEYMAP"
QMK terminology has changed
Co-Authored-By: mkem114 <20897849+mkem114@users.noreply.github.com>
* Add two spaces after maintainer in README
This is required to render properly
Co-Authored-By: mkem114 <20897849+mkem114@users.noreply.github.com>
* Remove redundant line
"PREVENT_STUCK_MODIFIERS" is default on for QMK
Co-Authored-By: mkem114 <20897849+mkem114@users.noreply.github.com>
* Change include of keymaps to use QMK_KEYBOARD_H
This includes automatically
* Update make rules to match template
* Change from KC_MENU to KC_APP
The button functionality actually wanted is the context menu key
* [style] Change "dvorakMedia" to "dvorak_media"
* Update README to reflect minor changes
The debounce filtering reports a key/switch change directly, without any extra delay. After that the debounce logic will filter all further changes, until the key/switch reports the same state for the given count of scans.
So a perfect switch will get a short debounce period and a bad key will get a much longer debounce period. The result is an adaptive debouncing period for each switch.
This value defines how often the same key/switch state has to be detected in successive reads until the next key state can be reported.
In other words this value defines the minimum debouncing period for a switch.
* fix formatting of keymap
* update readme with boards I currently own
* made the wrong assumption that every board would use the same space for backspace
* update readme with boards I currently own
* Allows disabling animations in user space
* Describe disabling effects in the docs
* Allows disabling individual reactive modes
* Adds the list ode defines
* Add TKL JIS layout for Pegasus Hoof
Tested with a JIS Majestouch 2 TKL
* Add default_jis keymap for Pegasus Hoof
* Remove unnecessary keycode definition
* Remove legacy fn_actions in favor of MO(1)
* Remove unnecessary build directive
* fix to prime o keymap
* changed ortho keymaps
* added some symbols to lower layer
* set lower to be a higher layer than raise
* added split layout option with center numpad to prime_o keymap
* added some gaming functionality
* added alt f4 ortho keymaps and userspace
* fixed small error
* 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
* Move 68keys keymap to mf68 folder
* Remove 68keys keyboard now its been migrated to mf68 keymap
* Migrate 68keys build config to mf68 keymap overrides
* Unify multiple HID interfaces into one
This reduces the number of USB endpoints required, which frees them up
for other things.
NKRO and EXTRAKEY always use the shared endpoint.
By default, MOUSEKEY also uses it. This means it won't work as a Boot
Procotol mouse in some BIOSes, etc. If you really think your
keyboard needs to work as a mouse in your BIOS, set
MOUSE_SHARED_EP = no in your rules.mk.
By default, the core keyboard does not use the shared endpoint, as not
all BIOSes are standards compliant and that's one place you don't want
to find out your keyboard doesn't work.. If you are really confident,
you can set KEYBOARD_SHARED_EP = yes to use the shared endpoint here
too.
* unify endpoints: ChibiOS protocol implementation
* fixup: missing #ifdef EXTRAKEY_ENABLEs
broke build on AVR with EXTRAKEY disabled
* endpoints: restore error when too many endpoints required
* lufa: wait up to 10ms to send keyboard input
This avoids packets being dropped when two reports are sent in quick
succession (eg. releasing a dual role key).
* endpoints: fix compile on ARM_ATSAM
* endpoint: ARM_ATSAM fixes
No longer use wrong or unexpected endpoint IDs
* endpoints: accommodate VUSB protocol
V-USB has its own, understandably simple ideas about the report formats.
It already blasts the mouse and extrakeys through one endpoint with
report IDs. We just stay out of its way.
* endpoints: document new endpoint configuration options
* endpoints: respect keyboard_report->mods in NKRO
The caller(s) of host_keyboard_send expect to be able to just drop
modifiers in the mods field and not worry about whether NKRO is in use.
This is a good thing. So we just shift it over if needs be.
* endpoints: report.c: update for new keyboard_report format
* Docs: Configurator Support
* Minor updates
* Updated keyboard.h example to use #pragma once
per @drashna
https://github.com/qmk/qmk_firmware/pull/4396#discussion_r232140934
* Add link to doc under Reference section
Added to _sidebar.md and _summary.md
* Changed doc title; minor tweaks
Re-titled the doc as "Supporting Your Keyboard in QMK Configurator".
Made some minor changes to the keyboard.h examples.
* Added tags object to JSON example
* add functions to set specific backlight state
* add function to query backlight state
* update documentation with new backlight functions
* Update tmk_core/common/backlight.c
Co-Authored-By: codyd51 <phillip.ennen@gmail.com>
* Update tmk_core/common/backlight.h
Co-Authored-By: codyd51 <phillip.ennen@gmail.com>
* update docs for is_backlight_enabled() name change
* Add 412-64 keyboard firmware
It's pretty barebones for now, but the Model 00 is also a pretty barebones machine. Model 01 won't be better, but plenty of pins exist for things like LEDs on Model 02.
* MANU/PROD ID changes.
Changed around the MANUFACTURER and PRODUCT IDs to be more polite when viewed in qmk toolbox.
* Fixing PROD again.
For the love of all that is good and holy, that was ugly. This new one looks better. This stuff matters to me for some reason.
* Yep, updating MANU again.
There we go. That's better - From my name to my "design firm".
* Update keyboards/412_64/keymaps/default/keymap.c
Co-Authored-By: FateEverywhere <41215461+FateEverywhere@users.noreply.github.com>
* Update keyboards/412_64/rules.mk
Co-Authored-By: FateEverywhere <41215461+FateEverywhere@users.noreply.github.com>
* Update keyboards/412_64/rules.mk
Co-Authored-By: FateEverywhere <41215461+FateEverywhere@users.noreply.github.com>
* Update keyboards/412_64/rules.mk
Co-Authored-By: FateEverywhere <41215461+FateEverywhere@users.noreply.github.com>
* Update keyboards/412_64/rules.mk
Co-Authored-By: FateEverywhere <41215461+FateEverywhere@users.noreply.github.com>
* Refactored M6-B to use Zeal60 RGB backlight code
* Fixed M6-B LED co-ordinates
* Minor changes to RGB config for Zeal65
* Added dynamic keymaps to WT80-A, WT60-A, WT-80A, U80-A
* initial commit for kbd67 keyboard
* add in a standard matrix
* get the correct matrix for layout_all
* add a layout_65_ansi LAYOUT macro
* get a default keymap in
* add caps lock led support
* fix formatting of my name in the comments
* add QMK Configurator support
* turn on bootmagic
* Starting point for blue pill based practice60
* Changes
* add
* try raw bin no botloader
* swap back to bootloader version
* edit
* Remove debug LED flash
* Disable JTAG to open up B3 and B4
* Add led backlight support (no breathing yet)
* Update matrix for correctness
* RGB Underglow working in a very simple state
* not as bright
* Move to handwired
* revert ChibiOS_Test changes
* Changes based on PR comments
* Address PR comments v2
* Move files
* Fix up screen off timer of helix
* Fix Up ScreenOffInterval exceeded uint16_t
* Fix Up never waking up once screen off if in case of matrix are not dirty
* Changing referenIng incorrect constant name
* OLED_ENABLED => SSD1306OLED
* Improve internal processing of process_record_kb()
* Use the return value of process_record_gfx()
* Move a include statement into #ifdef block
Move #include "ssd1306.h` statement into #ifdef block
* Move process_record_kbI()
Move process_record_kb() from helix.c to rev1.c/rev2.c/pico.c
* Move process_record_kb()
* fix about screen off timer
* Fix Up ScreenOffInterval exceeded uint16_t
* Fix Up never waking up once screen off if in case of matrix are not dirty.
* Revert "fix about screen off timer"
This reverts commit 3d175f2340.
* Fix up screen off timer of crkbd
* Fix Up ScreenOffInterval exceeded uint16_t
* Fix Up never waking up once screen off if in case of matrix are not dirty.
* Fix up screen off timer of helix
* Fix Up ScreenOffInterval exceeded uint16_t
* Fix Up never waking up once screen off if in case of matrix are not dirty
* Revert "Fix up screen off timer of helix"
This reverts commit f0efb82443.
* Improve internal processing of process_record_kb()
* Use the return value of process_record_gfx()
* Fix a indent
Fix a indent
* Remove unnecessary re-definitions for XXXXXXX and _______
* Update 6lit to use KC_NO in layout macros
* Update rules.mk to follow current template
* Remove use of deprecated function action_get_macro - unused and contents were from old template
* Remove use of deprecated function action_get_macro - all code was commented out
* Remove use of deprecated function action_get_macro - convert macro to use process_record_user
* Convert keymap to consistent use of _______
* fix use of old style header guards
* Swap KC_NO for XXXXXXX macro since the swap to the macro for KC_TRANS
* Resolve use of ?= in rules.mk files
* Remove duplication of rules.mk and config.h in gherkin mjt keymap
* Remove unnecessary #includes
* Align layout macros so foobar can use gherkin keymaps
* Align 6lit layout macros with foobar
* Remove ifndef QUANTUM_DIR from keymaps
* Initial 25 port
* Initial 25 port - fix info.json and hand_swap_config
* Review comments - fix layout macros, copyright comments, and duplicated use of layering macros
* Add support for slackware distribution (linux_install.sh)
The required packages are not provided by the official repository. The packages
need to be installed from slackbuilds.org either manually or with the help of
third party tools like sbotools.
* Modify linux_install.sh according to code review
Modifies the Slackware section of the linux_install.sh script based on the
suggestions from the code review.
* Modify utils/linux_install.sh according to suggestions
* Improve new_project script
- use git user.name if available to replace the boilerplate name in
files we generate
- fix shellshock warnings
* Test for git repo
Suggestion by @skullydazed
* Fix shellshock warning
* Incorporate feedback from reviewers
- thanks @vomindoraan
- use a heredoc instead of echo for console
- factor out common paths
* I2C driver docs
- Added I2C driver docs.
- Changed arm master i2c driver to have a weak i2c_init as it is impossible to account for all possible port configuration in the STM32 world.
* Update docs/i2c_driver.md
Co-Authored-By: yiancar <yiangosyiangou@cytanet.com.cy>
* Update docs/i2c_driver.md
Co-Authored-By: yiancar <yiangosyiangou@cytanet.com.cy>
* Update docs/i2c_driver.md
Co-Authored-By: yiancar <yiangosyiangou@cytanet.com.cy>
* Update docs/i2c_driver.md
Co-Authored-By: yiancar <yiangosyiangou@cytanet.com.cy>
* GPIO release fix
* initial commit
* put my name everywhere
* get the switch matrix correct
* add a basic keymap
* use a better LAYOUT macro
* update readme
* Add QMK Configurator support
* Added support for backlight , and a UK iso layout
Added support for backlight , and a UK iso layout. Now uses the SPLIT_KEYBOARD #define rather than relying on lets split
* Update keyboards/diverge3/keymaps/isoUK/keymap.c
Co-Authored-By: mcmadhatter <mcmadhatter@hotmail.com>
* Update keyboards/diverge3/keymaps/isoUK/keymap.c
Co-Authored-By: mcmadhatter <mcmadhatter@hotmail.com>
* Simplified the lower layer
Simplified the lower layer
* dir rename to snake case
dir rename to snake case
* changed dir case
changed dir case
* Update keyboards/diverge3/rules.mk
Co-Authored-By: mcmadhatter <mcmadhatter@hotmail.com>
* Update keyboards/diverge3/keymaps/iso_uk/config.h
Co-Authored-By: mcmadhatter <mcmadhatter@hotmail.com>
* Update keyboards/diverge3/config.h
Co-Authored-By: mcmadhatter <mcmadhatter@hotmail.com>
* Update keyboards/diverge3/keymaps/iso_uk/keymap.c
Co-Authored-By: mcmadhatter <mcmadhatter@hotmail.com>
* Update keyboards/diverge3/keymaps/iso_uk/keymap.c
Co-Authored-By: mcmadhatter <mcmadhatter@hotmail.com>
* Update keyboards/diverge3/keymaps/iso_uk/keymap.c
Co-Authored-By: mcmadhatter <mcmadhatter@hotmail.com>
* Update keyboards/diverge3/config.h
Co-Authored-By: mcmadhatter <mcmadhatter@hotmail.com>
* Update keyboards/diverge3/keymaps/iso_uk/config.h
Co-Authored-By: mcmadhatter <mcmadhatter@hotmail.com>
* Update keyboards/diverge3/keymaps/iso_uk/config.h
Co-Authored-By: mcmadhatter <mcmadhatter@hotmail.com>
* Update keyboards/diverge3/keymaps/iso_uk/config.h
Co-Authored-By: mcmadhatter <mcmadhatter@hotmail.com>
* aligned and tidyied up
aligned and tidyied up
* dlg's keymap
* fix list order
* remove cruft
* pragma
Co-Authored-By: dlgoodr <dlg@dsrw.org>
* turn on bootmagic, enable swapping ` and Esc while I figure out which compromise is least bad
* Initial move of 40percent.club boards to common parent folder.
* Refactor readme files to be consistent
* Refactor readme files to be consistent - fix make command examples.
* Refactor readme files to be consistent - align readme filenames.
* Refactor readme files to be consistent - fix repo url.
* Disable Community keymap builds as they are currently failing due to missing functionality
* Move more of 40percent.club boards to common parent folder.
* Refactor readme files to be consistent - align readme filenames.
* Refactor readme files to be consistent - fix make command examples.
* Preliminary 30wer firmware. Not tested on real board yet.
* Added a layer to default 30wer keymap.
* Wrote readme for 30wer.
* Added 30wer info.json.
* Configurable Rainbow Swirl range
This allows tweaking of the rainbow effect to
get different effects on keyboards with varied
LED layouts. We found the value 1950 works on
the RGBKB.net Sol to get a cool striped effect
across the keyboard.
* Document RGBLIGHT_RAINBOW_SWIRL_RANGE
* Better wording for the documentation
The new simple API can be selected.
Previous version, can select two way.
* use old API (compatible with let's split serial.c)
* use new API (multi-type transaction)
This version, can select three way.
* use old API (compatible with let's split serial.c)
* use new API (single-type transaction)
* use new API (multi-type transaction)
There is no change in the code generated by this change.
* Consistency fixes and more eeprom defaults
* Handle setting Unicode mode on eeprom reset better
* Unicode EEPROM hack
* Re-enable permissive hold and ignore mod tap
* Set unicode input mode
* More unicode stuff
* more haaaaaacks
* Attempted RGB Cleanup
* Fix compiler issue
* Add GitLab CI config for personal compiling
* Add avr gcc version to GitLab CI script
* Add rgblight init to matrix init
* Use Magic+Esc for entering bootloader mode
* Expand rules.mk
* Improve FN_RCTL tap dance
* Avoid one-line if statements
* Add PROGMEM to keymaps definition
* td_fn_rctl_* → td_fn_rctrl_*
* Fix FN_RCTL tap dance bug when count is 4, 8, 12 etc.
* Add ACTION_TAP_DANCE_DOUBLE_MODS
* Rearrange/rename keycode defines
* Use RAL_RGU and RCT_RSF in keymaps
* Replace keymap ASCII art with box drawing characters
* Add FN_FNLK and use it
* Set Unicode input mode in eeconfig_init_user instead of matrix_init_user
* 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
After further testing and feedback from others, the bottom row matrix was incorrect. Also RGB number was incorrect (I was tired when building this, really shouldn't do that).
* converter/adb_usb: Configurator support
Note: LAYOUT_ext_ansi has a blank space between the Spacebar and the
Right Alt/Option key when loaded in the Configurator. This is
deliberate.
Stock Apple Extended Keyboards and AEK IIs send the scan code for Left
Command when either Command key is used. (This is noted already in the
readme.) That being the case, the Command keys cannot be assigned to
different functions. Whichever keycode is placed on Left Command will be
used for both Command keys.
* converter/adb_usb: adb_usb.h cleanup
- replaced KEYMAP_COMMON_H with ADB_USB_H
- white space changes for visual alignment in LAYOUT_ext_ansi macro
* port over Rozakiin https://github.com/Rozakiin/Noxary_Firmware/tree/master/noxary_x268
* rename LAYOUT to LAYOUT_65_ansi default layout
* add configurator support
* add community layout support
* put Rozakiin's name everywhere
* update readme
* problems with the 65_ansi keymap to be diagnosed later
* Add distro support for sabayon
Sabayon is a gentoo based distro with a different package manager. Does
not need any use flags or masking for the required packages.
* Add missing backslash
* Put echo string in quotes, remove extra newline
* Order gentoo/sabayon packages alphabetically.
Rewrote USB state tracking for implementation of suspend state.
Updated suspend.c in entirety.
Main subtasks (generally hardware related) are now run prior to keyboard task.
* add computed pins from mcu type
* update for atmega32a
* doc typo
* add atmega16 chips, link to references
* remove avr include from config
* exclude assembler in config.h includes
* consolodate options, add 646
* fix typo in pindef
* Keymap: add jyh levinson keymaps
remove tap dance number keys due to sluggish responses
simplify I2C configuration
reverse hyper and meh positions
reduce tapping term to allow fast typing with mod tap space keys
remove Alt hold on right space key. too many false touches.
add vim-style arrows (hjkl) on asdf; semicolon/quote on raise
correct documentation string for jyh levinson layout
add alternative levinson layout for jyh
more inspiration from atreus keyboard. keeps shift in the expected
places. reduces number of layers. puts numpad layout easily
accessible. places important keys on palms and meta keys on top
corners for xmonad.
correct layer switching in jyh2 levinson layout
I was getting stuck on the numpad layer because the numpad hold key
was remapped once the layer was activated. Bad idea. Minor other
refinements.
use curly bracket { instead of brace [ on raise layer
add RGB keys on adjust layer
bootmagic key is confusing. turn it off.
try out permissive hold setting to make mod-tap better
remove hold for right control on quote key. too many mistakes
turn off permissive hold. it was causing unexpected behavior
enable rgb underglow animations
add make it pink/blue key to levinson layout
prevent stuck modifiers in jyh2 levinson keymap
* fix up deprecated code after code review
* remove PREVENT_STUCK_MODIFIERS because it is default
Co-Authored-By: yamad <jyamada1@gmail.com>
Added JTAG disable code to the split_common slave code since the slave never calls keyboard_init(). In the future the slave should likely be modified to call keyboard_init() in some way, but without calling any of the unnecessary USB initialization code.
* added initial config files for vinta
* added readme
* changed product id and device ver
* fixed keymap illustration
* updated rules.mk to enable more commands
* removed a bunch of pre-code text; changed some grammar woopsies
* removed bootmagic lite
* updated developer's note
* updated readme.md
* Initial commit of guidoism
* created movement layer
* movement layer works!
* removed unnecessary layers
* moved enter key up and recreated caps lock
* cleaned up
* num pad
* checkpoint
* checkpoint
* checkpoint
* Added num pad
* changed max power draw so i can use this on ipad
* move around quotes
* added tri layer for a homed numpad
* moved layout to new style
* Update readme.md
* Update readme.md
* Update readme.md
* Update readme.md
* added keys to unicode conversion
* removed adjust layer since its not used anymore
* moved esc to seperate key
* tweaked python
* checkpoint
* new code put into function
* new code put into function
* cleanup
* cleanup
* new code works perfect
* removed old code
* removed old code
* generate_c.py now replaces code within keymap.c
* added function layer
* updated readme
* updated readme
* updated readme
* updates readme
* updates readme
* updates readme
* Tweaks based on CR
* Remove old guidoism
* Use MO(_FUNCTION) directly
* Preliminary additon of bootmagic lite functionality
* Cleanup code
* Clean up bootmagic code
* Add documentation and clean up code
* Make 'lite' an option for BOOTMAGIC_ENABLE
* Update Templates with note about Bootmagic Lite option
* Detect Debounce variable
* Make sure debounce is a non-zero number
* Capitalize Bootmagic
* Capitalize bootmagic
* Update wording
* Re-add EEPROM reset, by popular demand
And add eeprom-less version to drashna userspace for his sanity
* Fix spacing
* Set BOOTMAGIC_ENABLE to use full/lite/off
And default yes to "full" for compatibility
* Add Bootmagic lite info to templates
* Remove text from makefiles
* Cleanup of makefile
* mention yes in bootmagic docs
* Wordsmitthing the docs
* Fix white spaces
* Readd default bootmagic setting, because it's necessary
* layer locked breathing, layer changed brighter leds
* move config for tapping term into config.h
* Respect LED off even with layer indicators, add readme and update config
to new standard
* update Readme with note about both sides of board being required to flash
- [ ] 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. -->
* 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 +109,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
@@ -132,16 +132,22 @@ If you define these options you will enable the associated feature, which may in
*`#define TAPPING_TOGGLE 2`
* how many taps before triggering the toggle
*`#define PERMISSIVE_HOLD`
* makes tap and hold keys work better for fast typers who don't want tapping term set above 500
* makes tap and hold keys trigger the hold if another key is pressed before releasing, even if it hasn't hit the `TAPPING_TERM`
* See [Permissive Hold](feature_advanced_keycodes.md#permissive-hold) for details
*`#define IGNORE_MOD_TAP_INTERRUPT`
* makes it possible to do rolling combos (zx) with keys that convert to other keys on hold
* See [Mod tap interrupt](feature_advanced_keycodes.md#mod-tap-interrupt) for details
* makes it possible to do rolling combos (zx) with keys that convert to other keys on hold, by enforcing the `TAPPING_TERM` for both keys.
* See [Mod tap interrupt](feature_advanced_keycodes.md#ignore-mod-tap-interrupt) for details
*`#define TAPPING_FORCE_HOLD`
* makes it possible to use a dual role key as modifier shortly after having been tapped
* See [Hold after tap](feature_advanced_keycodes.md#hold-after-tap)
* See [Hold after tap](feature_advanced_keycodes.md#tapping-force-hold)
* 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`
@@ -159,6 +165,8 @@ 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
@@ -189,12 +197,51 @@ 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
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
*`#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 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.
@@ -246,6 +293,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`
@@ -256,7 +305,40 @@ 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.
*`CUSTOM_DEBOUNCE`
* Allows replacing the standard key debouncing routine with a custom one.
*`WAIT_FOR_USB`
* Forces the keyboard to wait for a USB connection to be established before it starts up
*`NO_USB_STARTUP_CHECK`
* Disables usb suspend check after keyboard startup. Usually the keyboard waits for the host to wake it up before any tasks are performed. This is useful for split keyboards as one half will not get a wakeup call but must send commands to the master.
## USB Endpoint Limitations
In order to provide services over USB, QMK has to use USB endpoints.
These are a finite resource: each microcontroller has only a certain number.
This limits what features can be enabled together.
If the available endpoints are exceeded, a build error is thrown.
The following features can require separate endpoints:
*`MOUSEKEY_ENABLE`
*`EXTRAKEY_ENABLE`
*`CONSOLE_ENABLE`
*`NKRO_ENABLE`
*`MIDI_ENABLE`
*`RAW_ENABLE`
*`VIRTSER_ENABLE`
In order to improve utilisation of the endpoints, the HID features can be combined to use a single endpoint.
By default, `MOUSEKEY`, `EXTRAKEY`, and `NKRO` are combined into a single endpoint.
The base keyboard functionality can also be combined into the endpoint,
by setting `KEYBOARD_SHARED_EP = yes`.
This frees up one more endpoint,
but it can prevent the keyboard working in some BIOSes,
as they do not implement Boot Keyboard protocol switching.
Combining the mouse also breaks Boot Mouse compatibility.
The mouse can be uncombined by setting `MOUSE_SHARED_EP = no` if this functionality is required.
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
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 B1, B2, and B3 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 +258,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/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)`
@@ -256,7 +337,7 @@ 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!
### 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.
@@ -126,5 +130,5 @@ For now, you need to rollback avr-gcc to 7 in brew.
@@ -11,8 +11,8 @@ Keycodes are actually defined in [common/keycode.h](https://github.com/qmk/qmk_f
There are 3 standard keyboard layouts in use around the world- ANSI, ISO, and JIS. North America primarily uses ANSI, Europe and Africa primarily use ISO, and Japan uses JIS. Regions not mentioned typically use either ANSI or ISO. The keycodes corresponding to these layouts are shown here:
<!-- Source for this image: http://www.keyboard-layout-editor.com/#/gists/070a530eedaed36a2d77f3f6fd455677 -->
@@ -21,11 +21,11 @@ Additionally, if at least one right-handed modifier is specified in a Mod Tap or
# 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,22 +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
@@ -147,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 */
```
@@ -162,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:
@@ -171,30 +250,56 @@ As of [PR#1359](https://github.com/qmk/qmk_firmware/pull/1359/), there is a new
#define PERMISSIVE_HOLD
```
This makes it easier for fast typists to use dual-function keys. Without this, if you let go of a held key inside the tapping term, it won't register.
This makes tap and hold keys (like Mod Tap) work better for fast typist, or for high `TAPPING_TERM` settings.
Example: (Tapping Term = 200ms)
If you press a Mod Tap key, tap another key (press and release) and then release the Mod Tap key, all within the tapping term, it will output the "tapping" function for both keys.
- SHFT_T(KC_A) Down
- KC_X Down
- KC_X Up
- SHFT_T(KC_A) Up
For Instance:
With defaults, if above is typed within tapping term, this will emit `ax`. With permissive hold, if above is typed within tapping term, this will emit `X` (so, Shift+X).
-`SHFT_T(KC_A)` Down
-`KC_X` Down
-`KC_X` Up
-`SHFT_T(KC_A)` Up
# Mod tap interrupt
Normally, if you do all this within the `TAPPING_TERM` (default: 200ms) this will be registered as `ax` by the firmware and host system. With permissive hold enabled, this modifies how this is handled by considering the Mod Tap keys as a Mod if another key is tapped, and would registered as `X` (`SHIFT`+`x`).
When a dual role key used for a modifier is quickly followed by another keys, it is interpreted as held even before the tapping term elapsed. This is a problem if a key is used for example inside a rolling combo because the second key will be pressed before the first key is released.
?> 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`.
For example, when trying to type the rolling combo "zx" and z being configured to send Ctrl when hold, z rapidly followed by x actually sends Ctrl-x. That's bad.
## Ignore Mod Tap Interrupt
You can disable this behavior by defining `IGNORE_MOD_TAP_INTERRUPT` in`config.h`.
To enable this setting, add this to your`config.h`:
Note that this only concerns modifiers and not layer switching keys.
```c
#define IGNORE_MOD_TAP_INTERRUPT
```
# Hold after tap
Similar to Permissive Hold, this alters how the firmware processes input for fast typist. If you press a Mod Tap key, press another key, release the Mod Tap key, and then release the normal key, it would normally output the "tapping" function for both keys. This may not be desirable for rolling combo keys.
When the user holds a key after tap, this repeats the tapped key rather to hold a modifier key. This allows to use auto repeat for the tapped key. If you prefer to hold a modifier instead, define `TAPPING_FORCE_HOLD` in `config.h`.
Setting `Ignore Mod Tap Interrupt` requires holding both keys for the `TAPPING_TERM` to trigger the hold function (the mod).
For Instance:
-`SHFT_T(KC_A)` Down
-`KC_X` Down
-`SHFT_T(KC_A)` Up
-`KC_X` Up
Normally, this would send `X` (`SHIFT`+`x`). With `Ignore Mod Tap Interrupt` enabled, holding both keys are required for the `TAPPING_TERM` to register the hold action. A quick tap will output `ax` in this case, while a hold on both will still output `X` (`SHIFT`+`x`).
?> __Note__: This only concerns modifiers and not layer switching keys.
?> 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
To enable `tapping force hold`, add the following to your `config.h`:
```c
#define TAPPING_FORCE_HOLD
```
When the user holds a key after tap, this repeats the tapped key rather to hold a modifier key. This allows to use auto repeat for the tapped key.
Example:
@@ -210,8 +315,14 @@ 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`:
```c
#define RETRO_TAPPING
```
Holding and releasing a dual function key without pressing another key will result in nothing happening. With retro tapping enabled, releasing the key without pressing another will send the original keycode even if it is outside the tapping term.
For instance, holding and releasing `LT(2, KC_SPACE)` without hitting another key will result in nothing happening. With `RETRO_TAPPING` defined in your `config.h`, it will send `KC_SPACE`.
For instance, holding and releasing `LT(2, KC_SPACE)` without hitting another key will result in nothing happening. With this enabled, it will send `KC_SPACE` instead.
@@ -61,10 +61,19 @@ 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
For ARM devices, you can adjust the DAC sample values. If your board is too loud for you or your coworkers, you can set the max using `DAC_SAMPLE_MAX` in your `config.h`:
```c
#define DAC_SAMPLE_MAX 65535U
```
## Music Mode
@@ -151,7 +160,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.
@@ -11,7 +11,15 @@ There are three separate but related features that allow you to change the behav
On some keyboards Bootmagic is disabled by default. If this is the case, it must be explicitly enabled in your `rules.mk` with:
```make
BOOTMAGIC_ENABLE=yes
BOOTMAGIC_ENABLE=full
```
?> You may see `yes` being used in place of `full`, and this is okay. However, `yes` is deprecated, and ideally `full` (or `lite`) should be used instead.
Additionally, you can use [Bootmagic Lite](#bootmagic-lite) (a scaled down, very basic version of Bootmagic) by adding the following to your `rules.mk` file:
```make
BOOTMAGIC_ENABLE= lite
```
## Hotkeys
@@ -99,3 +107,47 @@ If you would like to change the hotkey assignments for Bootmagic, `#define` thes
|`BOOTMAGIC_KEY_DEFAULT_LAYER_5` |`KC_5` |Make layer 5 the default layer |
|`BOOTMAGIC_KEY_DEFAULT_LAYER_6` |`KC_6` |Make layer 6 the default layer |
|`BOOTMAGIC_KEY_DEFAULT_LAYER_7` |`KC_7` |Make layer 7 the default layer |
# Bootmagic Lite
In addition to the full blown Bootmagic feature, is the Bootmagic Lite feature that only handles jumping into the bootloader. This is great for boards that don't have a physical reset button but you need a way to jump into the bootloader, and don't want to deal with the headache that Bootmagic can cause.
To enable this version of Bootmagic, you need to enable it in your `rules.mk` with:
```make
BOOTMAGIC_ENABLE= lite
```
Additionally, you may want to specify which key to use. This is especially useful for keyboards that have unusual matrices. To do so, you need to specify the row and column of the key that you want to use. Add these entries to your `config.h` file:
```c
#define BOOTMAGIC_LITE_ROW 0
#define BOOTMAGIC_LITE_COLUMN 1
```
By default, these are set to 0 and 0, which is usually the "ESC" key on a majority of keyboards.
And to trigger the bootloader, you hold this key down when plugging the keyboard in. Just the single key.
!> Using bootmagic lite will **always reset** the EEPROM, so you will lose any settings that have been saved.
## Advanced Bootmagic Lite
The `bootmagic_lite` function is defined weakly, so that you can replace this in your code, if you need. A great example of this is the Zeal60 boards that have some additional handling needed.
To replace the function, all you need to do is add something like this to your code:
You can additional feature here. For instance, resetting the eeprom or requiring additional keys to be pressed to trigger bootmagic. Keep in mind that `bootmagic_lite` is called before a majority of features are initialized in the firmware.
This will send Ctrl+C if you hit Z and C, and Ctrl+V if you hit Z and V. But you could change this to do stuff like change layers, play sounds, or change settings.
This will send Ctrl+C if you hit Z and C, and Ctrl+V if you hit X and V. But you could change this to do stuff like change layers, play sounds, or change settings.
@@ -16,35 +16,35 @@ 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 | You are using the included matrix.c and debounce.c | Nothing. Debounce_sym_g will be compiled, and used if necessary |
| custom | Use your own debounce.c | ```SRC += debounce.c``` add your own debounce.c and implement necessary functions |
| sym_g / eager_pk | You are using the included matrix.c and debounce.c | Use an alternative debounce algorithm |
**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 included ```debounce_sym_g.c```s for sample implementations.
* 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:
* debounce_eager_pk - debouncing per key. On any state change, response is immediate, followed by ```DEBOUNCE_DELAY``` millseconds of no further input for that key
* debounce_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 CMD/GUI + KC_GRV is actually mapped to a hot key so it will not output a backtick.
## 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`:
@@ -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) {
if (!record->event.pressed) {
### Macro Commands
@@ -169,21 +187,21 @@ Use the `M()` function within your `KEYMAP()` to call a macro. For example, here
@@ -213,11 +231,11 @@ There are some functions you may find useful in macro-writing. Keep in mind that
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 +250,8 @@ 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.
### `clear_keyboard();`
This will clear all mods and keys currently pressed.
@@ -250,16 +270,16 @@ This example defines a macro which sends `Ctrl-C` when pressed down, and `Ctrl-V
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
@@ -150,6 +154,30 @@ These are the effects that are currently available:
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) |
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!
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.
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 main 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.
* **`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.
1. Press the `RESET` keycode, or short RST to GND quickly (you only have 7 seconds to flash once it enters)
2. Wait for the OS to detect the device
4. Flash a .hex file
5. Wait for the device to reset automatically
3. Flash a .hex file
4. Wait for the device to reset automatically
or
@@ -106,5 +106,28 @@ Flashing sequence:
1. Press the `RESET` keycode, or short RST to GND quickly (you only have 7 seconds to flash once it enters)
2. Wait for the OS to detect the device
4. Flash a .hex file
5. Reset the device into application mode (may be done automatically)
3. Flash a .hex file
4. Reset the device into application mode (may be done automatically)
## STM32
All STM32 chips come preloaded with a factory bootloader that cannot be modified nor deleted. Some STM32 chips have bootloaders that do not come with USB programming (e.g. STM32F103) but the process is still the same.
At the moment, no `BOOTLOADER` variable is needed on `rules.mk` for STM32.
1. Enter the bootloader using any of the following methods:
* Tap the `RESET` keycode (may not work on STM32F042 devices)
* If a reset circuit is present, tap the RESET button
* Otherwise, you need to bridge BOOT0 to VCC (via BOOT0 button or bridge), short RESET to GND (via RESET button or bridge), and then let go of the BOOT0 bridge
2. Wait for the OS to detect the device
3. Flash a .bin file
* 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
(the `dfu-programmer` package is availble on AUR only so you should download from there or use an AUR helper)
## Nix
@@ -57,6 +63,7 @@ If you're using [homebrew,](http://brew.sh/) you can use the following commands:
brew tap PX4/homebrew-px4
brew update
brew install avr-gcc@7
brew link --force avr-gcc@7
brew install dfu-programmer
brew install dfu-util
brew install gcc-arm-none-eabi
@@ -122,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().
`CUSTOM_DEBOUNCE`
Lets you replace the default key debouncing routine with your own code. You will need to provide your own implementation of debounce().
## 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.
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!
|`void i2c_init(void);` |Initializes the I2C driver. This function should be called once before any transaction is initiated. |
|`uint8_t i2c_start(uint8_t address);` |Starts an I2C transaction. Address is the 7-bit slave address without the direction bit. |
|`uint8_t i2c_transmit(uint8_t address, uint8_t* data, uint16_t length, uint16_t timeout);` |Transmit data over I2C. Address is the 7-bit slave address without the direction. Returns status of transaction. |
|`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. |
### Function Return
All the above functions, except `void i2c_init(void);` return the following truth table:
|`#STM32_I2C_USE_XXX` |Enable/Disable the hardware driver XXX (each driver should be explicitly listed) |FALSE |
|`#STM32_I2C_BUSY_TIMEOUT` |Time in ms until the I2C command is aborted if no response is received |50 |
|`#STM32_I2C_XXX_IRQ_PRIORITY` |Interrupt priority for hardware driver XXX (THIS IS AN EXPERT SETTING) |10 |
|`#STM32_I2C_USE_DMA` |Enable/Disable the ability of the MCU to offload the data transfer to the DMA unit |TRUE |
|`#STM32_I2C_XXX_DMA_PRIORITY` |Priority of DMA unit for hardware driver XXX (THIS IS AN EXPERT SETTING) |1 |
Secondly, in the `halconf.h` file, `#define HAL_USE_I2C` must be set to `TRUE`. This allows ChibiOS to load its I2C driver.
Lastly, we need to assign the correct GPIO pins depending on the I2C hardware driver we want to use.
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. You can use these defines to set your i2c pins:
| `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);
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
@@ -12,12 +12,12 @@ The following functions can provide basic control of GPIOs and are found in `qua
|`setPinInputHigh(pin)`|Set pin as input with build in pull-up |
|`setPinInputLow(pin)` |Set pin as input with build in pull-down (Supported only on STM32)|
|`setPinOutput(pin)` |Set pin as output |
|`writePinHige(pin)` |Set pin level as high, assuming it is an output |
|`writePinHigh(pin)` |Set pin level as high, assuming it is an output |
|`writePinLow(pin)` |Set pin level as low, assuming it is an output |
|`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!
|`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)
@@ -318,44 +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)
@@ -429,18 +429,6 @@ This is a reference only. Each group of keys links to the page documenting their
@@ -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
Your computer keyboard has a processor inside of it, not unlike the one inside your computer. This processor runs software that is responsible for detecting button presses and sending reports about the state of the keyboard when they are pressed or released. QMK fills the role of that software, detecting button presses and passing that information on to the host computer. When you build your custom layout you are creating the equivalent of an .exe for your keyboard.
Your computer keyboard has a processor inside of it, not unlike the one inside your computer. This processor runs software that is responsible for detecting button presses and sending reports about the state of the keyboard when buttons are pressed or released. QMK fills the role of that software, detecting button presses and passing that information on to the host computer. When you build your custom keymap, you are creating the equivalent of an executable program for your keyboard.
QMK tries to put a lot of power into your hands by making easy things easy, and hard things possible. You don't have to know how to program to create powerful layouts, you only have to follow a few simple syntax rules.
QMK tries to put a lot of power into your hands by making easy things easy, and hard things possible. You don't have to know how to program to create powerful keymaps — you only have to follow a few simple syntax rules.
# Getting Started
Before you can build keymaps you need to install some software and setup your build environment. This only has to be done one time no matter how many keyboards you want to compile firmware for.
Before you can build keymaps, you need to install some software and setup 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
### Text Editor
You'll need a program that can edit and save **plain text** files. If you are on Windows you can make due with Notepad, and on Linux you can use Gedit, both of which are simple but functional text editors. On macOS be careful with TextEdit.app, it will not save plain text files unless you make sure to select "Make Plain text" from the "Format" menu, or you can use another program such as Sublime Text.
You'll need a program that can edit and save **plain text** files. If you're on Windows you can make do with Notepad, and on Linux you can use gedit. Both of these are simple but functional text editors. On macOS, be careful with the default TextEditapp: it will not save plain text files unless you explicitly select _Make Plain Text_ from the _Format_ menu.
You can also download and install a dedicated text editor like [Sublime Text](https://www.sublimetext.com/) or [VS Code](https://code.visualstudio.com/). This is probably the best way to go regardless of platform, as these programs are specifically made for editing code.
?> Not sure which text editor to use? Laurence Bradford wrote [a great introduction](https://learntocodewith.me/programming/basics/text-editors/) to the subject.
### QMK Toolbox
QMK Toolbox is an optional graphical Windows and macOS program that allows you to both program and debug your custom keyboard. You will likely prefer it to easily flash your keyboard and receive the debugging messages that your keyboard will print.
QMK Toolbox is an optional graphical program for Windows and macOS that allows you to both program and debug your custom keyboard. You will likely find it invaluable for easily flashing your keyboard and viewing debug messages that it prints.
Download the files from the links below:
[Download the latest release here.](https://github.com/qmk/qmk_toolbox/releases/latest)
For Windows: "qmk_toolbox.exe" or "qmk_toolbox_install.exe" (with installer)
*For Windows: `qmk_toolbox.exe` (portable) or `qmk_toolbox_install.exe` (installer)
* For macOS: `QMK.Toolbox.app.zip` (portable) or `QMK.Toolbox.pkg` (installer)
For Mac: "QMK.Toolbox.app.zip" or "QMK.Toolbox.pkg" (with installer)
We've tried to make QMK as easy to set up as possible. You only have to prepare your Linux or Unix environment, then let QMK install the rest.
## Environment Setup
We've tried to make QMK as easy to setup as possible. You only have to prepare your Linux or Unix environment and let QMK install the rest.
?> If you haven't worked with the Linux/Unix command line before there are a few basic concepts and commands you should learn. These resources will teach you enough to work with QMK:<br>
?> If you haven't worked with the Linux/Unix command line before, there are a few basic concepts and commands you should learn. These resources will teach you enough to be able to work with QMK:<br>
[Must Know Linux Commands](https://www.guru99.com/must-know-linux-commands.html)<br>
* Follow the installation instructions on the msys2 homepage: http://www.msys2.org
* Close any open msys2 terminals, and open a new terminal
* Install git by running this command: `pacman -S git`
* Follow the installation instructions on the [MSYS2 homepage](http://www.msys2.org).
* Close any open MSYS2 terminals and open a new MSYS2 MinGW 64-bit terminal.
* Install Git by running this command: `pacman -S git`.
### macOS
You will need to install homebrew. Follow the instructions on the homebrew homepage: https://brew.sh
You will need to install Homebrew. Follow the instructions on the [Homebrew homepage](https://brew.sh).
After homebrew is installed continue with "Download QMK", following step "Setup QMK" runs a script that will install other packages.
After Homebrew is installed, continue with _Set Up QMK_. In that step you will run a script that will install other packages.
### Linux
You will need to install git. It's extremely likely you already have it, but if not one of the following commands should install it:
You will need to install Git. It's very likely that you already have it, but if not, one of the following commands should install it:
* Debian/Ubuntu/Devuan: `apt-get install git`
* Fedora/Redhat/Centos: `yum install git`
* Debian / Ubuntu / Devuan: `apt-get install git`
* Fedora / Red Hat / CentOS: `yum install git`
* Arch: `pacman -S git`
## Download QMK
?> Docker is also an option on all platforms. [Click here for details.](getting_started_build_tools.md#docker)
Once you have setup 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 Console window and leave it open for the remainder of this guide. Inside that window run these two commands:
## Set Up QMK
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:
git clone https://github.com/qmk/qmk_firmware.git
cd qmk_firmware
?> If you already know [how to use GitHub](getting_started_github.md) we recommend you create and clone your own fork instead. If you don't know what that means you can safely ignore this message.
?> 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.
## Setup QMK
QMK comes with a script to help you setup the rest of what you'll need. You should run it now by typing in this command:
QMK comes with a script to help you setup the rest of what you'll need. You should run it now by typing in this command:
./util/qmk_install.sh
util/qmk_install.sh
## Test Your Build Environment
Now that your QMK build environment is setup you can build a firmware for your keyboard. Start by trying to build the default layout for your keyboard. You should be able to do that with a command in this format:
Now that your QMK build environment is setup, you can build a firmware for your keyboard. Start by trying to build the keyboard's default keymap. You should be able to do that with a command in this format:
make <keyboard>:default
For example, to build a firmware for a Clueboard 66% use:
For example, to build a firmware for a Clueboard 66% you would use:
make clueboard/66/rev3:default
When it is done you should have a lot of output that ends similar to this:
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`:
@@ -96,3 +96,24 @@ And to do so, add `reset_keyboard()` to your function or macro, and this will re
If you're having issues with Audio, RGB Underglow, backlighting or keys acting weird, then you can reset the EEPROM (persistent setting storage). Bootmagic is one way to do this, but if that isn't enabled, then you can use a custom macro to do so.
To wipe the EEPROM, run `eeconfig_init()` from your function or macro to reset most of the settings to default.
## Tap random key
If you want to send a random character to the host computer, you can use the `tap_random_base64()` function. This [pseudorandomly](https://en.wikipedia.org/wiki/Pseudorandom_number_generator) selects a number between 0 and 63, and then sends a key press based on that selection. (0–25 is `A`–`Z`, 26–51 is `a`–`z`, 52–61 is `0`–`9`, 62 is `+` and 63 is `/`).
?> Needless to say, but this is _not_ a cryptographically secure method of generating random Base64 keys or passwords.
## Software Timers
It's possible to start timers and read values for time-specific events. Here's an example:
This page covers how to properly support keyboards in the [QMK Configurator](https://config.qmk.fm/).
## How the Configurator Understands Keyboards
To understand how the Configurator understands keyboards, first one must understand layout macros. For this exercise, we're going to imagine a 17-key numpad PCB, which we're going to call `numpad`.
```
┌───┬───┬───┬───┐
│NLk│ / │ * │ - │
├───┼───┼───┼───┤
│7 │8 │9 │ + │
├───┼───┼───┤ │
│4 │5 │6 │ │
├───┼───┼───┼───┤
│1 │2 │3 │Ent│
├───┴───┼───┤ │
│0 │ . │ │
└───────┴───┴───┘
```
?> For more on layout macros, see [Understanding QMK: Matrix Scanning](understanding_qmk.md?id=matrix-scanning) and [Understanding QMK: Matrix to Physical Layout Map](understanding_qmk.md?id=matrix-to-physical-layout-map).
The Configurator's API reads the keyboard's `.h` file from `qmk_firmware/keyboards/<keyboard>/<keyboard>.h`. For our numpad, this file would be `qmk_firmware/keyboards/numpad/numpad.h`:
```c
#pragma once
#define LAYOUT( \
k00, k01, k02, k03, \
k10, k11, k12, k13, \
k20, k21, k22, \
k30, k31, k32, k33, \
k40, k42 \
) { \
{ k00, k01, k02, k03 }, \
{ k10, k11, k12, k13 }, \
{ k20, k21, k22, KC_NO }, \
{ k30, k31, k32, k33 }, \
{ k40, KC_NO, k42, KC_NO } \
}
```
QMK uses `KC_NO` to designate places in the switch matrix where there is no switch. Sometimes, `XXX`, `___` or `____` are used as shorthand to make this section easier to read if it needs to be debugged. This is usually defined near the beginning of the `.h` file:
```c
#pragma once
#define XXX KC_NO
#define LAYOUT( \
k00, k01, k02, k03, \
k10, k11, k12, k13, \
k20, k21, k22, \
k30, k31, k32, k33, \
k40, k42 \
) { \
{ k00, k01, k02, k03 }, \
{ k10, k11, k12, k13 }, \
{ k20, k21, k22, XXX }, \
{ k30, k31, k32, k33 }, \
{ k40, XXX, k42, XXX } \
}
```
!> This usage differs from that of keymap macros, which almost always use `XXXXXXX` (seven capital X's) for `KC_NO` and `_______` (seven underscores) for `KC_TRNS`.
!> To prevent user confusion, using `KC_NO` is preferred.
The layout macro tells the Configurator that our keyboard has 17 keys, arranged in five rows of four columns each. Our switch positions are named `k<row><column>`, counting from 0. The names themselves actually don't matter, as long as they match between the top section, which receives the keycodes from the keymap, and the bottom half which designates where each key is in the matrix.
To display our keyboard in a way that resembles the physical keyboard, we need to build a JSON file that tells the Configurator how to tie the physical locations and sizes of our keys to our switch matrix.
## Building the JSON file
To build the JSON file, the easiest way is to build the layout in [Keyboard Layout Editor](http://www.keyboard-layout-editor.com/) ("KLE"), from which we'll feed the Raw Data into a QMK tool that converts this data into a JSON the Configurator will read and use. Since KLE opens by default with a numpad layout, we're just going to remove the Getting Started instructions, and use what's left.
Once the layout is as desired, move to the Raw Data tab in KLE, and copy the contents:
```
["Num Lock","/","*","-"],
["7\nHome","8\n↑","9\nPgUp",{h:2},"+"],
["4\n←","5","6\n→"],
["1\nEnd","2\n↓","3\nPgDn",{h:2},"Enter"],
[{w:2},"0\nIns",".\nDel"]
```
To convert this data into our JSON, go to the [QMK KLE-JSON Converter](https://qmk.fm/converter/), paste the Raw Data into the Input field, and click the Convert button. After a moment, our JSON data will appear in the Output field. Copy the contents to a new text document, and name the document `info.json`, saving it in the same folder that contains `numpad.h`.
Use the `keyboard_name` object to set the name of the keyboard. The `bootloader` object is deprecated, so it can be deleted. For instruction purposes, we will put each key's object on its own line. This is only to make the file more human-readable, and does not affect the Configurator's functionality.
```json
{
"keyboard_name":"Numpad",
"url":"",
"maintainer":"qmk",
"tags":{
"form_factor":"numpad"
},
"width":4,
"height":5,
"layouts":{
"LAYOUT":{
"layout":[
{"label":"Num Lock","x":0,"y":0},
{"label":"/","x":1,"y":0},
{"label":"*","x":2,"y":0},
{"label":"-","x":3,"y":0},
{"label":"7","x":0,"y":1},
{"label":"8","x":1,"y":1},
{"label":"9","x":2,"y":1},
{"label":"+","x":3,"y":1,"h":2},
{"label":"4","x":0,"y":2},
{"label":"5","x":1,"y":2},
{"label":"6","x":2,"y":2},
{"label":"1","x":0,"y":3},
{"label":"2","x":1,"y":3},
{"label":"3","x":2,"y":3},
{"label":"Enter","x":3,"y":3,"h":2},
{"label":"0","x":0,"y":4,"w":2},
{"label":".","x":2,"y":4}
]
}
}
}
```
The `layouts` object contains the data that represents the physical layout of the keyboard. It has an object `LAYOUT`, which needs to match the name of our layout macro from `numpad.h`. The `LAYOUT` object itself has an object named `layout`, which contains one JSON object for each physical key on our keyboard, formatted as follows:
```
┌ The name of the key. Not displayed in the Configurator.
│ ┌ The key's X-axis location, in key units from the
│ │ keyboard's left edge.
│ │ ┌ The key's Y-axis location, in key units from
│ │ │ the keyboard's top (rear-facing) edge.
↓ ↓ ↓
{"label":"Num Lock", "x":0, "y":0},
```
Some objects will also have `"w"` and `"h"` keys, which represent a key's width and height, respectively.
?> For more on the `info.json` files, see [QMK Keyboard Guidelines: Keyboard Metadata](hardware_keyboard_guidelines.md?id=keyboard-metadata)
## How the Configurator Programs Keys
The Configurator's API uses the layout macro and the JSON file we've given it to create a visual representation of the keyboard that has each visual object tied to a specific key, in sequence:
key in layout macro | JSON object used
:---: | :----
k00 | {"label":"Num Lock", "x":0, "y":0}
k01 | {"label":"/", "x":1, "y":0}
k02 | {"label":"*", "x":2, "y":0}
k03 | {"label":"-", "x":3, "y":0}
k10 | {"label":"7", "x":0, "y":1}
k11 | {"label":"8", "x":1, "y":1}
k12 | {"label":"9", "x":2, "y":1}
k13 | {"label":"+", "x":3, "y":1, "h":2}
k20 | {"label":"4", "x":0, "y":2}
k21 | {"label":"5", "x":1, "y":2}
k22 | {"label":"6", "x":2, "y":2}
k30 | {"label":"1", "x":0, "y":3}
k31 | {"label":"2", "x":1, "y":3}
k32 | {"label":"3", "x":2, "y":3}
k33 | {"label":"Enter", "x":3, "y":3, "h":2}
k40 | {"label":"0", "x":0, "y":4, "w":2}
k42 | {"label":".", "x":2, "y":4}
When a user selects the top-left key in the Configurator, and assigns Num Lock to it, the Configurator builds a keymap file with `KC_NLCK` as the first key, and so on as the keymap is built. The `label` keys are not used; they are only for the user's reference in identifying specific keys when debugging the `info.json` file.
## Issues and Hazards
Currently, the Configurator does not support key rotation or non-rectangular key shapes like ISO Enter. Additionally, keys that are vertically-offset from their "row" — the arrow keys on 1800-layouts like the [TKC1800](https://github.com/qmk/qmk_firmware/tree/4ac48a61a66206beaf2fdd5f2939d8bbedd0004c/keyboards/tkc1800/) being a prominent example — confuse the KLE-to-JSON Converter, if not adjusted for by the contributor of the `info.json` file.
### Workarounds
#### Non-rectangular keys
For ISO Enter keys, QMK custom is to display it as a rectangular key, 1.25u wide and 2u high, aligned so its right edge is aligned with the right edge of the alphanumeric key block.

*A 60% keyboard in standard ISO layout, as rendered by QMK Configurator.*
#### Vertically-offset keys
For vertically-offset keys, place them in KLE as if they were not offset, then edit the Y-values as needed in the converted JSON file

*An 1800-layout keyboard as rendered in Keyboard Layout Editor, without the vertical offset applied to the arrow keys.*

*A Unix diff file, showing the changes needed to vertically-offset the arrow keys in our keyboard's JSON file.*
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:
@@ -77,7 +77,7 @@ 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.
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
@@ -130,31 +130,33 @@ 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.
Make example for this keyboard (after setting up your build environment):
make 1upkeyboards/1up60hte:default
See the [build environment setup](https://docs.qmk.fm/#/getting_started_build_tools) and the [make instructions](https://docs.qmk.fm/#/getting_started_make_guide) for more information. Brand new to QMK? Start with our [Complete Newbs Guide](https://docs.qmk.fm/#/newbs).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.