Previously, when looking for rules.mk files, we'd parse the individual
folders (A/B/C/D/E) into 5 variables, (A/B/C/D/E, A/B/C/D, A/B/C, A/B,
and A). Then, we'd get the final directory names and store _those_ in 5
new variables (A, B, C, D, and E). Then, when looking for the rules.mk,
we'd look in root_dir/keyboards/(A|B|C|D|E)/rules.mk, instead of looking
in root_dir/keyboards(A|A/B|A/B/C|A/B/C/D|A/B/C/D/E)/rules.mk. This
commit changes that logic from the former to the latter.
* Line ending stuff again
* Added Let's Split Eh? Files and updated #USE_IC2 checks to also include th EH revision (can only be used in I2C)
* Added personal keymap, updated some of the EH files
* Created new keyboard file for testing "lets_split_eh" will merge into lets_split once fully functional
* Added split code from lets_split, removed pro micro imports and LED code
THIS IS WORKING CODE, WITHOUT RGB AND BACKLIGHT
* Took back original Lets Slit files for the lets_split keyboard, working in the lets_split_eh folder for now
* Updated eh.c
* More rework of the I2C code, added global flags for split boards.
* Introduced RGB over I2C, having weird edge case issues at the moment though
* Fixed weird I2C edgecase with RGB, although still would like to track down route cause..
* Changed RGB keycodes (static ones) to activate on key-up instead of key-down to elimate weird ghosting issue over I2C
* Lots of changes, mainly externalized the Split keyboard code and added logic for only including when needed.
- Added makefile option "SPLIT_KEYBOARD" that when = yes will include the split keyboard files and custom matrix
- Split keyboard files placed into quantum/split_common/
- Added define option for config files "SPLIT_HAND_PIN" FOr using high/low pin to determine handedness, low = right hand, high = left hand
- Cleaned up split logic for RGB and Backlight so it is only exectuted / included when needed
* Updated documentation for the new makefile options and #defines specific to split keyboards
* Added a bit more info to docs, so people aren't confused
* Modifed Let's Split to use externalized code, also added left and right hand eeprom files to the split_common folder
* Removed some debugging from eh.c
* Small changes to keyboard configs. Also added a default keymap (just a copy of my that_canadian keymap).
* Added a README file to the Let's Split Eh?
* Changed it so RGB static updates are done on key-up ONLY for split boards rather than all boards. Also fixed leftover un-used variable in rgblight.c
* Updated default keymap and my keymap for Let's Split Eh? Updated the comments so it reflects RGB control, and removed audio functions.
* Fixed lets_split_eh not having a default version
* Removed "eh" references from lets_split folder for now
* Took lets_split folder from master to fix travis build errors, weird my local was overriding.
* Changed LAYOUT_ortho_4x12_kc -> LAYOUT_kc_ortho_4x12 to match bakingpy and others
* Removed rules.mk from my lets_split keymap, not needed
* Updated the config_options doc to better explain the usage of "#define SPLIT_HAND_PIN"
* Use string with delay
* Add skipped region to ergodox
* Add send string config
* Use default_layer_state instead of function
* Fully generalize keyboards
* old iris cleanup
* Fix Drashna keymap compile issues
By checking to see if secret.c exists before actually trying to add it
* Remove unnecessary references
* Add 4x12 ortho board
* Update userspace readme for secrets
* Make RGB more modular
* Fix iris keymap, since we don't need the lower left (Function keys)
* Fix includes
* Add Blanks
* Fix Ergodox lower layer
* Add suspend commands
* Add Maltron Layout
* Add additional layouts
* Finish adding gamepad to Iris
* Tweaks to iris gamepag layer
* make gaming layers more friendly
* minor gaming layer tweak
* Add Carplax
* Add modded key timer function
* Cleanup and macro documentation
* Add QMK DFU info
* Add 'old' keymap for 12 LED spare
* Update Pro Micro documentation
* Disable twinkling so it fits in firmware space
* Switch to QMK DFU bootloader, since it's better anyhow
* Write default layer state colors to EEPROM
Since we are writing to EEPROM anyways, and this way, it sticks on reboot
* Fix QMK DFU bootloader options
* More updates for QMK DFU support
* Use matrix scanning hack for startup_user until #3113 gets merged
* Fix indicator light consistency issue
* Add/readd ifdefs to indicators
* Add/readd alt indicator
* Remove RGB Twinkling from Viterbi macro pad
* Fix default layer color detection
* Fix rebase and detection issues
* Cleanup code so it will compile if RGBLIGHT is disabled
* Revert vsode settings
* Use Pragma Once instead of boilerplate code
* initial files for rev 6 with encoder
* music map init, dip scan added
* adds ws2812 driver for arm
* flesh out dip and encoder support
* adds default encoder res
* adds default encoder res
* start muse implementation
* muse working with encoder as control
* flip direction
* try mouse wheel again
* dont break other revs
* dont break other revs
* conditional autio
* pwm ws driver (not working)
* update build includes for chibios
* update ws2812 driver/config
* last commit for glasser code
* working example
* remove rgb for now
* finish up rev6
* working encoder keycodes
* add warnings to planck keymaps about the LAYOUT
* - Fixed DK60 version in config.h
* - Updated dk60 readme with new QMK rules
* - Fixed wording in readme
* Added dbroqua layout for DZ60
I've also updated dz60.h to add "true HHKD" keymap definition (6U
spacebar).
With the default HHKB definition r_alt was not mapped and when I pressed
r_menu it was r_alt.
Regards
* Updated dbroqua layout for HHKB keyboard
Added default configuration and alternate (swap gui/alt keys).
Save user choice in keyboard memory (like plank, thanks for this
feature!).
* Added dbroqua layout for Iris keyboard
* Updated layout and fixed includes
* Turn backlight support on by default
* Correct error on LED backlight support
Turns out, it doesn't work if you don't enable it in rules.mk. Who knew?
* Adds Audio Keycodes to both the feature page and master list
* Re-orders the keycode list, so it's alphabetical (mostly)
* Add additional (missing) sections to the keycode list
* Add and update links in the keycode page
* Add and reorder links in sidebar's keycode section
* integrated Peter Fleury's LCD library for HD44780 LCDs
* fixed typo
* cleanup finished
* add documentation
* added HD44780 documentation
* removed keyboard from .gitmodules
* resolved merge conflict
* removed edit of kira75s rules.mk made by merge
* moved hd44780 to drivers/avr
* Added licence info to hd44780 files
* Added link to hd44780 docs.
@drashna mentioned it'd be good to have a mention of the userspace in
the QMK structure section. Rather than rewrite the docs on userspace, I
chose to link to the existing documentation.
* mitosis:datagrok: improved tenkey layout; changelog + more in README
* mitosis:datagrok enable audio!
* mitosis:datagrok: underscore on right shift, rearrange some symbols
* mitosis:datagrok: add more descriptions to readme
* mitosis:datagrok: abuse space cadet to get equivalent of RSFT_T(KC_UNDS)
Friend was having trouble with their tada since their build environment wasn’t setup. Updated so they could access the links that were listed (old links 404’d)
* default keymap refactor: QMK_KEYBOARD_H include; readability
* Configurator support
* info.json was missing a comma
* Added matrix functions to matrix.c per @drashna
* Moved info.json to rev1 directory
* rev1 info.json metadata update
* Configurator support for ErgoDash rev2
* Moved rev1/ergodash.h to ergodash.h
* Integrate rev2 support into ergodash.h; delete rev2/ergodash.h
* 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
* add hhkb bluetooth functionality (rn42)
pretty much straight from tmk
some minor changes to make things work
* hhkb jp personal keymap
* Revert "hhkb jp personal keymap"
This reverts commit 886713d8bb98572f03110f285706a8140a083892.
* Initial commit for Comet46 firmware
* Update Comet46 README
* Add readme to satt keymap of comet46
* Add default keymap for Comet46
* Fix broken link in readme
* Delete redundant includes
* Modify default keymap & fix LAYOUT macro
* Modify satt keymap of Comet46
* Add H87a keymap and info
* Create readme.md
* Add h87a .json for kbfirmware.com use
* Update readme.md
* Update readme.md
* Update h87a files
* Delete Makefile
* Update readme.md
* Delete desktop.ini
* update files to match new QMK framework
* Update files to match new QMK structure
* Update files to match new QMK structure
* add layout name information
* Add info.json
* update keymap to support layout_all
* update keymap to support layout_all
* update rules.mk to fix filesize
* Update readme.md
* Update config.h
* Update readme.md
* Update config.h
* Update config.h
Add "define CONFIG_H and include "config_common.h" back to file
* Added basic MxSS support
* Fixed split RSHFT for ISO layouts
* Updated readme.md for MxSS
* Added initial support for individual control of front RGB LEDs
* Changed RGBLED color selection to work using hue and saturation rather than RGB
Added code for LED state change on layer change
* Avoid needing an entire 8 bits to store the brightness value
* Added custom keycodes, along with their handlers
* Added EEPROM storage for front LED config
* Fixed up ability to use QMK Configurator and updated readme.md
* Applied suggested changes from pull request: https://github.com/standard/standard/issues/452
Updated name in license descriptions
Updated layouts to snake case
Corrected mistakes in info.json
Updated layer_colors to a weak attributed array in mxss.c
* Defined a new safe range for custom keycodes in keymap.c
* Fixed up issues with front LED
Fixed LEDs not always updating in indicator mode
Added support for the other RGBLIGHT modes in RGB mode
* Attempted fix for ISO layouts for QMK configurator
* Added basic MxSS support
* Fixed split RSHFT for ISO layouts
* Updated readme.md for MxSS
* Added initial support for individual control of front RGB LEDs
* Changed RGBLED color selection to work using hue and saturation rather than RGB
Added code for LED state change on layer change
* Avoid needing an entire 8 bits to store the brightness value
* Added custom keycodes, along with their handlers
* Added EEPROM storage for front LED config
* Fixed up ability to use QMK Configurator and updated readme.md
* Applied suggested changes from pull request: https://github.com/standard/standard/issues/452
Updated name in license descriptions
Updated layouts to snake case
Corrected mistakes in info.json
Updated layer_colors to a weak attributed array in mxss.c
* Defined a new safe range for custom keycodes in keymap.c
If you run `brew install avr-gcc`, you get a version that has
compatibility issues with LUFA. I updated the getting started guide for
osx, the qmk_install setup script, and added a section to the FAQ for
folks like me who accidentally updated avr-gcc past 7.
* preliminary Gray COD67 checkin
* Get part of the switch matrix prepped
* finish switch matrix
* mock the pins and keymap for now
* add keymap fixes
* update readme with flashing instructions
* keymap fix
* Add more flashing and notes info to readme
* remove un needed file
* fix comments
* add QMK Configurator Support
* Configurator support
* Add LAYOUTS = planck_mit to rules.mk
* Disable Tap Dance at the keyboard level
* Keymap refactor: QMK_KEYBOARD_H; enable Tap Dance for default keymap
* Add keymaps/default/rules.mk to enable Tap Dance
* Reverse the addition of config.h in keyboards/tetris/keymaps/default/
* Initial port of AL1 Keyboard from Triangle Labs
* Change REPLACE WITH YOUR NAME and some readme changes
* More readme change to indicate Group Buy Link
* Give Triangle Lab credit
* remove pins from config.h and rely on matrix.c
* Add QMK Configurator support
* new matrix for LE(Last Edition) E6V2
* Update pin outs for the new version of the PCB
* putting in some placeholders for now
* Trying to get e6v2/oe:default to compile
* put rules.mk in the right directory
* Add and update readme files
* move info.json to oe directory
* Update LE directory
* rename keyboard name
* Add QMK Configurator Support
At this time, ths only covers the ALL case and allows people to use
the configurator to generate their keymaps. More work will need
to be done.
* Refactor KEYMAP to LAYOUT standards
- Change KEYMAP to LAYOUT_ortho
- Added a new LAYOUT called LAYOUT_numpad
* Use the new LAYOUT_numpad macro
* Add QMK Configurator support
* Change LAYOUT names as per code review
* Change positioning of keys in the matrix
* fix compile issue
* initial support for kc60se extracted from Blake Lewis
* add my name to the list
* remove breathing as the backlight pin is not a PWM one
* use standard LAYOUT macros such as 60_ansi and 60_ansi_split_bs_rshift
* Make the base LAYOUT more sensible and add Configurator support
* add atmel-dfu bootloader
* Adding Rama M10-A Macropad
* ch-ch-ch changes...
* Major overhaul based on SMT's keymap.
* more changes.
* Moved the FKeys to the ADJUST layer.
* More rearranging.
* Alias in Atreus62 keymap to make it more legible
Added config.h to fix tapping_term issue for Caps Lock key in OSX
* Added OrthoDox layout.
* More layout changes.
* Fixing things with the keyboard.
* Finishing touches.
Set left-hand master in config.h
Embedded the arrow keys in keymap.c
* Revised keymap making this easier to use.
* additions and changes.
* changes to various keymaps.
* Minor adjustments to OrthoDox layout.
* Added Eco keymap. Updated Let's Split keymap.
* Added gherkin
* Removed my M10A keymap
* Planck Keymap Updates
Updated my Planck keymap and created a simple keymap for Seph's Preonic.
* Added readme
* readme fixes
* Update readme.md
more clarification
* Keymap Tweaks
Removed the Power button setting from the keymap. It was in a
horrible location. I'll work on getting it setup somewhere else
sometime later.
* Added Readme
I finally got around to adding a readme to this keymap. I've also added minor changes to the layout.
* Fixed Keymap Error
* Fixed Readme
* adding iris and levinson keymaps
* Tweaks to keymap
* added youngJZ keymap
* Changes to keymap
Added a readme.md
* Levinson changes
Added the readme.md and rules.mk files.
Configured RGB underglow and backlighting.
* fixed readme
* changes to keymaps
* Updated keymap
* Updated readme.md
* Updated Readme (again)
* Updated Readme
Fixed formatting. Again.
* Updated readme
This is the last readme update for this keyboard update. I hope.
* Added Contra keymap
* Kinesis Keymap Update
* Updated Keymaps
I've updated my Kinesis (Stapelberg) layout and my Clueboard 66 layout.
I've also updated my Kinesis Readme.
* Clueboard Keymap update
Added media keys to my Clueboard 66 Rev2 layout.
* Added keymap
Added Minidox keymap & rules.
Added user function to Let's Split keymap that turns off the red
LEDs on the Pro Micros.
* New Zen keymap
Added Zen keyboard to my list of keyboards, so had to generate a new
keymap for it.
Also adding some changes to my MiniDox keymap and config.h, as well
as my Levinson's config.h.
The config.h file changes enable ee_hands.
* A few changes for useability
I made a few changes to the Minidox keymap to see if I can't make it more useable.
I'm also working on streamlining the Zen keyboard keymap to reduce layers.
* Re-vamped Iris keymap.
* changes
* minor keymap change
This was a minor keymap change to use mod_tap for the backspace key:
ALT when held, BSPC when tapped.
* Added Fourier keymap
* Keymap Cleanup
Moved KC_ESC to KC_CAPS, and changed KC_ESC to KC_GRV
This is because of muscle memory, I kept hitting ESC when trying to hit TAB.
* Keymap Adjustments
Swapped Caps/Esc, put Caps in Raise/Lower layers, put Grv in normal
Esc position. Adjusted the readme.md to reflect these changes.
* minor tweaks
Added code to disable red ProMicro LEDs after flashing.
* Clean-up
* Corrections to keymap.
Fixed a foul-up in the Zen keymap where the lctrl was where the LOWER
should have been.
* Changes to make this fall in line with the new Layout features
* Moving to LAYOUTs for 4x12 boards
* fixed config.h file
* standardization changes
* Reverted Atreus62 keymap to LAYOUT format
* Switch Preonic and Nyquist to ortho_5x12
* Corrections to config.h
* config.h file tweaks
* config.h file tweaks
* Added missing integers.
* Updated Seph's keymap to LAYOUT standard.
* Keymap tweaks & changes
* Bringing keymap up to LAYOUT standard
* Trying to get LEDs working
* Fixes for Stapelberg
Updated my keymap to confirm to the new LAYOUT standard.
Updated the stapelberg.h to reflect this LAYOUT standard.
Updated the stapelberg.c files to hopefully get the LEDs working.
* Getting closer to Kinesis LED functionality.
* NKRO Fix
Disabled NKRO for VUSB ortho_5x12 boards
* Hardware update
Backlight enable
Change pin
Add 2keys (68→70)
* change readme
* support rev1
change keymap path
* move ergodash.h
* sync the left and right backlight led
matrix.c is same as iris keyboad
backlight breathing is unstable, so it comment out
* disabled commands
* dual spacefn, -= match to amj40 layout
-= was killing my muscle memory, so I moved it. Don't have any other
plans for kl though, so leaving them there as well.
* now helix led_test local rgblight.[ch] not use. remove.
* greatly simplify keyboards/helix/rev2/keymaps/led_test/keymap.c
Helix keymap 'led_test' use modified default/keymap.c
* Add Dynamic Macro Toggle using Tap Dance
One Tap -> Play Macro 1
Two Taps -> Stop Recording
Three Taps -> Start Recording Macro 1
* Move feature from default to dyn_macro_tap_dance
* Convert 4 space tabs to 2 space tabs
Follows qmk style guidelines
* Addition of hard brigtness limit for RGB_Matrix
- Added a define "RGB_MATRIX_MAXIMUM_BRIGHTNESS" to enable hard limiting the maximum brightness for rgb_matrix
- Used the above define to limit the maximum brigthness of HS60 for better stability
* Added docs for new rgb_matrix define
* Addition of check for maximum brightness
* Add mbsurfer keymap for DeltaSplit75 with ANSI split backspace
* Update mbsurfer DeltaSplit75 keymap to include right hand arrow cluster
* Update mbsurfer DS75 keymap, move volume down to be symmetrical
* Add readme to Mbsurfer DS75 keymap
* Fix Mbsurfer DS75 keymap image
* Clean up mbsurfer DeltaSplit75 keymap, add layer overview comments
* Fix volume down and add mute to fn layer
* Restructure kbd75 to support multiple revs
* add rev2 files
* fix config comments
* try and avoid duplicate code for LAYOUT macros
* keep the same layouts for rev2 for info.json
* Add QMK Configurator support for the numpad layout
* update readme to talk about rev2
* Clean up SEND_STRING keycodes and add media keys
* Remove stray define
* Add missing SEND_STRING keycodes for completeness
Also, add KC_EJCT to the keycode references
* Create keymap.c
Modified the default to be way more like a pok3r, already clear that it needs a better ctrl location.
* Delete keymap.c
* Create keymap.c
Modified the default keymap to be more like a pok3r, clearly needs a better ctrl location and probably some other tweaks.
* Add files via upload
* Update keymap.c
Parenthesis correction.
* Parenthetical cleanup
Forgot one...
* Mods and numpad; cleanup
Rework mods and numpad layer, remove superfluous declarations
* comment define devlayer
* Create readme.md
Background and intention.
* Updated to fit example
* Update readme.md
* Update rules.mk
* Update config.h
* Updated includes
Replaced:
#include "iris.h"
#include "action_layer.h"
#include "eeconfig.h"
With:
#include QMK_KEYBOARD_H
* Update rules.mk
Removed RGB enable declarations
* Update rules.mk
* Update keymap.c
Spaced out on MINS and EQL.
* Update rules.mk
Removed unnecessary block.
* Remove the RGB call
Make would fail because of the RGB call that wasn't anywhere but here, cleaned that up from the default config.
* Update keymap.c
Added [ and ] since I'd forgotten them originally...
* slight tweaks to xd75 keymap
* update to config.h to remove undef of solenoid active
* code organization for userspace
* updates to userspace and keymaps
* add rgb to userspace and lets split
* add conditional around rgb functions in userpsace
* move rgb layer changes into layer_state_set_user
* Add Plover layer to DCompact from Planck default
* Fix up and update DCompact READMEs
* Add missing Steno features
* Switch flags to re-enable extrakeys
* Fix compilation bug in Chimera layout
* Update config.h
Matrix pinout updated to current revision.
* Add updated matrix, define RGB pin
Matrix updated to current pinout, pin for WS2812 defined.
* Update config.h
Matrix rearrangement due to change in Teensy2.0++ position
* Update readme.md
Added maintainer info, updated controller info
* Add mbsurfer keymap for DeltaSplit75 with ANSI split backspace
* Update mbsurfer DeltaSplit75 keymap to include right hand arrow cluster
* Update mbsurfer DS75 keymap, move volume down to be symmetrical
* Add readme to Mbsurfer DS75 keymap
* Fix Mbsurfer DS75 keymap image
* Adjust TAPPING_TERM to make accessing the nav layer easier
* JJ40: Add RESET key to lower layer.
* Disable all lock LEDs on "oscillope" keymap.
I'm not 100% sure why yet, but attempting to turn on a lock LED on my v1
JJ40 PCB causes the PCB to become unresponsive. The easy fix is to just
disable all of the lock LEDs, since I don't have any LEDs on my keyboard
anyway.
Many thanks to u/wanleg on Reddit for suggesting this fix: https://www.reddit.com/r/olkb/comments/8en8f1/strange_caps_lock_behavior/e06kcaf/
* DactylManuform: Updating dvorak keymap
* Changed NAV and NUM layers to LOWER and RAISE
* Removed Mod+Key form RAISE and LOWER keys to be used as layer togglers exclusively
* Added missing keys to LOWER layers
* DactylManuform: fixed bugs in keyboard config file
* DactylManuform: Change default mouse config
The default mouse config parameters are slow and not very user friendly, this commit overrides the default
values.
wq
Signed-off-by: Sameeh Jubran <sameeh.j@gmail.com>
* Dactylmanuform: Update default keymap (qwerty) to match dvorak's
Recently devorak's layout went through some changes for changing layer toggles behavior,
adding missing keys, and fix minor bugs, this commit introduces these changes to the default keymap.
Signed-off-by: Sameeh Jubran <sameeh.j@gmail.com>
* Dactylmanuform: Add permissive hold support
Signed-off-by: Sameeh Jubran <sameeh.j@gmail.com>
* DactylManuform: Updating documentation
* Adding a picture of the keyboard
* Adding keymaps pictures
* Adding missing EEPROM files for EE_HANDS
flashing these before firmware will let the
user use either hand as master without reflashing
Signed-off-by: 20lives <lior@dotcore.co.il>
* Added files for my new layout.
* Added layout template
* Qwerty layout done
* Qwerty layout done
* Test commit
* Qwerty, colemak e dvorak layouts done.
* Added templates for extra layers
* Added templates for extra layers
* Small adjustments on function layer
* Minor updates
* Minor updates
* daily update
* added my dz60 layout
* added my niu mini layout
* made the suggested corrections
* Clone default chimera-o layout
* Make changes for base layer
* Enable mouse suppport flag
* Implement majority of DAD layout
* Add mouse movement keys
* Fine tune mouse control and fix tap toggle
* Fix mouse button locations
* Set adpater LED colors for layers
* Increase responsiveness of key taps
* Update layout for thumb comfort
* Rename layout and add README
* Add comments to keymap
* Implement DCompact layout for Planck
* Copy over DCompact README to planck
* Fix up odds and ends for Planck
* Readme cleanup
* Refactor KEYMAP to LAYOUT
* Configurator support
* Readme cleanup
Didn't spot that the modified lines were formatted as a list the first time.
* 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
* updated normacos layout and fixed some readme typos
* removed leftover merge diff
* added waits to macros that make use of SEND_STRING
* fixed wrong waits on macros that use SEND_STRING
* normalized macro comments after adding waits
* Added Modular keyboards L,R and NUM
Created code modules for the 3 modules of the modular keyboard.
Original idea by MechboardsUK. Uses i2c implementation similar to lets
split
* Remove modular from master
This is to fix incorrect branching
* fixed bootloader makefile
- Echo -e does not behave coorectly on mac
- Replaced with equivilant printf statements
* quick typo fix
* started work on halfkeyboard
* update to keymap
* halfkey layouts complete for dvorak and qwerty
* added plover layout to halfkeyboard mapping
* fixed error in dvorak layout right hand
* fixed error in dvorak layout right hand, comments updated
* thing
* added minus and equals to normal layouts
* added minus and equals to normal layouts
* adde visualizer matching halfkeyboard mappings
* adde visualizer matching halfkeyboard mappings
* updated keymaps for mirror handedness functionality for all layers. Also added visualizer code for distinct color for each layer, and LCD text displaying the current layer.
* had a KC_TILD where should have had KC_GRAV
* its spelled KC_GRAVE
* mouskeys and some visualizer work.
* added LED backlight visuals
* trying to get visualizer working
* Move lufa descriptor to protocol/usb_descriptor
* Try to compile usb_descriptor on ChibiOS
* Add lufa_utils for ChibiOS
Lufa USB descriptors for ChibiOS
* More lufa_util compatibility fixes
* First compiling version of shared USB descriptor
* Send the usb descriptors
* Fix the CONSOLE output on ChibiOS
* Add errors for unsupported interfaces
* Enable support for vitual serial port USB descriptors
* Implement virtual serial port for ChibiOS
* Cleanup the lufa_utils
Use the default lufa header files
* Add raw hid support for ChibiOS
This is completely untested
* Enable midi compilation on ChibiOS
* Move midi functionality out of lufa.c
* Don't register sysex callback when not needed
* ChibiOS compilation fixes
* Update ChibiOS submodule
* Fix the Midi USB descriptor
It didn't work properly when both Midi and Virtual serial port was enabled.
* Add MIDI support for ChibiOS
* Fix USB descriptor strings on ChibiOS
* Use serial usb driver for raw hid
* Generalize the ChibiOS stream like drivers
This makes the initialization much more simple and eliminates a lot of
the code duplication.
* Convert console output to chibios stream driver
* Fixes for ChibiOS update
* Update the ChibiOS contrib submodule
To include the usb data toggle synchronization fixes
* Fix duplicate reset enumeration on ChibiOS
* Add missing include
* Add number of endpoints check for ChibiOS
* Enable serial USB driver on all keyboards
* Add missing includes when API is enabled withot midi
* Add another missing inlcude
* consolidated my custom animations into visualizer.c in my keymap directory
* LED backlight keys animation KITT scanner
* moved my custom rules.mk to my keymap folder
* undoing changes i shouldn't have done
* more fixes
* updated comments on the visulizer code
* steno keys added to plover layout
* updated halfkeyboard rules to allow steno mode
* adding my stuff back after hard reset
* added a plover layout back in for androud steno app
* fixed layer toggle typo
* merged again
* visualizer decided to have a conflict again. fixed.
* keymap change to add mouse keys and put layer switching on shortcuts layer
* made the ergodox LEDs scan left to right and back again
* visualizer work
* KITTSCANNER finally
* fixed right hand shortcuts layer and removed handedness switching for base layer so jump in gaming works corrrectly
* added another sweep that goes full on over both boards then full off in both directions
* added function key layer and cleaned up some layer switching
* Add SX60
* Add config maps and layouts as well as readmes.
* cleanup and fixes
* correct readme
* add missing closing commenty tag
* Changing includes to QMK_KEYBOARD_H
* Update settings.json
Remove config change that was added automatically by vscode.
* Update readme.md
fix readme formatting
* 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
* add Freggy keymap
* adjust the delay of serial.c
* change readme
* renumber _ADJUST for shrink program size
* Add suspend functions
* Disable RGB code if it's disabled
* Add suspend code to ChibiOS for future compatibility
* 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 keyboard init stuff for separate PR
* Update readme.md
updated links, hope those are the correct ones
* planck premek - left thumb shift
* middleclick key
* mod tap thumb-shift, space
* update layout description
* Port my keymap to QMK
* Add Percent Canoe keyboard
* Fix row of nonus backslash
* Update info.json to be correct for canoe
* fix alignment
* Use qmk shortcuts rather than tmk functions
* Move over first macro
* Move rest of macros over
* clean up unused functions
* Move files to userspace for HHKB
* Add keymaps for hhkb
* Change LAYOUT_ISO to LAYOUT_iso
* Remove bootloader key in info.json
* Remove tilde remap from Karabiner
* Add country_iso_alpha2_code to macros
* Add my keymap for canoe
* Add layer colour indicator
* Fix bad rebase
* Fix naming of keymap from rebase
* Add GRV to function layer
* Fix keymap to use new LAYOUT_JP
* Update keymaps to use process_record_*
rather than action functions
* Update hhkb imports to be just what is needed
* Update whitefox to use LAYOUT macro instead of KEYMAP
* Remove redundant imports from user definition
* Move TAPPING_TERM to config.h
* Use layer change events to change RGB LED colour
* temp
* Fix layer switching to iPad on HHKB
* Fix Canoe pictures
* modifying fortitude for working
* add accurate keymap
* backlight fix
* Fix slave LED Backlight
* Add readme.md
* modified readme.md
* Fixed make error
* Commit including suggestions
* Add dvorak and colemak layout and some fix
* Optimize secrets code
* Orthodox tweaks
* rules.mk features
* Minor cleanup
* Revert mod bits
* Force Hold breaks One Shot Tap Toggle
* Cleanup
* Moke keymaps more consistent
* minor ergodox tweak
* More OSM for the Orthodox
* Cleanup of userspace
* Toggle Secrets
* Add hidden process record for super secret macros
* Make sure secret macros always compiles
* finish up making them super secret
* Add ColinTA's rgb twinkle as WIP
* Optimize RGB Twinkling for typing
Also, tweak RGB indicators.
AND WTF, I HAVE NO IDEA WHY THE INDICATORS ONLY WORK AS IS. The logical method for getting them working doesn't ... and it's beyond bizarre
* Make console logging more configurable
* Indicator travisty
* Clean up userspace rgb code
* Optimize RGB Twinking to work on default layer only, and to base it's color on the curent hue
* Eff it... rgblight_sethsv_at runs at every matrix scan
* RGB Twinkle cleanup
* Update Iris code for new board
* Move RGB Indicator and RGB Twinkle into userspace
* Move RGB Indicator code to rgb_stuff.c
* Major cleanup of RGB Code in userspace
* Additional cleanup of RGB code in userspace
* Use noeeprom functions to save my boards!
* Enable RGB Sleep on all boards now
* Add old iris board
* tapping tweak
* Use byte 19 for eeprom to prepare for possible merge of eeconfig function pr
* Add code to fix default layer after eeprom reset
* Put in my keymaps
* Fixed all but weird lets split issue
* Organized and tried to trobleshoot lets split
* Organized and tried to trobleshoot lets split
* Added bbaserdem keymaps
* Added bbaserdem keymaps
* Fixed stuff
* FIxed a filename error
* add not-so-minidox handwire keyboard
* corrected keymap
* multiple adjustments to not_so_minidox keyboard
* remove I2C master left define
* update default layer set function
* move solenoid code into userspace
* minor adjustments to config.h
* update keymaps to utilize userspace
* move features and config to userspace, correct build issue
* correct solenoid pin
* adjust defaults for solenoid pin and enable
* default solenoid to on for not_so_minidox
* disable RGBLIGHT_SLEEP for xd75
* tweaking solenoid enable/disable in userspace and keymaps
* preonic-keymap: kuatsure keymap
* preonic-kuatsure: move arrows and braces and stuffs
* preonic-kuatsure: give more time for leader
* preonic-kuatsure: move _ to lower o
* preonic-kuatsure: tap dance space to enter
* preonic-kuatsure: move vol buttons around
conflicted with kaleidoscope file navigation
* preonic-kuatsure: lower+spc = esc
* preonic-kuatsure: add lock key & remove led stuff
* preonic-kuatsure: little bit of tmux leadering
* preonic-kuatsure: remove colemak and dvorak
* preonic-kuatsure: remove lock key and tap dance
* preonic-kuatsure: lower space -> enter -- raise space -> esc
* preonice-kuatsure: move tmux stuff to homerow keys
* preonic-kuatsure: set tmux prefix to a function
* preonic-kuatsure: hello game layers
* preonic-kuatsure: instead of zelda, ffvii for game mode :)
* preonic-kuatsure: mild changes after playing games to game modes
* preonice-kuatsure: omg comma dangles and spaces in switch!
* preonic-kuatsure: kinda make lower a shift on special characters
* preonic-kuatsure: I don't use these
* preonic-kuatsure: move vol- to the begining of media row
* preonic-kuatsure: more tmux leader stuff ( pane 3 & last pane )
* preonic-kuatsure: abstract out tmux pane zooming
* preonic-kuatsure: abstract pane switch
* preonic-kuatsure: game_mod is carries over lower positions
starting to wonder if I need game_mod ... lol
* preonic-kuatsure: switch lwr/rse esc / ent
* preonic-kuatsure: add leaders for window switching
* preonic-kuatsure: major pruning of adjust layer
* preonic-kuatsure: major rework on raise layer
* preonic-kuatsure: game mods f layer is raise now
* user-kuatsure: hello
* various-kuatsure: use layout format + globalize querty / number keys
* preonic-kuatsure: don't use tap dance anymore
* various-kuatsure: code formatting
* various-kuatsure: add function layer vars
* preonic-kuatsure: moar formatting
* preonic-kuatsure: add home / end keys
Added rules.mk for the infinity
* Moved tap dance enums to gordon.h
* Moved tap dance aliases to gordon.h
Moved TD to user space
* Added config file with preventing mods sticking
* Added a few keys to keymap
* Feat: Create personal ergodox keymap
* FEAT: Update bpruitt-goddard keymap with custom layout
* Fix: Remove unused pieces from bpruitt-goddard keyboard
* Feat: Add QWERTY layer to bpruitt-goddard ergodox keymap
* Refactor: Remove unused layers from bpruitt-goddard keymap
* Fix: Update base layer for bpruitt-goddard keymap
* Fix: Remove un-reachable key combo from FN layer
* Fix: Rename FN layer to numpad layer
* Feat: Create one-shot modifier layer for mac os use
* Doc: Update readme to reflect my keymap
* Feat: Add mac desktop space switching
* feat: Update keymap layers to use ergodox pretty format
* And and fix _noeeprom functions to many of the RGB Underglow functions
* Many functions are unnecessarily calling the eeprom write code. The toggle/enable is command is especially guilty of this, as it writes to EEPROM 3 times. But rgb mode writes twice, every time it's called. And init resets the rgb eeprom range and then writes back to it twice!
* Fixed the rgblight_sethsv_noeeprom to work as expected, by moving a lot of the code to a helper function.
* Added a noeeprom function for mode, enable, disable, and toggle functions. (didn't bother for increase/decrease stuff, and didn't add new keycodes)
* Add to predefined colors list
* Add new functions to manual/docs
* Update RGB Sleep feature to use _noeeprom
Because that's exactly what it should be doing, actually!
* Add Percent Canoe keyboard
* Fix row of nonus backslash
* Update info.json to be correct for canoe
* Change LAYOUT_ISO to LAYOUT_iso
* Remove bootloader key in info.json
* Update default Nyquist revision
* LED slave fix
* Sync changes from lets_split
* Add needed check for debouncing
* Remove line that was setting PD2 pin and interfering with use of that pin
* Add backlight key to keymap
* Refactor for AMJ Pad
* Configurator update for AMJ Pad
* Add hardware agnostic layouts numpad_6x4 and ortho_6x4
* Add agnostic layouts to rules.mk
* Refactor AMJ Pad to use new hardware agnostic layouts
* Refresh & improve leader documentation page
- register_code/unregister_code are not the recommanded way to do macro.
- Provide some details I wish I had found when first used the leader
functionality.
* Add old way to use macro.
* Initial commit of guidoism
* created movement layer
* movement layer works!
* removed unnecessary layers
* moved enter key up and recreated caps lock
* Added num pad
* Fix dead link to USB keycodes doc
Link was dead and the fresher version I could find on usb.org is still older than this one.
Thus, WaybackMachine seems the best option.
* Fix dead link to USB keycodes doc, with 2 options
Give the WaybackMachine link (fresher and for reference of the content of the original link) and the usb.org one (older)
* Fix serial split for BFO9000
* Fix serial split for DeltaSplit75
* Fix serial split for Helix
* Fix serial split for MiniDox
* Fix serial split for Viterbi
* Revert "Fix serial split for Helix" since it's super complex
This reverts commit 72538df105ba6d5fe6915773a20c509f2a47785d.
We'll let the helix owner fix this issue, or dive into the code later
Wait for 1 second before turning on RGB to get debug messages on
console.
- configure HSV color, on a brand new pro micro the default values are
0, 0, 0
* Refactor for Alps64
* Reverts deletion of LAYOUT_kc macro; renames LAYOUT_standard_60 to LAYOUT_60_ansi
* Add LAYOUTS = 60_ansi to rules.mk
* Rename LAYOUT_standard_60 to LAYOUT_60_ansi in info.json
* Adds basic support for u/flehrad's bigswitch pcb
- also adds support for OSX Eject/Power
The function of this key depends on the version of OSX and if you
have physical media. For a macbook pro 2017 holding this key down
brings up the shutdown dialog. If you wrap it in LCTL and LSFT the
screenlock turns on immediately.
* Switch to Layout Macro
- add a code for OSX Sleep
* Add a README
* Turn on RGB by default
* Add info.json
* Address comments by @drashna
* Only define Eject in keymap
* Account for backlight enabled flag when passing backlight level to slave
* Add BL_TOGG to keymap for testing
* Apply backlight fix to Iris
* Port I2C LED backlight control from Iris to Levinson
* A personal layout for the orthodox keyboard
* Added layout readme.md
* Consolidated inclues with #include QMK_KEYBOARD_H
* Moved layer tones setup to config.h
* Replace persistent_default_layer_set calls with set_single_persistent_default_layer
* Simplified the process_record_user function using layer_state_set_user function and MO() to set the lower, raise, nav and media layers
* Removed AUDIO_ENABLE ifdefs and persistent_default_layer_set() as they are not needed any more
* Added Modular keyboards L,R and NUM
Created code modules for the 3 modules of the modular keyboard.
Original idea by MechboardsUK. Uses i2c implementation similar to lets
split
* Remove modular from master
This is to fix incorrect branching
* HS60 ANSI update
* HS60 ANSI update
* preliminary check in of Kira75
* Layout done
* make an appropriate keymap and fix layout commas
* formatting changes and housekeeping
* add info.json contents for QMK Configurator support
* add RGB underglow support
* add support for caps and num lock leds
* community layout support for eagle_viper v2 and remove mechmerlin keymap dir
* community layout support for eagle_viper v2 and remove mechmerlin keymap dir
* Change to QMK_KEYBOARD_H and remove merlin keymap in favor of cmmunity layouts
* community layout support 60_ansi
* community layout support for 60_ansi
* Adding Rama M10-A Macropad
* ch-ch-ch changes...
* Major overhaul based on SMT's keymap.
* more changes.
* Moved the FKeys to the ADJUST layer.
* More rearranging.
* Alias in Atreus62 keymap to make it more legible
Added config.h to fix tapping_term issue for Caps Lock key in OSX
* Added OrthoDox layout.
* More layout changes.
* Fixing things with the keyboard.
* Finishing touches.
Set left-hand master in config.h
Embedded the arrow keys in keymap.c
* Revised keymap making this easier to use.
* additions and changes.
* changes to various keymaps.
* Minor adjustments to OrthoDox layout.
* Added Eco keymap. Updated Let's Split keymap.
* Added gherkin
* Removed my M10A keymap
* Planck Keymap Updates
Updated my Planck keymap and created a simple keymap for Seph's Preonic.
* Added readme
* readme fixes
* Update readme.md
more clarification
* Keymap Tweaks
Removed the Power button setting from the keymap. It was in a
horrible location. I'll work on getting it setup somewhere else
sometime later.
* Added Readme
I finally got around to adding a readme to this keymap. I've also added minor changes to the layout.
* Fixed Keymap Error
* Fixed Readme
* adding iris and levinson keymaps
* Tweaks to keymap
* added youngJZ keymap
* Changes to keymap
Added a readme.md
* Levinson changes
Added the readme.md and rules.mk files.
Configured RGB underglow and backlighting.
* fixed readme
* changes to keymaps
* Updated keymap
* Updated readme.md
* Updated Readme (again)
* Updated Readme
Fixed formatting. Again.
* Updated readme
This is the last readme update for this keyboard update. I hope.
* Added Contra keymap
* Kinesis Keymap Update
* Updated Keymaps
I've updated my Kinesis (Stapelberg) layout and my Clueboard 66 layout.
I've also updated my Kinesis Readme.
* Clueboard Keymap update
Added media keys to my Clueboard 66 Rev2 layout.
* Added keymap
Added Minidox keymap & rules.
Added user function to Let's Split keymap that turns off the red
LEDs on the Pro Micros.
* New Zen keymap
Added Zen keyboard to my list of keyboards, so had to generate a new
keymap for it.
Also adding some changes to my MiniDox keymap and config.h, as well
as my Levinson's config.h.
The config.h file changes enable ee_hands.
* A few changes for useability
I made a few changes to the Minidox keymap to see if I can't make it more useable.
I'm also working on streamlining the Zen keyboard keymap to reduce layers.
* Re-vamped Iris keymap.
* changes
* minor keymap change
This was a minor keymap change to use mod_tap for the backspace key:
ALT when held, BSPC when tapped.
* Added Fourier keymap
* Keymap Cleanup
Moved KC_ESC to KC_CAPS, and changed KC_ESC to KC_GRV
This is because of muscle memory, I kept hitting ESC when trying to hit TAB.
* Keymap Adjustments
Swapped Caps/Esc, put Caps in Raise/Lower layers, put Grv in normal
Esc position. Adjusted the readme.md to reflect these changes.
* minor tweaks
Added code to disable red ProMicro LEDs after flashing.
* Clean-up
* Corrections to keymap.
Fixed a foul-up in the Zen keymap where the lctrl was where the LOWER
should have been.
* Changes to make this fall in line with the new Layout features
* Moving to LAYOUTs for 4x12 boards
* fixed config.h file
* standardization changes
* Reverted Atreus62 keymap to LAYOUT format
* Switch Preonic and Nyquist to ortho_5x12
* Corrections to config.h
* config.h file tweaks
* config.h file tweaks
* More Iris Tweaks
* Mess with iris arrow keys
* Massive layout overhaul to make everything more OLKB
* Additional tweaks
* Cleanup Userspace
Remove unused layer code, and properly set userspace eeprom structure.
* EEPROM stuff
* Only use indicators if layer indication is enabled
* Iris and Orthodox Tweaks (Status Indicators)
* Additional tweaks to finish tri layer conversion
* Disable ProMicro ligths globally
* Add Pro Micro hacking info
* Successfully get mod indication working on thumb clusters
* Enable printing when console is enabled
* Make Modifier Indicator lights more modular
* Keymap cleanup
* Tapping test changes
* Cleanup and minor tweaks
* Added Modular keyboards L,R and NUM
Created code modules for the 3 modules of the modular keyboard.
Original idea by MechboardsUK. Uses i2c implementation similar to lets
split
* Remove modular from master
This is to fix incorrect branching
* HS60 initial rgb port
porting HS60 to master rgb code
* HS60 fixes
* Hs60 rgb changes
* Cleanup for HS60 ISO
* More HS60 cleanup
* Update config.h
* More Cleanup for HS60
* HS60 modifications to work with configurator
* More HS60 cleanup
* Remove userspace layouts on HS60
* Update rules.mk
* HS60 bootloader change
* Added Modular keyboards L,R and NUM
Created code modules for the 3 modules of the modular keyboard.
Original idea by MechboardsUK. Uses i2c implementation similar to lets
split
* Remove modular from master
This is to fix incorrect branching
* General fixes for RGB_matrix
- Complited speed support for all effects
- Fixed raindrop effects to initialized after toggle
- Fixed raindrop effects to use all available LEDs
- Fixed effect step reverse function
- Moved RGB_MATRIX_SOLID_REACTIVE under correct flag
* Documentation update for RGBmatrix
* More doc updates
* I2C library can now retry if it has failed
- Replaced the original TWIlib by LFKeyboard's modified version
- Allows for an extra argument on TWITransmitData, if blocking is set to 1 function will retry to transmit on failure. Good for noisy boards.
* RGB Matrix, use alternative I2C library
TWIlib seems to be hanging for me sometimes probably due to ISR routine. I have used i2c_master as a good alternative.
Note: this commit is for Wilba6582 to verify before merge
* Update rgb_matrix.c
* RGB matrix cleanup
- Remove TWIlib
* Add support for Swap Hands feature to Orthodox and Iris
* Fix hag's iris keymap to use LAYOUT properly
* Fix Swedish's Iris Keymap
* Fix Drashna's Orthodox keymaps, because he's an idiot
Many a times one would want to use multiple modifiers with the same key,
preferably without having to hold anything, like `Ctrl+Shift+C` or
`Ctrl+Shift+V` to copy/paste in GNOME Terminal. To make this possible, we need
to be able to chain one-shot modifiers, so that we can have multiple of them
active at the same time.
The easiest way to accomplish this is that whenever we activate a one-shot
modifier, we apply it on top of the existing set, instead of re-setting the
state. When deactivating, either due to an interrupt, or due to a timeout, we
deactivate all oneshots anyway, so the clearing part is covered. When we turn
the one-shot modifier into a toggle, that will also clear all one-shot modifiers
first, so we covered that case too.
Fixes#2796, #1580, and #856.
Signed-off-by: Gergely Nagy <qmk@gergo.csillger.hu>
* FORK!
* WIP - just how i like it
* empty
* more movement
* mouse keys
* more vimminess
* append/insert shift
* WIP - vim macros
* blocked out layer below in cmd mode.
also, about to restart my cmd approach.
* WIP - new vim layer
ripoff of the ergodox one, but rewritten as a state machine.
* debugged some, got key repeat working
* moooar coverage
* moooar coverage
* regular vis mode
* basically done with basics.
* some refactoring
- common movement sequences into helper function
- added some rgb controls
* modkey passthru feature
* stdized on cmd-left/right instead of ctrl-a/e
sadly. as there's no reliable shift-ctrl-e
* indicator lights
* moved vim layer into userspace
* cleaned up some yanking edge cases
* docs and some tweaks to layerescapes
* updated/added license strings
* updated comments
* moved config changes to keymap
* spurious changes removed
* cleanup pass, HT drashna for suggestions
- used _keymap() pattern to better modularize event processing in userspace
- made some static things static
- removed unused function
- improved reset.
* dz60 started. keymaps done.
* bugfixes: missing state change in d-, lspace should toggle vim mode.
* Caps lock indicator -> vim indicator.
And adjusted mousekey settings.
* don't actually need the second move trigger and it makes typing less responsive.
* some oppurtunistic bugfixing from my other keyboard (sorry)
* added readme for my dz60 keymap.
* bugfixing and comments updated (niu_mini)
* cleanup as suggested from review
* FORK!
* WIP - just how i like it
* empty
* more movement
* mouse keys
* more vimminess
* append/insert shift
* WIP - vim macros
* blocked out layer below in cmd mode.
also, about to restart my cmd approach.
* WIP - new vim layer
ripoff of the ergodox one, but rewritten as a state machine.
* debugged some, got key repeat working
* moooar coverage
* moooar coverage
* regular vis mode
* basically done with basics.
* some refactoring
- common movement sequences into helper function
- added some rgb controls
* modkey passthru feature
* stdized on cmd-left/right instead of ctrl-a/e
sadly. as there's no reliable shift-ctrl-e
* indicator lights
* moved vim layer into userspace
* cleaned up some yanking edge cases
* docs and some tweaks to layerescapes
* updated/added license strings
* updated comments
* moved config changes to keymap
* spurious changes removed
* cleanup pass, HT drashna for suggestions
- used _keymap() pattern to better modularize event processing in userspace
- made some static things static
- removed unused function
- improved reset.
* Add tap-dancing semicolon.
* Infinity60 was running out of USB space.
* Rename common layout variable so it doesn't collide with some keyboards.
* Godspeed!!!
* Patch the number of LEDs for 1up60rgb
* Don't light up if rgblight is off.
* Add HHKB layout.
* Add HHKB to Talljoe's layout.
* Bring back bananasplit keymap.
* info.json
* Userspace config.h doesn't seem to be setting PREVENT_STUCK_MODIFIERS
* Remove 1uprgb workaround
* Add TKL to talljoe keymap.
Also introduces the tkl layout.
* FORK!
* WIP - just how i like it
* empty
* more movement
* mouse keys
* more vimminess
* append/insert shift
* WIP - vim macros
* blocked out layer below in cmd mode.
also, about to restart my cmd approach.
* WIP - new vim layer
ripoff of the ergodox one, but rewritten as a state machine.
* debugged some, got key repeat working
* moooar coverage
* moooar coverage
* regular vis mode
* basically done with basics.
* some refactoring
- common movement sequences into helper function
- added some rgb controls
* modkey passthru feature
* stdized on cmd-left/right instead of ctrl-a/e
sadly. as there's no reliable shift-ctrl-e
* indicator lights
* moved vim layer into userspace
* cleaned up some yanking edge cases
* docs and some tweaks to layerescapes
* updated/added license strings
* updated comments
* moved config changes to keymap
* spurious changes removed
* preliminary checkin for facew keyboard
* Update readme file
* put the standard 60 ansi layout in
* update rules to have LAYOUT_60_ansi to use my userspace layouts
* Add
* Revert "Add"
This reverts commit 4b10fef88712a63f4a91410410b4c99346fa1b24.
* Add Ergo42 keymaps
for JIS layout
* Fix hdbx keymap for Ergo42
Changed some keys layout and add description.
* Updated hdbx keymaps for Ergo42
Now using update_tri_layer_state.
Underglow color sync layer-switching.
* Fixed hdbx keymap
Deleted rgb define line (now using master) and fixed some issues pointed out.
* update ignore
* fixed
* Added support for JJ50 from KPRepublic, no rgb or backlight control yet. Added as a layout of ymd96 at the moment (same microprocessor). Basic keymap with three layers to get started.
* Added support for JJ50
* Tidied up jj50 code, backlight and RGB is now working.
* Renaming "KEYMAP" to "LAYOUT" to adhere to the new QMK standards.
* move obelus and nakey to ckeys directory
* delete the originals
* short readme about ckeys
* edit readmes to reflect new changes
* add build guide info..and here's me trying to retrigger the build job
* Stopping point at creating targets for new_project script
* Add second argument for target
* Add the ps2avrgb target
* consider the case where the firmware type target is not valid
* fix template files to be more generic
* Code cleanup
* Change variable name to be more descriptive
* make avr the default
* forgot to put the template files in
* Take out useless comments
* add usage info
* Added Modular keyboards L,R and NUM
Created code modules for the 3 modules of the modular keyboard.
Original idea by MechboardsUK. Uses i2c implementation similar to lets
split
* Remove modular from master
This is to fix incorrect branching
* General fixes for RGB_matrix
- Complited speed support for all effects
- Fixed raindrop effects to initialized after toggle
- Fixed raindrop effects to use all available LEDs
- Fixed effect step reverse function
- Moved RGB_MATRIX_SOLID_REACTIVE under correct flag
* Documentation update for RGBmatrix
* More doc updates
* Use memmove instead of memcpy
gcc 8.1 gives the following error:
lib/lufa/LUFA/Drivers/USB/Class/Common/HIDParser.c:93:5: error: 'memcpy' accessing 42 bytes at offsets 28 and 0 overlaps 14 bytes at offset 28 [-Werror=restrict]
This patch resolve this by using memmove instead
Signed-off-by: Sameeh <Sameeh Jubran>
* Remove ATTR_CONST from a void returning function
gcc 8.10 gives the following error when attempting to compile
lib/lufa/LUFA/Drivers/USB/Core/Events.h:334:5: error: 'const' attribute on function returning 'void' [-Werror=attributes]
Signed-off-by: Sameeh <Sameeh Jubran>
* Added support for the upcomming Lets_split vitamins included
* Updated readme
* Corrected header of readme
* Enabled RGB
* Broke everything
* broke some more shit
* Revert "broke some more shit"
This reverts commit 6ad68e6269cc0d04c16564ce9598dfd3db1e23c1.
* Revert "Broke everything"
This reverts commit feeee4e40db15a726f2292b6a9406ef45c1e54a7.
* Fixed USB detection, and RGB on slave
* started modifying readme, to use msys2
* Added support for the upcomming Lets_split vitamins included
* Updated readme
* Corrected header of readme
* Enabled RGB
* Broke everything
* broke some more shit
* Revert "broke some more shit"
This reverts commit 6ad68e6269cc0d04c16564ce9598dfd3db1e23c1.
* Revert "Broke everything"
This reverts commit feeee4e40db15a726f2292b6a9406ef45c1e54a7.
* Fixed USB detection, and RGB on slave
* started modifying readme, to use msys2
* Updated readme to reflect use of msys2 Added avrdude to msys path
* added avrdude option to msys installer
* Removed extra installation of avrdude
* Renamed to vitamins_included and implemented drashnas changes
* Fixed include guard
* Fixed some includes, and added avrdude target to docs.
* Fixed default keyboard
* add new layout and fix formatting
* Add 60_ansi layout so I can use my user space defined layouts
* Make QMK_KEYBOARD_H and LAYOUT renames
* update info.json file
* Added Modular keyboards L,R and NUM
Created code modules for the 3 modules of the modular keyboard.
Original idea by MechboardsUK. Uses i2c implementation similar to lets
split
* Remove modular from master
This is to fix incorrect branching
* Add effect speed support for RGB Matrix *No eeprom yet*
Keycodes RGB_SPI and RGB_SPD have been added to increase and decrease effect speed.
Speed is not saved in EEPROM yet as per Jack's request.
* Update rgb_matrix.c
* RGB Matrix speed fix rgblight.h
* More fixes for rgb speed. Speed functions declared but not used in rgblight
* More travis fixes..
* Another one for travis..
* Move the microswitches to the top of the keyboard like how it is
physically
Format change to make things pretty
* Fix keymap to match the new layouts
* stopping point at new info.json file
* Update readme
* Finish up QMK Configurator fixes for info.json
* initial commit
* add row/column and pin info
* Add first part of switch matrix
* documentation and additional config items
* map out the non confusing part of the matrix
* map out the top row
* ok I think I got it
* fix some stupid compile errors
* put in a default keymap
* rename LAYOUT to LAYOUT_all
* add a standard layout and info.json file
* Fix up readme for default keymap
* Add toggle key LED functionality
* changes based on review feedback
* added additional configurator support
Added support for choosing between 5 configurator options:
Layout (supports all keys)
Layout_ansi_1u
Layout_iso_1u
Layout_ansi
Layout_iso
* confirming to conventions
replaced .h filenames with QMK_KEYBOARD_H
There are a lot of resources for getting help with QMK.
## Realtime Chat
You can find QMK developers and users on our main [gitter chat room](https://gitter.im/qmk/qmk_firmware). We also have other rooms for more specific discussion:
The official QMK forum is [/r/olkb](https://reddit.com/r/olkb) on [reddit.com](https://reddit.com).
## Github Issues
You can open an [issue on GitHub](https://github.com/qmk/qmk_firmware/issues). This is especially handy when your issue will require long-term discussion or debugging.
QMK has a staggering number of features for building your keyboard. It can take some time to understand all of them and determine which one will achieve your goal.
* [Advanced Keycodes](Advanced_Keycodes.md) - Change layers, type shifted keys, and more. Go beyond typing simple characters.
* [Audio](Audio.md) - Connect a speaker to your keyboard for audio feedback, midi support, and music mode.
* [Auto Shift](Auto_Shift.md) - Tap for the normal key, hold slightly longer for its shifted state.
* [Backlight](Backlight.md) - LED lighting support for your keyboard.
* [Bootmagic](Bootmagic.md) - Adjust the behavior of your keyboard using hotkeys.
* [Dynamic Macros](Dynamic_Macros.md) - Record and playback macros from the keyboard itself.
* [Key Lock](Key_Lock.md) - Lock a key in the "down" state.
* [Layouts](Layouts.md) - Use one keymap with any keyboard that supports your layout.
* [Leader Key](Leader_Key.md) - Tap the leader key followed by a sequence to trigger custom behavior.
* [Macros](Macros.md) - Send multiple key presses when pressing only one physical key.
* [Mouse keys](Mouse_Keys.md) - Control your mouse pointer from your keyboard.
* [Pointing Device](Pointing_Device.md) - Framework for connecting your custom pointing device to your keyboard.
* [PS2 Mouse](PS_2_Mouse.md) - Driver for connecting a PS/2 mouse directly to your keyboard.
* [RGB Light](RGB_Lighting.md) - RGB lighting for your keyboard.
* [Space Cadet Shift](Space_Cadet_Shift.md) - Use your left/right shift keys to type parenthesis and brackets.
You use the functions when you are implementing your own midi device.
You set a send function to actually send bytes via your device, this method is called when you call a send function with this device, for instance midi_send_cc
You use the midi_device_input to process input data from the device and pass it through the device's associated callbacks.
You use the midi_device_set_pre_input_process_func if you want to have a function called at the beginning of the device's process function, generally to poll for input and pass that into midi_device_input
`public void `[`midi_device_input`](#group__midi__device_1gad8d3db8eb35d9cfa51ef036a0a9d70db)`(`[`MidiDevice`](#struct__midi__device)` * device,uint8_t cnt,uint8_t * input)` | Process input bytes. This function parses bytes and calls the appropriate callbacks associated with the given device. You use this function if you are creating a custom device and you want to have midi input.
`public void `[`midi_device_set_send_func`](#group__midi__device_1ga59f5a46bdd4452f186cc73d9e96d4673)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_var_byte_func_t send_func)` | Set the callback function that will be used for sending output data bytes. This is only used if you're creating a custom device. You'll most likely want the callback function to disable interrupts so that you can call the various midi send functions without worrying about locking.
`public void `[`midi_device_set_pre_input_process_func`](#group__midi__device_1ga4de0841b87c04fc23cb56b6451f33b69)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_no_byte_func_t pre_process_func)` | Set a callback which is called at the beginning of the midi_device_process call. This can be used to poll for input data and send the data through the midi_device_input function. You'll probably only use this if you're creating a custom device.
`struct `[`_midi_device`](Internals/internals_midi_device.md#struct__midi__device) | This structure represents the input and output functions and processing data for a midi device.
Process input bytes. This function parses bytes and calls the appropriate callbacks associated with the given device. You use this function if you are creating a custom device and you want to have midi input.
#### Parameters
*`device` the midi device to associate the input with
Set the callback function that will be used for sending output data bytes. This is only used if you're creating a custom device. You'll most likely want the callback function to disable interrupts so that you can call the various midi send functions without worrying about locking.
#### Parameters
*`device` the midi device to associate this callback with
*`send_func` the callback function that will do the sending
Set a callback which is called at the beginning of the midi_device_process call. This can be used to poll for input data and send the data through the midi_device_input function. You'll probably only use this if you're creating a custom device.
#### Parameters
*`device` the midi device to associate this callback with
*`midi_no_byte_func_t` the actual callback function
# struct `_midi_device` {#struct__midi__device}
This structure represents the input and output functions and processing data for a midi device.
A device can represent an actual physical device [serial port, usb port] or something virtual. You should not need to modify this structure directly.
QMK (*Quantum Mechanical Keyboard*) is an open source community that maintains QMK Firmware, QMK Flasher, qmk.fm, and these docs. QMK Firmware is a keyboard firmware based on the [tmk\_keyboard](http://github.com/tmk/tmk_keyboard) with some useful features for Atmel AVR controllers, and more specifically, the [OLKB product line](http://olkb.com), the [ErgoDox EZ](http://www.ergodox-ez.com) keyboard, and the [Clueboard product line](http://clueboard.co/). It has also been ported to ARM chips using ChibiOS. You can use it to power your own hand-wired or custom keyboard PCB.
QMK (*Quantum Mechanical Keyboard*) is an open source community that maintains QMK Firmware, QMK Toolbox, qmk.fm, and these docs. QMK Firmware is a keyboard firmware based on the [tmk\_keyboard](http://github.com/tmk/tmk_keyboard) with some useful features for Atmel AVR controllers, and more specifically, the [OLKB product line](http://olkb.com), the [ErgoDox EZ](http://www.ergodox-ez.com) keyboard, and the [Clueboard product line](http://clueboard.co/). It has also been ported to ARM chips using ChibiOS. You can use it to power your own hand-wired or custom keyboard PCB.
## How to Get It
@@ -12,7 +19,7 @@ Otherwise, you can either download it directly ([zip](https://github.com/qmk/qmk
## How to Compile
Before you are able to compile, you'll need to [install an environment](01_Getting_Started/01_Install_Build_Tools.md) for AVR or/and ARM development. Once that is complete, you'll use the `make` command to build a keyboard and keymap with the following notation:
Before you are able to compile, you'll need to [install an environment](getting_started_build_tools.md) for AVR or/and ARM development. Once that is complete, you'll use the `make` command to build a keyboard and keymap with the following notation:
make planck/rev4:default
@@ -22,4 +29,4 @@ This would build the `rev4` revision of the `planck` with the `default` keymap.
## How to Customize
QMK has lots of [features](05_Features/index.md) to explore, and a good deal of [reference documentation](http://docs.qmk.fm) to dig through. Most features are taken advantage of by modifying your [keymap](07_Reference/Keymap_Overview.md), and changing the [keycodes](06_Keycodes/index.md).
QMK has lots of [features](features.md) to explore, and a good deal of [reference documentation](http://docs.qmk.fm) to dig through. Most features are taken advantage of by modifying your [keymap](keymap.md), and changing the [keycodes](keycodes.md).
@@ -123,21 +123,27 @@ If you define these options you will enable the associated feature, which may in
## Behaviors That Can Be Configured
* `#define TAPPING_TERM 200`
* how long before a tap becomes a hold
* how long before a tap becomes a hold, if set above 500, a key tapped during the tapping term will turn it into a hold too
* `#define RETRO_TAPPING`
* tap anyway, even after TAPPING_TERM, if there was no other key interruption between press and release
* See [Retro Tapping](feature_advanced_keycodes.md#retro-tapping) for details
* `#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
* 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
* `#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)
* `#define LEADER_TIMEOUT 300`
* how long before the leader key times out
* `#define ONESHOT_TIMEOUT 300`
* how long before oneshot times out
* `#define ONESHOT_TAP_TOGGLE 2`
* how many taps before oneshot toggle is triggered
* `#define IGNORE_MOD_TAP_INTERRUPT`
* makes it possible to do rolling combos (zx) with keys that convert to other keys on hold
* `#define QMK_KEYS_PER_SCAN 4`
* Allows sending more than one key per scan. By default, only one key event gets
sent via `process_record()` per scan. This has little impact on most typing, but
@@ -173,6 +179,16 @@ If you define these options you will enable the associated feature, which may in
* `#define MOUSEKEY_MAX_SPEED 7`
* `#define MOUSEKEY_WHEEL_DELAY 0`
## Split Keyboard Options
Split Keyboard specific options, make sure you have 'SPLIT_KEYBOARD = yes' in your rules.mk
* `#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.
* `#define USE_I2C`
* For using I2C instead of Serial (defaults to serial)
# 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.
@@ -184,7 +200,7 @@ This is a [make](https://www.gnu.org/software/make/manual/make.html) file that i
* `SRC`
* Used to add files to the compilation/linking list.
* `LAYOUTS`
* A list of [layouts](05_Features/Layouts.md) this keyboard supports.
* A list of [layouts](feature_layouts.md) this keyboard supports.
## AVR MCU Options
* `MCU = atmega32u4`
@@ -226,3 +242,5 @@ Use these to enable or disable building certain features. The more you have enab
* Unicode
* `BLUETOOTH_ENABLE`
* Enable Bluetooth with the Adafruit EZ-Key HID
* `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
@@ -11,7 +11,7 @@ Third-party contributions help us grow and improve QMK. We want to make the pull
## I Don't Want to Read This Whole Thing! I Just Have a Question!
If you'd like to ask questions about QMK you can do so on the [OLKB Subreddit](https://reddit.com/r/olkb) or on [Gitter](https://gitter.im/qmk/qmk_firmware).
If you'd like to ask questions about QMK you can do so on the [OLKB Subreddit](https://reddit.com/r/olkb) or on [Discord](https://discord.gg/Uq7gcHh).
Please keep these things in mind:
@@ -29,7 +29,7 @@ QMK is largely written in C, with specific features and parts written in C++. It
# Where Can I Go for Help?
If you need help you can [open an issue](https://github.com/qmk/qmk_firmware/issues) or [chat on gitter](http://gitter.im/QMK/qmk_firmware).
If you need help you can [open an issue](https://github.com/qmk/qmk_firmware/issues) or [chat on Discord](https://discord.gg/Uq7gcHh).
# How Do I Make a Contribution?
@@ -101,7 +101,7 @@ You'll find all our documentation in the `qmk_firmware/docs` directory, or if yo
Most first-time QMK contributors start with their personal keymaps. We try to keep keymap standards pretty casual (keymaps, after all, reflect the personality of their creators) but we do ask that you follow these guidelines to make it easier for others to discover and learn from your keymap.
* Write a `readme.md` using [the template](https://docs.qmk.fm/documentation_templates.html#).
* Write a `readme.md` using [the template](documentation_templates.md).
* All Keymap PR's are squashed, so if you care about how your commits are squashed you should do it yourself
* Do not lump features in with keymap PR's. Submit the feature first and then a second PR for the keymap.
* Do not include `Makefile`s in your keymap folder (they're no longer used)
@@ -113,7 +113,7 @@ Keyboards are the raison d'être for QMK. Some keyboards are community maintaine
We also ask that you follow these guidelines:
* Write a `readme.md` using [the template](https://docs.qmk.fm/documentation_templates.html#).
* Write a `readme.md` using [the template](documentation_templates.md).
* Keep the number of commits reasonable or we will squash your PR
* Do not lump core features in with new keyboards. Submit the feature first and then submit a separate PR for the keyboard.
* Name `.c`/`.h` file after the immediate parent folder, eg `/keyboards/<kb1>/<kb2>/<kb2>.[ch]`
@@ -122,9 +122,9 @@ We also ask that you follow these guidelines:
## Quantum/TMK Core
Before you put a lot of work into building your new feature you should make sure you are implementing it in the best way. You can get a basic understanding of QMK by reading [Understanding QMK](For_a_Deeper_Understanding/Understanding_QMK.md), which will take you on a tour of the QMK program flow. From here you should talk to us to get a sense of the best way to implement your idea. There are two main ways to do this:
Before you put a lot of work into building your new feature you should make sure you are implementing it in the best way. You can get a basic understanding of QMK by reading [Understanding QMK](understanding_qmk.md), which will take you on a tour of the QMK program flow. From here you should talk to us to get a sense of the best way to implement your idea. There are two main ways to do this:
* [Chat on Gitter](https://gitter.im/qmk/qmk_firmware)
* [Chat on Discord](https://discord.gg/Uq7gcHh)
* [Open an Issue](https://github.com/qmk/qmk_firmware/issues/new)
Feature and Bug Fix PR's affect all keyboards. We are also in the process of restructuring QMK. For this reason it is especially important for significant changes to be discussed before implementation has happened. If you open a PR without talking to us first please be prepared to do some significant rework if your choices do not mesh well with our planned direction.
@@ -140,7 +140,7 @@ We also ask that you follow these guidelines:
* Keep the number of commits reasonable or we will squash your PR
* Do not lump keyboards or keymaps in with core changes. Submit your core changes first.
* Write [Unit Tests](http://docs.qmk.fm/unit_testing.html) for your feature
* Write [Unit Tests](unit_testing.md) for your feature
* Follow the style of the file you are editing. If the style is unclear or there are mixed styles you should conform to the [coding conventions](#coding-conventions) above.
For a lot of people a custom keyboard is about more than sending button presses to your computer. You want to be able to do things that are more complex than simple button presses and macros. QMK has hooks that allow you to inject code, override functionality, and otherwise customize how your keyboard behaves in different situations.
This page does not assume any special knowledge about QMK, but reading [Understanding QMK](For_a_Deeper_Understanding/Understanding_QMK.md) will help you understand what is going on at a more fundamental level.
This page does not assume any special knowledge about QMK, but reading [Understanding QMK](understanding_qmk.md) will help you understand what is going on at a more fundamental level.
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.
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.
### Example `matrix_init_user()` Implementation
@@ -165,7 +167,7 @@ Whenever possible you should customize your keyboard by using `process_record_*(
### Example `matrix_scan_*` Implementation
This example has been deliberately omitted. You should understand enough about QMK internals to write this without an example before hooking into such a performance sensitive area. If you need help please [open an issue](https://github.com/qmk/qmk_firmware/issues/new) or [chat with us on gitter](https://gitter.im/qmk/qmk_firmware).
This example has been deliberately omitted. You should understand enough about QMK internals to write this without an example before hooking into such a performance sensitive area. If you need help please [open an issue](https://github.com/qmk/qmk_firmware/issues/new) or [chat with us on Discord](https://discord.gg/Uq7gcHh).
### `matrix_scan_*` Function Documentation
@@ -177,13 +179,42 @@ This function gets called at every matrix scan, which is basically as often as t
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.
# Keyboard Idling/Wake Code
If the board supports it, it can be "idled", by stopping a number of functions. A good example of this is RGB lights or backlights. This can save on power consumption, or may be better behavior for your keyboard.
This is controlled by two functions: `suspend_power_down_*` and `suspend_wakeup_init_*`, which are called when the system is board is idled and when it wakes up, respectively.
### Example suspend_power_down_user() and suspend_wakeup_init_user() Implementation
This example, at the keyboard level, sets up B1, B2, and B3 as LED pins.
```
void suspend_power_down_user(void)
{
rgb_matrix_set_suspend_state(true);
}
void suspend_wakeup_init_user(void)
{
rgb_matrix_set_suspend_state(false);
}
```
### `keyboard_init_*` Function Documentation
* Keyboard/Revision: `void suspend_power_down_kb(void)` and `void suspend_wakeup_init_user(void)`
* Keymap: `void suspend_power_down_kb(void)` and `void suspend_wakeup_init_user(void)`
# Layer Change Code
Thir runs code every time that the layers get changed. This can be useful for layer indication, or custom layer handling.
This runs code every time that the layers get changed. This can be useful for layer indication, or custom layer handling.
### Example `layer_state_set_*` Implementation
This example shows how to set the [RGB Underglow](05_Features/RGB_Lighting.md) lights based on the layer, using the Planck as an example
This example shows how to set the [RGB Underglow](feature_rgblight.md) lights based on the layer, using the Planck as an example
You can add some colors. What about a warning message?
**[warning [WARNING] The color depends on the theme. Could look normal too]
What about an error message?
**[error [ERROR] This is not the error you are looking for]
?> This is a helpful tip.
```
Renders as:
?> This is a helpful tip.
# Documenting Features
If you create a new feature for QMK, create a documentation page for it. It doesn't have to be very long, a few sentences describing your feature and a table listing any relevant keycodes is enough. Here is a basic template:
@@ -94,4 +61,4 @@ This page describes my cool feature. You can use my cool feature to make coffee
|KC_SUGAR||Order Sugar|
```
Place your documentation into `docs/feature_<my_cool_feature>.md`, and add that file to the appropriate place in `docs/_summary.md`. If you have added any keycodes be sure to add them to `docs/06_Keycodes/index.md` with a link back to your feature page.
Place your documentation into `docs/feature_<my_cool_feature>.md`, and add that file to the appropriate place in `docs/_sidebar.md`. If you have added any keycodes be sure to add them to `docs/keycodes.md` with a link back to your feature page.
@@ -17,7 +17,7 @@ Note that this set-up has been tested on Ubuntu 16.04 only for the moment.
# Prerequisites
## Build Environment
Before starting, you must have followed the [Getting Started](index.md#getting-started) section corresponding to your system. In particular, you must have been able to build the firmware with the `make` command.
Before starting, you must have followed the [Getting Started](README.md#getting-started) section corresponding to your system. In particular, you must have been able to build the firmware with [the `make` command](../#the-make-command).
## Java
Eclipse is a Java application, so you will need to install Java 8 or more recent to be able to run it. You may choose between the JRE or the JDK, the latter being useful if you intend to do Java development.
@@ -85,4 +85,4 @@ We will now configure a make target that cleans the project and builds the keyma
8. Double-click the build target you created to trigger a build.
9. Select the <kbd>Console</kbd> view at the bottom to view the running build.
This page covers questions about building QMK. If you haven't yet done so, you should read the [Build Environment Setup](01_Getting_Started/index.md) and [Make Instructions](01_Getting_Started/03_Build_Compile_Instructions.md) guides.
This page covers questions about building QMK. If you haven't yet done so, you should read the [Build Environment Setup](getting_started_build_tools.md) and [Make Instructions](getting_started_make_guide.md) guides.
## Can't Program on Linux
You will need proper permissions to operate a device. For Linux users, see the instructions regarding `udev` rules, below. If you have issues with `udev`, a work-around is to use the `sudo` command. If you are not familiar with this command, check its manual with `man sudo` or [see this webpage](https://linux.die.net/man/8/sudo).
@@ -104,3 +104,17 @@ brew install dfu-programmer
brew install gcc-arm-none-eabi
brew install avrdude
```
### avr-gcc 8.1 and LUFA
If you updated your avr-gcc to above 7 you may see errors involving LUFA. For example:
`lib/lufa/LUFA/Drivers/USB/Class/Device/AudioClassDevice.h:380:5: error: 'const' attribute on function returning 'void'`
For now, you need to rollback avr-gcc to 7 in brew.
TMK was originally designed and implemented by [Jun Wako](https://github.com/tmk). QMK started as [Jack Humbert](https://github.com/jackhumbert)'s fork of TMK for the Planck. After a while Jack's fork had diverged quite a bit from TMK, and in 2015 Jack decided to rename his fork to QMK.
From a technical standpoint QMK builds upon TMK by adding several new features. Most notably QMK has expanded the number of available keycodes and uses these to implement advanced features like `S()`, `LCTL()`, and `MO()`. You can see a complete list of these keycodes in [Keycodes](06_Keycodes/index.md).
From a technical standpoint QMK builds upon TMK by adding several new features. Most notably QMK has expanded the number of available keycodes and uses these to implement advanced features like `S()`, `LCTL()`, and `MO()`. You can see a complete list of these keycodes in [Keycodes](keycodes.md).
From a project and community management standpoint TMK maintains all the officially supported keyboards by himself, with a bit of community support. Separate community maintained forks exist or can be created for other keyboards. Only a few keymaps are provided by default, so users typically don't share keymaps with each other. QMK encourages sharing of both keyboards and keymaps through a centrally managed repository, accepting all pull requests that follow the quality standards. These are mostly community maintained, but the QMK team also helps when necessary.
This page covers questions people often have about keymaps. If you haven't you should read [Keymap Overview](07_Reference/Keymap_Overview.md) first.
This page covers questions people often have about keymaps. If you haven't you should read [Keymap Overview](keymap.md) first.
## What Keycodes Can I Use?
See [Keycodes](06_Keycodes/index.md) for an index of keycodes available to you. These link to more extensive documentation when available.
See [Keycodes](keycodes.md) for an index of keycodes available to you. These link to more extensive documentation when available.
Keycodes are actually defined in [common/keycode.h](https://github.com/qmk/qmk_firmware/blob/master/tmk_core/common/keycode.h).
@@ -20,8 +20,8 @@ QMK has two features, Bootmagic and Command, which allow you to change the behav
As a quick fix try holding down `Space`+`Backspace` while you plug in your keyboard. This will reset the stored settings on your keyboard, returning those keys to normal operation. If that doesn't work look here:
Modifier keys or layers can be stuck unless layer switching is configured properly.
For Modifier keys and layer actions you have to place `KC_TRANS` on same position of destination layer to unregister the modifier key or return to previous layer on release event.
See the [Grave Escape](05_Features/Grave_Escape.md) feature.
See the [Grave Escape](feature_grave_esc.md) feature.
## Arrow on Right Modifier Keys with Dual-Role
This turns right modifier keys into arrow keys when the keys are tapped while still modifiers when the keys are hold. In TMK the dual-role function is dubbed **TAP**.
@@ -147,7 +147,7 @@ This turns right modifier keys into arrow keys when the keys are tapped while st
/* Arrow keys on right modifier keys with TMK dual role feature
@@ -15,13 +15,13 @@ This will allow you to use `FN_CAPS` and `ALT_TAB` in your `KEYMAP()`, keeping i
### Limits of These Aliases
Currently, the keycodes able to used with these functions are limited to the [Basic Keycodes](06_Keycodes/Basic.md), meaning you can't use keycodes like `KC_TILD`, or anything greater than 0xFF. For a full list of the keycodes able to be used see [Basic Keycodes](06_Keycodes/Basic.md).
Currently, the keycodes able to used with these functions are limited to the [Basic Keycodes](keycodes_basic.md), meaning you can't use keycodes like `KC_TILD`, or anything greater than 0xFF. For a full list of the keycodes able to be used see [Basic Keycodes](keycodes_basic.md).
# 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](07_Reference/Keymap_Overview.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)
* `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](07_Reference/Custom_Code.md#programming-the-behavior-of-any-keycode).)
* `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.
* `LT(layer, kc)` - momentarily activates *layer* when held, and sends *kc* when tapped.
@@ -131,11 +131,9 @@ We've added shortcuts to make common modifier/tap (mod-tap) mappings more compac
* `LCAG_T(kc)` - is CtrlAltGui when held and *kc* when tapped
* `MEH_T(kc)` - is like Hyper, but not as cool -- does not include the Cmd/Win key, so just sends Alt+Ctrl+Shift.
{% hint style='info' %}
Due to the way that keycodes are structured, any modifiers specified as part of `kc`, such as `LCTL()` or `KC_LPRN`, will only activate when held instead of tapped.
?> Due to the way that keycodes are structured, any modifiers specified as part of `kc`, such as `LCTL()` or `KC_LPRN`, will only activate when held instead of tapped.
Additionally, if there is at least one right modifier, any other modifiers will turn into their right equivalents, so it is not possible to "mix and match" the two.
{% endhint %}
?> Additionally, if there is at least one right modifier, any other modifiers will turn into their right equivalents, so it is not possible to "mix and match" the two.
# One Shot Keys
@@ -177,3 +175,37 @@ Example: (Tapping Term = 200ms)
- SHFT_T(KC_A) Up
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).
# Mod tap interrupt
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.
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.
You can disable this behavior by defining `IGNORE_MOD_TAP_INTERRUPT` in `config.h`.
Note that this only concerns modifiers and not layer switching keys.
# Hold after tap
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`.
Example:
- SHFT_T(KC_A) Down
- SHFT_T(KC_A) Up
- SHFT_T(KC_A) Down
- wait more than tapping term...
- SHFT_T(KC_A) Up
With default settings, `a` will be sent on the first release, then `a` will be sent on the second press allowing the computer to trigger its auto repeat function.
With `TAPPING_FORCE_HOLD`, the second press will be interpreted as a Shift, allowing to use it as a modifier shortly after having used it as a tap.
!> `TAPPING_FORCE_HOLD` will break anything that uses tapping toggles (Such as the `TT` layer keycode, and the One Shot Tapping Toggle).
# Retro Tapping
When you hold a dual function key, and haven't pressed anything when you release the key, normally nothing happens. However, if you enable this, if you release the key without pressing another key, it will send the original key, even if it is outside of the tapping term.
For instance, if you're using `LT(2, KC_SPACE)`, if you hold the key, don't hit anything else and then release it, normally, nothing happens. But with `RETRO_TAPPING` defined in your `config.h`, it will send `KC_SPACE`.
Your keyboard can make sounds! If you've got a Planck, Preonic, or basically any AVR keyboard that allows access to certain PWM-capable pins, you can hook up a simple speaker and make it beep. You can use those beeps to indicate layer transitions, modifiers, special keys, or just to play some funky 8bit tunes.
Up to two simultaneous audio voices are supported, one driven by timer 1 and another driven by timer 3. The following pins can be defined as audio outputs in config.h:
Timer 1:
`#define B5_AUDIO`
`#define B6_AUDIO`
@@ -58,13 +59,20 @@ PLAY_LOOP(my_song);
It's advised that you wrap all audio features in `#ifdef AUDIO_ENABLE` / `#endif` to avoid causing problems when audio isn't built into the keyboard.
The available keycodes for audio are:
* `AU_ON` - Turn audio mode on
* `AU_OFF` - Turn audio mode off
* `AU_TOG` - Toggle audio mode
## Music Mode
The music mode maps your columns to a chromatic scale, and your rows to octaves. This works best with ortholinear keyboards, but can be made to work with others. All keycodes less than `0xFF` get blocked, so you won't type while playing notes - if you have special keys/mods, those will still work. A work-around for this is to jump to a different layer with KC_NOs before (or after) enabling music mode.
Recording is experimental due to some memory issues - if you experience some weird behavior, unplugging/replugging your keyboard will fix things.
06_Keycodes available:
Keycodes available:
* `MU_ON` - Turn music mode on
* `MU_OFF` - Turn music mode off
@@ -89,6 +97,20 @@ By default, `MUSIC_MASK` is set to `keycode < 0xFF` which means keycodes less th
Which will capture all keycodes - be careful, this will get you stuck in music mode until you restart your keyboard!
For a more advanced way to control which keycodes should still be processed, you can use `music_mask_kb(keycode)` in `<keyboard>.c` and `music_mask_user(keycode)` in your `keymap.c`:
bool music_mask_user(uint16_t keycode) {
switch (keycode) {
case RAISE:
case LOWER:
return false;
default:
return true;
}
}
Things that return false are not part of the mask, and are always processed.
The pitch standard (`PITCH_STANDARD_A`) is 440.0f by default - to change this, add something like this to your `config.h`:
#define PITCH_STANDARD_A 432.0f
@@ -131,6 +153,23 @@ You can configure the default, min and max frequencies, the stepping and built i
This is still a WIP, but check out `quantum/keymap_midi.c` to see what's happening. Enable from the Makefile.
@@ -6,7 +6,7 @@ Bootmagic is a system for configuring your keyboard while it initializes. To tri
Bootmagic Keycodes allow you to access the Bootmagic functionality after your keyboard has initialized. To use Bootmagic Keycodes you assign keycodes starting with `MAGIC_`, much in the same way you define any other key.
Command is a feature that allows you to control different aspects of your keyboard. Command used to be called Magic. Command is typically accessed by holding Left and Right Shift at the same time, although that can be customized. While it shares some functionality with Bootmagic it also allows you to access functionality that Bootmagic does not. For more information see the [Command](05_Features/Command.md) documentation page.
Command is a feature that allows you to control different aspects of your keyboard. Command used to be called Magic. Command is typically accessed by holding Left and Right Shift at the same time, although that can be customized. While it shares some functionality with Bootmagic it also allows you to access functionality that Bootmagic does not. For more information see the [Command](feature_command.md) documentation page.
Command is a way to change your keyboard's behavior without having to flash or unplug it to use [Bootmagic](05_Features/Bootmagic.md). There is a lot of overlap between this functionality and the [Bootmagic Keycodes](05_Features/Bootmagic.md). Whenever possible we encourage you to use that functionality instead of Command.
Command is a way to change your keyboard's behavior without having to flash or unplug it to use [Bootmagic](feature_bootmagic.md). There is a lot of overlap between this functionality and the [Bootmagic Keycodes](feature_bootmagic.md). Whenever possible we encourage you to use that functionality instead of Command.
This is an integration of Peter Fleury's LCD library. This page will explain the basics. [For in depth documentation visit his page.](http://homepage.hispeed.ch/peterfleury/doxygen/avr-gcc-libraries/group__pfleury__lcd.html)
You can enable support for HD44780 Displays by setting the `HD44780_ENABLE` flag in your keyboards `rules.mk` to yes. This will use about 400 KB of extra space.
## Configuration
You will need to configure the pins used by your display and its number of lines and collumn in your keyboards `config.h`.
Uncomment the section labled HD44780 and change the parameters as needed.
````
/*
* HD44780 LCD Display Configuration
*/
#define LCD_LINES 2 //< number of visible lines of the display
#define LCD_DISP_LENGTH 16 //< visibles characters per line of the display
#define LCD_DATA0_PORT LCD_PORT //< port for 4bit data bit 0
#define LCD_DATA1_PORT LCD_PORT //< port for 4bit data bit 1
#define LCD_DATA2_PORT LCD_PORT //< port for 4bit data bit 2
#define LCD_DATA3_PORT LCD_PORT //< port for 4bit data bit 3
#define LCD_DATA0_PIN 4 //< pin for 4bit data bit 0
#define LCD_DATA1_PIN 5 //< pin for 4bit data bit 1
#define LCD_DATA2_PIN 6 //< pin for 4bit data bit 2
#define LCD_DATA3_PIN 7 //< pin for 4bit data bit 3
#define LCD_RS_PORT LCD_PORT //< port for RS line
#define LCD_RS_PIN 3 //< pin for RS line
#define LCD_RW_PORT LCD_PORT //< port for RW line
#define LCD_RW_PIN 2 //< pin for RW line
#define LCD_E_PORT LCD_PORT //< port for Enable line
#define LCD_E_PIN 1 //< pin for Enable line
#endif
````
Should you need to configure other properties you can copy them from `quantum/hd44780.h` and set them in your `config.h`
## Usage
To initialize your display call lcd_init() with one of these parameters:
````
LCD_DISP_OFF : display off
LCD_DISP_ON : display on, cursor off
LCD_DISP_ON_CURSOR : display on, cursor on
LCD_DISP_ON_CURSOR_BLINK : display on, cursor on flashing
````
This is best done in your keyboards `matrix_init_kb` or your keymaps `matrix_init_user`.
It is advised to clear the display before use.
To do so call `lcd_clrsrc()`.
To now print something to your Display you first call `lcd_gotoxy(column, line)`. To go to the start of the first line you would call `lcd_gotoxy(0, 0)` and then print a string with `lcd_puts("example string")`.
There are more posible methods to control the display. [For in depth documentation please visit the linked page.](http://homepage.hispeed.ch/peterfleury/doxygen/avr-gcc-libraries/group__pfleury__lcd.html)
2. Enable key lock by including `KEY_LOCK_ENABLE = yes` in your Makefile.
3. That's it!
Important: switching layers does not cancel the key lock. Additionally, key lock is only able to hold standard action keys and One Shot modifier keys (for example, if you have your shift defined as `OSM(KC_LSFT)`; see [One Shot Keys](06_Keycodes/Quantum_Keycodes.md#one-shot-keys)). This does not include any of the QMK special functions (except One Shot modifiers), or shifted versions of keys such as KC_LPRN. If it's in the [Basic Keycodes](06_Keycodes/Basic.md) list, it can be held. If it's not, then it can't be.
Important: switching layers does not cancel the key lock. Additionally, key lock is only able to hold standard action keys and One Shot modifier keys (for example, if you have your shift defined as `OSM(KC_LSFT)`; see [One Shot Keys](quantum_keycodes.md#one-shot-keys)). This does not include any of the QMK special functions (except One Shot modifiers), or shifted versions of keys such as KC_LPRN. If it's in the [Basic Keycodes](keycodes_basic.md) list, it can be held. If it's not, then it can't be.
As you can see, you have three function. you can use -`SEQ_ONE_KEY` for single-key sequences (Leader followed by just one key), and `SEQ_TWO_KEYS` and`SEQ_THREE_KEYS`for longer sequences. Each of these accepts one or more keycodes as arguments. This is an important point: You can use keycodes from **any layer on your keyboard**. That layer would need to be active for the leader macro to fire, obviously.
As you can see, you have a few function. You can use `SEQ_ONE_KEY` for single-key sequences (Leader followed by just one key), and `SEQ_TWO_KEYS`,`SEQ_THREE_KEYS`up to `SEQ_FIVE_KEYS` for longer sequences.
Each of these accepts one or more keycodes as arguments. This is an important point: You can use keycodes from **any layer on your keyboard**. That layer would need to be active for the leader macro to fire, obviously.
Macros allow you to send multiple keystrokes when pressing just one key. QMK has a number of ways to define and use macros. These can do anything you want: type common phrases for you, copypasta, repetitive game movements, or even help you code.
{% hint style='danger' %}
**Security Note**: While it is possible to use macros to send passwords, credit card numbers, and other sensitive information it is a supremely bad idea to do so. Anyone who gets a hold of your keyboard will be able to access that information by opening a text editor.
{% endhint %}
!> **Security Note**: While it is possible to use macros to send passwords, credit card numbers, and other sensitive information it is a supremely bad idea to do so. Anyone who gets a hold of your keyboard will be able to access that information by opening a text editor.
## The New Way: `SEND_STRING()`&`process_record_user`
Currently only 2 drivers are supported, but it would be trivial to support all 4 combinations.
Define these arrays listing all the LEDs in your `<keyboard>.c`:
const is31_led g_is31_leds[DRIVER_LED_TOTAL] = {
/* Refer to IS31 manual for these locations
* driver
* | R location
* | | G location
* | | | B location
* | | | | */
{0, C1_3, C2_3, C3_3},
....
}
Where `Cx_y` is the location of the LED in the matrix defined by [the datasheet](http://www.issi.com/WW/pdf/31FL3731.pdf). The `driver` is the index of the driver you defined in your `config.h` (`0` or `1` right now).
|`RGB_MODE_RGBTEST `|`RGB_M_T` |Red,Green,Blue test animation mode |
note: for backwards compatibility, `RGB_SMOD` is an alias for `RGB_MOD`.
## Hardware Modification


Here is a quick demo on Youtube (with NPKC KC60) (https://www.youtube.com/watch?v=VKrpPAHlisY).
@@ -6,9 +6,9 @@ Hit the semicolon key once, send a semicolon. Hit it twice, rapidly -- send a co
With this feature one can specify keys that behave differently, based on the amount of times they have been tapped, and when interrupted, they get handled before the interrupter.
To make it clear how this is different from `ACTION_FUNCTION_TAP`, lets explore a certain setup! We want one key to send `Space` on single tap, but `Enter` on double-tap.
To make it clear how this is different from `ACTION_FUNCTION_TAP`, let's explore a certain setup! We want one key to send `Space` on single tap, but `Enter` on double-tap.
With `ACTION_FUNCTION_TAP`, it is quite a rain-dance to set this up, and has the problem that when the sequence is interrupted, the interrupting key will be send first. Thus, `SPC a` will result in `a SPC` being sent, if they are typed within `TAPPING_TERM`. With the tap dance feature, that'll come out as `SPC a`, correctly.
With `ACTION_FUNCTION_TAP`, it is quite a rain-dance to set this up, and has the problem that when the sequence is interrupted, the interrupting key will be sent first. Thus, `SPC a` will result in `a SPC` being sent, if they are typed within `TAPPING_TERM`. With the tap dance feature, that'll come out as `SPC a`, correctly.
The implementation hooks into two parts of the system, to achieve this: into `process_record_quantum()`, and the matrix scan. We need the latter to be able to time out a tap sequence even when a key is not being pressed, so `SPC` alone will time out and register after `TAPPING_TERM` time.
@@ -16,11 +16,13 @@ But lets start with how to use it, first!
First, you will need `TAP_DANCE_ENABLE=yes` in your `rules.mk`, because the feature is disabled by default. This adds a little less than 1k to the firmware size. Next, you will want to define some tap-dance keys, which is easiest to do with the `TD()` macro, that - similar to `F()`, takes a number, which will later be used as an index into the `tap_dance_actions` array.
This array specifies what actions shall be taken when a tap-dance key is in action. Currently, there are three possible options:
This array specifies what actions shall be taken when a tap-dance key is in action. Currently, there are five possible options:
* `ACTION_TAP_DANCE_DOUBLE(kc1, kc2)`: Sends the `kc1` keycode when tapped once, `kc2` otherwise. When the key is held, the appropriate keycode is registered: `kc1` when pressed and held, `kc2` when tapped once, then pressed and held.
* `ACTION_TAP_DANCE_DUAL_ROLE(kc, layer)`: Sends the `kc` keycode when tapped once, or moves to `layer`. (this functions like the `TO` layer keycode).
* `ACTION_TAP_DANCE_FN(fn)`: Calls the specified function - defined in the user keymap - with the final tap count of the tap dance action.
* `ACTION_TAP_DANCE_FN_ADVANCED(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn)`: Calls the first specified function - defined in the user keymap - on every tap, the second function on when the dance action finishes (like the previous option), and the last function when the tap dance action resets.
* `ACTION_TAP_DANCE_FN_ADVANCED(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn)`: Calls the first specified function - defined in the user keymap - on every tap, the second function when the dance action finishes (like the previous option), and the last function when the tap dance action resets.
* `ACTION_TAP_DANCE_FN_ADVANCED_TIME(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn, tap_specific_tapping_term)`: This functions identically to the `ACTION_TAP_DANCE_FN_ADVANCED` function, but uses a custom tapping term for it, instead of the predefined `TAPPING_TERM`.
The first option is enough for a lot of cases, that just want dual roles. For example, `ACTION_TAP_DANCE_DOUBLE(KC_SPC, KC_ENT)` will result in `Space` being sent on single-tap, `Enter` otherwise.
@@ -31,6 +31,20 @@ The reason for this, is that `<name>.h` won't be added in time to add settings (
So you should use the `config.h` for QMK settings, and the `<name>.h` file for user or keymap specific settings.
`/users/<name>/rules.mk` will be included in the build _after_ the `rules.mk` from your keymap. This allows you to have features in your userspace `rules.mk` that depend on individual QMK features that may or may not be available on a specific keyboard. For example, if you have RGB control features shared between all your keyboards that support RGB lighting, you can `define RGB_ENABLE` in your keymap `rules.mk` and then check for the variable in your userspace `rules.mk` like this:
```make
ifdef RGB_ENABLE
# Include my fancy rgb functions source here
endif
```
Because of this, any time you turn on QMK features in your `users/<name>/rules.mk`, you should conditionally enable them only if the flag isn't already defined, like this:
```make
ifndef TAP_DANCE_ENABLE
TAP_DANCE_ENABLE = yes
endif
```
This will ensure that you can explicitly turn off features for an individual keymap.
## Readme
Please include authorship (your name, github username, email), and optionally [a license that's GPL compatible](https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses).
@@ -48,7 +62,7 @@ If you do add a `config,h` file, you want to make sure that it only gets process
#endif // !USERSPACE_CONFIG_H
```
You can use any option hre that you could use in your keymap's `config.h` file. You can find a list of vales [here](07_Reference/Config_Options.md).
You can use any option hre that you could use in your keymap's `config.h` file. You can find a list of vales [here](config_options.md).
## Example
@@ -118,7 +132,7 @@ Additionally, this should flash the newly compiled firmware automatically, using
## Override default userspace
By default the userspace used will be the same as the keymap name. In some situations this isn't desirable. For instance, if you use the [layout](05_Features/Layouts.md) feature you can't use the same name for different keymaps (e.g. ANSI and ISO). You can name your layouts `mylayout-ansi` and `mylayout-iso` and add the following line to your layout's `rules.mk`:
By default the userspace used will be the same as the keymap name. In some situations this isn't desirable. For instance, if you use the [layout](feature_layouts.md) feature you can't use the same name for different keymaps (e.g. ANSI and ISO). You can name your layouts `mylayout-ansi` and `mylayout-iso` and add the following line to your layout's `rules.mk`:
QMK has a staggering number of features for building your keyboard. It can take some time to understand all of them and determine which one will achieve your goal.
* [Advanced Keycodes](feature_advanced_keycodes.md) - Change layers, type shifted keys, and more. Go beyond typing simple characters.
* [Audio](feature_audio.md) - Connect a speaker to your keyboard for audio feedback, midi support, and music mode.
* [Auto Shift](feature_auto_shift.md) - Tap for the normal key, hold slightly longer for its shifted state.
* [Backlight](feature_backlight.md) - LED lighting support for your keyboard.
* [Bootmagic](feature_bootmagic.md) - Adjust the behavior of your keyboard using hotkeys.
* [Dynamic Macros](feature_dynamic_macros.md) - Record and playback macros from the keyboard itself.
* [HD44780 LCD Display](feature_hd44780.md) - Support for LCD character displays using the HD44780 standard.
* [Key Lock](feature_key_lock.md) - Lock a key in the "down" state.
* [Layouts](feature_layouts.md) - Use one keymap with any keyboard that supports your layout.
* [Leader Key](feature_leader_key.md) - Tap the leader key followed by a sequence to trigger custom behavior.
* [Macros](feature_macros.md) - Send multiple key presses when pressing only one physical key.
* [Mouse keys](feature_mouse_keys.md) - Control your mouse pointer from your keyboard.
* [Pointing Device](feature_pointing_device.md) - Framework for connecting your custom pointing device to your keyboard.
* [PS2 Mouse](feature_ps2_mouse.md) - Driver for connecting a PS/2 mouse directly to your keyboard.
* [RGB Light](feature_rgblight.md) - RGB lighting for your keyboard.
* [RGB Matrix](feature_rgb_matrix.md) - RGB Matrix lights for per key lighting.
* [Space Cadet](feature_space_cadet.md) - Use your left/right shift keys to type parenthesis and brackets.
* [Stenography](feature_stenography.md) - Put your keyboard into Plover mode for stenography use.
* [Swap Hands](feature_swap_hands.md) - Mirror your keyboard for one handed usage.
* [Tap Dance](feature_tap_dance.md) - Make a single key do as many things as you want.
* [Terminal](feature_terminal.md) - CLI interface to the internals of your keyboard.
* [Thermal Printer](feature_thermal_printer.md) - Connect a thermal printer to your keyboard to be able to toggle on a printed log of everything you type.
@@ -4,6 +4,8 @@ This page describes setting up the build environment for QMK. These instructions
<!-- FIXME: We should have ARM instructions somewhere. -->
Note: If it is your first time here, Check out the "Complete Newbs guide" instead
## Linux
To ensure you are always up to date, you can just run `sudo util/install_dependencies.sh`. That should always install all the dependencies needed. **This will run `apt-get upgrade`.**
@@ -54,7 +56,7 @@ If you're using [homebrew,](http://brew.sh/) you can use the following commands:
This will compile the targeted keyboard/keymap and leave it in your QMK directory for you to flash.
## 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](01_Getting_Started/01_Install_Build_Tools/Vagrant.md).
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).
There are a lot of resources for getting help with QMK.
## Realtime Chat
You can find QMK developers and users on our main [Discord server](https://discord.gg/Uq7gcHh). There are specific channels in the server for chatting about the firmware, Toolbox, hardware, and configurator.
## OLKB Subreddit
The official QMK forum is [/r/olkb](https://reddit.com/r/olkb) on [reddit.com](https://reddit.com).
## Github Issues
You can open an [issue on GitHub](https://github.com/qmk/qmk_firmware/issues). This is especially handy when your issue will require long-term discussion or debugging.
Github can be a little tricky to those that aren't familiar with it - this guide will walk through each step of forking, cloning, and submitting a pull request with QMK.
{% hint style='info' %}
This guide assumes you're somewhat comfortable with running things at the command line, and have git installed on your system.
{% endhint %}
?> This guide assumes you're somewhat comfortable with running things at the command line, and have git installed on your system.
Start on the [QMK Github page](https://github.com/qmk/qmk_firmware), and you'll see a button in the upper right that says "Fork":
@@ -21,8 +19,7 @@ And be sure to select "HTTPS", and select the link and copy it:
From here, enter `git clone ` into the command line, and then paste your link:
@@ -35,13 +32,12 @@ Checking out files: 100% (2799/2799), done.
You now have your QMK fork on your local machine, and you can add your keymap, compile it and flash it to your board. Once you're happy with your changes, you can add, commit, and push them to your fork like this:
@@ -6,12 +6,16 @@ This page attempts to explain the basic information you need to know to work wit
QMK is a fork of [Jun Wako](https://github.com/tmk)'s [tmk_keyboard](https://github.com/tmk/tmk_keyboard) project. The original TMK code, with modifications, can be found in the `tmk` folder. The QMK additions to the project may be found in the `quantum` folder. Keyboard projects may be found in the `handwired` and `keyboard` folders.
### Userspace Structure
Within the folder `users` is a directory for each user. This is a place for users to put code that they might use between keyboards. See the docs for [Userspace feature](feature_userspace.md) for more information.
### Keyboard Project Structure
Within the folder `keyboards` and its subfolder `handwired` is a directory for each keyboard project, for example `qmk_firmware/keyboards/clueboard`. Within it you'll find the following structure:
* `keymaps/`: Different keymaps that can be built
* `rules.mk`: The file that sets the default "make" options. Do not edit this file directly, instead use a keymap specific `Makefile`
* `rules.mk`: The file that sets the default "make" options. Do not edit this file directly, instead use a keymap specific `rules.mk`.
* `config.h`: The file that sets the default compile time options. Do not edit this file directly, instead use a keymap specific `config.h`.
### Keymap Structure
@@ -25,23 +29,26 @@ In every keymap folder, the following files may be found. Only `keymap.c` is req
If the keymap `config.h` exists, that file is included by the build system and the keyboard `config.h` is not included. If you wish to override settings in your keymap's `config.h` you will need to include some glue code:
The build system automatically picks up the config files in the above order. If you wish to override any setting set by a previous `config.h` you will need to first include some boilerplate code for the settings you wish to change.
```
#ifndef CONFIG_USER_H
#define CONFIG_USER_H
#include "config_common.h"
#pragma once
```
If you want to override a setting from the parent`config.h` file, you need to`#undef` and then `#define` the setting again, like this:
Then to override a setting from the previous`config.h` file you must`#undef` and then `#define` the setting again.
```c
The boilerplate code and setting look like this together:
@@ -14,7 +14,7 @@ The full syntax of the `make` command is `<keyboard_folder>:<keymap>:<target>`,
The `<target>` means the following
* If no target is given, then it's the same as `all` below
* `all` compiles as many keyboard/revision/keymap combinations as specified. For example, `make planck/rev4:default` will generate a single .hex, while `make planck/rev4:all` will generate a hex for every keymap available to the planck.
* `dfu`, `teensy` or `dfu-util`, compile and upload the firmware to the keyboard. If the compilation fails, then nothing will be uploaded. The programmer to use depends on the keyboard. For most keyboards it's `dfu`, but for ChibiOS keyboards you should use `dfu-util`, and `teensy` for standard Teensys. To find out which command you should use for your keyboard, check the keyboard specific readme.
* `dfu`, `teensy`, `avrdude` or `dfu-util`, compile and upload the firmware to the keyboard. If the compilation fails, then nothing will be uploaded. The programmer to use depends on the keyboard. For most keyboards it's `dfu`, but for ChibiOS keyboards you should use `dfu-util`, and `teensy` for standard Teensys. To find out which command you should use for your keyboard, check the keyboard specific readme.
* **Note**: some operating systems need root access for these commands to work, so in that case you need to run for example `sudo make planck/rev4:default:dfu`.
* `clean`, cleans the build output folders to make sure that everything is built from scratch. Run this before normal compilation if you have some unexplainable problems.
@@ -113,7 +113,7 @@ This allows you to interface with a Bluefruit EZ-key to send keycodes wirelessly
`AUDIO_ENABLE`
This allows you output audio on the C6 pin (needs abstracting). See the [audio page](05_Features/Audio.md) for more information.
This allows you output audio on the C6 pin (needs abstracting). See the [audio page](feature_audio.md) for more information.
`FAUXCLICKY_ENABLE`
@@ -121,7 +121,7 @@ Uses buzzer to emulate clicky switches. A cheap imitation of the Cherry blue swi
`VARIABLE_TRACE`
Use this to debug changes to variable values, see the [tracing variables](07_Reference/Unit_Testing.md#tracing-variables) section of the Unit Testing page for more information.
Use this to debug changes to variable values, see the [tracing variables](unit_testing.md#tracing-variables) section of the Unit Testing page for more information.
`API_SYSEX_ENABLE`
@@ -131,7 +131,11 @@ This consumes about 5390 bytes.
`KEY_LOCK_ENABLE`
This enables [key lock](05_Features/Key_Lock.md). This consumes an additional 260 bytes.
This enables [key lock](feature_key_lock.md). This consumes an additional 260 bytes.
`SPLIT_KEYBOARD`
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
## Customizing Makefile Options on a Per-Keymap Basis
Note that the layout of the keycodes is similar to the physical layout of our keyboard - this make it much easier to see what's going on. A lot of the keycodes should be fairly obvious, but for a full list of them, check out [Keycodes](06_Keycodes/index.md) - there are also a lot of aliases to condense your keymap file.
Note that the layout of the keycodes is similar to the physical layout of our keyboard - this make it much easier to see what's going on. A lot of the keycodes should be fairly obvious, but for a full list of them, check out [Keycodes](keycodes.md) - there are also a lot of aliases to condense your keymap file.
It's also important to use the `KEYMAP` function we defined earlier - this is what allows the firmware to associate our intended readable keymap with the actual wiring.
## Compiling Your Firmware
After you've written out your entire keymap, you're ready to get the firmware compiled and onto your Teensy. Before compiling, you'll need to get your [development environment set-up](01_Getting_Started/index.md) - you can skip the dfu-programmer instructions, but you'll need to download and install the [Teensy Loader](https://www.pjrc.com/teensy/loader.html) to get the firmware on your Teensy.
After you've written out your entire keymap, you're ready to get the firmware compiled and onto your Teensy. Before compiling, you'll need to get your [development environment set-up](getting_started_build_tools.md) - you can skip the dfu-programmer instructions, but you'll need to download and install the [Teensy Loader](https://www.pjrc.com/teensy/loader.html) to get the firmware on your Teensy.
Once everything is installed, running `make` in the terminal should get you some output, and eventually a `<project_name>.hex` file in that folder. If you're having trouble with this step, see the end of the guide for the trouble-shooting section.
QMK runs on a variety of hardware. If your processor can be targeted by [LUFA](http://www.fourwalledcubicle.com/LUFA.php) or [ChibiOS](http://www.chibios.com) you can probably get QMK running on it. This section explores getting QMK running on, and communicating with, hardware of all kinds.
This page describes the support for for AVR processors in QMK. AVR processors include the atmega32u4, atmega32u2, at90usb1286, and other processors from Atmel Corporation. AVR processors are 8-bit MCU's that are designed to be easy to work with. The most common AVR processors in keyboards have on-board USB and plenty of GPIO for supporting large keyboard matrices. They are the most popular MCU for use in keyboards today.
If you have not yet you should read the [Keyboard Guidelines](07_Reference/01_Keyboard_Guidelines.md) to get a sense of how keyboards fit into QMK.
If you have not yet you should read the [Keyboard Guidelines](hardware_keyboard_guidelines.md) to get a sense of how keyboards fit into QMK.
## Adding Your AVR Keyboard to QMK
@@ -20,15 +20,15 @@ This will create all the files needed to support your new keyboard, and populate
## `readme.md`
This is where you'll describe your keyboard. Please follow the [Keyboard Readme Template](07_Reference/Documentation_Templates.md#keyboard-readmemd-template) when writing your `readme.md`. You're encouraged to place an image at the top of your `readme.md`, please use an external service such as [Imgur](http://imgur.com) to host the images.
This is where you'll describe your keyboard. Please follow the [Keyboard Readme Template](documentation_templates.md#keyboard-readmemd-template) when writing your `readme.md`. You're encouraged to place an image at the top of your `readme.md`, please use an external service such as [Imgur](http://imgur.com) to host the images.
## `<keyboard>.c`
This is where all the custom logic for your keyboard goes. Many keyboards do not need to put anything at all in here. You can learn more about writing custom logic in [Custom Quantum Functions](07_Reference/Custom_Code.md).
This is where all the custom logic for your keyboard goes. Many keyboards do not need to put anything at all in here. You can learn more about writing custom logic in [Custom Quantum Functions](custom_quantum_functions.md).
## `<keyboard>.h`
This is the file you define your [Layout Macro(s)](05_Features/Layouts.md) in. At minimum you should have a `#define LAYOUT` for your keyboard that looks something like this:
This is the file you define your [Layout Macro(s)](feature_layouts.md) in. At minimum you should have a `#define LAYOUT` for your keyboard that looks something like this:
```
#define LAYOUT( \
@@ -48,7 +48,7 @@ The physical matrix (the second half) must have a number of rows equaling `MATRI
## `config.h`
The `config.h` file is where you configure the hardware and feature set for your keyboard. There are a lot of options that can be placed in that file, too many to list there. For a complete overview of available options see the [Config Options](07_Reference/Config_Options.md) page.
The `config.h` file is where you configure the hardware and feature set for your keyboard. There are a lot of options that can be placed in that file, too many to list there. For a complete overview of available options see the [Config Options](config_options.md) page.
### Hardware Configuration
@@ -66,9 +66,7 @@ Do change the `MANUFACTURER`, `PRODUCT`, and `DESCRIPTION` lines to accurately r
#define DESCRIPTION A custom keyboard
```
{% hint style='info' %}
Note: On Windows and macOS the `MANUFACTURER`, `PRODUCT`, and `DESCRIPTION` fields will be displayed in the list of USB devices. On Linux these values will not be visible in `lsusb`, since Linux takes that information from the list published by the USB-IF.
{% endhint %}
?> Note: On Windows and macOS the `MANUFACTURER`, `PRODUCT`, and `DESCRIPTION` fields will be displayed in the list of USB devices. On Linux these values will not be visible in `lsusb`, since Linux takes that information from the list published by the USB-IF.
### Keyboard Matrix Configuration
@@ -97,7 +95,7 @@ Finally, you can specify the direction your diodes point. This can be `COL2ROW`,
### Backlight Configuration
By default QMK supports backlighting on pins `B5`, `B6`, and `B7`. If you are using one of those you can simply enable it here. For more details see the [Backlight Documentation](05_Features/Backlight.md).
By default QMK supports backlighting on pins `B5`, `B6`, and `B7`. If you are using one of those you can simply enable it here. For more details see the [Backlight Documentation](feature_backlight.md).
```
#define BACKLIGHT_PIN B7
@@ -107,12 +105,12 @@ By default QMK supports backlighting on pins `B5`, `B6`, and `B7`. If you are us
```
{% hint style='info' %}
You can use backlighting on any pin you like, but you will have to do more work to support that. See the [Backlight Documentation](05_Features/Backlight.md) for more details.
You can use backlighting on any pin you like, but you will have to do more work to support that. See the [Backlight Documentation](feature_backlight.md) for more details.
{% endhint %}
### Other Configuration Options
There are a lot of features that can be configured or tuned in `config.h`. You should see the [Config Options](07_Reference/Config_Options.md) page for more details.
There are a lot of features that can be configured or tuned in `config.h`. You should see the [Config Options](config_options.md) page for more details.
There are a number of features that can be turned on or off in `rules.mk`. See the [Config Options](07_Reference/Config_Options.md#feature-options) page for a detailed list and description.
There are a number of features that can be turned on or off in `rules.mk`. See the [Config Options](config_options.md#feature-options) page for a detailed list and description.
@@ -8,7 +8,7 @@ All names should be lowercase alphanumeric, and separated by an underscore (`_`)
## `readme.md`
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](07_Reference/Documentation_Templates.md#keyboard-readmemd-template).
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).
## Image/Hardware Files
@@ -22,7 +22,7 @@ Given the amount of functionality that QMK exposes it's very easy to confuse new
### Bootmagic and Command
[Bootmagic](05_Features/Bootmagic.md) and [Command](05_Features/Command.md) are two related features that allow a user to control their keyboard in non-obvious ways. We recommend you think long and hard about if you're going to enable either feature, and how you will expose this functionality. Keep in mind that users who want this functionality can enable it in their personal keymaps without affecting all the novice users who may be using your keyboard as their first programmable board.
[Bootmagic](feature_bootmagic.md) and [Command](feature_command.md) are two related features that allow a user to control their keyboard in non-obvious ways. We recommend you think long and hard about if you're going to enable either feature, and how you will expose this functionality. Keep in mind that users who want this functionality can enable it in their personal keymaps without affecting all the novice users who may be using your keyboard as their first programmable board.
By far the most common problem new users encounter is accidentally triggering Bootmagic while they're plugging in their keyboard. They're holding the keyboard by the bottom, unknowingly pressing in alt and spacebar, and then they find that these keys have been swapped on them. We recommend leaving this feature disabled by default, but if you do turn it on consider setting `BOOTMAGIC_KEY_SALT` to a key that is hard to press while plugging your keyboard in.
@@ -30,7 +30,7 @@ If your keyboard does not have 2 shift keys you should provide a working default
## Custom Keyboard Programming
As documented on [Customizing Functionality](07_Reference/Custom_Code.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`.
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
@@ -47,16 +47,6 @@ The `info.json` file is a JSON formatted dictionary with the following keys avai
* 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.
* `bootloader`
* What bootloader this keyboard uses. Available options:
* `atmel-dfu`
* `kiibohd-dfu-util`
* `lufa-dfu`
* `qmk-dfu`
* `stm32-dfu-util`
* `caterina`
* `halfkay`
* `bootloadHID`
* `maintainer`
* GitHub username of the maintainer, or `qmk` for community maintained boards
* `width`
@@ -143,4 +133,4 @@ If your keyboard makes use of the [uGFX](https://ugfx.io) features within QMK yo
## Technical Details
If you're looking for more information on making your keyboard work with QMK, [check out the hardware section](04_Hardware/index.md)!
If you're looking for more information on making your keyboard work with QMK, [check out the hardware section](hardware.md)!
@@ -51,7 +51,7 @@ layout is set to QWERTY, a sample of the matching table is as follow:
## Back to the Firmware
As the layout is generally fixed (unless you create your own), the firmware can actually call a keycode by its layout name directly to ease things for you. This is exactly what is done here with `KC_A` actually representing `0x04` in QWERTY. The full list can be found in [keycodes](06_Keycodes/index.md).
As the layout is generally fixed (unless you create your own), the firmware can actually call a keycode by its layout name directly to ease things for you. This is exactly what is done here with `KC_A` actually representing `0x04` in QWERTY. The full list can be found in [keycodes](keycodes.md).
You use the functions when you are implementing your own midi device.
You set a send function to actually send bytes via your device, this method is called when you call a send function with this device, for instance midi_send_cc
You use the midi_device_input to process input data from the device and pass it through the device's associated callbacks.
You use the midi_device_set_pre_input_process_func if you want to have a function called at the beginning of the device's process function, generally to poll for input and pass that into midi_device_input
`public void `[`midi_device_input`](#group__midi__device_1gad8d3db8eb35d9cfa51ef036a0a9d70db)`(`[`MidiDevice`](#struct__midi__device)` * device,uint8_t cnt,uint8_t * input)` | Process input bytes. This function parses bytes and calls the appropriate callbacks associated with the given device. You use this function if you are creating a custom device and you want to have midi input.
`public void `[`midi_device_set_send_func`](#group__midi__device_1ga59f5a46bdd4452f186cc73d9e96d4673)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_var_byte_func_t send_func)` | Set the callback function that will be used for sending output data bytes. This is only used if you're creating a custom device. You'll most likely want the callback function to disable interrupts so that you can call the various midi send functions without worrying about locking.
`public void `[`midi_device_set_pre_input_process_func`](#group__midi__device_1ga4de0841b87c04fc23cb56b6451f33b69)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_no_byte_func_t pre_process_func)` | Set a callback which is called at the beginning of the midi_device_process call. This can be used to poll for input data and send the data through the midi_device_input function. You'll probably only use this if you're creating a custom device.
`struct `[`_midi_device`](docs/api_midi_device.md#struct__midi__device) | This structure represents the input and output functions and processing data for a midi device.
Process input bytes. This function parses bytes and calls the appropriate callbacks associated with the given device. You use this function if you are creating a custom device and you want to have midi input.
#### Parameters
*`device` the midi device to associate the input with
Set the callback function that will be used for sending output data bytes. This is only used if you're creating a custom device. You'll most likely want the callback function to disable interrupts so that you can call the various midi send functions without worrying about locking.
#### Parameters
*`device` the midi device to associate this callback with
*`send_func` the callback function that will do the sending
Set a callback which is called at the beginning of the midi_device_process call. This can be used to poll for input data and send the data through the midi_device_input function. You'll probably only use this if you're creating a custom device.
#### Parameters
*`device` the midi device to associate this callback with
*`midi_no_byte_func_t` the actual callback function
# struct `_midi_device` {#struct__midi__device}
This structure represents the input and output functions and processing data for a midi device.
A device can represent an actual physical device [serial port, usb port] or something virtual. You should not need to modify this structure directly.
When defining a [keymap](07_Reference/Keymap_Overview.md) each key needs a valid key definition. This page documents the symbols that correspond to keycodes that are available to you in QMK.
When defining a [keymap](keymap.md) each key needs a valid key definition. This page documents the symbols that correspond to keycodes that are available to you in QMK.
This is a reference only. Each group of keys links to the page documenting their functionality in more detail.
@@ -215,7 +215,7 @@ To actually handle the keypress event we define an `action_function()`. This fun
This should have given you a basic overview for creating your own keymap. For more details see the following resources:
* [Keycodes](06_Keycodes/index.md)
* [Keymap FAQ](03_FAQ/05_Keymaps.md)
* [Keycodes](keycodes.md)
* [Keymap FAQ](faq_keymap.md)
We are actively working to improve these docs. If you have suggestions for how they could be made better please [file an issue](https://github.com/qmk/qmk_firmware/issues/new)!
QMK is a powerful Open Source firmware for your mechanical keyboard. You can use QMK to customize your keyboard in ways both simple and powerful. People of all skill levels, from complete newbie to master programmer, have successfully used QMK to customize their keyboard. This guide will help you do the same, no matter your skill level.
@@ -8,9 +8,11 @@ Not sure if your keyboard can run QMK? If it's a mechanical keyboard you built y
* [Testing and Debugging](02_Complete_Newbs_Guide/04_Testing_and_Debugging.md)
* [Getting Started](newbs_getting_started.md)
* [Building Your First Firmware](newbs_building_firmware.md)
* [Flashing Firmware](newbs_flashing.md)
* [Testing and Debugging](newbs_testing_debugging.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).
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](01_Getting_Started/07_Getting_Help.md).
@@ -8,17 +8,15 @@ If you have closed and reopened your terminal window since following the first p
Start by navigating to the `keymaps` folder for your keyboard.
{% hint style='info' %}
If you are on macOS or Windows there are commands you can use to easily open the keymaps folder.
?> If you are on macOS or Windows there are commands you can use to easily open the keymaps folder.
macOS:
?> macOS:
open keyboards/<keyboard_folder>/keymaps
Windows:
?> Windows:
start keyboards/<keyboard_folder>/keymaps
{% endhint %}
## Create a Copy Of The `default` Keymap
@@ -32,21 +30,17 @@ Open up your `keymap.c`. Inside this file you'll find the structure that control
This line indicates the start of the list of Layers. Below that you'll find lines containing either `LAYOUT` or `KEYMAP`, and these lines indicate the start of a layer. Below that line is the list of keys that comprise a that particular layer.
{% hint style='danger' %}
When editing your keymap file be careful not to add or remove any commas. If you do you will prevent your firmware from compiling and it may not be easy to figure out where the extra, or missing, comma is.
{% endhint %}
!> When editing your keymap file be careful not to add or remove any commas. If you do you will prevent your firmware from compiling and it may not be easy to figure out where the extra, or missing, comma is.
## Customize The Layout To Your Liking
How to complete this step is entirely up to you. Make the one change that's been bugging you, or completely rework everything. You can remove layers if you don't need all of them, or add layers up to a total of 32. Check the following documentation to find out what you can define here:
* [Keycodes](06_Keycodes/index.md)
* [Features](05_Features/index.html)
* [FAQ](03_FAQ/index.md)
* [Keycodes](keycodes.md)
* [Features](features.md)
* [FAQ](faq.md)
{% hint style='info' %}
While you get a feel for how keymaps work, keep each change small. Bigger changes make it harder to debug any problems that arise.
{% endhint %}
?> While you get a feel for how keymaps work, keep each change small. Bigger changes make it harder to debug any problems that arise.
## Build Your Firmware
@@ -70,4 +64,4 @@ Checking file size of planck_rev5_xyverz.hex
## Flash Your Firmware
Move on to [Flashing Firmware](02_Complete_Newbs_Guide/03_Flashing_Firmware.md) to learn how to write your new firmware to your keyboard.
Move on to [Flashing Firmware](newbs_flashing.md) to learn how to write your new firmware to your keyboard.
@@ -6,23 +6,21 @@ Now that you've built a custom firmware file you'll want to flash your keyboard.
The simplest way to flash your keyboard will be with the [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases).
However, the QMK Toolbox is only available for Windows and macOS currently. If you're using Linux (or just wish to flash the firmware from the command line), you'll have to use the [method outlined below](02_Complete_Newbs_Guide/03_Flashing_Firmware.md#flash-your-keyboard-from-the-command-line).
However, the QMK Toolbox is only available for Windows and macOS currently. If you're using Linux (or just wish to flash the firmware from the command line), you'll have to use the [method outlined below](newbs_flashing.md#flash-your-keyboard-from-the-command-line).
### Load The File Into QMK Toolbox
Begin by opening the QMK Toolbox application. You'll want to locate the firmware file in Finder or Explorer. Your keyboard firmware may be in one of two formats- `.hex` or `.bin`. QMK tries to copy the appropriate one for your keyboard into the root `qmk_firmware` directory.
{% hint style='info' %}
If you are on Windows or macOS there are commands you can use to easily open the current firmware folder in Explorer or Finder.
?> If you are on Windows or macOS there are commands you can use to easily open the current firmware folder in Explorer or Finder.
Windows:
?> Windows:
start .
macOS:
?> macOS:
open .
{% endhint %}
The firmware file always follows this naming format:
@@ -82,7 +80,7 @@ Click the `Flash` button in QMK Toolbox. You will see output similar to the foll
First thing you'll need to know is which bootloader that your keyboard uses. There are four main bootloaders that are used, usually. Pro-Micro and clones use CATERINA, and Teensy's use Halfkay, OLKB boards use QMK-DFU, and other atmega32u4 chips use DFU.
You can find more information about the bootloaders in the [Flashing Instructions and Bootloader Information](01_Getting_Started/04_Flashing_Firmware.md) page.
You can find more information about the bootloaders in the [Flashing Instructions and Bootloader Information](flashing.md) page.
If you know what bootloader that you're using, then when compiling the firmware, you can actually add some extra text to the `make` command to automate the flashing process.
@@ -239,4 +237,4 @@ Booting
Congrats! Your custom firmware has been programmed to your keyboard!
Give it a try and make sure everything works the way you want it to. We've written [Testing and Debugging](02_Complete_Newbs_Guide/04_Testing_and_Debugging.md) to round out this Newbie Guide, so head over there to learn about how to troubleshoot your custom functionality.
Give it a try and make sure everything works the way you want it to. We've written [Testing and Debugging](newbs_testing_debugging.md) to round out this Newbie Guide, so head over there to learn about how to troubleshoot your custom functionality.
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.