* 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
* 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.
* added tanuki
* updated definitions to new qmk standard
* complying with suggestions made by drashna
* update rulesfile
* used qmk template for readme file
* Made an appropriate KLE and converted it.
For use with the CA66 on qmk.fm
* Changed KEYMAP to LAYOUT to match new info.json
* Changed #include and LAYOUT for new info.json
* added own keymap for planck
* dynamic macros
* moved the reset button
* Update readme for volume explanation
* Format
* added safe double shift
* changed the modified shift to regular shift, for allowing shift + F keys
* moved power stuff to the function layer
* del button on raise
* Update Readme.md
* updated F keys
* Add pletcher keymap to dilly/keymaps
For the moment, this keymap just removes unneeded RGB keycodes, since
an iPad will cut the keyboard off if LEDs are turned on.
* Drop support for A_RSFT, add media and autoshift
* Lower USB_MAX_POWER_CONSUMPTION for dilly on iPad
* Document USB_MAX_POWER_CONSUMPTION
This config option is useful for limiting the requested power by, e.g.,
an iOS device. While the default value is 500, a much lower value--say,
50--can sufficiently power a small keyboard without LEDs.
* Add personal keymap for Pearl 40%
* Updating readme and adding keymap image
* Updated readme
* Force make to use Python 3
* cleanup keymap
* updated keymap image
* update readme for new keymap image
* reverting atmega32a_program
* removed redundant sections of user config and rules
* fixed user config file
* fixed led indicators to properly show layer 4
* Fix Unicode sample
* Add irony mark
* Remove unpretty keymaps
* Add QMK DFU and Conditional Music Mode
* Unicode fixes
* Unicode fixes
* Make layer indication more modular
* Finish removing Faux Click
* Cleanup of UserSpace and addition of 'update_tri_layer_state' function
* Add modifier status indicators to Orthodox
* Remove tri layer function
* Minor tweaks
* Remove the Orthodox's Indicator's reliance on layer_state_set
* Add custom EEPROM settings
* Make EEPROM config more efficient
* Viterbi Config
* Add Iris Keyboard layout and Userspace cleanup
* Iris keyboard tweaks
* Use Grave Escape on Iris
* Update Readmes
* edited keymap and fitted for tada68
* edited rules to make mouse work
* filled config.h to make mouse cursor move smooth
* added descriptive readme
* added layout with split backspace and steamlined naming
* added layout with split shift, split backspace and split #
* changed keymap to fit the new layout
* removed duplicate layout KEYMAP_FAKB and pointed keymap.c to default on
* further cleanup from layout duplicate
* 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
* copied lets_slit to splinter
* initial splinter layout
* remove unused keymaps
* implemented second half of the keyboard
* initial definition of tap dance
* the tap dance is working now
tap dance for right hand 4c 2r
hold - shift
single tap - n
double tap - ñ
triple tap - Ñ
* clear the keymap.c
* put the tap state on to array
* the n tilde tap dance should produce right shift if hold
* add esc grv tap dance
* remove the defined SS_LSFT on tap_dance.h
because it was added on the quantum.h
* minor cleanup for the keymap
* use the X_* on tap dance
* added super alt tap dance
* use the NO_TAP on tap dance reset
* allow track what rows and cols pressed
* added the RGUI_ALT
* keymap arrangement
* use i2c
* initial rgb
* layer colors
* initial rgb pressed key
* set the layers led
* SUCCESS!!!
* cleaning
* improve shifted layer
* led brightness
* initial caps rainbow
* rename SET_LED_RGB to SET_LED_RGB_HEX
* clean the SET_LED_RGB_HEX and added SET_LED_RGB
* clean format
* caps lock rainbow
* rename key_led to set_key_led
* caps lock rainbow enhanced
* make varibiables static
* change back the loop max value to 360 for the rainbow
* add scroll lock to the rainbow led
* fix pos calculation of right hand board
* add ative keys and make rainbow color can override by key press
* remove the TOTAL_MATRIX_POINTS
* some improvments for the rgb
* call the rgblight_set on the process_record_user
* some enhancement for the leds
* pass the dim value to set_layer_led and limit the brightness on _VL
set the brightness to 2 if the dim value is less than 2 because
their is not enought power for the leds.
* remove the rgb steps on the config
* use the non rev config
* remove all the revisions
* favor i2c instead of serial and remove all the ref for the serial
* clang formatting
* allow to save to eeprom the brightness value
* add bootloader caterina this will enable soft reset key
* initial commit for the userspace
* added my own keymap for splinter
* first working userspace
* move splinter to handwired keyboards
* handwired splinter default keymap
* move some config to my keymap
* cleanup some headers on the keymap
* move the EECONFIG_RGB_DIM to the user space
* I fix remove the GUI on SPC and ENT
* remove the default include on tap_dance.c
* add lights.c and refactoring
* fix wrong source for led index
* seperate the variable on set_layer_led for readabilty.
* set the usb max power consumption to 50
* fix led lighting
* add new enums for tap dance
* use romeve path avr on eeprom.h
* fix wrong spelling on TP names
* changed the tap dance
* allow to set rainbow on some pressed key
* add reset key
* fix error on matrix.c if ROW2COL is used
* add extraflags -flto
* See e2352d4
* Got no love from i2c, serial to the rescue
* Fix the led will lit up to color red after boot
* Trial if the power can handle yellow color at full
* Add comment
* Use EE_HANDS
* add config.h in the use space
* KC_N on BL should wrap in SFT_T
* See d13567d, put it back but increase 1 level
* Fix led soldering mistake
* set the tapping_term to 100
* Use TT for the changing the layer
* Remove the changing space to enter and vice version on BL and UL
* Increate the tapping term
* Use tap dance on changing layer
* Add assorted layer
* propery way to tapdance
* Remove DA_EGRV
This also fix the wrong placement of the reset and dance lspr should register
the KC_LGUI on finished not unregistered.
* Remove the media control to the up and down layer
* Remove the interrupted state of the tap dance
* swapt the space and enter on to th caps
* Shorthand
* Keymap update
* My keymap for lets_split
* cleaning
* edited keymap and fitted for tada68
* edited rules to make mouse work
* filled config.h to make mouse cursor move more smooth
* added descriptive readme
* added hhkb eric
* dz60 and hhkb
* editted eric hhkb and dz60
* Added HHKB Config
* Removed HHKB Config
* Added HHKB Config
* Changed the legends on HHKB info.json
* Added Tada68 ISO Config and Staryu
* Removed Tada68 ISO Config
* Add naKey on behalf of ckeys
* Update James's code to more modern QMK standards
* Add info.json for QMK Configurator support
* Fix that build breakage
* Rename naKey.c to nakey.c
* Rename naKey.h to nakey.h
* Use the new debounce algorithm in dactyl/matrix.c [#2065]
This incorporates the fixed/optimized debounce code added to
quantum/matrix.c in:
* 508eddf8ba8548d3f71e1c09a404839beb49f45c
* 4c6960835c0a6e29670dabdc27117d7d3c7f99f5
* 32f88c07173b795c6981c779057dceba00aeb1cb
* f4030289744fc6dc82dd85c955070c0845813cc5
* a06115df19a74d39b08758472b221e630c3680d3
* Fix the row/column swap in dactyl [#2065]
With a column-driven keyboard, reading from the mcp23081 returns a
column-state, which takes some extra work to translate into the
row-state used in the actual matrix. The ergodox_ez code sidestepped
that problem by calling rows "columns" and columns "rows." With this
change, the dactyl now calls rows "rows" and columns "columns."
* Cleanup: variable names, documentation [#2065]
* Support MATRIX_MASKED in dactyl/matrix.c [#2065]
* Only unselect one col in unselect_col [#2065]
Bonus: saves one i2c transaction per matrix_scan!
* Implement COL2ROW in dactyl/matrix.c [#2065]
* Fix a typo in dactyl/matrix.c
This entirely doesn't matter. The PORT values are set during
init_keyboard and never change. They're repeatedly set to the same
thing. These PORT lines shouldn't even exist, but since they do, they
should at least look right.
* Implement COL_PINS/ROW_PINS for dactyl [#2065]
* Rename "mcp23018" to "expander" [#2065]
I honestly don't know whether/how well this code works with other I/O
expanders, but at least in theory, it should be generic enough to work
with others. Given that, the variable names shouldn't refer to a
specific model of expander.
* Remove matrix_power_up from dactyl/matrix.c [#2065]
It's commented out in quantum/matrix.c, and the dactyl has no power
up/down behavior beyond being unplugged (which goes to matrix_init), so
there's no sense keeping it around.
* Only initialize expander_input_mask once [#2065]
...and rename input_mask to expander_input_mask, since now that it isn't
scoped to init_expander it isn't clear that it's only for the expander.
* Rename LAYOUT to LAYOUT_all
Add additional layouts for the pearl with all splits
and the pearl with splits but a 6.25u spacebar.
* add new layouts to info.json
* Change handling of adjust layer to make it more LT(...) friendly.
* Update based on feedback from drashna.
* Change handling of adjust layer to make it more LT(...) friendly. This reworks handling to make it a little more friendly to include in keymaps.
* QMK Configurator updates for the Pearl 40%
Attempt to get the physical layout as displayed in the Configurator more true-to-life.
* Bugfixes per mechmerlin
"By changing KEYMAP to LAYOUT in the .h file, all the keymaps who rely on KEYMAP are now broken. You need to go into the keymap directory and fix all the keymaps affected by this change. Should just be an issue of renaming KEYMAP to LAYOUT."
* Merge pull request #2 from noroadsleft/noroadsleft-patch-20180425
Bugfixes per mechmerlin
* keymap.c updates for Pearl
-#include "pearl.h"
+#QMK_KEYBOARD_H
* Update config.h
Matrix pinout updated to current revision.
* Add updated matrix, define RGB pin
Matrix updated to current pinout, pin for WS2812 defined.
* 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
* CU75 keymap fix
Incorrect keymap now fixed
* Add new project files for UT47
* Copy over keymap and related files
* Add LED_controls.ino
* Add README instructions
* Attempt sending press byte data
* Disable mousekeys
* Enable sending serial data to LED controller
* Update LED mode names
* Remove extra file
* Add LED enable flag
* Update READMEs with more info
* Credit original author
* Update copyrights
* Update docs
* Changed based on review
* Move layout screenshot to Imgur
* Append to src
* Enable mousekeys to fix bad keycodes
* Additional changes based on feedback
* Fix fn layer keys
* 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
* nyquist
* danielhklein nyquist setup
* shift left controls
* remove readme
* cleanup before pr
* ready for pr
* updated bootmagic, arrows, and special chars
* allow gui on arrows
* replace arrows with right modifiers
* documentation re-added
* updated personal repo
* fixes to layers
* DRambo Planck keymap in Colemak
* DRambo Planck keymap in Colemak
* Satan GH60 keymap for Bri
QWERTY layout with Navigation layer toggled with "Caps Lock" key.
* xd75 keymap in Colemak for Mac and Win
* DRambo Planck keymap in Colemak
* Satan GH60 keymap for Bri
QWERTY layout with Navigation layer toggled with "Caps Lock" key.
* xd75 keymap in Colemak for Mac and Win
* Added Iris Colemak layout for Mac, Windows, and Gaming.
* changed comment text
* DRambo Planck keymap in Colemak
* Satan GH60 keymap for Bri
QWERTY layout with Navigation layer toggled with "Caps Lock" key.
* xd75 keymap in Colemak for Mac and Win
* Added Iris Colemak layout for Mac, Windows, and Gaming.
* changed comment text
* Added Iris keymap from DavidRambo
* Added planck keymap from DavidRambo
* Added xd75 keymap from DavidRambo
* Added readme
* Deleted redundant repos in Iris, Planck, and XD75 keymaps.
* Tweaked XD75 keymap
* DRambo Planck keymap in Colemak
* Tweaked XD75 keymap
* Merge branch 'master' of https://github.com/DavidRambo/qmk_firmware
Removed redundant repos with "Rambo" title.
* changed iris nav layers
* changed nav layers for xd75
* Updated Iris, tweaked nav on xd75
* add mechmerlin 60 ansi layout
* put meaningful #defines
* missed the backslash
* add merlin split layout
* rename to have a -ansi
* Add appropriate readme files
* rename KEYMAP to LAYOUT
* support for default layout
* support for the community keymaps
* make sure I don't break the configurator
* Don't break the configurator Merlin
* initial commit for meme keyboard
* Fix that row by column
* Fix those dimensions
* work in progress commit
* got that switch matrix to work
* add all supported layouts
* add info.json for QMK configurator support
* let my name be known
* alpha with firmware added to list of keyboards, ready to push
* revised according to drashna's fixes
* keymap -> layout?
* fixed macro and improved layout issuesOC
* Update rules.mk
* Update alpha.h
* Update and rename keyboards/alpha/layouts/default/28_alpha/keymap.c to keyboards/alpha/keymaps/default/keymap.c
* alpha/readme.md added according to qmk templateOC
* resolved a careless merge conflict
* bugfix
* Fixed /keyboards/alpha/readme.md formatting issues
* Add personal Tada68 keymaps
* remove uneccessary tada68 folder
* recommit with temp name
* remove bad folder name
* fix bullet list format
* rename to fezzant
* remove unnecessary config.h file
* Add userspace to talljoe layout.
* Move more authority to userspace and create Bananasplit layout.
* Move more things into userspace.
* Common Core example
* More work on common layout.
* Num layer.
* talljoe-ansi layout
* Updates for Zeal60
* Add Zeal60 to 60_ansi_split_bs_rshift
* Swap Escape and Grave
* Num-layer tweaks
* More tweaks.
* Add 1up60rgb to world of layouts.
* Rename ansi_split_bs_rshift layout to hhkb.
* Control RGB Backlight.
* change capslock led
* Remove obsolete line from rules.mk.
* Add user-friendly userspace override.
* Fix enter for 1uprgb60
* Revert "Rename ansi_split_bs_rshift layout to hhkb."
This reverts commit 53133719db25c7cb6a199108bbf5d980481a45f4.
* Adds initial keyboard config and layouts for ALF X2 60%
* Cleans up empty if/else blocks
* Renames KEYMAP to LAYOUT across the alf_x2 config files.
* Replaces include in alf_x2 keymaps with QMK_KEYBOARD_H macro
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.
## What is QMK Firmware?
## How to Get It {#how-to-get-it}
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
If you plan on contributing a keymap, keyboard, or features to QMK, the easiest thing to do is [fork the repo through Github](https://github.com/qmk/qmk_firmware#fork-destination-box), and clone your repo locally to make your changes, push them, then open a [Pull Request](https://github.com/qmk/qmk_firmware/pulls) from your fork.
Otherwise, you can either download it directly ([zip](https://github.com/qmk/qmk_firmware/zipball/master), [tar](https://github.com/qmk/qmk_firmware/tarball/master)), or clone it via git (`git@github.com:qmk/qmk_firmware.git`), or https (`https://github.com/qmk/qmk_firmware.git`).
## How to Compile {#how-to-compile}
## How to Compile
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:
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:
make planck/rev4:default
@ -20,6 +27,6 @@ This would build the `rev4` revision of the `planck` with the `default` keymap.
make preonic:default
## How to Customize {#how-to-customize}
## How to Customize
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).
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).
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/keycodes.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.
@ -19,14 +19,15 @@ Currently, the keycodes able to used with these functions are limited to the [Ba
# Switching and Toggling Layers
These functions allow you to activate layers in various ways.
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)
* `MO(layer)` - momentary switch to *layer*. As soon as you let go of the key, the layer is deactivated and you pop back out to the previous layer.
* `LT(layer, kc)` - momentary switch to *layer* when held, and *kc* when tapped.
* `TG(layer)` - toggles a layer on or off.
* `TO(layer)` - Goes to a layer. This code is special, because it lets you go either up or down the stack -- just goes directly to the layer you want. So while other codes only let you go _up_ the stack (from layer 0 to layer 3, for example), `TO(2)` is going to get you to layer 2, no matter where you activate it from -- even if you're currently on layer 5. This gets activated on keydown (as soon as the key is pressed).
* `TT(layer)` - Layer Tap-Toggle. If you hold the key down, the layer becomes active, and then deactivates when you let go. And if you repeatedly tap it, the layer simply becomes active (toggles on). It needs 5 taps by default, but you can set it by defining `TAPPING_TOGGLE`, for example, `#define TAPPING_TOGGLE 2` for just two taps.
* `LM(layer, mod)` - Momentary switch to *layer* (like MO), but with modifier(s) *mod* active. Only supports layers 0-15 and the left modifiers.
* `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.
* `TG(layer)` - toggles *layer*, activating it if it's inactive and vice versa
* `TO(layer)` - activates *layer* and de-activates all other layers (except your default layer). This function is special, because instead of just adding/removing one layer to your active layer stack, it will completely replace your current active layers, uniquely allowing you to replace higher layers with a lower one. This is activated on keydown (as soon as the key is pressed).
* `TT(layer)` - Layer Tap-Toggle. If you hold the key down, *layer* is activated, and then is de-activated when you let go (like `MO`). If you repeatedly tap it, the layer will be toggled on or off (like `TG`). It needs 5 taps by default, but you can change this by defining `TAPPING_TOGGLE` -- for example, `#define TAPPING_TOGGLE 2` to toggle on just two taps.
# Working with Layers
@ -36,9 +37,9 @@ Care must be taken when switching layers, it's possible to lock yourself into a
If you are just getting started with QMK you will want to keep everything simple. Follow these guidelines when setting up your layers:
* Setup layer 0 as your "base" layer. This is your normal typing layer, and could be whatever layout you want (qwerty, dvorak, colemak, etc.)
* Setup layer 0 as your default, "base" layer. This is your normal typing layer, and could be whatever layout you want (qwerty, dvorak, colemak, etc.). It's important to set this as the lowest layer since it will typically have most or all of the keyboard's keys defined, so would block other layers from having any effect if it were above them (i.e., had a higher layer number).
* Arrange your layers in a "tree" layout, with layer 0 as the root. Do not try to enter the same layer from more than one other layer.
* Never try to stack a higher numbered layer on top of a lower numbered layer. Doing so is tricky and error prone.
* In a layer's keymap, only reference higher-numbered layers. Because layers are processed from the highest-numbered (topmost) active layer down, modifying the state of lower layers can be tricky and error-prone.
### Intermediate Users
@ -130,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.
@ -89,6 +89,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`:
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).
const rgb_led g_rgb_leds[DRIVER_LED_TOTAL] = {
/* {row | col <<4}
* | {x=0..224, y=0..64}
* | | modifier
* | | | */
{{0|(0<<4)},{20.36*0,21.33*0},1},
{{0|(1<<4)},{20.36*1,21.33*0},1},
....
}
The format for the matrix position used in this array is `{row | (col << 4)}`. The `x` is between (inclusive) 0-224, and `y` is between (inclusive) 0-64. The easiest way to calculate these positions is:
x = 224 / ( NUMBER_OF_ROWS - 1 ) * ROW_POSITION
y = 64 / (NUMBER_OF_COLS - 1 ) * COL_POSITION
Where all variables are decimels/floats.
`modifier` is a boolean, whether or not a certain key is considered a modifier (used in some effects).
## Keycodes
All RGB keycodes are currently shared with the RGBLIGHT system:
* `RGB_TOG` - toggle
* `RGB_MOD` - cycle through modes
* `RGB_HUI` - increase hue
* `RGB_HUD` - decrease hue
* `RGB_SAI` - increase saturation
* `RGB_SAD` - decrease saturation
* `RGB_VAI` - increase value
* `RGB_VAD` - decrease value
* `RGB_SPI` - increase speed effect (no EEPROM support)
* `RGB_SPD` - decrease speed effect (no EEPROM support)
* `RGB_MODE_*` keycodes will generally work, but are not currently mapped to the correct effects for the RGB Matrix system
## RGB Matrix Effects
These are the effects that are currently available:
enum rgb_matrix_effects {
RGB_MATRIX_SOLID_COLOR = 1,
RGB_MATRIX_ALPHAS_MODS,
RGB_MATRIX_DUAL_BEACON,
RGB_MATRIX_GRADIENT_UP_DOWN,
RGB_MATRIX_RAINDROPS,
RGB_MATRIX_CYCLE_ALL,
RGB_MATRIX_CYCLE_LEFT_RIGHT,
RGB_MATRIX_CYCLE_UP_DOWN,
RGB_MATRIX_RAINBOW_BEACON,
RGB_MATRIX_RAINBOW_PINWHEELS,
RGB_MATRIX_RAINBOW_MOVING_CHEVRON,
RGB_MATRIX_JELLYBEAN_RAINDROPS,
#ifdef RGB_MATRIX_KEYPRESSES
RGB_MATRIX_SOLID_REACTIVE,
RGB_MATRIX_SPLASH,
RGB_MATRIX_MULTISPLASH,
RGB_MATRIX_SOLID_SPLASH,
RGB_MATRIX_SOLID_MULTISPLASH,
#endif
RGB_MATRIX_EFFECT_MAX
};
## Custom layer effects
Custom layer effects can be done by defining this in your `<keyboard>.c`:
void rgb_matrix_indicators_kb(void) {
// rgb_matrix_set_color(index, red, green, blue);
}
A similar function works in the keymap as `rgb_matrix_indicators_user`.
## Additional `config.h` Options
#define RGB_MATRIX_KEYPRESSES // reacts to keypresses (will slow down matrix scan by a lot)
#define RGB_MATRIX_KEYRELEASES // reacts to keyreleases (not recommened)
#define RGB_DISABLE_AFTER_TIMEOUT 0 // number of ticks to wait until disabling effects
#define RGB_DISABLE_WHEN_USB_SUSPENDED false // turn off effects when suspended
#define RGB_MATRIX_SKIP_FRAMES 1 // number of frames to skip when displaying animations (0 is full effect) if not defined defaults to 1
## EEPROM storage
The EEPROM for it is currently shared with the RGBLIGHT system (it's generally assumed only one RGB would be used at a time), but could be configured to use its own 32bit address with:
#define EECONFIG_RGB_MATRIX (uint32_t *)16
Where `16` is an unused index from `eeconfig.h`.
## Suspended state
To use the suspend feature, add this to your `<keyboard>.c`:
@ -19,10 +19,12 @@ First, you will need `TAP_DANCE_ENABLE=yes` in your `rules.mk`, because the feat
This array specifies what actions shall be taken when a tap-dance key is in action. Currently, there are three 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_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(KC_SPC, KC_ENT)` will result in `Space` being sent on single-tap, `Enter` otherwise.
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.
And that's the bulk of it!
@ -179,42 +181,124 @@ Below is a specific example:
* Double Tap = Send `Escape`
* Double Tap and Hold = Send `Alt`
The following example can be easily expanded to more than 4 quite easily:
## Setup
You will need a few things that can be used for 'Quad Function Tap-Dance'. The suggested setup is to create a user directory for yourself. This directory will contain rules.mk `<your_name>.c` and `<your_name>.h`. This directory should be called `<your_name>`, and located in the top level `users` directory. There should already be a few examples to look at there.
### In `/qmk_firmware/users/<your_name>/rules.mk`
Put the following:
```c
//**************** Definitions needed for quad function to work *********************//
//Enums used to clearly convey the state of the tap dance
TAP_DANCE_ENABLE = yes
SRC += your_name.c
```
Pretty simple. It is a nice way to keep some rules common on all your keymaps.
### In `/qmk_firmware/users/<your_name>/<you_name>.h`
You will need a few things in this file:
```c
#ifndef YOUR_NAME
#define YOUR_NAME
#include "quantum.h"
#include "process_keycode/process_tap_dance.h"
typedef struct {
bool is_press_action;
int state;
} xtap;
enum {
SINGLE_TAP = 1,
SINGLE_HOLD = 2,
DOUBLE_TAP = 3,
DOUBLE_HOLD = 4,
DOUBLE_SINGLE_TAP = 5 //send SINGLE_TAP twice - NOT DOUBLE_TAP
// Add more enums here if you want for triple, quadruple, etc.
DOUBLE_SINGLE_TAP = 5, //send two single taps
TRIPLE_TAP = 6,
TRIPLE_HOLD = 7
};
typedef struct {
bool is_press_action;
int state;
} tap;
//Tap dance enums
enum {
CTL_X = 0,
SOME_OTHER_DANCE
}
int cur_dance (qk_tap_dance_state_t *state);
//for the x tap dance. Put it here so it can be used in any keymap
Will include the `/users/jack/` folder in the path, along with `/users/jack/rules.mk`.
Additionally, `config.h` here will be processed like the same file in your keymap folder. This is handled separately from the `<name>.h` file.
Additionally, `config.h` here will be processed like the same file in your keymap folder. This is handled separately from the `<name>.h` file.
The reason for this, is that `<name>.h` won't be added in time to add settings (such as `#define TAPPING_TERM 100`), and including the `<name.h>` file in any `config.h` files will result in compile issues.
The reason for this, is that `<name>.h` won't be added in time to add settings (such as `#define TAPPING_TERM 100`), and including the `<name.h>` file in any `config.h` files will result in compile issues.
So you should use the `config.h` for QMK settings, and the `<name>.h` file for user or keymap specific settings.
So you should use the `config.h` for QMK settings, and the `<name>.h` file for user or keymap specific settings.
## 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).
## `Config.h`
If you do add a `config,h` file, you want to make sure that it only gets processed once. So you may want to start off with something like this:
If you do add a `config,h` file, you want to make sure that it only gets processed once. So you may want to start off with something like this:
```c
#ifndef USERSPACE_CONFIG_H
@ -48,7 +48,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](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).
This will add a new `KC_MAKE` keycode that can be used in any of your keymaps. And this keycode will output `make <keyboard>:<keymap">`, making frequent compiling easier. And this will work with any keyboard and any keymap as it will output the current boards info, so that you don't have to type this out every time.
Additionally, this should flash the newly compiled firmware automatically, using the correct utility, based on the bootloader settings (or default to just generating the HEX file). However, it should be noted that this may not work on all systems. AVRDUDE doesn't work on WSL, namely (and will dump the HEX in the ".build" folder instead).
## 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](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`:
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":
@ -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.
@ -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.
@ -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,9 +30,7 @@ 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
@ -44,9 +40,7 @@ How to complete this step is entirely up to you. Make the one change that's been
* [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.
@ -12,17 +12,15 @@ However, the QMK Toolbox is only available for Windows and macOS currently. If
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:
@ -14,9 +14,7 @@ Before you can build keymaps you need to install some software and setup your bu
You'll need a program that can edit and save **plain text** files. If you are on Windows you can make due with Notepad, and on Linux you can use Gedit, both of which are simple but functional text editors. On macOS you can not use TextEdit.app, it will not save plain text files. You will need to install another program such as Sublime Text.
{% hint style='info' %}
Not sure which text editor to use? Laurence Bradford wrote [a great introduction](https://learntocodewith.me/programming/basics/text-editors/) to the subject.
{% endhint %}
?> Not sure which text editor to use? Laurence Bradford wrote [a great introduction](https://learntocodewith.me/programming/basics/text-editors/) to the subject.
### QMK Toolbox
@ -29,12 +27,9 @@ QMK Toolbox is a Windows and macOS program that allows you to both program and d
We've tried to make QMK as easy to setup as possible. You only have to prepare your Linux or Unix environment and let QMK install the rest.
{% hint style="info" %}
If you haven't worked with the Linux/Unix command line before there are a few basic concepts and commands you should learn. These resources will teach you enough to work with QMK:
* [Must Know Linux Commands](https://www.guru99.com/must-know-linux-commands.html)
?> If you haven't worked with the Linux/Unix command line before there are a few basic concepts and commands you should learn. These resources will teach you enough to work with QMK:<br>
[Must Know Linux Commands](https://www.guru99.com/must-know-linux-commands.html)<br>
@ -63,9 +58,7 @@ Once you have setup your Linux/Unix environment you are ready to download QMK. W
git clone https://github.com/qmk/qmk_firmware.git
cd qmk_firmware
{% hint style='info' %}
If you already know [how to use GitHub](getting_started_github.md) we recommend you create and clone your own fork instead. If you don't know what that means you can safely ignore this message.
{% endhint %}
?> If you already know [how to use GitHub](getting_started_github.md) we recommend you create and clone your own fork instead. If you don't know what that means you can safely ignore this message.
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.
