* 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 3d175f2340c14250a71af78afec5a1e890d9f4e7.
* 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 f0efb82443a7dc34b75579359b0514e8bfa51100.
* 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
2018-11-03 15:09:32 -07:00
710 changed files with 24278 additions and 6524 deletions
@ -132,14 +132,15 @@ 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
*`#define ONESHOT_TIMEOUT 300`
@ -260,3 +261,32 @@ Use these to enable or disable building certain features. The more you have enab
* 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.
@ -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 -->
@ -73,7 +73,6 @@ These allow you to combine a modifier with a keycode. When pressed, the keydown
|`HYPR(kc)`| |Hold Left Control, Shift, Alt and GUI and press `kc`|
|`MEH(kc)` | |Hold Left Control, Shift and Alt and press `kc` |
|`LCAG(kc)`| |Hold Left Control, Alt and GUI and press `kc` |
|`ALTG(kc)`| |Hold Right Control and Alt and press `kc` |
|`SGUI(kc)`|`SCMD(kc)`, `SWIN(kc)`|Hold Left Shift and GUI and press `kc` |
|`LCA(kc)` | |Hold Left Control and Alt and press `kc` |
@ -171,30 +170,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:
@ -212,6 +237,12 @@ With `TAPPING_FORCE_HOLD`, the second press will be interpreted as a Shift, allo
# 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.
@ -65,6 +65,13 @@ The available keycodes for audio are:
*`AU_OFF` - Turn audio mode off
*`AU_TOG` - Toggle audio mode
## 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`:
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.
@ -30,7 +30,7 @@ Make sure that the order for both matches.
## 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 0xFFFFFFFF. As with `UNICODE_MAP`, you may want to maintain a mapping table in your keymap file. However, there is no keycodes for this feature, you will have to add a keycode or function to call `qk_ucis_start()`. Once you've run that, you can just type the text for your unicode, and then hit space or enter to complete it, or ESC to cancel it. And if it matches an entry in your table, it will automatically "backspace" the trigger word (from your table) and then will input the unicode sequence.
For instance, you would need to have a table like this in your keymap:
|`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.
This can be changed by declaring the `i2c_init` function which intentionally has a weak attribute. Please consult the datasheet of your MCU for the available GPIO configurations. The following is an example initialization function:
```C
voidi2c_init(void)
{
setPinInput(B6);// Try releasing special pins for a short time
setPinInput(B7);
chThdSleepMilliseconds(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
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.
## 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:
@ -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 program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
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.